Coverage evidence for regulated controls

Every record, accounted for.

E3 is building evidence that every record in a control’s source population was either covered or excluded under a stated rule, checkable by examiners with a standalone verifier, offline. Built first for BSA/AML controls at sponsor banks and their fintech partners.

Request the primer See how it works

01
The problem

You carry the liability. Someone else runs the system.

The sponsor bank answers for BSA/AML controls that its fintech partners execute.

When examined, the evidence on hand is screenshots, spreadsheets and attestations, all produced by the party under examination, after the question was asked.

  • Jan 2024

    Blue Ridge

    OCC consent order over BSA/AML and third-party risk failures in its fintech partnerships.

  • Jun 2024

    Evolve

    Federal Reserve cease-and-desist over AML, OFAC and risk-management gaps in its fintech partner program.

  • Oct 2024

    Axiom

    OCC consent order over BSA/AML program deficiencies tied to its fintech partner business.

In each case, the bank was the named party.

120+

US banking enforcement actions, fines and suits in 2024.

$61B

Annual financial-crime compliance spend across the US and Canada.

Sources: American Banker / OCC (2024); LexisNexis Risk Solutions, True Cost of Financial Crime Compliance.

02
The blind spot

Controls rarely fail. Populations do.

Most failures involve records that never reached the control. A screening rule can run perfectly on the wrong population. Sampling can’t catch this, because the sample is drawn from the records that already made it in.

  • Unwired

    A product line never joined to the feed.

  • Parallel ledger

    A partner channel nobody connected.

  • Migration gap

    A date range silently dropped.

  • Changed predicate

    A status code whose meaning shifted.

  • Late arrivals

    Corrections that landed after the window closed.

E3 makes the population itself the thing being checked.

03
How it works

Four steps, one file.

This is the design. The packet below and the Status section show what the proof of concept verifies today.

  1. 01

    The control is written down.

    A readable plan, signed by a governance authority.

  2. 02

    The population is committed.

    A signed extraction states the rule, the time window and the totals. Every record left out is counted and tied to a stated reason.

  3. 03

    One fixed runtime executes it.

    A published program. The plan is data, not new code for each control.

  4. 04

    The Evidence Packet is handed over.

    The recipient runs a standalone verifier: offline, with no account and no call to E3.

From our proof-of-concept run on AMLworld, IBM Research’s public synthetic AML dataset.
Evidence PacketAMLworld daily run
source rows read
5,078,345
anchored (in population)
4,932,279
excluded
0
rejected at ingest
146,066 · unmapped currency · reported, not yet signed
partition vs signed commitment
✓
epochs
18 / 18
VERDICTACCEPT

ACCEPT covers the anchored population. Records rejected at ingest are recorded in an unsigned report today; binding them into signed evidence is the next build step.

What the verifier checks today

  1. Scope and evidence signatures are valid, and the scope covers the period.
  2. The population matches its signed commitment, in both root and count.
  3. Classification counts reconcile within each receipt.

Planned

  1. Every exclusion and ingest rejection is bound to a signed rule.
  2. The source total is reconciled inside signed evidence.
  3. Signatures come from a governance authority with validity periods.
  4. The runtime matches a published, reproducible build.

The same mechanism applies wherever a control meets a population. We are building BSA/AML first.

The construction: Verifiable Computation over Independently Evidenced Populations (VCEP). Patent pending.

04
Status

Where we are.

Built

  • EVP-1 proof of concept in Rust, with a standalone verifier and a file-based trust store.
  • Testing on AMLworld, IBM Research’s public synthetic AML transaction dataset: 18 of 18 epochs ACCEPT over 4,932,279 anchored records; 146,066 rows rejected at ingest are reported, not yet proven.
  • A tamper demonstration of 10 cases (dropped rows, altered totals, broken bindings). Each is rejected at its expected check.

Next

  • Bind ingest rejections and exclusion rules into signed evidence, checked by the verifier.
  • Testing against real-format institutional data with a design partner.
  • An independent review of the verifier.
  • A reproducible build with a published digest.

Regulatory

  • In conversation with the NYDFS Research and Innovation Division.
  • No regulator has endorsed this, and we don’t represent otherwise.

Support

  • Lambda Research Grant
  • 1752VC Launchpad
  • Patent pending (provisional filed)
What we don’t claim
  • Today, records rejected at ingest are reported, not proven. Closing that gap is our next milestone.
  • We don’t prove your extraction query was the right one.
  • A snapshot is not a full period. Late postings and restatements are recorded; the general case is still open.
  • We don’t judge whether your policy is wise, only that the approved control covered the full population.
  • No regulator has endorsed this.

05
Team

Team

  • Kevin Mangroo

    Founder & CEO

    Cryptographic systems, RegTech infrastructure and BSA/AML compliance. Sole inventor on the VCEP work.

    LinkedIn · Email

Supported by engineering and compliance advisors.

Selecting first design partners.

For sponsor banks and fintechs that want to test coverage evidence on their own BSA/AML controls. Email us for the primer and a demo walkthrough.

Request the primer Design partner inquiry