Solutions

Seven products. One platform underneath.

Each solution below is a configuration of the same CMS, wallet, ledger and settlement engine — which is why you can launch one this quarter and add another without a second integration.

3.1 · Card Issuing

Your first card programme, without a card platform team.

For fintechs that have the licence and the sponsorship, and now need something customers can hold. Debit on a linked account, prepaid on a funded wallet, or companion cards hanging off a parent — all three run on the same product definitions.

  • Debit cards. Spend against a live wallet balance with real-time authorisation.
  • Prepaid cards. Load, spend, reload — with expiry, dormancy and fee rules per product.
  • Companion cards. Additional cards on one wallet, each with independent limits and MCC rules.
  • Virtual-first issuance. Issue instantly in-app, post the plastic later — or never.
Typical buyerNewly licensed EMI or PI with no card product live
What you bringLicence, BIN sponsor, processor, card bureau
What NDDEO bringsCMS, wallet, ledger, console, APIs
Time to first cardWeeks, once sponsor and processor connectivity is in place
3.2 · Payroll Cards

Pay people who do not have a bank account.

Payroll providers lose margin every time a payout has to route through a third party. Issuing your own wage card turns that cost line into a product line — and gives the employer a reconciliation view they currently do not have.

  • Bulk disbursement. One payroll file loads thousands of cards, with per-employee confirmation.
  • Earned-wage access. Partial early draws posted as holds against the next payroll run.
  • Employer sub-tenancy. Each employer sees only its own workforce, with its own approvers.
  • Spend controls. MCC and ATM rules where the programme or regulator requires them.
This is the shape of programme run by providers such as Dopay and Eazipay — pay-to-card for workforces that payroll cannot reach through a bank account.
Typical buyerPayroll, EOR, staffing and earned-wage-access providers
Core needPaying unbanked or under-banked workers on time
Key modulesCMS + wallet + bulk load + settlement
ReconciliationPer payroll run, per employer, per worker
Related industryPayroll providers →
3.3 · Corporate Expense

Company money, spent inside the rules.

Expense programmes live or die on control. The finance team needs to know that a card cannot be used where it should not be — before the transaction, not in next month's report.

MCC restrictions

Allow travel and fuel, block gambling and cash. Defined per card, per department or per whole programme, and enforced at authorisation.

Budget controls

Monthly ceilings per card and per cost centre, with automatic decline on breach and a clear reason code back to the employee.

Department cards

A corporate wallet with sub-wallets per team, each funded, capped and reported separately but settling to one account.

Approval workflow

Raising a limit or unblocking a card needs a second approver — the same maker-checker flow that protects your own operations.

Virtual cards per vendor

One card per supplier or subscription, locked to a merchant and an amount, closed the moment the contract ends.

Finance-ready export

Transactions tagged by cost centre and category, exported for the accounting system rather than retyped from statements.

3.4 · Multi-Currency Wallets

Four currencies, one customer, no conversion surprises.

A customer holding EUR, USD, AED and INR is not four customers with four balances. They are one relationship with four pockets, one set of limits and one statement — and FX that is visible rather than buried in the rate.

  • EUR euro-area spend and SEPA funding
  • USD the default corridor currency
  • AED GCC salary and everyday spend
  • INR remittance receive side and local spend
Because FX is posted as a pair of ledger entries with a recorded rate and margin, you can price transparently and still see exactly what the programme earns.
Wallet — Priya S. (Dubai → Kochi) ├─ AED 8,400.00 [salary in] ├─ INR 96,250.00 [family transfer] ├─ USD 640.00 [online spend] └─ EUR 120.50 [travel] FX AED → INR rate 22.68 margin 0.45% posted as two entries, both auditable

Use-case-led: the wallet mirrors how the customer actually lives

3.5 · Remittance & MSB

Stop losing the customer at the receive side.

A transfer that ends in a cash pick-up ends the relationship. A transfer that lands in a wallet with a card attached keeps the balance, the data and the next transaction — without changing your corridor or your licence.

  • Receive-side wallets. The recipient gets a balance and a card, not a collection code.
  • Corridor-aware ledgers. Segregated balances per currency and per corridor, reconciled centrally.
  • FX transparency. Rate and margin recorded on every conversion, for pricing and for audit.
  • MSB-grade controls. Velocity limits, sanctions-screening hooks and a complete audit trail.
The pattern is familiar to wallet-led operators such as Treasure Global (Oxi Wallet / ZCITY): the wallet, not the transfer, is the product.
Typical buyerMSBs, FX businesses and cross-border payment firms
Problem solvedOne-off transfers with no retained balance or data
Key modulesWallet + ledger + CMS + settlement
Regulatory noteYour MSB or PI permissions stay yours; NDDEO is the technology layer
Related industryRemittance companies →
3.6 · Travel Cards

Load before you fly. Spend without the markup.

A travel card is a multi-currency wallet with a plastic front end and tighter rules. The platform already has the hard parts — you choose the corridors and the pricing.

FX wallets

Lock a rate by loading the destination currency in advance, or let the card convert at point of sale with a rate you control.

Multi-currency balances

Several destination currencies held at once, with a defined fallback pocket when the customer spends somewhere unplanned.

Spending abroad

Geographic and channel rules, ATM caps, and instant freeze from the app — the controls travellers actually ask for.

Travel and remittance programmes share the same wallet model. Launching one makes the other a configuration exercise rather than a new project.
3.7 · Embedded Finance

Put cards and wallets inside someone else's product.

If your customers are businesses that want to offer payments to their users, you need a platform that can be sub-tenanted, branded per client and reported per client — without giving anyone a view of anyone else's data.

  • BaaS platforms. Resell card and wallet capability to your own downstream clients.
  • Neobanks. Ship account, card and wallet features without building a card team.
  • Marketplaces. Seller wallets, payout cards and split settlement across a two-sided platform.
  • Per-client branding. Each sub-tenant sees its own console, its own card art, its own reports.
How neobanks use this
Tenancy modelTenant → sub-tenant → programme → product, isolated at every level
BrandingPer sub-tenant — console, card art, statements, notifications
ReportingRolled up for you, scoped down for each client
CommercialsYour pricing to your clients; ours to you. We never contract past you.
IntegrationOne API surface, tenant resolved from the credential
Not sure where to start

Most programmes begin with one of three.

Pick the one closest to your business and we will show you that configuration specifically, not a generic tour.

Next step

See the platform on your own programme.

A 45-minute architecture review: your licence, your BIN sponsor, your processor — and exactly what NDDEO would run on top.