Which STP failures belong in repair?

Payment Series | Episode 16

The payment failed STP. Do you really want Operations to touch it? 🤔

Not every STP failure belongs in repair.

Some can be fixed.

Some should be rejected.

And some only create unnecessary Operations workload.

Take two illustrative examples.

Scenario 1: No intermediary found

The Payment Engine cannot resolve a correspondent for the creditor agent.

Operations may be able to investigate and enrich the agent chain using permitted reference data such as:

SSI · SwiftRef · Routing tables

✅ Repairable

But if the same exception appears every day:

Fix the routing rule, not the queue.

Scenario 2: Insufficient funds

The payment passes validation, but the debtor account cannot cover the debit.

What can Operations actually repair?

Usually, nothing.

Depending on product and cut-off rules, the payment may:

→ Wait for funding

→ Retry later

→ Move to hold

→ Reject

❌ Not repairable

💡 Payment Professional Takeaway

Before sending an exception to repair, ask:

Can human intervention genuinely change the outcome?

Then check:

→ Is repair worth the SLA, cut-off and operational cost?

→ Who owns the exception and what happens next?

For every exception, define:

Repairable / Non-repairable · Owner · Queue · SLA · Next action

A repair queue is not a dumping ground.

It is for exceptions where human intervention can genuinely change the payment outcome.

💬 What is the most common reason payments land in repair in your bank?

One episode. One practical example. One insight.

#Payments #PaymentOperations #STP #PaymentRouting #ISO20022