Fintech is evolving fast — real-time payments, open banking, embedded finance. This list curates everything you need to stay sharp and ahead in 2025.

1. What is Fintech, and Why Does It Matter?

Imagine walking into a bank in 2003. You fill out a deposit slip, wait in line, speak to a teller, and maybe — just maybe — get a service completed in 30 minutes.

Now fast forward to today: you open an app, move your money, invest in stocks, buy insurance, or send a cross-border payment — all in a few taps. That’s fintech in action.

Fintech stands for financial technology. But that’s not the whole story. It’s not just “tech in finance.” It’s about how technology changes the way financial services are designed, delivered, and experienced.

At its core, fintech is about solving three persistent problems in traditional finance:

• It’s too slow (think 3–5 days for a transfer),
• It’s too expensive (high fees and poor transparency), and
• It’s often exclusionary (leaving behind those with limited access to credit or digital tools).

That’s where startups, APIs, mobile-first experiences, machine learning, and even blockchain come in. Fintech aims to democratize finance — make it faster, more affordable, and more accessible.

Some well-known fintech categories:

• Payments: Stripe, Razorpay, PayPal
• Lending: Upstart, Kabbage, Zopa
• Banking-as-a-Service: Synapse, M2P, Unit
• Wealthtech: Robinhood, Groww, Betterment
• Insurtech: Lemonade, Acko
• Crypto & Web3: Coinbase, MetaMask

From a PM’s perspective, fintech isn’t just about features — it’s about solving pain in systems that haven’t changed in decades.

Whether you’re launching a new digital wallet or building an onboarding flow for small business credit, you’re redesigning an experience that people rely on every day for their livelihoods.

2. How Money Moves: Authorization, Clearing & Settlement

Let’s say you’re buying coffee with your debit card at 8:57 AM. You tap your card, get a notification that $4.50 was debited, and walk out sipping your espresso.

But behind the scenes, three distinct stages have just started. They’re called authorization, clearing, and settlement — the plumbing of payments.

Here’s what happens:

Step 1: Authorization (Real-Time, Instant)

This is the “Can this transaction go through?” step.

• Your bank checks: Is this really you? Do you have enough balance?
• The merchant’s terminal connects via their payment provider to ask the issuer for permission.
• If approved, you see the “Transaction Successful” message instantly.

At this stage, no money has actually moved yet. It’s a handshake, not the delivery.

Step 2: Clearing (Batch Processing)

Later that day, your transaction details are bundled into a batch and shared between banks and networks (Visa, Mastercard, etc.) to reconcile what happened.

• Was the transaction amount correct?
• Any currency conversions involved?
• Are there fees or adjustments?

Step 3: Settlement (Funds Actually Move)

Usually, 1–2 days later, the $4.50 is finally transferred from your bank to the merchant’s bank.

This is where actual funds flow, through central banking systems or card networks’ settlement rails.

Let’s bring this alive with a real-world example:

Stripe (a payment processor) handles millions of card payments every day. When you pay a merchant using Stripe, the platform handles authorization instantly. But Stripe doesn’t send the merchant their money immediately. That money gets settled in bulk, often next business day, depending on geography, currency, and risk settings.

From a PM’s perspective, this delay matters.

• If you build a wallet or merchant dashboard, you need to show settled balance vs. authorized transactions.
• If you’re working on refunds or disputes, you need to understand where the transaction is in the lifecycle to know what’s possible.

Why This Matters in Fintech

These three stages (authorization, clearing, settlement) define how money moves.

If your fintech product deals with the timing of funds, reporting, reconciliation, or fraud prevention, you need to know this inside-out.

And now that faster rails like RTP, UPI, and PIX are cutting settlement down to seconds, these once-separate stages are starting to collapse. That’s the future of fintech infrastructure.

3. Issuing vs Acquiring — Who’s Who in a Card Transaction?

Let’s say you’re at a clothing store. You swipe your Visa card, it gets approved, and you walk away with a new jacket.

But behind that simple swipe, two very different banks are involved:

• One that gave you the card (your bank)
• One that supports the store (the merchant’s bank)

This is where the roles of issuer and acquirer come in.

Who is the Issuer?

The issuing bank is the one that provides the card to the customer (you). Examples: HDFC, Chase, Capital One.

They:

• Approve or decline transactions
• Own the relationship with the cardholder
• Take on credit risk (if it’s a credit card)
• Handle billing, rewards, fraud alerts, etc.

Who is the Acquirer?

The acquiring bank supports the merchant. Examples: Adyen, Stripe (via acquiring partnerships), Worldpay.

They:

• Provide the merchant with tools to accept cards
• Route transactions to the card networks (Visa, Mastercard)
• Help with onboarding, settlement, and support
• Charge merchant fees (MDR) and often pass on network costs

Why Does This Separation Exist?

The card networks (Visa, Mastercard, etc.) don’t actually hold your money or issue cards. They’re switches and rulemakers — they enable communication between issuers and acquirers.

Think of card payments as a conversation between two banks — the issuer speaks for the customer, the acquirer speaks for the merchant, and Visa/Mastercard make sure they understand each other.

Real-World Example

When you pay using a Revolut card at a shop powered by Square, here’s what happens:

• Revolut is the issuer (they gave you the card and manage your account).
• Square is the acquirer (they helped the merchant accept your card).
• Visa or Mastercard is the network connecting the two.

Topic 4: Payment Schemes & Card Networks — Visa Isn’t a Bank

When someone says “Visa payment,” it’s easy to assume Visa is the one sending or receiving money. But here’s the twist: Visa doesn’t hold your money, issue cards, or settle funds. Neither does Mastercard.

So what do they do?

They operate the payment schemes or card networks — global highways that connect issuers and acquirers, define the rules of the road, and ensure that transactions are processed securely and reliably.

What is a Payment Scheme?

A payment scheme is a set of rules, standards, and technologies that govern how transactions are initiated, routed, authorized, and settled.

Think of it like:

• Visa/Mastercard: Card-based schemes
• UPI/PIX/RTP: Account-based schemes

Each scheme defines:

• How to format a transaction
• How to route it between parties
• What fees apply and who pays them
• How disputes are handled

Major Card Networks (Global)

• Visa and Mastercard (open loop)
• American Express and Discover (closed loop)
• UnionPay (China)
• JCB (Japan)
• RuPay (India)

Open loop = banks issue the cards and accept payments (like Visa/Mastercard)
Closed loop = the same entity issues and acquires (like AmEx)

Real-World Relevance

Let’s say you’re building a multi-currency card product. The card network you choose will determine:

• Where the card can be used (coverage)
• What FX fees apply
• What rules govern things like chargebacks, tokenization, and settlement time

If you’re issuing cards on Mastercard, your team will integrate with Mastercard’s APIs, follow their dispute windows, and absorb their interchange rules.

If you’re supporting merchants in India, RuPay may offer better economics or coverage locally.

Topic 5: Tokenization — The Secret Layer That Keeps Your Card Safe

Ever wondered how Apple Pay or Google Pay lets you tap to pay without actually exposing your real card number? That’s tokenization at work.

In the old days, every time you paid with your card, the actual card number (PAN) was shared with the merchant, passed through systems, and stored — creating multiple points of vulnerability.

Enter tokenization, a security technique that replaces sensitive data with a safe, unique placeholder.

What is Tokenization?

Tokenization replaces the Primary Account Number (PAN) of a card with a token — a random string of characters that’s useless outside of its intended context.

There are two major types of tokens in fintech:

1. Merchant Tokenization (Vaulting)

• Used by PSPs like Stripe or Razorpay
• They store the real card in a secure vault and return a token to the merchant
• The merchant can reuse the token for future payments without ever seeing the real card

2. Network Tokenization (Scheme-Managed)

• Managed by Visa, Mastercard, etc.
• The card is replaced by a token at the network level, not just by the PSP
• More secure and portable — used by Apple Pay, Samsung Pay, and most mobile wallets

Why Tokenization Matters

• Reduces PCI DSS compliance scope (you’re not storing actual card data)
• Minimizes exposure in case of data breaches
• Enables safe recurring payments, one-click checkouts, and saved cards
• Essential for in-app, mobile, and contactless transactions

Real-World Example

When you use Apple Pay:

• Your real card number is never stored on the device or Apple’s servers.
• Instead, Apple requests a network token from Visa or Mastercard.
• That token is used for all payments — and if it’s stolen, it’s useless anywhere else.

Platforms like Netflix or Spotify use merchant tokenization to securely store your card details for billing, while large PSPs like Adyen have adopted network tokenization for better success rates and security.

Why It Matters for PMs

If you’re building any product that stores, reuses, or routes cards, you need to decide:

• Do you build your own vault, or use a PSP?
• Do you support network tokens for higher auth rates?
• How do you manage token lifecycle events (like card expiry or replacements)?

Tokenization isn’t just a backend detail — it’s central to fraud prevention, conversion rates, and user trust.

For a deeper dive, I highly recommend the course. It costs less than a burger yet delivers exceptional value for anyone looking to break into Fintech.

Fintech BootCamp: Master Financial Ecosystem

Topic 6: BIN/IIN Ranges — The First 6 Digits That Tell You Everything

Ever looked at a card number and wondered how fintech platforms know which bank issued it, what type of card it is, or even which country it came from?

The answer lies in the BIN or IIN — short for Bank Identification Number or Issuer Identification Number. This is the first 6 to 8 digits of a card number, and it tells you a lot more than you’d think.

What’s Inside a BIN?

Let’s break down a sample card number:
5432 87XX XXXX XXXX

• 543287 → The BIN
• First digit (5) = Mastercard
• The next 5 digits identify the issuing bank, card type, and region

BINs help payment processors determine:

• Which issuer gave out the card
• Whether it’s debit, credit, or prepaid
• Country of issue (for geo-blocking or FX rules)
• If it’s a consumer or commercial card

Real-World Use Cases

When you build a checkout page:

• You can detect the card type and scheme instantly after 6 digits
• You can route to the right acquirer for better success rates
• You can enforce regional restrictions (e.g., block cards from unsupported markets)

For example, Netflix may restrict trial offers based on BINs from certain countries.
Stripe uses BIN data to offer real-time card metadata for fraud prevention and analytics.

BIN Ranges Are Changing

In 2022, Visa and Mastercard expanded from 6-digit to 8-digit BINs to deal with card number exhaustion. This is especially important for fintech PMs:

• Your backend and BIN-detection logic must support 8-digit parsing
• PSPs and card programs must align with the new standard

Why It Matters for PMs

As a fintech PM, BINs help you:

• Understand your customer base (what % of cards are prepaid? what regions?)
• Route transactions for higher success rates or lower interchange
• Flag suspicious patterns (e.g., mismatch between card country and user location)

If you’re launching a global product or building a card issuing platform, BIN logic becomes product logic — affecting risk, experience, and economics.

Topic 7: Refunds, Voids & Reversals — Why All Refunds Aren’t Equal

Let’s say a customer places an order on your app and then immediately cancels it. In the backend, should you initiate a refund, void, or a reversal?

Believe it or not, these aren’t just different words — they represent different stages in the transaction lifecycle and have big implications for cost, speed, and user experience.

So What’s the Difference?

1. Void

• Happens before settlement
• Cancels a transaction that was authorized but not yet captured
• No money moves because the funds were never actually taken
• Typically used within the same day

2. Refund

• Happens after settlement
• Funds have already been deducted from the user’s account and settled to the merchant
• Requires a new transaction to send the money back
• Takes 1–7 business days, depending on bank and region

3. Reversal (or Authorization Reversal)

• Happens right after authorization, before clearing
• Signals to the issuer that the hold on the user’s funds can be released
• Avoids funds being blocked for days
• Not all issuers honor reversals in real time

Real-World Example

A customer books a flight on Skyscanner and cancels within 30 minutes. If the airline hasn’t settled the payment yet, they can void the transaction, and the customer sees no charge.
But if the transaction is already settled, the airline must refund, and the customer waits 3–5 days to see the money.

Some modern PSPs like Stripe or Adyen expose this distinction clearly in their APIs. Others (like legacy banking systems) may just lump everything as a refund.

Why It Matters for PMs

These nuances impact:

• Customer support tickets (“Where is my refund?”)
• Cash flow for merchants
• Reconciliation complexity (refunds are separate transactions)
• Authorization holds on a user’s card

As a fintech PM, you should:

• Know when to void vs refund based on transaction status
• Expose real-time status updates in your UI
• Educate merchants on when funds are actually returned

Understanding this flow helps reduce user friction and build trust — especially in products like booking, ride-hailing, or retail where cancellations are common.

Topic 8: Payment Message Standards — ISO 8583 vs ISO 20022

Ever wonder how banks and processors around the world communicate billions of transactions daily — across countries, currencies, and systems?

It’s not magic. It’s messaging standards, and two formats dominate the fintech world: ISO 8583 and ISO 20022.

ISO 8583: The Old Warrior

Developed in the 1980s, ISO 8583 is the de facto standard for card-based transactions.

If you’ve ever swiped your card at a POS terminal, the authorization request and response were almost certainly formatted using ISO 8583.

• It’s compact and binary, built for old-school telecoms and card rails
• Still used by most card networks (Visa, Mastercard, RuPay, etc.)
• Messages are made up of fields like MTI (Message Type Indicator), DE (Data Elements), etc.

Despite its legacy, it still powers the majority of the world’s card payment infrastructure.

ISO 20022: The Modern Standard

ISO 20022 is the XML/JSON-based messaging standard designed for real-time, richer data and cross-border payments.

• Adopted by SEPA, SWIFT, Faster Payments, UPI, and others
• Supports detailed metadata — useful for compliance, reconciliation, invoicing
• XML-based = more verbose, but machine-readable and easier to extend
• Being phased in by SWIFT as the new global format

Real-World Relevance

If you’re building:

• A card switch? You’ll deal with ISO 8583.
• A real-time A2A payment product? You’ll probably use or parse ISO 20022.
• Cross-border infrastructure? Your backend must map between both standards.

Example: In 2023, SWIFT began migrating to ISO 20022 globally. Any fintech connected to SWIFT must now support this richer data format.

Why It Matters for PMs

Even if you’re not writing the parser yourself, understanding message formats helps you:

• Scope product timelines accurately
• Know what data is available at each step of a payment
• Understand why something failed (often buried in raw fields)
• Translate compliance or reporting needs into technical requirements

TL;DR: ISO 8583 is the language of cards. ISO 20022 is the future of banks.

If your product touches payment processing, reconciliation, or data analytics, understanding these formats gives you a serious edge.

Topic 9: Payment Reconciliation — The Silent Backbone of Fintech

Here’s a question: if your system says ₹1,00,000 was collected yesterday, but your bank account only shows ₹99,200 — where did the money go?

That’s the world of reconciliation. It’s how fintech products make sure the money they think moved matches what moved.

What is Payment Reconciliation?

In simple terms, reconciliation is the process of matching internal transaction records with external reports from banks, payment gateways, card networks, and wallets.

You’re answering questions like:

• Was the transaction captured and settled?
• Did we receive the correct amount (after fees)?
• Is the payment status in our database accurate?
• Do we need to reconcile refunds, chargebacks, and reversals?

Real-World Example

Let’s say you run a marketplace like Instacart or BigBasket:

• You collect payments via UPI, cards, and wallets
• You process refunds, promos, and partial cancellations
• You pay out money to sellers or delivery partners

Recon is what makes sure that:

• Every ₹ charged = ₹ actually received (minus MDR)
• Refunds were issued from the correct ledger account
• Settlements were tracked to the right vendor or partner

If you miss a recon mismatch, you might double-refund, misreport earnings, or worse — fail an audit.

Why It’s Complex

• Payment methods settle on different timelines
• Some providers deduct fees before settlement, others after
• Disputes, reversals, and refunds add exceptions
• There’s often no single source of truth — only partial records

Why It Matters for PMs

Whether you’re building an internal finance dashboard or a customer wallet:

• You need to design recon-friendly systems (timestamps, transaction IDs, webhook receipts)
• You’ll often need auto-recon rules + manual exception queues
• Reconciliation impacts trust, cash flow, and regulatory reporting

Recon is like brushing your teeth. You don’t do it to show off. You do it to avoid rot.

Ignore it, and your systems might look shiny on the outside while quietly falling apart inside.

Topic 10: Chargebacks & Disputes — The Fintech PM’s Worst Headache

You launched a great payment flow. Conversions are up. But then, three weeks later, your ops team flags a spike in chargebacks. What happened?

Chargebacks are a form of consumer protection — and also one of the biggest loss centers in fintech.

What is a Chargeback?

A chargeback happens when a cardholder disputes a transaction and asks their bank to forcibly reverse it.

Reasons include:

• “I didn’t authorize this transaction” (fraud)
• “I didn’t receive the product” (non-delivery)
• “I canceled the service but still got billed” (billing error)

The bank investigates the claim and provisionally returns the money to the customer, while the merchant must prove their case.

The Lifecycle of a Chargeback

1. Customer disputes a charge
2. Their bank (issuer) files a chargeback with the card network
3. The merchant (you) is debited immediately
4. You can accept or contest the dispute
5. If contested, you submit evidence (receipts, logs, policies)
6. Network decides the outcome (called arbitration if it escalates)

Real-World Example

Let’s say you’re a PM at a digital subscription service like Spotify. A user signs up for a 30-day trial, forgets to cancel, and gets billed ₹499.

They dispute the charge with their bank saying: “I didn’t authorize this.” Even though your systems show they opted in, you now must respond with clear, timestamped proof — or lose the money.

Each chargeback also comes with a fee, typically ₹250–₹600 per dispute, regardless of outcome.

Why It’s Costly

• You lose the money and the product/service
• You pay a chargeback fee
• Too many disputes = penalty programs from Visa/Mastercard
• You waste time on manual dispute ops

Worse, if your chargeback ratio exceeds 0.9% (Visa) or 1.0% (Mastercard), you may be placed in a Monitoring Program — a fancy way of saying “you’re at risk of losing processing privileges.”

Why It Matters for PMs

If you touch billing, risk, support, or payments, you must:

• Track dispute reasons and patterns (friendly fraud vs true fraud)
• Build dispute evidence packages (terms of use, device logs, delivery proofs)
• Offer clear cancellation flows and refund policies
• Partner with PSPs that offer dispute management tools or auto-evidence submission

Every chargeback is a signal. As a PM, it’s your job to figure out: Is this bad UX? Poor communication? Or actual fraud?

Topic 11: Card-Present vs Card-Not-Present — Two Very Different Worlds in Payments

Let’s say you go to a café and tap your card to pay. Later that evening, you order dinner online using the same card.

To you, both feel like regular payments. But to the payments ecosystem? These are two entirely different beasts — called Card-Present (CP) and Card-Not-Present (CNP) transactions.

And this distinction affects fraud risk, fees, compliance, and even user experience.

What Is Card-Present?

A Card-Present transaction is when the physical card is used in-person at a terminal or POS (point-of-sale) device:

• Tap (NFC)
• Dip (EMV chip)
• Swipe (magstripe)

Because the card is physically there and verified on the spot, the fraud risk is lower, and so are the interchange fees.

What Is Card-Not-Present?

Card-Not-Present transactions happen when the card isn’t physically there:

• Online shopping
• In-app payments
• Recurring subscriptions
• Phone-based orders (IVR, call centers)

Since the card can’t be authenticated physically, CNP carries higher fraud risk, and that translates to higher processing fees, stricter authentication, and more declines.

Real-World Example

Let’s say you’re building a checkout experience for a food delivery app like Zomato.

• A dine-in POS payment = Card-Present
• An order paid through the app = Card-Not-Present

Even if both use the same card, your authorization rates, fraud rules, and network fees will differ — sometimes by 20–40 basis points.

Some card networks like Visa or Mastercard offer lower fees for CP transactions because they’re more secure. That means for merchants, accepting cards in person is cheaper than online.

From a Fintech PM’s Perspective

You need to ask:

• Is your platform supporting both CP and CNP flows?
• Do your risk models treat them differently?
• Can your dashboards segment CP vs CNP performance?
• Are you optimizing 3DS or other authentication for CNP cases?

Understanding CP vs CNP isn’t just a compliance checkbox. It shapes your fraud strategy, checkout design, and even unit economics.

12. EMV Chip, Contactless & NFC — How Cards Evolved to Be Smarter

Remember when we used to swipe cards with a magnetic stripe? Then came the chip. Now we just tap.

But how does it all work — and why does it matter in fintech?

Let’s break down the tech behind modern card-present transactions, especially:

• EMV Chip
• Contactless
• NFC

These aren’t just convenience upgrades — they also reduce fraud, shift liability, and influence infrastructure design.

1. EMV Chip — The Smart Security Layer

EMV stands for Europay, Mastercard, and Visa, which created the global chip card standard.

Unlike magstripe cards (which hold static data), EMV chips generate a new cryptographic code every time you use them. This makes it nearly impossible to clone the card or reuse the data for fraud.

That’s why:

• Most countries have mandated EMV compliance
• Merchants using only magstripe terminals are now liable for fraud (called the “liability shift”)
• EMV is a global standard, not optional

2. Contactless — Tap to Pay with the Same Chip

Contactless cards use RF (radio frequency) signals from the EMV chip — they don’t need to be inserted.

The tech works through NFC (Near Field Communication), and the card still generates EMV-compliant cryptograms.

Key facts:

• Contactless = still EMV-secure
• Most cards now support both dip and tap
• Usually capped at a tap limit (e.g., ₹5,000 in India) for faster payments
• Used in transit systems, cafes, retail, and softPOS

3. NFC — The Same Tech in Your Phone

When you use Apple Pay, Google Pay (tap-to-pay mode), or even Samsung Pay, you’re using NFC.

Your phone stores a network token instead of the actual card number, and that token is used to perform a secure tap transaction — just like a contactless card.

This is often referred to as mobile EMV or digital wallet payments.

Real-World Example

London’s Tube system lets you tap your card or phone directly at the turnstile.

• If you tap a physical card → EMV contactless
• If you tap your phone → NFC + tokenization

Both routes are fast, secure, and treated as card-present, but the risk models and fees may differ.

In the U.S., Square launched a hardware-free “tap to pay” solution using NFC on Android phones, allowing merchants to accept cards without a terminal — known as softPOS.

Why It Matters for PMs

As a product manager building for in-person payments, ask:

• Do we support EMV-compliant readers and terminals?
• Are we ready for tap-to-pay via phone (NFC)?
• Is our infrastructure PCI-compliant and ready for contactless?
• Are we enabling a fast, secure experience without compromising on data quality?

The shift from swipe to chip to tap is more than UX — it changes fraud risk, compliance exposure, and device hardware costs.

13. 3-D Secure & Strong Customer Authentication — Can You Prove It’s Really You?

You’ve probably seen it before: you enter your card details, and suddenly you’re asked to enter an OTP or authenticate with your face or fingerprint.

That extra step? It’s part of 3-D Secure (3DS) and Strong Customer Authentication (SCA).

These mechanisms exist to answer one fundamental question:
“Can you prove this user is who they say they are?”

What is 3-D Secure (3DS)?

3-D Secure is a protocol created by card networks (Visa, Mastercard, etc.) to add a security layer to online card transactions.

The “3-D” refers to the three domains involved:

1. Issuer domain (the bank that issued the card)
2. Acquirer domain (merchant’s bank)
3. Interoperability domain (the card network itself)

How it works:

• User initiates a card-not-present transaction
• 3DS triggers a step-up authentication (OTP, biometric, etc.)
• The issuer verifies the identity and either approves or declines

Evolution: 3DS1 vs 3DS2

• 3DS1 = Pop-ups, redirection, clunky UX
• 3DS2 = Frictionless flows, mobile-friendly, supports biometric and app-based auth

With 3DS2, the issuer can approve without interrupting the user if risk signals look good.

What is Strong Customer Authentication (SCA)?

Introduced under PSD2 in Europe, SCA is a regulatory requirement, not just a technical feature.

It mandates that most electronic payments use 2 out of 3 factors:

1. Something you know (password/PIN)
2. Something you own (phone, card)
3. Something you are (biometrics)

3DS2 is the tool that helps meet SCA compliance for card payments in Europe and other regulated markets.

Real-World Example

You run an e-commerce platform in the UK. When a customer pays via card:

• 3DS2 is invoked
• They get a push notification from their banking app
• They authenticate via Face ID or fingerprint
• The payment completes smoothly

But if you’re operating in the U.S., SCA may not apply — so you can skip 3DS entirely for most domestic payments (though you may still use it for fraud control).

Why It Matters for PMs

As a product manager, 3DS and SCA impact:

• Conversion rates: More friction = more drop-off
• Fraud rates: 3DS shifts liability to the issuer
• Compliance: You must support SCA in regulated regions
• UX: You must design fallbacks for 3DS failures or unsupported devices

Your job isn’t just “implement 3DS.” It’s to balance friction vs fraud — and know when to trigger it or skip it.

Done well, SCA builds trust. Done poorly, it kills conversion.

For a deeper dive, I highly recommend the course. It costs less than a burger yet delivers exceptional value for anyone looking to break into Fintech.

Fintech BootCamp: Master Financial Ecosystem

Topic: 14 Credential-on-File, CIT vs MIT — The Backbone of Subscription Payments

Let’s say a user signs up for your platform, adds their card, and agrees to auto-renew monthly.

Three months later, your system charges the card — without any user input.

That’s credential-on-file billing in action, and behind the scenes, it involves CITs and MITs — two concepts every fintech PM should know.

What is Credential-on-File (CoF)?

Credential-on-File means the merchant or PSP stores the user’s card details (or a tokenized version) securely for future use.

CoF is used for:

• Subscriptions (Netflix, Spotify)
• One-click checkout (Amazon, Flipkart)
• Recurring utility payments or EMI collections

The rules around CoF are defined by card networks, and improper usage can lead to disputes, declines, or fines.

CIT vs MIT — What’s the Difference?

Every card transaction involving stored credentials falls into one of two buckets:

1. CIT — Cardholder-Initiated Transaction

• The customer actively starts the payment
• Example: Clicking “Pay Now” on a checkout page

2. MIT — Merchant-Initiated Transaction

• The merchant charges the card based on prior consent
• Customer isn’t present at the time of payment
• Example: Monthly subscription renewals, no-show hotel charges, or usage-based billing

MITs must be linked to a previous CIT, and must have:

• Clear consent from the user
• Proper CoF indicators in the payment message

Why This Matters in the Real World

Card networks and issuers track MITs closely.

If you don’t mark the transaction correctly:

• It might get flagged as suspicious or fraudulent
• You won’t be protected under the 3DS liability shift rules
• Issuers may block or downgrade your merchant profile

Real-World Example

You run a SaaS product like Notion

• First payment = CIT + 3DS auth
• Subsequent monthly charges = MIT, referencing that initial CIT

If the user’s card expires or is reissued, your PSP must support lifecycle management or token updates to keep the billing uninterrupted.

Why It Matters for PMs

If your fintech product involves:

• Subscriptions
• Stored cards for future use
• Auto-debits or retry logic

Then you need to:

• Understand and label CIT vs MIT correctly
• Ensure proper user consent flows
• Work with PSPs that support network tokenization and CoF compliance

Your billing logic isn’t just backend logic — it’s part of your compliance, fraud, and customer experience strategy.

Get this wrong, and payments fail silently. Get it right, and your LTV soars.

15. Recurring Payments & Dunning — Keeping the Revenue Flowing

Let’s say a user signs up for your service and agrees to be billed ₹499/month. Everything works fine for 3 months… until the 4th payment fails.

Maybe their card expired. Maybe they’re low on funds. Maybe their bank was down.

Now what?

This is where the recurring payments engine and dunning strategy come into play — and if you ignore them, you’re leaving money on the table every month.

What Are Recurring Payments?

Recurring payments are automated, scheduled charges made to a user’s stored payment method — typically for:

• Subscriptions (e.g., Netflix, Hotstar)
• Loan repayments (e.g., BNPL installments)
• Utility or bill pay (e.g., phone bills)

These payments can be:

• Fixed (₹499/month)
• Variable (usage-based like AWS or GPay recharge limits)
• Time-based (daily, monthly, annual)

You typically rely on MITs (Merchant-Initiated Transactions) to process them.

What Is Dunning?

Dunning is the process of handling failed recurring payments — and it’s as important as the payment itself.

It includes:

• Retrying the charge (at smart intervals)
• Notifying the user (SMS, push, email)
• Offering alternative payment methods
• Grace periods, suspensions, or service restrictions

Done well, dunning can recover 20–40% of failed payments.

Real-World Example

Imagine you’re a PM at Duolingo Plus:

• Day 0: Monthly auto-renew charge fails
• Day 1: Retry at 6 am → still fails
• Day 2: User gets a push + email: “Update your payment method”
• Day 3: Retry succeeds → user remains subscribed

This flow is invisible to the user when done right — but disastrous if skipped.

Some platforms use machine learning to time retries based on user history and card type. Others retry at common salary credit windows (e.g., 1st or 15th of the month).

Why It Matters for PMs

Your recurring payment setup should:

• Track first-time success rate and recovery success rate
• Support lifecycle events (card expiry, reissuance)
• Have multi-channel nudges ready (email + SMS + push)
• Offer payment method switching mid-cycle
• Respect regional mandates (e.g., RBI’s e-mandate in India)

Recurring payments are not “set and forget.” They’re an engine you need to tune — and dunning is your revenue recovery playbook.

Topic 16: Authorization Optimization & Retries — Getting More Yeses from Issuers

Not every card decline is final. In fact, many declines can be recovered — if you know what to do.

That’s what authorization optimization is all about: increasing the likelihood that a transaction will be approved by the issuer, especially in CNP and recurring use cases.

Why Do Authorizations Fail?

Common reasons:

• Expired or blocked card
• Insufficient funds
• Incorrect CVV or expiry
• Card not enrolled in 3DS
• Issuer down or timing out
• Transaction flagged as risky

But here’s the thing: not all declines are equal.

Some are soft declines (temporary or retryable). Others are hard declines (permanent — don’t bother retrying).

How Optimization Helps

Fintech platforms like Stripe, Adyen, and Checkout.com have built playbooks to:

• Retry soft declines at better times
• Use network tokens instead of static PANs
• Route transactions via alternate acquirers
• Auto-correct metadata mismatches (e.g., wrong CVV format)

These strategies can improve auth rates by 2–5%, which is huge at scale.

Smart Retry Strategy

A smart retry engine considers:

• Time of day (avoid issuer downtime windows)
• Day of week (e.g., retries near salary credits)
• Decline code (retry only for soft declines)
• Acquirer route (local vs global)
• Payment method metadata (CIT vs MIT indicators)

Think of retries like CPR for payments — but only useful if done with precision.

Real-World Example

Let’s say you’re running a digital insurance app. Monthly payments are failing at 6–7% due to declines.

After optimizing:

• You switch from raw PAN to network tokens
• Retry only insufficient funds errors after 48 hours
• Route high-value transactions through a local acquiring partner

Result? Auth rate improves by 4.8%, churn drops, and support tickets go down.

Why It Matters for PMs

If you’re building anything with card payments, EMIs, subscriptions, or wallet top-ups, ask:

• What’s our current authorization rate by issuer, region, BIN?
• Do we segment retry reasons or treat all failures the same?
• Are we using a PSP that supports smart retries, local routing, and tokenization?

Optimizing authorizations is one of the rare things that improves conversion, retention, and margins — all at once.

Don’t let your revenue die at the gate. Give it a second chance to succeed.

17. Network Tokenization & Card Updaters — Keep the Card, Lose the Risk

Let’s say your user adds a card to your platform, and six months later, the card gets reissued — maybe it expired, maybe it was reported lost. If you’ve stored the old PAN, your next transaction attempt will fail.

Unless… you’re using network tokenization and card updater services.

These are the invisible tools that help your billing infrastructure stay secure, compliant, and most importantly — up-to-date.

What Is Network Tokenization?

Unlike basic vaulting (where a PSP stores card details securely and issues a merchant token), network tokenization is powered by card networks (Visa, Mastercard, RuPay, etc.).

Here’s how it works:

• You send the PAN (real card number) to the network once
• The network replaces it with a token (unique to your use case)
• That token is mapped securely on the network’s side to the original card

Now, every time the card is reissued or updated, the token remains valid. It also auto-updates behind the scenes, increasing success rates and reducing fraud.

Benefits of Network Tokenization

• Security: PAN never hits your servers or PSP logs
• Higher Auth Rates: Issuers are more likely to approve network tokens
• Lifecycle Management: Tokens auto-update when a card is reissued
• Reduced PCI Scope: You never store the actual card number
• Better UX: Fewer failed payments due to expired/lost cards

What About Card Updaters?

Card updater services are tools offered by networks and issuers that allow merchants to refresh stored card data.

There are two kinds:

1. Real-time updaters — triggered during transactions (e.g., Stripe sends a charge request, gets updated credentials back)
2. Batch updaters — periodic syncs where the PSP refreshes all stored cards in your vault

These are critical for:

• Subscription businesses
• BNPL/lending products with scheduled repayments
• Wallet top-ups and CoF use cases

Real-World Example

You’re a PM at Spotify. A user signs up for Premium with their Mastercard. Six months later, the card is reissued.

Because you use network tokenization and card updater services:

• The new card number is automatically updated in the background
• Your next billing attempt succeeds
• The user has no idea a change happened — and that’s the magic

Why It Matters for PMs

Ask yourself:

• Is our PSP using network tokenization or just basic vaulting?
• Are we subscribed to card updater services?
• What % of our failed charges are due to expired or replaced cards?
• Are we passing the right metadata for CoF and MIT billing?

Silent retention = success. You win when the user never sees a failed charge.

18. Chargeback Reason Codes & Representment — Fighting (and Winning) the Right Battles

Imagine this: your user disputes a ₹1,000 transaction, saying they “never received the product.” Your platform gets charged. You lose the money and pay a ₹500 dispute fee.

Do you give up? Or fight back?

If you’re smart — and equipped with the right tools — you represent the case and win back your revenue. But it all starts with understanding chargeback reason codes and how to build a solid representment case.

What Are Chargeback Reason Codes?

Every time a customer disputes a transaction, the card network assigns a reason code — a numeric or alphanumeric code that explains why the dispute occurred.

Each network has its own system:

• Visa: Reason codes like 10.4 (Fraud — Card Absent Environment)
• Mastercard: Codes like 4837 (No Cardholder Authorization)
• AmEx, Discover: Their own structures

Common categories include:

• Fraud (unauthorized transaction, stolen card)
• Product/Service Issues (not received, not as described)
• Processing Errors (duplicate charge, wrong amount)
• Cancelled Recurring Billing

Understanding the code helps you:

• Know whether you’re liable or protected
• Decide whether to accept or fight the chargeback
• Tailor your evidence submission to the exact reason

What Is Representment?

Representation is your opportunity to contest the chargeback by submitting compelling evidence to prove that:

• The transaction was authorized
• The goods/services were delivered
• Your policies were clearly communicated
• The customer is making a false claim (aka friendly fraud)

You only get one shot — so the quality of your evidence matters.

What to Include in a Representment Package

Depending on the reason code, include:

• Proof of delivery (tracking number, timestamps)
• Screenshots of digital delivery
• Customer agreement/terms of service
• IP logs, device fingerprint, or login history
• 3DS authentication result or OTP confirmation
• Prior customer communication (emails, chats)

Real-World Example

You’re the PM at Blinkit (a grocery delivery app). A user claims they never received an order worth ₹750.

Because you track delivery with GPS and OTP, your support team:

• Pulls up the GPS location of the delivery
• Shares the OTP match record
• Screenshots in-app confirmation

You submit this to the card network — and win the case.

Why It Matters for PMs

If your product accepts payments and faces chargebacks:

• Track reason codes over time to identify patterns (e.g., 4837 fraud spikes)
• Build a chargeback dashboard to monitor dispute win rate
• Standardize evidence templates by reason code
• Consider working with dispute management platforms like Chargeback911, Midigator, or Verifi

Fighting every chargeback isn’t smart. Fighting the right ones, with the right evidence, is.

Topic 19: Stored Credentials & Scheme Compliance — Saving Cards the Right Way

Storing a customer’s card for future payments sounds simple: you collect the number once and save it. But under the hood, it’s governed by strict rules set by Visa, Mastercard, and other schemes.

If you don’t follow them? You risk failed payments, disputes, or even blacklisting.

Let’s walk through what “stored credentials” really mean — and how to keep your system compliant, secure, and scalable.

What Are Stored Credentials?

Stored credentials are card details (PAN or token) that a merchant or PSP stores to:

• Charge later (e.g. subscription renewals, one-click checkout)
• Enable features like auto-recharge, recurring billing, or saved cards

These stored details fall under Card-on-File (CoF) use cases and are subject to card network rules.

Key Scheme Compliance Requirements

1. User Consent

• You must clearly disclose what you’re storing the card for
• User must agree to terms (with checkboxes, T&Cs, or explicit flows)
• The user should be able to view and delete stored cards

2. Transaction Metadata

• Mark each transaction as CIT (Cardholder-Initiated) or MIT (Merchant-Initiated)
• Include CoF indicators in your payment request to the network
• Link MITs back to the original CIT

3. Lifecycle Management

• Handle expired, reissued, or lost cards via tokenization or card updater services

4. Notifications

• Inform users when a card is added, updated, or about to be charged
• Mandated in markets like India, the UK, and the EU

5. PSP & Vaulting Rules

• If you’re using a PSP to store cards, ensure they are PCI-DSS compliant and network token-ready
• If you store cards directly, your own systems must be PCI-compliant

Real-World Example

You’re building a payments layer for a ride-hailing app like Ola:

• A user adds their card during their first ride = CIT
• That card is stored (with consent) for future one-tap checkouts
• Later, when you charge them automatically for a ride = MIT
• You must mark that MIT correctly, reference the original CIT, and follow network CoF rules

If you don’t? Your PSP or issuer may reject the charge, flag it as fraud, or escalate to Visa compliance teams.

Why It Matters for PMs

Stored credentials power the best user experiences:

• Subscription billing
• One-click recharges
• Auto-pay for utilities or EMIs

But they can break silently if you don’t comply:

• Unlabeled MITs = declines
• Missing consent = legal exposure
• Improper vaulting = PCI violations

PMs need to own the entire card lifecycle, not just the first swipe.

Topic 20: Risk Controls for Card Payments — Your Frontline Defense Against Card Fraud

Card payments are incredibly convenient — but also one of the most common attack vectors in fintech.

As a product manager, it’s not just the fraud team’s job to think about risk. It’s your job to build the hooks for proactive fraud control, transaction monitoring, and remediation.

So let’s break down the most effective risk controls for card payments — from simple rules to sophisticated machine learning layers.

Types of Risks in Card Payments

1. Stolen Card Details — used in online checkouts (CNP fraud)
2. Synthetic Identity — fake personas with valid cards
3. Card Testing Bots — small-value transactions to validate stolen cards
4. Friendly Fraud — real users who file chargebacks after receiving service
5. Acquirer-level Risk — merchant uses stolen cards to fake GMV (first-party fraud)

Key Risk Controls You Should Implement

1. Velocity Rules

• Flag multiple attempts in short timeframes
• E.g., 3 failed payments in 2 minutes → block IP or card

2. BIN & IP Matching

• Does the user’s IP match the card’s issuing country?
• If not, consider 3DS or extra verification

3. Device Fingerprinting

• Track device/browser metadata (OS, screen size, fingerprint hash)
• Helps catch bots or repeat fraudsters using different cards

4. Behavioral Analysis

• Mouse movement, scroll speed, typing patterns
• Is this a human, or a bot trying to brute-force cards?

5. 3-D Secure (with Smart Routing)

• Trigger 3DS dynamically based on transaction risk level
• Avoid friction for good users, but add a step-up for risky ones

6. Blacklists & Whitelists

• Block known bad cards, emails, or IPs
• Fast-lane good customers who’ve built trust over time

Real-World Example

You’re a PM at Dream11. During IPL season, traffic spikes and fraudsters try to add stolen cards in bulk.

Your system:

• Flags more than 5 card add attempts per user within 10 mins
• Requires 3DS for cards from high-risk BIN ranges
• Blacklists IPs showing bot-like behavior (same browser, no user interaction)

Result? Drop in fraud attempts by 40%, minimal impact on legit users.

Why It Matters for PMs

If you’re building card flows, ask:

• Can we tune risk rules per segment (new vs repeat users)?
• Do we log and track transaction risk signals (device, IP, time of day)?
• Are we measuring false positives (good users blocked by mistake)?
• Is our PSP or fraud tool customizable, or do we need to build in-house rules?

Good fraud prevention doesn’t just stop bad actors — it protects the experience of good ones.

21. ACH, SEPA & Direct Debits — The Classic Bank-to-Bank Rails

Picture this: you’re paying rent, receiving your salary, or setting up an auto-debit for your internet bill. In most cases, no cards are involved — just bank accounts.

That’s the world of account-to-account (A2A) payments — and the three biggest global mechanisms are ACH (US), SEPA (EU), and Direct Debits (global pattern, local rules).

They may not be real-time or glamorous, but they move trillions of dollars every day.

1. What is ACH? (U.S.)

ACH (Automated Clearing House) is a batch-based electronic network in the U.S. that moves money between bank accounts.

It powers:

• Salary deposits (payroll)
• Bill payments
• Tax refunds
• Bank-to-bank transfers

ACH supports:

• Credits (you push money to someone else)
• Debits (you pull money from someone else, with authorization)

There are two speeds:

• Standard ACH: settles in 1–3 business days
• Same Day ACH: settles within hours (limited to lower-value transactions)

ACH is cheap, reliable, and widely used — but not instant.

2. What is SEPA? (Europe)

SEPA (Single Euro Payments Area) is the EU’s unified system for euro-denominated bank transfers. It enables:

• Domestic and cross-border A2A payments across 36 countries
• Low-cost, fast transfers (usually within 24 hours)
• SEPA Credit Transfers (push)
• SEPA Direct Debits (pull, often used for subscriptions and billing)

SEPA is built for efficiency and reach in the EU — think of it as Europe’s ACH.

3. What Are Direct Debits?

Direct debit is a global pattern where a merchant or service provider can pull money from your account based on your prior consent.

• In India, this could be eNACH
• In the UK, BACS Direct Debit
• In Singapore, GIRO

It’s perfect for:

• Subscriptions
• Utility bills
• EMIs and loan collections

It’s not always real-time, but it automates recurring revenue and reduces friction.

Real-World Example

You’re building a SaaS tool in the EU like Notion, and want to collect monthly fees from users.

Instead of asking for card details:

• You offer SEPA Direct Debit
• Customers provide their IBAN, sign a mandate
• Your system automatically pulls €8/month from their bank
• Costs are lower than card payments, and churn is reduced

Why It Matters for PMs

If you’re building A2A payments in the U.S., EU, or Asia:

• Understand the settlement windows (ACH ≠ real-time)
• Offer clear mandate flows for user consent
• Build webhook-driven state management (ACH returns, SEPA rejections)
• Consider when cards are overkill, and direct debit is better

Old-school doesn’t mean outdated — it means stable, regulated, and deeply embedded in business flows.

22. RTP, Faster Payments, UPI, PIX — The Real-Time Payment Revolution

Let’s say you send ₹5,000 from your bank to a friend’s. They get it in seconds. No wait. No batch settlement. No card fees.

Welcome to the world of real-time payments — A2A rails that are instant, 24/7, and frictionless.

Fintech is rapidly shifting from card rails to real-time systems like:

• RTP (U.S.)
• Faster Payments (UK)
• UPI (India)
• PIX (Brazil)

If you’re not building for real-time, you’re already behind.

What Are Real-Time Payments?

They’re systems that:

• Move money directly between bank accounts
• Settle instantly (within seconds)
• Operate 24x7x365, even on weekends and holidays
• Often come with rich messaging and metadata support

These rails are becoming the default for peer-to-peer, merchant, and payout use cases.

1. RTP (Real-Time Payments — U.S.)

• Launched by The Clearing House
• Fully live in the U.S., supported by major banks
• Supports instant push payments (not pull-based)
• Useful for payroll, gig payouts, and B2B
• Also supports Request for Payment (RfP)

2. Faster Payments (UK)

• Launched in 2008
• Enables bank transfers in seconds
• Common for salary, bill pay, reand nt
• Used by neobanks like Monzo, Revolut, and Starling

3. UPI (India)

• Built by NPCI, launched in 2016
• Combines instant A2A payments, identity resolution (via UPI IDs), and QR-based merchant flows
• Powers over 10 billion transactions/month (as of 2024)
• Free for users, cheap for merchants
• Dominates use cases from P2P, to retail, to bill pay, to lending collections

4. PIX (Brazil)

• Launched by Banco Central do Brasil
• Rapid adoption across consumers and merchants
• Enables 24/7 instant payments using email, phone, QR codes
• Now embedded in ride-hailing, ecommerce, and even social apps

Real-World Example

You’re a PM at a ride-hailing platform like Uber:

• Drivers want instant payouts
• Credit cards take 2–3 days to settle
• So you build UPI push payouts for Indian users and PIX payouts for Brazilian drivers
• Result: Better driver retention, lower operational cost, no card fees

Why It Matters for PMs

If you’re building A2A products:

• Choose real-time rails to cut out card fees and delays
• Design for 24/7 ops — no more “next business day” assumptions
• Build robust failure handling (instant = no second chances)
• Consider identity mapping (e.g., UPI IDs, aliasing, phone numbers)

Real-time payments are no longer a differentiator. They’re table stakes.

If you’re not building on RTP, UPI, or PIX yet — your competitors are.

23. Open Banking — PIS, AIS & the API-ification of Bank Accounts

Imagine if your app could read a customer’s bank balance, categorize their spending, and initiate a payment from their account — all without card rails or manual uploads.

That’s the promise of Open Banking — a global shift toward API-driven access to bank data and payments, controlled by the customer and enforced by regulation.

What Is Open Banking?

Open Banking is the practice of banks opening up their systems via secure APIs that allow licensed third-party providers (TPPs) to:

• Access bank data (with consent)
• Initiate payments on behalf of users

The customer stays in control — and gives explicit permission to connect their account.

It’s driven by regulations in some markets and market innovation in others:

• PSD2/PSD3 in Europe
• UK Open Banking Standard
• Account Aggregators (AA) in India
• Voluntary APIs in markets like Singapore, Australia, and the U.S.

Two Main Services in Open Banking

1. AIS — Account Information Services

Allows fintech apps to access user account data, such as:

• Bank balances
• Transaction history
• Income/expense categorization
• Recurring payments or subscriptions

Use cases:

• Credit underwriting (lenders like Zopa, Upstart)
• Personal finance apps (like YNAB or Walnut)
• SME cash flow tools

2. PIS — Payment Initiation Services

Allows apps to initiate payments from a user’s bank account, as an alternative to cards.

Use cases:

• One-time checkout (cheaper than cards)
• Invoice payments
• Subscription debits

In India, this is evolving under UPI Autopay and AA-linked debit flows.

Real-World Example

You’re building a lending app like KreditBee:

• Use AIS to pull real-time income and spending behavior
• Use PIS or UPI Autopay to collect EMIs from the user’s account directly
• No need for salary slips, NACH paperwork, or card authorization

Result: Faster onboarding, lower risk, and reduced operational overhead.

Why It Matters for PMs

If your product deals with:

• Credit underwriting
• A2A payments
• Income-based segmentation
• Risk profiling

You should explore:

• Which APIs are available in your region (regulated or voluntary?)
• What consents do you need to legally use data or initiate debits
• How to build smooth consent UX (trust + transparency)
• Which partners (like Yodlee, Plaid, FinBox, or Setu) support your use case

Open Banking shifts power to the user — and enables PMs to build smart, real-time, and low-cost financial flows.

24. Mandates, eNACH & Direct Debit Rules — Getting Permission to Auto-Debit

Let’s say your customer agrees to pay ₹3,000 every month for a loan, or ₹299 for a subscription.

Wouldn’t it be better if your system could automatically pull those payments from their account without asking every time?

That’s what mandates are for — pre-approved instructions to auto-debit money from a bank account, governed by formal processes like eNACH, debit mandates, and autopay rules.

What Is a Mandate?

A mandate is a legal authorization given by a customer to:

• Allow recurring debits from their account
• Define terms like amount, frequency, and validity period

Once set up, the merchant can pull funds on schedule, without re-authentication each time — within the limits of the original consent.

India-Specific: eNACH & UPI Autopay

eNACH (Electronic National Automated Clearing House)

• Managed by NPCI, enables recurring bank debits
• Used for EMIs, insurance premiums, and SIPs
• Set up involves net banking, Aadhaar OTP, or physical signature
• Operates over ACH/NACH clearing rails

UPI Autopay

• Instant, UPI-based e-mandates for small-ticket recurring payments
• Set up in-app (e.g., on a lending or subscription platform)
• OTP-based consent + collect-style flow
• Common for < ₹15,000 debits (RBI cap)
• Used by apps like Groww, Disney+, PhonePe, and OTT platforms

Mandate Lifecycle

A complete mandate flow includes:

1. Registration — Customer gives consent
2. Authentication — Bank verifies identity
3. First debit — Usually tested or zero-amount
4. Recurring execution — On schedule
5. Pause or cancel — User can revoke at any time

Mandate status must be tracked and exposed in your product UI.

Real-World Example

You’re a PM at Cred offering credit card bill payment in EMIs.

• During checkout, the user sets up a UPI Autopay mandate for 6 monthly payments
• You call the UPI intent flow
• User verifies via UPI app (e.g., GPay or Paytm)
• EMIs get auto-deducted monthly; no further action is needed
• You track failures, retries, and next due dates in your backend

Why It Matters for PMs

Mandates are the glue for any recurring A2A flow.

If you offer: Credit, Subscriptions, Bill pay, Insurance and Wealth/SIPs

You need to:

• Choose the right mandate rail (eNACH, UPI Autopay, card mandate, etc.)
• Build clear consent flows with limits
• Handle failures, cancellations, and retries gracefully
• Comply with RBI or local rules around user communication and authorization

Mandates reduce churn, improve collections, and build user trust — when implemented cleanly.

They’re not just an infra feature — they’re a core part of fintech UX and unit economics.

25. Standing Orders & Scheduled Transfers — Set It and Forget It

Imagine a salaried user who wants ₹10,000 automatically moved from their salary account to their investment account on the 1st of every month. Or a parent who wants a fixed amount transferred weekly to their child’s student account.

They don’t want to log in each time — they want it to just happen.

That’s what standing orders and scheduled transfers are designed for: automated, future-dated account-to-account payments, typically used for saving, lending, or regular internal transfers.

What Is a Standing Order?

A standing order is an instruction given by a customer to their bank to automatically send a fixed amount of money to a specific account at regular intervals — daily, weekly, monthly, or annually.

Unlike mandates or direct debits, the payment is pushed by the payer’s bank. It’s a customer-driven flow, not a merchant-initiated one.

Standing orders are common in:

• The UK and EU via Faster Payments and SEPA
• Some Indian banks through scheduled NEFT or IMPS
• Investment platforms and personal finance apps globally

What Are Scheduled Transfers?

A broader term, scheduled transfers refer to any payment that is pre-set to occur at a later date or on a recurring basis.
They’re often built into banking apps, neobanks, and wealthtech platforms.

Use cases include:

• Setting up automatic loan repayments to a friend
• Auto-transfers to savings pots or FD accounts
• Internal transfers between multiple accounts (e.g., salary to expenses)

Unlike standing orders, which are usually set via the bank directly, scheduled transfers are often built into product experiences — embedded within apps or dashboards.

Real-World Example

You’re building a neobank like Niyo or Jupiter, and you want users to build better saving habits.

You let users:

• Set up a ₹5,000 monthly transfer from salary account to a “vacation goal” wallet
• Choose the date, frequency, and destination
• Edit or cancel anytime via the app

Once set, the transfer just happens — no nudges, no reminders.

This builds trust, reduces friction, and encourages user stickiness.

Why It Matters for PMs

If your fintech product touches:

• Savings
• Lending
• Expense planning
• Wealth management
• Financial automation

You should think about:

• Offering recurring transfer features that are flexible, editable, and transparent
• Providing clear visibility into upcoming payments
• Handling insufficient balance logic with retries or alerts
• Making cancellations and modifications easy and compliant

Standing orders and scheduled transfers may not be glamorous, but they’re the backbone of long-term customer retention.

Sometimes, the best UX is invisible. Set it once — and it just works.

26. Request to Pay / UPI Collect — Flip the Flow with Pull Payments

Let’s flip the script for a second.

Instead of the payer sending money, what if the payee could send a request, and the user could simply approve it?

That’s exactly what Request to Pay (RTP) and UPI Collect flows do. They enable pull-based payments, where the receiver initiates a request and the sender consents with a click or tap.

What Is Request to Pay?

Request to Pay (RTP) is a concept used globally — most notably in the UK and EU — that allows a merchant, biller, or platform to request money from a payer, who can then approve the request through their banking app or wallet.

It’s more secure than pushing money to someone, because:

• The payee defines the amount and reason
• The payer only needs to authorize — no need to enter details
• It reduces errors, improves reconciliation, and lowers fraud risk

RTP is often used for:

• Bill collection
• Invoicing
• Gig worker payouts (reverse flow)
• One-time donations or vendor payments

What Is UPI Collect?

In India, this is called a UPI Collect request.A merchant, lender, or app sends a request to a user’s UPI ID.

The user gets a notification in their UPI app (e.g., PhonePe, GPay, Paytm), and approves it with PIN or biometric.

It’s one of the most efficient pull-payment flows — especially for:

• Loan repayments
• Subscription collection
• Pay-on-delivery for ecommerce
• Service providers (e.g., freelancers, tuition teachers)

UPI Collect also supports QR codes, intent-based flows, and auto-reminders.

Real-World Example

You’re building a lending app like KreditBee or Slice.
You want to collect EMIs without relying on card or netbanking every time.

Here’s the flow:

• On the due date, you trigger a UPI Collect request to the user’s ID
• They receive a notification on their UPI app
• They authenticate via PIN
• The EMI is paid, without visiting your app or logging in

It’s fast, frictionless, and doesn’t require you to store sensitive card or account data.

Why It Matters for PMs

If you’re building in:

• Lending
• P2P payments
• Bill pay
• Gig economy
• Donation platforms

RTP/Collect flows let you:

• Move away from payer-initiated friction
• Collect on time with real-time notifications
• Reduce fraud (payer must authorize the pull)
• Improve conversion and compliance

Make sure you:

• Have fallback flows for missed or declined requests
• Retry requests with logic (e.g., time-based intervals)
• Offer clear transaction history and consent records

Request to Pay flips payment UX from “go find and pay” to “approve when asked.” It’s the future of bill collection and merchant flows.

27. Bank Account Verification & Microdeposits — Are You Sending Money to the Right Account?

You’re building a P2P wallet, lending app, or payout platform. A user adds their bank account — and you now need to verify it.

Is it really their account? Did they mistype the number? Or worse… are they trying to route money somewhere they shouldn’t?

Bank account verification is the process of ensuring that the account details provided by a user actually belong to them — before you allow any money movement.

Why Verification Matters

When you skip account verification:

• Payouts can fail due to invalid account or IFSC/branch mismatches
• Funds may be misrouted to the wrong person
• Fraudsters can redirect money to mule accounts
• Refunds or reconciliations become messy and time-consuming

It’s a classic case of “garbage in, garbage out.” If you don’t catch it at the input stage, you’ll pay for it later.

Common Verification Methods

1. Penny Drop / Microdeposit

You send a small amount (₹1 or $0.01) to the provided account and check if:

• The transaction succeeds
• You get the correct account holder name back from the bank or PSP
• This matches the user’s KYC name

This is low-cost, reliable, and widely supported — but not always real-time.

2. Real-Time API Verification

Some partners (e.g., Cashfree, Decentro, Plaid, FinBox) offer instant bank account verification using regulated access to NPCI or banking networks.

These APIs verify:

• Account status (active/inactive)
• Holder name
• IFSC or branch validation
• In some cases, even match to PAN or Aadhaar

This speeds up onboarding and reduces operational load.

Real-World Example

You’re a PM at RazorpayX, enabling businesses to send vendor payouts.

• Vendors add their bank details to your dashboard
• You run a microdeposit + name match behind the scenes
• If there’s a mismatch (e.g., account is in someone else’s name), you flag it for the user
• Only verified accounts are allowed to receive money

This reduces payout failures and prevents fraud via impersonation.

Why It Matters for PMs

If your product allows:

• Payouts
• Refunds
• Salary transfers
• Credit disbursals

You must:

• Build verification into your onboarding flow
• Support retry or correction UX for failed attempts
• Set thresholds (e.g., high-value payouts need re-verification)
• Integrate with PSPs that offer instant APIs or fallback to microdeposits

A failed payout may cost ₹5 to fix. A wrong payout could cost you ₹50,000 + user trust.

Don’t wait to verify at the point of failure. Verify up front.

28. Virtual Accounts & Account Tokenization — Scaling Reconciliation Without the Headaches

Let’s say you’re running a marketplace. Hundreds of sellers are receiving payments daily. How do you track which ₹10,000 came from which customer… and which seller it belongs to?

This is where virtual accounts and account tokenization come in — they help fintechs track, reconcile, and scale A2A flows without needing a new bank account for every user.

What Are Virtual Accounts?

A virtual account is a unique, system-generated bank account number that’s mapped to a specific customer, vendor, or transaction.

It’s not a real, standalone bank account — it’s an alias created by your payment partner (PSP or bank) to tag incoming payments.

When money is sent to that virtual account:

• It lands in a pooled account owned by your platform
• You know exactly who sent what and why, based on the virtual ID
• You can instantly attribute the payment in your ledger or CRM

Why Use Virtual Accounts?

• No need to open a new bank account per user
• Instant, automated reconciliation of incoming payments
• Works well for B2B collections, lending, tuition, gig platforms, etc.
• Reduces operational effort and fraud risk
• Let's you build “bank-like” experiences without full infra

Virtual accounts can be one per:

• Customer
• Vendor
• Invoice
• Transaction

This makes them incredibly flexible.

What Is Account Tokenization?

Different from card tokenization, account tokenization refers to replacing a real bank account number with a virtual alias or token, for security and privacy.

This is useful for:

• Storing user bank details securely
• Abstracting real account numbers during API calls
• Building trust in B2B or marketplace flows

Instead of sharing your real bank account, you share a tokenized version — and only the platform or PSP can decode and route the funds.

Real-World Example

You’re a PM at a lending platform like Indifi.

• You assign each borrower a unique virtual account for EMI repayment
• When they transfer ₹5,000, the system knows exactly which borrower made the payment
• The amount lands in your platform’s pool account but gets auto-attributed in real time

No need for UTR checks, CSV uploads, or manual tagging.

Why It Matters for PMs

If you’re building: B2B fintech, Marketplaces, Lenders, Wealth apps and Gig platforms

You should:

• Use virtual accounts to simplify incoming reconciliation
• Leverage tokenization to keep user data secure
• Offer transaction-level tracking and references
• Work with providers like Cashfree, Setu, RazorpayX, or banks with VA support

Scaling A2A payments without virtual accounts is like running a call center without phone numbers.

It works… until you grow. Then it breaks.

29. Payouts, Mass Payouts & Payroll Rails — Moving Money at Scale

SpLet’s say your platform needs to pay 10,000 gig workers every week. Or send daily commissions to thousands of sellers. Or process payroll for 500 employees every month.

Doing outhat with one transfer at a time? Impossible.

That’s where payout infrastructure and mass disbursement rails come in — the backbone of modern fintech platforms handling scale, speed, and reliability in money movement.

What Are Payouts?

A payout is any outgoing transfer of funds from a business or platform to:

• A customer
• A vendor
• An employee
• A third-party beneficiary

These could be:

• Refunds
• Loan disbursals
• Cashback or rewards
• Salary payments
• Insurance settlements

Payouts can be one-time or recurring, low-value or high-value, manual or automated — depending on the use case.

What Are Mass Payouts?

Mass payouts involve sending money to many recipients at once, with automated mapping, retry logic, and success tracking.

You’re not uploading files and clicking buttons 1,000 times — you’re integrating with a system that:

• Accepts bulk payout files or API calls
• Validates account details and balances
• Sends payments in parallel
• Tracks status, failures, and returns
• Posts webhook or event logs for real-time reconciliation

Common rails used:

• IMPS, NEFT, UPI (India)
• ACH, RTP (U.S.)
• PIX (Brazil)
• Faster Payments (UK)
• Partner APIs from providers like RazorpayX, Cashfree, Stripe Connect, Deel, or Payoneer

What Are Payroll Rails?

When paying salaries at scale, you may use specialized flows:

• Bank-to-bank payroll integrations (with corporate netbanking or salary APIs)
• White-label solutions that combine salary, tax, and compliance
• Auto-scheduled flows tied to attendance or HRMS systems
• Smart handling of weekends, holidays, and failed debits

Good payroll systems also support:

• Payslip generation
• PF/ESI/TDS deductions (India)
• Perks, advances, and bonuses

Real-World Example

You’re the PM at a logistics startup like Shadowfax.

• You need to pay 25,000 delivery partners weekly
• You set up automated UPI payouts via your PSP’s bulk payout API
• Failed payouts are flagged and retried automatically
• You use RazorpayX’s dashboard to track payout status, download reports, and reconcile balances
• Partner balances are updated in real time in your own app

This system scales without growing your ops team.

Why It Matters for PMs

If you’re handling disbursements of any kind:

• Choose the right payout rail per geography and use case
• Decide between API vs dashboard-based operations
• Automate balance management, failure handling, and status tracking
• Ensure KYC-compliant onboarding for payout recipients
• Maintain real-time visibility for your internal ops and your users

Great fintech products don’t just collect money well — they disburse money better.

30. Wires & High-Value RTGS Systems — When Speed Isn’t Optional

Not all payments are small. Sometimes, you need to move ₹50 lakhs, $250,000, or €1 million — fast, securely, and irrevocably.

That’s the world of wires and high-value real-time settlement systems like RTGS, CHIPS, Fedwire, TARGET2, and their equivalents across countries.

These aren’t consumer flows — they’re enterprise-grade, and used when accuracy, speed, and finality matter more than cost.

What Is a Wire Transfer?

A wire transfer is a high-value, point-to-point transfer between banks — often across countries — using a secure interbank network like:

• SWIFT (international messaging layer)
• RTGS (domestic, real-time gross settlement systems)
• CHIPS, Fedwire (U.S.)
• TARGET2 (Europe)
• BOJ-NET, LVTS, and others (Asia, Canada, etc.)

Wires are typically used for:

• Large B2B payments
• Settlements between institutions
• Escrow releases
• Treasury or fund movements
• IPO or bond transactions

What Is RTGS?

RTGS stands for Real-Time Gross Settlement. Unlike ACH or NEFT (which are batch-based and lower value), RTGS:

• Settles each transaction individually and in real time
• Has no netting or delay
• Handles only large-value payments (₹2 lakhs and above in India)
• Operates during specific hours, though 24x7 models are emerging

Think of RTGS as the fast lane for big money, where trust, finality, and system stability are paramount.

Why Not Use a Card or UPI for These?

• Cards have transaction limits and require customer presence
• UPI is capped (₹1–2 lakhs per day per user) and lacks full certainty for high-value
• NEFT or ACH are batch-based and slow
• Only RTGS or wire systems offer finality + real-time + volume support

They’re more expensive, but necessary when:

• Payment failure is not acceptable
• Reversals are operationally risky
• Bank confirmation is required immediately

Real-World Example

You’re a PM at a B2B cross-border payments company like Wise or Instarem.

• Your customer wants to move $500,000 to a supplier in Germany
• You trigger a SWIFT message via TARGET2 to the recipient’s bank
• You track status via MT103 or gpi trace, and notify your customer when funds settle
• Compliance and FX conversion are handled midstream
• The transaction clears within hours, not days

The same customer may also use RTGS domestically to fund their wallet before the international leg begins.

Why It Matters for PMs

If your product supports:

• Cross-border B2B payments
• Treasury operations
• Lending to SMEs or large disbursals
• Escrow or settlements
• Institutional wallets or banking platforms

You need to:

• Understand when to use wire/RTGS vs batch or instant
• Know the operational cutoff times and holidays
• Provide transaction reference tracking (e.g., UTR or MT103)
• Handle exceptions, reversals, or manual ops escalations gracefully

Wire transfers are boring… until you’re moving $1M and can’t afford to get it wrong.

For a deeper dive, I highly recommend the course. It costs less than a burger yet delivers exceptional value for anyone looking to break into Fintech.

Fintech BootCamp: Master Financial Ecosystem

31. Cross-Border Remittances & Corridors — The Maze of Moving Money Internationally

Let’s say a user in the UK wants to send money to their parents in India. They use your app, tap “Send,” and ₹25,000 lands in their parents’ account in minutes.

But behind the scenes? That money didn’t fly over — it went through a chain of banks, partners, and regulatory gates, across what we call a remittance corridor.

What Are Cross-Border Remittances?

Cross-border remittances are international money transfers made from one country to another, usually:

• By migrant workers to families back home
• By global freelancers receiving client payments
• For tuition, medical expenses, or family support

They are typically low-to-mid value, high volume flows — and incredibly price-sensitive.

What Is a Corridor?

A remittance corridor is a directional payment flow between two countries — for example:

• US → Mexico
• UAE → India
• UK → Nigeria

Each corridor has its own:

• Preferred rails and partners
• Pricing models and fees
• Regulatory hurdles
• Currency exchange processes

Some corridors are well-trodden, high-volume, and efficient. Others are costly, fragmented, or underbanked.

How Money Moves Across Borders

1. The sender initiates a transfer on an app (e.g., Wise, Western Union, Remitly)
2. The platform holds a nostro account in the recipient country’s currency
3. The sender’s money funds the transfer in their home country
4. The platform or its partner pays out locally in the recipient country — no actual money “travels” across borders

In most cases, funds are pre-funded or settled via banks, aggregators, or card networks.

Real-World Example

You’re a PM at a remittance platform targeting Gulf → India users.

• The sender pays in AED using a local payment method
• Your partner in India pays out in INR to the recipient’s bank via IMPS or UPI
• The platform earns via FX markup + service fee, and reconciles daily between entities
• You optimize for speed, payout success, and regulatory compliance

Why It Matters for PMs

Cross-border products are deceptively complex. As a PM, you must:

• Understand the corridors you operate in — what’s easy in US→UK may be hard in Kenya→India
• Choose the right partners for origination and payout (local PSPs, banks, agents)
• Handle KYC, AML, and local compliance at both ends
• Track FX rates, margin, and settlement risk
• Build fallback paths (e.g., if one payout partner fails)

Cross-border payments aren’t just a product — they’re a choreography of systems, licenses, and local trust.

32. FX Pricing — Spot, Spread & Markup Explained Simply

You see it everywhere: “No hidden fees.” But then you realize your $100 transfer to Mexico became $91 in pesos, not $95.

What happened? Welcome to foreign exchange pricing, where platforms make (or lose) money in the spread — the difference between spot rates and what the customer gets.

What Is a Spot Rate?

The spot rate is the real-time price at which one currency can be exchanged for another in the open FX market — say, USD to INR or EUR to GBP.

This rate:

• Changes constantly based on supply, demand, and macro conditions
• It is influenced by central banks, market movements, and geopolitical risk
• It is not directly accessible to consumers or even most fintechs

It’s the base rate used to calculate everything else.

What Is the FX Spread?

The spread is the difference between the buy rate and sell rate offered by a provider. It’s how banks, platforms, and liquidity providers make money on conversions.

For example:

• Spot rate = 1 USD = ₹83.20
• Your app offers 1 USD = ₹81.90
• The spread is ₹1.30 per USD — the provider’s markup

Some platforms are transparent (e.g., Wise shows mid-market + fee). Others bundle the fee into the rate, claiming “zero fees” but charging silently through the spread.

Components of FX Pricing

1. Spot rate — the raw exchange rate from the market
2. Spread/markup — platform adds a buffer to earn revenue
3. Conversion fee — additional flat or % fee on top (not always disclosed)
4. Partner costs — banks or PSPs involved may also take a cut

If you’re not managing these actively, you’re either losing money or overcharging without knowing it.

Real-World Example

You’re a PM at a multicurrency wallet like Revolut or NiYO Global.

• A user loads $1,000 and converts it to EUR to spend on vacation
• You use real-time FX data from liquidity providers
• You offer spot rate + 0.5% markup during market hours, +1% on weekends
• You display the rate breakdown, estimated fee, and lock-in time to the user

This builds trust, transparency, and predictability — and gives your product a pricing edge.

Why It Matters for PMs

FX pricing decisions affect:

• Your unit economics (spread = revenue or cost)
• Your conversion funnels (users drop off if rates seem unfair)
• Your transparency and trust
• Your margin per corridor or product

You should:

• Benchmark against market leaders regularly
• Track real vs offered rates and monitor user sensitivity
• Decide when to fix rates (pre-quote) vs float them (real-time)
• Build smart pricing rules (e.g., lower markup for VIPs, higher during volatility)

FX is not just a backend operation — it’s a frontline product and monetization lever.

The right FX pricing can make your product globally scalable, locally competitive, and financially sustainable.

33. Correspondent Banking & SWIFT — The Backbone of Global Payments

Here’s a puzzle: You’re in Kenya. Your bank wants to send $10,000 to someone in Peru. But the two banks don’t know each other. They’re not connected.

So how does the money move?

Enter the world of correspondent banking and SWIFT — a vast, behind-the-scenes network that connects the world’s banks and enables money to flow between them.

What Is Correspondent Banking?

Correspondent banking is a system where banks hold accounts with one another and act as intermediaries to send money internationally — especially when the sender’s and receiver’s banks don’t have a direct relationship.

In simple terms:

• Your bank (Bank A) sends money to a correspondent bank it partners with
• That bank knows how to reach Bank B (the receiver’s bank)
• It forwards the funds accordingly

This creates a chain of trusted relationships, enabling fund transfers across countries and currencies — even when there’s no direct link.

Why Is This System Needed?

• Not every bank has a global presence or branches everywhere
• Many operate only domestically
• Correspondent banks bridge the gap and offer access to international clearing systems

It’s like routing a letter through several post offices until it reaches its final destination.

What Is SWIFT?

SWIFT (Society for Worldwide Interbank Financial Telecommunication) is:

• A messaging network (not a money transfer network)
• Used by 11,000+ institutions in 200+ countries
• It sends standardized messages between banks to execute cross-border transfers

For example:

• MT103 message = “Send $1,000 from this account to that one”
• The actual funds settle later via the banks’ accounts (like Nostro/Vostro — more on that next)

SWIFT doesn’t hold money. It ensures everyone speaks the same language securely and reliably.

Real-World Example

You’re a PM at Wise (formerly TransferWise). A user in Canada wants to send money to Ghana.

Your platform:

• Uses local banking partners in both countries
• Sends a SWIFT message to trigger payout from a Ghanaian bank’s account
• Uses correspondent partners where direct reach is missing
• Tracks the flow using SWIFT GPI (Global Payments Innovation) to get near real-time updates

Why It Matters for PMs

If you work on cross-border money movement, you need to understand:

• Who your correspondent partners are (and their cut of the fees)
• Which currencies/countries require longer chains
• How long funds take to settle, and what delays or failures look like
• The structure and tracking of SWIFT messages (MT103, MT202)
• How FX and compliance costs change at each hop

Most cross-border delays and costs aren’t product issues — they’re infrastructure issues.
As a PM, knowing where the “friction” lies helps you set better expectations and build smarter systems.

34. Nostro/Vostro Accounts — The Hidden Ledger Entries That Move the Money

Let’s say Bank A in the U.S. wants to pay Bank B in India. How does it send the actual money?

Does it wire cash? Move gold bars?

No — it uses pre-funded accounts, maintained with each other. That’s where Nostro and Vostro accounts come in.

They’re like the tabs banks keep with one another, and they are critical for cross-border settlement and FX transactions.

What Are Nostro and Vostro Accounts?

• A Nostro account (Latin for “ours”) is a bank’s account in a foreign country, held in that country’s currency
• A Vostro account (Latin for “yours”) is how the foreign bank refers to the same account

So:

• From the U.S. bank’s point of view: “This is our account in India” → Nostro
• From the Indian bank’s point of view: “This is your account with us” → Vostro

They are the same account, just seen from opposite sides.

Why These Accounts Exist

They allow banks to:

• Pre-fund balances in foreign currencies
• Settle cross-border transactions instantly (no real-time money movement needed)
• Simplify FX conversions and treasury ops

Every time a remittance or trade settlement occurs, money is debited/credited via these accounts — not by moving physical cash.

Real-World Analogy

Think of a bar tab between friends:

• You paid for pizza last week
• I bought the drinks yesterday
• Instead of settling every time, we track balances and settle up later

Nostro/Vostro accounts are how banks do this — at a global scale.

Real-World Example

You’re a PM at a cross-border platform like Airwallex.

• You hold a Nostro account in EUR with a French bank
• When a merchant in India wants to pay a supplier in France:
• You debit your EUR Nostro balance
• Credit the supplier via the local French rails
• The INR equivalent is debited from the Indian sender’s wallet
• No international wire needed — just internal ledger movements

This makes your service faster, cheaper, and compliant with local FX laws.

Why It Matters for PMs

Nostro/Vostro accounts affect:

• Your ability to settle fast in foreign currencies
• How much pre-funding and liquidity do you need in each corridor
• The timing and cost of reconciliation and FX
• Your counterparty risk (what if the partner bank freezes your funds?)

As a PM, you should:

• Work closely with your treasury or FX team to understand your liquidity positions
• Monitor account balances to avoid payment failures or delays
• Design fallback strategies in case a Nostro partner goes offline

If SWIFT is the message, Nostro is the money. Without funded accounts, your rails don’t move.

35. Multi-Currency Wallets & Balances — One Wallet, Many Currencies

Imagine a user who gets paid in USD, spends in GBP, and invests in INR — all through a single app.

That’s the magic of multi-currency wallets: a unified account that can hold, manage, and convert multiple currencies at once, without needing multiple bank accounts.

What Is a Multi-Currency Wallet?

A multi-currency wallet is a digital wallet that lets users:

• Hold balances in different currencies (e.g., USD, EUR, GBP, INR)
• Convert between them at market or marked-up rates
• Spend or send in any of those currencies, based on their needs

It abstracts away the complexity of FX, correspondent banking, and conversion — while giving users control and visibility over their money in each currency.

How It Works Under the Hood

Multi-currency wallets rely on:

• Pooled accounts or Nostro accounts in different countries
• Ledger-level architecture to separate balances per currency
• FX partners or liquidity providers for real-time conversions
• Local payout rails to enable disbursement in local currency
• Smart routing to pick the right currency for each transaction

For the user, it’s a clean UI. For the fintech, it’s a complex system of sub-ledgers, FX pricing, and treasury ops.

Real-World Use Cases

• Travel cards (e.g., Niyo Global, Revolut): Hold multiple currencies and spend like a local
• Freelancer wallets (e.g., Wise, Payoneer): Receive in USD, convert and withdraw in local currency
• Crypto offramps: Convert crypto to fiat in a chosen currency
• SME tools: Invoice in one currency, collect in another, manage FX impact

Real-World Example

You’re a PM at Wise.

• A user in India receives USD from Upwork
• They convert $200 to INR at a 0.5% markup on spot rate
• The remaining $800 sits in their USD balance
• They later use it to pay for an Amazon UK order in GBP — Wise auto-converts USD to GBP using the best available FX rate
• The user can see each currency balance, conversion history, and fees clearly

This creates a bank-like experience, but better — real-time, transparent, and user-controlled.

Why It Matters for PMs

Multi-currency wallets involve:

• Smart product architecture: one ledger, many sub-balances
• Clear user controls: select preferred currency, convert when needed
• Risk management: holding multiple currencies involves FX exposure
• Partner strategy: FX liquidity, local banks, wallet licenses

A great multi-currency experience gives users global flexibility with local simplicity.
PMs who build this well win trust and repeat usage.

36. Dynamic Currency Conversion (DCC) — The Hidden Cost of Convenience

Ever swiped your card abroad and seen this prompt:
“Would you like to pay in your home currency or local currency?”

If you choose your home currency (say INR), you just fell into the trap of Dynamic Currency Conversion (DCC) — a “helpful” feature that often costs more than you think.

What Is DCC?

Dynamic Currency Conversion lets foreign merchants or ATMs offer cardholders the option to pay in their own currency instead of the local one.

It sounds good:

• Transparent pricing
• No surprise FX on your statement
• Easier to mentally compare costs

But here’s the catch — the exchange rate is usually poor, and extra fees are often hidden in the conversion.

How It Works

1. You swipe your INR card at a store in London
2. The terminal detects it’s an Indian-issued card
3. It offers: “Pay £100 in INR or GBP?”
4. If you choose INR, the terminal or processor applies a merchant-controlled FX rate
5. That rate may include a 3–7% markup
6. The payment settles in INR, and you avoid FX fees from your bank — but you just overpaid

So while DCC adds transparency, it removes control from the user and gives pricing power to the merchant or acquirer.

Real-World Example

You’re building a travel card product like NiYO Global.

A user swipes the card in Singapore:

• The merchant’s terminal offers DCC (₹6,300) vs SGD ($100)
• User picks INR out of convenience
• But the DCC rate was 4.5% worse than Visa’s interbank rate
• Your platform has to educate the user post-facto, even though you didn’t control the terminal

It impacts user trust, perception of your product, and long-term usage.

Why It Matters for PMs

If you issue cards or support cross-border card spend:

• You don’t control DCC — it’s merchant-side
• But you can educate users to “always pay in local currency”
• You can display real-time FX rates in your app
• You can offer rate lock features or transparent alerts post-transaction

Also consider:

• Monitoring where DCC is frequently offered
• Surfacing alerts and guidance in-app after such spend
• Providing comparison tools to build user trust

DCC isn’t illegal — but it’s often misleading. Your product doesn’t own it, but your user blames you for it.

37. Local vs Cross-Border Acquiring — The Hidden Driver of Payment Conversion & Cost

Let’s say a Nigerian cardholder tries to pay a UK-based merchant. The card works — but the transaction fee is high, and the approval fails.

Why?

Because it was processed via cross-border acquiring, not local acquiring — and that makes all the difference in cost, success rate, and user experience.

What Is Acquiring?

An acquirer (aka acquiring bank or PSP) is the financial institution or provider that enables a merchant to accept card payments.

Every card transaction involves:

• Issuer (user’s bank)
• Network (Visa, Mastercard, etc.)
• Acquirer (merchant’s bank)

Acquiring can be local or cross-border, depending on where the merchant and customer are based.

Local vs Cross-Border Acquiring

Local acquiring:

• Merchant uses an acquirer based in the same country/region as the customer’s card issuer
• Result: Lower cost, higher approval rates, better compliance

Cross-border acquiring:

• The acquirer is in a different country from the cardholder
• Often leads to:
• Higher decline rates (due to risk filters)
• Higher MDRs (fees)
• FX conversion costs
• Increased chance of fraud flags

For example:

• Indian user paying a Singapore merchant via a Singapore acquirer = cross-border
• Same user paying through Razorpay (Indian acquirer) = local

Why Local Acquiring Wins

• Better success rates
• Lower interchange + scheme fees
• Avoids FX markups and card rejections
• Often compliant with local card scheme rules (e.g., Rupay, Elo, etc.)

Real-World Example

You’re a PM at Stripe launching in Brazil.

• To serve Brazilian merchants well, you need local acquiring partnerships (e.g., via Stone or Ebanx)
• Otherwise, international card transactions from Brazilian users are processed cross-border
• Many fail due to local card scheme restrictions and tight fraud controls
• By setting up local acquiring, you dramatically increase the success rate and revenue per merchant

Why It Matters for PMs

If you’re building a global payment product:

• Understand where your users are and what cards they use
• Support local acquiring in top countries (either directly or via PSPs)
• Monitor success rates by BIN country vs merchant acquirer location
• Consider multi-acquirer routing based on the user’s geography

Users don’t care how acquiring works — but they’ll drop off if it fails.
As a PM, owning this layer means you control success rate and margin.

38. Sanctions Screening in Cross-Border — Blocking the Bad Guys (and Avoiding Fines)

Here’s a nightmare scenario:

You unknowingly process a payment for someone in North Korea, or send money to an entity under U.S. sanctions.

Your platform gets flagged. Your partner bank freezes your account. You’re hit with massive fines.

This is why sanctions screening is mandatory in cross-border payments. It’s not optional. It’s the law.

What Are Sanctions?

Sanctions are government-imposed restrictions on individuals, companies, banks, and even entire countries — meant to:

• Prevent terrorism financing
• Block money laundering
• Enforce foreign policy

Sanctions lists are published by:

• OFAC (U.S.)
• UN, EU, UK (FCA)
• India (RBI), Singapore (MAS)
• FATF “blacklists” and “greylists”

These lists include:

• Individuals (e.g., drug lords, terrorists)
• Entities (e.g., shell companies, rogue banks)
• Countries (e.g., North Korea, Iran, Syria)

What Is Sanctions Screening?

It’s the process of checking every cross-border transaction and user against global sanctions lists to ensure:

• You’re not enabling prohibited transactions
• You’re not working with banned individuals/entities

Screening happens:

• At onboarding (KYC, KYB)
• During transactions (name + country match)
• For payouts and beneficiaries (recipient banks/accounts)

Matches can result in:

• Automatic blocks
• Manual review
• Suspicious activity reports (SARs)

Real-World Example

You’re a PM at Airwallex, powering B2B payments between Asia and Europe.

• A company signs up with a UBO (ultimate beneficial owner) based in Crimea
• Your onboarding flow runs KYB + sanctions screening
• The system flags a match with an OFAC-listed entity
• You block onboarding, trigger internal review, and file a report

This prevents your company from violating international law and protects your bank partners, too.

Why It Matters for PMs

If you’re moving money across countries:

• You are legally responsible for screening
• You must integrate with AML/sanctions providers (e.g., ComplyAdvantage, Sift, Alloy)
• You must build:
• Real-time alerting
• Manual case management
• Review queues + audit trails

Also, pay attention to:

• False positives (e.g., someone named “Mohammad Khan” isn’t always a terrorist)
• Keeping screening rules updated per region
• Data quality (bad name matching = risk)

Sanctions compliance is like brakes on a car — you don’t win races with it, but you crash without it.

As a PM, building a compliant, reliable screening system protects your product, partners, and reputation — and keeps you off regulatory radar.

39. Treasury, Liquidity & Float Management — The Fintech PM’s Silent Power Lever

You’ve built a slick international wallet. UX is clean, onboarding is smooth, and FX conversion is fast.

But what happens when:

• You don’t have enough GBP to fulfill today’s payouts?
• Your EUR float is stuck in a Vostro account that’s yet to settle?
• A partner bank in the U.S. is offline and can’t disburse USD?

Now your entire product grinds to a halt.

That’s why treasury and liquidity management is the silent, invisible, and essential layer behind all global fintech operations.

What Is Treasury Management?

In fintech, treasury management means:

• Monitoring balances across currencies, accounts, and partners
• Forecasting cash inflows and outflows
• Maintaining float to ensure real-time disbursals
• Managing FX exposure, working capital, and regulatory buffers

It ensures you have the right money, in the right place, at the right time, with minimal cost and maximum efficiency.

Key Concepts

• Float: The pool of money pre-funded into accounts to fulfill user requests
• Liquidity: How easily you can access cash (in any currency) to meet obligations
• Working capital: Funds required to operate the product on a day-to-day basis
• Rebalancing: Moving float across geographies or currencies to meet demand
• Cash burn optimization: Keeping float lean without causing transaction failures

Real-World Example

You’re a PM at a cross-border platform like Payoneer.

• You hold balances in 8+ currencies with different banks globally
• You observe that Indian freelancers are withdrawing more INR than expected this month
• Your treasury team has to rebalance float from a lower-demand corridor (e.g., SGD) into INR
• You must also maintain minimum buffer limits to ensure 100% payout success — even during volatility

All this is transparent to the user, but critical to product performance.

Why It Matters for PMs

You may not own treasury, but your product depends on it. You must:

• Set up dashboards that track balances per corridor
• Forecast user behavior and payout trends
• Align with your finance team to avoid liquidity bottlenecks
• Support fallback flows (e.g., if one payout partner runs dry)
• Help define float strategy during product launches in new geos

When liquidity fails, it’s not a backend problem. It’s a PM failure in disguise.

40. Cross-Border RTP & 24/7 Settlement — Real-Time, Real Money, No Delays

Imagine this: It’s 3 a.m. on a Sunday. A user in the U.K. sends money to a freelancer in the Philippines. The freelancer gets paid in 10 seconds.

No bank hours. No T+2 delay. No, “funds will reflect shortly.”

That’s the vision of cross-border RTP (Real-Time Payments) and 24/7 settlement — a new frontier in global fintech.

The Old World vs The New

Traditional cross-border payments:

• Involve multiple intermediaries
• Settle in batches (e.g., once per day)
• Are constrained by business hours and cut-off times
• Take 1–3 business days, sometimes longer

Cross-border RTP:

• Enables real-time or near-instant transfers
• Leverages instant domestic rails + connected APIs
• Reduces reliance on SWIFT MT messages and batch files
• Allows 24x7 operations — including nights and holidays

What’s Powering This Shift?

1. Domestic RTP systems like: UPI (India), Faster Payments (UK), PIX (Brazil), FedNow (U.S.) and PayNow (Singapore)

2. Interlinking RTP rails across borders (e.g., Singapore–India UPI–PayNow)

3. Private RTP networks (like Visa Direct, Mastercard Send)

4. ISO 20022 messaging enabling richer, interoperable data formats

Real-World Example

You’re the PM at Wise or Revolut.

• You offer near-instant payouts from Europe to India
• You connect with Faster Payments in the UK → partner bank → IMPS/UPI in India
• The payout clears in seconds, even on weekends
• You notify users with a real-time webhook and ledger update
• Treasury is pre-funded in India, so there’s no settlement lag

This delights users and sets a conversion benchmark.

Challenges and Watchouts

• Not all countries support instant settlement
• FX still needs pre-funding or smart pricing models
• You need payout licenses or partnerships in each destination
• Compliance and fraud risk increase with speed — so AML must be real-time too
• Reconciliation must be bulletproof to avoid downstream ledger issues

Why It Matters for PMs

If your product involves:

• Gig economy payouts
• Remittances
• Travel or spend cards
• Crypto off-ramps
• SME merchant wallets

Then instant settlement = product differentiation.

You should:

• Work with providers that support RTP rail
• Design around timeouts, retries, and failover paths
• Expose status updates to users (e.g., “in progress”, “credited”)
• Monitor settlement health and FX coverage

RTP is not just speed — it’s a trust-building feature disguised as infrastructure.

As a PM, it’s your job to make “instant” truly feel instant, even if there’s complexity underneath.

41. Core Banking Systems & Ledgers — Where the Money Actually Lives

Let’s imagine you build the perfect neobank app — smooth onboarding, sleek UI, and instant transfers.

But under the hood, where is the money? Where are the balances stored? What determines whether a payment can be made?

That’s the job of the core banking system (CBS) and its ledger — the beating heart of any financial institution.

What Is a Core Banking System?

A Core Banking System is the back-end engine that:

• Maintains all customer account balances
• Posts debits and credits
• Enforces rules like overdrafts, interest, and holds
• Reconciles transactions and end-of-day positions
• Talks to card networks, payment switches, and regulators

In simple terms: it’s the system of record — the source of truth for every penny in your bank or fintech product.

Ledgers: The Foundation of Money Movement

A ledger is a structured log of:

• Every transaction
• Every change in balance
• Who did what, when, and why

It’s not just a balance sheet — it’s an audit-proof timeline of your financial history.

There are typically:

• Customer ledgers: balance per user/account
• Product ledgers: e.g., cards, loans, savings
• Settlement ledgers: clearing between internal or partner accounts

Some fintechs build custom ledgers using tools like PostgreSQL or ledger-as-a-service APIs (e.g., Basis Theory, Moov, Treasury Prime, Synctera).

Real-World Example

You’re a PM at a digital bank like Monzo or Nubank.

• When a user pays with their card, the core system first checks available balance in the ledger
• If approved, a hold is placed, the transaction is posted, and the ledger is updated
• At end of day, settlement batches are run, recon confirmed, and reporting logs are sent to the central bank
• Everything is timestamped and version-controlled — for compliance, fraud, and audits

Even a minor inconsistency in your ledger can bring down the entire product.

Why It Matters for PMs

If your product holds money:

• Know where the ledger lives (yours, partner bank’s, or third-party)
• Understand the posting logic: what triggers a debit? what rules block it?
• Build idempotent APIs — the same transaction shouldn’t post twice
• Design for atomicity — balances should never be in an in-between state
• Support ledger queries for user transparency, reconciliation, and reporting

A broken ledger means broken trust. And fintech without trust is just a design exercise.

42. Deposit Accounts: Checking, Savings, Current — The Building Blocks of Banking

Let’s say you give users a digital wallet. Great. But is it a checking account? A savings account? A current account for businesses?

These distinctions aren’t just naming — they define:

• Features & limitations
• Regulatory compliance
• Interest earnings
• Fund access rules

Understanding deposit account types is vital to offering the right product to the right customer.

1. Checking Accounts (U.S.) / Current Accounts

• Designed for frequent use
• Used for spending, paying bills, and receiving salary
• Usually no interest (or very low)
• Often linked to debit cards and payment rails
• Can have overdraft facilities

Think of it as a transactional account — your default place for daily money flow.

2. Savings Accounts

• Meant for storing money and earning interest
• Often come with withdrawal limits or lower transaction frequency
• Interest rates vary by bank, country, and central bank policy
• In some countries, they are regulated differently (e.g., minimum balance, withdrawal limits)

Fintechs often blend savings with rewards to make it feel modern (e.g., “4.5% returns with no lock-in”).

3. Current Accounts (Businesses)

• Used by businesses or self-employed users
• Handle large volumes and higher balances
• No interest typically, but offer features like bulk payments, overdrafts, or expense tracking
• Can integrate with invoicing, payroll, and accounting software

These are often customized per segment: e.g., freelancers, small businesses, exporters.

Why It Matters for PMs

If your fintech offers account-like features:

• Decide what kind of account it truly is
• Understand the regulations that apply (e.g., interest calculation, withdrawal rules)
• Map out user flows per account type (salary vs savings vs merchant)
• Ensure ledger, KYC, and compliance logic align
• Make it easy to switch or segment funds (e.g., “spend pocket” vs. “savings pocket”)

The account type you offer defines not just features — it defines trust, utility, and legal standing.

43. KYC & Identity Proofing — Verifying Who Your Customer Really Is

Every fintech product starts with the same question: “Who are you?”

That’s the role of KYC (Know Your Customer) and identity proofing — ensuring you know exactly who’s using your platform, so you can prevent fraud, meet regulations, and build trust.

What Is KYC?

KYC is the regulated process of verifying a customer’s identity before allowing them to use financial services.

It’s a legal requirement in most countries, enforced to:

• Prevent money laundering (AML compliance)
• Stop terrorist financing (CFT compliance)
• Reduce fraud risk
• Maintain trust in the financial system

The Two Layers of KYC

1. Identity Proofing — Confirming the customer’s real identity using reliable data sources.
2. Ongoing Monitoring — Tracking activity for suspicious behavior and updating KYC records periodically.

Common Data Collected in KYC

• Full legal name
• Date of birth
• Residential address
• Government-issued ID (passport, national ID card, driver’s license)
• Selfie or biometric check
• Proof of address (utility bill, bank statement)

Real-World Example

You’re a PM at Revolut in the UK:

• New user signs up for a multi-currency account.
• KYC flow collects passport details + address + selfie verification.
• Cross-checks details with the UK government and global AML watchlists.
• Account is activated only after all verification steps pass.

Why It Matters for PMs

If you skip or weaken KYC:

• You risk fines, license suspension, or losing your banking partners.
• Fraud rates skyrocket.
• Regulatory authorities lose trust in your platform.

If you overdo it:

• Users drop off during onboarding.
• CAC increases.

PMs must balance security and conversion — keeping onboarding smooth while staying compliant.

44. eKYC, Video KYC & Document Verification — Making KYC Digital

Traditionally, KYC meant in-person verification — visiting a branch, showing your documents, waiting days for approval.

But modern fintech moves too fast for that.
Enter eKYC, video KYC, and digital document verification — methods that verify users remotely, instantly, and at scale.

What is eKYC?

eKYC (Electronic Know Your Customer) is the process of digitally verifying a customer’s identity without in-person interaction.

It typically uses:

• Scanned/uploaded ID documents
• Automated checks against government or commercial databases
• Facial biometrics for liveness and matching

Video KYC

In markets with stricter verification rules, video KYC adds an extra layer:

• A live video call with an agent or AI system
• User shows their face and ID document on camera
• Liveness checks ensure it’s a real person (not a photo or deepfake)

Video KYC is common in:

• EU neobanks
• Certain APAC markets
• Regulated sectors like crypto exchanges

Document Verification

This involves:

• Uploading an official ID (passport, driver’s license, national ID)
• OCR (Optical Character Recognition) to extract details
• Authenticity checks (watermarks, holograms, security features)
• Face match with a selfie for identity confirmation

Providers like Onfido, Jumio, and Trulioo offer global coverage for these checks.

Real-World Example

You’re a PM at Wise onboarding users in Europe:

• User uploads a passport photo via mobile app.
• OCR extracts data, and the system checks it against EU AML databases.
• The user takes a selfie; facial recognition confirms a match with the passport photo.
• In high-risk cases, you trigger video KYC with an agent for extra assurance.
• Total onboarding time: under 5 minutes.

Why It Matters for PMs

If your product requires identity verification:

• Pick the right verification level for your risk profile and regulatory requirements.
• Integrate with global verification APIs for scale.
• Offer mobile-first, fast, and error-proof flows.
• Build fallback paths (e.g., manual review if automated checks fail).
• Keep conversion analytics for each step to spot drop-offs.

The best eKYC systems feel like onboarding — not an interrogation.

45. KYB, UBO & Business Verification — Trust But Verify (Especially in B2B)

Let’s say a business signs up to your platform, claiming to be “Greenleaf Wholesale Ltd.”

• Do they exist?
• Are they a shell company?
• Is there a sanctioned individual behind it?

That’s where KYB (Know Your Business) and UBO (Ultimate Beneficial Ownership) checks come in — helping you answer the real question:

“Who owns this business, and are they safe to onboard?”

What Is KYB?

KYB is the process of verifying the identity, legitimacy, and risk profile of a business entity before allowing them to use financial services.

It’s the business version of KYC — but more complex, because:

• Businesses have legal structures
• They may operate across borders
• Beneficial owners can be hidden behind layers

Key Components of KYB

1. Company registration: Is the entity legally incorporated?
2. Directors and signatories: Who has control or access?
3. UBO (Ultimate Beneficial Owners): Who owns 25%+ (or as per local rules)?
4. Business activity: What do they do — and is it high risk (e.g., gambling, crypto)?
5. Sanctions screening: Are any stakeholders blacklisted globally?

Documents Typically Collected

• Certificate of incorporation
• Business license or registration extract
• Articles of association or bylaws
• Proof of business address
• Shareholding structure or UBO declaration
• Identity documents for UBOs and directors

Real-World Example

You’re a PM at Stripe onboarding e-commerce merchants across Europe.

• A merchant from Germany signs up.
• Your KYB system fetches company records via register APIs (e.g., Handelsregister, Companies House, etc.)
• It extracts director info, triggers sanctions checks on UBOs, and checks if the business is high-risk or restricted
• If verified, the account is approved and assigned a processing limit
• Ongoing monitoring is set up to flag future red flags (like ownership changes)

Why It Matters for PMs

If you’re onboarding businesses:

• Build modular KYB flows based on entity type and jurisdiction
• Automate via data providers like Kompany, Dun & Bradstreet, Alloy, or Middesk
• Design manual review queues for edge cases (e.g., sole proprietorships)
• Track approval times and drop-offs — long forms = lost leads
• Monitor for UBO changes over time (e.g., via webhook or batch refresh)

B2B fintechs die from bad KYB — either too risky, or too slow.

46. Bank-as-a-Service (BaaS) Models — How Fintechs Launch Banking Products Without a Bank

Say you want to build:

• A digital wallet
• A debit card product
• A savings account for freelancers
• SME bank accounts linked to invoicing tools

But you’re not a bank.

How do you launch these features compliantly, with real bank accounts and regulatory coverage?

That’s the promise of Bank-as-a-Service (BaaS) — where regulated banks expose their infrastructure as APIs so fintechs can embed banking inside their apps.

What Is BaaS?

Bank-as-a-Service allows fintechs to offer bank-like functionality (accounts, cards, payments) by integrating with licensed banking partners via APIs.

The bank handles:

• Licensing & compliance
• Ledger & account management
• Connectivity to payment rails (ACH, SEPA, RTP, etc.)

The fintech handles:

• UX, onboarding, customer servicing
• Use case & verticalization
• Product logic

Types of BaaS Providers

1. Direct banks offering APIs

• e.g., Solaris (EU), Cross River (U.S.), ClearBank (UK)

2. BaaS platforms that abstract multiple banks

• e.g., Unit, Synctera, Treasury Prime, Bond

3. Modular stacks combining KYC, cards, accounts, etc.

Real-World Example

You’re a PM at a U.S.-based expense management startup.

• You want to issue virtual cards and FDIC-insured business accounts
• You partner with Unit, who sits on top of Blue Ridge Bank
• You integrate their APIs for: Customer onboarding, KYC/KYB, Account creation, Card issuing via Visa, and Transaction monitoring
• The bank takes care of compliance, while you build a slick experience

You’ve now launched “banking” without becoming a bank.

Risks and Considerations

• BaaS providers are not all equal — check licensing footprint, SLAs, and Uptime
• You may be affected by partner bank regulatory issues
• Compliance is still your responsibility under “responsible fintech” models
• Exit and migration paths should be planned (many BaaS providers are startups themselves)

Why It Matters for PMs

If you’re building embedded finance:

• Choose the right BaaS partner for your region, product, and customer base
• Understand roles and responsibilities (who owns KYC, fraud, limits, reporting?)
• Set up SLAs for uptime, onboarding, and issue resolution
• Plan for scaling limits, pricing tiers, and regulator reporting needs

BaaS gives you banking superpowers — but you’re still responsible for how you use them.

47. Card Issuing, BIN Sponsorship & Program Management — Building Your Own Card, Without Being a Bank

Picture this: You’re building a fintech app that helps creators manage their income. You want to offer a branded Visa card so users can spend their balance instantly, online or offline.

But you’re not a bank. You don’t own a card license. You don’t have direct access to Visa or Mastercard.

How do you launch a card?

That’s where card issuing, BIN sponsorship, and program management come in.

What Is Card Issuing?

Card issuing is the process of creating and managing debit, credit, or prepaid cards under your brand, for use on global payment networks like Visa or Mastercard.

These cards:

• Are linked to a real or virtual balance (like a wallet or account)
• Can be physical or virtual
• Work online, offline, or via Apple Pay/Google Pay

The Role of BIN Sponsorship

A BIN (Bank Identification Number) is the first 6–8 digits of a card that identify the issuing institution.

Because only regulated entities can get BINs from Visa/Mastercard, most fintechs:

• Partner with a BIN sponsor (a licensed bank or issuer)
• Get issued cards “under” the sponsor’s BIN
• Customize the card design, rules, and limits via APIs

Program Management: Running the Show

Program managers are intermediaries that help fintechs launch card products by handling:

• Compliance with network rules
• Transaction processing and fraud control
• Card production and fulfillment
• Reporting to the card network and regulators

Example providers: Marqeta, Galileo, Highnote, Enfuce, MarqVision

Real-World Example

You’re a PM at Ramp (US expense management platform).

• You want to issue corporate cards with custom controls (e.g., $50 daily limit, merchant category blocking).
• You work with Marqeta (a modern issuer processor) + Visa as the network.
• Marqeta’s APIs let you:
• Create new cards on the fly
• Set spend controls, freeze/unfreeze cards
• Monitor real-time transactions
• Behind the scenes, Marqeta is plugged into a BIN sponsor bank for regulatory compliance

The result? A full-stack card experience without being a bank.

Why It Matters for PMs

If you want to offer card functionality:

• Choose the right issuer processor and BIN sponsor for your market and product type
• Know your scheme rules (Visa/Mastercard compliance is non-negotiable)
• Decide what you want to control: card controls? branding? fulfillment?
• Build limits, spend rules, and fraud logic into your core platform
• Design user journeys: card activation, PIN setup, card lock, dispute handling

Issuing cards isn’t just a feature. It’s a regulated product that builds trust and stickiness — if done right.

48. Statements, Passbooks & Proof of Funds — Trust Through Transparency

Picture this: You’re applying for a visa, renting an apartment, or getting a business loan. The agency or lender asks, “Can you show your last 3 months of account activity?”

That’s where account statements, passbooks, and proof of funds become crucial — not just for recordkeeping, but for building trust in your platform.

What Are These Documents?

• Statements: Monthly summaries of all transactions, balances, interest, and fees — usually in PDF format.
• Passbooks: Real-time digital logs of transactions — traditionally used in physical banks, now evolving into app-based activity logs.
• Proof of Funds (POF): A formal document (bank letter or statement) verifying that a user or business has sufficient funds for a specific purpose (e.g., immigration, rent, bidding).

Core Use Cases

• Visa & immigration applications
• Loan underwriting
• Business onboarding (KYB)
• Internal account audits & reconciliation
• Fraud or dispute resolution

These aren’t just passive reports — they’re documents of record that regulators and institutions rely on.

Real-World Example

You’re a PM at Wise offering multi-currency accounts.

• A freelancer in Germany needs a statement for their EUR account to apply for a visa

Your system generates:

• Monthly statements with timestamps, balances, and Wise’s legal address
• A downloadable PDF with a watermark and a signature
• A branded “proof of funds” letter showing current balance, certified by Wise
• All of this is available via a self-serve dashboard, reducing customer support load

What Makes a Statement “Good”?

1. Legibility — Simple, clean formatting.
2. Authenticity — Timestamped, branded, digitally signed or watermarked.
3. Completeness — Opening/closing balances, transaction detail, bank identifiers.
4. Compliant — Format must meet regulatory requirements in certain geos (e.g., FCA, BaFin).

Why It Matters for PMs

If your product holds funds:

• You must provide downloadable monthly statements (this is often a regulatory requirement).
• Offer custom date range filters and exports (PDF, CSV, JSON).
• Allow users to generate proof of funds letters on demand.
• Ensure your statements include correct identifiers and branding — banks and consulates will check.
• Build in version control to avoid tampering or spoofing.

The moment users need to prove something, your product must prove it for them — instantly, cleanly, and credibly.

49. Limits, Holds & Funds Availability — The Money Might Be There… But You Can’t Use It (Yet)

Picture this: You receive a $1,000 bank transfer and see it in your balance instantly. But when you try to withdraw it, your app says:

“Funds will be available in 3 business days.”

You’re confused. It’s your money — why can’t you touch it?

That’s the world of holds, limits, and availability windows, and it’s a big deal in fintech infrastructure.

What Are We Talking About?

• Limits = Rules that cap how much money can be sent, received, withdrawn, or held.
• Holds = Temporary freezes placed on incoming or outgoing funds.
• Funds Availability = When the money actually becomes usable, not just visible.

Where Do Limits and Holds Show Up?

• Daily withdrawal caps (e.g., ATM or wallet limits)
• Incoming payment review holds (e.g., fraud/risk check)
• Account-level limits (e.g., max balance allowed for unverified users)
• Network-imposed limits (e.g., ACH processing cutoffs)
• Regulatory caps (e.g., e-money wallet max balance limits under PSD2)

Real-World Example

You’re a PM at Cash App.

• You allow users to receive instant payments via debit cards.
• To reduce fraud, you place a $500/day receive limit for new accounts.
• Large deposits get placed on a 24-hour hold for verification.
• Even though the balance appears, the user can’t cash out until cleared.

This is shown in the UI with: “$800 pending — available tomorrow at 9:00 AM”

This ensures risk control + user clarity.

Why It Matters for PMs

As a PM, you need to:

• Design limit logic by tier, use case, and risk profile.
• Set smart defaults (e.g., $5K send limit, $10K receive, no overdraft).
• Explain limits clearly in the product — don’t make users guess.
• Offer limit increases as a growth lever (e.g., verify identity to raise limits).
• Communicate with transparency, not hidden in small text.

Users don’t get mad about limits. They get mad when they don’t know there is one.

50. Fees, Overdrafts & Interest Management — The Hidden Revenue (and Risk) in Your Product

Picture this: You use your digital bank account to buy lunch. You don’t realize you’ve gone negative.

A few hours later, you get an alert:

“Overdraft of $15 used. $2.50 fee charged. Please repay within 5 days to avoid interest.”

This single event — a tiny overdraft — touches fees, interest, and risk controls all in one go.

Types of Charges in Fintech

1. Explicit Fees

• Flat fees: e.g., $2 ATM fee, $10 for international wire
• Percentage fees: e.g., 1.5% FX conversion fee
• Subscription: e.g., Revolut Premium

2. Overdrafts

• Short-term negative balance coverage
• May involve interest, fees, or grace periods

3. Interest Management

• Paid to users (e.g., savings accounts: 2% APY)
• Charged to users (e.g., unpaid credit card balance: 24% APR)
• Requires accrual, compounding logic, and disclosures

Real-World Example

You’re a PM at Chime (a neobank in the U.S.)

• You offer SpotMe, a no-fee overdraft feature:
• Users can spend up to –$200 without penalty.
• Repayments happen automatically when new funds arrive.
• It’s available only for users with a direct deposit history.

Behind the scenes:

• You track how many days overdrafts go unpaid
• You offer tiered limits (–$20 → –$200) based on usage
• You avoid interest by capping exposure and risk

It builds trust and stickiness.

Why It Matters for PMs

Whether you’re charging fees or covering overdrafts:

• Be transparent — never surprise users with hidden charges.
• Build logic for fee waivers (e.g., first time, VIP user, subscription plan?)
• Handle interest accrual and compounding with accuracy (especially for credit or lending products).
• Know your regulatory boundaries — interest rate caps, overdraft disclosure laws, etc.

Money is emotional. When users feel misled about fees or balances, they churn — fast.

Design your fee and interest systems with empathy, accuracy, and clarity.

51. Underwriting & Credit Scoring Models — Deciding Who Deserves Credit (and How Much)

Picture this: A user applies for a $2,000 loan through your app.

They’ve never borrowed from you before. You don’t know if they’ll repay you — or vanish.

Now it’s decision time:
✅ Approve?
⛔ Reject?
⚖️ Ask for more info?

This is underwriting in action — the art and science of deciding who gets credit, how much, at what interest rate, and on what terms.

What Is Underwriting?

Underwriting is the process of assessing creditworthiness before giving someone a loan or a line of credit.

It includes:

• Evaluating risk: Will this user default?
• Scoring applicants: What’s their credit profile?
• Setting limits: How much can we lend?
• Pricing: What APR or fees should we charge?

Types of Underwriting Models

1. Traditional scorecard-based (e.g., FICO or bureau score-based models)
2. Rule-based systems (e.g., IF employment_status = “verified” → increase limit)
3. ML/AI models (e.g., gradient boosting, neural networks using 100+ features)
4. Hybrid: Combine human review + automated rules (popular for SME lending)

Real-World Example

You’re a PM at Klarna, a BNPL provider.

• A new user wants to buy a $500 phone via “Pay in 4.”
• Your underwriting engine checks:
• Past repayments with Klarna
• Bureau data (e.g., Experian, TransUnion)
• Bank transaction patterns (via open banking)
• Device and location consistency (fraud checks)
• Result: The system approves the purchase instantly, with a soft credit limit of $1,000.

Why It Matters for PMs

Underwriting drives:

• Approval rate → conversion and growth
• Default rate → losses and risk exposure
• Loan pricing → margin and profitability

As a PM, you must:

• Balance risk and growth
• Build real-time, explainable decisions (users hate being declined without reason)
• Ensure regulatory fairness (no bias, no black-box models in some regions)

Underwriting is where product, data science, and compliance collide.

52. Credit Bureaus & Alternative Data — The Backbone of Lending Decisions

Picture this: You apply for a credit card. The issuer pulls your credit score and instantly decides your fate — approved with $5,000 limit, or rejected.

But where did that score come from?

That’s the world of credit bureaus and, increasingly, alternative data providers — sources that help fintechs evaluate borrower reliability.

What Are Credit Bureaus?

Credit bureaus are companies that collect, aggregate, and share individuals’ and businesses’ credit histories.

They store data like:

• Past loans, credit cards, mortgages
• Payment history (on-time, late, default)
• Credit utilization and limits
• Number of credit inquiries (hard/soft pulls)

The 3 major global bureaus are:

• Equifax
• Experian
• TransUnion

Each bureau generates a credit score (like FICO in the U.S. or VantageScore) used by lenders to make decisions.

The Problem with Traditional Bureaus

• Many people (especially young or low-income users) are “credit invisible”
• Bureaus often have incomplete or outdated data
• They’re slow and not real-time
• Not ideal for emerging markets or thin-file customers

Enter: Alternative Data

Fintechs now look beyond bureaus by analyzing:

• Bank transactions (via open banking or Plaid)
• Income patterns & cash flow volatility
• E-commerce and utility bill payments
• Phone usage, social behavior (in some markets)
• Gig economy work history

These data points help underwrite the “invisible middle” — people who don’t have credit cards, but pay rent, stream Netflix, and earn income.

Real-World Example

You’re a PM at Tala (a lending app in Africa and Southeast Asia).

• You can’t rely on credit bureaus — many customers have no file.
• Instead, your app analyzes:
• SMS and mobile money transaction history
• App usage patterns and location consistency
• Repayment history on past Tala loans
• Result: Tala builds its own internal score and underwrites millions of borrowers profitably.

Why It Matters for PMs

• Always ask: What data do I trust for credit decisions?
• Work with bureau APIs (e.g., Nova Credit, TransUnion, CRIF) and
  alternative data APIs (e.g., Plaid, Pinwheel, Argyle, Provenir).
• Design flows that are privacy-compliant (GDPR, CCPA)
• Make scores explainable to users (especially if rejected)

Lending is no longer just about scorecards. It’s about context — and creditworthiness in the real world.

53. Loan Lifecycle: Origination to Collections — What Really Happens After “Approved”

Picture this: A user gets approved for a $5,000 personal loan in your app.
They feel excited, relieved… but your work has only just begun.

Behind the scenes, a loan must be funded, tracked, repaid, and — if things go wrong — recovered. That’s the loan lifecycle, and managing it well is the heart of every lending product.

The 5 Stages of the Loan Lifecycle

1. Origination

• Application → underwriting → approval
• Identity verification, income checks, KYC/KYB
• Credit terms defined: amount, interest rate, repayment period

2. Disbursement

• Funds are transferred to the user (bank account, wallet, or card)
• Accounting entries are created (loan asset booked)

3. Servicing

• Managing repayments (EMIs, auto-debits)
• Interest accruals, notifications, and account statements
• Customer support for changes, payment plans

4. Delinquency Handling

• When repayments are late
• Grace periods, reminder nudges, repayment rescheduling
• Risk flags triggered

5. Collections or Charge-Offs

• Final attempts to recover money
• Debt collection teams or agencies
• Write-off after 90–180 days (based on regulation and policy)

Real-World Example

You’re a PM at Upstart, a U.S. fintech lender.

• A borrower applies for a 3-year loan to consolidate credit card debt.
• Origination: Upstart uses an AI model to approve in minutes, using education + employment data.
• Disbursement: The money is deposited in the borrower’s account the next day.
• Servicing: Repayments auto-debit every month. A dashboard shows interest remaining, principal repaid, next due date.
• Delinquency: A missed payment triggers a friendly reminder email → in-app nudge → human call.
• Collections: After 120 days, the account is handed over to a licensed collector.

Everything is automated — but deeply human when needed.

Why It Matters for PMs

• You don’t just build “loan approval” — you build a system that supports a financial relationship over time.
• Design for edge cases: failed payments, partial payments, early repayment.
• Automate with care: repayments, notices, and collections.
• Comply with lending regulations: grace periods, interest caps, disclosures, etc.
• Build internal dashboards to monitor delinquency buckets and repayment health.

The real product is the system behind the scenes — not the “Apply Now” button.

54. Product Types: Term Loans, LOCs, Revolvers — Different Loans, Different Behavior

Picture this: Two users borrow $1,000 from your platform.
One gets the whole amount upfront, repays in 12 fixed installments.
The other draws $200 at a time, pays interest only on what they use.

Same amount. Totally different credit product.

That’s why understanding loan types is essential for fintech PMs — because the UX, revenue model, and risk profile all change with it.

1. Term Loans (Installment Loans)

• Borrower gets the full amount upfront
• Fixed or variable interest rate
• Repaid over a defined term in equal installments (EMIs)
• Common for personal loans, car loans, and student loans

🛠️ PM notes:

• The repayment schedule is predictable
• Great for structured financial goals
• Works well with mobile reminders + EMI calculators

2. Lines of Credit (LOCs)

• Approved limit, user draws funds as needed
• Only pay interest on the used amount
• Revolves — pay back, borrow again
• Credit cards are a type of LOC

🛠️ PM notes:

• Riskier: can be maxed out any time
• Users love flexibility → use for unpredictable expenses
• Needs strong real-time ledger + limit engine

3. Revolving Credit / Revolvers

• Similar to LOCs, but focused on short-term liquidity
• Can carry balance month-to-month
• Often comes with minimum due + interest on unpaid balance

Use cases:

• Credit cards
• Working capital credit lines for SMEs
• BNPL with rolling limits

Real-World Example

You’re a PM at Brex building credit lines for startups.

• Customers don’t get lump-sum loans.
• Instead, they’re issued a revolving line based on revenue or bank balance.
• Every spend reduces the line → repayments replenish it.
• Interest-free for 30 days, but overdue balances incur interest.

You design:

• A spend tracking dashboard
• Smart alerts (e.g., “85% of limit used”)
• Integration with accounting tools

Why It Matters for PMs

• Pick the loan type that fits your user’s behavior: Fixed-term for large purchases, Credit lines for flexible spending
• Build different logic for: Repayments, Interest computation and Notifications, and nudges
• Plan your revenue model: origination fee, interest, usage fee, subscription?

The shape of the loan defines the shape of the product — and how users experience it.

55. BNPL: Pay-in-4 vs POS Financing — Not All “Buy Now, Pay Later” Is the Same

Picture this: You’re browsing an online store and spot a $200 pair of headphones.

At checkout, you see: “Buy now, pay later — 4 interest-free payments of $50.”

Tempting, right? That’s the magic of BNPL (Buy Now, Pay Later) — a booming fintech model designed to smooth out purchases and reduce friction. But not all BNPL is created equal.

There are two major types: Pay-in-4 and POS Financing, and each behaves very differently under the hood.

Pay-in-4: The Netflix of Credit

Pay-in-4 BNPL splits your purchase into four equal installments:

• No interest
• First payment made at purchase
• The remaining three auto-debited bi-weekly

It’s designed for small-ticket, everyday purchases — clothes, electronics, cosmetics.

Users love it because:

• No hard credit check
• Feels like “free money” (even though it’s a loan)
• Quick, no-friction approval (often <10 seconds)

For the BNPL provider (like Klarna, Afterpay, or Affirm), revenue comes from:

• Merchant discount fees (2–6%)
• Late fees (though some players like Apple Pay Later avoid these)

POS Financing: The Credit Card Replacement

Point-of-sale (POS) financing is a longer-term loan, usually:

• 6, 12, 24, or 36 months
• With or without interest
• Often used for big-ticket items (furniture, laptops, healthcare)

These loans feel more like traditional credit, but embedded inside the checkout flow.

You’ll see this when buying a $1,200 mattress and choosing:

“Pay $100/month for 12 months — 0% APR for qualified customers.”

Here, underwriting is deeper:

• Credit bureau checks
• Income verification
• Structured repayment plans

POS loans usually show up on credit reports — unlike Pay-in-4, which is often invisible.

Real-World Example

You’re a PM at Affirm working with Peloton.

• A customer wants to buy a $2,000 bike.

You offer both options:

• Pay-in-4 → $500 now + 3 more bi-weekly payments
• POS loan → $83/month for 24 months at 0% APR
• The Pay-in-4 option is instant. The POS loan requires soft credit pull + income confirmation.
• You get paid a % by Peloton, and may also earn interest (depending on APR).

Each product targets a different customer mindset — impulse vs planned purchase.

Why It Matters for PMs

Understanding these two BNPL models is critical because:

• They serve different customer intents: small splurges vs long-term buys.
• Risk, margin, and regulation differ: Pay-in-4 is short-term and low-risk; POS loans require tighter compliance.
• UX must be tailored: one-click for Pay-in-4, educational flow for financing.
• You’ll need two distinct loan engines, delinquency tracking, and repayment plans under the hood.

As a PM, you’re not just building a payment option — you’re shaping how people perceive and manage debt.

56. Risk-Based Pricing & APR Computation — Why Not Everyone Pays the Same

Picture this: Two people apply for a $5,000 loan. One gets 9% interest. The other? 27%.

Seems unfair? Not quite.

Welcome to risk-based pricing — where a borrower’s creditworthiness directly affects the cost of their loan.

What Is Risk-Based Pricing?

At its core, risk-based pricing means: The Higher the risk of default, higher the price (APR) of the loan.

Lenders do this to protect themselves from potential losses.

If a user is statistically more likely to miss payments, the lender either:

• Charges higher interest (to offset risk), or
• Declines the loan

It’s how most personal loans, credit cards, auto loans, and even BNPL POS financing work.

What Goes Into APR?

APR (Annual Percentage Rate) is the total cost of borrowing, expressed yearly. It includes:

• Interest rate (fixed or variable)
• Origination fees
• Maintenance fees
• Any other finance charges

Example:

• $5,000 loan, 10% interest, $100 origination fee → APR = ~11.6%, not 10%

APR helps users compare apples to apples across lenders.

How Pricing Is Set in Fintech

Most fintech lenders use scoring models to bucket customers:

• Prime (low risk): APR 8–12%
• Near-prime: APR 15–25%
• Subprime: APR 30% or more — or declined

They might also adjust pricing based on:

• Employment history
• Repayment behavior with other fintech apps
• Income consistency (via open banking)
• Loan purpose (e.g., vacation vs medical emergency)

Some platforms (like Upstart) use machine learning to build risk tiers based on non-traditional data like education and job type.

Real-World Example

You’re a PM at SoFi designing a personal loan product.

• Your underwriting model assigns a risk score to each applicant.

Based on the score, you map them to a rate tier:

• Tier A: 8.99%
• Tier B: 13.99%
• Tier C: 19.99%

Each offer includes:

• Transparent APR disclosure
• Monthly installment breakdown
• No hidden fees

By pricing risk precisely, you approve more users — without blowing up your default rate.

Why It Matters for PMs

Risk-based pricing shapes:

• Loan accessibility: Who gets approved, and at what cost
• Revenue strategy: Higher risk = higher return (if managed well)
• UX design: Transparent, compliant disclosures are a must
• User trust: People accept higher prices when reasons are explained clearly

The best lending products don’t just price risk — they communicate it with clarity and empathy.

57. Collateral, LTV & Covenants — What Happens When Borrowers Can’t Pay?

Picture this: You’re building a lending platform for small businesses.
A restaurant owner wants a $100,000 loan. Would you just… trust them?

What if they go bankrupt? How do you recover the money?

That’s where collateral, LTV, and covenants come in — they protect the lender when things go south.

What Is Collateral?

Collateral is an asset pledged by the borrower to secure the loan. If they can’t repay, the lender has the right to seize and sell the asset.

Examples:

• A mortgage uses the house as collateral
• A car loan uses the vehicle
• SME loans might use inventory, equipment, or invoices

Loans that require collateral are called secured loans. No collateral? That’s an unsecured loan — and it’s riskier for the lender.

What Is LTV (Loan-to-Value)?

LTV = Loan Amount / Collateral Value

It tells you how much risk the lender is taking relative to the asset.

Example:

• Collateral = $100,000 house
• Loan = $80,000 → LTV = 80%

Lower LTV = More cushion for the lender. A 50% LTV means the asset would have to lose half its value before the lender loses money.

Fintechs often define max LTV thresholds:

• Mortgage: ~80%
• Auto: ~70%
• Crypto loans: ~50% (due to volatility)

What Are Covenants?

Covenants are rules written into the loan agreement to ensure the borrower stays financially healthy.

They’re common in:

• Corporate loans
• Venture debt
• Revenue-based financing

Types of covenants:

• Financial: Maintain a minimum EBITDA, revenue, or liquidity ratio
• Operational: Submit audited financials quarterly
• Negative covenants: Don’t take on new debt without permission

If covenants are breached, the lender can demand early repayment or renegotiate terms.

Real-World Example

You’re a PM at Clearco, a fintech that offers revenue-based financing to e-commerce startups.

• You lend $100K against projected future revenues.
• You structure the loan so that:
• Repayments come as a % of the monthly sales
• The LTV doesn’t exceed 70%
• There’s a covenant: monthly sales must stay above $30K

If sales fall below that, the platform pauses future disbursements and reassesses.

You’ve just built risk controls that protect the business — without breaking trust.

Why It Matters for PMs

• Lending is about the return of capital, not just access to capital
• If you’re not building with risk in mind, you’re not building lending infrastructure.
• Collateral-backed loans can offer better rates and lower losses, but require asset management and recovery workflows.
• LTV and covenants are tools to control risk at scale — especially in SME, property, or crypto lending platforms.

As a PM, you’re not just funding users — you’re guarding the downside when things go wrong

58. Delinquency Buckets, Roll Rates & NPLs — Measuring a Loan Portfolio’s Health

Picture this: You’ve disbursed 10,000 loans. Everything looks fine… until you realize 1,000 of them haven’t made a payment in over 60 days.

That’s a problem.

To manage lending at scale, you need to track who’s paying, who’s late, and how bad it’s getting. That’s where delinquency metrics like buckets, roll rates, and NPLs come in.

What Are Delinquency Buckets?

A delinquency bucket groups loans by how late they are on payment:

• 0+ DPD = 1 day late
• 30+ DPD = more than 30 days past due
• 60+, 90+, 120+ DPD = increasing severity

It’s like a triage system — the further behind a loan is, the harder it is to recover.

You’ll often see metrics like:

• “5% of loans are 30+ DPD”
• “Portfolio has 1.8% in 90+ DPD bucket.”

This helps risk and collections teams prioritize efforts.

What Are Roll Rates?

Roll rate = % of loans that “roll forward” into a worse bucket over time.

Example:

• Of 100 loans in 30+ DPD today
• 40 move to 60+ DPD next month → Roll rate = 40%

High roll rates = bad sign.

They indicate borrowers are not self-curing, and delinquency is getting worse.

Roll rates are key inputs into credit loss forecasting.

What Are NPLs?

NPL = Non-Performing Loan

A loan becomes “non-performing” when it’s past a defined delinquency threshold (usually 90 or 120+ days) and unlikely to be repaid.

NPL Ratio = NPLs / Total Loan Book

Example: $2M in NPLs on a $100M book → 2% NPL ratio

Regulators and investors use this to assess a lender’s asset quality.

Real-World Example

You’re a PM at Kiva, a global P2P lending platform.

• You launch a dashboard for loan performance.

You define buckets:

• On-time
• 1–29 days late
• 30–59 days
• 60–89 days
• 90+ days = Non-performin
• You display roll rate trends to spot trouble early.
• The collections team focuses on a 30–60 DPD bucket, where recovery odds are still high.

You’ve turned raw delinquency data into an actionable, prioritizable view of portfolio health.

Why It Matters for PMs

• Delinquency is inevitable — but it must be measured early and often.
• Buckets and roll rates give you leading indicators of future defaults.
• NPLs impact your profitability, credit risk, and investor confidence.

As a PM, you need to decide:

• What thresholds define each bucket
• How frequently to I update
• Who needs alerts — ops, collections, or leadership

In lending, risk doesn’t arrive all at once. It rolls in quietly — unless you’re watching.

For a deeper dive, I highly recommend the course. It costs less than a burger yet delivers exceptional value for anyone looking to break into Fintech.

Fintech BootCamp: Master Financial Ecosystem

61. AML/CFT Frameworks — Keeping Dirty Money Out of Clean Systems

Picture this: A criminal wants to turn $1 million of drug money into “legit” funds. They can’t just walk into a bank and deposit it.

So they use shell companies, fake invoices, or layer funds across fintech apps.

This is exactly what AML (Anti-Money Laundering) and CFT (Countering the Financing of Terrorism) frameworks are designed to stop.

What Is AML/CFT?

AML/CFT refers to the laws, controls, and systems designed to:

• Detect suspicious transactions
• Prevent criminal or terrorist organizations from using the financial system
• Comply with global and local financial regulations

It’s not just a bank’s job anymore — every fintech that moves money must have AML/CFT systems in place.

The Global Framework: FATF

The Financial Action Task Force (FATF) sets global standards for AML/CFT.

Nearly every country builds its local laws (like the BSA in the US, or AMLD in Europe) based on FATF’s recommendations.

Key FATF expectations:

• KYC (Know Your Customer)
• Transaction monitoring
• Suspicious Activity Reports (SARs)
• Risk-based approach — don’t treat all customers the same

How Fintechs Implement AML

Modern AML programs include:

• Customer onboarding checks (e.g., identity verification, sanctions lists)
• Transaction monitoring rules (e.g., unusual transfers, structuring patterns)
• Case management systems for investigation
• Automated SAR filing to regulators

Example triggers:

• Sending $9,999 to 5 different accounts in a day
• Logging in from multiple countries within hours
• A new account receiving large crypto deposits and withdrawing to cash

Real-World Example

You’re a PM at Revolut, expanding into new markets.

• You need to support regulators in the UK, EU, US, and Singapore.
• You build an internal AML engine that:
• Flags unusual behavior (high velocity, mismatched KYC details)
• Automatically files SARs for accounts over a risk threshold
• Sends alerts to the compliance team with explainable triggers

This system ensures Revolut stays compliant across jurisdictions — and avoids hefty fines.

Why It Matters for PMs

• AML is not optional — it’s a legal obligation for any money movement.
• Poor AML design = fines, license loss, or shutdown
• Your product should support:
• Tiered customer risk profiling
• Dynamic rule building for monitoring
• Manual review workflows and case escalation

You’re not just shipping features — you’re helping keep the financial system clean and trustworthy.

62. Sanctions & OFAC Screening — Don’t Let the Wrong People In

Picture this: A user signs up for your remittance app. Everything looks fine — until your bank freezes the account.

Why?

That user is on a sanctions list — and you just enabled an illegal transaction.

Welcome to the world of sanctions screening, where getting it wrong isn’t just risky — it’s criminal.

What Are Sanctions?

Sanctions are government-imposed restrictions on:

• Individuals
• Entities
• Countries

They’re used to combat:

• Terrorism
• Human rights violations
• Political conflicts (e.g., North Korea, Russia)

If your platform processes a transaction involving a sanctioned party, you can face multi-million-dollar penalties.

What Is OFAC?

OFAC (Office of Foreign Assets Control) is the US agency that enforces economic and trade sanctions.

It publishes lists like:

• SDN (Specially Designated Nationals)
• Blocked Persons List

Other global regulators include:

• EU Sanctions List
• UN Sanctions
• UK HMT Sanctions (OFSI)

Most fintechs need to screen against all relevant lists based on where they operate.

How Screening Works in Fintech

Sanctions screening typically includes:

• Name and entity matching during onboarding (using fuzzy logic to catch “Ali Bin Mohammed” vs “Mohammad Ali Bin”)
• Ongoing screening as new names are added to lists
• Transaction screening for beneficiary names, countries, banks

The system should alert the compliance team for review — and block high-risk transactions in real-time.

Real-World Example

You’re a PM at Wise (formerly TransferWise).

• You integrate a global sanctions screening API that:
• Checks all user signups against 10+ sanction lists
• Screens every transaction’s beneficiary name and bank SWIFT code
• Uses AI to reduce false positives (e.g., “John Iran”, ≠ “bank in Iran”)
• You also set up audit logs for regulators and escalation flows for compliance officers.

This system is key to Wise’s global expansion and regulatory trust.

Why It Matters for PMs

• Sanctions compliance is a non-negotiable trust layer in money movement
• False negatives = huge legal risk
• False positives = terrible UX and churn

As a PM, you need to:

• Design workflows for real-time screening
• Build UI for compliance review
• Ensure high match accuracy with minimal friction

In global fintech, knowing who not to serve is as important as knowing who to help

63. PSD2/PSD3 & Strong Customer Authentication — Europe’s Rules That Shaped Global Fintech

Picture this: You’re trying to pay online with your card.

Suddenly, you get redirected to your banking app to confirm the purchase — via Face ID or an OTP.

That friction? It exists because of a law.

Meet PSD2, the regulation that reshaped how money moves and who gets access to it in Europe — and beyond.

What Is PSD2?

PSD2 (Payment Services Directive 2) is an EU regulation that:

• Opened up banking data to third parties (like fintech apps)
• Mandated stronger security for digital payments
• Created a framework for Open Banking across Europe

It came into force in 2018, replacing the older PSD1 framework.

And now? PSD3 is on the way — expected to go live around 2026.

What Did PSD2 Actually Do?

1. Enabled Open Banking APIs

• Banks were required to share data (with user consent) with third-party providers
• This created an explosion of apps for budgeting, payments, and credit scoring

2. Introduced SCA (Strong Customer Authentication)

• All online payments above ~€30 must be verified using 2+ of the following:
• Something you know (password)
• Something you have (phone, OTP)
• Something you are (fingerprint, Face ID)

3. Created New Player Types

• AISP (Account Information Service Providers) — Can access your bank account data
• PISP (Payment Initiation Service Providers) — Can initiate payments directly from your bank

PSD3 Is Coming: What Changes?

• Harmonizing PSD2 and E-Money rules
• Expanding scope to cover embedded finance and digital wallets
• Tightening fraud prevention for instant payments and crypto
• More clarity for “technical service providers” (like Plaid or Tink)

This matters because what starts in Europe often inspires frameworks globally (e.g., UK Open Banking, Brazil’s Open Finance, Singapore’s SGFinDex).

Real-World Example

You’re a PM at TrueLayer, building Open Banking payments for merchants.

• You let customers pay directly from their bank account instead of using cards.
• To comply with PSD2:
• You register as a PISP under the UK FCA
• You implement SCA flows using redirect to bank + biometric confirmation
• You build fallback mechanisms for banks with buggy APIs

This allows merchants to skip card fees and enables safer, faster A2A payments.

Why It Matters for PMs

• PSD2 is the foundation of Open Banking in Europe — it dictates how you access, move, and protect money
• SCA adds friction — but it’s non-negotiable. UX must work around it, not against it.
• As PSD3 evolves, you’ll need to rethink:
• Who owns the customer journey
• How to minimize drop-offs during SCA
• Where embedded finance fits in

Regulation can feel like a blocker — but smart PMs turn it into an enabler of better, safer products.

65. Data Privacy (GDPR, CCPA) — Your Users’ Data Isn’t Just Yours

Picture this: A customer uses your app to view their transactions. A week later, they email you:

“I want to delete all my data — permanently.”

Can you do it? Should you have collected it in the first place?

Welcome to the world of data privacy regulations, where trust isn’t just about tech — it’s about control.

What Are GDPR and CCPA?

• GDPR (General Data Protection Regulation): EU law enacted in 2018
• CCPA (California Consumer Privacy Act): US (California) law effective 2020

Both give users rights over their personal data — and impose strict obligations on companies handling it.

Other similar laws are emerging in:

• UK (UK GDPR)
• Brazil (LGPD)
• India (DPDP Act)
• Canada (CPPA upcoming)

Core Principles of Data Privacy Laws

1. Consent & Transparency

• Tell users exactly what you collect and why
• No more sneaky checkboxes

2. Data Minimization

• Collect only what you need — not “just in case”

3. Right to Access & Erasure

• Users can request a copy of all their data
• Or ask you to delete it completely

4. Portability

• Users can ask you to transfer their data to another provider

5. Security & Breach Notification

• If data is leaked, you must notify users and authorities — usually within 72 hours

How This Plays Out in Fintech

Fintechs hold deeply sensitive data:

• Bank account numbers
• Transaction histories
• KYC docs
• Location and device data

So you must:

• Get clear consent (no pre-checked boxes!)
• Provide easy access to a “Download My Data” or “Delete My Account” flow
• Implement audit logs and encryption across your stack
• Document data processing agreements with vendors

Real-World Example

You’re a PM at Curve, a card aggregator app in Europe.

• You allow users to link multiple cards and view spend data in one place.

To comply with GDPR:

• You encrypt all card metadata at rest
• Let users export their full transaction history from the app
• Build a “Right to Be Forgotten” workflow that removes customer info across internal services and third-party vendors

This lets users feel in control — and keeps you out of regulatory trouble.

Why It Matters for PMs

• Data privacy isn’t just legal overhead — it’s a core part of user trust

You’ll need to:

• Map data flows end-to-end
• Build UI for consent, access, and deletion
• Ensure vendors are compliant too

The rule is simple: if you wouldn’t want your own data handled that way, don’t do it to your users.

66. Licensing: EMI, PI, MSB & Money Transmitter — The Fintech Permission Slips

Picture this: You launch a beautiful fintech app where users can send money, hold balances, and pay bills.

Everything works — until your bank partner freezes your account. Why? You didn’t have the right licenses to move and hold money.

In fintech, it doesn’t matter how sleek your UX is — you can’t operate legally without a license.

What Are Fintech Licenses?

A fintech license is a government-issued permission to perform regulated financial services, like:

• Storing funds
• Transferring money
• Issuing cards
• Providing payment services

The license you need depends on:

• The country you operate in
• What exactly your product does
• Whether you hold funds, move them, or both

Common License Types by Region

Europe (regulated by local financial authorities under EU law):

• EMI (Electronic Money Institution) — For holding customer balances and issuing e-money (e.g., Revolut)
• PI (Payment Institution) — For payment processing, but without storing funds (e.g., checkout processors)

US:

• MSB (Money Services Business) — Broad federal designation under FinCEN for companies that transmit, convert, or store money
• Money Transmitter License (MTL) — State-level licenses required in 49 states for moving funds (e.g., PayPal, Cash App)

UK:

• Similar to EU with EMI and PI licenses, issued by the FCA.

Other countries (like Singapore, Canada, Australia) have their own equivalents — usually a Payment Service Provider or Money Transfer Operator license.

When Do You Need One?

You typically need a license if you:

• Store customer funds (wallets, balances, prepaid cards)
• Move money between users or from users to businesses
• Sell or exchange foreign currency
• Operate a marketplace that holds seller funds before settlement

If you only offer tech infrastructure (like Plaid or Tink), you may not need a license — but your partners will.

Real-World Example

You’re a PM at a US-based neobank called Volt, planning to expand across 3 EU countries.

• You partner with a local bank in each country to avoid getting licenses in every region.
• But for autonomy, you pursue an EMI license in Lithuania (a common base for pan-EU fintechs).
• You need to design workflows for:
• Safeguarding customer funds
• Monthly reports to the central bank
• AML compliance tied to your license

This license lets Volt operate independently and serve all EEA customers under passporting.

Why It Matters for PMs

• Without the right license, your product can’t go live — or scale globally.
• You’ll need to:
• Understand where licenses are held (in-house vs partners)
• Build features that meet licensing obligations (like ledgering, reporting, customer verification)
• Align product rollout plans with legal approval

Licenses are the passport of fintech — and the UX you ship must honor their boundaries

67. Recordkeeping, Audit & Regulatory Reporting — Receipts for Everything

Picture this: A regulator walks in and says,

“Show me every payment your app processed over the last 3 months. And the KYC of each user involved.”

Can you do it — instantly, accurately, and completely?

That’s what recordkeeping and regulatory reporting is all about.

It’s less glamorous than APIs or growth hacks, but it’s what keeps your company in business.

What Is Recordkeeping in Fintech?

It’s the process of storing structured, auditable records of:

• Transactions
• KYC/AML checks
• Complaints
• Consent logs
• Fund movements
• System changes (audit trails)

Most regulators require fintechs to retain data for 5–10 years, depending on jurisdiction.

What Is Regulatory Reporting?

You’re not just storing data — you’re regularly submitting it to regulators.

Common reports include:

• Suspicious Activity Reports (SARs)
• Transaction Volume Reports
• Chargeback summaries
• Liquidity and float positions
• Quarterly financials and capital adequacy

These are often automated XML or JSON feeds submitted via regulatory portals.

What About Audits?

Regulators (or your licensing partner) may conduct surprise audits or scheduled reviews.

You’ll need:

• A full audit trail of user actions, fund flows, and system updates
• Proof of compliance with AML, SCA, and consumer protection laws
• Signed logs, role-based access, and version control

Real-World Example

You’re a PM at N26, operating under an EMI license in Europe.

• Every payment must have a matching ledger entry
• You build systems that:
• Tag transaction types for reporting (e.g., SEPA credit vs card payout)
• Log KYC decision trees for each user
• Sync monthly summaries with the BaFin (Germany’s financial regulator)

Auditors can see how every cent moved — and why.

Why It Matters for PMs

• If it’s not logged, it didn’t happen — that’s how regulators think.
• As a PM, you must:
• Design for traceability (every change must be reconstructible)
• Build reporting feeds into the core product, not as an afterthought
• Work with compliance to define the right level of granularity and retention

Good recordkeeping isn’t just about checking boxes — it’s your safety net when things go wrong.

Great — let’s dive into the next pair from Section 7: Compliance & Regulation:

Here’s the content for Topic 68: Travel Rule & VASPs and Topic 69: Complaints, Chargebacks & Disclosures — written to be clear, engaging, and globally relevant.

68. Travel Rule & VASPs — Crypto’s FATF-Compliant Identity Check

Picture this: You’re using a crypto wallet to send $5,000 to a friend overseas.

The platform suddenly asks: “Who are you sending it to? What’s their name and wallet provider?”

Why? Because of the Travel Rule — a growing global mandate that makes crypto more like traditional banking.

What’s the Travel Rule?

Originally designed for banks, the Travel Rule requires financial institutions to:

• Collect and share identifying information about the sender and receiver of a transaction
• For transfers above a certain threshold (often $1,000 USD or local equivalent)

In 2019, the FATF (Financial Action Task Force) extended this rule to Virtual Asset Service Providers (VASPs) — including:

• Crypto exchanges
• Custodial wallets
• Crypto payment processors

So now, if you’re a VASP, you must attach this info when processing qualifying transfers — just like SWIFT messages do in traditional finance.

What Info Must Be Shared?

For the originator (sender):

• Full name
• Wallet address or account number
• National ID or account info

For the beneficiary (receiver):

• Full name
• Wallet address or unique identifier
• Possibly the VASP is handling the other side

This data “travels” with the transaction between VASPs.

How It’s Implemented

There’s no global technical standard — yet. But many VASPs are adopting:

• TRISA (Travel Rule Information Sharing Architecture)
• OpenVASP
• Notabene, Sumsub, or CipherTrace integrations

These tools help ensure encrypted, compliant, and verifiable info sharing without exposing personal data on the blockchain.

Real-World Example

You’re a PM at Coinbase, enabling cross-border crypto transfers.

• To comply with the Travel Rule:
• You ask senders to provide receiver details above $1,000
• You validate if the receiving wallet is hosted by a compliant VASP
• You build integrations with Notabene to exchange identity metadata securely

This ensures Coinbase stays FATF-compliant while preserving the UX crypto users expect.

Why It Matters for PMs

• The Travel Rule is about reputation and global access — non-compliance = delistings, bans, or loss of licenses

You’ll need to:

• Build flows to collect and verify sender/receiver identity
• Integrate with a rule engine to determine when the rule applies
• Handle edge cases like self-hosted wallets or anonymous users

Crypto is no longer the Wild West — regulation is coming fast, and your product must be ready to adapt

69. Complaints, Chargebacks & Disclosures — Building Trust When Things Go Wrong

Picture this: A customer is charged twice for the same transaction.
They email support. No response.
They tweet angrily. Still nothing.
They file a chargeback — and the regulator steps in.

Welcome to the compliance side of customer experience: complaints handling, chargebacks, and disclosures.

What Are These, and Why Do They Matter?

1. Complaints Handling

• Users must have a clear way to file grievances
• You must acknowledge, investigate, and resolve within defined timelines
• Regulators track complaint ratios and resolution times

2. Chargebacks

• When a user disputes a card transaction (e.g., fraud, duplicate charge)
• The issuing bank temporarily refunds the user and pulls funds from the merchant
• You need dispute resolution flows — for both users and merchants

3. Disclosures

• Fintechs must clearly communicate:
• Terms & conditions
• Fees and pricing
• Data usage
• Risks (especially in lending or investing products)

These aren’t just operational details — they’re regulated obligations in most markets.

How It’s Done in Fintech

Fintechs must build:

• In-app complaint forms (with time-stamped logs and escalation flows)
• Transparent chargeback dashboards (reason codes, status tracking, evidence upload)
• Easy-to-read disclosures at onboarding, not buried in footnotes

Most regulators require:

• First response to complaints within 3–5 business days
• Full resolution within 14–30 days (depends on jurisdiction)
• Public reporting of complaint volumes in some countries (e.g., UK FCA)

Real-World Example

You’re a PM at Wise, offering international payments.

• A customer claims they sent money to the wrong bank due to an auto-fill error

Wise:

• Acknowledges the complaint within 24 hours
• Builds a retrieval workflow with the beneficiary bank
• Files a regulatory report if the issue is unresolved after 7 days

In parallel, disclosures about “user-entered data responsibility” are shown clearly during transfer confirmation.

This protects Wise legally and reputationally.

Why It Matters for PMs

• How you handle “bad days” defines your brand — and determines whether you keep your license

As a PM, you need to:

• Design flows for user feedback and complaint escalation
• Support detailed audit trails and response time tracking
• Embed clear, user-friendly disclosures into onboarding and transaction flows

A frictionless app is great — but a trustworthy, responsive app is what keeps users for life.

Perfect. Let’s wrap up with the first two topics from Section 8: Risk, Fraud & Security. These concepts form the frontline defense for fintech platforms — and they often work invisibly in the background.

71. Device Fingerprinting & Behavioral Signals — Knowing the User Without Asking

Picture this: A fraudster steals someone’s login credentials and tries to access their fintech account.

The username and password are correct — but the device is new, typing speed is erratic, and the mouse movements feel robotic.

The system instantly blocks the login. That’s the power of device fingerprinting and behavioral analytics.

What is Device Fingerprinting?

It’s a method to uniquely identify a user’s device using a combination of:

• Browser type & version
• Screen resolution
• Operating system
• Timezone
• Installed fonts/plugins
• IP address & network

These combined signals create a “device hash” or fingerprint — unique to the device, even without cookies.

Every time a user logs in or performs a sensitive action, the platform checks:

• Have we seen this device before?
• Is this device behaviorally consistent with past usage?

What Are Behavioral Signals?

These are passive, real-time cues about how a user interacts with your app:

• Typing rhythm
• Mouse movement patterns
• Tap pressure (on mobile)
• Session duration and sequence of actions
• Navigation habits (e.g., does the user always check their balance first?)

Together, these build a behavioral profile — like a digital body language.

Real-World Example

You’re a PM at Revolut, working on fraud prevention.

• A customer typically logs in every morning from an iPhone 13 using Face ID, checks their account, and makes a few transfers.
• One night, a login comes from a Chrome browser on a Windows laptop in another country.
• Device fingerprint: ✖️
• Typing pattern: ✖️ (slower and inconsistent)
• Behavior: ✖️ (goes straight to add payee — a red flag)

Result: Login blocked, OTP required, and session flagged for review.

Why It Matters for PMs

• These tools reduce fraud without hurting UX — no need for constant 2FA if risk is low

As a PM, you’ll need to:

• Integrate with device intelligence platforms (e.g., FingerprintJS, ThreatMetrix)
• Define thresholds for “normal” vs “risky” behavior
• Collaborate with risk teams to build adaptive authentication flows

It’s not just about who the user says they are — it’s whether their device and behavior feel right.

72. Synthetic Identities & First-Party Fraud — When the User Is the Fraud

Imagine this: A new user signs up, passes KYC with a valid-looking ID, takes a loan, and vanishes.

Only later do you discover that ID belonged to a real person, but the name and address were fake.

This wasn’t a stolen identity. It was a synthetic identity.

What is a Synthetic Identity?

It’s a fabricated digital persona created by blending real and fake information.

May include:

• Real Social Security Number (SSN) or national ID
• Fake name, email, phone, or address
• AI-generated face photos or forged documents

Unlike stolen identities (which belong to real people), synthetic profiles are fictional but plausible.

Fraudsters nurture these fake identities over time, making them look legitimate before committing fraud.

What is First-Party Fraud?

This occurs when the legitimate user themselves commits fraud.
Examples:

• Takes a loan with no intention to repay
• Disputes a real transaction claiming it was unauthorized
• Uses fake documents to qualify for a product

First-party fraud is hard to detect because:

• There’s no identity theft
• The user passed KYC and agreed to terms

Why These Are So Dangerous

• Synthetic and first-party fraud bypass traditional controls
• KYC and document verification alone won’t catch them
• Losses can be large and unrecoverable — especially in credit, BNPL, or crypto onboarding

Real-World Example

You’re a PM at a global lending fintech like Klarna.

• A user signs up with a real SSN but fake name and email
• Passes document verification using an AI-generated face
• Makes small, on-time payments to build credibility
• Suddenly maxes out multiple BNPL loans and disappears

Because the identity was synthetic, collections and legal recovery are impossible — it’s pure loss.

Why It Matters for PMs

• You must build multi-layered identity validation, not just rely on KYC vendors
• Combine data sources: device fingerprinting, behavioral signals, email/phone risk scores
• Consider onboarding risk scoring — declining or limiting exposure for risky new users

These fraud types don’t break into your system — they walk right through the front door.

73. Account Takeover (ATO) & Credential Stuffing — When Someone Else Walks Into Your Wallet

Imagine this: You wake up to 4 missed texts, 2 OTPs you didn’t request, and a drained bank balance.

You didn’t lose your phone. You didn’t give out your password.

But your account’s been emptied. You’ve just been hit with an Account Takeover (ATO) attack.

What Is Account Takeover (ATO)?

It’s when a fraudster gains unauthorized access to a legitimate user’s account and performs transactions as if they were the real person.

Usually done through:

• Phishing (fake login pages, emails)
• Credential stuffing (using leaked username-password combos from data breaches)
• SIM swapping (stealing SMS-based OTPs)

Once inside, they:

• Transfer funds
• Redeem loyalty points
• Change email/password to lock you out
• Even apply for credit or crypto withdrawals

What is Credential Stuffing?

It’s a brute-force technique where bots try thousands (or millions) of leaked credentials across platforms.

Why it works:

• Most users reuse passwords
• Fintech apps are juicy targets

Example: A fraudster gets hold of 500K login credentials leaked from a social media breach.

They use bots to test those logins on fintech apps like Chime, Cash App, or PayPal — hundreds might work.

Real-World Example

You’re a PM at PayPal.

• A customer’s account gets accessed from a new device in a different country.
• A few small test transactions are made (fraudster is testing card limits).
• Then comes a big one: a $2,500 transfer to a prepaid card.

Behind the scenes:

• Your system detects multiple login failures (credential stuffing pattern)
• The IP is on a known botnet list
• The transaction is flagged and reversed before settlement

This is where real-time monitoring + device fingerprinting + behavior analysis kick in.

Why It Matters for PMs

• ATO is not just about loss — it destroys user trust

You must:

• Enforce strong auth (2FA, passkeys, device checks)
• Monitor logins and high-risk flows for anomalies
• Use risk scoring before allowing password/email changes
• Educate users: “Don’t reuse passwords. Don’t trust that text.”

A fintech product that lets anyone take over your account is a product nobody uses again.

74. Friendly Fraud vs True Fraud — When the Customer Isn’t Always Right

Picture this:
A customer makes a legitimate online purchase, gets the product, and still disputes the charge with their bank:

“I never made this purchase.”

This is friendly fraud — and it costs fintechs and merchants billions every year.

What’s the Difference?

• True fraud = A third-party (like a hacker) made the purchase without the user’s knowledge. Example: Stolen card used on a travel site
• Friendly fraud = The real cardholder did make the transaction — but later denies it

Reasons include:

• Buyer’s remorse
• Child made the purchase
• Didn’t recognize the merchant descriptor
• Trying to get something for free

Why It’s So Tricky

• Friendly fraud looks exactly like true fraud on the surface
• The issuer (bank) typically sides with the customer
• The merchant or fintech has to prove the transaction was legitimate via: IP logs, Delivery receipts, Device fingerprint match and 3DS authentication records

Real-World Example

You’re a PM at Stripe, supporting merchants worldwide.

• A gaming customer disputes a $59 purchase.
• The merchant provides:
• Login IP matching past sessions
• 3DS authentication at checkout
• Usage of the product (game was played for 10+ hours)

Stripe packages this as representation to the issuer — and wins the chargeback.

But in many cases, especially small tickets, merchants simply absorb the loss.

Why It Matters for PMs

• Friendly fraud is a growing threat — especially in digital goods, subscriptions, and card-not-present scenarios

You need to:

• Build strong descriptors (so users recognize charges)
• Offer self-serve refunds to avoid escalations
• Collect and retain evidence for dispute handling
• Track which users dispute frequently (and cut them off if needed)

Sometimes the biggest fraud threat comes from the customers who seem the nicest.

75. Velocity Controls, Rules & ML Models — Your First Line of Defense in Stopping Suspicious Activity

Imagine this: A user signs up and, within the first 3 minutes, adds 3 cards, sends 5 peer-to-peer payments, and tries to withdraw their full balance.

Feels sketchy?

That’s exactly what velocity controls are built to catch.

What Are Velocity Controls?

They’re simple rule-based limits that monitor the speed and frequency of key actions in a given time window.

Examples:

• Max 3 card additions per hour
• No more than $500 withdrawn within 5 minutes of account creation
• No more than 5 logins from different IPs in 1 hour

They’re fast, easy to implement, and prevent obvious abuse patterns — like bot attacks or money mules.

Rules Engines — Adding Business Logic

Velocity controls are often part of a broader rules engine, which evaluates:

• Location (e.g., login from an unusual country)
• Amount (e.g., high-value transfer without 2FA)
• Time of day (e.g., late-night behavior spike)
• Device (e.g., unrecognized browser)

Each rule can result in:

• Allow ✅
• Challenge (OTP or KYC) ❓
• Block ❌
• Log for review 📄

Rules are usually deterministic — you define the condition, and the engine enforces it.

Where ML Comes In

Rules are reactive. Machine Learning (ML) models are proactive, learning patterns from historical data to predict fraud likelihood.

A good fraud ML model can look at:

• Historical fraud rates by device type
• Behavioral anomalies
• Network intelligence (shared fraud signals across merchants)

It returns a risk score, which the system can use to dynamically block, challenge, or allow a transaction — often in milliseconds.

Real-World Example

You’re a PM at Cash App.

• A newly onboarded account sends 8 instant payments to 5 different accounts within 15 minutes.
• The velocity rules engine flags this.
• A real-time ML model calculates a fraud risk score of 92/100.

You:

• Flag the user
• Freeze the balance
• Trigger KYC re-verification

This real-time blend of velocity + ML prevents account abuse before damage is done.

Why It Matters for PMs

• Fraud moves fast. You need tools that are:
• Configurable (rules)
• Scalable (ML)
• Explainable (logs for disputes)

PMs must:

• Design clear thresholds and escalation paths
• Continuously test new rules
• Collaborate with data scientists to monitor false positives/negatives

It’s not about building the “perfect” rule — it’s about catching the fraud before it catches you.

76. 2FA, OTP, Passkeys & FIDO — The Battle for Secure But Seamless Login

Picture this:

You try logging into your neobank account, and it asks for a password

Then sends a text OTP…Then asks for Face ID…

And now you’re wondering — is this security, or just pain?

Striking the right balance between security and friction is where the magic lies — and 2FA, OTPs, passkeys, and FIDO are your tools.

What is 2FA?

Two-Factor Authentication (2FA) means verifying identity using two of the following:

1. Something you know — password or PIN
2. Something you have — phone, authenticator app, device
3. Something you are — fingerprint, Face ID

Used together, these make account takeover dramatically harder.

Types of 2FA Methods

• OTP (One-Time Password)
  Sent via SMS or email — popular but vulnerable to SIM swapping
• TOTP (Time-based OTP)
  Generated by apps like Google Authenticator or Authy — more secure than SMS
• Push Notifications
  Ask the user to approve a login with one tap
• Biometrics (Face ID, Touch ID)
  Fast and secure, but device-dependent
• Passkeys & FIDO
  Modern, passwordless authentication using secure cryptographic tokens tied to a device (like Apple iCloud Keychain or Android biometrics)

Enter: Passkeys & FIDO2

Passkeys are part of the FIDO2 (Fast Identity Online) standard. Instead of passwords, users authenticate using:

• Device biometrics (Face ID, fingerprint)
• Encrypted keys are stored securely on the phone or laptop

No shared secrets = no phishing, no credential reuse, no leaks.

Big players like Apple, Google, and Microsoft are rolling this out rapidly.

Real-World Example

You’re a PM at Robinhood.

• You want to replace email + SMS OTP logins with passkeys
• Users can opt in and register their phone biometrics as their credential

On the next login:

• No password needed
• No OTP needed
• Just Face ID → authenticated

This lowers drop-off and improves security.

Why It Matters for PMs

You’re always walking a tightrope between user friction and account safety

As a PM:

• Choose fallback flows (e.g., allow email OTP if passkey fails)
• Educate users about safer options like passkeys
• Use adaptive auth — only challenge users when risk is high

The strongest lock on the door means nothing if the user refuses to open it — your job is to make security invisible yet unbreakable.

77. Tokenization, Vaulting & Key Management — Hiding the Crown Jewels Without Losing Access

Picture this: You’re building a fintech app that lets users save their debit card for one-click payments.

Storing the 16-digit card number (PAN) directly in your database would make you a target for hackers, regulators — and PCI auditors.

Instead, you use tokenization and vaulting. You never store the actual data — just a token that works like a secure stand-in.

What is Tokenization?

Tokenization is the process of replacing sensitive data (like a card number or bank account) with a non-sensitive, randomly generated token that has no exploitable value outside your system.

Example:

• Original card: 4111 1111 1111 1111
• Token: f92f91aa-36d4-44cf-b03a-b8c4e6f74b32

This token is meaningless to anyone outside the vault — but still works for you to initiate payments, refunds, and recurring charges.

What Is Vaulting?

Vaulting is where the original sensitive data is stored securely, typically:

• In a PCI-compliant server with encryption, audit trails, and strict access controls
• Often run by third-party providers like Very Good Security (VGS), Basis Theory, or Stripe’s Vault

You interact only with tokens — the vault handles the real data.

What Is Key Management?

Key management is how cryptographic keys are:

• Generated (using strong entropy)
• Stored (in secure environments like HSMs)
• Rotated regularly
• Revoked when compromised

All encryption (e.g., for vault data, 3DS secrets, JWTs) relies on robust key management — often via providers like AWS KMS, Google Cloud KMS, or HashiCorp Vault.

Real-World Example

You’re a PM at Plaid or Stripe.

• A merchant wants to store cards for recurring billing.
• You generate a token for each card and vault the PAN behind the scenes.
• Merchants never touch the card numbers — they use the token in their API calls.

If a hacker breaches the merchant’s system, the tokens are useless without access to the vault.

Why It Matters for PMs

• Tokenization minimizes your risk surface — and dramatically lowers compliance burden

As a PM:

• Decide when/where to tokenize (cards, bank accounts, SSNs, etc.)
• Choose whether to build or outsource the vault
• Coordinate with security/legal teams on scope and access policies

In fintech, protecting sensitive data isn’t just about safety — it’s about trust and survivability.

78. Data Breaches, PCI DSS & Scope Reduction — Why Your App Can’t Touch That Card

Imagine this: Your neobank gets 1 million signups in 3 months. Then one night, someone on your team accidentally logs raw card numbers to a file — and your system is compromised.

You now owe customers an apology, regulators a fine, and yourself a long weekend of damage control.

That’s why PCI DSS and scope reduction matter more than ever.

What Is PCI DSS?

Payment Card Industry Data Security Standard (PCI DSS) is a global compliance framework that defines how cardholder data must be:

• Stored
• Transmitted
• Processed

It applies to any business that touches card data — from startups to giants like Adyen or Stripe.

PCI DSS has 12 core requirements grouped under areas like:

• Network security (firewalls, encryption)
• Access controls (who can view card data)
• Logging & monitoring
• Penetration testing

Non-compliance can mean:

• Heavy fines (up to $500K per incident)
• Loss of ability to process cards
• Legal liability in case of breach

What’s a Data Breach?

A breach occurs when unauthorized parties access sensitive data, either due to:

• Code vulnerability (e.g., SQL injection)
• Insider error (e.g., credentials leaked on GitHub)
• Cloud misconfigurations (e.g., S3 buckets left public)

In fintech, breaches involving card or account data can trigger:

• Regulatory disclosures
• Customer attrition
• Lawsuits
• Bank partner fallout

What Is Scope Reduction?

Scope = any system that touches raw cardholder data.

To make your life easier:

• Use client-side tokenization (Stripe.js, Checkout SDK)
• Store only tokens, not actual PANs
• Route card data directly to the PSP (so your backend is not in scope)

Reducing scope reduces:

• Engineering overhead
• Security burden
• Compliance costs

Real-World Example

You’re a PM at a B2B SaaS platform that allows businesses to collect payments.

• Option A: You collect card details via a form and send them to your backend → Now you’re in PCI scope.
• Option B: You use Stripe Elements or Adyen’s Drop-in form → Card data goes straight to the PSP, and you only handle the token.

You just avoided Level 1 PCI compliance headaches and reduced breach risk.

Why It Matters for PMs

• Fintech PMs must build for security from day one

You’ll need to:

• Work with compliance teams on PCI audits
• Use PCI-compliant vendors wherever possible
• Train engineers on scope-reducing design choices

In fintech, the best way to protect user data… is to never touch it in the first place.

79. Dispute Management & Representment — Fighting Chargebacks Like a Pro

Picture this: A customer messages your support team:

“I didn’t make this $98 transaction. I want my money back.”

Next thing you know, a chargeback request lands via the card network — and you have just a few days to respond or lose the money (and pay a fee).

Welcome to the world of dispute management.

What Is a Dispute?

A dispute happens when a customer contacts their issuer (bank) to contest a card transaction.

This results in:

• The transaction is being reversed temporarily
• The merchant’s account was debited
• A chargeback process initiated

The merchant then has two choices:

• Accept the chargeback and lose the money
• Submit a representation (evidence to fight the dispute)

What Is Representment?

Representation is your chance to prove the transaction was valid. You typically submit:

• Proof of delivery (tracking, confirmation emails)
• 3DS authentication logs (for liability shift)
• IP and device match to past sessions
• Screenshots of in-app use (for digital goods)
• Refund policies & terms agreed at checkout

All of this must be submitted via your PSP or chargeback management platform within a strict time window (often 7–14 days).

Why Chargebacks Hurt

• You lose revenue + inventory, + fees
• Your chargeback rate (disputes / total transactions) is monitored
• Cross certain thresholds (e.g., 0.9% on Visa) and you get flagged
• Risk of being placed on monitoring programs or even being shut off by networks

Real-World Example

You’re a PM at Wise (formerly TransferWise).

• A user sends $500 to a friend via card.
• A week later, they dispute the transaction as “unauthorized.”
• Wise pulls logs:
• Location, IP, and device all match user history
• 3DS was completed
• User acknowledged receipt in app messages

Wise submits this for representation and wins the case — the chargeback is reversed.

Why It Matters for PMs

As a PM, you must:

• Build systems that collect dispute evidence at the time of transaction
• Set up alerts when disputes spike
• Track which flows (e.g., subscriptions, P2P) cause the most chargebacks
• Consider adding dispute APIs or self-serve tools

A fintech that can’t defend its transactions will lose both money and merchant trust

80. Business Continuity, DR & Incident Response — Because “Sorry” Isn’t a Strategy

Imagine this: It’s Monday morning. Your payments platform is down.
No logins, no payouts, no merchant dashboards. Slack is on fire. Your CEO is texting. Twitter is exploding.

You don’t just have a tech problem — you have a business continuity crisis.

What Is Business Continuity?

Business Continuity Planning (BCP) is how your fintech company prepares to continue critical operations during:

• Outages
• Cyberattacks
• Infrastructure failures
• Natural disasters

It involves:

• Backup systems
• Manual workarounds
• Escalation protocols
• Crisis communication playbooks

What Is Disaster Recovery (DR)?

DR is the technical side of business continuity — the plan to restore systems and data after a failure.

Example DR strategies:

• Multi-region deployment (AWS, GCP failover zones)
• Hourly database backups + restore testing
• Read replicas for degraded performance mode
• Warm standby environments

Goal: Get back up fast, even if at reduced functionality.

What Is Incident Response?

It’s how your org detects, contains, and resolves unexpected failures or breaches.

A good IR plan includes:

• Monitoring + alerting systems (Datadog, PagerDuty)
• Severity classification (SEV-1 vs SEV-2)
• War rooms + ownership rotation
• Postmortems with action items

Most fintechs use tools like:

• StatusPage for external comms
• Runbooks for repeatable troubleshooting
• Slack war rooms for coordinated response

Real-World Example

You’re a PM at Plaid.

One morning, a third-party API update causes your ACH verification flow to fail for 30% of users.

You:

• Trigger the IR team (SEV-2)
• Roll back the release
• Post an update on StatusPage
• Add logging to better detect similar failures
• Update your DR playbook to include fallback routing

Your merchants stay informed. Your users keep trusting you.

Why It Matters for PMs

• Fintech is mission-critical — if your app goes down, your users’ money is at risk

As a PM, you should:

• Understand your system’s DR and BCP policies
• Know where the single points of failure are
• Ensure incident response tools are baked into your product flow (e.g., retry buttons, grace periods)

In fintech, uptime is product quality — and recovery is part of the user experience

For a deeper dive, I highly recommend the course. It costs less than a burger yet delivers exceptional value for anyone looking to break into Fintech.

For a deeper dive, I highly recommend the course. It costs less than a burger yet delivers exceptional value for anyone looking to break into Fintech.

Fintech BootCamp: Master Financial Ecosystem

Recommend that you read these related articles:

21 Essential Fintech Concepts Every Product Manager Must Know

100+ Product Metrics: The Ultimate Guide for Product Managers

31 Startup business models you must know (with examples)

Topic 1: What is Fintech and how does it work

How Money and Finance have evolved over time

Imagine you want candy. But to get it, you must first:

Walk to a bank 2 km away, wait in the queue to withdraw cash, and then go to a shop that only accepts cash, hoping they have change.

Problem with banks: Too much friction, delay, and exclusion. They required physical branches and paper forms, excluded rural users and small merchants, and even delayed settlements of your money.

Now imagine an app lets you tap once, pay instantly, and the candy arrives in 15 minutes. That’s why we need Fintech Companies.

Fintech started by removing this friction, bringing speed, access, and control to everyday financial tasks.

Fintech = Financial Technology and refers to the integration of technology into financial services to:

• Improve accessibility, efficiency, and transparency
• Reduce costs and manual processes
• Serve new user segments underserved by traditional banks

Fintech spans across: Payments, Lending, Wealth Management, Insurance, Compliance, and Infrastructure. It’s not just startups: banks, ecommerce, payroll systems, and super apps are all embedding financial services today.

But how do all the payment, lending, and budget management apps we use work under the hood?

Let’s understand with the help of the Pipes and Platform Analogy

Topic 2: Introducing Pipes vs Platforms

When you turn on a faucet, clean water flows. But behind that tap are pipes, filters, and pumps. Fintech is the same — the app is the tap, but infrastructure does the heavy lifting.

• Pipes (Infra Layer): Core banking systems, payment rails, KYC, fraud checks. Tools like Mambu, Marqeta, Onfido, Finacle
• Taps (UX Layer): User-facing fintech apps: Groww, Cash App, Zopa

In fintech, there are two dominant business models: infrastructure providers (“pipes”) and customer-facing applications (“platforms”).

Plaid is a pipe powering APIs for apps. Chime is a platform using banking infrastructure to serve end-users.

a) Pipes — The Infra That Powers Fintech Builders

Pipes provides APIs, tools, and compliance rails, but doesn’t face end users directly, and monetizes through usage-based pricing or rev share

Examples: Stripe is in Payments, while M2P / Railsr is in Cards, loans, wallets, and Plaid is in bank account data aggregation

Why Pipes Matter: They can accelerate time to market, let builders focus on UX, not infra, and also enable regulatory compliance without licenses

Pipes are the silent engines — invisible, but critical to scale.

b) Platforms — The UX Layer That Interfaces With Users

Platforms deliver value directly to consumers or businesses, Monetize via MDR, interest, SaaS, or subscription, and Control UX, support, and trust layer

Examples: Cash App (US): P2P + investing + cards

• RazorpayX (India): Payouts + credit + current accounts
• Revolut (UK): FX + cards + investing
• Groww / INDmoney: Investing + wealth products

Topic 3 Digital Payment Systems and Their Types

So, what are digital payments, and can you explain to me like I’m 5

Imagine you’re at a candy shop. Instead of giving cash, you press a button on your phone. The shopkeeper smiles — they’ve been paid instantly.

So just like sending a photo through WhatsApp, digital payments let you send money instantly to someone — using phones, cards, or QR codes.

Digital payments are money transfers done electronically — no cash, no paper.

Examples: Card swipes at shops or websites, UPI or Faster Payments (FPS), Wallet top-ups and Buy Now Pay Later (BNPL), and Crypto wallets (e.g., Coinbase Pay, MetaMask Pay)

Anatomy of a Digital Payment Transaction

Every digital payment goes through four core players — the customer, merchant, bank, and a clearing engine that moves the money.

1. Customer side: Initiates payment via card, UPI, wallet, QR, etc.
2. Merchant/payment processor: Collects request, forwards via gateway
3. Bank side: Validates account, checks balance, settles transaction
4. Settlement engine: Moves money from payer to payee’s bank account (instantly or in T+1)
5. How does a Card payment work?

When you tap, swipe, or pay online, multiple players work behind the scenes to complete the transaction in seconds:

1. POS or Gateway captures your card info and sends it to the Processor.
2. The Processor forwards it to the Acquirer Bank (merchant’s bank).
3. The Acquirer routes it via a Card Network (e.g., Visa) to the Issuing Bank (your bank).
4. The Issuing Bank checks the balance and approves or declines.
5. The response returns, completing the purchase.
6. Later, funds are settled in batches — the Issuing Bank sends money to the Acquirer, who pays the merchant.

2. Pay by bank app — A New Way to Pay

Here’s how it works when you pay through Open Banking:

1. You tap “Pay by Bank” on a checkout page.
2. The app redirects you to your bank to approve the payment.
3. You log in and confirm via Face ID or OTP.
4. The money is moved directly from your account to the merchant.
5. You’re redirected back with a confirmation.

Why Open Banking Payments Are the Future

Open Banking isn’t just about convenience — it’s better by design:

• Secure: You never share card or account details
• Fast: Payments are real-time
• Cost-effective: No card fees
• Transparent: You control who accesses what and when

Whether you’re topping up, checking out, or settling invoices, Open Banking is transforming how money moves.

For a deeper dive, I highly recommend the course. It costs less than a burger yet delivers exceptional value for anyone looking to break into Fintech.

Fintech Product Management Bootcamp 2025 (25 hrs) — Enroll now

Topic 4 QR Codes & Tap to Pay for In-Person Payments

QR code payments allow users to scan a static or dynamic code using their mobile wallet or banking app to pay instantly.

It’s popular in Asia and emerging markets, requiring no hardware — just a smartphone and internet access.

Both methods are frictionless, hygienic, and mobile-friendly, reducing wait times and improving the in-person checkout experience. For merchants, they offer low setup costs and faster throughput, especially during peak hours.

QR Flows:

• Static QR — Same code, used multiple times
• Dynamic QR — Auto-filled amount/order (e.g., UPI)
• Deep Link QR — Opens payment app with context

Topic 5: Tap-to-Pay (NFC) Seamless In-Person Payments

Tap to Pay (contactless NFC) lets users pay by tapping their card or phone on a payment terminal. It’s fast, secure, and ideal for retail, transit, and quick-serve environments.

• Uses NFC chips in phones/cards
• Needs POS hardware (transit, cafés, retail)
• Fast and frictionless at physical counters

The future of payments is secure, seamless, and embedded. It’s not about form factors anymore — it’s about experience.

What’s Changing:

• Cards are turning into tokens stored securely
• Phones are replacing POS terminals (Tap-to-Pay)
• QR codes are enabling acceptance at scale

Why It Matters:

• Better UX — No swipe, PIN, or device handover
• Safer — Card data is never exposed
• Scalable — Works across apps, borders, and devices

Modern payment flows prioritize speed, safety, and adaptability over physical hardware.

Tap to Pay vs QR. Which is better?

Where do These Work Best?

• QR — India (UPI), Brazil (Pix), China (WeChat Pay)
• Tap to Pay — Urban POS systems, transit, modern retail

Offering both options ensures coverage across customer preferences and device types — a key part of building a future-ready payment stack.

Topic 6: Neobanks vs Traditional Banks vs BaaS

Why Digital Banking Isn’t One-Size-Fits-All

Digital banking today spans user-facing apps, backend infra, and regulatory licensing — often split across different players in the value chain.

Three Models Exist:

• Traditional Banks: Own license + infra + brand
• Neobanks: Offer UX, but rent infra
• BaaS Providers: Offer infra-as-a-service to fintechs

Traditional Banks — Strong on Compliance, Weak on UX

Traditional banks control customer funds and licenses directly, running on legacy systems. Their strength is scale and trust, not digital speed.

• Strengths: Regulatory credibility and Large balance sheets
• Weaknesses: Outdated legacy tech and Limited developer tools
• Examples: HSBC, SBI, Wells Fargo, Barclays

Traditional banks anchor the system, but struggle with speed and modern design.

Neobanks are mobile-first banks with sleek apps but rely on backend partners for actual banking services.

• Strengths: Fast onboarding, modern interfaces, and targeting digital-native users
• Weaknesses: Don’t have their license, and Infrastructure depends on third parties

Topic 7: BaaS — Banking as a Service

BaaS is like renting a ready-made banking kit so you can build your own finance app — without becoming a real bank. It helps you plug into tools like cards, payments, and KYC using APIs.

Why It Exists:

• Starting a bank is hard, expensive, and slow
• Most banks aren’t tech-friendly
• Startups want to launch fast with less effort

Example: Think of BaaS like using someone else’s kitchen to run your lemonade stand. You bring the idea, they handle the backend. Fintechs like Zolve and Step do exactly this.

Banking-as-a-Service (BaaS) enables fintechs to launch accounts, cards, lending, and compliance without holding a license — all powered through APIs.

Example: Slice (India), Step (US), and Zolve (US/India) all ride on BaaS rails for cards and accounts without owning bank licenses.

BAAS Key Capabilities:

• Allows you to create a Bank account and issue a card
• KYC and onboarding flows
• Compliance handling (AML, PCI, bureau reporting)
• Payouts, settlements, and recon dashboards

BaaS allows anyone to embed finance, even if they’re not a bank.

Global Leaders in BaaS — What They Offer

• M2P (India): Focus on cards, EMI tools, and regulated NBFC infra and Powers brands like Slice, Uni, and SBM cards
• Unit (US): API-first platform for accounts, cards, compliance, and used by accounting tools and SaaS platforms
• Railsr (UK/EU): Offers FX wallets, cards, credit tools, and is used by fintechs and brands across Europe

Tired of reading theory, let’ see all the strip’s products and learn things a better way

Topic 8: Payment Gateways and Processors

The Payment Mystery: Who’s Really Behind Your “Instant” Purchase?

Ever wonder what happens in those 3 seconds between clicking “Buy Now” and seeing “Payment Successful”?

You think it’s just you and Amazon, but there’s a whole crew working behind the scenes!

The Hidden Players:

• 🚪 Payment Gateway — The bouncer checking IDs
• ⚡ Payment Processor — The money-moving magician
• 🌐 Card Network — The rulebook keeper (Visa, Mastercard)
• 🏦 The Banks — Your bank (issuer) and the merchant’s bank (acquirer)

Example: You buy on Amazon → Razorpay (gateway) → FIS (processor) → Mastercard (network) → Your HDFC card → Amazon’s ICICI account

The Core Players: Gateway, Processor & Networks

1. Payment Gateway, the friendly cashier, is handling everything at the front desk. They collect and protect card info through checkout forms and send payment requests to the processor, and eventually show you the final result. Examples: Stripe, Razorpay, PayU

2. Payment Processor turns payment requests into actual money in your account. Connects your business to the banking world, runs fraud checks and verifies funds, and settles money (1–2 days later). Examples: FIS, WorldPay, Adyen

3. Card Networks — Internet infrastructure for money — set rules, don’t move money. Standardize how cards work globally, Charge interchange fees (~1.5% credit, ~0.5% debit). Examples: Visa, Mastercard, RuPay

The Complete Journey: From Click to Cash

Here’s what happens when you buy that ₹2,000 gadget online:

The 5-Second Symphony:

• You click “Pay” — Gateway captures your card details
• Gateway → Processor — “Can you process this ₹2,000 payment?”
• Processor → Network → Bank — “Does this person have ₹2,000 and is this legit?”
• Bank Responds — “Yes, approved!” (or “Nope, declined”)
• You see the Result — “Payment Successful!” appears
• Settlement (1–2 Days Later) — Money moves from your bank to the merchant’s bank

The Amazing Part: This involves 5+ companies across multiple countries, but happens faster than you can blink!

Topic 9: Issuer and Acquirer in Card-Based Payments

But why do Cards Still Dominate Global Payments?

Even in a world of A2A and wallets, cards remain the backbone of commerce. Here’s why:

• Accepted Everywhere — Visa/Mastercard work online & offline globally
• Credit and Rewards — Drive loyalty and spending
• Trusted & Secure — 3DS, chargebacks, and mature fraud systems
• Globally Interoperable — Smooth across currencies and countries

Key Roles in a Card Transaction:

• Issuer — User’s bank or fintech
• Acquirer — Merchant’s PSP or bank
• Network — Visa, Mastercard, Amex
• Processor & Gateway — Power the backend tech

Issuing vs. Acquiring — Two Sides of the Card Game

Issuers: The Consumer Side

• Approve cards, set limits, handle billing, and disputes
• Examples: Capital One, Apple Card, Monzo, Slice
• Fintechs issue cards via APIs, BIN sponsors, and BaaS platforms

Acquirers: The Merchant Side

• Onboard merchants provide terminals/gateways
• Manage settlements, payouts, and fraud checks
• Key players: Stripe, Adyen, Razorpay, PayPal

Together, issuers and acquirers enable and settle every card transaction.

Want to go from curious to confident in Fintech?

Dive deeper with the Fintech Product Management Bootcamp 2025 — a 25+ hour course packed with real-world insights and case studies for less than the price of dinner.

Fintech Product Management Bootcamp 2025 (25 hrs) — Enroll now

Topic 10: Payment Checkout and Methods

The checkout page is where users either complete the purchase or drop off. Design, speed, and security all matter.

Problems to Solve to checkout:

• High cart abandonment at the payment step
• Poor UX from slow or complex forms
• Regulatory friction, like 3DS authentication
• Low retry success if payment fails

Checkout Speed and Conversion

A normal checkout flow typically asks users to enter their shipping details, payment information, and contact data from scratch. It offers flexibility — users can choose delivery options or edit details — but it’s slower and more prone to cart abandonment.

In contrast, express checkout lets returning users pay in one or two clicks by pre-filling saved data (via wallets like Apple Pay, Google Pay, or Stripe Link). It minimizes friction, especially on mobile, and significantly improves conversion for repeat customers.

The Check Out flow must balance the user convenience vs Fraud prevention and should be mobile-optimized and ensure the Payment options vs checkout simplicity

Smart product teams often offer both options: express checkout upfront for speed, and a full checkout form below for users who need more control or are checking out for the first time.

A great checkout experience can lift conversions by 20–30% or lose them entirely.

Why Local and Multiple Payment Methods Matter at Checkout

Customers expect to pay using methods they trust and prefer — and these vary widely across regions.

While cards dominate in some countries, others rely more on wallets, A2A systems, BNPL, or even cash-based vouchers.

Offering local payment options like UPI in India, iDEAL in the Netherlands, or Klarna in Germany boosts trust and increases the chance of conversion.

For merchants, supporting multiple methods improves coverage, success rates, and revenue, especially when expanding globally.

A one-size-fits-all checkout is no longer enough — localized, flexible payment options are now a growth lever, not just a feature.

Topic 11: Hosted and Embedded Checkout

Hosted vs Embedded are the two main approaches with different strengths that a company can choose based on the priorities.

1. Hosted Checkout offers the fastest way to go live with payments, providing a fully PCI-compliant solution out of the box.

It automatically handles authentication and requires minimal backend integration, making it ideal for rapid launches.

2. Embedded Checkout Benefits:

It supports saved cards and custom flows and making it Easier to A/B test and optimize, and keeps users on your domain

The Trade-off:

Hosted = speed vs control while Embedded = control vs complexity.

Hence, the Best Choice is to use Hosted for MVPs, embedded for scale-up products.

Checkout Retry Logic — Recovering Failed Payments Smoothly

Not all payment failures mean lost revenue — smart retry logic can help recover many of them without frustrating the user.

Common failure points include network timeouts, expired cards, insufficient funds, or 3DS/OTP issues. With saved card tokens, systems like Stripe can automatically retry payments after a short delay or on a specific trigger (e.g., salary credit date).

Other strategies include fallback options like switching to UPI or wallet, or prompting users in-app to re-enter CVV or select a new method.

Done right, this logic can lift post-failure conversion by 10–15%, turning declined payments into successful ones with minimal user friction.

Topic 12: What is 3D Secure and how does it work?

3D Secure 2 (3DS2) is a mandatory layer of authentication in card payments designed to reduce fraud and protect both users and merchants.

3D Secure 2 is required under PSD2 (EU), SCA (UK), and by RBI (India) and typically involves an OTP, biometric, or push notification from the card issuer before approving a transaction.

While it effectively lowers fraud risk, it introduces 5–20 seconds of friction, often causing OTP failures or drop-offs, especially on mobile.

3DS is needed when:

• The payment is high risk or flagged by fraud systems
• The issuing bank requires strong customer authentication (SCA)
• The merchant operates in a regulated market

3DS is essential — but to keep conversions high, it should be UX-optimized using auto-fill, biometrics, or native SDKs to make the experience smoother without sacrificing security.

While it adds a few seconds of friction, 3DS helps lower fraud rates.

Topic 13: Tokenisation Balancing Security and Speed

What Is Card Tokenization and Why Does It Matter?

When a customer enters their card details on a checkout page, those details — such as card number and CVV — are sensitive and must be protected.

Card tokenization is a security technique that replaces this sensitive data with a non-sensitive equivalent, called a token. This token can be used for processing payments without ever exposing the actual card number again.

For example, instead of storing a 16-digit card number, a merchant stores a unique token like tok_1a2b3c....

The card number gets converted to a token (via Visa, Mastercard). Stored on device, browser, or vault, and the Merchant or PSP never sees the real card number (PAN)

Even if a token were intercepted, it would be useless to attackers without the original card details and cryptographic keys managed by a PCI-compliant provider like Stripe.

Tokenization is essential for:

• Reducing PCI compliance burden for businesses
• Preventing card data breaches and fraud
• Enabling faster checkouts by securely storing card information for reuse
• Supporting features like one-click checkout and recurring billing

It’s not just about security — it also enables better user experiences.

When card details are tokenized and linked to a customer profile, returning users can check out faster without re-entering their information.

Where It’s Used: It is used in Apple Pay, Google Pay, Samsung Pay, In-app cards (Uber, Amazon), and in Token vaults (Stripe, Razorpay)

Summarise: How Stripe Link Enables Faster, Smarter Checkouts

Stripe Link enables one-click checkout by storing card details securely using tokenization. After a user’s first purchase, their card is saved as a token — allowing them to pay instantly across any Stripe Link-enabled site.

This removes friction for repeat users, reducing the need to re-enter card details or go through full authentication steps again. It speeds up checkout from over a minute to just a few seconds.

Stripe Link also handles 3DS flows intelligently, often using biometric or OTP autofill, making the experience secure but seamless.

Combined with tokenization and dynamic retry options, Stripe Link helps reduce cart abandonment and improve overall checkout conversion.

Topic 14: MDR (Merchant Discount Rate)

MDR (Merchant Discount Rate) is the fee deducted from a transaction before the merchant gets paid. It’s shared across four players:

• Issuer — 50–70% (interchange)
• Network — 10–15% (markup/assessment)
• Acquirer — 15–25% (margin)
• Gateway — Charged separately or bundled with PSP

For example, on a $1,000 card payment with a 2% MDR, the merchant receives $980, while $20 is split across the payment ecosystem.

MDR covers infrastructure, fraud protection, and operational costs, but also directly impacts a merchant’s margins — especially in low-margin industries like grocery or fuel.

Typical MDR Rates:

• Credit cards — 1.5–3% globally
• Debit cards — 0.3–1% (regulated in many markets)
• Amex/commercial cards — 2.5–4%

Rates vary by payment method (card, wallet, UPI), merchant category, and transaction volume. High-volume or essential service merchants often get lower negotiated MDRs.

Regulatory Caps:

• EU — Debit 0.2%, Credit 0.3%
• India — RuPay ~0.6%
• US — Varies by network

When Cards Make Sense — And When They Don’t

Best Use Cases:

• Cross-border commerce (Visa/Mastercard reach), where collecting bank payments and transferring money to the continent is diffcult
• Credit-linked subscriptions or products, as banks hate building and maintaining their complex subscription logic themself
• Loyalty-driven customer segments

Where Cards Fall Short:

• Low-margin merchants (can’t absorb MDR)
• A2A-dominant markets (e.g., UPI, RTP)
• Instant settlement needs (wallets, real-time A2A)

What’s Emerging:

• Tokenized cards + mobile NFC
• Card-based BNPL (e.g., Slice, Zilch)
• Gen Z shift to non-card methods in Asia and Africa

Cards remain central to digital payments — but now face real competition from faster, cheaper rails.

Topic 15: Account-to-Account Payments

A2A Payments — Moving Money Without the MiddlemenAccount-to-account (A2A) payments let users send money directly from their bank account — no cards, no wallets.

They’re typically powered by domestic rails like UPI (India), ACH (US), SEPA (EU), or FPS (UK).

Unlike card payments, A2A involves no intermediaries charging interchange fees, making it a low-cost option for both merchants and users.

Why A2A Is Taking Off:

• Lower cost than card payments and have Real-time fund transfers
• Great for recurring or high-value transactions

It also supports instant settlement in many markets, improving cash flow and reducing payment delays.

A2A is ideal for bill payments, subscriptions, salary disbursals, and increasingly, merchant checkout flows where cost and speed matter.

Popular A2A Rails:

• UPI (India) — Mobile-first, instant
• ACH (US) — Slower, batch-based
• RTP (US) — Real-time and FedNow-aligned
• FPS (UK) — Instant bank-to-bank
• SEPA Instant (EU) — Euro-wide reach

How A2A Payments Work — Behind the Scenes

A2A payments follow different flows based on geography and rail:

Flow (UPI / RTP / FPS):

• Select “Pay from Bank”
• Authenticate via bank/UPI app
• Confirm via PIN, biometric, or OTP
• Funds settle instantly

Flow (ACH):

• Share routing + account number
• Give consent for recurring use
• Payment clears in T+1 to T+3 batches

Authentication Methods:

• Bank login, OAuth, PIN
• In-app push or SMS OTP

Topic 16: Wallet Infrastructure and Its Types

Even with A2A and cards, digital wallets offer unique advantages:

Why Wallets Persist:

• Instant checkout without repeat authentication
• Support for loyalty, offers, and stored value
• Work in low-connectivity zones
• Combine payments, identity, and rewards

Examples: Apple Pay, Google Pay (tokenized card wallets), Paytm, GCash, Venmo, M-Pesa, and PayPal — Digital-first ecosystem

Wallets succeed by becoming part of the user’s daily flow, not just a payment method.

Wallet Types — Closed, Semi-Closed & Open

Wallet types differ by regulatory scope and usability range:

• Closed Wallets: Work only within one platform (e.g., Starbucks, Ola Money) and can’t be used for external use or redemption, and are often used for promos or loyalty
• Semi-Closed Wallets: Can be used at partner merchants, but no direct withdrawal to the bank, and governed by KYC thresholds
• Open Wallets: Issued by banks or NBFCs with full KYC but Support cash-out, P2P, and POS transactions. Examples: M-Pesa, PayPal, Paytm (post-KYC)

Wallet Use Cases & Monetization Models

• India: Products like Paytm, PhonePe — Wallet + UPI for QR, bill pay, utilities, and all these are governed by semi-closed rules from the RBI
• Africa (Kenya): M-Pesa — Telecom wallet with cash agents, remittances, and utilities, and offers micro-credit features
• US/EU: Apple Pay, PayPal — Tokenized wallets, used for e-commerce

How wallet make money, i.e, Revenue Levers:

• MDR (1–2%), float income
• Cross-sell: credit, gold, insurance
• Commissions from bill pay, cashback

Wallets drive monetization through engagement, float, and embedded services.

Topic 17: Cross-Border Money Transfer

Cross-Border Payments Are Still Slow, Expensive & Opaque

Sending money across borders is often slow, hard to track, and full of hidden fees — even in 2024.

The Core Problems:

• Delays: 1–5 days for traditional transfers
• Hidden costs: Intermediary bank fees, markups
• Poor visibility: No real-time tracking or FX quote

Real Scenario: A freelancer in Kenya waits 4 days for a client’s wire from the US — loses 7% in fees + FX difference.

The problem lies in the underlying slow banking system i.e, SWIFT

How SWIFT Works — The Legacy Backbone of Global Payments

SWIFT (Society for Worldwide Interbank Financial Telecommunication) powers most global wires, but wasn’t built for speed.

How It Works:

• Bank A sends payment instructions to Bank B via SWIFT messaging
• Funds pass through 1–3 correspondent banks
• Each bank may charge processing fees
• Settlement can take 2–5 days

Limitations: No real-time status, Limited FX control, and Fee deductions at each hop but Still Used For: B2B transfers, High-value and Regulated markets (e.g., USD wires to Africa)

So SWIFT is global but not real-time. Now compare that to Wise, which settles in hours with transparent pricing.

Enter Modern FX APIs — Real-Time, Transparent, and Scalable

Modern FX APIs allow platforms to send, convert, and settle payments globally — in near real time.

Key Features:

• Mid-market FX rates + clear fee breakdown
• Virtual accounts in multiple currencies
• Real-time payout tracking + webhook alerts
• Lower cost than banks (0.5–1.5% markup vs 3–5%)

Examples:

• Wise (UK): Peer-to-peer FX with 50+ currency coverage
• Airwallex (AU): Multi-currency accounts for global SaaS/ecommerce
• Payoneer (US): Freelancer and SME payouts across 190+ countries

Cross-border infra is being rebuilt — faster, cheaper, and fully digital.

Topic 18: FX Pricing — Markups, Mid-Market & Conversion

FX Pricing Isn’t What It Seems — And That’s a Problem

FX Pricing: The Hidden Cost Hurting Users

Most users don’t know the actual FX rate they receive, or how much they lose on every transfer. Banks and platforms often advertise “free” transfers but silently apply high FX markups.

The Problem: Legacy providers hide 1–5% FX spreads in the exchange rate itself. Fees are shown as zero, but margins are buried in poor conversion rates.

Real Impact:

• Google rate: 1 USD = 85 INR
• Platform rate: 1 USD = 82.75 INR
• A 2.6% hidden fee, despite showing “no fees.”

Understanding FX pricing is essential for transparency, fairness, and building user trust. Traditional methods like SWIFT and card payments quietly cost more than they appear.

FX Pricing Models — Fixed, Tiered, or Spread-Based

Modern FX platforms use different pricing models to balance cost, transparency, and volume.

1. Spread-Based (Most Common): Small markup on mid-market (0.25–1.5%) and Dynamic per currency pair like Wise

2. Tiered FX Pricing: Better rates for higher volumes like Airwallex, Payoneer

3. Fixed FX Contracts: Custom locked rates for enterprises like Banks, treasury desks

Pricing models affect not just cost, but also monetization and trust.

FX Cost Breakdown — Know What You’re Paying For

Example:

• Transfer $1,000 from the UK to India
• FX spread loss: $25
• SWIFT fee: $20
• Net received = ~$955 or less

Even low-fee platforms can be expensive if FX is mispriced — transparency is key.

Topic 19: Treasury Flows — Settlement Cycles and Ledgers

The Hidden Engine of Global Payments

Cross-border payouts may feel instant, but behind the scenes, it’s a complex machine of ledgers, liquidity pools, and FX risk management.

What actually happens:

• Funds may show as “sent” but settle 1–2 days later (T+1/T+2)
• Liquidity needs to be pre-funded across currencies
• Treasury teams manage FX exposure, timing, and reconciliation

Example: An e-commerce platform credits sellers in INR instantly, but the USD is settled a day later using internal shadow ledgers.

Understanding T+1 and Rolling Settlement Models

“T+1” means the transaction settles one business day after it’s initiated — now a common model in FX and cross-border B2B flows.

Settlement Types:

• T+0 (Instant): Real-time, rare for cross-border
• T+1: Funds settle next business day
• T+2 or T+3: Common in capital markets and legacy banking

Used In: SME payouts, Remittance batch settlements, and SaaS vendor invoice payments

T+1 offers a practical tradeoff — fast enough for user experience, manageable enough for FX and liquidity risk.

Multi-Currency Ledgers — How Fintechs Track Balances Internally

Platforms operating in multiple currencies need internal systems to track balances, conversions, and obligations in real time.

What Ledgers Store:

• Virtual wallet balances by currency
• FX-converted equivalents
• Pending vs available balances
• Holds for chargebacks or reserve ratios

Best Practices:

• Isolate FX impact from the core ledger
• Reconcile with the banking partner daily

Example: Airwallex offers platform clients a multi-currency ledger-as-a-service model.

Treasury Flows — The Story Behind “Instant” Global Payments

Imagine a UK-based marketplace paying an Indian seller in INR. The seller sees the money instantly, but behind the scenes, it’s a complex orchestration.

The platform holds USD in a U.S. bank. When a payout is triggered:

• A T+1 model settles INR the next day, but a shadow ledger shows real-time.
• It either pre-funds INR locally or uses just-in-time FX.
• A multi-currency ledger tracks balances, conversions, and reserves.
• A solid treasury stack — banks, FX engines, APIs — manages liquidity, reconciles funds, and monitors issues like slippage.

To the seller, it feels instant, but it’s smart treasury infra balancing speed, cost, and reliability.

Building the Treasury Stack — Liquidity + Tooling

To run global flows, fintechs combine banks, FX engines, and automation tools.

Liquidity Models:

• Pre-funding (e.g., Wise): Fast payouts, higher capital cost
• Just-in-time FX (e.g., Revolut): Lower float, risk of delays

Stack Components: Local banking partners, FX & settlement engines and Risk monitoring (FX slippage, reconciliation gaps)

Key KPIs to Track:

• Time to Settle (TTS)
• FX slippage
• Pre-funding float
• Retry/failure rate
• Reconciliation gaps

Want to go from curious to confident in Fintech?

Dive deeper with the Fintech Product Management Bootcamp 2025 — a 25+ hour course packed with real-world insights and case studies for less than the price of dinner.

Fintech Product Management Bootcamp 2025 (25 hrs) — Enroll now

Topic 20: Smart Routing and Orchestration

Why Smart Routing Decides Payment Success

The choice of payment path impacts success rates, costs, and speed. Single-processor systems break when that route fails, leading to lost revenue.

Problems with Basic Routing:

• Single-processor systems fail if the route goes down
• No fallback equals lost payments
• Missing optimization on success rates

What Smart Routing Does:

• Picks the best payment path dynamically
• Routes based on BIN, geography, and network conditions
• Uses historical success rates to optimize

Smart routing can lift success rates by 3–10%.

Orchestration: Managing Multiple Payment Partners

Payment orchestration manages complex flows across processors and countries. Not every business needs it on day one, but knowing when to invest is crucial.

Key Features:

• Abstracts the multi-PSP setup complexity
• Unified dashboard to configure flows
• Supports fallback and A/B testing

When to Use Single vs Multi:

• Single: Faster to go live, easier integration
• Multi: Redundancy for uptime, optimized routing
• Sweet Spot: Start bundled, add at $10M+ GMV

Popular Players: Primer, Juspay, Razorpay’s Magic Retry

Complete Payment Strategy: The Three Pillars

Smart routing + orchestration + webhooks ensure reliability and global scale. The most successful fintechs orchestrate payments, not just process them.

How the Layers Work:

• Smart Routing: Choose the best route dynamically
• Orchestration: Configure flows across PSPs
• Webhooks: Real-time event notifications

Implementation Strategy:

• Start with bundled solutions (Stripe, Adyen)
• Add orchestration at $10M+ GMV
• Monitor success rates by BIN and geography

Final Tips: Always auto-retry failed webhooks, run sandbox testing for fallbacks, and Track routing performance in real-time

Topic 21: Refunds, Chargebacks, and Disputes

After a transaction, things don’t always go smoothly — customers may request a refund, raise a chargeback, or dispute a payment for various reasons.

Understanding these flows is key to managing risk and customer trust.

A refund is initiated by the merchant — usually for returns, cancellations, or service issues. It reverses the payment, returning funds to the customer’s original method.

Inside a Chargeback: The Journey from Dispute to Ruling

Imagine a customer sees a charge they don’t recognize on their card. They reach out to their issuer (their bank), claiming it’s unauthorized or that the product was never delivered.

The issuer investigates and finds the claim valid, triggering a dispute.

A dispute refers to the overall process of investigating and resolving a chargeback. Merchants can submit evidence (like shipping records or signed receipts) to challenge the claim.

This kicks off pre-arbitration, where the acquirer has 30 days to respond. They can accept the claim or push back with supporting evidence. If they contest it, a pre-arbitration response is sent to the issuer, also within 30 days.

If both sides still disagree, the case enters arbitration, and Visa steps in. Each party gets 10 days to submit final evidence before Visa delivers a final ruling.

This process ensures fair resolution, but it’s time-bound and resource-heavy — so preventing disputes upfront remains the smartest strategy.

So in disputes the Funds are pulled from the merchant and returned to the user unless the merchant can successfully defend the case.

What is the problem with charbacks?

Too many chargebacks hurt a business’s reputation and may lead to fines or payment restrictions. That’s why strong fraud prevention, clear policies, and easy refund handling are essential to avoid escalations.

Topic 22: Reconciliation: The Back Office Mess

You’re a PM at a growing D2C brand, accepting payments via Stripe, Razorpay, and PayPal. Orders come in fast — but your finance team is stuck in a daily mess.

A $999 payment settles as $970 after fees. A refund on Stripe shows up a day later. A PayPal chargeback deducts money with no clear match in your system. Each platform has its own timing, formats, and rules, making it nearly impossible to track what was actually earned or lost.

This is the reconciliation challenge — matching sales, payouts, refunds, and disputes across systems. Without it, you risk accounting errors, delayed reports, and poor cash flow visibility.

Smart teams automate reconciliation with tools that standardize data, auto-match by payment or order ID, and flag mismatches. It’s not just finance ops — it’s critical fintech plumbing.

Unified Back Office Reconsilation: The Complete Solution

Smart platforms unify refund tracking, chargeback defense, and reconciliation in one place.

Modern Infrastructure Design:

• Refund Tracker: Show users’ timeline and status
• Chargeback Ops: Track alerts and defend disputes
• Reco Engine: Match bank, gateway, and app records

The Stripe Stack: 15 Products That Power Modern Internet

Question 1: I want to launch my startup, but don’t live in the U.S. How do I register and get started?

1. Stripe Atlas — Start a business in the USA

Stripe Atlas helps global entrepreneurs start and run a U.S. business, including incorporation, tax ID setup, and bank account opening. It’s a fast, all-in-one solution for founders looking to enter the U.S. market.

• Use Cases: Startups based in India, Europe, Africa, and Remote-first SaaS companies
• Example: Hundreds of YC-backed startups have used Atlas to form Delaware C-Corps.
• Merchant Usage: Apply via Stripe Atlas to receive legal, tax, and banking support in one place.

Question 2:Now that I’m set up, how can I accept payments online and globally?

2. Stripe Payments — Core Payment Processing

Stripe Payments lets businesses accept online and in-app payments using cards, wallets, bank transfers, and local methods. It’s designed to simplify global payment acceptance through a single integration, removing the complexity of handling regional methods, security, and compliance.

Use Cases: E-commerce checkouts, SaaS platforms, and International online stores

Example: Shopify uses Stripe Payments to accept cards and wallets across multiple countries.

Merchant Usage: Integrated via Stripe Checkout or APIs for a custom payment experience.

Question 3: I want a payment page but don’t want to build one from scratch. What’s the easiest way?

Stripe Checkout offers a ready-to-use, responsive payment page that supports cards, wallets, discounts, and tax. It’s optimized for conversion and mobile and reduces the need to build a secure payment flow from scratch.

• Use Cases: Digital product sales, Subscription signups, and Donation pages
• Example: Notion uses Checkout to let users upgrade their accounts securely.
• Merchant Usage: Redirect customers to a Stripe-hosted page via a single API call.

Question 4:What if I want a branded checkout UI instead of using a hosted page?

Stripe Elements provides prebuilt, secure UI components like card inputs and payment buttons, allowing full control over the checkout experience while staying PCI-compliant.

• Use Cases: Custom website payment flows, Mobile-first apps, and Branded customer journeys
• Example: Instacart uses Elements to match its checkout design while maintaining security.
• Merchant Usage: Add Elements to the frontend with the Stripe JS SDK and minimal backend setup.

Question 5: I want to accept payments in-store too. How do I go beyond online?

Stripe Terminal bridges online and offline commerce with hardware and SDKs to accept in-person payments. It allows businesses to unify payment tracking across all channels and geographies.

• Use Cases: Retail stores and pop-ups, Event ticketing and Cafés, and in-person services
• Example: Glossier uses Terminal to offer a consistent checkout experience in stores.
• Merchant Usage: Connect certified card readers to mobile or web apps via Stripe SDKs.

Question 6: How do I manage recurring payments and subscriptions easily?

Stripe Billing helps businesses manage subscriptions, metered usage, trials, and recurring invoices. It streamlines billing complexity with built-in support for pricing models, revenue recognition, and customer portals

• Use Cases: SaaS billing models, Content or membership subscriptions, and Cloud usage-based platforms
• Example: Slack uses Billing to charge per seat and manage self-serve upgrades.
• Merchant Usage: Configure pricing plans and subscription flows via dashboard or API.

Question 7: I don’t use subscriptions, but need to send invoices and get paid online.

Stripe Invoicing allows merchants to generate, send, and track invoices with built-in tax and payment capabilities. It eliminates manual billing and helps businesses get paid faster across borders.

• Use Cases: Freelancers and agencies, B2B SaaS vendors and One-off service providers
• Example: Consultants use Invoicing to email invoices and collect online payments from global clients.
• Merchant Usage: Create invoices via dashboard or automate using the API.

Question 8: How can I become a platform like Uber or Upwork and pay multiple users?

Stripe Connect enables platforms like marketplaces or gig apps to handle multi-party payments. It manages onboarding, compliance (KYC), and fund splitting so that businesses can focus on their core offering without building complex payout infrastructure.

• Use Cases: Food delivery apps, Creator platforms, and Freelance marketplaces
• Example: Lyft uses Connect to manage and pay thousands of drivers seamlessly.
• Merchant Usage: Choose from Standard, Express, or Custom accounts depending on control needs.

Question 9: Can I offer financial services like bank accounts to my users?

Stripe Treasury lets platforms offer bank-like financial features such as balances, interest-bearing accounts, ACH transfers, and card access — without needing to become a bank themselves.

• Use Cases: Creator and gig economy platforms, Business management apps, and Vertical SaaS platforms
• Example: Shopify Balance is powered by Stripe Treasury to provide merchant accounts.
• Merchant Usage: Build financial workflows using APIs to embed treasury services.

Question 10: Can I issue branded cards to users or employees?

10. Stripe Issuing — Create Virtual & Physical Cards

Stripe Issuing enables businesses to instantly create, manage, and distribute branded debit or expense cards to users or employees. It offers controls over spend, real-time rules, and seamless integration with fund flows.

• Use Cases: Fintech apps and neobanks, Corporate expense management, and Instant cashback or disbursement tools
• Example: Ramp uses Issuing to power its corporate card infrastructure.
• Merchant Usage: Use Stripe’s API to issue cards, manage limits, and monitor usage.

Question 11: How do I prevent fraud and chargebacks on my platform?

11. Stripe Radar — Smart Fraud Protection

Stripe Radar uses machine learning to automatically detect and block fraudulent transactions. It continuously improves based on patterns across millions of global businesses, reducing chargebacks and fraud risk.

• Use Cases: High-volume e-commerce, Cross-border merchants and Subscription platforms
• Example: Shopify relies on Radar to protect its merchants from fraud at checkout.
• Merchant Usage: Enabled by default with Stripe Payments and customizable via rules dashboard.

Question 12: How do I comply with global tax laws without a full finance team?

12. Stripe Tax — Global Tax Automation

Stripe Tax automates the calculation and collection of sales tax, VAT, and GST in over 40 countries. It ensures tax compliance, manages thresholds, and supports both digital and physical product sales.

• Use Cases: International SaaS, Global e-commerce and Digital marketplaces
• Example: Notion uses Stripe Tax to handle global tax collection without a dedicated tax team.
• Merchant Usage: Enable tax in Checkout or Billing with automatic jurisdiction detection.

Question 13: How do I verify customer identities securely and at scale?

13. Stripe Identity — Fast and Secure Identity Verification

Stripe Identity verifies users with document scans and selfies, helping businesses meet KYC requirements and prevent fraud. It detects fake or altered IDs with machine learning and government data checks.

• Use Cases: Fintechs and digital wallets, Online platforms requiring age or identity proof, and Community platforms with sensitive content
• Example: Discord uses Stripe Identity to verify users in regulated communities.
• Merchant Usage: Launch via hosted flow or API integration for seamless user verification.

Question 14: Can I automatically send all my Stripe data to my analytics stack?

14. Stripe Data Pipeline — Sync Financial Data to Warehouses

Stripe Data Pipeline automatically syncs payment and financial data to analytics warehouses like Snowflake or Redshift. This supports advanced reporting, forecasting, and financial modeling.

• Use Cases: Revenue analytics teams, CFO dashboards, and Customer lifetime value tracking
• Example: SaaS companies sync subscription data for churn prediction models.
• Merchant Usage: Connect data warehouses via the Stripe dashboard or programmatically.

Question 15: Is there a way I can contribute to sustainability as a business?

15. Stripe Climate — Support Carbon Removal

Stripe Climate enables businesses to allocate a portion of revenue toward verified carbon removal technologies. It makes it easy for companies to act on climate goals without large internal programs.

• Use Cases: Purpose-driven e-commerce, DTC brands, marketplaces, and Subscription startups
• Example: Substack contributes a portion of its revenue via Stripe Climate.
• Merchant Usage: Opt in from the dashboard and track impact transparently.

Want to go from curious to confident in Fintech?

Dive deeper with the Fintech Product Management Bootcamp 2025 — a 25+ hour course packed with real-world insights and case studies for less than the price of dinner.

Fintech Product Management Bootcamp 2025 (25 hrs) — Enroll now

Recommend that you read these related articles:

21 Essential Fintech Concepts Every Product Manager Must Know

100+ Product Metrics: The Ultimate Guide for Product Managers

31 Startup business models you must know (with examples)

As a Fintech product manager, I spent years mastering the fundamentals of Fintech. I’ve distilled all of my knowledge into a single, comprehensive article.

For a deeper dive, I highly recommend the course. It costs less than a burger yet delivers exceptional value for anyone looking to break into fintech product management.

Fintech Product Management: Become a Fintech PM.

Concept 1. Banks, Banking Systems and Infrastructure

If you’re new to this domain, understanding payment systems and infrastructure is essential, as they form the backbone of the fintech ecosystem.

Gaining this knowledge will help you build a solid foundation in fintech. To make it easier, I’ve divided this into three main parts.

a) Overview of Payment Systems: We will explore the fundamental concepts that underpin payment systems, including the transfer of funds, processing, and settlement.

b) Payment Instruments: Examining various payment instruments such as cash, checks, and electronic forms, and their role in the financial ecosystem.

c) Participants in Payment Systems: Understanding the key entities involved in payment processes, including payers, payees, banks, and intermediaries.

a) Understanding the Basics of Payment Systems

Banks generate profit from the difference in interest rates between deposits and loans. They effectively create money by lending out a portion of the deposits they receive, which adds liquidity to the economy without necessarily increasing inflation. But let’s not turn this into a macroeconomics lesson!

How Bank make money :

1. Interest on Loans:

• Banks profit from interest on loans such as credit cards, personal loans, and mortgages, with rates varying by loan type.
• Example: A $5,000 loan at 9.65% interest over two years yields $566 for the bank.

2. Bank Fees:

• Banks charge various fees for services and transactions, including NSF, overdraft, ATM, late payment, minimum balance, withdrawal, and wire transfer fees.
• Customers can avoid fees via online services, account monitoring, direct deposits, and responsible spending.

The reserve requirement set by the Central Bank affects how much banks can lend. So trust in banks is crucial; we rely on them to safeguard our money. Banks lend out more money than they have but maintain customer trust.

b) Payment Instruments

Money instruments are financial tools that enable transactions and the exchange of value, including cash, checks, electronic transfers, cards, and money orders, facilitating everyday financial activities.

• Demand Drafts: Prepaid instruments issued by banks, ensuring payment to recipients.
• Cashier’s Checks: Bank-issued checks, secured by the bank’s funds.
• Money Orders: Prepaid instruments for secure transactions.
• Electronic Funds Transfer (EFT): Digital money transfer methods, including wire transfers and direct deposits.
• Banker’s Acceptance: Short-term debt instruments guaranteed by banks, often used in international trade.
• Promissory Notes: Written promises for loan repayments.
• Traveler’s Checks: Safe travel money with replacement options.
• Bearer Bonds: Unregistered bonds redeemable by whoever holds them.
• Bank Guarantees: Assurance by a bank to pay if contract terms aren’t met.
• Electronic Checks (e-Checks): Digital versions of paper checks for online payments.

c) Participants in Payment Systems

• Payers and Payees: These are the individuals or businesses initiating (payer) and receiving (payee) payments.
• Banks: Central to the payment ecosystem, banks facilitate fund transfers, issue payment instruments, and manage accounts.
• Payment Processors and Gateways: Intermediaries handling transaction authorization and routing, ensuring successful completions.
• Card Networks: Companies مانند Visa and Mastercard that connect banks and merchants, providing infrastructure and rules for card-based transactions.
• Regulatory Bodies: Central banks and other financial authorities establish guidelines to ensure safe, reliable, and efficient payment systems.

Concept 2. Payment Gateways

Payment infrastructure is the backbone of financial transactions globally, comprising systems and networks that facilitate secure and efficient money transfers.

Understanding the Role of Payment Gateways

• The Bridge Between Merchants and the Financial World: Payment gateways act as secure interfaces, connecting online businesses to the complex web of banks, card networks, and payment processors that handle financial transactions.
• Encryption and Authorization: These gateways safeguard sensitive payment information through encryption and transmit it to the relevant financial institutions for authorization and processing.
• Seamless Integration: Payment gateways can be integrated into websites and e-commerce platforms, allowing customers to conveniently and securely pay for goods and services online.

The payments industry is experiencing significant changes, with a shift from cash to cashless payments, driven by customer demand for fast and secure transactions. Regulatory initiatives like PSD II aim to promote innovation. New technologies, such as open banking, are reducing costs and increasing efficiency.

The Payment Gateway Stack

Understanding the key players involved in the payment gateway process is essential:

• Issuing Bank: The financial institution that provides credit or debit cards to consumers. They hold customer funds and approve or decline transactions based on available balances or credit.
• Issuer Processor: Partnering with issuing banks, these companies manage card authorization, settlement of funds, and other backend processes.
• Card Networks (Visa, Mastercard, etc.): These networks serve as the backbone, connecting banks and merchants, setting rules, and facilitating communication between financial institutions during transactions.
• Payment Gateway: The technology platform that encrypts and transmits card data to the acquiring bank’s processor and communicates results to the merchant.
• Acquiring Bank: The merchant’s bank, is responsible for processing the payment and depositing the funds into the merchant’s account.
• User-Facing App: The front-end interface where users interact with the merchant’s online store, initiate the transaction, and enter their payment information.

Payment System Architecture: Considerations and Types

• Security: A robust payment architecture prioritizes data encryption, multi-factor authentication, and fraud detection mechanisms to safeguard sensitive information and transactions.
• Scalability: The architecture needs to handle growing transaction volumes without performance bottlenecks to support business growth efficiently.
• Integration: Seamless integration with various e-commerce platforms, accounting systems, and additional services is essential.
• Flexible Payment Options: The architecture should support diverse payment methods like credit/debit cards, digital wallets, and potentially alternative payment options.
• Payout Time: Consider the time it takes for processed payments to reach the merchant’s account.
• Multi-Currency Support: For international businesses, support for a multitude of currencies and streamlined foreign exchange handling is crucial.

Concept 3 Fintech Worldwide landscape

a) Everything about Open Banking

Open banking API facilitates data-sharing from large banks to startups for streamlined app development through secure Application Programming Interfaces (APIs).

Example: Similar to Uber using Google Maps API for location data.

Open banking connects banks (ASPSPs) with third-party providers (TPPs) like AISPs and PISPs, transforming digital finance and consumer banking access.

• TPPs (Third-Party Providers): Authorized entities providing financial services using open banking APIs.
• AISP (Account Information Service Provider): Accesses and aggregates a customer’s financial data for insights and financial management.
• PISP (Payment Initiation Service Provider): Initiates payments directly from a customer’s bank account, facilitating online transactions.
• ASPSP (Account Servicing Payment Service Provider): Banks or institutions holding customer accounts, allowing TPPs access under open banking rules.

b) Everything about UPI (Unified Payments Interface)

UPI is a real-time payment system in India that facilitates instant fund transfers between bank accounts through mobile devices.

Why It’s Used: Provides a simple, interoperable, and secure payment infrastructure, reducing the reliance on cash transactions.

Example: Apps like PhonePe and Google Pay use UPI to enable users to make peer-to-peer payments, pay bills, and shop online seamlessly.

How does UPI Works

Step 1 Registration

Bob login into payments and provided his phone number +91 123456s78 and verified using OTP and set up VPA (Virtual Payment Address) bob@paytm

Step 2 Link bank account

Bob wants to link his SBI bank account, and The request is forwarded to NPCI. It acts as a switch between acquiring banks and issuing banks.

Step 3 — Transfer money

He will enter the UPI ID(VPA) or Scan the QR code to transfer money directly to Alice’s account.

Use cases of UPI

• Peer-to-Peer (P2P) Transfers: Transfer money to a friend or family member by entering their UPI ID or scanning their QR code.
• Merchant Payments: Pay for groceries at a local store through by scanning the merchant’s QR code or entering their UPI ID.
• Bill Payments: Settle utility bills (electricity, water, gas) by selecting the biller and entering the required details.
• Online Shopping: Make purchases on e-commerce platforms and pay with UPI during checkout.
• Mobile Recharge and DTH Payments: Recharge your mobile phone or pay for DTH services by entering the mobile number or customer ID.
• UPI for Investments: Invest in mutual funds through Apps and use UPI for seamless transactions.

Concept 4 Card Networks

The payments industry is experiencing significant changes, with a shift from cash to cashless payments, driven by customer demand for fast and secure transactions. Here are all the parties involved when a card payment happens at your nearby grocery store.

Issuers, Acquirers, and Credit Card Networks

• Issuers provide credit or debit cards to customers, Acquirers enable merchants to accept these cards, and Credit Card Networks facilitate transactions between them. They facilitate the smooth flow of funds between customers, merchants, and financial institutions during card transactions.
• For example, A customer (cardholder) uses a Visa (Credit Card Network) issued by Bank X (Issuer) to make a purchase. The merchant’s Acquirer ensures the payment is processed, and funds are transferred to the merchant.
• Acquirer Bank: Facilitates electronic payments for merchants and earns fees for their services.
• Issuer Bank: Provides credit or debit cards to consumers, approves or declines transactions, and generates revenue through interest and fees from cardholders.

Here is how a card payment at a nearby grocery store looks like

Step 1: Consumer initiates purchase by swiping card at POS or entering details online.

Step 2: Encrypted card details are sent to a payment processor.

Step 3: The payment processor directs details to the relevant credit card network (Visa, Mastercard, etc.)

Step 4: The credit card network verifies funds and authenticates the transaction with the issuing bank.

Step 5: Issuing bank approves or declines the transaction, and the response is relayed back to the merchant through the network.

Step 6: If approved, the acquiring bank processes the payment batch, crediting the merchant and debiting the cardholder’s account.

Step 7: Issuing bank bills the cardholder, and the acquiring bank pays the merchant after deducting fees, such as interchange fees.

Everything About Debit and Credit Cards

You can use a debit or credit card to Withdraw cash (use debit to avoid fees), Make online purchases (credit cards offer more protection), Send money to others and Pay bills.

• Debit Cards: You can Electronic transfer from linked accounts. Doubles as an ATM card. No borrowing; uses funds deposited.
• Credit Cards: Allows borrowing from the bank and has a Revolving account with a credit limit. This also has Minimum repayment and interest on delays.
• Forex Cards: Holds foreign currency for international travel. Single or multi-currency variants.
• Prepaid Cards: Load money in advance, not linked to a bank account. A common example: is prepaid gift cards.

• Swipe (Magnetic-Stripe): The traditional method uses the card’s magnetic stripe. Data is read by swiping through the PoS terminal. Phasing out due to security concerns.
• Dip (Chip-based): Utilizes EMV chip technology. More secure and generates unique codes for each transaction. Inserted into the terminal for processing.
• Tap (Contactless NFC): The latest method employing Near Field Communication, the Cardholder taps the card near the terminal, Enhancing speed and convenience, and gaining popularity.

Concept 5 Direct Debit Payments

A payment method where customers authorize businesses to pull funds from their bank accounts, mostly for recurring payments. Handled by Bacs (Bankers’ Automated Clearing Services) in the UK.

Steps to Set Up Direct Debit:

• Step 1 Prepare Mandate: Gather customer details including account number and sort code.
• Step 2 Get Signed Mandate: Obtain customer approval by having them sign the mandate.
• Step 3 Submit Mandate: Send the signed mandate to the bank; activation takes 4–6 days.
• Step 4 Send Payment Notice: Notify the customer 10 days prior about the payment amount and date.
• Step 5 Initiate Payment: On the due date, the business requests payment via the Bacs network.
• Step 6 Settlement: Funds take 3–5 working days to settle into the business’s account after the payment date.

Concept 6 Merchant Services Provider

Merchant services are solutions that enable businesses to accept and process electronic payments.

Key merchant services include:

• Merchant Accounts: Temporary fund-holding bank accounts.
• Payment Gateways: Software linking websites to payment processors.
• Checkout Pages: Optimized for increased conversion rates.
• Analytics: Tools for data collection informing business decisions.
• Mobile Payments: Services like Apple Pay and Google Pay.
• Virtual Terminals: Allows card-not-present transactions via phone, email, etc.
• POS Systems: Hardware and software for in-store transactions.
• Credit Card Terminals: Devices for accepting card payments in physical stores.

Concept 7 Embedded Finance

Understanding the Concept

• Seamless Integration: Embedded finance involves the seamless incorporation of financial services, such as payments, lending, or insurance, directly into the digital experiences of non-financial companies and platforms.
• Frictionless User Experience: The goal is to provide customers with convenient access to financial products and services within the context of their everyday interactions, removing unnecessary steps and making financial tasks more intuitive.
• Enabled by Technology: Embedded finance is made possible by modern APIs (Application Programming Interfaces) and fintech infrastructure that allow for seamless connections between diverse platforms.

The Role of Payment Gateways in Embedded Finance

• The Foundation of Embedded Payments: Payment gateways form a crucial part of the embedded finance landscape, particularly in scenarios involving embedded payments. They facilitate the secure and efficient processing of card-based and other digital transactions within non-financial environments.
• Behind the Scenes: While users experience a seamless payment flow within their favorite app or platform, behind the scenes, payment gateways handle the complexities of authorization, encryption, and communication with financial institutions.

Popular Types of Embedded Finance

Embedded Payments:

• Facilitating payments directly within e-commerce platforms, ride-hailing apps, or even social media experiences.
• Offering flexibility with diverse payment methods (cards, digital wallets, bank transfers, etc.).

Embedded Insurance:

• Integrating tailored insurance products into relevant customer journeys. For example, offering travel insurance when booking a trip, or device protection when purchasing electronics.

Embedded Financing (Also known as Embedded Lending):

• Providing point-of-sale financing options (installment plans, “Buy Now, Pay Later”), credit cards, or other forms of lending directly within online shopping experiences.

Benefits of Embedded Finance

• Improved Customer Experience: Frictionless access to financial services enhances overall user experience.
• New Revenue Streams: Non-financial firms can unlock additional revenue by offering financial products.
• Increased Customer Engagement: Embedded finance solutions can drive customer loyalty and brand affinity.
• Innovation and Competition: Embedded finance fosters a more dynamic and competitive financial services landscape.

Concept 8 Fraud, Disputes, and Chargebacks

A chargeback is a reversal by a credit cardholder due to unauthorized transactions, misrepresentation, or fraud. The credit card issuer investigates and refunds money to the cardholder, charging it back to the merchant.

If a merchant receives a chargeback dispute, they should:

• Review the reason for the dispute
• Gather evidence like receipts and proof of delivery
• Submit evidence and explain why the reversal is invalid
• Consider mediation if the evidence is strong
• Resubmit the charge if the dispute continues

The credit card issuer or acquiring bank decides chargeback disputes based on evidence and card network rules.

Chargebacks can be costly for merchants through fees and processing costs. If a merchant wins a dispute, the chargeback is cancelled but they may still need to take steps to get paid by the customer.

Concept 9 Payment Service Providers (PSP) and Account Information Service Providers (AISP)

AISP (Account Information Service Provider) aggregates consumer banking data for financial management, while PISP (Payment Initiation Service Provider) initiates direct online bank-to-merchant payments, simplifying transactions.

Data Brought By API

• Banks have accumulated data about user transactions and expenses, which can be valuable for startups.
• API-sharing allows startups to use this data safely to create new products with user consent.
• Using this data companies can see the Location of banking branches, Details of certain banking products, Transaction data, Mortgage payments, Electricity bills, and Travel expenses and build better financial products.

AISP (Account Information Service Provider)

An AISP is an entity authorized under open banking regulations, such as PSD2 in Europe, to access a customer’s financial data from banks and financial institutions, with the customer’s consent.

Use in Insurance:

• Risk Assessment: Enhances underwriting by analyzing clients’ financial data.
• Customization: Offers personalized insurance products based on spending habits.
• Efficiency: Streamlines claims processing and fraud detection using real-time data.
• Personal Finance: Apps offer consolidated financial views and budgeting advice.
• Credit Scoring: Lenders assess creditworthiness for personalized loan offers.
• Wealth Management: Investment platforms provide tailored advice using financial data.
• E-commerce: Platforms personalize shopping experiences based on purchase history.
• Bill Management: Apps track and manage subscriptions and recurring payments.
• Debt Management: Services offer consolidation plans using account information.

PISP (Payment Initiation Service Provider)

Payment Service Providers (PSPs) are financial institutions that facilitate money transactions between merchants and customers, acting as intermediaries in the payment process.

PSPs integrate various payment methods (like credit/debit cards, e-wallets, direct bank transfers) and handle technical and regulatory aspects of payment processing, including security and anti-money laundering measures.

• Facilitate direct online payments from bank accounts.
• Benefits: Streamlined transactions, and lower costs.
• Examples: PayPal, Stripe.

Concept 10 Neobanks

Neobanks are digital-only banks without physical branches, offering online account services, virtual cards, instant payments, and budgeting tools.

Types and Benefits: Online Account Opening, Virtual Cards: Convenience and accessibility for users.

Real World Example: Chime

Use Case: Redefining traditional banking by offering mobile-based banking services, including no-fee checking accounts, early direct deposit, and budgeting tools.

How Do Neobanks Make Money?

• Interchange-led Model (e.g., Chime): Revenue from interchange fees when customers use Neobank’s card.
• Credit-led Model (e.g., Nubank): Focus on credit services, starting with credit cards and expanding to banking accounts.
• Ecosystem-led Model (e.g., Monzo): Checking accounts may not be the primary profit driver but enable various monetization strategies, including subscriptions.
• Asset-led Model (e.g., Aspiration): Emphasis on saving accounts, attracting deposits with competitive rates. Some prioritize ethical or moral spending management.
• Product Extensions Model (e.g., Robinhood): Successful credit-led models extending into diverse product offerings. Often involves partnerships with prominent tech companies and traditional banks.

For a deeper dive, I recommend taking the course.

Fintech Product Management: Become a Fintech PM.

P.S. It costs less than a burger and offers incredible value if you’re aiming to break into fintech!

Concept 11 Know Your Customer (KYC)/ Know Your Business (KYB)

KYC is the Verification process to identify and verify the identity of individual customers while KYB is tailored for business entities.

Why we need KYB:

• To reduce the risk of doing business with entities involved in financial crimes
• To avoid penalties and reputation damage from non-compliance databases

What KYB offers:

• AML Screening — Global screening 1000+ watchlists, Politically Exposed Persons (PEPs), sanctions lists, etc.
• Sanctions Screening — Global sanctions by various regulatory bodies.
• Adverse Media Checks — Monitoring for negative news and red flags.
• UBO KYC — Detailed KYC verification of Ultimate Beneficial Owners.
• Document Verification — OCR of official documents like GST, certificates, and licenses.
• Central Database Checks — Validation against government databases like MCA, and CERSAI.

How to perform KYB?

Concept 12 Anti-Money Laundering (AML)

Money Laundering is the process of hiding the origins of money obtained illegally (drug trade, human trafficking, etc) by transferring it to make it appear legitimate.

AML is a way to screen customers against watchlists and monitor transactions to detect money laundering activities.

Why is AML Compliance Important?

• Prevents fraud and financial crimes
• Avoids heavy non-compliance fines
• Maintains reputation and customer trust

Key Aspects of an AML Compliance Program:

• Policies for customer screening
• Dedicated compliance team and AML officer
• Employee AML training
• Customer background checks and transaction monitoring

Benefits of Robust AML Compliance:

• Reduces business risk exposure
• Increases efficiency via automation
• Enhances customer onboarding experience
• Ensures regulatory obligations are met

Concept 13 Fraud Prevention and Detection

Fraud detection involves identifying illegal activities like identity theft, phishing scams, or unauthorized transactions.

How Fraudsters Operate:

• Fraudsters, often organized groups, employ various tactics like identity theft, phishing, and financial scams.
• The rise of phishing, credit card fraud, identity theft, and money laundering requires advanced detection methods.

Banking and Fintech Use Cases:

• Credit Card Fraud Detection: AI analyzes transactions for anomalies like sudden increases or atypical expenses.
• Identity Theft Detection: AI prevents identity theft by spotting suspicious transactions or behaviors.
• Loan and Mortgage Fraud Detection: AI evaluates applications using NLP to identify potential fraud patterns.
• Money Laundering Activity Detection: Deep learning models uncover hidden correlations in account activity.

Concept 14 PSD2 (Payment Services Directive 2)

EU legislation updating payment services for the digital age. Introduced to enhance consumer protection, promote innovation, and improve security in digital payments.

• Consumer Protection: Enhances security and privacy in payment services.
• Faster Payments: Streamlines processes for quicker transactions.
• Market Competition: Boosts competition among payment providers.
• Open Banking Support: Enables innovative financial services through secure data access.
• Fraud Prevention: Strengthens authentication to reduce fraud risks.

Impact on Open Banking: Enabled third-party access to bank data (with customer consent), fostering competition and innovation in financial services.

Concept 15 Strong Customer Authentication(SCA)

Strong Customer Authentication (SCA) is a European requirement enhancing payment security by necessitating two-factor authentication; it affects online and in-store transactions in the EEA.

1. Payment Initiation:

The process starts with the customer initiating a payment, either online or in person.

2. Authentication and Authorization:

The customer’s identity is verified using two-factor authentication, fulfilling the SCA requirements.

3. Payment Execution:

Upon successful authentication, the payment is processed and completed through the payment service provider.

Concept 16 Advanced Payment Technologies

In this part, we will understand NFC, Defi, and some other advanced payment technologies that will reshape the future of Fintech.

a) Near Field Communication (NFC) is a wireless technology that enables communication between electronic devices when they are nearby, typically within 4 cm or less.

Initiation: Devices with NFC (e.g., smartphones, payment terminals) connect when close.

• Modes:
• Peer-to-peer: Active NFC devices exchange information.
• Reader/writer: Active devices read/write from/to passive devices (e.g., smart cards).
• Card emulation: NFC acts as a contactless card for digital payments.

Transaction: A payer’s device (smartphone or smartwatch) communicates with a payment terminal via NFC. Encrypted data exchange completes transactions swiftly.

b)Mobile Wallets: Apple Pay, Google Pay, Samsung Pay, etc., allow users to make NFC payments using their smartphones.

E-wallet transactions have seen significant growth. Understanding how e-wallet payment processing works for both P2P and P2M transactions is crucial.

• P2P: Direct transaction between users with the e-wallet acting as the intermediary. Instant settlement with no redirection.
• P2M: Involves an intermediary (payment processor) between customer and merchant.

c)Contactless Cards: Debit or credit cards with a contactless symbol enable tap-and-go payments.

d)Wearable Devices: Smartwatches and other wearables equipped with NFC technology can be used for payments.

Concept 17 Decentralized Finance (DeFi)

DeFi is a monetary system built on public blockchains, utilizing protocols, digital assets, dApps, and smart contracts. It aims to provide an alternative to traditional financial systems, emphasizing global accessibility, safe transactions, and lower costs.

Traditional Finance vs. DeFi:

• Operational Structure: Traditional Finance is managed by institutions, whereas DeFi operations are handled by algorithms and smart contracts.
• Transparency: Traditional Finance relies on intermediaries for transparency, while DeFi offers code transparency and pseudonymous transactions to enhance trust.
• Global Accessibility: Traditional Finance is limited to localities, in contrast, DeFi provides global access to networks and services.

Concept 18 SWIFT

SWIFT (Society for Worldwide Interbank Financial Telecommunication) is a messaging network used by banks and financial institutions globally to securely communicate and facilitate cross-border transactions.

How SWIFT Works:

• Step 1 Each member bank gets a unique 8-digit SWIFT code identifying it
• Step 2 To send money abroad, sending bank initiates a SWIFT message to the receiving bank
• Step 3 Message contains key transaction details — beneficiary account, amount, etc.
• Step 4 The receiving bank approves the message once the details are verified
• Step 5 Funds can then be credited to the required account SWIFT itself does not hold any funds, only facilitates communication

Concept 19 Automated Clearing House (ACH) Transactions

ACH stands for Automated Clearing House — a network that facilitates electronic transfer of money. It allows businesses to surely transfer larger payments at a lower cost directly from bank accounts.

• Step 1 Setup — The business gets authorization from the customer to pull money from their bank account.
• Step 2 Initiation — The business sends transaction details like account numbers, amount, etc. to its bank (Originating Depository Financial Institution — ODFI).
• Step 3 Batching — ODFI groups transactions and sends them to the ACH operator.
• Step 4 Distribution — The ACH operator routes transactions to the customer’s bank (Receiving Depository Financial Institution — RDFI).
• Step 5 Completion — RDFI pulls money from the customer’s account and completes the transfer.

Concept 20 Peer-to-Peer (P2P) Lending

Lending and Borrowing Platforms are digital ecosystems that connect individuals or businesses in need of funds with potential lenders. These platforms eliminate traditional intermediaries, facilitating direct transactions between borrowers and lenders.

1. Peer-to-peer (P2P) Lending: Individuals lend money directly to others, bypassing banks.

2. Institutional Lending: Businesses or individuals access loans from institutional or alternative lenders.

Benefits:

• Streamlined Processes: Quick approval and disbursement via automation.
• Competitive Rates: Cost-effective loan options compared to traditional banking.

Concept 21 Insurance Technology (Insurtech)

InsurTech, a fusion of insurance and technology, encompasses innovative technologies transforming the insurance sector.

Most people who pay for the insurance don’t suffer a loss. Therefore the money these people will pay covers the losses of the people who suffer a loss. Anything left over is profit from the insurance company.

• P2P Insurance: Friendsurance, Lemonade, and InsPeer leverage communities to pool premiums.
• On-Demand Insurance: Activated during asset use, meeting real-time consumer needs.
• Microinsurance: Swift underwriting for smaller risks, e.g., travel or event coverage.
• Gig Economy Insurance: Tailored coverage for freelance opportunities like Uber and Airbnb.
• Comparison Portals: Check24 and PolicyGenius enable product comparisons across various companies.
• Digital Insurers: Sherpa and similar companies handle end-to-end insurance processes.
• Open Insurance: Lemonade’s API fosters collaboration, creating a connected data ecosystem.

For a deeper dive, I recommend taking the course.

Fintech Product Management: Become a Fintech PM.

P.S. It costs less than a burger and offers incredible value if you’re aiming to break into fintech!

Recommend that you read these related articles:

• Want to Be a Fintech PM? Master These 20+ Must-Know Concepts (Part 1)
• 100+ Product Metrics: The Ultimate Guide for Product Managers
• 31 Startup business models you must know (with examples)

Why do you need product Metrics in the first place?

Imagine you are on a cross-country road trip and the car you are driving does not have a dashboard! Without a dashboard, you are completely blind to how your car is doing.

It’s difficult for you to know about the speed of the car, Gas Level, and other warnings if something goes wrong.

Peter Drucker once said “You can’t improve what you don’t measure”

So product metrics are a critical tool for product managers that provide insights into how users are interacting with a product, which can help product managers make informed decisions about how to improve the product.

Well now that you understand the importance of measuring your product metrics. Let’s understand the user journey before you actually spend some time understanding product metrics.

To illustrate the user journey, let’s consider a person using Canva, a popular design tool. (I prefer Figma, but that’s a topic for another day.)

The best way to understand Product Metrics is by using the AARRR (Acquisition, Activation, Retention, Revenue, Referral) framework.

User Journey of an online tool like CANVA

If you have used CANVA or any online tool a typical customer journey would look something like this.

1. Acquisition:

• Type “CANVA” or a related keyword like “Design online” on Google.
• Click on a search result to go to the Canva website.
• Sign up for a free account.

2. Activation/Engagement:

• Search for a design template.
• Customize the template to create a new design.
• Download the design.

3. Retention:

• Use Canva regularly to create new designs.
• Share your designs with others.

4. Revenue:

• Upgrade to a premium plan to unlock more features.

5. Referrals:

• Invite your friends and colleagues to use Canva.

Let’s break this down step by step and see which product metrics you need to track.

Step 1 Acquisition Metrics

There are two main ways users get to Canva: they can either type the URL directly into their browser or search for a design tool on Google.

Let’s take the example of a user who lands on the Canva website by searching for it on Google. If you closely observe the URL, you will see that it contains a UTM (Urchin Tracking Module) code. This code can be used to track the source of traffic, the campaign, and other important metrics.

A few important metrics your track here is your

1.Cost per click (CPC)
Cost per click (CPC) is the amount of money you pay when someone clicks on your Google ad. The CPC can vary depending on the niche and geography of your target audience.

2. Customer Acquisition Cost (CAC)
Customer Acquisition Cost (CAC) is the average amount of money you spend to acquire a new customer. In your example, if you spent \$10,000 on Google CPC ads and acquired 1,000 new customers, your CAC would be \$10.

3. Top and the bottom of the funnel

The top of the funnel (TOF) refers to the stage in the customer journey where users are first exposed to your product or service.

The bottom of the funnel (BOFu) refers to the stage where users are ready to make a purchase. The percentage of users who move from the TOF to the BOFu is known as the conversion rate.

4. Bounce Rate

Bounce rate is the percentage of visitors who leave your website after viewing only one page. A high bounce rate can be a sign that your landing page is not effective or that your targeting is off. You can improve your bounce rate by optimizing your landing page and targeting your ads more effectively.

5. Channel Effectiveness

Channel effectiveness is a measure of how well different marketing channels are performing in terms of driving traffic, sign-ups, or purchases. You can measure channel effectiveness by tracking the number of visitors, sign-ups, or purchases that each channel generates.

6. Traffic Source Distribution

The traffic source distribution is a measure of how your website traffic is distributed by different sources. You can track traffic source distribution by looking at the referring domains, search engines, or social media platforms that send traffic to your website.

I could write an individual article on these metrics, but that’s not the focus of this guide. Let’s move on to step 2.

Step 2. Activation/Engagement Metrics

After signing up for Canva, users can either start from scratch with a blank canvas or search for an existing template to customize.

When you use Canva, you’re using a collection of features that have been designed to solve your user pain points and give you the flexibility to create a wonderful design.

Whether you’re searching for a template, changing the color, or adding an animation, each of these features is designed to make your life easier.

The product team at Canva is constantly tracking, optimizing, and improving these features based on user feedback. They have a deep understanding of user pain points, and they use this understanding to create features that make a real difference.

This is what we call “user empathy.” It’s the ability to understand and address the needs of our users in a way that is both thoughtful and effective.

This is the list of metrics that a PM at CANVA might be Tracking

1. DAU/MAU: These metrics show how many users are active on your app on a daily, weekly, and monthly basis. They are a good measure of the overall health of your product and can help you track your growth over time.
2. Session length: Session length is typically measured in minutes or seconds. It can be calculated by dividing the total time spent by users on your product by the number of sessions.
3. Time to value (TTV): TTV is typically measured in days, weeks, or months. It can be calculated by dividing the time it takes for a user to experience the core benefits of your product by the number of users who have experienced those benefits.
   In fintech, the core benefit is payment, while in design tools, it’s design output. A shorter time to value (TTV) leads to higher user satisfaction, engagement, and retention.
4. User Activation Rate : The percentage of users who successfully complete a certain milestone in your onboarding process. For a design tool like canva activation happens when you finally download the design after picking a template and editing it.
5. Product Stickness — This shows how sticky is your product and are people really using it regularly. It is usually calculated by this formula (DAU/MAU*100)

For example — If 100k people have used your app in one month and 20% are using it every day. Then your sickness is 20% (20k/100k*100). Sickness is usually higher for social media apps and lower for software products.

5. Feature usage — This shows the usage of a specific feature or functionality in the product
- How many designs were downloaded every day?
- How many templated were browsed by a user?
- How much search feature is used by people?

6. Funnels and Drop-off rates — This usually Shows how much it takes for a user to do an action and what’s the drop-foof rate
- The average time taken by a user from Editing a design to downloading it?
- Time taken from signup to downloading a design

and many others……there are countless KPIs and Metrics you can track for a product. Now let’s look at step 3 which usually determines the growth of a product.

If you want to Deep-Dive into all the metrics, KPIs, and Concepts then I recommend you to watch my course on Product Management: Product Analytics for Decision Making

Step 3. Retention Metrics

There is a famous saying that

If people are using your product over time they will eventually pay for it.

This may or may not be true depending on the industry and geography but usage and retention are probably the most important factors that drive the success of the product. For retention, you majorly need to understand about retention cohort.

Retention Cohort — A retention cohort reflects the business's health and it will help you understand the percentage of users retained on your app.

The above screenshot is a retention cohort of App users over 10 days. So if 1098 people have used your app on Jan 25, 12% of users will come back on Day 10.

You can also create a retention cohort on a Weekly, or monthly basis for metrics like the design downloaded. For example:- If 200 people downloaded the design on Jan 25, how many of them came back and download the design on Day 10?

Here is the list of metrics that a PM at CANVA might be measuring

1. Dollar Retention — This shows how much your business revenue has grown or shrunk within a particular period from the same set of users. For example:- If your company was making $100k per year (ARR) from 10k users and got reduced to $80k/per year from the same users then your dollar retention is down by 20%.
2. Usage Retention — It shows how much a specific feature is used by the customer over time.
   For example — If 100 people have used the search feature on Jan 25, how many of them are using it after Day 10
3. Churn Rate — Churn means how many people have stopped paying for your product. High churn often means that the product is not good enough for the price point. One can calculate it on a monthly or yearly basis.

So the main goal here is to ensure more and more people use your product and how will you be would be able to retain them over time.

Step 4. Revenue Metrics

Now that people have started using your product you have to figure out ways by which you can make money from your product.

In the case of CANVA if you want to use Premium Assets (SVG, PNG) or a Premium template then you have to take their paid plan. CANVA is a great example of the Freemium business Model.

Want to learn more about the different business models and pricing strategies that startups can use? Check out my deep dive article on 31 Startup Business Models and Pricing Strategies.

1. Trial-to-Paid Conversion Rate

The percentage of trial users who convert into paying customers.

For example — So if 1k people signed for Free-trial and only 50 of them took your paid plan you have a Trail-to-paid conversion rate of 5%.

2. Paying user percentage —

So if 100k customers are using CANVA and only 10k are paying then paying user percentage is 10% (100k/10k).

The benchmark for this metric varies a lot based on industry, business model, and pricing strategy. A design tool like CANVA would have a paying user percentage of 5% while a tool like Google Drive may have a lower paying user percentage of 1%.

But overall it is quite useful when you are iterating the product and making changes to the business model.

3. No. of paid subscribers —

If you are building a Freemium tool like Canva or an app like Spotify then you would see how your paid subscriber is growing over time. You can create a line chart using Excel or create a board using Mixpanel, Amplitude, or PowerBI.

4. Time to the first transaction —

Once the user has signed up on your app or software how much time does it take to make their first purchase?

In the case of a fintech or a food delivery app the product value realization is quite fast (Sometimes under 1 minute) but it may take up to a month for a software product. So look out for industry and category benchmarks before you make up your mind.

5. Average order value —

As the name suggests AOV shows the average value of an order. This is a widely used metric in e-commerce and food delivery. To lift these metrics companies often use product bundling and discounting.

For example — Buy 1 Get 1, Add 1 more unit and get a 15% discount, Buy for X Amount and you would get a 20% discount. All of these hacks are used to increase the AOV across various categories

6. Average revenue per user (ARPU) —

This shows the average amount of revenue you are generating per user. To calculate this you need to divide your total revenue by a total number of users.

ARPU = Total Revenue/ Total users

To increase ARPU companies usually tries to sell multiple products to their customers to increase their prices altogether.

If your product is used by people internationally then you can also break down your ARPU by country wise as countries may have different purchasing power.

7. Customer Lifetime Value(CLTV) —

CLTV is the total net profit a company can expect to generate from a customer throughout their entire relationship.

CLTV helps you understand how much to spend while acquiring a customer. If you are spending $1000 to acquire one customer and sell them a $20 monthly plan then it will take 50 months for your company to break even.

Thumb rule — The LTV/CAC ratio should be 3:1, which means you should make 3x what you would spend on acquiring a customer.

8. Revenue by Category/Segment/Vertical —

It is widely used by companies who are managing multiple products or categories, hence they need to know how well are they doing product or category-wise.

For example — A company like Amazon may track its Category wise Revenue, profit, and market share.

Similar Amazon may also be tracking its product-wise revenue to understand how well its cloud computing and e-commerce verticals are doing

9. Gross Margin —

Gross Margin is the portion of a company’s revenue left over after direct costs are subtracted. In short, It’s the portion of business revenue left over after you subtract direct costs, such as labor and raw materials

I am sure you would have heard terms like Top-line and Bottom line. The loosely held term Top-line means Revenue/Sales and the bottom line usually means EBITA or Profits.

10. Profit Margin —

Profit margin is the portion of a company’s sales revenue that it gets to keep as a profit, after subtracting all of its costs.

As you can see in the above diagram the revenue from sales was around $330,000 but the profit after tax is just $19,250.

So the main goal here is to ensure your product is making money and you are making money for your investors.

Step 4. Referral Metrics

If you use any tool or mobile app you would have seen a tab like “Refer and Earn” that asks you to invite your friend so that you can earn money. This is considered the cheapest source of customer acquisition and has worked really well for some early stages for Uber, Amazon, etc.

Now the alternative to this approach is collaboration, which is the powerhouse of CANVA. You can share your design and add as many team members as you want. The more people you invite the better it is for CANVA.

Here is the list of metrics that a PM at CANVA might be measuring

1. Virality Coefficient

The viral coefficient is a metric that determines the number of new users generated by referrals from existing customers.

Virality is the inherent incentive for customers to refer friends to a new app or software they like and earn some reward if their friends use the product.

The number of new users acquired through referrals by existing users. Often expressed as a ratio (<1, 1, >1).

2. Customer Referral Rate — The percentage of customers who refer others to the product.

3. Referral Conversion Rate — The percentage of referrals that convert into active users.

4. Net Promoter Score (NPS) — A measure of customer satisfaction and loyalty based on how likely users are to recommend the product to others.

Warning: NPS measures customer attitude and sentiment, not the actual behavior.

Average Referral rewards won (Canva doesn’t have it anymore)

1. Average user Invited in one Account
2. Paid user with Invitation code

and many others……Now let’s look at the 4th step which usually determines the long-term success of the company.

You can read more about 100+ Product Metrics given in the sheet, but let’s also understand Product analytics tools to measure these metrics.

Tools you use to measure product metrics

When it comes to analyzing data and looking into product metrics, oftentimes the data is quite scattered when it comes to measuring these metrics so companies use CDP tools like Segment to store all these data in a single warehouse so that people can analyze it.

Here is the list of tools companies use across the product journey to measure product metrics.

These tools will help you understand the different types of active Users based on how much they engage with your product.

• Power User — The cohort of active users with the Highest Engagement
• Core User — The cohort of active users with the Medium engagement
• Casual User — The cohort of active users with the lowest engagement

These tools will also help you understand the Frequency Breadth and Depth of the Engagement.

Which metrics to prioritize and which ones to ignore

There are constellations of metrics. So not every metric can be used at the same time.

So let’s understand which to prioritize and how to figure out your business goals and your product value.

So here is the framework you can use to avoid tracking vanity metrics.

• North Star — This reflects the prime value you give to users
• Primary/Level 1 Metric — Complement the north star/focus metric
• Supporting/ Level 2 Metric — Shows that the product is growing in a healthy direction (Leading indicators to your north star and L2 metrics.)

North Star Metric is the most important metric for the long-term success of your product. NSM lies in this simple statement, “If a company brings top value to its customers, then growth and success are inevitable”.

Let’s Understand North — Star and L1, L2 with some example

To break this down further let’s pick Uber Eats.

Sector Specific Product Metrics

Here are the Most important product metrics for e-commerce

If you want to Deep-Dive into all the metrics, KPIs, and Concepts then I recommend you to watch my course on MBA in Product Management: Become a Product Manager

Some FREE Courses on Product Management

1. Technology for Product Managers: Guide for Aspiring Tech PM
2. Product Management Fundamentals: A Beginner’s Guide