Fintechs move money and hold financial data with the attack surface of a cloud-native software company and the regulatory exposure of a bank, often with a fraction of a bank's security team. Their products are APIs, mobile apps and cloud workloads, their partners are banks, card schemes and data aggregators, and their attackers range from fraud rings to state actors chasing crypto assets. This guide covers the fintech threat picture, the regulation that applies to payment, e-money, lending, open banking and crypto firms, the controls that differ from a general enterprise baseline, and how to measure them. It is written for security, engineering, fraud and compliance leads at fintechs, and for banks assessing fintech partners.
Key takeaways
- Fraud and cyber are one problem. ENISA found social engineering was the most common route to fraud in the European finance sector, so account takeover, authorised push payment fraud and API abuse belong in the security programme, not only with the fraud team.
- Your licence decides your rulebook. Payment and e-money institutions and crypto-asset service providers are inside DORA in the EU; US non-bank financial firms fall under the FTC Safeguards Rule; bank partners impose interagency third-party expectations by contract.
- APIs are the product and the attack surface. Broken object level authorisation and abuse of sensitive business flows (OWASP API1 and API6 2023) lead directly to data exposure and money movement.
- Machine identities hold the money. Cloud roles, payment API keys, signing keys and CI/CD tokens are the credentials behind the largest fintech and crypto losses, as the Bybit hack showed.
- Outsourced operations need insider controls. Support agents and contractors with access to customer data are a primary data theft route, as the Coinbase insider breach showed.
What makes fintech different
Fintech covers payment service providers and e-money issuers, digital lenders, neobanks built on a partner bank (banking as a service), open banking account information and payment initiation providers, wealth and trading apps, and crypto exchanges and custodians. The common thread is that customer-facing financial functions run on public cloud, third-party APIs and fast release cycles.
- Direct path from compromise to cash: A stolen session, API key or signing key can move funds immediately and irreversibly. ATT&CK v20 tracks this impact as T1657 Financial Theft.
- Layered third parties: A typical fintech depends on a sponsor bank, a card processor, a KYC provider, an open banking aggregator, a cloud provider and an outsourced support team. Each is both a supplier risk and a regulatory dependency.
- Customer authentication is a regulated control: In the EU and UK, strong customer authentication under PSD2 is a legal requirement for payments and account access, not a product choice. See the PSD2/PSD3 Strong Customer Authentication Guide.
- Small security teams, large obligations: A 200-person fintech can carry the incident reporting, testing and third-party register duties of a much larger bank.
Threat picture
ENISA's first finance sector threat landscape (published 21 February 2025) analysed 488 publicly reported incidents between January 2023 and June 2024. Credit institutions were the most targeted entity type at 46%. Social engineering was the most common initial access route for fraud; recorded fraud was only 6% of incidents, which ENISA attributes to under-reporting and to fraud being recorded under its initial vector. Hacktivist DDoS targeted credit institutions in 58% of cases. Ransomware hit finance less than other sectors, but when it did the main impact was financial loss (38%). ENISA also recorded 29 supplier-related incidents, most of them data exposure (63%), and rising crypto-related fraud and theft. Mobile banking trojans and spyware against bank customers made up most of the malware cases.
| Threat | How it shows up in fintech | ATT&CK v20 / OWASP | Priority control |
|---|---|---|---|
| Account takeover and credential stuffing | Reused passwords and phished OTPs used to log in and drain balances or change payout details | T1110.003, T1621, T1078 | Passkeys or app-bound authenticators; risk-based step-up on payee and device changes. See the Account Takeover Prevention Guide. |
| Authorised push payment fraud | Customers socially engineered into sending money themselves; SCA succeeds because the real customer approves | T1566 (against customers) | Payee name checks, dynamic warnings, payment holds on risk signals. See the Authorised Push Payment (APP) Fraud Guide. |
| API authorisation flaws | Changing an account or transaction ID in a request returns another customer's data or acts on their account | OWASP API1:2023 Broken Object Level Authorization; API2:2023 Broken Authentication | Object-level authorisation checks in every handler; automated authorisation tests in CI |
| Abuse of sensitive business flows | Bots opening accounts with synthetic identities, cycling referral bonuses, card testing | OWASP API6:2023 Unrestricted Access to Sensitive Business Flows | Rate and velocity limits per flow, device signals, bot management. See the Synthetic Identity Fraud Guide. |
| Cloud credential and role abuse | Over-privileged workload roles, leaked access keys and stolen session tokens used to read data stores or alter code | T1078.004, T1528, T1530 | Least-privilege roles, short-lived credentials, metadata service hardening |
| Software supply chain | Compromised dependencies, build pipelines or front-end assets used to alter transactions | T1195.002 | Pinned dependencies, signed builds, integrity checks on served scripts |
| Insider and outsourced support abuse | Bribed agents export customer data for extortion or targeted fraud | T1213 | Field-level masking in support tools, export alerts, access by case only |
| DDoS | Hacktivist and extortion floods on login and payment endpoints | Not technique-specific | Upstream DDoS protection, graceful degradation of non-critical features |
Regulation by fintech model
Most fintechs are regulated through their licence, through their bank partner, or both. The table lists the regimes that most often apply. Status is as checked in October 2026; confirm current positions with the regulator before relying on dates. See the Financial Services Cyber Regulation Map for the wider set (MAS, APRA, HKMA, RBI, SEC, NYDFS).
| Regime | Who it reaches | Security obligations that matter most |
|---|---|---|
| EU DORA (EU) 2022/2554, applies since 17 January 2025 | Payment institutions, e-money institutions, crypto-asset service providers, investment firms, credit institutions and other financial entities | ICT risk framework, major incident reporting (initial notice within four hours of classification and no later than 24 hours after awareness, 72 hour intermediate, final within a month), resilience testing, register of ICT third-party arrangements. See the DORA Guide. |
| EU PSD2 and RTS on SCA; PSR and PSD3 (provisional agreement November 2025) | Payment service providers, account information and payment initiation providers | Strong customer authentication, dedicated interfaces for third-party access, fraud monitoring; the PSR adds payee checks, fraud data sharing and refunds for defined impersonation fraud |
| EU MiCA, fully applicable from 30 December 2024 | Crypto-asset service providers | Authorisation; grandfathered national providers may continue only until 1 July 2026 or until authorised or refused. See the Crypto Exchange Identity and Key Security Guide. |
| UK FCA PS26/2, rules in force 18 March 2027 | Payment service providers (incident reporting); authorised payment and e-money institutions among others (third-party reporting) | Operational incident reports to thresholds; notify new or significantly changed material third-party arrangements; annual register of material third parties |
| US FTC Safeguards Rule (16 CFR Part 314) | Non-bank financial institutions under FTC jurisdiction, such as lenders, finance companies and mortgage brokers | Qualified Individual, written risk assessment, MFA, encryption in transit and at rest, logging, annual penetration test and six-monthly vulnerability scans unless continuously monitored, service provider oversight, annual board report; notify the FTC within 30 days of a breach affecting 500 or more consumers (since May 2024) |
| US interagency third-party guidance (Fed, FDIC, OCC, June 2023) | Banks, and by contract their fintech partners | Due diligence, contract terms, ongoing monitoring and termination across the relationship lifecycle; the agencies explicitly include fintech relationships |
| US CFPB Personal Financial Data Rights (section 1033) | Data providers and authorised third parties in open banking | Final rule issued 22 October 2024; under reconsideration since an August 2025 advance notice that asks about data security and privacy, so track its status closely |
| PCI DSS v4.0.1 | Any entity that stores, processes or transmits cardholder data | Scope reduction, MFA into the cardholder data environment, script integrity on payment pages. See the PCI DSS 4.0 Guide. |
Priority controls
These are the controls where fintech differs from a general baseline. Implement in the order of the phased plan below.
Customer authentication and account integrity
- Phishing-resistant by default: Offer passkeys or app-bound cryptographic authenticators and treat SMS OTP as a fallback. SMS remains exposed to SIM swap; see the SIM Swap Fraud Guide.
- Protect the high-risk changes: Step up authentication and add a cooling-off delay for new payees, payout account changes, new devices, contact detail changes and limit increases. These are where account takeover turns into loss.
- Dynamic linking: Where SCA applies, bind the authentication to the amount and payee so a phished approval cannot be reused for another payment.
- Identity proofing: Combine document verification, liveness and data checks at onboarding, and re-verify on account recovery. See the Identity Proofing and KYC Guide.
API and application security
- Authorisation per object: Every endpoint that takes an account, card, loan or transaction identifier must check the caller owns it. Build this into a shared library and test it with negative cases in CI. See the API Security Guide.
- Financial-grade API profiles: For open banking and partner APIs, use sender-constrained tokens (mTLS or DPoP) and the FAPI security profiles rather than bearer tokens alone. See the OAuth 2.1, GNAP and FAPI Guide.
- Idempotency and replay protection: Payment endpoints need idempotency keys, signed webhooks and strict timestamp checks. See the Webhook Secrets Security Guide.
- Inventory: Retire old API versions and undocumented partner endpoints; they are where authorisation fixes were never applied.
Cloud, machine identities and keys
- Least-privilege workload roles: The Capital One breach turned a server-side request forgery into data theft because a firewall's cloud role could read storage it did not need. Scope roles per service and require IMDSv2 or the equivalent on every platform.
- No long-lived keys: Replace static cloud access keys and payment provider secrets with workload identity federation and short-lived tokens; vault what must remain and rotate it automatically. See the Secrets Management Guide.
- Protect signing and wallet keys: Keep payment, card and wallet keys in HSMs or managed key services, with dual control for key ceremonies and transaction signing. See the Cryptographic Key Management Guide.
- Developer endpoints are production: In the Bybit case, attackers compromised a Safe{Wallet} developer's laptop, hijacked active AWS session tokens that had already passed MFA, and changed JavaScript served to signers. Restrict who can deploy front-end assets, require signed releases and monitor changes to served code.
Third parties and outsourced operations
- Register and classify: Keep a register of ICT and outsourced service providers with criticality, data held and exit plan; DORA, FCA PS26/2 and bank partners all expect one. See the Third-Party Risk Management Guide.
- Support tool design: Mask identity documents, full account numbers and balances by default in support tools; reveal per case with a reason; alert on volume. Outsourced agents should never be able to export lists.
- Bank partner alignment: Agree incident notification times, evidence sharing and audit rights with the sponsor bank before launch, so your plan matches theirs.
Phased implementation
- Map obligations (month 1): List each licence and partner contract, and the security clauses, testing duties and incident clocks each imposes. Build one severity model that triggers every required notice.
- Close the money paths (months 1 to 3): Step-up and delays on payee and payout changes, payment limits, idempotency and authorisation tests on payment APIs. Run new fraud rules in monitor-only mode for two weeks, compare false positives, then enforce, keeping the previous rule set ready to restore.
- Machine identity clean-up (months 2 to 6): Inventory cloud keys, API keys and CI tokens; remove unused ones; move workloads to federated short-lived credentials one service at a time, with the old key disabled (not deleted) for a rollback window.
- Customer authentication upgrade (months 3 to 9): Launch passkeys to a pilot cohort, measure enrolment and recovery calls, then default new customers to passkeys and migrate existing customers at login.
- Third-party and support controls (months 3 to 9): Complete the register, add masking and export alerts in support tools, and test incident notification with your bank partner.
- Test (yearly and on change): Penetration test APIs and mobile apps at least annually and after major releases; run a tabletop for account takeover at scale and for a compromised cloud key.
Decision guidance
| Decision | Option A | Option B | How to choose |
|---|---|---|---|
| Own licence vs banking as a service | Own e-money or payment licence: direct regulatory duties (DORA, PS26/2), more control | Partner bank: duties flow by contract and examiner scrutiny of the bank | Under a partner model, plan for the bank's examiners to read your controls; evidence quality matters as much as the control |
| Build vs buy fraud detection | Build: tuned to your product, needs data science staff | Buy: faster, consortium data, less transparency | Buy first for card and device signals; build rules for product-specific flows. See the Fraud and Cyber Convergence Guide. |
| SMS OTP vs passkeys | SMS: universal reach, SIM swap and phishing exposure | Passkeys: phishing-resistant, recovery design needed | Default to passkeys; keep SMS only as a recovery fallback with extra checks |
| Screen scraping vs API access for data aggregation | Scraping: stores customer credentials | Token-based API access: scoped and revocable | Use APIs wherever offered; never store customer bank passwords |
Early-stage fintechs should focus on cloud identity hygiene, secrets, payment API authorisation, MFA for all staff and a contracted MDR service. See the Startup Identity and Secrets Security Guide. Scale-ups and licensed firms add a dedicated fraud and security operations function, formal resilience testing, a full third-party register and independent assurance such as SOC 2 Type II or ISO/IEC 27001.
Detection and measurement
- Customer account events: payee additions, payout account changes, device enrolment, recovery flows and limit changes, correlated with login risk.
- API telemetry: authorisation failures per caller, sequential identifier access, unusual volumes per business flow.
- Cloud audit logs: use of access keys from new locations, role assumption chains, reads from storage holding customer data, changes to served front-end assets.
- Support tool logs: record views per agent per hour, reveals of masked fields, exports.
| Metric | Why it matters |
|---|---|
| Fraud losses per £1m or $1m transacted, split by ATO, APP and first-party fraud | Shows whether controls reduce loss, not just alerts |
| Share of active customers on passkeys or app-bound authenticators | Tracks removal of phishable factors |
| Long-lived cloud and API keys older than 90 days | Target zero; each is a Capital One or Bybit style exposure |
| Payment API endpoints with automated object-level authorisation tests | Target 100% |
| Critical third parties with current assessment, contract clauses and exit plan | Required evidence under DORA and bank partner contracts |
| Time to submit a regulator-ready initial incident notice in exercises | Must beat the shortest applicable clock |
Framework mapping
| Area | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | ISO/IEC 27001:2022 Annex A |
|---|---|---|---|
| Regulatory obligations register | GV.OC-03 | PM-9, SA-4 | A.5.31 |
| Customer and workforce authentication | PR.AA-01, PR.AA-05 | IA-2, IA-5, AC-6 | A.5.17, A.8.5 |
| Data protection and keys | PR.DS-01 | SC-8, SC-12 | A.8.24 |
| Third parties and outsourcing | GV.SC-05, GV.SC-07 | SA-9, SR-3, SR-6 | A.5.19 to A.5.22 |
| Testing and vulnerabilities | ID.RA-01 | RA-5, CA-8 | A.8.8 |
| Monitoring and incident reporting | DE.CM-03, RS.CO-02 | SI-4, IR-4, IR-6 | A.8.16, A.5.24 |
Common failure patterns
- SCA treated as the whole fraud answer: authorised push payment fraud succeeds with the genuine customer completing SCA, so payee checks and behavioural signals are still needed.
- Over-privileged cloud roles: the Capital One breach is the classic case of a single role reaching far more data than its function needed.
- Developer sessions trusted as much as production: in the Bybit hack, MFA had already been passed and the stolen session tokens were enough to change what signers saw, leading to a loss of about $1.5 billion.
- Support tools with full data and no limits: in the Coinbase insider breach, bribed outsourced agents copied data on 69,461 customers, with estimated costs of $180 million to $400 million.
- Old API versions left running: the authorisation fix lands in v3 while v1 still serves partners.
- Incident plans that ignore the partner bank: the bank's notification clock may be shorter than yours, and it cannot meet it if you tell it late.
Practitioner checklist
- Map every licence and partner contract to its security, testing and incident reporting duties in one register.
- Add step-up authentication and cooling-off delays on payee, payout, device and contact detail changes.
- Test object-level authorisation on every payment and account API in CI, including retired versions still reachable.
- Use sender-constrained tokens and FAPI profiles for open banking and partner APIs.
- Remove long-lived cloud and payment API keys; use federation and short-lived credentials; keep signing keys in HSMs or managed key services.
- Restrict and monitor who can change served front-end code and deployment pipelines.
- Mask sensitive fields in support tools, remove export ability for outsourced agents and alert on volume.
- Default customers to passkeys or app-bound authenticators with a designed recovery path.
- Exercise incident notification with your bank partner and against the shortest regulatory clock.
Standards and references
- ENISA: Threat Landscape Finance Sector
- FTC: Safeguards Rule, what your business needs to know
- Federal Reserve, FDIC and OCC: Interagency guidance on third-party relationships: risk management
- FCA: PS26/2 Operational incident and third party reporting
- ESMA: Markets in Crypto-Assets Regulation (MiCA)
- CFPB: Personal Financial Data Rights
- OWASP: API Security Top 10 2023
- MITRE ATT&CK: Financial Theft
Related NHI Mgmt Group resources: Financial Services Identity Security Guide · Financial Services Cyber Regulation Map · DORA Guide · Payment Fraud Guide · Web3 and Crypto Security Guide. This guide summarises DORA, PSD2, MiCA, FCA PS26/2, the FTC Safeguards Rule and related US guidance as they affect fintechs and is not legal advice.