MERIDIAN GLOBAL FINANCE

When things go wrong — refusals, disputes and reversals.

Every other demonstration on this site succeeds. That is not how a payment system is judged. What matters is what happens when a payment should not go through, when a customer says they never authorised one, and when money has already reached a fraudster. Each scenario below runs for real, commits to the ledger, and can be traced afterwards. Several of them are supposed to fail — and the failure is the point.

Every scenario runs live Refusals are recorded, not just returned ECH953 reversal, demonstrated Not the production network

Refusals — when a payment should not happen

A refusal that leaves no record is only half a control. Each of these writes a permanent entry, so the attempt itself is evidence.

Refused Direct debit above the ceiling

A utility company tries to collect £210 against a ceiling the customer set at £150. Ordinary direct debit systems collect first and let the customer claim it back afterwards. Here it simply does not happen.
ECH104 · direct debit

Refused Payment from a frozen card

The holder froze their card from the app. A payment is then attempted. The freeze is not advisory.
ECH950 · priority security protocol

Refused Settlement before compliance clears

An institution attempts to send before KYC and AML have been confirmed. On a correspondent network the payment would go and be screened in flight. Here the instruction cannot be constructed.
ECH955 · priority KYC/AML escalation

Refused A PAM draw beyond the safe-draw rule

A citizen attempts to draw more than has accrued. The fund's capital is never available to it, by construction — the ledger refuses rather than flags for review.
ECHAAA020 · PAM lifecycle

Disputes — when a payment did happen and shouldn't have

The harder case. Money moved, and someone says it should not have. What decides it is the quality of the record.

Resolved “I never authorised this”

A customer disputes a payment. The compliance token attached to that settlement is retrieved: who instructed it, from which device and account, at what time, and whether checks cleared beforehand. The dispute is decided on evidence rather than on which party is more persistent.
ECH734 · advice of discrepancy

Resolved Goods never arrived

A merchant took payment and did not deliver. The payment itself is not in doubt — the obligation behind it is. The record establishes what was paid, to whom and against what reference, which is what a chargeback process needs and rarely has cleanly.
ECH416 · advice of non-payment / non-acceptance

Reversal — when the money has already gone

The scenario the whole compliance architecture exists for. This is the one to watch.

Fraud Recovering funds sent to a fraudster

An elderly customer is deceived into sending £80,000 to an account controlled by a fraudster overseas. Under correspondent banking the money is typically gone before anyone acts. Here the full sequence runs: trace, court order, freeze, and reversal. Watch which steps are automatic and which require a judge — the distinction is deliberate.
ECH950 freeze · ECH965 evidence request · ECH953 court-ordered reversal

The ledger

Every scenario writes here, including the refusals. Nothing is removed — a reversal is a new entry, not an erasure.
Run a scenario and the entries appear here.

What this page is, and isn't

What's real here

Every scenario commits genuine SHA-256 hash-chained entries, and the refusals are real refusals: the amounts genuinely do not move, and the attempt is recorded as its own permanent entry so a customer can later prove a collection was attempted against them. The base-33 round-trip check runs on every value. The ECH codes shown against each scenario are the ones documented in the ESTC codex, including ECH953 for court-ordered reversal, which exists in that specification and is exercised here rather than merely listed. A reversal is written as a new entry rather than by deleting the original — the history of a disputed payment stays intact.

What's simulated

No court order is verified here; the fraud scenario accepts a reference and proceeds, exactly as the settlement page does, and a production system would need genuine judicial verification before acting. The parties are demonstration accounts and no real customer, bank or fraudster is involved. Recovery is shown as succeeding: in reality funds are frequently dissipated before any order is obtained, and this demonstrates the mechanism rather than a success rate. Cross-jurisdiction enforcement depends on the receiving institution being a network participant bound by its terms, which is set out on the settlement page and is not the same as one country's court reaching into another's.