/stp-automation

name: stp-automation
description: "Measure and raise straight-through processing (STP) rates in securities operations through zero-touch, exception-based processing. Use when measuring STP rates and analyzing manual touchpoints in an existing process, replacing review-all workflows with exception-based processing, evaluating RPA vs API-based vs hybrid automation for legacy systems, building exception queuing, categorization, and auto-resolution workflows, conducting process mining or root cause analysis on exception volumes, or setting STP rate targets and continuous improvement programs. For approval chains, four-eyes controls, and SLA monitoring, see workflow-automation."

STP & Automation

Core Concepts

1. STP Fundamentals

Straight-through processing is the end-to-end automated completion of a business process without manual intervention: a transaction enters the system at one end and exits as a completed, booked, and confirmed event at the other with no human touching it along the way. True STP means zero manual intervention for the happy path; a process with a human review or approval at a midpoint is partially automated, not STP.

**STP rate calculation.** The fundamental metric is:

STP Rate = Automated Completions / Total Volume * 100

An "automated completion" is a transaction or workflow instance that passed through every step without manual intervention. If a trade requires a human to confirm a counterparty identifier before it can settle, that trade is not STP even though every other step was automated. The denominator is total volume, including both automated and exception items.

**Industry benchmarks by process type.** STP rates vary significantly by domain and firm maturity:

• Equity trade processing (listed, domestic): 90-98% for mature firms
• Fixed income trade processing: 70-85% (lower due to less standardized identifiers and settlement conventions)
• Account opening (simple individual/joint accounts): 60-80%
• Account opening (complex entity/trust accounts): 20-40%
• Corporate actions (mandatory events): 80-90%
• Corporate actions (voluntary events): 30-50%
• Reconciliation (position and cash): 85-95% auto-match rates
• Settlement instruction matching: 75-90%

These ranges reflect the spectrum from mid-tier broker-dealers to large custodian banks. A firm's position within the range depends on data quality, system integration maturity, and the complexity of its product mix.

**The business case for STP** compounds across four dimensions: cost reduction (per-transaction labor cost becomes fixed infrastructure cost), speed (seconds instead of queuing and handoff delays — directly reducing settlement risk), error reduction (consistent rules instead of re-keying and judgment variance), and scalability (volume spikes at quarter-end or corporate action clusters do not require proportional staffing).

2. STP Architecture

Building STP capability requires five architectural layers that work in concert. A weakness in any layer breaks the chain and forces manual intervention.

**Data standardization.** This is the foundation. STP fails when systems disagree on how to represent the same entity. Standardization encompasses:

• **Identifiers.** Security identifiers (CUSIP, ISIN, SEDOL, ticker), counterparty identifiers (LEI, DTCC participant number, BIC/SWIFT code), account identifiers (custodian account number, internal account ID). Every system in the chain must resolve to the same identifier for the same entity.
• **Formats.** Date formats (ISO 8601), currency codes (ISO 4217), country codes (ISO 3166), quantity representations (whole shares vs. fractional, signed vs. unsigned), price formats (decimal vs. fraction for fixed income).
• **Reference data.** A golden source for security master data, counterparty data, and account data that all systems consume. Discrepancies in reference data are the single largest source of STP breaks.
• **Messaging standards.** FIX protocol for trade messages, SWIFT for settlement instructions, ISO 20022 for payments and corporate actions. Adoption of industry-standard messaging reduces translation errors.

**Validation rules.** At each step in the process, the system applies automated checks to confirm the data is complete, consistent, and within expected parameters:

• **Completeness checks.** All required fields populated (e.g., a settlement instruction must have settlement date, security identifier, quantity, counterparty, settlement location).
• **Format checks.** Values conform to expected formats (dates are valid, amounts are numeric, identifiers match expected patterns).
• **Cross-field checks.** Logical consistency between fields (settlement date is after trade date, quantity and side agree with the net money calculation, currency matches the security's denomination).
• **Range checks.** Values fall within acceptable ranges (price is within a tolerance of the last known price, quantity does not exceed position, settlement date is within the standard settlement cycle).
• **Referential checks.** Referenced entities exist in the system (the security is in the security master, the counterparty is in the counterparty database, the account is active).

**Routing rules.** Automated decision-making that directs a transaction through the correct processing path without human judgment:

• **Product-based routing.** Equities route to equity settlement, fixed income to fixed income settlement, derivatives to derivatives processing.
• **Market-based routing.** Domestic trades route to domestic settlement systems, international trades route to global custody.
• **Counterparty-based routing.** Trades with certain counterparties route to specialized queues or systems (e.g., prime brokerage trades, DVP vs. free delivery).
• **Threshold-based routing.** Transactions above a dollar or quantity threshold route to a senior review queue. Transactions below the threshold process automatically.
• **Regulatory routing.** Transactions s