Before the RFP: Business Analysis for Digital Wallet Projects
Share the page:
Most digital wallet projects are specified as a feature list: tap to pay, send money, see a balance. The hard requirements sit underneath: a ledger that reconciles to the cent, token handling that keeps card data out of your systems, and a regulatory classification that decides whether you register with the Bank of Canada or FINTRAC before launch. Worldpay's 2026 Global Payments Report puts digital wallets at 56% of global online spending in 2025, so the question is what to specify before a vendor prices one. This guide covers the digital wallet requirements that belong in your RFP, the Canadian rules that shape them, and the business case numbers to settle first. For product, payments, and IT leaders with budget approval and no spec yet.
Introduction
The wallet RFP we see most often runs about eleven pages. Nine of them describe screens. The remaining two ask the vendor to confirm that the product will be "secure, compliant, and scalable," which every vendor confirms, because the sentence costs nothing to agree with.
You probably arrived here because a vendor, a lawyer, or your own finance team asked a question the RFP could not answer. Who holds the customer's money overnight. What the balance shows while a top-up is pending. Whether the thing you are building makes you a payment service provider. Those are not development questions. They are analysis questions, and the order matters: the answers shape the vendor list, the timeline, and the budget, so they have to exist before the RFP goes out rather than after the contract is signed.
Why do digital wallet projects stall before a vendor is chosen?
They stall because the sponsor writes the RFP as a list of features, and features are the only part of a wallet that is easy. Worldpay's 2026 Global Payments Report, based on a survey of more than 63,000 consumers across 42 markets, found that digital wallets accounted for 56% of global online spending and 33% of in-person spending in 2025. The interface pattern is settled. Every vendor can build the balance screen and the tap-to-pay flow, and most of them have. What they cannot do is make three decisions that belong to you.
The first is loop type. A closed-loop wallet holds value that can only be spent with you, like a coffee chain's app or a transit card. An open-loop wallet moves money to and from the wider payment system, through a card network, Interac, or bank transfer. The second is funds custody: when a customer loads $50, who legally holds it, you, a partner bank, or a licensed payment service provider? The third is rails: which networks the wallet rides on, which decides the certifications you need and the fees you pay per transaction.
The pattern we see most often is a loyalty operator that wanted stored value to lift repeat purchase, discovered halfway through procurement that holding customer balances made it a payment service provider under the Retail Payment Activities Act, and had to restart the RFP with a partner bank in the architecture. The vendors were not at fault. They had priced the wallet that was described.
If you are at this stage, the earlier guide on the discovery phase of a project covers how to run these decisions as a bounded exercise with an exit gate.
Key Takeaway: Decide loop type, funds custody, and rails before the RFP. A vendor cannot price what you have not decided, and three vendors will price three different wallets.
What belongs in digital wallet requirements that a generic app spec misses?
The money movement model. A wallet is a ledger with a user interface attached, and the ledger is where projects fail. Generic app requirements describe what the user sees. Wallet requirements describe what the balance is at every moment between the user tapping a button and the money arriving, and what the system does when those two things disagree.
Start with the transaction state model. Every payment passes through a sequence of states: initiated, authorized, pending settlement, settled, failed, reversed, disputed. For each state the requirement has to answer four questions. What does the customer's available balance show? What does the ledger balance show? What notification fires, and to whom? What happens if the next state never arrives, which is the timeout rule nobody writes until the first stuck transaction sits in production for three days. The visual below maps the states and the four questions each one must answer.
The state model produces the first half of the checklist. The second half comes from everything around the ledger: identity, limits, fraud, integration, reporting, and access. The table lists the ten areas a wallet requirements document has to cover, the question the RFP must answer in each, and an example of what a testable acceptance criterion looks like.
The failure we see most often is a wallet that launched with a balance screen and no reconciliation requirement, so finance found the gap between the ledger and the processor's settlement file in month two, by hand, in a spreadsheet. ID Business Analysis Canada writes that reconciliation requirement into the BRD during a Requirements Engagement, with the settlement file format, the matching rule, and the exception queue specified before a vendor is shortlisted, because a vendor asked to "support reconciliation" will build whatever is cheapest to call by that name.
Key Takeaway: Every state in the transaction model needs a balance rule, a notification rule, and a timeout. If your requirements describe fewer than seven states, the spec is incomplete and the vendor will fill the gaps for you.
Which Canadian compliance requirements shape the wallet design?
Four regimes decide the architecture before a developer writes a line, and each one turns into requirements rather than a legal footnote. The Retail Payment Activities Act puts payment service providers under Bank of Canada supervision, with registration, safeguarding of end-user funds, an operational risk framework, incident response, and annual reporting; the safeguarding and risk management obligations have been in force since September 8, 2025. The Proceeds of Crime (Money Laundering) and Terrorist Financing Act brings in FINTRAC if the wallet remits or transmits funds, or deals in virtual currency, which triggers registration as a money services business before operations begin, along with identity verification, record keeping, and reporting. PCI DSS applies the moment card data touches an environment you control. Privacy law applies regardless: PIPEDA federally, and Quebec's Law 25 if you have Quebec customers, which for a consumer wallet you will.
Layered on top are the network and program rules. Apple Pay and Google Pay have their own program terms and certification steps. Interac has rules for e-Transfer and debit. Card brands have their own, and the Code of Conduct for the Payment Card Industry in Canada governs how merchants are treated. Accessibility adds a final layer: the Accessible Canada Act for federally regulated organizations and Ontario's AODA for most others, both of which resolve in practice to WCAG conformance in the payment path.
The analysis task is classification, and it belongs in week one of discovery. Is the wallet a payment service provider, a money services business, both, or neither? A closed-loop wallet that only stores value spent with you may sit outside both; the moment it lets one customer send money to another, the answer changes. Each answer adds or removes a partner from the architecture, a registration from the timeline, and a cost line from the budget. A pattern we have seen at credit unions: the team assumed PCI scope was the processor's problem until the design placed card entry on a screen the credit union hosted, which put its entire backend in scope. Moving the entry field to the processor's hosted component took a week in design and would have taken a quarter after launch.
Key Takeaway: Run the regulatory classification in week one. The answer changes the vendor list, the timeline, and the budget, and no vendor will do it for you because none of them carry the liability.
What goes into the digital wallet business case?
Three things: revenue or savings lines you can defend to a CFO, cost lines vendors never quote, and an adoption curve with a floor case. Most wallet business cases arrive with the first and skip the other two.
On the revenue side the candidates depend on loop type. A closed-loop wallet earns on repeat purchase lift, prepaid float while balances sit unspent, and lower card acceptance cost when the top-up is funded by bank transfer rather than card. An open-loop wallet may earn interchange share on a prepaid card program and transaction fees on transfers. Each line needs a mechanism and an owner, not an industry benchmark pasted from a vendor deck.
The costs vendors omit are the ones that continue after go-live: the compliance program itself, including the people who file the reports; fraud losses, which are a cost of doing business rather than a defect; customer support for failed and pending transactions, which is where most wallet support volume comes from; certification cycles with the networks every time you change something material; scheme and processor fees per transaction; and the per-check cost of identity verification, which scales with every account you open whether or not it ever transacts.
Adoption is where the honest work is. A wallet with no reason to be opened twice is a prepaid card with worse economics. Build the floor case, the one where only your most frequent customers adopt it, and check whether the project still clears the hurdle. If the business case only works on the optimistic curve, the business case does not work. The earlier piece on revenue leakage examples covers how to find the process gaps that usually hide inside the "savings" line.
Key Takeaway: Model the floor adoption case and the post-launch cost lines before the RFP. A wallet that only pays back at optimistic adoption is a marketing cost, and it should be approved as one.
How do you turn the requirements into an RFP vendors can price?
Structure the RFP around decisions already made, requirements with acceptance criteria, and an evaluation grid published in advance. Vendors will tell you how to build a digital wallet app; that is their job, and most of them do it well. Your job is to tell them what it must do, under which rules, and how you will know it works.
A wallet RFP that produces comparable bids has nine parts. Context and decisions made: loop type, funds custody, rails, regulatory classification, partner bank or processor if already selected. Functional requirements organized by transaction state, not by screen. Non-functional requirements with numbers: availability, authorization latency, recovery time and recovery point objectives, peak transactions per second at your busiest hour, not your average one. The integration inventory with an owner on each side of every interface. Compliance obligations assigned by name: who holds the PCI attestation, who is the registered entity, who files with FINTRAC. The data model and any migration from an existing loyalty or stored-value program. Acceptance criteria and the test approach, including how reconciliation will be demonstrated before go-live. The commercial model you want priced: build, build and operate, or license. And the evaluation weights, published, so a vendor who knows reconciliation carries 20% of the score answers it properly instead of with one sentence.
The requirements verification pass described in requirements verification methods applies here with extra force, because a wallet requirement that cannot produce a test cannot produce a price either. The vendors who decline to bid on a precise RFP were going to be the problem bids. The ones who bid will have read it, and their questions will tell you which of them has built a ledger before and which has built an app with a balance on it.
Key Takeaway: Organize functional requirements by transaction state and publish the evaluation weights. If reconciliation and compliance together carry less than a third of the score, the RFP is still a feature list.
Frequently Asked Questions
What is a digital wallet requirements document?It is the specification that defines what a wallet must do at every transaction state, under which regulatory and network rules, with testable acceptance criteria for each requirement. It covers the ledger and reconciliation, funds custody, tokenization and PCI scope, identity tiers, limits, fraud and disputes, failure states, integrations, reporting, and accessibility, and it records the decisions that shape all of them: closed or open loop, who holds the funds, and which rails the wallet rides. It is the input to the RFP, not the output of the vendor's discovery.
Do we need a business analyst before hiring a wallet development company?Yes, if nobody on your side has written a ledger specification or run a regulatory classification before, because those two pieces decide what the vendor is pricing. ID Business Analysis Canada does this work as a Discovery Sprint: a business analyst with a systems analyst runs the classification, the transaction state model, the integration inventory, and the business case floor, and delivers the requirements document and the RFP structure so that vendor bids come back comparable. The development company then builds against a specification rather than discovering it at your expense.
How long does digital wallet discovery take before the RFP can go out?Four to six weeks is the typical range for an organization with an existing customer base and one or two source systems to integrate. Week one is regulatory classification and the loop, custody, and rails decisions. Weeks two and three are the transaction state model, the integration inventory, and the compliance requirements. The remaining time goes to the business case floor, acceptance criteria, and assembling the RFP itself. Organizations that already have a partner bank or processor selected move faster; those that have to run that selection first should add a month.
Should we launch a closed-loop or an open-loop wallet first?Closed loop first, in most cases, because it keeps you outside most of the regulatory perimeter while you learn whether customers open the wallet twice. A closed-loop launch tests adoption, support volume, and reconciliation on real transactions without the registration, safeguarding, and network certification work an open-loop wallet needs. Design the ledger and the state model as if open loop is coming, so the second phase extends the system rather than replacing it. The exception is an organization whose entire case rests on person-to-person transfers, where closed loop proves nothing.
Conclusion
The eleven-page RFP described a product the vendors could all build and none of them could price, because the decisions that set the price were not in it. Loop type, funds custody, rails, and regulatory classification are analysis work, and they come before the RFP or they come after the contract, at a different cost.
If your wallet project has budget approval and a feature list, ID Business Analysis Canada runs the pre-RFP work as a Discovery Sprint: regulatory classification, transaction state model, integration inventory, business case floor, and an RFP with acceptance criteria and published evaluation weights, so the bids you receive describe the same wallet. Book a free consultation and bring the RFP draft; the first thing we will do is count the pages about screens
Sources
- Worldpay, Global Payments Report 2026, Trend 3: Digital wallets are winning on multiple fronts, 2026; digital wallets at 56% of global online and 33% of in-person spending in 2025, survey of more than 63,000 consumers across 42 markets.
- Bank of Canada, Retail payments supervision, obligations of payment service providers under the Retail Payment Activities Act, including the September 8, 2025 date for risk management and funds safeguarding frameworks.
- FINTRAC, Money services businesses, services that require registration, including remitting or transmitting funds and dealing in virtual currencies.
- PCI Security Standards Council, PCI DSS, the standard governing environments that store, process, or transmit cardholder data.
- Business Analysis Canada, Guarding the Gate: The Value of a Project Discovery Phase in IT Strategy, business-analysis.ca blog, August 2026.
- Business Analysis Canada, Prove It Early: Requirements Verification Methods That Catch Defects Before Build, business-analysis.ca blog, September 2026.
- Business Analysis Canada, Follow the Money: Revenue Leakage Examples and the Process Gaps Behind Them, business-analysis.ca blog, September 2026.