Straight-through processing measurement quantifies the share of in-scope cases that reach a valid accepted business outcome from a defined start event to a defined end event without disallowed human handling, hidden correction or manual re-entry. A defensible measure fixes the case identifier, observation window, eligible population, permitted system actions, terminal state and treatment of retries, reopens and downstream reversals. The rate is reported with quality, time, exception and control measures because a high touchless percentage alone does not prove a good process.
STP rates are easy to inflate. Teams exclude difficult channels, count attempts instead of cases, stop the clock at a technical handoff, label a bulk upload as automated or ignore corrections performed after completion. Failed cases can disappear from the denominator and reopened work can appear as a new case. An automation may achieve a high rate by rejecting more inputs, lowering validation or pushing review downstream. When each team defines touch differently, portfolio comparisons become meaningless and incentives reward routing around the metric rather than improving the service.
Define one end-to-end case and business outcome before instrumenting events. Use the full intended population as the primary denominator, then show eligibility and exclusions separately. Count a case as STP only after the acceptance window closes and relevant downstream validation has passed. Preserve every touch, retry, repair, route and reopen in the trace. Segment by source and risk, pair the headline rate with harmful outcomes and queue time, and reconcile event data to operating records. Treat changes in denominator or rules as versioned metric changes, not silent improvement.
Definition
Fix the case boundary and denominator before calculating a rate
Define the business case independently of system messages. A payment, invoice, onboarding request or service case may create several technical attempts but should retain one stable identity. State the start event early enough to include preparation and intake work. Define the terminal business outcome and an acceptance window during which rejection, reversal or correction can invalidate completion. A file successfully transmitted to another queue is not end-to-end processing if people must finish the decision there.
Use the total intended in-scope cohort as the primary denominator. Show technical eligibility as a second measure rather than deleting ineligible cases. Publish exclusions such as tests, duplicates confirmed before processing and genuinely out-of-scope requests with reason codes. Track cancelled and abandoned cases separately. Freeze cohort membership by the start event so later failures cannot disappear. This structure reveals whether improvement comes from better processing, cleaner inputs or a narrower population.
| Population | Meaning | Control |
|---|---|---|
| In scope | All intended business cases | Stable primary denominator |
| Eligible | Cases automation can attempt | Eligibility rate shown |
| Attempted | Cases entering the automated path | No duplicate attempts |
| Completed | Cases reaching a terminal state | Acceptance window open |
| Accepted STP | Valid outcome without disallowed touch | Final numerator |
Instrumentation
Define touch and preserve the entire event trace
Create a touch taxonomy before implementation. Human interpretation, correction, approval, re-entry and exception decisions normally disqualify touchless completion. Pure monitoring, automated validation and policy-approved system recovery may not. Bulk upload or bulk approval is still human handling when a person prepares or authorizes the cases. Record the actor type, action, reason and source rather than inferring touch from a missing screen event. Include support tools, email and offline preparation where they affect the case.
The event trace needs case identifier, event time, processing time where different, state, system, actor type, reason, rule or model version and correlation across handoffs. Idempotent retries remain attached to the same case. Reopens and post-completion corrections link back to the original cohort. Validate event ordering and impossible transitions. Missing telemetry should create an unknown classification, not an automatic STP success. Reconcile case counts with operational queues, ledgers or other authoritative records.
- Classify human decisions and preparation explicitly.
- Keep retries and duplicates under the original case identity.
- Link downstream corrections and reopens to the original cohort.
- Store rule and automation versions with each decision.
- Treat missing traces as unknown until reconciled.
Measurement
Pair the headline rate with quality, exceptions and time
The headline numerator is accepted cases that completed without a disallowed touch. Report it against the total in-scope cohort and, secondarily, against eligible cases. Add first-pass completion, first-pass acceptance, exception rate, automated repair, retry, reopen, reversal, harmful acceptance and harmful rejection. Measure elapsed time from the business start and active human handling separately. An STP gain that increases rejection, abandonment or correction is not an operating improvement.
Segment by source channel, product, partner, document type, language, complexity, risk tier and rule version where these materially change behavior. Use cohorts based on start time and wait until their acceptance windows mature. Show counts with percentages because a high rate on a tiny segment can mislead. Use confidence intervals or ranges for sampled quality measures. Compare cost per accepted outcome, including platform, review, exception and support work, instead of cost per automated attempt.
| Dimension | Measure | Gaming signal |
|---|---|---|
| Coverage | Eligible and attempted share | Difficult work excluded |
| Automation | Accepted STP share | Technical handoff counted |
| Quality | Correction and harmful outcome | Validation weakened |
| Flow | Elapsed time and queue age | Work moved downstream |
| Economics | Cost per accepted outcome | Residual work omitted |
Governance
Version the definition and improve exception causes
Assign a metric owner and publish the formula, event sources, touch taxonomy, exclusions, acceptance window, segments and current version. Any change that can affect numerator or denominator receives an effective date and parallel calculation where practical. Preserve prior series or clearly break the trend. Review access and audit trails so teams cannot recode cases solely to improve performance. Use independent samples of accepted STP cases to test whether telemetry and quality controls agree with reality.
Drive improvement from the exception Pareto by cause, consequence and source. Prevent incomplete inputs, standardize valid variation, strengthen validation, repair deterministic errors and design effective human routes for real ambiguity. Observe whether one intervention moves work to another team or later stage. Set targets for quality and access alongside STP. The strongest program can accept a lower rate where consequence requires judgment and can explain why. Straight-through processing is a means to reliable flow, not an objective that overrides the business outcome.
- Publish and version every component of the formula.
- Reconcile dashboard counts with authoritative operating records.
- Independently sample accepted cases for hidden touch and defects.
- Improve exception causes rather than recoding their denominator.
- Allow a deliberate human boundary when consequence requires it.
What good looks like
Useful outcomes from measure straight through processing
- The organization uses one case boundary and accepted end state across teams.
- Eligible, excluded, attempted, completed and accepted populations are visible separately.
- Manual touches, automated repairs, retries, reopens and downstream reversals are consistently classified.
- The STP rate cannot improve merely by rejecting or excluding difficult work.
- Quality, control and customer outcomes remain visible beside automation volume.
- Segments expose where channels, products, partners or data create exceptions.
- Metric versions and rule changes preserve comparability over time.
- Improvement work targets exception causes rather than optimizing a dashboard number.
Operating model
How to run the work
- 01
Define the case and end state
Choose the business trigger, stable identifier, scope, terminal outcome, acceptance window and downstream checks. State whether cancellation, rejection and abandonment count.
- 02
Specify populations and touch rules
Define total in-scope, technically eligible, attempted and accepted cases. Classify human decisions, data repair, bulk actions, automated recovery, retries and support intervention.
- 03
Instrument the end-to-end trace
Record ordered events with case, timestamp, actor type, system, rule version, reason, state and correlation across handoffs. Preserve reopens and corrections.
- 04
Calculate a metric family
Report accepted STP, eligibility, completion, exception, first-pass quality, rework, harmful outcome, latency and cost by meaningful segment and cohort.
- 05
Reconcile and govern the measure
Compare event totals with financial and operational records, investigate missing cases, version definitions and require review before exclusions or acceptance rules change.
Evaluation
Questions that change the decision
- What event opens one business case and what stable identifier follows it?
- Which outcome is genuinely complete and for how long can it still be reversed?
- Which cases belong in the intended population even if automation cannot process them?
- What human activity disqualifies STP and what system repair remains permitted?
- How are retries, duplicates, partial completions, reopens and cancellations counted?
- Which downstream defects invalidate an apparently completed case?
- Which segments need separate rates because their rules or risks differ?
- Who owns the metric definition and approves a version change?
Failure modes
Where teams lose control
The denominator can exclude precisely the cases that generate operational work.
A workflow can count messages or attempts rather than unique business cases.
A technical completion can occur before the customer or ledger outcome is accepted.
Manual spreadsheet preparation can be hidden before the measured start event.
Bulk approval can be misclassified as touchless processing.
Automated retries can inflate volume or conceal unstable processing.
Rejected cases can improve STP while worsening service access or conversion.
Downstream correction and reversal can happen outside the observation window.
Aggregate rates can hide poor performance for one source, language or risk tier.
Changing the touch definition can create an artificial improvement trend.
Measurement
Measure the finished job
Measure the completed workflow, including review effort and exceptions. Output volume on its own is not evidence of a better process.
- accepted STP cases divided by the total in-scope cohort
- technical eligibility and attempted automation rate
- first-pass completion and first-pass acceptance
- manual-touch and exception rate by reason
- automated repair, retry and duplicate rate
- reopen, downstream correction and reversal rate
- harmful acceptance, rejection and abandonment
- active handling and end-to-end elapsed time
- cost per accepted case including residual operations
- event completeness and reconciliation difference
Questions
Common questions
What is a good straight-through processing rate?
There is no universal target. The appropriate rate depends on case mix, control obligations and consequences. Compare a stable definition over time with quality, access and cost.
Should ineligible cases be excluded from the STP denominator?
Keep the total intended population visible as the primary view and report technical eligibility separately. Otherwise the rate can improve by narrowing what automation attempts.
Does automated correction still count as STP?
It can if the correction is policy-approved, deterministic, fully traced and produces a valid outcome without human handling. Report automated repair separately to expose instability.
When should an STP case be counted as complete?
Only after the defined business outcome is accepted and the relevant correction or reversal window has closed, not merely when one system hands the case to another.
Sources
Primary references
- Straight-through processing definition European Central Bank
- Foreign exchange risk guidance on STP Bank for International Settlements
About the author
George Manolas
George writes about commercial qualification, RFP operations and the delivery economics behind enterprise technology decisions.
Zenith
AI workflow automation for repetitive, document-heavy and research-heavy operations.
Operations, finance, commercial and transformation teams. Start with the workflow, constraints and evidence you already have.
See Zenith→