Trade Fails & Exception Resolution Agent
- Version
- v1
- Owner
- Hiroshi Tanaka · Desk Head
- Desk
- Cross-Asset Solutions
- Effective date
- 09 Jul 2026
- Review cycle
- Annual
- Graph
- 5 nodes · 4 edges
- Generated
- 25 Oct 2026 · 22:33 UTC
Contents
Document control
This Policy & Procedure document is generated live from the governed definition of the application. Its authority derives from the platform record — the versioned DAG, the governance sign-offs and the append-only audit log — not from separate manual authoring.
- Document ID
- PP-FAILS-AGENT-V1
- Application
- Trade Fails & Exception Resolution Agent · fails-agent
- Version
- v1
- Status
- Prod
- Category
- Back office
- Owner
- Hiroshi Tanaka — Desk Head (Cross-Asset Solutions desk)
- Classification
- Internal
- Effective date
- 09 Jul 2026
- Review cycle
- Annual
- Last submitted
- 03 Jun 2026
- Generated
- 25 Oct 2026 · 22:33 UTC
Purpose & scope
Purpose
Pulls TLM breaks, diagnoses the SSI mismatch, takes an ops confirmation and re-matches the trade.
It sits in the Back office domain of the Markets OS App Studio and is delivered as a visually-built Directed Acyclic Graph of typed nodes, executed in a deterministic topological order under enforced governance.
In scope
- The end-to-end automated workflow defined by the current app version and its nodes.
- The controls embedded in that workflow (human approvals, risk monitors, validations).
- The systems and datasets the workflow reads through the safe MCP broker.
- The governance gates every version must clear before it can run in production.
Out of scope
- This is a decision-support / automation workflow — it is not investment advice, and it does not itself constitute an order to trade.
- In this proof-of-concept the external connectors (Murex, TLM, Bloomberg, Progmat, SAP, Oracle ERP) are simulated behind the broker; no live booking or settlement occurs.
- Bespoke desk mandates, limits and suitability checks remain governed by their own policies.
Roles & responsibilities
The parties below carry the app through its lifecycle. HITL approver roles are read directly from the app's HUMAN_IN_LOOP node configuration, so this table reflects the controls actually wired into the workflow.
| Party | Responsibility |
|---|---|
| Hiroshi Tanaka (Owner) | Accountable for the app: its correctness, its fitness for purpose and its release into production. |
| Platform Engineering / Champions | Build, test and maintain the DAG; remediate findings; publish new versions. |
| Desk head (HITL approver) | Provide the human approval at each HUMAN_IN_LOOP gate during a run. |
| Technology Standards reviewer, Business Risk reviewer | Clear the governance gates and cryptographically sign off each release. |
| Internal Audit & Assurance | Independent oversight; reads the append-only audit log and sign-off ledger. |
| Head of Global Markets | Ultimate business accountability for the app estate this document belongs to. |
RACI matrix
| Activity | Responsible | Accountable | Consulted | Informed |
|---|---|---|---|---|
| Build, test & maintain the app | Platform Engineering | Hiroshi Tanaka | Desk users | Audit |
| Submit & release to production | Hiroshi Tanaka | Head of Global Markets | Technology Standards reviewer; Business Risk reviewer | Audit |
| Operational approval during runs (HITL) | Desk head | Hiroshi Tanaka | Business Risk | Audit |
| Technical & risk governance review | Technology Standards reviewer; Business Risk reviewer | Head of Global Markets | Compliance | Audit |
| Independent oversight & assurance | Internal Audit | Head of Global Markets | — | Regulators |
RACI — Responsible does the work · Accountable owns the outcome · Consulted gives input · Informed is kept in the loop.
Process overview & procedure
The procedure below is the exact sequence the execution engine runs, listed in the topological order the platform schedules (Kahn's algorithm — every step appears after the steps it depends on). Each step names the action, the system or dataset it touches, its inputs and outputs, and any control that fires at that point.
| # | Action | System / data | Inputs | Outputs | Control |
|---|---|---|---|---|---|
| 1 | TLM Breaks (MCP call) | TLM · getBreaks (via MCP) | Workflow trigger | Diagnose SSI | — |
| 2 | Diagnose SSI (Transform) | Platform compute | TLM Breaks | Ops Review | — |
| 3 | Ops Review (Human in loop) | Approver: DESK_HEAD | Diagnose SSI | TLM Match Trade | Human approval — DESK_HEAD (SLA 90m) |
| 4 | TLM Match Trade (MCP call) | TLM · matchTrade (via MCP) | Ops Review | Resolution | — |
| 5 | Resolution (Output) | Platform compute | TLM Match Trade | Final output | — |
Key controls
Controls prefixed C- are wired into this app's DAG; controls prefixed P- are platform controls that apply to every governed app. Evidence for each is recorded in the named table.
| Control | Description | Type | Owner | Frequency | Evidence |
|---|---|---|---|---|---|
| C-01 | Ops Review — Human approval by DESK_HEAD within a 90-minute SLA. The run halts (PENDING_HITL) until the decision is recorded. | Preventive | DESK_HEAD | Per run | mos_execution_node_results |
| P-01 | Four-eyes on trades — the database enforces approver ≠ trader on every booking (CHECK constraint chk_trade_four_eyes). | Preventive | Platform | Per trade | mos_trades |
| P-02 | Governance release gates — DRAFT → TECH_STANDARDS_REVIEW → BUSINESS_RISK_REVIEW → APPROVED_FOR_PROD → PROD; no version runs in production un-gated. | Preventive | Governance | Per release | mos_governance_reviews |
| P-03 | $50M / high-risk-counterparty auto-mandate — a size or counterparty breach in any node config forces a Level-3 Compliance review, recorded with its machine reason. | Preventive / Detective | Governance | Per submission | mos_governance_reviews.mandated_reason |
| P-04 | Cryptographic sign-offs — each gate is cleared by an HMAC signature over a hash of the exact graph, re-verified at promotion time. | Preventive | Governance | Per release | mos_governance_signoffs |
| P-05 | Append-only audit log — every state change is written immutably; overrides require a ≥20-character justification (DB CHECK). | Detective | Platform | Continuous | mos_audit_log |
| P-06 | Safe MCP allow-list — the AI never touches a system directly; the broker allow-lists each operation, denies writes on read-only connectors, and audits every call. | Preventive | Platform | Per call | mos_mcp_invocations |
Key metrics & KPIs
The operational metrics below are computed live from the execution ledger. The workspace for this app presents the same figures as live KPI tiles and charts.
| Metric | Definition | Target | Current | Source |
|---|---|---|---|---|
| Run volume | Total workflow executions recorded for this app. | Steady-state utilisation once live | 1 | mos_execution_runs |
| STP rate | Runs completing straight-through with no failure. | ≥ 95% | 0.0% | mos_execution_runs |
| HITL interventions | Runs that halted awaiting a human decision. | Minimise; resolve within SLA | 1 | mos_execution_runs · mos_execution_node_results |
| HITL SLA | Target minutes to a human decision at each HUMAN_IN_LOOP gate. | 90m | 90m | HUMAN_IN_LOOP node config |
| Execution failures | Runs that ended FAILED. | 0 | 0 | mos_execution_runs |
Systems & data lineage
Every external system this workflow interfaces is reached through the MCP broker — the only safe path to a connector. The broker allow-lists the operation, denies any write on a read-only connector, and audits the call. No node touches a live system directly.
| System / source | Type | Interface | Access | Note |
|---|---|---|---|---|
| TLM | Connector (MCP) | getBreaks | Read-only via broker | Allow-listed; every call audited to mos_mcp_invocations. |
Risk & regulatory
Regulatory validations
This version references no explicit VALIDATION ruleset. Regulatory obligations remain governed by the desk's standing controls and the platform governance gates.
Governance status
- Current version status
- Prod
- Release control
- Gated (DRAFT → PROD) with cryptographic sign-offs
- Audit trail
- Append-only mos_audit_log
Model risk
Any pricing, risk or NLP node embeds a model. In this proof-of-concept those computations are deterministic simulations; in production they fall under the bank's model-risk management framework (independent validation, periodic review and performance monitoring) before use.
Change history
Every version this app has carried, newest first. A new version is always a fresh DRAFT until it clears governance.
| Version | Status | Author | Created | Submitted | Approved |
|---|---|---|---|---|---|
| v1 (current) | Prod | Hiroshi Tanaka | 24 May 2026 | 03 Jun 2026 | 09 Jul 2026 |
Approvals & sign-offs
Each sign-off is an HMAC signature over a hash of the exact graph that was signed, appended to the immutable sign-off ledger. The Verified badge is re-derived here and now — the same check promotion runs — so any tampering with the ledger row or the graph shows as Invalid.
| Gate | Signer | Decision | Signature | Signed at | Hash |
|---|---|---|---|---|---|
| Tech standards | Raj Patel | Approved | Verified | 20 Jun 2026 · 02:57 | 1e0236d2ea7f305ba35152da… |
| Business risk | Anja Kowalski | Approved | Verified | 20 Jun 2026 · 02:57 | 59e8380db6b24c07d896ada6… |
Glossary & references
Node types used in this app
| Type | Name | Family | Meaning |
|---|---|---|---|
| MCP_CALL | MCP call | Source | Calls an external system through the safe, audited MCP broker. |
| DATA_TRANSFORM | Transform | Transform | Maps, filters, aggregates, joins or enriches data in-flow. |
| HUMAN_IN_LOOP | Human in loop | Control | Halts the run and waits for a named human to approve. |
| OUTPUT | Output | Sink | The terminal result of the workflow. |
Connectors
| Connector | System |
|---|---|
| MUREX | Murex MX.3 — trade capture, valuation & book risk |
| TLM | SmartStream TLM — reconciliation, breaks & settlement instructions |
| BLOOMBERG | Bloomberg — market data, curves, FX rates & security static |
| PROGMAT | Progmat — tokenization ledger & on-chain settlement |
| SAP | SAP Treasury — treasury & cash positions, journals |
| ORACLE_ERP | Oracle ERP — general-ledger & AP/AR balances |
Platform terms
| Term | Definition |
|---|---|
| DAG | Directed Acyclic Graph — the shape every app takes; nodes run in topological order with no cycles. |
| HITL | Human-in-the-loop — a control node that halts a run for a human decision. |
| MCP | The broker layer through which the AI safely, and only in an allow-listed way, touches a system. |
| STP | Straight-through processing — a run completing with no human intervention or failure. |
| Sign-off | A cryptographic (HMAC) approval binding a named human to the exact graph they approved. |
| Governance gate | A required review (Tech Standards / Business Risk / L3 Compliance) a version must clear. |
Generated automatically by Markets OS from the governed app definition — this document reflects the live platform record at the time of generation.