Digital Banking and FinTech

01Purpose and scope

• This manual supports the course Digital Banking and FinTech. It describes how product, operations, risk, and technology teams actually build, launch, and run customer-facing financial services delivered through apps, websites, APIs, and partner platforms.
• The scope covers retail and small business accounts, payments, lending products that are originated digitally, digital onboarding, and the use of third-party providers such as cloud hosts, card processors, identity verification vendors, and banking-as-a-service partners. It does not cover trading platforms, crypto asset custody, or insurance underwriting in depth, which follow separate rulebooks.
• Practice varies a great deal by setting. A chartered bank with a legacy core system works differently from a non-bank fintech that relies on a sponsor bank to hold customer deposits. Both must answer the same basic questions about who holds the money, who answers to the customer, and who is accountable when something fails.

02Core principles

• Customer funds and customer data are treated as the primary assets. Every design decision should be traceable to how money moves, who can see information, and what happens if a message is lost, duplicated, or delayed.
• Ledger accuracy comes before feature speed. A payment app is only useful if the balance shown to a customer matches the books of the institution that holds the funds. Reconciliation is part of the product, not a back-office afterthought.
• Controls are layered rather than relied on individually. Authentication, transaction limits, anomaly detection, velocity rules, and manual review each catch different failures. No single control should be assumed sufficient.
• Third parties extend accountability but do not transfer it. If a partner processes a payment or verifies an identity on your behalf, your organization still owns the outcome in the eyes of regulators and customers, so contracts and monitoring must reflect that.
• Design for the failure case. Settlement cycles, payment network outages, and vendor downtime are normal events. The customer experience during those events matters as much as the happy path.

03Planning and preparation

• Start by defining the product and the regulatory position it relies on. Identify whether the organization is the licensed or chartered entity, whether it operates under a sponsor or partner bank, and which money transmission or lending licenses apply. These answers depend on jurisdiction and change over time, so confirm them with counsel and the current authoritative source for the relevant regulator before any design work is locked.
• Map the money flows and data flows on a single diagram. Show each system, each external provider, each settlement account, and each point where personal data is collected or stored. This map becomes the basis for risk assessment, vendor reviews, and audit evidence.
• Set the decision rights early. Product owns customer outcomes, risk owns the risk appetite and sign-off on controls, compliance owns the regulatory interpretation, and technology owns system design and availability. Disputes between these groups are cheaper to settle before build starts.
• Prepare a launch scope document that lists supported transaction types, currencies, customer segments, geographic limits, daily and per-transaction limits, and the operating hours of any payment rail. Vague launch scopes cause the most expensive rework later.
• Confirm that the core infrastructure can produce the data needed for daily reconciliation, regulatory reporting, and fraud investigation. Retrofitting event logging after launch is slow and often incomplete.

04Recommended workflow

1. 1
   : Define the customer problem and the regulated activity in one page. Name the product, the customer type, the money movement involved, and the partners required. Obtain risk and compliance sign-off on this page before engineering starts detailed design.
2. 2
   : Draft the end-to-end journey for the most common path and the three most likely failure paths. Include onboarding, funding, a payment or transfer, a reversal, and account closure. Note which screens depend on which backend calls.
3. 3
   : Select and contract providers. For identity verification, card issuing, payment rails, and cloud hosting, compare at least two options where feasible, check the provider's security attestations and incident history, and confirm data residency and sub-outsourcing terms. Record the reasons for the choice.
4. 4
   : Build the ledger and payment logic with idempotent operations, so that a retried request does not create a second transfer. Use a double-entry ledger or a well-tested equivalent, and keep the ledger as the source of truth for balances.
5. 5
   : Integrate the customer interface with the ledger and partner APIs. Display pending, posted, and failed states distinctly. Customers frequently misread pending transactions as completed, which drives support volume and disputes.
6. 6
   : Run controlled testing with internal staff, then with a limited external group under caps. Test reconciliation between the internal ledger and the partner statement file, not only the screens. Measure exception counts and resolution time.
7. 7
   : Launch in stages with defined rollback criteria. Expand customer segments or limits only after the exception rate and fraud loss rate are within the thresholds agreed in the planning phase, and keep an on-call owner for each partner integration.

05Quality checks, risk controls and compliance

• Reconciliation is the most important recurring check. Compare the internal ledger, the settlement account balance, and the partner or network files every business day. Investigate every unexplained difference, record the root cause, and track aging of open items. Reconciliation breaks that remain open for many days usually signal a control gap.
• Fraud and financial crime controls include customer identity verification, sanctions screening, transaction monitoring, and suspicious activity reporting where the law requires it. In the United States these obligations stem from the Bank Secrecy Act and related anti-money laundering rules, while the European Union applies its own directives and regulations. Confirm which rules apply to your entity and product with compliance staff and the current guidance from the relevant regulator.
• Strong customer authentication and session security are required for many payment flows in the European Union under PSD2 and its technical standards. Other jurisdictions use different approaches. Where card data is handled, the Payment Card Industry Data Security Standard applies to the environment that stores, processes, or transmits card data, and the scope of that environment should be minimized through tokenization.
• Data protection rules vary. Personal data handling must follow applicable privacy laws, which may include the General Data Protection Regulation in Europe or state privacy statutes in the United States. Keep a record of processing activities, limit access by role, and set retention periods that match legal requirements.
• Operational resilience and incident response need written plans. Define severity levels, customer communication templates, regulator notification timelines where applicable, and a process for pausing a product feature without taking the whole platform offline.
• This guidance does not replace qualified professional judgment, approved internal procedures, or required regulatory authorization. Regulated activities such as holding deposits, extending credit, or moving money generally require a license or a documented sponsor arrangement before launch.

06Collaboration and documentation

• Maintain a single product record that links the business rationale, risk assessment, control list, vendor contracts, test evidence, and approval history. Auditors and examiners ask for this kind of traceability, and internal teams rely on it when an incident occurs months after launch.
• Run a weekly cross-functional review during build and a monthly review after launch. Include product, engineering, operations, risk, compliance, customer support, and the partner management lead. Keep decisions and open actions in a shared tracker with named owners and due dates.
• Write runbooks for common operations tasks such as reversing a payment, freezing an account, handling a chargeback, or replaying a failed webhook. Runbooks should be tested by someone who did not write them, since gaps appear quickly under that test.
• Vendor management needs its own rhythm. Review partner service reports, uptime, complaint volumes, and security incidents at least quarterly, and confirm that audit rights and incident notification clauses in contracts are being exercised when needed.
• Customer-facing language requires review by compliance and legal. Disclosures about fees, timing, deposit insurance where it applies, and dispute rights should be accurate in every channel, including help articles and marketing pages.

07Measures and continuous improvement

• Track a short set of indicators tied to outcomes. Useful measures include successful transaction rate, median time to settle, reconciliation break count and age, fraud loss as a percentage of payment volume, false positive rate for fraud alerts, onboarding completion rate, and support contacts per thousand active customers. Set targets only after a baseline is established from real data.
• Separate leading indicators from lagging ones. Authentication failure spikes or rising manual review queues often appear before fraud losses do, so they deserve an alert threshold of their own.
• Review each incident and near miss in a blameless format. Record what the control was meant to do, what actually happened, and which change would have prevented or detected the issue sooner. Close the loop by checking that the change was made and that it worked.
• Revisit risk limits and product scope on a fixed cycle. Limits set for launch are usually too generous or too tight once real customer behavior is visible, and adjustments should be documented with the reason for the change.
• Trade-offs are constant. Tighter fraud rules reduce losses but block legitimate customers, raising abandonment and support costs. Faster onboarding lowers friction but may admit higher-risk accounts. Record these trade-offs explicitly so future decisions start from known positions.

08Common mistakes and how to prevent them

• Treating the app balance as the ledger. Customer-facing balances often combine posted and pending amounts in ways that differ from the books. Define one authoritative balance calculation, document it, and test it against reconciliation output.
• Assuming a partner's compliance covers your obligations. A sponsor bank or processor may run its own program controls, but your product still needs its own risk assessment, monitoring, and customer complaint handling. Confirm in writing which party does what.
• Launching without a tested reversal and dispute process. Refunds, chargebacks, and failed payments generate most of the early operational load. Test them with realistic volumes before opening the product widely.
• Storing more personal data than the product needs. Collecting full identity documents or card numbers in systems that do not require them expands breach impact and audit scope. Use tokens and third-party vaults where possible.
• Underestimating vendor concentration. Relying on one identity provider, one card processor, or one cloud region creates a single point of failure. Where the cost is justified, plan a secondary path and test the failover.
• Letting pending states confuse customers. Show clear labels for pending, posted, and returned items, and explain expected timing in plain language at the point of action.

09Practical checklist

• Confirm the licensing or sponsor arrangement and the jurisdictions in scope with counsel before design lock.
• Document the money flow and data flow map and keep it current after every provider change.
• Assign named owners for product, risk, compliance, technology, and each partner relationship.
• Build a ledger with idempotent posting and confirm it is the source of truth for balances.
• Run daily reconciliation against partner and settlement files and track aging of every open break.
• Apply authentication, transaction limits, and monitoring that match the risk of each product flow.
• Verify that card data scope is minimized and that tokenization is used where applicable.
• Test reversals, disputes, and failed payment handling with realistic volumes before launch.
• Review vendor performance, security incidents, and contract rights at least quarterly.
• Hold blameless incident reviews and confirm that corrective actions were completed and effective.

★Learning sources

• Micro Degree: Digital Banking and FinTech
• Micro Degree: Accounts Payable Management
• Micro Degree: Bank Reconciliation Operations
• Micro Degree: FinTech Fundamentals