Praxis Prime
Tracking a 2-Million-Share Block Trade Across Execution, Risk, and
Settlement — Bound by a Single OrderID.
A hedge fund's Execution Trader uses an EMS. The CRO uses a separate risk aggregator. The Ops Analyst uses email. When the trade breaks at T+1, the back office lacks the data lineage to trace it back to the routing decision. Praxis Prime is the design hypothesis that one OrderID across Front, Middle, and Back — anchoring a shared data spine — is the binding constraint for the next generation of prime brokerage platforms.
T+1 Made the Back Office the Binding Constraint.
Most Institutional Platforms Still Optimise the Buy Button.
The defining insight: since the SEC's May 2024 mandate moving the US equity settlement cycle to T+1, the operational lifecycle — not execution speed — is what determines whether a prime broker is competitive. A trade that executes in milliseconds but breaks at settlement the next morning costs the firm CSDR penalties accumulating per minute of delay. Today, the Execution Trader, the CRO, and the Ops Analyst look at three different systems with three different data models. Praxis Prime asks: what if they all looked at the same OrderID?
A Front-to-Back prime brokerage concept unifying execution + risk + settlement under one OrderID, designed for the post-T+1 (SEC Rule 15c6-2) regime where the operational lifecycle is the binding constraint. 8 modules, 56 React components, 5,288 LOC TypeScript, FIX 4.4 + SWIFT MT54x literacy. Killer feature: FIX/SWIFT Diff Viewer for the settlement-break resolution moment.
- 8 modules across Front/Middle/Back office: Dashboard, Execution, Order Book L2, Trade Blotter, Risk, Compliance, Settlement, Position Details
- 56 React components / 5,288 LOC TypeScript / React 18 + Vite 6 + Tailwind v4 + Recharts
- Working live prototype deployed at /PraxisPrime/, OrderID-spine architecture binding execution → risk → settlement on one identifier
- Regulatory anchors named by section: SEC Rule 15c6-2 (T+1 settlement), CSDR settlement discipline, FIX 4.4 ExecutionReport state machine, SWIFT MT543 settlement-instruction standard, SEC Rule 17a-4(f) audit retention
- Not a production deployment — concept artifact, no live venue routing, no real SWIFT settlement messages sent
- Not a real T+1 affirmation-rate measurement — the 78% → 92-95% target in the Validation Roadmap is the design hypothesis, not a measured outcome
- Not a single-author code claim — the 5,288 LOC TypeScript was AI-augmented (Claude Code / Codex / Antigravity), each function reviewed and curated by Ed but not line-by-line hand-written
- Not Bloomberg-tier institutional terminal aesthetic — this is a unified F2B operational surface, distinct register from execution density
- Self-initiated concept exploration 2026, original IP, zero client overlap
- Production foundations: ACY Connect FIX 4.4 institutional API gave direct exposure to ExecutionReport state machine, prime-broker integration requirements
- FIX/SWIFT Diff Viewer (the killer feature) demonstrates protocol literacy — the tag-level diff is a real protocol pattern, the specific NVDA settlement-break example is illustrative
- Read time: ~37 min full · ~8 min if you stop after the Killer Feature section
| Method | Source / Sample | Key Insight That Shaped Design |
|---|---|---|
| Production Experience | ACY Connect institutional API platform — FIX 4.4 ExecutionReport state machines, prime-broker integration patterns, JSON envelope translations for institutional clients. Multi-year production exposure (ACY Securities, 2021–2025). | FIX is not a "data format" — it is a state machine. Tag 39 OrdStatus transitions (0 New → 1 Partially Filled → 2 Filled → 4 Canceled → 8 Rejected) drive what the trader can do next. Any UI that flattens this into a status badge throws away the operational signal. |
| Regulatory Review | SEC Rule 15c6-2 (T+1 settlement, effective 28 May 2024 — final adopting release 17 CFR § 240.15c6-2); CSDR settlement-discipline penalties (EU Regulation 909/2014, Article 7); DTCC T+1 operational playbook; FINRA Rule 11860 affirmation/disaffirmation guidance. | T+1 compresses the affirmation window from end-of-day on T+1 to 9:00 PM ET on T. That means by 21:00 ET on trade day, every allocation must be matched, every SSI confirmed, every break flagged. The Back Office is no longer a 24-hour buffer — it is a 6-hour critical path. |
| Protocol Specification Read | FIX 4.4 specification (Tag 35=8 ExecutionReport, Tag 150 ExecType, Tag 39 OrdStatus, Tag 14 CumQty, Tag 31 LastPx); SWIFT MT54x category-5 standards (MT540 Receive Free, MT541 Receive Against Payment, MT542 Deliver Free, MT543 Deliver Against Payment); ISO 20022 sese.023 / sese.024 settlement-instruction equivalents. | FIX and SWIFT speak different languages for the same trade. A FIX Tag 6 AvgPx field has no clean equivalent in MT543 — MT543 carries a SettlementAmount that depends on accrued interest, fees, and FX. Reconciliation is a translation problem, not a comparison problem. The UI must show both messages side-by-side, not just a diff. |
| Operational Domain Mapping | Public DTCC affirmation-by-9pm research, ISDA T+1 readiness reports, SIFMA buy-side operational surveys (2023–2024 published cohorts). | The Ops Analyst is the lowest-status, highest-leverage seat on the trade floor. Under T+1, one Ops Analyst can stop the trade from settling — or save it. The platform should make that seat feel like an institutional trader's seat, not a clerical one. Keyboard-first triage, escalation paths, full data lineage on every screen. |
| Design Hypothesis | Derived from all above; not validated in production. Working React/TypeScript prototype (5,288 LOC, 56 components) used as a thinking tool, not an A/B test. | The highest-leverage design intervention is the FIX/SWIFT Diff Viewer — a single screen that collapses a 4-hour email cycle (Ops Analyst → Counterparty Ops → reconciliation team → custodian → resubmit) into a 30-second UI-driven resolution. If this primitive works, every other module benefits from the shared OrderID spine underneath it. |
Three Roles. One OrderID Spine.
Institutional trading is a relay race. The Execution Trader hands the trade to the CRO who hands it to the Ops Analyst. Each role has a fundamentally different time horizon, decision authority, and information appetite. Praxis Prime gives each role a purpose-built workspace while binding them to the same OrderID — because an Execution Trader's routing decision becomes a CRO's margin consumption becomes an Ops Analyst's settlement break.
Execution Trader
- Slice a 2,000,000-share block into VWAP / TWAP / POV algos without leaking signal
- Route to the best venue mix (lit / dark / mid-point) under live spread conditions
- Monitor real-time fill quality vs benchmark and intervene if slippage breaches threshold
- Hand the trade to the back office with a clean FIX 4.4 audit trail
Chief Risk Officer
- Maintain cross-margin discipline across positions in real time
- Run stress scenarios (vol +200bps · liquidity halving · correlation breakdown)
- Monitor concentration heatmap by issuer, sector, geography
- Set risk gates that auto-throttle the Front Office before they breach limit
Operations Analyst
- Affirm allocations and SSIs by 9:00 PM ET on trade day (SEC 15c6-2 / DTCC affirmation cut-off)
- Resolve FIX-vs-SWIFT field mismatches before settlement window closes
- Triage exceptions by CSDR penalty exposure, not arrival time
- Escalate to counterparty Ops with the exact mismatched field, not a vague "trade broke"
Three Problems Worth Solving
The Three-System Problem
The Execution Trader sees the order in an EMS. The CRO sees an aggregated risk number
in a separate dashboard. The Ops Analyst sees an email confirmation from the counterparty.
Three views of the same trade, three different data models, no shared spine. When a break
surfaces at settlement, no one has the lineage to trace it back to the routing decision.
The answer is a shared OrderID that travels with the trade across every screen — the SOR
fill carries it forward into the margin calculation, the margin calculation carries it
forward into the settlement instruction, and the settlement instruction carries it forward
into the exception triage queue. One ID, three workspaces, full lineage.
FIX vs SWIFT — Translation, Not Comparison
A FIX 4.4 ExecutionReport carries Tag 6 AvgPx, Tag 14 CumQty, Tag 17 ExecID. A SWIFT MT543
instruction carries SettlementAmount, NominalQuantity, and SETR (settlement transaction
type code). The fields look similar but encode different things: AvgPx is in execution
currency; SettlementAmount is in settlement currency with accrued interest and fees
applied. A naive diff would flag every trade as broken.
The challenge: how do you design a diff viewer that knows which fields are equivalent,
which need translation (currency, accrued, fees), and which represent genuine breaks?
The answer is field-level mapping with explicit "this is the translation, here's where it
doesn't match" annotations — not a string-by-string diff.
The 6-Hour Critical Path
Under T+1, the firm has from execution (often 09:30 ET) to 21:00 ET on trade day to
affirm. That is a 6-hour critical path — and most of it is consumed by counterparty
round-trips. If a break surfaces at 18:00 ET, the Ops Analyst has 3 hours, and the
counterparty's Ops desk in Asia or Europe is closed.
The challenge: how do you design an exception queue that ranks by penalty exposure, not
arrival time? The answer is CSDR-weighted triage — a $50M trade with a $4,000/hour
penalty surfaces above a $2M trade with a $300/hour penalty. The Ops Analyst's attention
goes where the regulatory cost is highest.
Retail Trading and Institutional Prime Brokerage Solve Opposite Problems.
The Patterns Don't Transfer Cleanly.
My production experience spans both retail trading (Finlogix, LogixTrader) and institutional infrastructure (ACY Connect FIX 4.4). Before designing Praxis Prime, I had to explicitly map where retail patterns apply — and where they would actively harm the institutional workflow.
| Dimension | Retail Trading Platform | Institutional Prime Brokerage (Praxis Prime) |
|---|---|---|
| Primary user | Individual trader, self-directed, 1 account | Buy-side firm, multi-seat, multi-account, multi-strategy |
| Order size | $100 – $50,000 per order | $1M – $500M per parent order, sliced into 100–500 child orders |
| Data primitive | Price & quantity | FIX 4.4 ExecutionReport with 30+ tags carrying state machine context |
| Time horizon | Milliseconds to days | Milliseconds (Front) → Hours (Middle) → Days (Back, T+1 binding) |
| "Done" condition | Order filled — green check, P&L updates | FIX confirmation + SWIFT MT54x match + counterparty affirmation + DTCC settlement |
| Failure mode | Rejected order — retry or cancel | Settlement break — CSDR penalty accrues per minute of delay until resolved |
| UI density | One ticker, one chart, large numbers | 30+ concurrent metrics per role, dense tables, keyboard navigation |
| What transfers | Information hierarchy under time pressure, real-time data architecture, FIX state machine literacy from ACY Connect | |
What transfers from production trading work: data-density tolerance, real-time architecture, FIX 4.4 protocol literacy from ACY Connect institutional API exposure. What doesn't transfer: the assumption that the lifecycle ends at "fill confirmed", or that one user is the entire audience. Institutional prime brokerage is a multi-seat relay race where the slowest seat (Ops Analyst, under T+1) determines whether the firm makes money or pays a penalty.
Three Office Layers. Eight Modules. One Spine.
Praxis Prime is structured as three office layers (Front · Middle · Back) spanning eight modules, all bound by a shared OrderID that flows from the Smart Order Router through margin consumption into the settlement instruction. The Front Office handles execution. The Middle Office handles risk. The Back Office handles settlement and exception resolution. Each layer has its own data appetite — but every screen can resolve any trade by OrderID.
Front Office — Execution
3 modules: Execution · Order Book · Trade Blotter. Smart Order Router visualisation across lit and dark venues. VWAP / TWAP / POV algo slicing for institutional block orders. Live TCA against arrival price, VWAP, and implementation shortfall. FIX 4.4 ExecutionReport blotter with state-machine-aware status badges. Level 2 order book with depth-of-market visualisation grounded in ACY Connect's institutional API exposure.
Middle Office — Risk
2 modules: Risk · Compliance. Cross-margin bar showing live margin utilisation across the book. Concentration heatmap by issuer, sector, geography. Stress-Test Slider that lets the CRO drag a vol-shock / liquidity-halving / correlation-breakdown scenario and watch the entire book reprice in real time. Pre-trade compliance gates (FINRA 2111 suitability, Reg SHO short-sale locate, OFAC sanctions screen) wired to auto-throttle the Front Office.
Back Office — Settlement
3 modules: Settlement · Position Details · FIX-SWIFT Diff Viewer. T+1 affirmation pipeline tracking every allocation against the 21:00 ET DTCC cut-off. Exception queue triaged by CSDR penalty exposure, not arrival time. Position Details with full settlement lineage back to the original parent OrderID. And the killer feature — the FIX/SWIFT Diff Viewer that resolves protocol-mismatch breaks in a 30-second UI cycle instead of a 4-hour email cycle.
The spine in one sentence: the FIX 4.4 Tag 11 ClOrdID assigned when the Execution Trader fires the parent order is the same identifier the Ops Analyst sees in SWIFT :20C: SEME 6 hours later. Every module (8 of them, across 3 office layers) resolves by that one ID — which is why a click on the OrderID in any screen pivots into any other screen with full context preserved.
Explore the Praxis Prime App
All eight modules are wired and navigable. Built in React 18 with Vite 6, Tailwind v4, Recharts, and Radix UI / shadcn — 56 components across 5,288 lines of TypeScript. Open the prototype to walk the OrderID lifecycle from Smart Order Router execution through cross-margin risk through T+1 settlement and FIX/SWIFT diff resolution.
The Unified Floor — One OrderID, Three Office Layers, Visible in 5 Seconds.
The Dashboard is the relay-race finish line. At a glance: the 2,000,000-share parent OrderID with its current fill state, the live margin utilisation bar (Middle Office), the T+1 settlement pipeline (Back Office), and the exception queue ranked by CSDR penalty exposure. The design principle: any seat on the floor — Trader, CRO, Ops Analyst — should be able to walk up to this screen and know the state of the trade within 5 seconds.
Dashboard — Front-to-Back Overview with OrderID-Anchored Lineage
Parent OrderID as First-Class Citizen
The OrderID is not a footnote — it is the header. Every metric on this screen resolves back to one parent order. Click the OrderID and you can pivot into any module (Execution, Risk, Settlement) with full context preserved. This is the shared data spine that fixes the three-system problem.
Live Fill State With Algo Provenance
1,432,000 / 2,000,000 shares filled (71.6%), VWAP +2.3bp vs arrival, current strategy VWAP-aggressive. The trader sees not just "how much is done" but "is the algo doing its job" — TCA vs benchmark in real time, with intervention controls one keystroke away.
Cross-Margin Utilisation Bar
67% margin utilised, $34M headroom against the firm-level limit. This is the CRO's first-look signal — green means breathe, amber means watch the next 200,000 shares of the algo, red means call the trader. The bar updates per fill, not per minute.
T+1 Affirmation Countdown
9:00 PM ET DTCC affirmation cut-off, currently 14h 32m remaining, 8 allocations pending counterparty match. This is the Ops Analyst's first-look signal — and it's on the same screen as the trader's algo telemetry. Lineage made visible.
2,000,000 Shares Without Leaking Signal — VWAP, TWAP, POV, and a Smart Order Router.
The Execution module is the Front Office cockpit. The trader slices a 2,000,000-share parent order into algorithmic children — VWAP for arrival-price benchmarks, TWAP for time-neutral distribution, POV for participation-rate constraints. The Smart Order Router visualisation shows which venues are receiving which slices in real time. The live TCA dashboard tracks fill quality against arrival, VWAP, and implementation shortfall benchmarks. The design move: make the algo a co-pilot the trader can argue with, not a black box they have to trust.
Execution — Smart Order Router with Algo Slicing and Live TCA
What the trader sees: the parent order's three child algos consume different venue mixes, and the live TCA bar measures fill quality against three benchmarks (arrival, VWAP, implementation shortfall) simultaneously. The dark-pool allocation is highlighted because it has produced tighter spreads than the lit market — the trader can see the proof and the algo gets to keep routing there.
SOR Venue Allocation, Visualised
The Smart Order Router doesn't hide the routing logic — it shows the active venue mix (lit / dark / mid-point) and the basis-point cost differential each is generating. When dark-pool fills are tighter than the lit, the trader sees the proof and the algo gets to keep routing there.
Algo Selector — VWAP / TWAP / POV
VWAP-aggressive for liquid names, TWAP for time-neutral patient strategies, POV for staying under a participation cap. The trader can switch mid-flight; the algo state machine handles graceful handover and keeps the FIX 4.4 ExecutionReport trail clean.
Live TCA Against Three Benchmarks
Arrival price, VWAP, implementation shortfall — all updated per fill. The trader sees not just "what did I get" but "what would I have got with a different algo" — a counterfactual that turns post-trade analysis into a live-trade signal.
Abort & Re-Route, One Keystroke
If slippage breaches the trader's threshold mid-flight, "Abort & Re-Route" pauses the algo, returns the unfilled portion to the staging book, and offers three alternative strategies. The trader's intervention is one keystroke, not a phone call to the algo desk.
Level 2 Microstructure — Reading the Tape, Not Just the Price.
The Order Book module surfaces Level 2 depth-of-market across the venue stack — bid and ask ladders, queue position, time-priority indicators, and aggressor-side highlights. Grounded in FIX 4.4 market-data primitives from ACY Connect's institutional API exposure. The trader uses this to confirm liquidity is real before unleashing the next 200,000 shares of the VWAP algo into the market.
Order Book — Level 2 Depth with Queue Position and Aggressor Highlights
Bid/Ask Ladder With Queue Position
The trader sees not just the size at each price level but where their child orders sit in the queue. When the firm is 4th in line at the bid with 200 shares, that is a different signal than 1st in line with 50,000.
Aggressor-Side Highlight
Trades that lift the offer are coloured green; trades that hit the bid are red. A flurry of green trades just before the algo's next slice means liquidity demand is high — adjust participation rate downward to avoid pushing the print.
Microsecond Time-Priority Indicators
For dark and mid-point venues, time-priority matters more than price — first in, first out. The indicator shows the firm's child orders' microsecond timestamps relative to peer orders at the same price level.
Venue Stack Toggles
NYSE, NASDAQ, ARCA, BATS, dark pools — each venue can be toggled on or off in the book view to isolate where the next slice should land. The trader builds the venue picture before committing the next child order.
A FIX-Aware Blotter. Status Is a State Machine, Not a Badge.
The Trade Blotter is the canonical record of every execution under the parent OrderID — and it is built around the FIX 4.4 state machine, not a flat status field. Each row carries Tag 35=8 ExecutionReport, Tag 150 ExecType, Tag 39 OrdStatus, Tag 14 CumQty, Tag 31 LastPx. Filterable by venue, algo, status, and CSDR penalty exposure. This is the bridge screen — the Execution Trader writes here, the CRO reads it for margin impact, the Ops Analyst reads it to populate the settlement instruction.
Trade Blotter — FIX 4.4 ExecutionReport-Aware Rows With State-Machine Status
Tag 39 OrdStatus, Surfaced
Status badges are state-machine transitions: 0 New → 1 Partially Filled → 2 Filled → 4 Canceled → 8 Rejected. Hovering the badge shows the transition history. This is what the FIX spec actually carries — not "open / closed".
Tag 150 ExecType — Independent From OrdStatus
ExecType (F=Trade, 5=Replace, 4=Canceled, 8=Rejected, H=Trade Cancel) tells the ops desk what kind of message just landed. A single order can throw a Trade, then a Replace, then a Trade Cancel — three ExecTypes, two OrdStatus transitions. The blotter surfaces both columns side-by-side.
CSDR Penalty Exposure Column
Every row carries a forward-looking CSDR penalty estimate — if this trade fails to settle on T+1, what is the per-day cost? Sortable column. This is the bridge from the Trader's "did it fill?" mindset to the Ops Analyst's "will it settle?" mindset.
One-Click Pivot to Settlement
Click any row → opens the Settlement module pre-filtered to that OrderID with the allocation pipeline, the SSI status, and the FIX-vs-SWIFT match state already resolved. The Trader and the Ops Analyst share the same row, with different next-screen affordances.
The Trade Blotter is the hinge of the case study. The Execution Trader writes here; the CRO reads it for margin impact; the Ops Analyst reads it to populate the settlement instruction. One row. Three audiences. The OrderID is what binds them.
Cross-Margin in Real Time — The CRO's Stress-Test Slider.
The Risk module is the CRO's cockpit. The cross-margin bar shows live utilisation across the firm's book — 67% used, $34M headroom against firm limit. The concentration heatmap ranks exposures by issuer, sector, and geography. The signature feature is the Stress-Test Slider — drag a vol-shock, liquidity-halving, or correlation-breakdown scenario and watch the entire book reprice. The CRO can ask "what if vol doubles?" and have the answer in 800ms, not 8 hours.
Risk — Cross-Margin Bar, Concentration Heatmap, Stress-Test Slider
Stress-Test Slider — Drag, See, Decide
Vol shock from 0 to +400bp. Liquidity halving from 1× to 0.25×. Correlation breakdown from baseline to perfect-correlation regime. The slider re-prices the entire book on drag — the CRO sees not a static report but a live scenario.
Concentration Heatmap by Issuer/Sector/Geography
The 12-tile heatmap surfaces the firm's exposure concentration — top 5 issuers consuming 38% of margin, top 3 sectors at 52%, US-listed names at 71%. The CRO sees where the firm is over-exposed before the next algo slice lands.
Cross-Margin Bar With Headroom Display
67% utilised. $34M headroom against firm-level limit. The bar updates per fill, with a forward-looking projection showing where utilisation will be when the current VWAP algo completes its remaining 568,000 shares.
Auto-Throttle Gate to Front Office
If the stress-test slider shows utilisation exceeding 85% under a defined scenario, the CRO can set an auto-throttle that pauses the Front Office algo before it breaches. The gate fires before the limit, not after — a soft brake, not a circuit-breaker.
Stress Test 01 — Baseline Scenario (Current Vol & Liquidity)
Stress Test 02 — Vol Shock +200bp Repricing the Book
Stress Test 03 — Liquidity Halving (Top-of-Book Depth ×0.5)
Stress Test 04 — Correlation Breakdown (Sector De-Correlation Regime)
Pre-Trade Compliance — The Algo Talks to FINRA Before the Trader Does.
The Compliance module wires three pre-trade gates directly into the SOR routing path: FINRA 2111 suitability (does the order match the client's risk profile?), Reg SHO short-sale locate (do we have a borrow before we sell short?), and OFAC sanctions screen (is the counterparty on a sanctioned list?). When any gate fails, the algo pauses, the trader is shown the exact failed check, and the path to remediation is one click.
Compliance — Pre-Trade Gates (FINRA 2111 · Reg SHO · OFAC) Wired Into SOR
FINRA 2111 Suitability Gate
The order is checked against the client's risk profile, investment objective, and concentration limits before the SOR routes the first child. Failures surface a specific 2111 paragraph reference — "Customer-Specific Suitability, 2111(b)" — so the trader knows which document to consult.
Reg SHO Short-Sale Locate
Before any short-sale child order is routed, the locate panel confirms the borrow. Hard-to-borrow names surface the borrow rate, lender, and locate-document reference. Naked-short attempts are blocked at the gate, not flagged after the fact.
OFAC Sanctions Screen
Counterparty entity, beneficial owner, and counterparty's bank are all screened against current OFAC sanctioned-entity lists. The screen runs in milliseconds and returns a green/amber/red signal with the matched list reference if a hit fires.
Audit Trail of Every Gate Outcome
Every pre-trade check is logged with timestamp, input data, gate version, and outcome — feeding the firm's SEC Rule 17a-4 record-keeping obligation. Auditors can replay any trade's compliance state at the moment of routing.
The 4-Hour Email Cycle Collapses to 30 Seconds.
The FIX/SWIFT Diff Viewer is the Signature Move.
This is the signature feature of Praxis Prime — the one a senior product designer at a top-tier prime brokerage would recognise as institutional-protocol literacy of a kind most fintech designers don't know exists. When a trade breaks at T+1, the FIX 4.4 ExecutionReport from the firm's OMS and the SWIFT MT54x settlement instruction from the counterparty disagree about a single field. Today, resolution takes 4 hours of email ping-pong. The FIX/SWIFT Diff Viewer turns that into a 30-second UI cycle.
The math under the headline: T+1 compresses affirmation from 24 hours to 6 hours. A break surfacing at 18:00 ET leaves 3 hours under the old workflow (email cycle, counterparty Ops desks in Asia/Europe closed) — and would miss the 21:00 ET DTCC cut-off. With the Diff Viewer collapsing that cycle to 30 seconds, the break is resolved by 19:30 ET and the trade affirms with 90 minutes of headroom. DTCC industry-average affirmation rate today is ~78%; the design hypothesis is 92–95% with this primitive in place.
Settlement — FIX/SWIFT Diff Viewer Resolving a Single-Field Break in One Screen
What the diff viewer surfaces: FIX Tag 1 Account "CITADEL-FUND-A-NEMESIS" vs SWIFT :97A: SAFE "CITADEL-FUND-A-NEM3SIS" — a one-character typo (E→3) that would fail the settlement match. The viewer auto-detects the Levenshtein distance, surfaces the suggested correction, and routes the resolution to the counterparty Ops desk with one click — pre-populated with both messages attached. The current CSDR penalty exposure ($4,320/day) is shown in the resolution bar so the Ops Analyst knows the cost of delay.
Field-Level Mapping, Not String Diff
FIX Tag 1 Account maps to SWIFT :97A: SAFE. FIX Tag 6 AvgPx maps to SWIFT :90B: DEAL PRICE. FIX Tag 14 CumQty maps to SWIFT :36B: SETT QTY. The viewer knows the protocol mappings — it doesn't diff raw text, it diffs equivalent fields.
CSDR Penalty Exposure in the Header
Every break shows the current daily penalty under CSDR Article 7 — $4,320/day for the example trade above. As the affirmation cut-off approaches, this number colours from amber to red. The Ops Analyst sees the cost of delay, not just the existence of a break.
One-Click Escalation Email
When the Ops Analyst can't resolve in-screen, the "Escalate to counterparty" button generates a pre-populated email with both messages attached, the mismatched field circled, and the suggested correction inline. The counterparty Ops desk replies with a single yes/no.
Full Resolution Audit Trail
Every break, every escalation, every resolution is logged with the FIX and SWIFT payloads, the operator's action, and the timestamp — feeding the firm's CSDR evidence of "best efforts" should the regulator come asking why a settlement missed the affirmation window.
The Forensic View — Settlement Lineage Back to the First Child Order.
Position Details is the forensic view of any settled trade. The screen shows the full lineage of the position — every child order, every fill, every venue, every counterparty, every settlement instruction, every confirmation. Click any element in the timeline and it pivots into the originating screen. This is the audit-defensible record that survives a SEC Rule 17a-4 inspection seven years from now.
Position Details — Full Settlement Lineage From Parent Order to Final DTC Settlement
Parent → Child → Fill Lineage
The OrderID tree unfolds in time-ordered nesting: parent order → algo slices → child orders → individual fills. Each node shows venue, price, quantity, FIX Tag 17 ExecID, and counterparty. Click any node to pivot into the originating screen with full context preserved.
Settlement Instruction Chain
Every fill produced a SWIFT MT54x settlement instruction. The chain shows the MT543 message, the counterparty's affirmation timestamp, the DTC settlement confirmation, and the cash leg's MT202 if cross-currency. Auditors can replay the entire trade lifecycle.
Counterparty & Custodian Surfaces
The position details panel surfaces the prime broker, executing broker, clearing broker, custodian, and any sub-custodian relationships — with their SSI references and contact-of-record on each leg. This is what the Operations Manager calls when a break is escalated.
SEC Rule 17a-4 Audit Surface
Every event in the lineage is timestamped to the millisecond and hash-sealed. The 7-year retention required by 17a-4(f) is built into the data model, not bolted on. Auditors get a single export covering execution, risk gates, settlement, and resolution.
Institutional, Not Consumer — Restraint as the Design Discipline.
The visual system inherits from the Edwson Design System and adapts to institutional density. Colour discipline is monochrome with a single accent (gold leaf) used sparingly to mark state-machine transitions and critical-path elements. Type is Cormorant Garamond for display, Inter for UI body, JetBrains Mono for FIX tags and SWIFT field references — the monospaced numerals matter because they sit in tables read at a glance.
30+ Concurrent Metrics, No Cognitive Overload
The Dashboard surfaces 30+ live metrics on one screen. The discipline is not "show fewer" but "rank by user role and time pressure" — the trader's metrics on the left, the CRO's in the middle, the Ops Analyst's on the right. Tab order and keyboard navigation are designed around the role's primary scan path, not the layout grid.
Monochrome With One Accent
Bone-white surface, near-black ink, single gold accent for state transitions. Red for breaks, amber for approaching limits, green for clean — but only at the moment of state change. A screen at rest is monochrome; only the live edge of the data stream uses colour.
Monospaced Numerals in Every Table
JetBrains Mono for FIX tags, SWIFT field references, ExecIDs, OrderIDs, and any number that sits in a column. The trader's eye scans down a column expecting alignment — proportional numerals defeat the scan. The discipline is unglamorous but it is what makes the platform feel institutional.
What I'd Test If I Took This to Production.
Praxis Prime is a concept — explicitly not shipped, not A/B-tested, not validated by paying customers. The honesty discipline here is to name what I'd test, in what order, and with what evidentiary bar. Anything I cannot measure in 6 months of production rollout I should not claim as proof.
Affirmation Rate Before 9PM ET
Today's industry average is ~78% affirmation by the DTCC 9PM cut-off (DTCC published statistics, 2024). My design hypothesis is that the FIX/SWIFT Diff Viewer + the CSDR-weighted exception queue could push this to 92–95% for buy-side firms using the platform. I'd measure trade-level affirmation timestamps for 90 days, controlled for trade volume and counterparty mix.
Break-Resolution Cycle Time
The 4-hour → 30-second compression is the headline claim. I'd measure resolution latency from break detection to counterparty affirmation reply, with the existing email cycle as the control arm and the Diff Viewer as the treatment. Significant improvement only counts if it's reproduced across multiple counterparties.
Penalty Exposure Reduction
CSDR Article 7 settlement-discipline penalties are public-facing — the firm's aggregate penalty exposure can be measured as a baseline and tracked over 12 months of platform deployment. My hypothesis: 60–75% reduction in cumulative penalty exposure, driven by the queue ranking by penalty cost and the Diff Viewer resolving the long-tail breaks.
Where Praxis Prime Sits in the Portfolio.
Praxis Prime is the seventh concept application in the Edwson Design System portfolio, and the third institutional-tier case study alongside TradeX Institutional Terminal and TradeX Hedge Fund. Together they map the three cognitive layers of institutional finance work.
TradeX Hedge Fund
- 11 canonical screens for the PM workflow
- 3 cognitive states framework (calm · alert · crisis)
- 4 AI autonomy tiers for proactive suggestion governance
- 5-screen KYC for institutional fund onboarding
TradeX Institutional Terminal
- 960-data-point Portfolio Risk Matrix
- Level 2 Order Book with depth-of-market
- Multi-chart orchestration with Fibonacci/Gann overlays
- Pre-trade compliance overlay (SEC 17a-4 / FINRA 2111)
Praxis Prime (This Case Study)
- 8 modules across Front, Middle, and Back office
- Shared OrderID spine binding all three office layers
- FIX 4.4 ExecutionReport state machine awareness throughout
- FIX/SWIFT Diff Viewer — the signature institutional-protocol feature
For a Senior PD or Design Lead interview panel.
This concept evidences institutional Front-to-Back operational thinking under the T+1 regime: 8 modules + 56 React components + 5,288 LOC working prototype, OrderID-spine architecture binding execution + risk + settlement on one identifier, FIX 4.4 + SWIFT MT54x protocol literacy visible in the Diff Viewer killer feature. Regulatory anchors named by section: SEC Rule 15c6-2, CSDR settlement discipline, FIX ExecutionReport state machine, SEC Rule 17a-4(f). Production foundations (ACY Connect FIX 4.4 institutional API) ground the protocol literacy; the F2B unification is the explicit concept extension.
What this case study deliberately does not claim. No certified WCAG 2.1 AA conformance — full disclosure with 12 contrast pairs measured + six limits at the accessibility audit disclosure. No real T+1 affirmation-rate measurement — the 78% → 92-95% target is the design hypothesis pattern; the parallel methodology rigor for any future measured claim would follow the Finlogix methodology disclosure (pre-registration, named limits, replication directions). No 18-month post-launch iteration arc — because no launch — but the parallel for a hypothetical production deployment would follow the ACY RG 268 iteration note (v1 failure modes acknowledged, honest negative results reported). No enterprise-IT political-skill arc inside a real prime broker — the institutional adoption pattern for F2B platforms follows the ACY Connect political-skill note (verification surface as adoption mechanism; the Diff Viewer is the verification-surface equivalent in this concept).
The disclosure register. The four 2026-05-18 field notes are the canonical voice this concept inherits from. The 5,288-LOC TypeScript figure is real, but the AI-augmentation disclosure is necessary: each function passed through Ed’s review and curation, the architecture decisions are his, but the code itself was produced with Claude Code / Codex / Antigravity AI collaboration — senior-PD honesty means saying so explicitly.
- Finlogix Cohen’s d = 2.47 disclosure
- n = 15 paired within-subjects design
- Seven limits named
- Eight-direction replication plan
- RG 268 disclosure surface, 18 months
- v1 modal → v2 strip → v3 inline
- Muscle-memory dismissal failure named
- Honest negative result on AUM lift
- 12 token contrast pairs measured
- ARIA + keyboard patterns documented
- Six limits named
- Six-component replication plan with cost estimates
- ACY Connect, 12 institutional clients
- One IT director who didn’t want to migrate
- Three credible objections named
- Three verification surfaces that earned adoption
Portfolio thread
Where Praxis Prime sits in the larger web
Praxis Prime sits at the intersection of three portfolio threads — the operational-lifecycle layer that completes the institutional triple alongside execution and PM cognition.
Thread
Institutional Front-to-Back Operations
Three sister case studies cover three cognitive layers — PM, execution, operations — bound by the OrderID spine.
- Praxis Prime — F2B Prime Brokerage Operational-lifecycle layer · 8 modules · OrderID-spine across Front · Middle · Back Concept · 5,288 LOC · FIX/SWIFT Diff Viewer killer feature
- TradeX — Institutional Terminal Execution-and-microstructure layer · Level 2 order book · pre-trade compliance overlays Concept · FIX 4.4 · SEC 17a-4 audit · FINRA 2111 suitability
- TradeX — Hedge Fund Dashboard PM-cognition layer above execution · 11 screens · 3 cognitive states · AI autonomy tiers Concept · buy-side · primary research with $100M–$50B AUM PMs
Thread
FIX 4.4 / SWIFT Protocol Literacy
Direct production exposure to FIX ExecutionReport state machines and SWIFT MT54x settlement instructions.
- FIX/SWIFT Diff Viewer signature feature Split-screen field-level diff resolving settlement breaks in 30 sec instead of a 4-hour email cycle Concept · FIX 4.4 Tag 35=8 · SWIFT MT543 · CSDR penalty-aware
- ACY Connect — Institutional FIX API Production source for the FIX 4.4 literacy — B2B layer serving 12+ prime-broker clients Shipped · 5-user taxonomy · FIX 4.4 ExecutionReport state machine
- The Terminal Model Documents how the FIX protocol literacy gets distilled into UI patterns via the AI cowork chain Methodology · 5 demos · Demo 02 maps OpenStock retail → institutional
Thread
Regulatory Routing · T+1, CSDR, SEC 17a-4
Settlement-discipline regulations driving the UI grammar — CSDR penalty fields, T+1 affirmation countdowns, 17a-4 retention hooks.
- Praxis Prime regulatory anchoring SEC Rule 15c6-2 T+1 affirmation · CSDR Article 7 penalty UI · DTCC 9:00 PM ET cut-off · SEC 17a-4 retention Concept · 4 named regulations mapped per module
- ACY Securities Ecosystem Production reference — 8 regulatory rewrites absorbed without structural rework over 4 years Shipped · 40+ jurisdictions · 150-component design system
- Double-Blind Fiduciary Protocol SHA-256 commit + reveal pattern · applicable to FIX-SWIFT Diff Viewer resolution audit trail Concept · SR 11-7 model risk · SEC 17a-4(f) 7-year retention