Straight-Through Processing in Treasury

Straight-through processing (STP) means a transaction flows end to end — from initiation through confirmation, settlement and accounting — with no manual re-keying or intervention. In treasury, high STP means a payment or deal is captured once and then flows automatically through every downstream step. It matters because these transactions move real money: every manual touchpoint STP removes is a place where an error can no longer creep in, a delay can no longer form, and a fraud can no longer hide. STP isn't automation for its own sake — it's the systematic removal of the risky, valueless human steps between "we decided to pay" and "it's paid and booked."

What STP is

Picture a payment's journey: someone initiates it, it's approved, sent to the bank, settled, acknowledged, and posted to the ledger. STP is the degree to which that whole chain happens without anyone re-entering the data. Full STP: entered once, flows all the way through. No STP: a human re-keys it at every boundary — into the banking portal, then into the accounting system, then into a reconciliation sheet.

Why it matters

Four benefits, all significant, but the last is the real prize:

• Fewer errors. Data entered once and reused can't be mistyped at step three.
• Lower cost. Manual re-keying is slow, expensive human effort doing what a machine should.
• More speed. Automated flows settle and post faster, with less lag.
• Stronger control. This is the one that matters most. Every hand that touches a payment is a control risk and a fraud opportunity. Fewer touchpoints means fewer places for money to be diverted or a mistake to slip through.

"

Every manual re-keying step in a payment flow is two things at once: a place for an honest error, and a place for a dishonest one. STP closes both at the same time.

What breaks STP

STP degrades wherever a human is forced to copy, translate or re-enter:

• Swivel-chair integration. Systems that don't talk, bridged by a person reading one screen and typing into another.
• Format mismatches. A bank or system that needs data in a shape nothing else produces, so someone translates it by hand. (This is why standard formats and ISO 20022 matter for STP.)
• Exceptions. Transactions that fall out of the automated path — a failed match, a missing reference — and land in a manual queue.
• Manual approvals outside workflow. Approvals done over email or on paper rather than in a system workflow, forcing re-entry to record the decision.

The building blocks

High STP rests on the same foundations as the rest of good treasury architecture:

• Integration — systems connected so data flows, not swivel-chaired.
• Standard formats — a common language so no translation step is needed.
• Matching — automated reconciliation (confirmations, statements, payment status) so the routine cases clear themselves.
• Workflow — approvals and controls built into the system, so a control step doesn't become a manual break.

STP vs exceptions: 100% is a myth

The goal is high STP, not total STP. Some transactions genuinely need human judgement — an unusual deal, a genuine exception, a control that should pause and ask. Chasing 100% automation means either forcing bad automation onto cases that need a person, or removing controls that should exist. The real target is: automate the routine to near-total, and handle the exceptions well — route them fast, to the right person, with context. A good STP design is measured as much by how cleanly it handles the exceptions as by how few there are.

Measuring it

STP is measurable: the STP rate is the proportion of transactions that flow through untouched. Tracking it — by process, by counterparty, by bank — turns "we should automate more" into a specific target and shows where the manual breaks actually are. What you measure, you can improve; an unmeasured STP rate is just a vague aspiration.

What usually goes wrong

• Swivel-chair everywhere. Unintegrated systems bridged by people, accepted as normal.
• Re-keying across formats. Manual translation because formats were never standardised.
• Controls as manual breaks. Approvals done outside workflow, so every control step breaks the flow and gets re-entered.
• No measurement. No STP rate, so no one knows where the manual effort and risk actually concentrate.
• Chasing 100%. Over-automating cases that need judgement, or dropping necessary controls to hit a number.

Integrate the systems, standardise the formats, automate the matching, build controls into workflow, and measure the STP rate — and treasury processing shifts from a chain of risky manual hand-offs to a flow that's captured once and trusted end to end. That's not just efficiency; for a function that moves money, it's one of the strongest controls you have.

See also interface monitoring and reconciliation and segregation of duties.