E-Money Platform Software
E-Money and Payments Infrastructure
Accounts, balances, double-entry ledger, vIBAN, cards, payments, AML/KYC and back office are engineered as one financial system rather than disconnected products — infrastructure for electronic money and payment institutions in the United Kingdom and the European Union.
The Customer Problem
The Product Is the Ledger
Wallet screens and cards are the visible surface of an e-money business. The operating weight sits underneath: correct balances, double-entry records, reconciliation against banks and processors, safeguarding data and the audit trails a supervisor expects to see.
Platforms assembled from disconnected products fail quietly. Balances are edited rather than posted, provider statements never fully reconcile, and the gaps surface during authorisation work, a safeguarding review or an incident.
Grumpio treats the platform as one financial system. An established modular foundation is customised to the institution's brand, licence model and providers while deployment and regulatory-readiness work progress in parallel: one delivery plan, one point of responsibility.
Module Scope
One Platform. Every Payment Layer.
The modules below operate within one architecture, drawing on the same double-entry ledger and back office rather than running as disconnected products. Scope is configured per project around the institution's licence, market and provider agreements; capability is always distinguished from authorisation and third-party dependencies.
Accounts and balances
Customer and company accounts with pending and available balances, holds and a controlled transaction lifecycle across multiple currencies.
Double-entry ledger
Financial movements are maintained through double-entry posting and auditable transaction history rather than mutable balance fields; reconciliation data is produced by the system.
vIBAN and bank transfers
vIBAN allocation, inbound transfer matching, outbound requests, beneficiaries and webhooks. Live scope depends on the customer's banking and vIBAN-provider agreements.
Card programme integration
Virtual and physical card lifecycle, authorisation-event processing, ledger movements, limits and freeze controls. Grumpio does not issue or print cards; regulated schemes, issuers and processors do.
Fiat and crypto funding
Funding through bank transfer, vIBAN and provider-supported methods. Crypto deposits with wallet-risk screening and conversion are available where the licence and card programme permit.
P2P transfers
Internal transfers with recipient resolution, ledger posting, fees, limits, risk controls and notifications.
Bill and service payments
A payments module for bills and services. Live coverage depends on the local aggregator or bill-payment provider and its commercial agreements.
Virtual POS and merchants
Merchant onboarding, payment links, refunds, settlement and reporting. Merchant acquiring depends on the customer's licence, acquirer and processor arrangements.
Reconciliation
Bank, vIBAN, card-processor, merchant and ledger reconciliation with exception handling and daily and period reporting.
Safeguarding
Safeguarding Starts in the Ledger
The e-money platform supports the ledger, reconciliation, records and operating workflows required to implement the customer's safeguarding model. The safeguarding method and account arrangements remain the institution's own; the platform's task is to make them operable and evidenced.
- Relevant-funds records: identification and classification data for the funds the safeguarding model covers.
- Reconciliation: bank and safeguarding-account reconciliation with exception workflows and period reporting.
- Reporting data: structured outputs for safeguarding returns, audit work and resolution evidence.
- Permissions and approvals: role-based control over fund operations, with audit trails behind administrative actions.
Technical Structure
Engineered for Production Operations
The platform is designed for high availability, horizontal scale and observability. The engineering approach — data and event architecture, deployment and security — is described on the technology page.
Review the technical scope-
Fees and limits engine
Transaction fees, customer segments and daily, monthly, card and transfer limits are administered centrally rather than hard-coded across modules.
-
Back office and permissions
Customers, accounts, balances, transfers, cards, merchants, reconciliation and reporting are administered through role-based permissions, with administrator activity recorded in audit history.
-
AML/KYC and screening workflows
Onboarding, ongoing screening and wallet-risk checks are integrated through AML screening and KYC verification — delivered by Legichain or customer-selected providers — with results stored for audit.
-
Web, iOS and Android applications
Customer applications and the administrative back office are customised to the institution's brand and module scope across web and mobile.
-
Standards-aligned engineering
An ISO 27001-aligned security approach, an ISO 22301-aligned business-continuity approach and card integrations designed around applicable PCI DSS requirements are part of the delivery model.
Regulatory Context
Two Markets. Two Frameworks.
The e-money and payment modules are structured around the relevant FCA, safeguarding, AML and information-system requirements, and delivery includes a jurisdiction-specific readiness programme rather than a generic checklist.
Platform capability is distinct from authorisation: licence type, safeguarding method and provider arrangements follow the customer's own regulatory model.
Assess your readiness-
United Kingdom
Implementation is planned around the FCA's payment services and electronic money framework, the enhanced safeguarding rules that have applied since May 2026 and the operational-resilience expectations placed on in-scope institutions.
-
European Union
The current PSD2 and EMD2 framework, strong customer authentication and DORA are treated as live operating requirements, with the incoming PSD3 and PSR package monitored as it is finalised. The e-money platform is adapted to the customer's home-state licence, safeguarding model, payment rails and card-programme structure.
Deployment
Customer-Specific Deployment
The platform is not locked to one cloud provider. Deployment follows the customer's regulatory, data-residency, cost and operating requirements, and environments can be installed on-premises, in a private cloud, with a preferred provider or in a dedicated data centre; installation, logging and backup are configured as part of the project.
On-premises and dedicated
Installation on customer-selected servers or dedicated infrastructure, with data flows, retention and access configured around the operating model.
Private and public cloud
Deployment with the preferred cloud provider, delivered with environment separation, secrets management and security configuration.
DevOps and handover
Container-based deployment, CI/CD, logging, backup and technical-team handover training are provided as part of the installation.
Commercial Model
White-Label and Source-Code Options
The same platform is delivered through two models, chosen around internal engineering capacity, data residency, intellectual-property expectations and the support model. White-label customers retain a contractual option to acquire the source code under defined commercial terms, and final rights in either model are contractual.
| Scope | White-Label | Source-Code Enterprise |
|---|---|---|
| Starting model | Launch from the established platform under a monthly or annual licence | Source code delivered under a licence granted to a named legal entity |
| Customisation | Brand identity, module selection, fee and limit configuration, integrations | Full source-code access for internal development; independent resale is not permitted |
| Data and hosting | Customer-controlled infrastructure where legally and technically appropriate | Customer-selected servers, data centre or cloud provider |
| Delivery contents | Installation, training, ongoing support and updates | Source code, deployment assets, technical documentation, handover training |
| Transition | Option to acquire source code under defined commercial terms | Transferable with the sale of the legal entity where the contract permits |
Integrations
Integration Categories
The platform connects to the institution's current and planned provider ecosystem. Integration scope is defined per project by provider agreements and technical assessment.
- Banking and cards: integration capability for banks, vIBAN providers, Visa, Mastercard, issuer/BIN sponsors and card-processing providers.
- Payment rails: bank transfer and vIBAN flows, multi-currency support and, in the EU, SEPA and instant-payment integration where available.
- KYC and AML providers: Legichain or customer-selected providers; multi-provider use and provider switching are supported.
- Bill-payment aggregators: local aggregators and service networks where the product includes bill and service payments.
- Notification and operations tools: email, SMS and operational monitoring systems.
FAQ
Frequently Asked Questions
The platform combines customer accounts and balances, a double-entry ledger, vIBAN and bank transfers, card-programme integration, fiat and crypto funding, P2P transfers, bill and service payments, virtual POS and merchant management, reconciliation, a fees and limits engine, back office and web, iOS and Android applications. Module scope is configured per project and licence model.
No. Cards are provided through card schemes, issuer and BIN sponsors, card-processing providers and card-fulfilment providers. Grumpio engineers the card-programme integration: virtual and physical card lifecycle, authorisation-event processing, ledger posting, limits, freeze and unfreeze controls, settlement and reconciliation.
The e-money platform supports the ledger, reconciliation, records and operating workflows required to implement the customer's safeguarding model. It maintains relevant-funds records, produces reconciliation and exception data and generates audit trails and reporting outputs. The safeguarding method and account arrangements remain the responsibility of the regulated institution.
In the white-label model, the established platform is customised to the customer's brand, module selection, fee structure and integrations and operated under a licence. In the source-code enterprise model, source code, deployment assets, technical documentation and handover training are delivered under a licence granted to a named legal entity; independent resale is not permitted.
Crypto funding exists as a technical capability: crypto deposits, wallet-risk screening, conversion where permitted and posting to the fiat balance. It is not automatically permissible under every licence or card programme, so the funding model is assessed against the customer's authorisation and provider arrangements before it is enabled.
Deployment follows the customer's regulatory, data-residency and operating requirements. The platform can be installed on-premises, in a private cloud, with a preferred cloud provider or in a dedicated data centre. Installation, CI/CD, logging and backup are configured as part of the project.
Next Step
The Platform Is Shown, Not Described
A product demonstration covers the module scope, the ledger and reconciliation model and the delivery options. Scope questions are answered on a working system.