Every financial decision explainable, traceable and provable.
The accountability layer of the transaction lifecycle. Every decision is sealed as it happens, hash-chained and signed — and can be verified by anyone, without trusting us.
What an evidence package contains.
One transaction, and everything that was true about it — sealed as it happened, not assembled afterwards from systems that have since moved on.
- The transaction recordParties, amount, currency, corridor and purpose as instructed, with the invoice or purchase order it pays bound to it.
- The decisionApprove, hold or reject, with the screening and risk inputs that produced it and the list versions in force at that moment.
- The policy versionThe exact version of your rules that decided this transaction — not the version running today.
- The approverWho approved or released a held transaction, under which rule, and when. Attribution is to a named actor, never to a role.
- Routing & executionWhich rail the transaction was routed to, when it was submitted, and the provider reference bound to it.
- SettlementWhat settled, when, and against which record from the executing institution.
- Ledger postingsThe debits and credits the movement produced, exactly as they were written.
- ReconciliationInstructed, executed and settled matched against one another, and any difference is surfaced, not absorbed.
Each record binds cryptographically to the one before it, so altering any record breaks the chain visibly. An examiner recomputes every hash on their own machine — verification does not depend on VadoRail being available, cooperative or still in business.
Six properties you can test today.
- AuditabilityEvery decision and movement is recorded as it happens and can be produced as a signed, independently verifiable package.
- ArchitectureControl sits on the transaction path, not beside it. A policy is a gate in front of execution, never a report behind it.
- Data protectionTenant data is isolated per organisation and per environment, and access is resolved server-side. A client-supplied claim is never trusted.
- Financial integrityDouble-entry postings must balance to be written. An unbalanced transaction is rejected by the database, not stored and corrected later.
- Access controlWho may initiate, approve, export and administer is separated, and every action is attributed to a named actor.
- API infrastructureKeys are issued per organisation and per environment, and a test key cannot act in live.
Do not take our word for it.
Every other claim on this page asks to be trusted. This one can be tested. Below is a signed evidence package in the format the platform produces — run the same check an examiner would run, then alter a record and watch the chain break.
What happens when you press Verify
- 1FetchYour browser downloads a signed evidence package containing five sealed payment decisions.
- 2RecomputeIt hashes every record with SHA-256 and compares each result to the hash sealed at decision time.
- 3Walk the chainIt checks that each record still binds to the one before it, then reports pass or fail.
- SyntheticThe payments, counterparties and decisions in the package are synthetic.
- RealThe SHA-256 hashing, the chain walk and the signature check are real, and run entirely in your browser.
Start with one corridor.
Connect your financial operations to infrastructure designed to move, govern, embed and finance money movement across borders.
Onboarding is sales-led with company verification — there is no anonymous signup.