Instrument Repository

Problem

A global asset manager needed every downstream system to agree on what a financial instrument is, how it behaves under corporate actions, and which states are allowed. Implementations had drifted over time, creating subtle reconciliation failures—hard to detect in operations and hard to explain to regulators when two systems disagreed on the same instrument event.

Specification & verification

We expressed instrument behaviour as a compact Spec++ specification: a few pages of rules and 26 invariants describing legal states and allowed events. Those invariants were machine-checked, not only peer-reviewed. From that specification we generated production code.

Guarantee you can take to a regulator

We can say, with proof, that certain invalid states are architecturally impossible—not merely unlikely in testing. When a supervisor asks why a corporate action did or did not flow through to trading, we can point to a formally defined rule and evidence it was enforced—e.g. Theorem 6.7: corporate actions cannot cascade to the trading layer in unapproved ways within the specified model.

How we delivered

Delivered via software engineering with Spec++ SDD—the same engagement model we offer on your highest-risk reference data or instrument workflows.

Agentic Compliance Operator

Problem

A wealth manager wanted to let AI propose account rebalancing actions while guaranteeing that no proposal could ever breach mandate or suitability rules, even if the AI was compromised or adversarially prompted.

Specification & verification

We defined a security model in which the AI is explicitly untrusted. Every state transition in the workflow is guarded by formally specified policies and zero‑knowledge proofs. The validator enforces the rules; the AI never becomes the enforcement layer.

Guarantee you can take to a regulator

The system comes with named theorems: for example, that no adversary—including a fully compromised AI—can cause a non‑compliant state transition. Each decision is accompanied by a hash‑chained, cryptographically verifiable record that can be presented in an examination.

Supplier onboarding with proof-gated governance

Problem

Large institutions want AI agents to onboard suppliers faster—screening, document checks, status updates—without trading away compliance accountability. Most agent platforms log what happened; they do not prove that each status change was evaluated against a stated policy before execution.

Specification & verification

Policy is uplifted into a Spec++ specification—versioned, machine-readable rules compliance can sign off on. At runtime, CECO evaluates each agent-proposed transition before it runs: the agent is untrusted; the validator decides; ZK proofs can show three-way match rules satisfied without disclosing supplier pricing to the agent.

Guarantee you can take to a regulator

For each onboarding decision you can produce a record showing what was decided, which rule applied, what state the system saw, any human approval, and cryptographic evidence the rule held at decision time—not a narrative rebuilt from CRM and ticket exports.

How we delivered

Delivered via the Compliance Operator (CECO) reference implementation, with policy uplifted from the client's existing onboarding rulebook into a Spec++ specification. The same engagement model is available for procurement and supplier management workflows.

OTC confirmation (look-alike screen)

Problem

This is one application of the Riley Betts Trust Fabric — portable trust, not a trading venue. OTC confirmation still sits on phone, email, chat, and each firm’s private logs. FIX carries the order. SWIFT carries the payment instruction. Neither carries a portable answer to: did both counterparties screen this trade, under stated rules, at a stated time — and agree the same terms?

Specification & verification

Two counterparty agents negotiate an OTC single-stock future. Each runs its own CECO gate against its own policy before execution. They co-sign one identical object — terms hash plus both compliance hashes — so there is no “my version vs yours.” A compact receipt (hashes, booked flag, timestamp) is then anchored on a chain neither firm owns. Ethereum stood in for Anchor. Validity stays in the off-chain certificate. The book never goes on-chain.

The hero scenario is not a fill. A buy-side restriction on an issuer also caught the look-alike future wrapper. The trade did not execute. Confirmation still recorded that both sides screened it, and that it was stopped.

Guarantee you can take to a regulator

You can point to a tamper-evident record, owned by neither firm’s IT department, that both sides screened the trade under stated rules at a stated time, and that it was stopped. The deny is a first-class shared fact. The chain attests existence and time; the certificate attests validity.

How we delivered

Delivered as a feasibility PoC — one application of the Riley Betts Trust Fabric (CECO locally; Ethereum standing in for Anchor). The fabric itself is portable trust, not an OTC product. The same engagement model is available as a scoped pilot on confirmation workflows.