The challenge
Four years into operation, the bank had grown fast. Microservices, third-party integrations, multiple mobile app versions, open banking connectors. Engineering shipped constantly and the API estate accumulated with it. Ahead of a DORA compliance review, the security team wanted to establish what their actual API surface looked like before the regulator did.
The answer was uncomfortable. They thought they had around 300 API endpoints. We found 441.
Around 140 additional endpoints: old API versions never decommissioned, internal services exposed externally during development and never pulled back, integration endpoints from partnerships that had since ended. Six had no authentication requirement at all. One of them returned customer transaction history without an auth header.
The credential stuffing problem was running at the same time. Attackers were testing stolen credential pairs against the login endpoint: automated, low-volume, distributed across thousands of residential proxies. Standard rate limiting hadn’t flagged anything. The attacks were visible only in aggregate, across signals no single tool was watching.
And a phishing campaign had been working. The bank’s fraud team had flagged a pattern: customers reporting unauthorised transfers from devices they didn’t recognise, in countries they weren’t in. The credentials were real. The sessions passed every authentication check. Something was logging in after the phishing succeeded and the attacker had valid credentials.
Three separate problems. Each needing a different answer.
The approach
We structured the engagement in two phases: discovery first, then protection. Deploying protection before knowing the full API surface would have left gaps.
API Security
We deployed Akamai API Security across the bank’s traffic. Over two weeks it catalogued every API receiving live traffic — endpoints, methods, request and response schemas, authentication patterns, traffic volumes. The full inventory came to 441 endpoints against the 300 the bank had documented.
The six unauthenticated endpoints were the immediate priority. One returned transaction history. Two were internal administrative APIs exposed on the public hostname. The others were legacy integration endpoints from partnerships that had ended. All six were remediated or decommissioned before the protection phase began.
Discovery also surfaced API behaviour the bank hadn’t been monitoring: endpoints accepting undocumented parameters, one returning more data fields than the API specification described. Neither was being actively exploited. Both were risk that hadn’t been visible before.
App & API Protector
With a complete and verified API inventory, we deployed AAP inline across the full surface. The configuration was built from the schemas surfaced during discovery — AAP’s API protection rules were written against what was actually deployed, not what was documented. Positive security model on the high-value account and payment endpoints. Rate shaping on the open banking connectors.
AAP and API Security feed each other: behavioral anomalies detected by API Security inform AAP’s inline blocking rules, closing the loop between discovery and enforcement.
Bot Manager Premier
We deployed BMP on the authentication endpoints. It classified the credential stuffing traffic within hours. The tooling had consistent TLS fingerprints and HTTP/2 patterns that persist regardless of IP rotation. Based on log analysis, the attack had been running for at least six weeks. It stopped the day BMP went active.
Account Protector
We deployed Account Protector on the post-authentication session layer. It builds a per-user behavioural profile — typical devices, locations, login times, transaction patterns — and scores each session against it in real time via a risk header passed to the bank’s application. High-risk sessions trigger step-up MFA rather than a hard block, keeping the experience intact for legitimate users while stopping attackers who have valid credentials but can’t complete the MFA challenge.
The phishing-driven account takeover attempts showed up in the data straight away. A typical flagged session: login from an unrecognised device in a new country, no session history on that device, followed within seconds by an attempt to initiate a SEPA transfer above €5,000. Account Protector scored these sessions above the step-up threshold. The transfers didn’t go through.
In the first month, Account Protector flagged 89 high-risk sessions for step-up authentication. The bank’s fraud team confirmed 31 as active fraud attempts. Zero completed.
The results
After full deployment, no fraudulent transaction completed. Credential stuffing stopped entirely on day one of BMP going active. The bank’s API surface was documented, protected, and monitored for the first time since it was built.
The DORA review found no findings on API security. The six unauthenticated endpoints, including the one serving transaction history, had been closed three months before the review date.
Legitimate customers were unaffected. Normal sessions passed without friction. No step-up challenges triggered on routine behaviour, no degradation in the mobile app.
What made it work
The sequence mattered. API Security came first because you cannot protect what you do not know exists. Deploying AAP on an incomplete inventory would have left 140 endpoints outside the policy. The discovery phase wasn’t a formality; it changed what the protection configuration looked like.
The four products cover different threat surfaces:
API Security finds what’s there. AAP blocks what’s targeting it. BMP stops the bots. Account Protector catches the humans who got through with valid credentials anyway.
Stopping credential stuffing stops one vector for account takeover. When phishing works, the attacker has real credentials and arrives in a human session that no bot detection will flag. That’s the gap Account Protector closes. In a digital bank, where a single fraudulent transfer can run to five figures, it’s not a gap worth leaving open.