Every Wallet Is Different, and That's the Point
We have been helping fintechs, financial institutions and even banks launch their digital wallets. Every client has a different need: the geography, the target market (retail or corporate or both), the budget they have planned and even the timeline by when they want to launch. There is a baseline recipe that is the same for all: peer to peer payments, KYC checks, AML policies, accounting ledgers, customer journeys. But that is still just a fifth of a mature digital wallet, about 20% of what goes into a wallet. The rest 80% varies according to each client's need, the licenses they hold, and the compliance and regulations in the jurisdiction they wish to operate in, and it is here that most of the time and cost is spent.
So if you are building a wallet right now, or in the middle of planning one, some of the questions you are asking would be:
- How can I control time and costs without compromising on essential features?
- What features do my users really require and what can wait?
- What does a genuine MVP look like?
- What kind of licensing do I require before I even start? What do I require for MVP? And finally what would I need for a full-fledged wallet ecosystem?
- What does compliance look like on day zero, what does it look like at MVP, and what would be needed for the full system eventually?
- Do I need an expensive eKYC service from a provider or can I make do with my own module?
- Should I obtain all licenses and prerequisites myself, or would it make more sense to use an underlying service provider when going global?
A recent example stands out. A mid-sized financial institution wanted to launch a digital wallet. During our discovery sessions we worked with the client team to determine answers to these questions, which in turn helped us understand their immediate, actual need. We discovered that they wanted to launch domestically, aimed at locals, focused more on retail, and that they had a limited budget and a tighter deadline.
So just like a racing team would remove non-essential parts to make a car faster and lighter, we went about trimming non-essential features to outline the MVP for phase one. Multi-currency rollouts, FX trading, cards and even eKYC from a third-party vendor were ruled out for MVP. Eventually the MVP was a closed-loop wallet system with a built-in KYC module, which helped them launch within the intended time and budget. With the MVP live and the customer base building rapidly, the client now has better bandwidth for expansion, which is where our next phase begins.
What then should your wallet look like? Let us look at some of the essential features of a digital wallet and examine whether you need to build them in the first iteration, or whether there is a way to build minimally and increment in phases.
Core Ledger and Account Structure
What it is
The system of record for every balance, transaction and movement of value inside the wallet. This is the one feature with no MVP shortcut worth taking.
Full scope
A double-entry ledger with multi-currency support, immutable transaction records, real-time reconciliation, and account structures for customers, merchants and any intermediary roles like agents.
MVP version
Still a proper double-entry ledger, single-currency or dual-currency if the market genuinely needs it, but with simpler account structures if the initial user base doesn't yet require merchant or agent roles.
What this is not the place to cut. Transaction integrity, idempotency and reconciliation logic should never be simplified to save time. This is the layer everything else (compliance reporting, customer trust, audit response) depends on. Perhaps one of the most tedious and toughest reporting obligations is the compliance and audit requirement mandated by the Bank of Lithuania under the e-money license it provides. An existing client who holds this license wanted to ensure they were 100% compliant, because the margin for error was literally zero. This is why we implemented reconciliation, safeguarding, audit reports and AML reporting from day zero rather than retrofitting later. You can see a comparable build in our multi-currency digital wallet case study.
Licensing and Regulatory Prerequisites
What it is
The authorizations that determine what your wallet is legally allowed to do, and often the single biggest factor in your actual timeline.
Why it gates everything else
Depending on jurisdiction, this typically means some combination of a payment service provider license, an e-money license, and access to a regulatory sandbox to pilot the product under supervision. These aren't paperwork that happens after the build. They shape how customer funds are safeguarded, what your AML program has to include, and in some cases what technology and hosting choices are even permitted.
MVP version
For a domestic-only launch, this usually means securing the narrowest license that covers your actual use case, rather than a broader license "in case you need it later." A tightly scoped license application is also typically faster to secure. For a global launch, identifying licensed providers that can supply the underlying regulatory footing (allowing you to launch a customized wallet as a wrapper around it) makes more sense for the MVP.
The practical takeaway. Licensing status should be confirmed, or actively in progress with qualified local counsel, before scope and architecture are locked. A wallet designed ahead of its actual licensing reality is a wallet that ends up partly rebuilt once the real ruleset is confirmed.
eKYC and KYB
What it is
The onboarding, identity verification and business-verification workflow that determines who's allowed to hold and use a wallet.
Full scope
A dedicated verification module covering document capture, OCR, biometric and liveness checks, government ID API integration where available, and structured KYB workflows for merchants and agents.
What to build versus buy. Own the onboarding journey, the verification rules, risk classification, manual review workflow and audit trail of every decision. Buy the specialist, regulated pieces: document authenticity checks, biometric matching, liveness detection, sanctions and PEP data. We've integrated third-party identity and screening tools including Ondato for automated KYC and Salv for AML case management on prior wallet and fintech engagements, precisely because those categories of verification depend on regulated data sources that aren't worth rebuilding from scratch. Our eKYC and onboarding article goes deeper on that architecture.
MVP version. In one European wallet build, the initial market was limited to the client's home country. Rather than licensing a broad pan-European identity verification platform from day one, we built the onboarding and decisioning workflow in-house (designed around the client's GDPR obligations on data minimization, consent and retention) and connected a single verification provider scoped to that one market. Broader coverage could be added later if the wallet expanded. The point wasn't avoiding third-party tools altogether; it was not paying for geographic coverage the launch didn't need yet.
AML and Transaction Monitoring
What it is
Sanctions and PEP screening, transaction monitoring rules, velocity and value limits, alert investigation, and the audit trail a regulator will eventually ask to see.
Why it can't wait
Even a small, domestic, single-market wallet carries real AML exposure: identity fraud, structuring, agent collusion in cash-heavy models, and the risk of a sanctioned party attempting to transact. A licensed operator is generally expected to have customer and merchant risk classification, screening, monitoring rules and case escalation from the day the wallet goes live, not from the day it goes international.
MVP version
The sophistication of the rules can scale with volume: more granular risk scoring, more automated triage, broader behavioral monitoring as the business grows. What doesn't scale later is whether the control framework existed at all from launch. Retrofitting monitoring and audit trails onto a live wallet with real transaction history is materially harder, and more expensive, than designing them in from the start.
A regulatory note worth flagging early. Operational resilience expectations under frameworks like DORA in the EU reinforce why AML and monitoring infrastructure shouldn't sit entirely with a single external provider. Incident traceability and recovery arrangements matter here just as much as the screening rules themselves.
Multi-Currency, FX and FX Trading
What it is
The ability to hold balances in more than one currency, convert between them, and in some builds, let users actively trade on currency or asset price movements within the wallet itself.
Full scope
We've built wallets with full multi-currency balances, configurable FX rate management, and in some cases FX or gold trading functionality that lets users benefit directly from price movement, not just hold and convert.
Our crypto and gold trading platform case study is an example of a wallet-adjacent build where trading functionality, not just custody, was core to the product.
MVP version, and where it earns its place. This is a feature where the temptation to include it "because competitors have it" is strong, and where discipline pays off. Most wallets that genuinely need multi-currency use cases are well served by established providers such as Currency Cloud, which we have used in almost every instance. If your use case requires multi-currency, using a global provider exponentially increases reach while keeping the integration straightforward. If your wallet is restricted to one currency, the entire currency module can be skipped in favor of a simpler wallet, exactly as in the case described earlier.
Payment Cards: Closed-Loop Credentials vs Scheme-Branded Cards
What it is
How wallet users actually spend their balance outside the wallet's own merchant network.
The distinction that matters most
A closed-loop digital payment credential, usable only within your own wallet ecosystem, is a genuinely different product from an open-loop Visa or Mastercard virtual card that works anywhere those networks are accepted. A closed-loop credential can usually be built as part of the core platform. A scheme-branded card requires an issuer or BIN sponsor, a card processor (Thredd is a well-known example of this category of infrastructure), participation in the scheme's own compliance regime, card lifecycle management and PCI-aligned handling of card data.
MVP version
Launch with closed-loop credentials for in-network payments if your initial use case doesn't require external card acceptance. This avoids the issuer, processor and scheme relationships entirely for phase one.
Full scope
Scheme-branded virtual or physical cards, layered on once the wallet has an issuing and processing relationship in place, typically alongside the international expansion work described below.
Why the terminology matters commercially. If a roadmap says "add virtual cards" without specifying which of these two it means, the cost and partner dependencies attached to that line item can be ten times apart. Getting this distinction right early avoids a very expensive surprise later.
Cross-Border and International Expansion
What it is
Connecting a domestic wallet to international accounts, cross-border FX, and payment rails once the business is ready to serve users beyond its home market.
How to architect for it without rebuilding
The domestic wallet should own its ledger, its identity and compliance decisioning, and its customer experience, with international capability attaching through a defined provider integration layer rather than being woven through the platform. That typically means a licensed payment or e-money institution, a program manager, a BIN sponsor, a card processor and a cross-border FX provider, rather than the wallet operator obtaining every license and building every rail independently.
Provider selection is regional, not global-brand-driven
On a wallet program for a bank in the UAE, the client's existing infrastructure was already built around a well-established regional processor. Network International is a strong example of a processor with deep reach across Middle East banking, precisely because so many banks in that market already run on their infrastructure. A different provider is often the right fit for a European e-money entity or a wallet entering the UK. The right choice depends on geography, supported rails, the settlement model, and just as importantly, the provider's actual willingness to support your target market.
One caution worth building in. Provider appetite for a given market or corridor varies, sometimes significantly, based on sanctions exposure, banking-access constraints or compliance complexity in that specific geography. Confirming a provider's real appetite for your market, in writing, before committing to an expansion route, avoids designing an architecture that's ready for a partner who may not actually say yes.
What partnership does and doesn't remove. A regulated infrastructure partner reduces the need to build and license every component independently. It doesn't eliminate the wallet operator's own contractual, operational and customer-protection obligations, which are shaped by the specific program and jurisdictions involved. Our multi-bank middleware and reconciliation engine shows how that provider layer is typically structured.
Crypto Wallet Extensions
What it is
Adding digital asset custody or trading functionality alongside an existing fiat wallet, rather than building a crypto-only product.
Where this comes up
Several of our fiat wallet builds have later extended to include a crypto wallet component, letting the same user base hold or trade digital assets alongside fiat balances, rather than requiring a separate app or account.
What actually changes when crypto is added
This isn't a simple feature toggle. It introduces its own custody, security and, in the EU, regulatory considerations. If the roadmap eventually extends into crypto-assets or tokenized value, frameworks like the EU's MiCA regime may become relevant to that specific layer of the product. It's worth treating as a distinct expansion decision with its own compliance review, rather than assuming it's automatically covered by the fiat wallet's existing licensing and architecture.
MVP implication
If crypto isn't part of your launch requirement, it's a clean candidate for deferral, provided the core ledger and account architecture aren't designed in a way that makes adding it later structurally difficult.
Lessons From Building Wallet Platforms in Regulated Markets
Regulatory requirements rarely stay confined to compliance documentation. They shape the ledger, the identity workflows, the data architecture, the access controls, the provider integrations, and the operational processes around a wallet. Our experience spans wallet and fintech platforms across European and Middle Eastern markets, including environments governed by GDPR, DORA and Bank of Lithuania e-money supervision in Europe, and UAE payment and banking regulation in the Gulf. Across all of them, the pattern holds: establishing the regulatory operating model before locking the platform architecture, even for a deliberately scoped MVP, is what avoids expensive rework later. The same principle runs through our work on legacy modernization in regulated financial services.
Who Should You Choose to Build Your Wallet?
At the very least, you need a technology partner with real domain knowledge across banking, finance, payments, and the regulatory landscape around them. Banking and finance applications are complex and heavily regulated by nature, and you want a partner who can navigate that terrain with you, not one who's learning it on your project. A digital wallet doesn't run purely on your own logic and your own defined rules. It also depends on third-party services, and it must hold up under real regulatory scrutiny. So the partner you choose needs to be able to build something robust, scalable and secure with all of that factored in from the start, not patched in after the fact. Our 7-point partner selection checklist sets out how to test that in discovery.
At Kanad, we've been fortunate to build digital wallet and payment solutions across multiple jurisdictions, including the EU, the UK and the Middle East. We've worked with traditional banks, digital and neo banks, financial institutions and fintech companies to help them bring their payment systems to life. Whether the goal is an MVP or the whole ecosystem right from the word go, we build wallets and payment systems tailored to your exact requirements, timeline and budget, without cutting corners. Our engagement models set out how those programs are structured.
Request a Technical Review
If you're currently scoping a digital wallet build and trying to work out what belongs in phase one, what to defer, and what it should realistically cost, we'd be happy to walk through it with you.
No obligation. No sales pressure. Just a practical, feature-by-feature conversation.