Is STP the same as real-time processing?

No. STP concerns manual intervention; an automatic process can still run in scheduled batches or wait for another system.

Is STP the same as robotic process automation?

No. RPA is one possible automation technique, while STP describes completion across a defined process.

Does an approval step prevent STP?

A required manual approval within the measured path means that case did not complete without intervention. State the boundary rather than hiding the step.

AI Glossary / Governance, ethics and safety / Advanced

Straight-through processing

Definition

Straight-through processing, or STP, is the completion of a defined transaction or business process through connected automated steps without manual intervention along that path. It depends on information moving between stages in usable form. STP can use AI, conventional business rules and system integrations, but AI is not required. State the measured process boundaries.

What it means

Automating one step is not the same as completing the whole process automatically. A system may extract information from a document but still require someone to correct it, approve it or re-enter it elsewhere. That case has not passed straight through a boundary that includes those activities.
An operation can support STP for suitable cases while sending exceptions to people. Distinguish automatic completion from the exception path. A useful report states which cases were eligible, which completed automatically and which needed intervention.
Human involvement in designing, maintaining and overseeing the system is compatible with individual transactions completing automatically. STP describes the transaction path, not an organization without human responsibility.

How it works

The workflow receives information, checks required fields and conditions, and passes the case through connected steps. Shared data definitions and reliable interfaces reduce the need for manual interpretation or re-entry. In financial messaging, structured standards such as ISO 20022 can support this interoperability.
Rules determine whether a case can continue automatically. Missing information, conflicting records or failed checks may create an exception. The system needs to record its status, prevent accidental duplicate actions and provide a clear route for resolution.
AI can support parts of the workflow, such as interpreting documents or categorizing requests. Its output still needs suitable validation against the requirements of the next step. A confident extraction is not proof that a downstream action is authorized or correct. Monitoring should distinguish automated completion from accurate completion and track failures after apparently successful processing.

Three practical examples

Order administration: A standard order is received, validated against agreed product information, recorded and acknowledged automatically. An invalid product code sends it to an exception queue.
Invoice handling: A system extracts invoice details and matches them with approved records. A mismatch requires review, so the case is not counted as straight-through completion for that measured workflow.
Service activation: A routine request passes eligibility checks and activates an agreed service without staff re-entry. Cases needing an additional decision follow a separate path with a recorded owner.

Think of it this way

Imagine a parcel moving through connected sorting stations without someone having to read and rewrite its label at each stop. The smooth path depends on a usable label, agreed destinations and working connections. A parcel diverted for investigation is an exception, and passing every station automatically does not itself prove that the original destination was correct.

Worked example

A fictional team receives 1,000 requests in a reporting period. It defines 800 as eligible for a particular automated workflow. Of those, 680 complete without manual intervention, while 120 require review. The other 200 follow a separate manual process.
The STP rate among eligible requests is 680 / 800 = 85%. The share of all incoming requests completed straight through is 680 / 1,000 = 68%. State the denominator.
Suppose a later check finds that 20 of the 680 automatic completions require correction. The team should report that rework separately rather than calling the 85% figure a quality score. If it defines an additional measure of automatic completions without subsequent correction in this period, the count is 660, or 82.5% of eligible requests.
These figures depend on the defined process boundary and follow-up window. They do not estimate total cost savings or prove that broadening eligibility would improve the service.

Illustrative case study

Fictional company Cedar Orders introduces automated processing for standard requests. The intake system reports a high automation rate because most forms are read successfully. Staff later reveal that they manually repair customer codes before the records reach the fulfillment system.
The company redraws the measurement boundary from receipt to confirmed recording in the destination system. It counts repairs as interventions and records their causes. The team discovers that two systems use different identifiers for the same product family.
It corrects the mapping, tests the integration and monitors both completion and rework. This fictional case illustrates why removing a recurring handoff problem can matter more than improving an isolated AI extraction score.

Common misconceptions and mistakes

“STP means every case must be automated.” Exception handling can be an intentional part of a responsible operating model.
“An automatic first step means an automatic process.” Manual correction or re-entry later in the defined path still matters.
“STP rate measures accuracy.” It measures automated passage under a stated convention; errors and rework require separate measures.
“AI is necessary.” Structured inputs, rules and integrations can support STP without machine learning.
“Automation guarantees compliance.” Requirements must be implemented correctly, and the resulting process needs appropriate oversight and evidence.

Business use

Define the process boundary and eligibility criteria before setting a target. Track intervention causes so improvements address recurring problems rather than merely exclude difficult cases from the denominator.
Assess completion time, quality, rework and exception workload together. Ensure that failures have owners and that records preserve what happened at each stage. When AI is involved, check whether model errors can trigger downstream consequences and whether uncertain cases are routed appropriately. A higher STP rate is useful only when the resulting service meets its intended requirements.

Check your understanding

Why are 85% and 68% both correct?

Answer: They use eligible requests and all requests as different denominators.

Why record later corrections?

Answer: Automated completion alone does not establish correct completion.

What should happen to a failed validation?

Answer: The process should record and route the exception instead of silently forcing it through.

Related terms

Business process management
Robotic process automation
Workflow automation
exception handling
system integration
data validation
reconciliation
human oversight

Learn next

Map a transaction from receipt to its final recorded outcome. Identify manual interventions, define an STP denominator and compare the resulting rate with quality and rework measures.

Sources

IBM, What Is Straight-Through Processing?, process scope and automation. https://www.ibm.com/think/topics/straight-through-processing Swift, About ISO 20022, structured financial messaging and interoperability. https://www.swift.com/standards/iso-20022 Stripe, What Is Straight Through Processing?, transaction automation context. https://stripe.com/resources/more/what-is-straight-through-processing-heres-what-you-need-to-know The rate calculations, practical scenarios and Cedar Orders case are original teaching illustrations.

Previous: Straight-through estimator Next: Strata