Nine capabilities, one tenant, one audit trail. Card management, wallets, ledger, compliance controls, settlement, developer tooling, a real sandbox and the security posture your regulator will ask about.
Each layer has a clear owner. That is what lets you change one without rebuilding the others — swap a processor, add a BIN, enter a new market, keep the same product.
A new card product, currency pocket or fee rule is a console change. Engineering time goes to your app, not to the platform.
Start with the CMS alone, add wallets when you need pockets, add settlement when volume makes manual recon painful.
Every action across every module lands in a single immutable log — which is what an auditor actually asks to see.
Everything that happens to a card between manufacture and closure — run by your operations team in your console, or driven entirely by API from your app.
Most platforms give a customer one balance. Real products need a parent and its children, a business and its departments, a traveller and four currencies — each with its own rules, all reconciling to one place.
One customer · four currencies · three cards · one reconciled ledger
Every authorisation, settlement, fee, reversal and transfer is a double-entry posting. That is the difference between a product you can audit and one you have to explain.
Client money, scheme settlement, fee income and suspense are separate accounts — the structure safeguarding rules expect.
Available and cleared balances update as authorisations land, so your app never shows a figure the card will not honour.
Pre-authorisations, tips, fuel holds and expiries are modelled explicitly, with automatic release on timeout.
Issuance, monthly, FX, ATM, decline and inactivity fees defined per product and posted as first-class entries.
Queryable per card, wallet, pocket or programme — with the original scheme message retained against each entry.
FX is a posting pair with a recorded rate and margin, so revenue and customer cost are never conflated.
Compliance features are not a module you buy later. They are how the console behaves from the first day, because retrofitting them after an audit finding is expensive.
Card programmes rarely fail on issuance. They fail when nobody can explain a 40-cent difference between the scheme file, the processor report and the bank statement.
Scheme clearing files, processor reports and bank statements are pulled in on schedule and normalised.
NIGHTLY / T+1Entries are matched against the ledger by scheme reference, amount and date, with tolerance rules you set.
AUTOMATEDOnly the breaks reach a human — in a worklist with the evidence attached, not a spreadsheet.
OPS REVIEWFees are calculated, positions posted, and settlement reports generated for finance and the regulator.
SAME DAYDocumentation, SDKs, webhooks and integration guides in one place — so integration is a sprint, not a project with a weekly sync.
Every endpoint with request and response examples, error codes and idempotency rules.
Client libraries for the common server stacks, so you are not hand-rolling HTTP and retries.
Signed, retried event delivery for authorisations, settlements, card state and approvals.
Step-by-step paths for the common programmes, from first API key to first live card.
Most sandboxes let you create a card and check a balance. Ours simulates the processor, so you can test a partial reversal at 2am before a real customer finds it. This is one of the clearest differences between NDDEO and the alternatives.
Your sponsor bank and your regulator will both send a questionnaire. These are the answers, stated plainly.
The platform is built to PCI-DSS control expectations: cardholder data is tokenised, PAN is never exposed to your application, and access to the card data environment is segregated and logged.
Data minimisation, purpose limitation, retention rules and subject-access export are built into the data model rather than handled by ticket.
Strong customer authentication flows, exemption handling and the transaction-data transparency PSD2 expects of an issuer-side platform.
TLS in transit, encryption at rest, encrypted settlement file exchange and key management separated from application access.
Each client is a hard-isolated tenant. No shared ledgers, no shared card data, no cross-tenant query path — by construction, not by filter.
Architecture diagrams, data-flow maps, control descriptions and audit-log samples for your due-diligence pack.
A 45-minute architecture review: your licence, your BIN sponsor, your processor — and exactly what NDDEO would run on top.
