How to build a fintech course: a complete guide for lecturers

Central question: What changes when technology rewires how financial services are produced, distributed and governed?

Begin by separating FinTech from a catalogue of apps. The useful teaching frame is functional: payments, saving, borrowing, investing, risk transfer and market infrastructure are established financial functions whose economics can change when data, software, connectivity and new institutional forms alter cost, speed, reach or control.

What this concept covers

• Financial intermediation and the functions of finance
• FinTech, TechFin and digital transformation of incumbents
• Unbundling and rebundling of financial services
• Technology, data and regulation as joint design constraints
• Value creation through lower frictions, broader access, better information or new coordination mechanisms

Learning outcomes

By the end of this concept, students should be able to:

• Map a FinTech product to the financial function it changes
• Distinguish technology novelty from economic novelty
• Identify the incumbent friction a FinTech proposition is trying to remove
• Compare value creation for customers, intermediaries and infrastructure providers

Supports Course Outcomes 1 and 2.

How to teach it

• Open with one customer journey, such as sending money or applying for credit, and map every intermediary and fee
• Ask groups to classify ten products by financial function rather than by company label
• Require a before-and-after process map showing which friction is reduced and which new risk appears

Case-style example

HarborPay processes £180 million of annual merchant payments at a 1.2% take rate. Its proposed instant-settlement service could cut merchants' average settlement delay from two days to ten minutes, but requires £1.8 million of new compliance and infrastructure cost. Students compute current gross fee revenue, estimate the break-even adoption rate if the new service adds 20 basis points, then argue whether speed creates enough value to justify the fixed cost. They discover that 'faster' is not automatically a business model.

Where students struggle

Students often equate FinTech with start-ups or assume digital delivery automatically lowers total cost. Keep returning to the underlying financial function, who bears risk and which costs are genuinely removed rather than shifted.

Reading and a quick check

Use the reading list below to select a current source linked to this topic. Ask students to complete one sentence: "This FinTech changes finance because it changes X, which affects Y, but creates Z risk."

Teaching activity

Use a process-mapping workshop. No simulation is needed at this stage because the learning objective is to diagnose the financial function before students design a venture.

Where it leads

The course can now move to the clearest infrastructure example: payments, where settlement, interoperability, pricing and network effects are visible.

Central question: How do digital payment systems move value, and where do economics, interoperability and trust sit in the stack?

Payments are the best place to teach that a customer-facing app is only the top of a layered system. Students should see acceptance, messaging, clearing, settlement, safeguarding, fraud controls and network rules, then connect those layers to merchant economics and user adoption.

What this concept covers

• Payment rails, wallets, card networks and account-to-account payments
• Clearing, settlement, safeguarding and liquidity
• Merchant discount rates, interchange, take rates and unit economics
• Interoperability, network effects and switching costs
• Cross-border payments, remittances and inclusion

Learning outcomes

By the end of this concept, students should be able to:

• Trace a payment from customer initiation to final settlement
• Calculate basic payment revenue and cost economics
• Evaluate when interoperability strengthens adoption or weakens platform lock-in
• Identify operational, fraud and liquidity risks in a payment design

Supports Course Outcomes 2 and 3.

How to teach it

• Draw a payment stack and have students place participants on it
• Compare closed-loop and interoperable systems
• Use a merchant P&L to show why small changes in take rate, fraud loss or chargebacks matter

Case-style example

PulseWallet has 600,000 monthly active users who make 8 payments each month at an average £24 ticket. The platform earns 0.55% per transaction and loses 0.12% to fraud and disputes. An interoperable bank-transfer rail would cut revenue to 0.35% but reduce losses to 0.04% and raise payment volume by an estimated 30%. Students compute contribution before operating costs under both models, then recommend whether to migrate. They discover that lower pricing can still improve economics if usage and loss rates move enough.

Where students struggle

Students tend to discuss payments at the interface level and ignore settlement, scheme rules and risk allocation. Require every proposal to state where money is held, when finality occurs and who absorbs a failed or fraudulent transaction.

Reading and a quick check

Use the reading list below to select a current source linked to this topic. Give three payment architectures and ask which one has the strongest network effect, which has the lowest direct fee and which leaves the most operational dependence.

Teaching activity

Run a payment-architecture design studio in which teams choose rails, economics and controls for the same merchant segment, then critique each other on settlement and failure modes.

Where it leads

Once students can see the infrastructure, they can evaluate digital banks and embedded-finance products that package payments with deposits, cards and other services.

Central question: When does a digital financial interface become a durable banking business rather than a subsidised distribution layer?

This concept moves from payments to the institution and customer relationship. Students compare licensed banks, neobanks, banking-as-a-service models and non-financial platforms that embed financial products. The analytical focus is customer acquisition, engagement, funding, cross-sell, compliance and who ultimately holds the balance-sheet risk.

What this concept covers

• Neobanks and digitally transformed incumbents
• Banking-as-a-service and embedded finance
• Deposit economics, fee income and cross-sell
• Customer acquisition cost, activation, retention and lifetime value
• Partner dependence, licensing and balance-sheet ownership

Learning outcomes

By the end of this concept, students should be able to:

• Compare licensed and partnership-based digital banking models
• Calculate simple CAC payback and customer contribution
• Identify where credit, liquidity and conduct risk sits
• Evaluate whether embedded finance complements or disintermediates banks

Supports Course Outcomes 3 and 4.

How to teach it

• Use a unit-economics worksheet for a neobank
• Map one embedded-finance product across platform, licensed bank and end customer
• Ask students which capabilities are strategic and which can safely be outsourced

Case-style example

NovaBank acquires customers for £42 each. Of 100,000 new accounts, 72% activate, annual churn is 18%, and an active customer contributes £3.60 per month before central overhead. A supermarket partner can cut acquisition cost to £18 but will keep 35% of contribution and owns the customer interface. Students calculate first-year contribution and approximate CAC payback for both channels, then choose direct or embedded distribution. They discover that cheaper acquisition may trade away control of the most valuable relationship.

Where students struggle

Students often celebrate user growth without asking whether activity, retention and monetisation are sufficient. Make them separate registered users, active users, funded accounts and profitable cohorts.

Reading and a quick check

Use the reading list below to select a current source linked to this topic. Ask which metric would make them change their view first: activation, churn, contribution per active customer or deposit funding cost.

Teaching activity

Use the verified Uala case later in the course or a fictional channel strategy memo here. The priority is to connect customer growth to banking economics and ownership of the relationship.

Where it leads

Digital banking naturally leads to credit, where data and automation can change underwriting speed and borrower access but also create model and fairness risks.

Central question: Can technology expand credit access without hiding or mispricing credit risk?

FinTech lending lets lecturers connect financial technology to a classic finance problem: information asymmetry. Digital footprints, cash-flow data and automated decisioning can change screening and servicing, while BNPL and marketplace models alter distribution and funding. Students should analyse both access and risk rather than treating faster approval as the outcome.

What this concept covers

• Digital lending and marketplace lending models
• Alternative data and cash-flow underwriting
• BNPL economics and consumer behaviour
• Funding models, securitisation and bank partnerships
• Default, loss given default, pricing, fairness and adverse selection

Learning outcomes

By the end of this concept, students should be able to:

• Calculate simple expected credit loss and contribution
• Evaluate whether alternative data improves screening or merely changes exclusion
• Compare originate-to-hold and originate-to-distribute models
• Identify consumer-protection and model-risk concerns

Supports Course Outcomes 4 and 5.

How to teach it

• Give students a loan cohort and ask them to reconcile yield with expected loss and servicing cost
• Compare approval thresholds for thin-file and traditional borrowers
• Require an explicit policy for explainability, hardship and adverse outcomes

Case-style example

ClearLend can approve 10,000 small-business applications. Its current model approves 45%, charges a 14% annual yield and predicts 5% default with 55% loss severity. A new cash-flow model would approve 58%, lower average yield to 13%, but predicts 6.2% default and costs £35 per originated loan to operate. Students estimate expected loss rates and revenue before funding cost, then decide whether broader approval is economically and socially defensible. They discover that access gains must be judged alongside pricing, loss and evidence quality.

Where students struggle

Students may treat an algorithmic score as objective. Push them to distinguish predictive accuracy, causal interpretation, fairness, explainability and the consequences of errors.

Reading and a quick check

Use the reading list below to select a current source linked to this topic. Ask students which change is worse for a lender: a one-point increase in default rate or a five-point fall in approval rate, and what data they need before answering.

Teaching activity

Use a credit-policy committee role-play where teams set approval and pricing thresholds for the same dataset and must defend both financial and conduct outcomes.

Where it leads

Lending depends increasingly on data access. The next concept asks who controls financial data and how open banking and APIs change competition.

Central question: What happens to competition and product design when customers can permission their financial data to move between providers?

Open banking turns data access into a strategic and regulatory design problem. Students should understand APIs at a conceptual level, but the finance teaching question is how permissioned data can reduce switching frictions, support account aggregation and underwriting, and redistribute value between banks, FinTechs and customers.

What this concept covers

• APIs, consent and permissioned data access
• Open banking and broader open-finance models
• Account information and payment initiation
• Data portability, switching costs and competitive entry
• Privacy, security, liability and consent quality

Learning outcomes

By the end of this concept, students should be able to:

• Explain an API-based financial-data flow without writing code
• Evaluate how data access changes entry barriers
• Design a consent flow that is economically useful and legally defensible
• Identify commercial dependence on incumbent data quality and uptime

Supports Course Outcomes 5 and 6.

How to teach it

• Build a simple API sequence diagram using boxes and arrows
• Give teams a product that only works if customers share transaction data and make them define the minimum data required
• Debate whether more data access always improves competition

Case-style example

LedgerLink offers cash-flow analytics to SMEs. It can integrate directly with six major banks for £480,000 a year and achieve 99.7% uptime, or use one aggregator for £170,000 with 99.1% uptime and a 0.08% error rate in categorised transactions. A missed or misclassified data point causes an estimated £14 support cost in 20% of affected cases. Students estimate expected support cost at 2 million monthly transactions and choose the architecture. They discover that cheaper connectivity can create hidden quality and dependency costs.

Where students struggle

Students can become overly technical or overly regulatory. Keep the analysis anchored to value: which data is needed, what decision it enables, who controls access and what happens when the data is unavailable or wrong.

Reading and a quick check

Use the reading list below to select a current source linked to this topic. Ask students to name the smallest dataset needed for a budgeting app, a lender and a fraud model, then compare the privacy burden.

Teaching activity

Run an API-product design workshop with a consent screen, data map and outage scenario. Teams defend data minimisation and commercial resilience.

Where it leads

Open data makes platforms more contestable, but platform scale can also create new concentration. That tension is the core of the next concept.

Central question: When does a FinTech platform create useful coordination, and when does scale become dependence or market power?

Platform models can bring merchants, consumers, lenders, investors or developers together. The course should distinguish direct and indirect network effects, ecosystem cross-subsidy and data advantages from simple user growth. BigTech entry adds a further question: whether finance is the product, an engagement layer or a complement to a wider ecosystem.

What this concept covers

• Two-sided and multi-sided platforms
• Direct and indirect network effects
• Data feedback loops and ecosystem cross-subsidy
• BigTech entry into payments, credit and wallets
• Concentration, interoperability and strategic dependence

Learning outcomes

By the end of this concept, students should be able to:

• Map value exchanges across platform sides
• Identify which network effect is actually present
• Evaluate subsidy and pricing choices across sides
• Assess concentration and dependency risks created by platform scale

Supports Course Outcomes 6 and 7.

How to teach it

• Have groups draw a platform with arrows showing money, data and value
• Change one side of the market and ask how the other side reacts
• Compare platform economics with a pipeline business that sells one product directly

Case-style example

MarketSquare runs an e-commerce marketplace with 1.4 million buyers and 42,000 sellers. Its wallet is used by 28% of buyers. Offering merchant credit could raise seller retention from 76% to 84%, but requires a lending partner that keeps 60% of interest margin and receives transaction data on funded sellers. Students estimate the number of sellers retained and debate whether the data-sharing and partner dependence justify the ecosystem gain. They discover that an attractive cross-side effect can still create a strategic control problem.

Where students struggle

Students often call any large digital firm a platform and any growth pattern a network effect. Require them to name the sides, the cross-side benefit and the mechanism that becomes stronger with scale.

Reading and a quick check

Use the reading list below to select a current source linked to this topic. Ask whether the case still works if the wallet disappears. If the platform value proposition is unchanged, the claimed network effect may not be financial.

Teaching activity

Use Ant Group (A) after this concept to test platform scope, finance-data feedback loops and regulatory perimeter questions.

Where it leads

Platforms change coordination through centralised digital systems. Distributed ledgers offer a different architecture for coordinating ownership and transfer.

Central question: Which financial frictions can shared ledgers or tokenisation remove, and which costs do they merely move elsewhere?

Teach blockchain as an institutional and market-infrastructure design choice, not as a synonym for cryptocurrency. Students need a functional understanding of shared state, consensus, programmability and tokenised claims, then a disciplined comparison with conventional databases and settlement arrangements.

What this concept covers

• Distributed ledgers, consensus and shared state
• Smart contracts and programmable workflows
• Tokenisation of money and financial assets
• Atomic settlement and delivery-versus-payment concepts
• Scalability, governance, privacy and interoperability trade-offs

Learning outcomes

By the end of this concept, students should be able to:

• Explain why a shared ledger may be useful without relying on jargon
• Compare centralised and distributed architectures for the same process
• Identify settlement, reconciliation and counterparty-risk implications
• Evaluate governance and interoperability requirements for tokenised finance

Supports Course Outcomes 7 and 8.

How to teach it

• Use a reconciliation exercise with three institutions keeping separate ledgers
• Then replace it with a shared-state design and ask what problem disappears and what new governance problem appears
• Have students specify who can write, validate, reverse and upgrade the system

Case-style example

TokenRail proposes to settle a private-bond market with £4 billion annual turnover. The current process costs dealers 9 basis points per trade in reconciliation and settlement operations. TokenRail estimates 4 basis points, but needs £3.2 million annual network governance and cyber cost shared across participants. Students calculate the turnover needed for aggregate savings to cover fixed cost, then debate whether same-day shared settlement is worth the governance dependence. They discover that tokenisation needs sufficient scale and institutional coordination, not only technical feasibility.

Where students struggle

Students can become captured by architecture labels. Force every claim back to a process metric: settlement time, reconciliation cost, collateral usage, counterparty exposure or programmability.

Reading and a quick check

Use the reading list below to select a current source linked to this topic. Give one use case and ask whether a normal permissioned database would achieve the same outcome. Students must justify why distribution is necessary.

Teaching activity

Run a settlement-design comparison. One team defends a conventional central operator; another defends a permissioned tokenised platform using the same service requirements.

Where it leads

Once the architecture is clear, students can analyse digital assets, stablecoins, DeFi and CBDCs without conflating all blockchain-based instruments.

Central question: How should students distinguish speculative cryptoassets from digital money, decentralised financial protocols and central-bank digital currency?

A rigorous FinTech course should cover digital assets but resist becoming a crypto markets course. The useful distinctions are economic claim, issuer, redemption promise, governance, settlement asset and risk. Stablecoins, DeFi and CBDCs solve different problems and create different exposures.

What this concept covers

• Cryptoassets and token economics
• Stablecoins, reserves and redemption risk
• DeFi protocols, automated market makers and smart-contract risk
• CBDC objectives and design choices
• Runs, liquidity, custody, governance and regulatory perimeter

Learning outcomes

By the end of this concept, students should be able to:

• Classify digital assets by economic claim and governance
• Analyse stablecoin reserve and redemption risk
• Explain the main DeFi mechanisms and failure modes
• Compare CBDC, commercial bank money and stablecoins as payment assets

Supports Course Outcomes 8 and 9.

How to teach it

• Give four digital instruments and remove their brand names so students classify them by claim
• Run a stablecoin balance-sheet stress test
• Separate protocol mechanics from investment-return narratives

Case-style example

StableFlow has £900 million of tokens outstanding backed by 70% short-dated government bills, 20% bank deposits and 10% secured commercial paper. In a stress, users seek to redeem 35% in three days. Bills can be sold at 99.7, deposits at par subject to a £120 million daily transfer limit, and commercial paper at 96. Students compute available three-day liquidity and redemption losses, then recommend reserve changes. They discover that 'fully backed' does not mean instantly liquid at par.

Where students struggle

Students may jump from price performance to technology conclusions. Keep asset pricing, payments utility, protocol governance and monetary design as separate analytical questions.

Reading and a quick check

Use the reading list below to select a current source linked to this topic. Ask students to classify three risks for a stablecoin holder: reserve credit risk, redemption liquidity risk and smart-contract risk, then identify which party can mitigate each.

Teaching activity

Use the Mercado Bitcoin case to examine the economics and financing of a crypto business without treating token prices as the sole source of value.

Where it leads

Digital assets make technology visible, but data-driven models are transforming mainstream finance just as deeply. The next concept turns to AI and machine learning.

Central question: Where does AI improve financial decisions, and where does it create model, explainability or conduct risk?

AI belongs in the subject as both a technology and a governance problem. Focus on use cases such as credit, fraud, service, trading, advice and compliance. Students do not need to build advanced models, but they should understand training data, prediction, drift, false positives, explainability and the distinction between a useful prediction and a defensible financial decision.

What this concept covers

• Machine learning in credit, fraud, advice and operations
• Alternative data and feature selection
• Model performance, drift and validation
• Explainability, bias, fairness and human oversight
• Generative AI in financial workflows

Learning outcomes

By the end of this concept, students should be able to:

• Interpret basic model-performance trade-offs
• Distinguish prediction quality from decision quality
• Identify fairness and explainability risks
• Design a governance process for model change and human override

Supports Course Outcomes 9 and 10.

How to teach it

• Use a confusion matrix rather than code to teach false positives and false negatives
• Change the cost of each error and ask students to move the threshold
• Require a model card covering purpose, data, limitations and escalation

Case-style example

SignalCredit's fraud model reviews 2 million monthly card transactions. At the current threshold it catches 92% of £1.5 million monthly fraud but falsely blocks 0.7% of legitimate transactions, creating £4.20 average service and lost-margin cost per false block. A stricter threshold catches 97% of fraud but raises false blocks to 1.6%. Students estimate avoided fraud and false-block cost, then recommend a threshold with customer-harm controls. They discover that higher model accuracy on one metric can worsen the total decision.

Where students struggle

Students often assume a more complex model is superior. Make them articulate the decision cost, data quality, explainability need and failure mode before discussing algorithm choice.

Reading and a quick check

Use the reading list below to select a current source linked to this topic. Ask which performance metric matters most for a given use case and why. There should be no universal answer.

Teaching activity

Run a model-risk committee exercise in which teams defend a threshold to product, risk and compliance stakeholders.

Where it leads

AI increases dependence on data and digital infrastructure. The next concept brings identity, cyber risk, fraud and operational resilience together.

Central question: How can a digital financial service scale trust when identity, fraud and infrastructure failure are continuous operating risks?

FinTech growth depends on reliable identity, authentication, security and service continuity. This concept connects onboarding friction to fraud loss, cybersecurity investment and operational resilience. The goal is not to train cyber engineers but to make students treat trust and resilience as economic design variables.

What this concept covers

• Digital identity, KYC and authentication
• Fraud typologies and transaction monitoring
• Cybersecurity governance and third-party risk
• Cloud concentration, outages and operational resilience
• Customer friction, false positives and incident response

Learning outcomes

By the end of this concept, students should be able to:

• Balance onboarding conversion against identity and fraud controls
• Calculate expected loss from simple fraud scenarios
• Map critical third parties and single points of failure
• Design escalation and recovery priorities after an incident

Supports Course Outcomes 10 and 10.

How to teach it

• Use a funnel showing application, verification, activation and fraud outcomes
• Introduce one control at a time and quantify conversion and loss effects
• Run a tabletop outage where teams decide which services to restore first

Case-style example

VerifyNow onboards 80,000 customers per month. Manual review catches 95% of identity fraud but 18% of legitimate applicants abandon the process. A new biometric flow is expected to cut abandonment to 8% while catching 91% of fraud. Identity fraud occurs in 1.1% of applications and costs £620 per successful fraud. Students estimate legitimate customers gained and incremental fraud loss, then decide whether to deploy with extra controls. They discover that lower friction can create value while still increasing risk that must be priced and governed.

Where students struggle

Students can discuss cyber and identity as compliance checklists. Require them to connect controls to customer conversion, expected loss, service availability and reputation.

Reading and a quick check

Use the reading list below to select a current source linked to this topic. Ask students which is the worse outcome for a given product: a false rejection, a false acceptance or a two-hour outage. The answer must depend on context and value at risk.

Teaching activity

Run an incident-response tabletop with product, technology, risk and regulator roles. The output is a prioritised action log and customer communication.

Where it leads

With the main product and infrastructure risks visible, students are ready to integrate regulation, competition, consumer protection and systemic stability.

Central question: How should regulation preserve trust and stability without freezing useful financial innovation?

Regulation should not be a final compliance lecture. It is a design variable throughout FinTech because licensing, data, safeguarding, conduct, competition and prudential rules shape the feasible business model. This concept asks students to reason across innovation benefits, consumer outcomes and system-wide externalities.

What this concept covers

• Activity-based and entity-based regulatory approaches
• Licensing, safeguarding and prudential perimeter
• Consumer protection, disclosure and vulnerable customers
• Competition, data access and platform concentration
• Regulatory sandboxes, RegTech and SupTech
• Financial stability, operational concentration and cross-border coordination

Learning outcomes

By the end of this concept, students should be able to:

• Identify which regulatory objective applies to a FinTech activity
• Evaluate trade-offs between innovation, competition and protection
• Design proportionate controls for a new product
• Recognise when firm-level innovation creates system-wide dependence

Supports Course Outcomes 10 and 10.

How to teach it

• Use a regulatory-objectives matrix rather than memorising jurisdiction-specific rules
• Give the same product to three stakeholder groups: founder, regulator and consumer advocate
• Ask teams to propose minimum launch conditions and evidence for review

Case-style example

FlexFinance wants to launch salary-linked advances to 200,000 workers. The average advance is £240 for 18 days with a £7 fixed fee. Internal testing suggests 22% of users would take more than six advances per year and 9% would roll into a partner credit product. Students calculate an illustrative annualised cost for a one-off advance, identify conduct risks, and draft launch conditions. One group prioritises access and transparency; another proposes stronger frequency limits. They discover that a low absolute fee can still create problematic repeat-use incentives.

Where students struggle

Students often assume regulation means naming rules. The higher-value skill is identifying the regulatory objective, the harm pathway and the evidence needed to show that controls are proportionate.

Reading and a quick check

Use the reading list below to select a current source linked to this topic. Ask students to write one sentence each from the perspective of innovation, competition, consumer protection and stability, then reconcile them into one decision.

Teaching activity

Run a regulatory approval committee using a fictional product dossier. Teams must approve, conditionally approve or reject and state the evidence that would change their view.

Where it leads

The final concept integrates the course by asking students to design and defend a FinTech venture that works commercially and institutionally.

Central question: Can a FinTech venture create customer value, earn sustainable economics and scale within technology and regulatory constraints?

Close by integrating finance, technology, customer need, unit economics, risk and regulation. A credible capstone asks students to design or evaluate a venture, not simply pitch an app. They should define the problem, product, market, revenue model, data and infrastructure dependencies, compliance perimeter, unit economics, funding need and evidence that could falsify the thesis.

What this concept covers

• Problem-solution fit and value proposition
• TAM, SAM, SOM and realistic adoption assumptions
• Revenue model, unit economics and use of funds
• Technology, data and partner dependencies
• Regulatory perimeter and go-to-market constraints
• Investor criteria, ownership and post-money valuation

Learning outcomes

By the end of this concept, students should be able to:

• Build a coherent FinTech business model linked to a real financial friction
• Defend market sizing and unit-economics assumptions
• Identify the minimum regulatory and technology capabilities needed to launch
• Present and negotiate a funding case under investor challenge

Supports Course Outcomes 10 and 10.

How to teach it

• Require a one-page venture logic before allowing pitch design
• Make every market-size and unit-economics claim cite a source or state an assumption
• Use a red-team review for regulation, data and operational resilience before investment pitching

Case-style example

OrbitPay plans a cross-border SME payments service. It targets 18,000 addressable firms, assumes 12% three-year penetration, £52,000 average annual payment volume per customer and a 0.65% take rate. Variable processing and compliance cost is 0.31% of volume; annual fixed operating cost at launch is £2.4 million. Students compute three-year revenue and contribution at target penetration, estimate the customer count needed to cover fixed cost, then decide whether to fund the plan. They discover how market share, unit margin and regulatory cost jointly determine whether a plausible product is investable.

Where students struggle

Students can produce polished pitches without an internally consistent model. Mark coherence across customer problem, economics, data, risk, regulation and funding, not presentation style alone.

Reading and a quick check

Use the reading list below to select a current source linked to this topic. Ask every team to name the single assumption that would kill its venture if wrong, plus the cheapest evidence it could gather next week to test it.

Where a simulation fits

The Startup Creation Simulation is the closest fit here. It is not a dedicated FinTech simulation. Use it only after students have already learned payments, digital banking, data, technology risk and regulation, then require startup teams to build FinTech ventures and VC teams to apply explicit FinTech investment criteria.

Where it leads

This concept closes the lifecycle. Students should now be able to evaluate a FinTech proposition as a financial service, a technology system, a regulated activity and a business model at the same time.

10-week course structure

A 10-week course should compress adjacent mechanisms while preserving the logic from financial function to integrated judgement. Combine payments with digital banking, and combine AI with identity and fraud rather than removing core risk topics.

14-week course structure

A 14-week version creates room to separate cross-border payments and inclusion, deepen digital-asset architecture, and give the capstone a dedicated design and debrief sequence.

The Startup Creation Simulation is the closest current Finsimco fit for FinTech, but it should be framed accurately. It is a 6 to 10 hour entrepreneurship simulation in which startup teams develop an opportunity, value proposition, market sizing and Business Model Canvas, while venture capital teams define investment criteria and an Investment Process Document. The sides then meet in a live pitch and funding market and negotiate investment amount and equity ownership.

Why it fits here

Use it only after the FinTech content has been taught. The simulation supplies the venture-creation and investor-decision process; your FinTech course supplies the domain constraints. Require every startup to propose a financial-technology venture and every VC team to publish criteria covering financial friction, unit economics, technology/data dependence, regulatory perimeter, trust and scalability.

What students do

• Startup teams identify the customer problem and solution, define the value proposition, size TAM, SAM and SOM, and complete a Business Model Canvas.
• VC teams write an investment thesis, set screening criteria and build an Investment Process Document before pitches arrive.
• Startup teams build and submit an investor pitch covering problem, solution, market size, business model, use of funds and amount sought.
• During the live stage, startups pitch and defend market sizing and unit economics while VC teams compare opportunities and question founders.
• Both sides negotiate investment amount and percentage ownership, which imply post-money valuation. Some ventures may receive secondary funding and some remain unfunded.
• The final debrief compares funding, valuation, ownership and whether investor choices matched stated criteria.

Recommended course placement

• Begin the FinTech-specific venture brief in Session 11 after regulation and risk integration.
• Use the main simulation stages across Session 12 plus additional scheduled or independent time, because the full activity does not fit into a normal two-hour class.
• Follow with an individual assumptions note or short oral defence so each student supplies attributable academic evidence.

Knowledge students should have before the simulation

• A clear FinTech customer problem and financial function
• Basic market sizing and unit economics
• Technology and data dependencies
• Relevant regulatory perimeter and consumer risks
• A defensible funding need and evidence plan

Delivery format

Suggested debrief questions

• Which venture solved a genuine financial friction rather than adding a digital interface?
• Which assumptions about adoption, take rate, loss, fraud or compliance most affected investability?
• Did VC teams actually fund ventures that matched their pre-committed investment criteria?
• Where did technology or data dependence create a risk that the pitch underweighted?
• Which regulatory or consumer-protection issue should have changed product design before funding?
• What evidence would you demand before committing real capital?

Grading with the Startup Creation Simulation

The Startup Creation Simulation involves startup teams building an opportunity, value proposition, market sizing, Business Model Canvas and pitch, while venture capital teams define screening criteria and an investment process. The sides then pitch, question and negotiate investment amount and ownership. For a FinTech course, grade the FinTech-specific reasoning you require around the simulation, not funding success by itself.

• Problem definition and evidence that the venture addresses a genuine financial friction.
• Quality and internal consistency of TAM, SAM, SOM, revenue model, unit economics and use of funds.
• Technology, data and third-party dependencies and whether they are appropriate for the proposed financial service.
• Regulatory perimeter, consumer protection, fraud, cyber and resilience considerations.
• For VC teams, quality and consistency of pre-committed investment criteria and how those criteria are applied across pitches.
• For startup teams, ability to defend market sizing and unit economics under investor questioning and negotiate credible funding and ownership terms.
• Individual assumptions note or oral defence explaining what the student would change after the debrief.

The platform provides team-level submissions, negotiated terms and comparative outcomes that can support academic judgement. It does not automatically establish which individual student made which argument or provide a confirmed individual contribution score.