Coverage evidence for regulated controls

Every record, accounted for.

E3 is building evidence that follows each record from its accepted source to its outcome, so an examiner can see that nothing went missing on the way. The first layer, population coverage, runs today as a proof of concept with a standalone verifier. 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 · OCC

    Consent order

    A sponsor bank, over BSA/AML and third-party risk failures in its fintech partnerships.

  • Jun 2024 · Federal Reserve

    Cease-and-desist

    A sponsor bank, over AML, OFAC and risk-management gaps in its fintech partner program.

In both cases, the bank was the named party, not the fintech.

120+

US banking enforcement actions, fines and suits in 2024.

$61B

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

Sources: OCC and Federal Reserve enforcement releases (2024); 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
The model

A record you can follow from source to outcome, with evidence at every step.

An examiner asks three questions about the records behind a control. Each layer of VCEP answers one. Only the first is built.

LayerQuestion it answersStatus
EVP-1Population Did every record from the accepted source arrive at the control, or get excluded with a counted reason? BuiltProof of concept
EVP-2Routing and attribution As records move through each step, does every one end up somewhere declared, and under which stated rule? Design
EVP-3Execution Did the approved process actually run? Design

Later layers extend the same evidence, so an EVP-1 result stays valid as the others are added.

Built: code exists and has run on public test data. Design: specified, not built and not tested. How the design layers work is not described here while patent filings are in progress.

04
EVP-1 today

Four steps, one file.

This is EVP-1, the population layer, as designed. 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 runs on AMLworld, IBM Research’s public synthetic AML dataset.
Evidence PacketAMLworld daily runs
source rows read
Oct 2 run: 5,078,345
Oct 16 run: 5,078,345
anchored (in population)
Oct 2 run: 4,932,279
Oct 16 run: 5,078,345
of which marked malformed
Oct 2 run: 78
Oct 16 run: 146,144
excluded
Oct 2 run: 0
Oct 16 run: 0
rejected at ingest
Oct 2 run: 146,066
Oct 16 run: 0
population vs signed commitment
Oct 2 run: ✓
Oct 16 run: ✓
epochs
Oct 2 run: 18 / 18
Oct 16 run: 18 / 18
VERDICT, BOTH RUNSACCEPT

In the Oct 2 run, 146,066 rows with an unmapped currency were rejected at ingest: reported, not yet signed. Since Oct 16 those rows are anchored and marked malformed, so every row read is inside the signed population. ACCEPT confirms each record has exactly one outcome, not that it is the right one.

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 daily epoch.

Planned

  1. The rule behind each exclusion, and each remaining ingest rejection, is signed, not only stated.
  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 question applies wherever a control depends on a complete population, such as insurance claims or healthcare billing. We are building BSA/AML first.

The construction: Verifiable Computation over Independently Evidenced Populations (VCEP). Patent pending: two provisional applications filed.

05
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 daily epochs ACCEPT in both runs. On Oct 2, 4,932,279 records were anchored and 146,066 rows rejected at ingest were reported, not yet signed. Since Oct 16, all 5,078,345 rows are inside the signed population, 146,144 of them marked malformed.
  • A tamper demonstration of 10 cases (dropped rows, altered totals, broken bindings). Each is rejected at its expected check.

Next

  • Sign the rule behind each exclusion, not only the count.
  • Testing on real-format institutional data.
  • An independent review of the verifier.
  • A reproducible build with a published digest.
  • EVP-2 and EVP-3 are in design.

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: two provisional applications filed
What we don’t claim
  • The claim depends on the source population being evidenced by a party independent of the pipeline being checked. Some banks hold such a record today and some don’t. Where none exists, the evidence is only as strong as the pipeline’s own account of itself.
  • EVP-2 and EVP-3 are design. Neither runs today, and neither has been tested.
  • Every result so far is on public synthetic data, not on any institution’s records. In our tests, one machine played every role.
  • The verifier confirms that each record has exactly one outcome. It does not confirm that the outcome was the right one, and the rule behind an exclusion is stated but not yet signed.
  • Rows whose amount cannot be read are still rejected at ingest and recorded only in an unsigned report. The AMLworld export had none.
  • 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.

06
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.

Test coverage evidence on your own controls.

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

Request the primer Request a walkthrough