# Stp Automation > 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 a… - **Type:** Skill - **Install:** `agentstack add skill-joellewis-finance-skills-stp-automation` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [JoelLewis](https://agentstack.voostack.com/s/joellewis) - **Installs:** 0 - **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [JoelLewis](https://github.com/JoelLewis) - **Source:** https://github.com/JoelLewis/finance_skills/tree/main/plugins/client-operations/skills/stp-automation ## Install ```sh agentstack add skill-joellewis-finance-skills-stp-automation ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # 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 subject to specific regulatory requirements (ERISA, OFAC screening, Reg SHO locate) route through the appropriate compliance check. **Exception handling.** When a transaction fails validation or cannot be routed automatically, the system must identify the exception, categorize it, and route it to the appropriate resolution queue. This is the boundary between STP and manual processing. The goal is to make the exception boundary as narrow as possible, handling as many edge cases automatically as the risk tolerance permits. **Status tracking.** Automated monitoring of every transaction's progress through the process. Each step in the workflow updates a status record. Status tracking enables real-time dashboards, automated escalation when items age beyond thresholds, and end-of-day completeness reporting. ### 3. Exception-Based Processing The foundational shift in operations efficiency is moving from a review-all model (every transaction is reviewed by a human) to a review-exceptions model (only transactions that fail automated validation are reviewed by a human). **Exception categorization.** Effective exception management requires a taxonomy of exception types: - **Data quality exceptions.** Missing data, invalid formats, unrecognized identifiers. These are preventable with better upstream data management and are the highest-priority targets for STP improvement. - **Validation failure exceptions.** Transactions that fail cross-field, range, or referential checks. Examples: price tolerance breach, unmatched settlement instructions, quantity exceeding position. - **Rule violation exceptions.** Transactions that violate business rules or compliance rules. Examples: concentration limit breach, restricted security trade, unapproved counterparty. - **System error exceptions.** Technical failures — timeout, connectivity loss, message parsing error. These are infrastructure issues, not business logic issues. - **Timing exceptions.** Transactions that arrive too late for same-day processing, miss a cutoff, or reference a future-dated event that cannot yet be processed. **Exception queuing and prioritization.** Exceptions are routed to work queues organized by type, severity, and urgency. Prioritization factors include: - Settlement date proximity (items settling today or tomorrow are highest priority) - Dollar value (larger transactions carry more financial risk if unresolved) - Counterparty SLA requirements (some counterparties have contractual resolution timeframes) - Regulatory deadlines (e.g., T+1 settlement compliance, corporate action election deadlines) - Aging (items that have been in the queue longer receive escalating priority) **Exception resolution workflows.** Each exception category has a defined resolution procedure: 1. The resolver opens the exception and reviews the details. 2. The system presents the likely root cause based on the exception category and historical patterns. 3. The resolver takes corrective action (amends data, contacts the counterparty, overrides with documentation, cancels and rebooks). 4. The corrected transaction re-enters the automated flow from the point of failure. 5. The resolution is logged with the action taken, the resolver's identity, and the timestamp. **Auto-resolution rules.** For well-understood, low-risk exception categories, the system can apply automated resolution without human intervention. Examples: - If a security identifier is missing but can be derived from other fields (e.g., ticker + exchange uniquely identifies a CUSIP), auto-populate and re-process. - If a settlement instruction mismatch is within a defined tolerance (e.g., accrued interest difference of less than $1.00), auto-match. - If a price tolerance breach is caused by a stale reference price, auto-update the reference price from the market data feed and re-validate. Auto-resolution rules require careful governance. Each rule must be documented with its rationale, risk assessment, approval authority, and periodic review schedule. **Exception metrics.** Key measurements for exception management: - **Exception volume.** Total exceptions per period, broken down by category. Trend analysis reveals whether STP is improving or degrading. - **Exception rate.** Exceptions as a percentage of total volume. The inverse of the STP rate. - **Aging distribution.** How long exceptions remain unresolved. A healthy queue has most items resolved same-day. Items aging beyond one day require escalation. - **Resolution time.** Average and median time from exception creation to resolution. Broken down by category to identify which types are slowest to resolve. - **Repeat exceptions.** Transactions or counterparties that generate the same exception repeatedly. These are the highest-value targets for root cause remediation. - **Auto-resolution rate.** The percentage of exceptions resolved by auto-resolution rules without human intervention. A sub-STP metric that measures the effectiveness of the auto-resolution layer. ### 4. Process Automation Patterns Different operational contexts call for different automation approaches. The patterns below are listed from simplest to most sophisticated. **Rule-based automation.** If-then logic applied to structured data. The most common and most reliable form of automation. Examples: if the trade is a listed equity with a recognized counterparty and standard settlement terms, route directly to settlement. If the account opening application has all required fields populated and KYC verification passes, submit to the custodian. Rule-based automation is deterministic, auditable, and easy to explain to regulators. **Template-based automation.** Standardized output generation from variable inputs. Examples: generating settlement instructions from trade data using a counterparty-specific template, producing client reports by populating a template with account data, creating regulatory filings by mapping internal data to the required format. Templates reduce errors by eliminating free-form composition. **Workflow automation.** Multi-step orchestrated processes where the completion of one step triggers the next. A workflow engine manages the sequence, handles branching logic (if step 3 fails, route to exception handling; if step 3 succeeds, proceed to step 4), and tracks status. Workflow automation is the backbone of STP — it connects individual automated steps into an end-to-end chain. **Robotic process automation (RPA).** Software bots that interact with application user interfaces the same way a human would — clicking buttons, entering data into fields, reading screen values, navigating menus. RPA is the automation pattern of last resort, used when: - The target system has no API or file-based integration option - The system is a legacy application that cannot be modified - The integration is temporary (bridging until a proper API is built) - The volume does not justify the cost of building a native integration RPA is brittle — UI changes break the bot — and requires ongoing maintenance. It is a pragmatic solution, not an architectural one. **API-based automation.** System-to-system communication through defined interfaces. The gold standard for integration because it is structured, versioned, documented, and testable. REST APIs, SOAP web services, and FIX protocol connections all fall in this category. API-based automation enables real-time, synchronous processing (request-response) or asynchronous processing (fire-and-forget with callback or polling). **Machine learning-assisted automation.** Classification, anomaly detection, and pattern recognition applied to operational data. Examples: classifying incoming corporate action notices by event type, detecting anomalous settlement fails that may indicate a counterparty issue, predicting which exception items are likely to auto-resolve vs. require human attention. ML-assisted automation augments rule-based processing by handling cases where rules are too complex to enumerate or where patterns evolve over time. ### 5. STP by Operations Domain Each operations domain has distinct STP characteristics, challenges, and success factors. **Account opening STP.** From application receipt through funded, active account. NIGO taxonomy, pre-submission validation, document requirements matrices, and custodian submission design are covered in account-opening-workflow; apply the measurement and exception-management framework in this skill to the targets defined there (60-80% STP for simple individual/joint accounts, 20-40% for complex entity/trust accounts). **Trade processing STP.** From trade execution through allocation, confirmation, and booking. Key STP challenges: block trade allocation complexity, counterparty confirmation matching, non-standard settlement terms, late trade reporting, manual enrichment of trade details. Success factors: standardized allocation rules, automated confirmation matching (CTM, ALERT), reference data quality for securities and counterparties, real-time trade validation against compliance rules. **Settlement STP.** From trade booking through delivery/receipt of securities and funds. Key STP challenges: settlement instruction mismatches, fails due to insufficient securities or funds, cross-border settlement complexity (time zones, local market practices, CSD requirements), partial settlement decisions. Success factors: SSI (standing settlement instruction) databases, automated matching engines, pre-settlement position checks, proactive fail management. **Corporate actions STP.** From event notification through entitlement calculation and booking. Key STP challenges: unstructured event notifications (narrative-format announcements), complex event types (mergers with elections, rights issues, spin-offs with fractional shares), tight election deadlines, multi-custodian entitlement reconciliation. Success factors: ISO 20022 event messaging, automated scrubbing of event data, rule-based entitlement calculation for mandatory events, automated deadline tracking. **Reconciliation STP.** Automated matching of internal records against custodian and counterparty records. Auto-match rate benchmarks, matching rule design, break categorization, and tolerance thresholds are covered in reconciliation; that skill owns the auto-match content, and reconciliation also serves as the primary detective control over every other STP domain. **Reporting STP.** Automated generation and delivery of regulatory reports, client reports, and management reports. Key STP challenges: data aggregation from multiple sources, format requirements that change with regulatory updates, exception handling for missing or in … ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [JoelLewis](https://github.com/JoelLewis) - **Source:** [JoelLewis/finance_skills](https://github.com/JoelLewis/finance_skills) - **License:** MIT Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-joellewis-finance-skills-stp-automation - Seller: https://agentstack.voostack.com/s/joellewis - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.