- Knowledge Base
- Reporting Services
- Validations
How does KOR identify a duplicate message?
Duplicate Message Handling
To protect data quality and avoid processing the same trade more than once, KOR uses a system that checks if a message is a duplicate before accepting it.
How it Works:
We create a unique “fingerprint” (called a hash) of each message using its content. If a new message has the same fingerprint as one we’ve already received, we reject it with error code 157 – Duplicate Message.
We do not silently skip duplicates — they are actively rejected to help clients track what happened.
What Goes Into the Fingerprint:
We include almost every field in the message. However, we exclude certain fields that don’t change the meaning of the trade or are tied to processing time, such as:
| Field Name | When Field is Excluded | Why It’s Excluded |
|---|---|---|
reportingTimestamp |
Always | Just shows when the system handled the message |
eventTimestamp |
Ignored unless level = PSTN | Operational updates often change this field |
actionType |
Always | Tells us what to do with the message, not its content |
clientMessageIdentifier |
Always | Processing field with no regulatory impact. |
amendmentIndicator |
Ignored for MODI messages | Helps avoid confusion when comparing MODI vs NEWT |
transactionTimestamp |
Excluded only for REMIT | That timestamp varies under REMIT without meaning a real change |
Everything else is used to ensure the system can catch true duplicates, regardless of formatting or data type differences.
What state is the de-dup logic performed against?
Always performed against the current valid trade state. (e.g., if a rejected message is submitted against the trade the state is not updated with those terms for this check)
Are any action type excluded?
Yes, EROR, REVI, and PRTO are excluded from this check as they do not update terms of the trade and would fail resubmission due to action type sequence validation.
