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.

Part of the Treasury Systems Architecture guide. See also interface monitoring and reconciliation and segregation of duties. The newsletter sends one finance-systems pattern every two weeks.