A modern digital wallet does not have to hold customer funds in a silo. With a licensed Third Party Provider (TPP), you can build a wallet experience on top of real bank accounts: show balances via Account Information Services (AIS), move money via Payment Initiation Services (PIS), and keep every action tied to explicit customer consent. That is how many neobanks, merchant wallets, and payroll products launch faster—they integrate open banking instead of negotiating bespoke bank pipes for every feature.
This guide walks through the basic steps. It is not legal advice; licensing rules differ by country. But the technical and product sequence is the same whether you are building in Pakistan, the EU, or other open-banking markets.
Step 1: Choose your wallet model
Clarify what “wallet” means for your product before you write code:
- Account aggregation wallet — displays linked bank balances and transaction history; money stays at the bank. Lowest regulatory surface if you are not holding funds.
- PIS-first payment wallet — user pays merchants or peers by initiating bank transfers from linked accounts (A2A). You orchestrate the payment; settlement happens on bank rails.
- Stored-value / e-money wallet — funds sit in a licensed e-money or payment institution account. Often combined with TPP rails for top-up and cash-out. Requires the right licence or sponsor bank.
Most TPP-backed MVPs start with aggregation + PIS: users see real balances and can pay out without you becoming a deposit-taking institution on day one. See TPP vs TSP if you are deciding whether to license, partner, or buy middleware.
Step 2: Secure TPP access (licence or partner)
To call bank APIs for AIS and PIS you need a regulated TPP path—or a contractual arrangement with a licensed TPP that white-labels connectivity. Your architecture should separate:
- TPP connector — OAuth-style redirects, token exchange, bank directory, webhooks.
- Your wallet app — UX, ledger views, limits, fraud rules, customer support.
FintechPaa builds TPP-style connectors and wallet backends for products like Meras.io (A2A payments). If you are scoping a build, start with which banks your users actually use and which AIS/PIS scopes you need.
Step 3: Onboard users with KYC
Wallet onboarding is two layers: who is this person? (KYC/AML) and which accounts can they link? (consent). Run identity verification before or in parallel with the first bank link. Store KYC status separately from consent records so you can block payments if verification fails or expires.
Minimum KYC artefacts: government ID, liveness check, sanctions screening, and for businesses—UBO and registration documents. Align retention with local AML rules.
Step 4: Link bank accounts (AIS)
Account linking is the heart of a TPP wallet:
- User selects “Add account” in your app.
- You create a consent request with scopes (accounts, balances, transactions).
- User is redirected to their bank for Strong Customer Authentication (SCA).
- Bank returns an authorisation code; your TPP layer exchanges it for access and refresh tokens.
- You fetch account list, normalise IBAN/account identifiers, and store tokens in a vault keyed by consent ID.
Show users which accounts are linked, consent expiry, and a one-tap revoke path. For wallet UX, many products compute a “spendable balance” from available balance minus pending PIS instructions. Details on consent lifecycle are in Building a TPP: AIS, PIS, and consent.
Step 5: Enable money movement (PIS)
Payments from a TPP wallet typically follow:
- User chooses payee, amount, and source account.
- You create a PIS consent (or reuse a payment scope where regulation allows).
- SCA at the bank confirms the instruction.
- Bank executes the transfer; you receive status via API polling or webhooks.
- Your wallet ledger records pending → settled (or failed) states.
Use idempotency keys on every payment request so retries never double-pay. Expose clear statuses to users: initiated, accepted, settled, rejected. For merchant wallets, pair PIS with reconciliation files or instant notification webhooks—see A2A payments beyond cards.
Step 6: Design your internal ledger
Even when funds are not stored in your entity, you need a ledger that mirrors reality:
- Linked account mirror — cached balances and transactions from AIS (with TTL and refresh rules).
- Payment intents — outbound PIS instructions with bank reference IDs.
- User-visible wallet balance — derived view, not necessarily a stored float.
Never show a balance your AIS cache cannot justify. Refresh before high-value payments. Log every derivation: which consent, which API call, which timestamp.
Step 7: Wire consent, SCA, and security
Wallet trust depends on predictable auth flows:
- Separate AIS and PIS consents where regulators require it.
- Encrypt tokens at rest; rotate keys; never log full account numbers in application logs.
- Handle token refresh and re-consent before expiry—silent failures frustrate users.
- Implement step-up authentication inside your app for high-risk actions (new payee, large transfer).
PSD2-style markets document SCA exemptions carefully. Our overview: PSD2 and Strong Customer Authentication.
Step 8: Compliance, audit, and ops
Regulators and partners will ask for traceability:
- Consent artefacts (scope, timestamp, IP, user agent).
- Payment audit trail from UI click → PIS request → bank status.
- AML monitoring on payee patterns and velocity limits.
- Incident response for token compromise or bank outage.
Build admin dashboards for support: lookup by user, consent ID, or bank payment reference. Operations teams should not need engineering to answer “where is my money?”
Step 9: Pilot, measure, scale
Roll out in a thin slice:
- Two or three banks covering most of your target users.
- One use case—e.g. pay a merchant QR or send to a saved beneficiary.
- Shadow mode reconciliation against bank statements for four weeks.
- Promote to general availability with limits, monitoring, and clear user comms.
Track authorisation success rate, SCA drop-off, time-to-settle, and support tickets per thousand payments. Optimise the redirect UX before adding features like split bills or scheduled transfers.
Reference architecture (summary)
A typical TPP wallet stack:
- Mobile/web app
- Wallet API (users, KYC status, limits, ledger views)
- TPP connector (consent, AIS, PIS, token vault, webhooks)
- Bank adapters (per ASPSP or via aggregator)
- Reconciliation & reporting service
FintechPaa implements this pattern for clients building open banking, A2A, and merchant settlement products in Pakistan and internationally. If you want a scoped architecture review or production build, talk to our team or explore TPP solutions.
← Back to Blog