Post-incident truth for trading execution systems.
When an order misbehaves, getting the honest answer takes days of engineering archaeology across scattered logs. Tusiro reads the records your firm already has and returns one evidence-backed answer: what happened, and whether your systems behaved correctly.
THE PROBLEM
An order goes wrong. The firm needs one clear story.
Today that story gets rebuilt by hand: slowly, across systems, under pressure.
A customer order
An order flows through the firm’s systems: from a customer, or from the firm’s own trading desk.
Something looks wrong
Late. Rejected. Strange price. Unexpected fill. A dispute opens, or the desk demands answers.
The hard question
What exactly happened to this order, and did the system handle it correctly?
Answering takes hours to days of senior engineering time. Logs get opened, order IDs get matched, timelines get rebuilt by hand while the customer, risk, and management all wait. Discovery interviews with brokerage engineering staff confirmed this is exactly how it works inside real firms today.
Knight Capital, 2012. A faulty deployment routed unintended orders for roughly 45 minutes while the firm struggled to see what its own systems were doing. Loss: over $460 million. Incident cost scales with the time a firm spends blind.
SEC Exchange Act Release No. 70694
PROOF
Order-record correctness is not a solved problem anywhere.
In October 2024, FINRA fined Citadel Securities $1,000,000 and IMC Financial Markets $1,200,000 for inaccurate order-event reporting to the Consolidated Audit Trail. Citadel Securities misreported roughly 42.2 billion order events over two years; IMC misreported roughly 21.8 billion across 35 distinct error types, caused by software and system issues their own tooling did not catch.
The firms with the deepest pockets and the best infrastructure teams in the industry cannot keep their own order records straight. It is an unsolved problem with fines attached.
THE ARTIFACT
The artifact: an order incident verification report.
Order received at 10:04:11 · Risk check completed
No confirmation back from the exchange · No final message sent to the customer
Internal status says “OK” · Customer-facing status says “Rejected”
Think flight recorder, not dashboard: a report the firm can put in front of a customer, a risk committee, or a regulator. Every claim is marked proven, missing, or conflicting, with the evidence behind it.
HOW IT WORKS
One report that explains what happened, and proves it.
Read records
Orders, fills, cancels, rejects, timestamps. Historical data only, from the systems the firm already runs.
Rebuild the story
What happened first, next, and last: one timeline across every system the order touched.
Check the rules
Did the system do what it should have done at each step? Every expectation is written as an explicit, testable rule.
Report the proof
Every claim in the report is marked proven, missing, or conflicting, with the evidence behind it.
AI assists evidence extraction from messy, mixed-format logs, and nowhere else. The verification core is fully deterministic and rule-based: the same records always produce the same verdict. There is no AI or LLM in the verification core or in any critical path.
A core library encoding order-lifecycle and protocol semantics, plus a firm-specific overlay configured in each pilot. The library compounds with every engagement.
Tusiro checks what already happened. No live control · no trading advice · no market prediction.
TRUST ARCHITECTURE
Customer data never needs to leave the customer.
The number one objection in this market, answered by design instead of promises.
Deploy close to the data
Tusiro runs inside the customer’s VPC, or fully on-premises when required. Nothing sensitive ever passes through a vendor cloud.
Read-only inputs
Historical records only. No live trading access. No execution control. Nothing that can break a production system.
Report-only output
The only thing that leaves is a redacted evidence report, never a raw data export. The firm controls every byte that moves.
Trading firms will not send sensitive order data to a young vendor, and they shouldn’t. Tusiro’s pilot path is designed around that reality, not against it. Prefer not to expose raw records at all? Semantic tokenization hashes order IDs, tokenizes symbols, and buckets sizes while preserving the timestamps, sequences, and state transitions that correctness rules actually check.
STATUS
What exists today, labeled honestly.
581,030
real NASDAQ order-book events processed end to end via LOBSTER, the academic order-book reconstruction from Humboldt University Berlin. Full pipeline: connector, schema validation, evaluator, evidence ledger, report.
What this proves, and what it doesn’t
Proves: the verification engine runs end to end on real market structure, on public data. Doesn’t prove: integration with messy multi-system customer records. That is exactly what pilots test.
Second source in implementation
An IBKR FX connector with frozen architecture is in implementation. This is the kind of connector work that forces hard decisions: which order IDs can be trusted, which acknowledgment counts as the real submission, and which timestamps are honest.
WHY NOW
Regulators now fine firms that cannot explain their own orders.
Citigroup fined £61.6M.
UK regulators fined Citi for weak trading-system controls after a $1.4B erroneous sell-off briefly hit European markets.
US fines: Citadel Securities & IMC.
FINRA fined two top trading firms $1M and $1.2M for inaccurate order records: bad records block reconstruction of market events.
EU DORA takes effect.
Incident reporting becomes a legal duty for ~20 categories of EU financial firms. Evidence after an incident is now required by law.
ESMA briefing on algorithmic trading.
Supervisory expectations tighten on governance, testing, and pre-trade controls, including AI used inside trading algorithms.
Regulators are no longer fining only bad trades; they are fining bad records of trades. Firms that cannot reconstruct their own order events pay for it. Tusiro is the layer that produces the proof.
NEXT STEP
Start with one incident.
Send the records around one real past incident, tokenized if you prefer, and receive the actual artifact: a verification report on your own order, your own systems, your own unresolved dispute. No imagination gap to bridge.