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 It’s Ignored	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
`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.

deduplication