Ellipe 3 — Verifiable Control Execution

“How do you know a control actually ran when you’re the one held responsible?”

Your partner says the reconciliation ran. Your examiner asks you to show it. Between those two sentences sits a screenshot, a spreadsheet and somebody’s word — all produced by the party being examined, after the question was asked. Every section below is an answer to that one question, and the answer is a file you can check yourself.

Get in touch

01
The problem

You carry the liability. They run the systems.

You signed for a control you cannot watch execute. Someone else runs it, on data you will never hold, inside systems your auditors will never log into — and when the examiner arrives, the question lands on your desk, not theirs.

Three things are true at once, and all three hold wherever this problem is worth solving. You cannot inspect their systems. They cannot hand you the data — it is sensitive, or too large, and receiving it would make the exposure yours. And you cannot simply take their word for it, because their word is precisely what is in question.

This is not a diligence failure, and it is not a trust problem between decent people. Everyone in the chain is acting in good faith with the tools available. There is simply no mechanism — so the gap gets papered over with attestations, and everybody signs, and everybody hopes.

And when hoping fails, the name on the order is yours.


02
The stakes

The order has the bank’s name on it

Blue Ridge, January 2024. Evolve, June 2024. Axiom, October 2024. In each case the failure ran through a partner program and the named party was the chartered bank. Blue Ridge then needed regulatory non-objection before onboarding anyone new, and offboarded more than a dozen existing partners to get out from under it.

Regulators have been explicit that banks can no longer rely on partner representations. Which leaves you holding a duty you have no instrument to discharge — and paying for the attempt twice over: once in the compliance function, and again in the hours it takes off the people who should be running the business.

120+

US banking enforcement actions, fines and suits in 2024 — the OCC’s 36 formal actions more than tripled its 2023 count.

42%

Of C-suite time — and 43% of board time — spent on regulatory and supervisory compliance, per the Bank Policy Institute.

+61%

Growth in employee hours spent complying and responding to examiner mandates over the decade to 2023.

$61B

Annual financial-crime compliance spend across the US and Canada; costs rose for 99% of institutions surveyed.

Sources: American Banker / OCC enforcement counts (2024); Bank Policy Institute (2023); LexisNexis Risk Solutions True Cost of Financial Crime Compliance, US & Canada. Figures are industry-wide context, not a projection for your institution.

The spend is not the scandal. The scandal is that it buys you a sample.


03
Why nothing
covers it

Six categories, six blind spots

Audit logsSilent about what was never recorded
Lineage toolsBuilt for reliability, not examination
GRC platformsDocumented intent, not execution
Third-party auditSampling; costly; point in time
Attestation / TEEsSilent on what data was fed in
LedgersRequire the activity to move on-chain

They also share one blind spot — and it is where the real failures happen.


04
The blind spot

Controls rarely fail. Populations do.

Enforcement actions overwhelmingly turn on records that never reached the control at all. Your partner is not lying to you; their control ran correctly — on the wrong population, with nothing in the chain capable of noticing. Sampling cannot catch it either: a sample drawn from the included population will never reveal the segment that was excluded before the control began.

Unwired

A product line never joined to the feed.

Parallel ledger

A partner channel nobody wired in.

Migration gap

A silently dropped date range.

Bad predicate

A status code whose meaning changed.

Late arrivals

Corrections that land after the window closed.

So any honest answer has to establish four things at once. Here they are.


05
The bar

Four claims, or it proves nothing

1

Identity

Which control ran — the exact procedure in canonical form, not a name in a memo.

2

Population

Over what, completely. The hardest of the four and the one nothing else serves.

3

Execution

Faithfully, as specified — one published runtime, one digest, one thing to audit.

4

Attribution

On whose authority — a governance signature, in-period, on the plan that ran.

Four steps establish all four of them, and they run in this order.


06
The mechanism

Four steps, one file at the end

STEP 01

The control is written down

A plain declarative plan a compliance officer can read — and a governance authority signs it. Claim 1 and 4.

plan_hash

STEP 02

The population is drawn and committed

A signed extraction states the rule, the time boundaries and the totals. Anything left out is counted and attributed to an approved reason. Claim 2 — the blind spot, closed.

dataset_root

STEP 03

One fixed runtime executes it

Every control runs inside the same published program, so there is one thing to audit — forever. The plan is data flowing through it, never a new program per control. Claim 3.

runtime_digest

STEP 04

The Evidence Packet is signed and handed over

The recipient runs a standalone verifier against it. No credentials, no network, no call to us. All four, in one file.

verdict

That file is the entire product. This is what one looks like.


07
The output

One file. Eight checks. No phone call.

Assurance that requires calling the vendor is not assurance — it is a service agreement. So the whole check list is public, and it is short enough to read here.

01The runtime digest matches the published build.
05The population commitment matches the extraction.
02The proof verifies against the verification key.
06Exclusions are attributed to an approved rule.
03The plan hash matches the readable plan.
07Findings match the proof's public outputs.
04The governance signature is valid and in-period.
08Every signature chain is valid.
Evidence PacketFBO RECON · 2026-07
plan_hasha41f…9c02
governance_signatureVALID · IN-PERIOD
dataset_root7be0…11af
source_total1,004,882
covered1,004,109 · 99.923%
excluded773 · rule EX-04 (approved)
runtime_digeste9d3…4470
findings2 breaks · 0 faults
VERIFIED8 / 8 · offline · 0.9s

Which changes what assurance costs you, and what it covers.


08
What it
changes

Everything, every period, for less than a sample costs

The economics of assurance have always run the wrong way: full coverage was the expensive option, so the industry bought samples and called it evidence. A proof over the whole population costs about what a proof over a sample costs — which quietly inverts the trade-off you have been making for decades.

Coverage

Every record, not forty of them

A sample cannot find the segment that never entered the population. Full execution can, and reports the coverage figure either way — so a gap surfaces as a number in the packet instead of a finding in an exam.

Every period, not once a year.

Time

The evidence request answers itself

No pulling queries under deadline, no reconstructing what a dashboard showed in March, no analyst re-explaining an export to an examiner. The packet already exists, and verification runs in about a second on a laptop.

Hours back for the people asked for them.

Cost

One artifact, every counterparty

The same packet satisfies the sponsor bank, the auditor and the examiner without a bespoke exercise for each. The expensive part of compliance is rarely the control — it is proving the control to a third party, repeatedly, by hand.

Produced once, checked by anyone.

We are deliberately not putting a savings percentage on this page. Nobody has run it in production yet, and a number we cannot evidence would undercut the one thing we are selling. Quantifying it honestly is a stated goal of the first pilots.

And the same arithmetic holds wherever a control meets a population.


09
Same shape,
ten vocabularies

One mechanism. Different words for it.

Every row below is the same sentence — a control, a population, a relying party — in a different industry's vocabulary. We start with FBO ledger reconciliation, where failure is unambiguous. We are not building all ten; we are building the first properly, in a way that does not have to be rebuilt to reach the others.

DomainThe controlWho needs the assurance
Ledger reconciliationFirstEvery FBO position matched to the custodian statementSponsor bank, trustee
AML / sanctionsEvery transaction screened against current listsSponsor bank, FinCEN, OFAC, state regulator
Financial reportingEvery material transaction included in the reported figureExternal auditor, audit committee, SEC
Healthcare claimsEvery claim checked against eligibility and coding rulesPayer, CMS, contracted auditor
Clinical trialsEvery adverse event captured and reported within the windowFDA, IRB, sponsor
AI governanceEvery model output evaluated against the stated safety policyRegulator, enterprise customer, board
Data protectionEvery deletion request executed across all systemsSupervisory authority, data subject

And none of it asks you to replace anything you already run.


10
Where it sits

Alongside what you run, not instead of it

No migration and no change to a system of record. The same approved control runs alongside yours, over the same committed population, reconciled periodically. Your production system stays the system of record; the packet is the only new artifact leaving the building.

We call this conformance mode. It is our best answer so far rather than a finished pattern — proving it in a real environment is exactly what the first pilots are for.

Your production system

Unchanged. Still the system of record.

Ellipe 3, alongside

Same control, same population. Periodic reconciliation.

Evidence Packet → relying party

Verified offline, without your data.


11
The limits

What we do not claim

Stating limits plainly is part of the product. An assurance system whose vendor overstates it is worth nothing to the person who has to rely on it — so this comes before the ask, not after.

We do not prove your extraction query was right

Every extractor faithfully runs the same wrong query. We make the rule explicit, quantify its coverage, and force any difference to be attributed to an approved exclusion.

A snapshot is not a period

Late settlement and back-posting mean a July extraction taken on August 1 can be impeccable and still incomplete. We record restatements; the general case is an open research problem.

We do not judge your rules

Whether a threshold is the right policy is a supervisory judgment. We prove the approved control ran over the complete population; we do not opine on whether it was approved wisely.

No regulator has pre-blessed this

None will, in advance. We are in talks with NYDFS to understand what supervisors would find useful. A verifier returns a verdict about an artifact, never an opinion about an organization.

Including the largest limit of all — which is simply where we are today.


12
Where we are

One gate decides everything

Complete

Architecture settled

One canonical control format, one runtime, 24 opcodes.

Complete

V1 proof of concept

A self-verifying packet at roughly a million records per proof.

In progress

First stable build

Byte-identical from published source, with a digest anyone can reproduce.

Then

CLI and connectors

In that order. First target: FBO ledger reconciliation.

The gate

Independent acceptance

A former Federal Reserve examiner runs the verifier with no involvement from us. Nothing architectural moves until that happens.

Institutional support

Lambda Research Grant. 1752VC Launchpad. NSF SBIR Phase I in progress. Engaged with Fintech Sandbox.

Regulatory conversations

In talks with NYDFS. No regulator has endorsed the artifact and we do not represent otherwise.

The team

Four co-founders who have worked together for over five years, including an active compliance professional at a regulated firm.


13
Still fair
to ask

Frequently asked questions

Who is this for, first?

Sponsor banks that hold regulatory liability for partner fintechs whose systems they do not operate, and the fintechs producing evidence for them. The bank asks for it, the fintech produces it, the examiner can check it.

Do you see my data?

No. The packet carries commitments, findings and signatures — not records. Your counterparty verifies it without the data, without access to your systems, and without our participation.

Is this blockchain?

No. Nothing moves on-chain and there is no token. The system uses succinct proofs, which means a claim about a million records can be checked without receiving a million records. Verification runs on a laptop.

What happens if a run fails?

Failed runs produce artifacts too. Evidence of failure is a first-class output — a system that only emits proof when things go well is suppressing, not proving.

What if Ellipe 3 disappears?

Nothing. Verification is offline and perpetual: nothing in a packet requires resolution against a live service, and the runtime is a published, reproducible build.

Can I run it today?

Not yet. V1 is a proof of concept; V2 is where it becomes practical. The first reproducible build with a published digest is the next milestone, and until it exists, independent verification cannot be meaningfully attempted.

Stop asserting it.Hand them the proof.

We are selecting the first conformance-mode pilots now. Reach out and we’ll send the primer, the regulator brief, and a first call when the stable build lands.

kevin.mangroo@ellipe3.com

Get in touch