What financial technology covers as a subject
Financial technology sits where financial services meet software, data and systems design. Courses with this title usually ask students to understand how money, payments, lending, investment and insurance actually work, and how technology changes the way those services are built, delivered, regulated and secured. The exact balance varies between courses. Some lean towards programming and data, others towards finance, business models and regulation. Check the module lists of the courses you are applying to and let that balance shape which evidence you lead with.
The point that separates fintech from its neighbours is the combination itself. A statement that is only about markets reads like a finance, banking and investment application. One that is only about coding reads like computer science. One built around probability and modelling suits quantitative finance or actuarial science better. A strong fintech statement shows you are curious about how a financial process works and how a technical system carries it out, and that you see problems in the gap between the two.
Interests that suit fintech specifically
Pick one or two areas you can discuss in some depth rather than listing every trend. Useful areas include:
- Payments infrastructure. What happens between tapping a card or phone and the money moving: authorisation, settlement, the role of card networks and banks, why some transfers are instant and others take days. You might reflect on why faster payments also make some fraud harder to reverse.
- Open banking and data sharing. Letting third-party apps access account data with consent raises questions about competition, privacy, security and who is liable when something goes wrong.
- Credit decisions and automated lending. Using data or algorithms to assess borrowers can widen access to credit, but it can also reproduce bias or rely on data people did not knowingly give. This interest suits applicants who like both statistics and ethics.
- Fraud, security and identity. Authentication, scams that exploit people rather than systems, and the trade-off between friction and safety in app design.
- Distributed ledgers and digital assets. Worth discussing only if you go beyond price speculation to the underlying questions: what problem a shared ledger solves, where a conventional database would do the job better, and what regulators worry about.
- Regulatory technology and compliance. How firms use software to meet anti-money-laundering and reporting obligations. Less fashionable, but it shows you understand that financial services operate under rules.
- Financial inclusion. Mobile money, budgeting tools, and services for people poorly served by traditional banks, along with the risk of excluding people who are not comfortable with digital tools.
Being interested in an app you use is a starting point, not evidence. What counts is what you found out about how it works and what you think about its design choices.
Using your school subjects
- Mathematics and further mathematics. Compound interest, sequences, statistics and probability all apply directly. A sentence on how you used regression or distributions to think about risk or prediction is more useful than saying you enjoy maths. Avoid presenting this as quantitative finance-level modelling unless you have actually done that.
- Computer science. Coursework on databases, encryption, algorithms or networks connects well. If you built a project, say what it did, what went wrong and what you would change. Hashing and public-key cryptography link naturally to payments security and ledgers.
- Economics. Money, banking, market structure and market failure give you the vocabulary to discuss why new entrants can challenge established banks, or why regulation exists at all.
- Business studies and accounting. Business models, revenue and cash flow help you question how a free app makes money. Accounting shows you understand records and controls, which matters in any system that moves money.
- Extended Project or independent research. A focused project, such as comparing how two payment methods handle fraud or assessing the trade-offs of buy-now-pay-later schemes, can anchor a statement. Write about your method and conclusion, not just the topic.
Preparation and activities you could consider
None of these is required. Choose what fits your interests and what you can reflect on honestly.
- A small coding project with a financial purpose. A budgeting tool, a loan repayment calculator, or a script that analyses publicly available price data. It shows you can turn a financial idea into working logic. It does not show professional software engineering, so describe it accurately.
- Working with public data. Analysing interest rate or inflation series in a spreadsheet or Python teaches you to clean data and question it. The limit is that analysis of past data is not prediction, and saying so shows judgement.
- Reading regulators’ and central banks’ published material. Consumer-facing explainers and discussion papers on topics such as digital payments or crypto-assets show how authorities frame risk. Mention a specific argument you weighed, not just the publisher’s name.
- Following a specific development over time. Tracking how a single issue, such as reimbursement rules for scam victims or a firm’s change of business model, unfolded gives you something concrete to analyse.
- Online courses or competitions. Introductory courses in programming, data or finance, or school enterprise and coding competitions, can help. Name what you learned and applied, not just the certificate.
- Talking to people in the sector. A conversation with someone working in a bank’s technology team or a payments firm can sharpen your understanding of everyday work. Treat it as insight, not experience.
Connecting experience that is not directly financial
Most applicants have not worked in fintech. Ordinary experience is useful when you draw out a specific connection and are clear about its limits.
- Retail or hospitality jobs. Using card terminals, handling refunds, dealing with declined payments or cash-up discrepancies gives you a frontline view of payment systems failing or working. You could reflect on why a payment was declined or how the till reconciled. It does not show you understand the back-end infrastructure, so pair it with what you then found out.
- Managing money for a family or as a carer. Helping a relative set up online banking, recognise a scam text or manage direct debits shows you how digital services work for people who find them hard. This links directly to inclusion and interface design. Keep personal details proportionate; the reflection matters more than the story.
- Volunteering with treasurer or fundraising tasks. Tracking donations, using online fundraising platforms or keeping club accounts shows you dealing with records, fees and accountability. It is small-scale bookkeeping, not financial management.
- Gaming and online communities. In-game currencies, marketplaces and account security can lead into questions about digital value and fraud. Use this only if you move from playing to analysis, for example how a platform prevents duplicated items or scams.
- Personal saving or investing apps. Comparing features, fees and how an app nudges behaviour can be good material. Avoid presenting trading gains as a qualification; short-term returns say little about understanding, and some readers will see them as a warning sign.
- Tech hobbies. Building a website, running a server or fixing family devices shows comfort with systems. Link it to finance through something like security or reliability, or it reads as a computing statement.
What useful reflection looks like
Reflection in a fintech statement usually involves holding two perspectives at once. Strong reflection tends to:
- explain a mechanism in a sentence or two, showing you understand how something works rather than that it exists;
- identify a trade-off, such as speed against fraud protection, personalisation against privacy, or innovation against consumer protection;
- consider who benefits and who carries the risk, including people outside the target user group;
- show where your view changed or where you found the limits of your own project or reading;
- link the point to what you want to study next, such as a module area or a question you cannot yet answer.
For example, writing that you built a loan calculator is weak. Writing that building it made you realise how small changes in rate and term altered total repayment, and that this made you question how clearly lenders present those figures, connects technical work to a financial and consumer issue.
Pitfalls specific to fintech statements
- Buzzword stacking. Listing blockchain, AI, big data and crypto without explaining any of them suggests surface interest. One concept explained well is worth more.
- Treating disruption as automatically good. Uncritical enthusiasm for replacing banks ignores regulation, failures and consumer harm. Show you can see weaknesses as well as appeal.
- Crypto price talk. Discussing what you bought and how much it rose shows little. If digital assets interest you, discuss the technology, governance or regulatory questions.
- Drifting into a neighbouring subject. Check the balance. If almost every paragraph is about markets or about code, ask whether fintech is the right course or whether your statement needs rebalancing.
- Overstating technical skill. Following a tutorial is not building a trading system. Accurate, modest description of real work is more convincing.
- Confusing the degree with a job. The course is the study of financial systems and technology, not training for one role at a particular firm. Career aims can be mentioned briefly, but the statement should be about the subject.
- Ignoring ethics and law. Data protection, fairness and consumer protection are central to the field. Leaving them out can make an interest look one-sided.
For general advice on planning, structure and editing, read our personal statement writing guide.