PASTA Threat Modelling for Real Banking Systems: The Add-Beneficiary & Fund-Transfer Walkthrough

Threat modelling has a reputation problem. Too many diagrams. Too many "security says no" meetings. Too theoretical to survive a quarterly delivery cycle. Yet every Indian retail bank, NBFC, and payment aggregator runs the same handful of flows that get compromised the same handful of ways — and not because the encryption was weak. Because the assumptions between systems were never written down, never challenged, and never tested.

PASTA — Process for Attack Simulation and Threat Analysis — is the seven-stage methodology designed to fix exactly this. It's risk-centric (not control-centric), evidence-driven, and produces output that survives a SEBI inspection, an RBI IT examination, and a CFO budget review. This walkthrough applies all seven stages to the single most fraud-targeted flow in Indian banking: add a new beneficiary, then transfer money.

Why Banking Teams Should Pick PASTA Over STRIDE Alone

STRIDE is a fine threat taxonomy (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege). It tells you the kinds of threats. It does not tell you whether they matter to your business, your regulators, or your CFO's risk register. PASTA wraps STRIDE inside a business-impact framework: every threat is traced to a business objective, a regulatory mapping, and a quantified risk decision.

The Scenario, In One Diagram

A retail customer opens the mobile app, logs in, adds a new payee (account number + IFSC), waits out the cooling-off window, and transfers funds. Behind that two-tap experience sits an authentication service, an OTP / step-up provider, a fraud-and-risk engine, the core banking ledger, an alert pipeline, and at least one external rail (NPCI / NEFT / RTGS / IMPS).

User simplicity is built on system complexity. Fraudsters don't break encryption — they exploit assumptions between systems.

Before listing threats, write down what the flow exists to do — in business terms, not control terms. For an Indian retail bank, the add-beneficiary + transfer flow exists to:

• Drive digital transaction volume (vs. branch / call centre)
• Defend against fintech disintermediation
• Meet RBI's digital adoption targets and the bank's own NPS goals
• Operate under DPDP, RBI Cyber Framework, and SEBI CSCRF (for capital-market entities)

Loss-event quantification at this stage matters: what is the cost of a single successful fraud (direct loss + RBI ombudsman settlement + churn + brand)? What is the cost of a 12-hour outage during a settlement window? Pair this with FAIR to get a rupee number for each scenario — without it, every threat looks "high".

Systems in scope for "add beneficiary + transfer" almost always include more than the AppSec team initially lists:

• Mobile app (Android / iOS) and the web equivalent
• API gateway / WAF / rate-limiter
• Authentication service (session, MFA, device binding)
• OTP / step-up provider (SMS aggregator, push, email)
• Fraud / risk engine (velocity, ML scoring, watchlist)
• Core banking system (beneficiary store, ledger, limits)
• Settlement rails (NEFT, RTGS, IMPS, UPI back-end)
• Logs, SIEM, alerting, and customer-support tooling

The "support tooling" line is the one that gets skipped — and the one CSAs (Customer Support Agents) get socially engineered through. If a CSA can lift a hold on a beneficiary, that capability is part of the threat model.

Decompose the user journey into discrete steps and the data each step writes:

The trust transition column is where the threats live. Each transition is an authentication, authorisation, or integrity decision — and each is a place where the next stage's threats actually land.

Realistic threat actors against an Indian retail bank's transfer flow:

STRIDE catalog mapped to the flow

The vulnerabilities most often surfaced when this flow is threat-modelled honestly:

• Beneficiary creation does not require step-up — only the eventual transfer does. The state change is the attack surface, not the money movement.
• OTP scope is broad — the same OTP authenticates "add beneficiary" and "transfer", or worse, is reused across sessions.
• Cooling-off can be lifted — a CSA or maker has a "remove hold" button with insufficient checker enforcement.
• Velocity rules count attempts, not behaviour — ten ₹49,000 transfers to a fresh beneficiary do not trip a threshold built around "amount > ₹50,000".
• Logs exist but alerts arrive after settlement — the SIEM has the event; the SOC sees it 18 minutes after NEFT clears.
• Device binding is suggestion, not enforcement — the same customer ID can transact from a "new device" with only OTP friction.

Vulnerabilities by themselves don't fund a money-mule operation. Chained vulnerabilities do. The attack tree below shows three sub-goals an adversary must satisfy — and at least one viable leaf under each.

The end-to-end fraud narrative

1. Credentials are bought from a stealer-log market — the bank never sees the breach.
2. SIM swap is initiated through a telco social-engineering attack timed to a public holiday evening.
3. Attacker logs in, adds a beneficiary controlled by a money mule, completes the OTP step.
4. Cooling-off window passes uneventfully — nothing on the SOC console suggests review.
5. Three transfers of ₹49,500 are issued to the new beneficiary across 22 minutes.
6. Mule withdraws cash at three ATMs in a different state. Fraud SIEM alert fires at minute 41.
7. By the time the SOC analyst opens the ticket, NEFT settlement has cleared.

Risk-prioritise the findings using likelihood × impact, and pick the controls that disrupt the most attack-tree leaves with the least conversion cost:

One control — step-up authentication at beneficiary creation — disrupts six of the nine attack-tree leaves with negligible UX cost. That is risk-aware design.

Mapping PASTA Output to Indian Regulations

A threat model that sits in a Confluence page is a science project. A threat model that maps each finding to a regulatory control is an audit deliverable. Indian BFSI regulators expect — and increasingly inspect for — this traceability:

Why Manual PASTA Stalls in Real Programmes

Every BFSI security team we've worked with runs into the same five blockers when trying to make PASTA a recurring practice:

• It's authored once, never refreshed. The doc ages out within a release cycle.
• Findings live in slides, controls live in JIRA. Traceability dies on the first hand-off.
• No quantification. Every finding is "high"; CFOs disengage.
• Regulator mapping is manual. Every audit re-derives the same SEBI / RBI cross-walk.
• Detection rules don't trace back. The SOC chases alerts that aren't tied to threat-model leaves.

Practitioner Checklist — Bring This Into Your Next Sprint

• Pick one high-fraud flow (add-beneficiary + transfer is a strong starting point).
• Run all seven stages in a single working session — deliberately rough.
• For each finding, write the regulator clause and the FAIR scenario it maps to.
• Pick one control that disrupts the most attack-tree leaves and ship it the same quarter.
• Re-run the model on the next major release. The first refresh is where PASTA earns its keep.