Deterministic Assurance: IBANforge IBAN validation
A commissioning experiment asking whether a paid machine-service result can be checked against an independently computed deterministic expectation rather than treating payment or fulfilment as proof of correctness.
Two paid calls to an external IBAN validation service settled on Base and returned valid values matching independently computed ISO 13616 MOD-97 expectations for one valid and one deliberately invalid German IBAN fixture; both observations produced signed Assurance receipts.
Research question
Can the Assurance Runner execute a bounded pair of paid controls against an external machine service, independently observe settlement and fulfilment, and then evaluate one returned field against an objective method that does not depend on trusting the seller's own answer?
This is a stronger question than “did the service return HTTP 200?” but deliberately narrower than “is this provider generally correct?”
Subject and scope
The subject was the externally operated IBANforge validation route at POST https://api.ibanforge.com/v1/iban/validate.
The independently tested capability was IBAN checksum validation. Only the returned valid field was evaluated. BIC, SEPA, bank, issuer and other enrichment fields were outside the independently verified scope.
The run was human-triggered commissioning using Runner-controlled bounded execution logic. It should not be read as proof of unattended production autonomy.
Method
valid result using ISO 13616 MOD-97 rather than the seller output.valid field with the precomputed MOD-97 expectation.Controlled fixtures
DE89370400440532013000 · expected true · observed trueDE90370400440532013000 · expected false · observed falseThe negative fixture returning false is a passing negative control. It is not a seller failure.
Observed paid execution
Settlement evidence
The positive control settled in Base block 50962836 and the negative control in block 50963382. Each settlement was 0.005 USDC.
Inspect the positive-control transaction
Inspect the negative-control transaction
Those public chain references support the settlement claim. They do not, by themselves, prove fulfilment or correctness.
Signed evidence
Two signed Assurance Evidence Receipts were published under the production Assurance signing key active for the commissioning run.
A useful failure-path observation
The first attempt to publish the completed evidence reached the Verification receiver while its write gate was disabled and returned HTTP 503 before write confirmation. The Runner treated the dispatch as indeterminate and did not automatically replay it.
After read-only reconciliation found no published record and the operator inspected the receiver state and idempotency behaviour, one explicit exact replay was approved. Publication then returned HTTP 200 and reconciliation confirmed the record.
This supports a fail-closed recovery behaviour. It does not justify automatic replay after every uncertain dispatch outcome.
What the experiment supports
The observation supports that the bounded production path completed two real paid calls against the stated route, independently observed both Base settlements, captured useful fulfilment and correctly compared the returned valid field with one positive and one negative MOD-97 expectation.
It also supports that the evidence publication path produced two signed buyer-readable receipts after the bounded recovery process completed.
What it does not support
Two passing controls do not establish permanent service reliability, universal IBAN correctness across countries or inputs, correctness of unrelated enrichment fields, or the provider's internal implementation mechanism.
The run does not establish traffic indistinguishability, unattended production autonomy, provider-wide trustworthiness, certification, or a universal recommendation to buy the service.
Primary public evidence
The public technical research record contains the bounded fixtures, settlement references, scope and receipt links. Atinamos Verification also exposes the commissioning evidence through buyer-readable surfaces.
Interpretation
IBANforge is useful because it demonstrates the difference between generic fulfilment evidence and independently testable correctness. Here, one narrow output claim had an external deterministic method: the checksum expectation could be computed before seeing the seller's answer.
That does not make every response field objectively testable. It simply shows that when a bounded independent method exists, correctness can be elevated from “not evaluated” to a specific observed comparison without turning that result into a provider-wide trust judgement.
How to cite
Atinamos Labs (2026). Deterministic Assurance: IBANforge IBAN validation. Experiment report, version 1.0. Observed 6 September 2026. https://atinamoslabs.co.uk/research/ibanforge-deterministic-assurance/
Revision history
v1.0 · 16 September 2026 — Initial Labs experiment report based on the already-public commissioning record and retained Atinamos evidence. Scope limited to the independently tested valid field and public-safe operational observations.