Mockup
Verifiable Control Execution Platform

Stop asking your sponsor bank to trust your evidence.

When regulated controls are executed outside your organisation's direct operational boundary, the evidence must be independently verifiable — not simply produced by the party being evaluated.

Evidence Packet EP·2026·0417·A93F
01
Control Identity
control.definition · version · scope
02
Population Declaration
covered set · declared exclusions
03
Execution Evidence
what occurred during execution
04
Verification Information
what an independent verifier needs
digest sha256:9f2c…41abverifiable offline

The primary artifact produced by the platform.

Who this is for

Built for organisations responsible for proving controls executed outside their direct operational boundary.

Fintech Platforms
Licensed Money Transmitters
Organisations executing regulated controls
Internal Audit
Who verifies

The parties who must establish that the control ran — without being asked to take the producer's word for it.

Sponsor Banks
Third-Party Risk
External Auditors

One organisation executes. Another organisation needs to verify.

§ 03 The shift

The organisation executing the control is often no longer the organisation responsible for trusting it.

01
Execution

Runs inside a partner, a vendor, or a platform you do not operate.

02
Oversight

Sits with an institution that has no direct visibility into that execution.

03
Accountability

Remains with the regulated entity regardless of who pressed the button.

04
Verification

Now has to happen across a boundary the evidence was never designed to cross.

Existing evidence was largely designed for environments where execution and accountability lived closer together.

§ 04 The problem

Modern oversight still relies on assertions.

Not because anyone is dishonest, but because the artifacts in circulation were built to describe work rather than to prove it. A report asserts. A dashboard asserts. A log asserts. Each one is only as good as the infrastructure and the goodwill behind it — and both sit on the producer's side of the boundary.

Where current evidence stops
01
Rule modified after execution

The definition that ran is not the definition on file today.

02
Silent population gaps

Records that were never in scope leave no trace of their absence.

03
Version drift

Lists, thresholds and models move; the evidence does not say which moved when.

04
Missing data

An upstream feed fails and the run completes as though it did not.

05
Historical overwrites

The state of the past is rewritten by the systems that hold it.

Existing evidence mechanisms often stop short of independently proving what executed, against which population, under which control definition.

CategoryWhat it doesWhat it cannot independently prove
Compliance PlatformsManage policies, workflows, obligations and compliance processes.The historical execution state of a specific control and its declared population.
AML & Screening SystemsExecute screening and identify potential risks.That historical execution, population coverage and control state remain independently verifiable.
Audit Logs & SIEMRecord operational events.Completeness and integrity of the underlying control execution population.
External AuditsProvide independent assessment and assurance.A portable execution artifact that can itself be independently reverified years later.

These categories are complementary. Ellipe 3 supplies the artifact they each depend on and none of them produce.

§ 05 The new category

Evidence that survives the organisational boundary.

Independent

The relying party can verify the evidence without trusting the producer's infrastructure.

Portable

Evidence can move between organisations without requiring access to the originating system.

Durable

Verification can remain possible after the original execution environment changes or disappears.

Verifiable Control Execution Platform · VCEP

A VCEP produces independently verifiable evidence of control execution, so that a relying party can establish what control ran, what population it covered and what execution evidence resulted — without relying solely on the producer's assertion.

Ellipe 3 builds VCEP infrastructure.
§ 06 The Evidence Packet

The primary artifact produced by the platform.

Evidence Packet EP·2026·0417·A93F
01
Control Identity
control.definition · version · scope
02
Population Declaration
covered set · declared exclusions
03
Execution Evidence
what occurred during execution
04
Verification Information
what an independent verifier needs
digest sha256:9f2c…41abverifiable offline
Control Identity

Identifies the exact control definition governing the execution.

Population Declaration

States the population covered and declared exclusions.

Execution Evidence

Records evidence of what occurred during execution.

Verification Information

Provides what an independent verifier needs to establish validity.

An Evidence Packet is designed to be independently verified without access to the originating infrastructure.

Explore the Evidence Packet
§ 07 How the relationship works

The producer generates the evidence. The relying party verifies it independently.

Producer
Fintech
Evidence Packet
01Control Identity
02Population Declaration
03Execution Evidence
04Verification Information
Boundary
Relying party
Sponsor Bank
Outcome
Verification
Producer
Vendor
Artifact
Evidence Packet
Relying party
Auditor
Outcome
Verification
§ 08 Where this applies

These are the control types Ellipe 3 is being built and validated against.

Sponsor Bank Oversight

Evidence for controls executed by fintech and program partners.

Sanctions Screening

Evidence supporting independent verification of screening execution and declared coverage.

FBO Reconciliation

Evidence supporting verification of reconciliation controls and population coverage.

Internal Assurance

Portable execution evidence for internal audit and assurance functions.

Applications under build and validation. Not claims of production deployment.

Replace trust with verification.

Talk With Us
The artifact

What is an Evidence Packet?

The primary artifact produced by the platform. It is a bounded, self-describing record of one control execution: the definition that governed it, the population it covered, what happened, and everything a third party needs to check the first three for themselves.

Everything else on this site exists to produce, move, or verify this object.

Verified without
a live API
access to originating infrastructure
continued access to the producer
dependency on Ellipe 3
§ 02Anatomy · canonical definition

Four claims, and what each one has to withstand.

Evidence PacketEP·2026·0417·A93F
01
Control Identity
control.definition · version · scope
02
Population Declaration
covered set · declared exclusions
03
Execution Evidence
what occurred during execution
04
Verification Information
what an independent verifier needs
digest sha256:9f2c…41abverifiable offline
01

Control Identity

Identifies the exact control definition that governed this execution — not the control as it is described today, but the version that actually ran: its parameters, thresholds, reference data and declared scope, bound to the execution rather than referenced from a mutable registry.

Answers: which rule ran? Withstands a rule being modified, renamed or retired after the fact.

02

Population Declaration

States the population the execution covered and, explicitly, what it did not. Exclusions are declared rather than inferred from absence, so a verifier can distinguish a record that was deliberately out of scope from a record that silently went missing.

Answers: over what? Withstands silent gaps and undeclared partial coverage.

03

Execution Evidence

Records evidence of what occurred while the control ran — outcomes, dispositions and the conditions under which they were reached — in a form fixed at execution time rather than reconstructed afterwards from systems that have since moved on.

Answers: what happened? Withstands historical overwrites and post-hoc reconstruction.

04

Verification Information

Carries what an independent verifier needs to establish that the first three claims hold — inside the packet, so the check can be performed by someone with no relationship to the producer, no access to the originating environment and no live connection to anything.

Answers: why should anyone believe it? Withstands the producer becoming unavailable.

§ 03Lifecycle

A packet outlives the run that produced it.

t0
Control

A definition is fixed and versioned.

t1
Execution

It runs against a declared population.

t2
Evidence Packet

The artifact is sealed and leaves the boundary.

t3
Independent verification

The relying party checks it themselves.

t4
Archive

It is retained as an ordinary file.

t+n
Reverify years later

The same check runs again and returns the same answer.

§ 04Who verifies

The verifier is independent of the producer.

Producer
Fintech
Artifact
Evidence Packet
Relying party
Sponsor Bank
Outcome
Verification
Producer
Vendor
Artifact
Evidence Packet
Relying party
Auditor
Outcome
Verification
§ 05What it is not

Three things it is regularly mistaken for.

Not a log export

A log records what a system chose to write down, in the format it happened to use, for as long as retention allows. It carries no declaration of the population it should have covered, and no way to establish that nothing was dropped.

Not a report

A report is a summary authored by the producer for a reader. Its accuracy rests on the producer's process. Re-reading it later tells you what was claimed, not whether the claim was true.

Not an attestation

An attestation transfers trust to a signer — it is a statement that someone competent looked. A packet does not ask the relying party to trust a signature over the underlying facts; it lets them check the facts.

All three describe execution. A packet is constructed so that execution can be established by someone who was not there.

Platform

What is a Verifiable Control Execution Platform?

A VCEP executes a control and, in the same operation, produces evidence that a third party can check independently. The two are not separable steps: the artifact is a by-product of execution, not a report written about it afterwards.

The platform's job is narrow and deliberate — bind a control definition to a run, declare the population, capture what occurred, and package all of it so the check can happen elsewhere, later, by someone else.

§ 02The artifact, briefly

One packet describes one execution across four claims: control identity, population declaration, execution evidence, verification information. The canonical definition of each lives on the Evidence page — this page assumes it.

Canonical definition
Evidence Packet
01Control Identity
02Population Declaration
03Execution Evidence
04Verification Information
§ 03How verification works

The verifier is handed a file and a procedure. Nothing else.

step 01
Receive

The packet arrives by whatever channel already exists — a portal, a share, an email attachment.

step 02
Check integrity

The packet is self-describing: its contents are checked against the commitments carried inside it.

step 03
Check coverage

The declared population is reconciled against the execution evidence, including declared exclusions.

step 04
Reach a verdict

The result is deterministic. The same packet and the same procedure return the same answer, on any machine, at any time.

§ 04Technical architecture

Five layers, one of which leaves the building.

layer 01
Control
layer 02
Runtime
Evidence Packet
layer 04
Verification Engine
layer 05
Verifier

Layers 01–02 run inside the producer. Layers 04–05 run inside the relying party. Layer 03 is the only thing that moves between them — and it is the only layer this site's business architecture shows.

§ 05Security principles
Integrity

A packet that has been altered does not verify. There is no partial credit.

Provenance

What produced the evidence, under which definition, is bound into the artifact rather than asserted alongside it.

Coverage

Exclusions are declared. An undeclared gap is a verification failure, not a silent omission.

Deterministic execution

Given the same inputs, the same result — which is what makes an independent re-check meaningful.

Independent verification

The check runs on the verifier's terms, on the verifier's hardware, without the producer in the loop.

Durable verification

The procedure is documented and stable, so a packet checked in 2026 can be checked again in 2033.

Cryptographic commitments and zero-knowledge techniques are how several of these properties are achieved. They are implementation, not proposition — the guarantees above are what a relying party is being offered.

§ 06Why independence matters

Every dependency is a future point of failure for the relying party.

producer infrastructure

If the check runs on the producer's systems, the producer is inside their own audit.

live APIs

An endpoint that is deprecated, rate-limited or offline takes the evidence with it.

vendor availability

Companies are acquired and wound down. Retention obligations outlast both.

mutable historical state

If the past can be edited, evidence about the past is a snapshot of an opinion.

§ 07Questions we get
Does verification require Ellipe 3?

No. The packet and the verification procedure are what a relying party needs. Our involvement is not a dependency of the check.

Does the verifier need our infrastructure?

No. That is the point of the boundary. Verification runs on the verifier's side with no connection back to the producing environment.

What if Ellipe 3 no longer exists?

Packets already issued remain verifiable. The format and procedure are documented so that the check does not depend on the company continuing to operate.

Does this replace my AML system?

No. Your screening system continues to execute screening. Ellipe 3 makes that execution independently provable to whoever has to rely on it.

Does this require moving customer data?

No. A packet is designed to establish coverage and execution without exporting the underlying records to the verifier.

Who verifies the packet?

The relying party — a sponsor bank, a third-party risk function, internal audit, or an external auditor acting on their behalf.

How long does verification remain possible?

For as long as the packet is retained and the documented procedure can be run. Durability is a design constraint, not a service level.

Contact

Talk With Us

Three kinds of conversation, and they are genuinely different. Tell us which one you are starting so it reaches the right person.

I am a…

The selected role is captured with the submission — it is the site's segmentation signal.

Start the conversation role · unset

No demo funnel. A person reads this and replies.

Instrumentation
scroll depth · CTA clicks · role selection