Core Modules of an EMI Platform

An electronic money institution platform is not a single program but a set of modules, each responsible for one part of holding and moving electronic money, connected through a single ledger. Understanding those modules — what each must do and how they depend on one another — is what separates evaluating a platform on its features from evaluating it on whether it can run a regulated payment business.

This article sets out the core modules of an EMI platform at the level of capability and control rather than implementation. It builds on what e-money platform software is and looks more closely at the parts an issuer commissions, integrates and must stand behind. Each module is described by what it owns, what it depends on, and the question a regulated issuer should ask when assessing it.

A Platform Built from Modules

An EMI platform is assembled from modules that each own a single responsibility and connect through one authoritative ledger. The accounts module holds value; the payments module moves it; card issuance extends spending; funding and redemption connect to banking rails; onboarding and screening decide who may hold an account; and administration, audit and reporting make the whole demonstrable. None of these stands alone — a payment is only correct if it posts to the ledger, and a balance is only trustworthy if it reconciles to safeguarded funds.

Distinguishing the modules matters because it turns a vague notion of a platform into a set of responsibilities an issuer can commission, integrate, replace and audit independently. It also clarifies ownership: which modules a firm runs itself, which it obtains from regulated third parties, and where the boundaries of its own control lie. The table below maps each core module to the question a regulated issuer should ask when evaluating it.

Accounts, Wallets and Balances

The accounts module is where electronic money is held. It records how much each customer holds and in which currency, and makes that balance available to every other module that needs it. Two ideas matter here. The first is that a customer's spendable balance and the ledger's record of it are related but not identical: the balance is a view, and the record is what the issuer reconciles and stands behind. The second is that holding value is not the same as lending it — an EMI records issued value that must remain matched by safeguarded funds, so the accounts module carries a constraint a bank's deposit system does not.

A capable accounts module supports multiple currencies where the licence allows, exposes balances consistently to payments, cards and reporting, and never lets a balance change without a corresponding ledger entry. When assessing it, the question is not how many account types it offers but whether every balance it shows can be traced to the ledger and redeemed.

Payments and Transfers

The payments module moves value: between customers of the same issuer as internal book transfers, and outward to external payment rails when money leaves the platform. Internally, a transfer is a movement between two balances that must post to the ledger as balanced entries; externally, the platform hands off to banking or scheme rails and must record the instruction, its state and its settlement.

The discipline that matters is ordering and idempotency — movements must post in sequence and exactly once, because a payment counted twice or lost is a safeguarding and reconciliation failure, not merely a customer-service one. A payments module is judged less on the variety of payment types it advertises than on whether every movement is recorded accurately, can be traced end to end, and reconciles against what left or entered the institution. Payment types and limits are configured according to the issuer's licence and risk appetite rather than assumed.

Card Issuance and the Regulated Roles

Card issuance extends spending to virtual and physical cards, but it is the module where the software does the least on its own. Issuing cards depends on regulated roles that sit outside the platform: an issuer, a BIN sponsor and a processor, each with obligations the software supports but does not replace. The platform's part is to authorise transactions against the customer's balance, post them to the ledger, and expose card controls and limits; the scheme connection, settlement and card production belong to the regulated roles.

This division matters for both control and honesty: an issuer should be clear about which roles it holds, which it obtains from partners, and where liability and settlement rest. The evaluation question is therefore not whether cards are possible, but which regulated roles stand behind the cards and who holds them.

Funding, Redemption and Reconciliation

The funding module connects the platform to banking rails so customers can add money and withdraw it, and it is where the defining constraint of electronic money is enforced: issued value must correspond to money actually received, and must be redeemable at par on demand. Every inbound funding event has to be attributed to the right customer and posted to the ledger; every redemption reduces issued value and returns funds.

This is also where safeguarding meets engineering. Customer funds are kept separate from the institution's own money and reconciled to the electronic money in issue, and the platform must produce the records that evidence it — a discipline made more prescriptive by the strengthened UK safeguarding rules that took effect in 2026, which expect more frequent reconciliation and regular safeguarding reporting. Making that demonstrable is part of regulatory readiness for an EMI. We do not provide legal opinions or guarantee authorisation. We implement regulatory and audit requirements across technology, infrastructure and operations. Registration under the money-laundering rules is not, by itself, authorisation to issue electronic money or hold client funds.

Onboarding, Identity and Screening

Before a customer can hold electronic money, the platform must establish who they are and whether they may be onboarded — the responsibility of the onboarding module. It combines identity verification with financial-crime screening: identity verification confirms the person is who they claim to be, and financial-crime screening checks them against sanctions, politically exposed person and adverse-media sources. Together these gate account opening, so that value is only ever held by customers the issuer has verified and screened. The module's job is to make the outcome automated and evidenced: a clear result the platform can act on and retain, rather than a manual queue. Screening does not end at onboarding; customers are re-screened periodically because circumstances change over time. When evaluating this module, the questions are whether verification and screening happen before value is held, whether results are retained as evidence, and whether ongoing screening is built in rather than bolted on.

Administration, Audit and Reporting

The final core module is the one that makes the platform operable and demonstrable: administration, audit and reporting — the back office. Administration is where staff act on accounts and payments under defined roles and permissions, so that authority is granted deliberately and every privileged action is attributable. Audit logging records what happened — who did what, when, and to which record — as evidence a supervisor or auditor can rely on. Reporting draws its figures from the ledger rather than assembling them by hand, so that safeguarding, regulatory and management reporting all reconcile to the same authoritative source. For a regulated issuer this module is not administrative overhead; it is where control and evidence live. A platform that can move money quickly but cannot show who did what, or whose reports diverge from its ledger, fails the test that matters most to a supervisor. The question to ask is whether the platform can evidence its own operation.

Summary and Next Steps

The core modules of an EMI platform — accounts, payments, card issuance, funding and redemption, onboarding and screening, and administration, audit and reporting — are not a feature list but a set of responsibilities that all resolve through a single ledger. Each can be commissioned, integrated and audited on its own, but none is correct in isolation: a payment is only right if it posts to the ledger, a balance only trustworthy if it reconciles to safeguarded funds, an account only openable once screening has cleared it.

The practical next step is to describe the modules a firm's licence and customers actually require, then assess any platform module by module against that description — including which regulated roles sit behind cards and funding, and who controls the deployment — rather than against a feature list. Judged that way, an EMI platform is measured by whether its modules, together, let a regulated issuer hold value accurately, move it safely and evidence every balance it shows. Deciding which modules to build, license or obtain from partners is itself an architecture decision, and one worth taking independent advice on.