Payments, with ISO 20022 on the inside

Most cores speak a proprietary internal format and translate at the boundary in both directions. That second translation is where reconciliation breaks. Here the internal shape IS the standard.

Rail by rail

Payment rails, message shapes and delivery status
RailMessage shapeWhat it guaranteesStatus
SAMOS (SARB RTGS)pacs.008 / pacs.002 / camt.054Window-aware settlement: an instruction submitted outside the window queues against the next one rather than failing at the counterparty.✓ Live
PayShap (rapid payments)Proxy resolution, request-to-paySub-10-second clearing with proxy (ShapID) resolution, and a recall path that is bound to the original instruction rather than reconstructed.✓ Live
DebiCheckAuthenticated mandates, TT1 / TT2 / TT3A mandate money-limit cannot be raised without debtor re-authentication — the amendment path re-enters authentication, it does not patch the record.✓ Live
SADC-RTGSCross-border ZAR settlementParticipant directory with settlement-agent routing and the same sanctions gate as domestic value.✓ Live
SWIFT MT + MXMT103 / MT202 with MX co-existenceMessage construction and inbound parsing are delivered; the live network connection is a deployment item, not a code item.◐ In build
Card (issuing and acquiring)ISO 8583 bridge onto the ISO 20022 spineIssuing with per-transaction and monthly ceilings from a versioned card product; PAN never lands in the platform — tokenization happens at the boundary.◐ In build
QR (interoperable)EMVCo payload parse and emitMerchant-presented and consumer-presented, with a conservation identity between what was scanned, what settled and what the merchant is paid.✓ Live
EFT (collections and payouts)Batch origination with camt.053 reconciliationStatement ingestion reconciles against originated batches; an unmatched credit is an exception with an owner, not a silent write-off.✓ Live

What holds across every rail

  1. Screened before the money moves — sanctions, PEP and adverse-media checks run before the value movement, not alongside it. A hold is a workflow state with an owner, and the operator who raised it cannot release it.
  2. One lifecycle transition per movement — the state change is a compare-and-swap. A concurrent duplicate loses the swap and moves nothing, which is why a double-submit cannot double-pay.
  3. Ceilings and limits are checked at the movement — not at set-up time. A limit configured before a facility existed still applies to the money that facility later moves.
  4. The accounting leg is part of the transaction — a payment that settled and a payment that posted are the same event, so there is no in-flight window to reconcile.
  5. Idempotent submission — a replayed instruction returns the original outcome. A replay carrying a different body is a conflict, never a second payment.
  6. Reversal is a fact, not an edit — an unwind appends a reversing entry. The original movement remains in the chain, which is what makes the history inspectable.

Wallets, VAS and acceptance

Single and multi-currency wallets

Balances are integer minor units against a ledger account, so a wallet balance IS an accounting position rather than a number kept alongside one. Multi-currency wallets carry pockets, holds and an FX path that books the spread as it is earned.

Value-added services

Airtime, data, electricity tokens, municipal bills, subscriptions and insurance premiums. Margin is recognised as it is earned, on the same audited ledger as loan interest — there is no separate VAS book to reconcile.

Merchant acceptance

Interoperable QR and card acquiring with merchant settlement batches. The merchant payout arithmetic is a conservation identity: what was collected, less the disclosed discount, equals what is paid.

Every movement is idempotent

A replayed purchase returns the original outcome marked already-processed. A provider rejection auto-reverses and the customer is told it was refunded — the interface never renders a confirmation for money that came back.