Message Repair Queue

A message repair queue is a work queue inside a bank's or payment firm's processing system where payment messages that cannot be processed automatically are held for staff to review, correct, approve or reject. It is a working term used in payment operations rather than a formally defined standard: the queue may be called a repair queue, exception queue or manual intervention queue depending on the vendor and the bank.

Messages land there when they fail payment message validation, cannot be routed, lack required data, or trigger a rule that needs human judgement. The size of the queue and how fast it is cleared are closely watched, because every repaired message costs staff time, risks missing a cut-off time and lowers the firm's straight-through processing rate. The queue sits close to, but apart from, the alert queues used for sanctions screening and fraud.

Think of an automated parcel-sorting line. Most boxes have clear labels and roll straight onto the right lorry. A few have a smudged postcode, a missing street name or two different addresses. Those are pushed onto a side table, where a person reads them, fixes the label if they can, and puts them back on the line, or sends them back to the sender if they cannot.

The message repair queue is that side table for payments. The fewer boxes that end up there, the faster and cheaper the whole operation runs. But when a box does land on the table, the person fixing it has to be careful: correcting a label in the wrong way can send money to the wrong place.

• Bad identifiers. An invalid Bank Identifier Code (BIC), an IBAN with wrong check digits, or a clearing code that does not match the bank named.
• Missing or unstructured data. Addresses or purpose codes that a scheme now requires in structured form under ISO 20022.
• Routing problems. No known route or correspondent bank for the currency, or an intermediary bank that is not reachable.
• Translation issues. Data truncated or lost when converting between legacy formats such as the SWIFT MT103 and ISO 20022.
• Business rule breaches. An unsupported currency, a value date in the past, or an amount above a limit that needs approval.

1. Capture. The system parks the message with a reason code explaining the failure.
2. Auto-repair. Many systems first try rules-based fixes, such as looking up a BIC from a national clearing code or reformatting a date. These are logged.
3. Manual repair. An operator corrects fields using reference data, or contacts the sender or customer.
4. Four-eyes approval. Changes to sensitive fields such as the beneficiary account, name or amount usually require a second person to approve.
5. Release or reject. The repaired message goes back through validation; unfixable messages are rejected, returned or held in a suspense account while a payment investigation runs.

Repair should never change a transaction's identity. The end-to-end transaction reference and UETR must pass through unchanged, so the payment can still be traced and later matched by the beneficiary through payment reference matching.

The usual measure of how much work avoids the queue is the straight-through processing (STP) rate:

The repair rate is the complement, 100% minus the STP rate. For example, if a bank processes 20,000 outgoing payments in a day and 600 go to the repair queue, the STP rate is $(20{,}000 - 600) \div 20{,}000 \times 100 = 97\%$ and the repair rate is 3%. If each repair takes an average of six minutes, those 600 messages consume 60 hours of staff time.

Operations teams also track queue age (how long items wait), items repaired versus rejected, repeat causes by sender, and how many items miss a cut-off. A growing queue behaves much like an alert backlog in compliance: delays compound, and older items are the riskiest.

The repair queue is an area of operational risk. Manual edits can introduce errors, and an operator who changes a beneficiary account could divert funds, so access rights, audit trails and dual approval are standard controls. Repaired messages must be re-screened, since a corrected name or country may now hit a sanctions list. Banks also try to reduce repairs at the source by giving corporate clients validation tools, publishing formatting guides, and rejecting rather than repairing in instant schemes, where there is no time for manual work. Persistent repair volumes from legacy payment systems are a common reason to invest in upgrades.

• Swift
• ISO 20022