Threat-Model a Fintech System, Not a Web App

You run the OWASP Top 10 against your fintech codebase. Broken access control, check. Injection, check. Cryptographic failures, check. You file the report, pass the SOC 2 audit, and move on.

Six months later, a timeout in your payment API causes a retry. The retry succeeds, and so did the original request. A customer's bank account gets debited twice, $2,500 instead of $1,250.

Your support team catches it on Monday morning.

OWASP didn't warn you about this. It wasn't designed to. The Top 10 was built for web applications, and the threat that just cost your customer real money has no web-application analogue.

Where OWASP stops

The OWASP Top 10 covers vulnerability classes that affect any web-facing application: injection, broken authentication, server-side request forgery, security misconfiguration. These are real risks in fintech systems too. A01, Broken Access Control, is probably the single most dangerous web vulnerability in a multi-tenant fintech because it can expose one customer's financial data to another.

But OWASP asks one question: can an attacker compromise the application?

A fintech threat model needs to ask a different question: can this system move money incorrectly? A system with perfect OWASP scores can still double-disburse, fabricate balances, or settle against stale sanctions data. The vulnerabilities that OWASP misses live in the money path, not the application layer.

The threats OWASP doesn't have a category for

Double disbursement. A payment API times out, the client retries, both requests succeed, and the customer loses money twice.

The system did exactly what it was designed to do. The design just didn't account for the fact that a timeout doesn't mean a failure.

The mitigation is idempotency keys at the ledger level, not the API level. An API-level deduplication that checks "did I see this request ID before" catches retries from the same client. A ledger-level deduplication that checks "did I already post this entry" catches retries from any source, including retries generated by internal queue processors, webhook handlers, and batch reconciliation systems.

Balance fabrication. Your system queries a third-party adapter, a bank API, a processor, a balance aggregator, and makes a disbursement decision based on the response. If that adapter is compromised or returns stale data, your system disburses against a balance that doesn't exist.

The trust boundary here is between your system and any external data source whose response triggers a financial decision.

Ledger tampering. OWASP's Software and Data Integrity Failures category covers the general class. But it frames the problem as "can an attacker modify data in transit or at rest."

In a fintech system, the specific risk is whether a malicious insider can modify the audit trail. A ledger entry that changes after posting doesn't just corrupt data. It makes the financial record unreliable for regulators, auditors, and dispute resolution. Append-only data structures and hash-chaining mitigate this, but only if the ledger is designed as immutable from the start.

Fee manipulation. A transaction is priced at 2.9% when the customer authorizes it. Between authorization and settlement, the fee changes to 3.5%. This can happen through configuration drift, a race condition in the pricing service, or deliberate manipulation by a compromised internal service. The gap between "fee calculated" and "fee charged" is a trust boundary that most threat models don't draw.

Sanctions screening staleness. You screen a recipient against the OFAC SDN list before disbursing. Your screening data was last updated 72 hours ago. In those 72 hours, the recipient was added to the list. You disbursed to a sanctioned entity using data that was accurate when you fetched it and wrong when you used it.

Webhook forgery. Your system receives a webhook from a processor confirming that a payment settled and credits the customer's balance. If that webhook was forged, the payment never actually settled, and you just created money from a POST request.

Webhook signature verification is the basic mitigation, but the deeper issue is that webhooks are trust boundaries that your system treats as ground truth.

How to apply STRIDE to money

STRIDE, Microsoft's threat classification framework, gives you six categories: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. The framework works for fintech systems, but only if you apply it to the right components.

Most teams run STRIDE against the application as a whole. For a fintech system, you need to run it against each component in the money path separately, because the threat profile changes at every trust boundary the money crosses.

The payment API has spoofing risks: can an attacker impersonate a legitimate client and initiate a transfer? The ledger carries tampering risks around whether entries can be modified after posting. And the settlement layer introduces repudiation risks, where the processor can deny it received your payment instruction, or you can deny you sent it.

Each component has different actors, different attack surfaces, and different mitigations. Draw your trust boundaries where money changes hands or where data crosses system ownership. Your API gateway, your processor integration, your bank connection, your webhook endpoints, and the boundary between your application and your ledger are all places where STRIDE should run independently.

What a fintech threat model actually looks like

A web application threat model starts with assets like user data, sessions, and credentials, then asks who can access them. A fintech threat model starts further downstream, at the money path itself, and asks what can go wrong at each step.

Map the money path. Trace every route money takes through your system, from the moment a customer initiates a transaction to the moment it settles in a bank account. Include the retry paths, the failure paths, and the reconciliation paths. The threat surface is the entire path, not just the happy path.

Identify the actors. Web threat models typically list external attackers, authenticated users, and administrators. A fintech threat model adds: compromised third-party integrations (processors, bank APIs, KYC providers), malicious insiders with ledger access, and your own system acting on stale or fabricated data.

Some of the most dangerous fintech threats come from components operating exactly as designed with inputs nobody anticipated.

Draw trust boundaries. Every point where data crosses ownership, from your system to a processor, from a processor to a bank, from a webhook to your ledger, is a trust boundary. Each boundary needs independent validation. A webhook from Stripe is trusted differently than a webhook from a white-label partner, and your system should enforce that difference.

Run STRIDE per component. Take each component in the money path and run all six STRIDE categories against it. Most will be empty. A few will surface risks you hadn't considered. The combination of ledger tampering and repudiation creates a scenario where a modified entry can't be attributed to anyone because the audit trail itself was altered.

Document residual risk. Every mitigation leaves a residual risk. Idempotency keys prevent duplicate disbursements but introduce a new risk: what happens when a legitimate retry is incorrectly deduplicated and a payment never settles? Document what you chose not to mitigate and why. This is the part SOC 2 auditors care about most, and bank partners will read it before they approve your integration.

Why the auditor won't catch it

SOC 2 requires a risk assessment under Trust Services Criteria CC3.2. It does not require a document called a threat model. Most fintech companies satisfy CC3.2 with an OWASP-based assessment, a penetration test report, and a vulnerability management policy. The auditor checks the box.

Your bank partner is the more demanding reviewer.

When a bank runs a security review before approving your integration, they ask questions that OWASP doesn't prepare you for. How do you prevent duplicate ACH debits? What happens if your balance check returns stale data? Can an internal engineer modify a ledger entry after it posts? How often is your sanctions screening data refreshed?

These questions target the money path. A threat model that only covers the application layer will leave you scrambling to answer them. The maker-checker pattern that banks use for high-value operations exists precisely because application-level controls are necessary but not sufficient.

Passing a bank security review on the first attempt means having already threat-modeled the money, not just the app.