FinTech Fundamentals

01Purpose and scope

• This manual supports the course FinTech Fundamentals. It describes how financial technology work is actually done in banks, lenders, payment processors, wealth platforms, and the vendors that serve them, and it is written as a reference for analysts, product staff, operations leads, and people moving into the field from finance, software, or compliance roles.
• Fintech covers a wide range of activity: digital account opening, payments and settlement, lending decisions, account data aggregation, fraud detection, automated investment advice, and the application programming interfaces that connect these pieces. This manual stays at the level of working practice. It explains the decisions a practitioner makes, the records those decisions produce, and the places where a team commonly goes wrong. It does not teach software engineering, actuarial modeling, or trading strategy.
• The limits matter. Rules for lending, payments, stored value, consumer data, and money transmission vary by country, by state or province, and sometimes by product type. Treat this manual as a description of common practice rather than a statement of what the law requires where you operate. For current requirements, consult the regulator or statute that applies to your activity and your legal or compliance function. This guidance does not replace qualified professional judgment, approved procedures, or required authorization.

02Core principles

• Start from the customer task and the money flow. Most fintech failures trace back to a mismatch between what a product promised and how funds or data actually moved. A practitioner should be able to draw the path of one transaction from initiation to final settlement, naming each party, each ledger, and each point where a status can change.
• Treat every financial record as a claim that must reconcile. Balances, statuses, and fees should agree across the product database, the processor's reports, and the general ledger. When they disagree, the disagreement is the work item. Smoothing it over with a manual adjustment without a documented cause is one of the most common ways small problems become audit findings.
• Design for partial failure. Card networks time out, automated clearing house files are returned, identity verification vendors go down, and third party risk scores drift over time. Good designs define what happens to a payment that was accepted but not confirmed, which customer message is shown, who is alerted, and how the transaction is resolved.
• Collect and keep only what a decision or a legal obligation needs. Record the purpose for each data element, restrict access by role, and set retention periods that match the stated purpose. Consent should be recorded as an event with a timestamp and a version of the wording the customer saw, not assumed from a checkbox that was never stored.

03Planning and preparation

• Before writing requirements, identify the product category and the regulatory perimeter. A digital wallet that holds stored value, a buy now pay later product, and an earned wage access feature can look alike to a customer but carry different licensing, disclosure, complaint handling, and data obligations. Ask legal or compliance to classify the activity in writing, and keep that classification with the product file.
• Map stakeholders early. The usual group includes the product owner, the engineering lead, risk, compliance, finance operations, the sponsoring bank if one exists, and the processors or cloud providers that will touch funds or data. Each one holds a piece of the decision. Record who signs off on which risk acceptance, because disputes after an incident almost always concern ownership rather than technology.
• Gather a baseline before setting targets. For a payments feature, that means current decline rates, dispute volumes, settlement timing, and reconciliation breaks from the existing flow. For a lending product, it means approval rates by segment, observed loss experience from comparable portfolios you have access to, and the cost of manual review per application. Where no internal baseline exists, say so and plan a limited pilot period rather than borrowing a number from a vendor presentation.
• Decide the vendor model before detailed design. Building a payment rail in house, using a banking as a service platform, or integrating a processor through its application programming interface each shifts liability, audit scope, time to market, and the degree of control you hold. Each choice trades speed against control, and the trade-off should be written down so it can be revisited when conditions change.

04Recommended workflow

1. 1
   : Define the customer outcome and the money or data movement on one page. Name every party, every ledger, and every status a transaction or application can hold, from initiated through pending, completed, returned, reversed, and closed.
2. 2
   : Classify the activity with compliance. Confirm licensing needs, required disclosures, consumer protection obligations, and data handling rules for the jurisdictions where the product will be offered. Record the classification, the reviewer, and any conditions attached to the approval.
3. 3
   : Write the control design alongside the happy path. Specify transaction limits, velocity checks, identity verification steps and their thresholds, fallback behavior when a vendor is unavailable, and the exception queue that will hold cases needing human review.
4. 4
   : Build integration contracts and test in sandbox environments. Confirm the vendor's current application programming interface version, how idempotency keys behave, how webhook retries are sent and deduplicated, and the cutoff times that govern same day versus next day settlement.
5. 5
   : Run reconciliation before launch. Compare the internal ledger, processor reports, and bank statements across at least one full settlement cycle, including a weekend or holiday if the product operates through them. Investigate every break and record the root cause, even when the amount is small.
6. 6
   : Launch in a limited segment with caps on volume, balances, and the number of customers. Monitor decline reasons, fraud losses, complaint categories, and support contacts daily, and define in advance the conditions that would pause the rollout.
7. 7
   : Review pilot results against the success criteria written in planning. Decide whether to expand, adjust, or stop, and document the decision with the evidence used. Expansion should trigger a fresh review of the control matrix, not only a configuration change.

05Quality checks, risk controls and compliance

• Testing for fintech needs more than functional checks. Test duplicate submissions, partial failures, reversals after settlement, currency rounding, time zone cutoffs, and the exact wording and status the customer sees while a payment is pending. Use production like data with personal information masked, and keep the test evidence with the release record.
• Core controls usually include identity verification with documented thresholds, transaction monitoring for suspicious patterns, sanctions screening against published lists, access reviews for production systems, and separation between the people who build payment logic and the people who approve payment releases. Many jurisdictions require anti money laundering programs with defined roles and suspicious activity reporting procedures. The specifics depend on where you operate, so confirm them with your compliance team and the current guidance from the relevant regulator.
• Security standards give practical reference points. If your systems store, process, or transmit payment card data, the Payment Card Industry Data Security Standard sets requirements that your acquirer or processor will expect you to meet, and the scope of your assessment depends on how card data flows through your environment. Consumer financial data rules such as the Gramm Leach Bliley Act in the United States and the General Data Protection Regulation in the European Union apply in different ways, and their applicability to a given product should be confirmed with counsel.
• Models used for credit or fraud decisions need documented inputs, performance monitoring, and a defined process for overrides. In the United States, fair lending and adverse action rules require lenders to give applicants accurate reasons for adverse decisions, which limits how opaque a credit model can be. Check current guidance from the relevant authorities before selecting a model type, and keep the validation evidence in the model file.
• Credit decisions, fraud holds, account freezes, sanctions matches, and tax reporting are areas where the guidance here is a starting point only. Follow the approved procedure, escalate to the designated owner, and obtain any required authorization before acting. Qualified professional judgment remains necessary in every such case.

06Collaboration and documentation

• Keep three documents current for every product. The first is a flow document showing money and data movement with named parties. The second is a control matrix mapping each risk to its control, its owner, and the evidence that proves the control operated. The third is an incident runbook covering processor outages, duplicate settlements, mass fraud events, and data exposure, with contact lists and decision rights written out.
• While a product is in pilot, hold a short weekly review with product, operations, risk, compliance, and engineering. Use a shared issue log with a single owner and a due date for each item. Avoid settling decisions only in chat threads, because auditors and incident reviewers will ask where a decision was recorded and who approved it.
• Vendor management needs its own file. It should contain the contract, service level terms, security attestations, data processing terms, sub processor lists, and an exit plan that explains how you would move customers and records if the vendor failed. Operations staff often hold the most useful knowledge about how a vendor actually behaves, so invite them into vendor reviews rather than only the procurement team.
• Documentation has limits. A document that nobody reads has no value, and an overgrown runbook is rarely followed under pressure. Keep runbooks short, put the first actions on the first page, and test them through tabletop exercises at least once before launch and after material changes.

07Measures and continuous improvement

• Track a small set of indicators tied directly to the design. Useful examples include authorization approval rate, settlement break rate, time to resolve a break, fraud loss as a share of payment volume, chargeback or dispute rate, complaint volume by category, and customer drop off during onboarding. Define each metric precisely, including numerator, denominator, and time window, before anyone looks at a dashboard.
• Set targets from your own baseline and stated risk appetite rather than from industry folklore. A workable approach is a tolerance band for each metric, with an agreed action when a band is breached. Expect trade-offs. Tightening fraud rules usually lowers losses but raises false declines, which in turn increases support contacts and lost revenue. Make those effects visible together so the team decides with both sides in view.
• Review incidents and exceptions monthly. Convert repeated exceptions into product changes, control changes, or clearer customer communication. Retire manual steps once they have been automated and tested, but keep an audit trail of what the manual step used to do so that historical records remain explainable.
• Practice differs by context. A small lender serving one state may run manual underwriting reviews that a national platform would automate under tight model governance. A payment facilitator in a high volume market needs different velocity limits from one serving a niche business to business segment. The same indicator can mean different things in each setting, so compare trends within a segment before comparing across products.

08Common mistakes and how to prevent them

• Treating the sponsor bank or processor as the owner of every compliance obligation. The bank or processor may hold certain regulatory duties, but your product still needs its own controls and monitoring. Write the split of responsibilities into the contract and the control matrix so that gaps are visible before an examiner finds them.
• Ignoring reconciliation until after launch. Breaks discovered late are expensive because customer balances have already moved. Build a daily matching job before the first live transaction and assign an owner to each break category, including the threshold at which a break becomes an incident.
• Assuming application programming interfaces are idempotent. Retries after a timeout can create duplicate charges or payouts. Use idempotency keys, test duplicate submissions in the sandbox, and confirm with the vendor how a timeout is reported and whether the original request may still complete.
• Launching with uniform limits for every customer. New accounts carry different risk from established ones. Tiered limits tied to verification level and account history reduce losses without blocking good customers, although tiers must be reviewed as customer behavior changes.
• Collecting more personal data than the purpose requires. Extra fields raise breach impact, consent obligations, and retention costs. Review each field against a written purpose and remove any field that cannot be defended.

09Practical checklist

• Confirm the activity classification and the reviewer's written conditions before design begins.
• Draw the money and data flow with every party, ledger, and status named.
• Document limits, velocity checks, verification thresholds, and exception queues alongside the happy path.
• Test duplicate submissions, partial failures, reversals, cutoffs, and pending state messages in the sandbox.
• Complete at least one full settlement cycle of reconciliation before the first live transaction.
• Launch in a capped segment with pause conditions written in advance.
• Keep the flow document, control matrix, incident runbook, and vendor file current.
• Review metrics against defined baselines and tolerance bands, and record every expansion or stop decision with its evidence.

★Learning sources

• Micro Degree: FinTech Fundamentals
• Micro Degree: Accounts Payable Management
• Micro Degree: Bank Reconciliation Operations
• Micro Degree: Digital Payment Systems