Web Application Firewall: Why Default Rules Aren't Enough for Fintech

A WAF running on default rules is better than no WAF. I’ll say that upfront, because what follows isn’t an argument for ripping out what you have. It’s an argument for understanding what it actually covers.

The default rule sets that ship with enterprise WAF platforms are designed to protect a generic web application against known, well-documented attack patterns. They do that reasonably well. What they don’t do is account for what makes your fintech platform different from a generic web application: the payment flows, the regulated data, the authentication patterns, the API surface, and the specific attack vectors that come with operating in a sector attackers find financially lucrative.

The threat picture in 2026 is no longer abstract. Akamai’s May 2026 State of the Internet report on financial services found that the median duration of Layer 3/4 DDoS attacks against the sector is up 738% since 2024. 96% of financial services leaders reported at least one API security incident over the past 12 months, the highest rate of any industry. In 2025, banking accounted for 60% of total web attacks and 83% of attacks against API endpoints. Running a WAF on defaults and calling it done is a reasonable starting point. It’s not a finished security posture for a platform operating in that environment.

What default rules actually cover

WAF default rule sets are built around taxonomies like the OWASP Top 10 and CVE databases. They block known SQL injection signatures, cross-site scripting patterns, path traversal attempts, and requests matching signatures from published exploits. The OWASP Top 10 itself was refreshed in late 2025, the first update since 2021. Security misconfiguration moved up to #2, software supply chain failures was added as a new category, and rule sets calibrated against the old list have catching up to do even at the baseline.

That coverage is real. These attack classes account for a large portion of opportunistic attacks: the automated scanners and script-kiddie toolkits that probe every target indiscriminately. For a lot of web applications, blocking those is the bulk of the relevant threat.

Fintech platforms aren’t only facing opportunistic attacks. They’re facing targeted ones, from fraud operations with specific financial objectives, from organised groups who have researched the platform, from hacktivist campaigns increasingly powered by AI. Akamai’s 2026 research found a 147% surge in advanced bot activity during late 2025, with one case study where 96% of all site traffic was identified as malicious scraping bots. Targeted attackers don’t use the payloads OWASP rules were written to catch. They probe for gaps, they customise their requests, and they’re patient.

Default rules also don’t know anything about your application’s business logic. They can identify a textbook SQL injection. They can’t identify a request that exploits a legitimate API endpoint in a way that extracts data it shouldn’t, because that request looks syntactically valid. Business logic attacks are the gap between “what the WAF rules block” and “what can actually hurt you.”

“But doesn’t Akamai’s AI handle all this?”

I get this question a lot, and it’s a fair one. Anyone running App & API Protector has been told the platform tunes itself.

It largely does, and the technology behind it is good. Akamai’s Adaptive Security Engine (ASE) is the ML layer inside App & API Protector. It analyses every security trigger across Akamai’s traffic, generates per-policy tuning recommendations, and pushes signature updates for new CVEs and zero-days without you lifting a finger. Akamai’s own numbers put detection improvements at 2x and false positive reduction at 5x compared to manual tuning. The Behavioral DDoS Engine handles volumetric anomalies with its own scoring model. API Discovery surfaces shadow endpoints you didn’t know were exposed. For the work of keeping a generic WAF in good shape, ASE removes most of the toil.

What ASE doesn’t do is know what your application does.

ASE tunes against the rule set it’s given. It doesn’t decide that your /transfer/initiate endpoint should have tighter rate limits than your /help/faq endpoint, because that classification depends on understanding which endpoints are sensitive in your business, not which endpoints attackers happen to be hitting. It doesn’t write a rule that says “flag any session where a new beneficiary is added within 30 seconds of login from an unrecognised device,” because that’s a fraud signal derived from your application’s logic, not an attack signature derived from traffic patterns. It can’t tell you that the /internal/reconcile endpoint your batch job hits at 02:00 every night should be excluded from a specific bot detection rule, because it doesn’t know that endpoint is internal in the first place.

The same is true of every WAF vendor’s AI layer. None of them have a model of your business logic, because your business logic isn’t in the training data.

There’s a defender-vs-attacker dynamic worth naming too. Akamai’s 2026 SOTI attributes the 738% jump in median DDoS duration partly to AI-powered attacker infrastructure running longer, more adaptive campaigns. ASE is good. The attackers are also using ML. Whatever ground the platform’s automation gains, the threat side is moving too.

So: is the AI enough? It’s enough for the parts of WAF management that look the same across every customer. The parts specific to your platform (endpoint classification, business logic rules, exceptions for your real traffic patterns) still need someone who understands both the platform and your application.

The gaps that matter most in fintech

Payment flow endpoints aren’t treated differently

Your payment processing endpoints are the highest-value target on your platform. A successful attack against them has direct financial consequences. They also tend to have complex request structures (multi-step flows, tokenised card data, callbacks, webhooks) that generic WAF rules weren’t written to model.

Default configurations typically apply the same rule set uniformly across the application. There’s no concept of “this endpoint handles card data and should have tighter controls, more aggressive anomaly detection, and different logging behaviour.” Building that requires understanding your own endpoint map well enough to apply differentiated policies, which is tuning work, not default configuration.

Legitimate fintech traffic looks unusual to generic rules

Financial applications generate request patterns that look suspicious to a rule set calibrated for generic web traffic. Automated reconciliation processes, high-frequency API calls from internal systems, batch operations during off-peak hours, payment processor callbacks from known IP ranges — all of these can trip generic anomaly detection rules. The result is false positives that either create noise or, if you’ve set your WAF to block rather than alert, disrupt legitimate operations.

What I usually see when a fintech team turns on a new WAF in blocking mode with default rules is a flurry of false positives in the first week, followed by a decision to put the WAF into detection-only mode “until we have time to tune it properly,” and then years later nobody has time. The protection ends up mostly theoretical. And since DORA came into force, that’s not only a security compromise. A WAF that can’t separate a real attack from routine batch traffic is a WAF that slows down the one thing the regulation now puts a clock on: deciding whether you’re looking at a reportable incident.

Getting to reliable blocking mode requires tuning the rule set against your actual traffic patterns. It’s not a one-time task. You iterate through false positive categories, build exceptions for legitimate but unusual traffic, and test changes before deploying them.

No coverage for credential abuse patterns specific to financial services

Account takeover in fintech goes beyond compromised credentials. It’s about what happens after: fund transfers, beneficiary changes, payment method additions. The attack patterns targeting these post-authentication flows are specific to financial services, and they’ve gotten harder to spot as AI-driven account takeover attempts have scaled.

A generic WAF rule set doesn’t have signatures for “authenticated user added a new payment destination immediately after login from a new device in a geography they’ve never used before.” That’s a fraud signal, not a WAF signal in the traditional sense. But the WAF layer, or more precisely an application security layer that integrates WAF capabilities with behavioural analytics, is where you build the controls to catch it.

Fintech platforms that handle this well typically have custom rules that combine authentication events, session context, and request patterns into detection logic specific to their own fraud patterns. That work can’t ship from a vendor’s default config.

API and microservices surface

Most fintech platforms have grown their API surface faster than their WAF rules have kept up with it. New microservices get deployed, new endpoints get added, and the WAF configuration that was set up 18 months ago still reflects the application architecture from that time.

The result is coverage drift: WAF policies that were reasonably well-matched to the application at deployment, but now have gaps where new endpoints aren’t covered or are covered by rules that don’t reflect how they actually behave. Akamai itself flagged this pattern in its 2026 financial services report, where shadow APIs and undocumented endpoints emerged as one of the most exploited entry points in the sector.

This is common enough that it’s almost a default state for fast-moving fintech teams. The problem compounds over time, and the longer it goes unaddressed, the more work catching it up becomes.

What proper WAF tuning looks like in practice

Tuning a WAF for a fintech environment isn’t a project with a fixed endpoint. It’s a continuous process with a few key phases.

Baseline and discovery

Before changing anything, understand what your WAF is currently seeing. Which rules fire most often? What’s the false positive rate? Which endpoints generate the most triggers, and how does that compare to actual confirmed attacks?

Most teams that haven’t looked at this recently are surprised by what’s in the data. Rules that haven’t fired in three years sitting next to rules that fire hundreds of times daily on legitimate traffic, and endpoints with no coverage at all. The baseline is where you find out what you’re actually working with.

Endpoint classification

Map your application’s endpoints by risk level and data sensitivity. Payment processing, authentication, account management, data export: these sit in a different risk category than your help centre or marketing pages. Once you have that map, you can apply differentiated WAF policies that concentrate protection where it matters.

For Akamai’s Kona Site Defender (and its newer App & API Protector platform, which extends the same protection model with an upgraded ML engine and hybrid deployment support), this means configuring separate security policies per hostname or path, with different rule sets, sensitivity levels, and response actions based on the classification of each endpoint. That configuration is more complex than a single global policy, but it’s the difference between protection calibrated to your application and protection that treats everything the same.

Custom rule development for business logic

The gaps that matter most, the ones targeting your specific payment flows, your account management logic, your API behaviour, require custom rules. These aren’t rules you can download from a threat feed. They require someone who understands both your application and the attack patterns relevant to your sector.

Custom rules for fintech WAF configurations typically cover things like rate limiting per authenticated user on high-risk endpoints (not just per IP), detection of scraping patterns against your pricing or product data, request sequence validation for multi-step payment flows, and geographic anomaly detection for authenticated sessions.

Writing good custom rules requires access to real attack data, which is another reason why working with a partner who operates across multiple fintech environments is useful. The rule patterns that catch attacks on one platform tend to be relevant to others in the same sector.

Testing before blocking

Every rule change in a production WAF is a potential false positive. The correct workflow, which is less common than it should be, is to deploy new rules in detection mode first, monitor against real traffic for a defined period, address any false positives through exceptions or rule refinement, and only then promote to blocking mode.

The temptation to skip this and go straight to blocking is understandable when the rules address a known attack. Resist it. A false positive on your payment endpoint during business hours is its own incident.

Making the case for WAF investment internally

The challenge with WAF tuning as a budget line is that it’s defensive spending whose value is invisible when it works. You’re not buying a feature; you’re reducing a risk that may never materialise in a visible way.

The framing that tends to work with fintech boards: what’s the financial exposure from the attack patterns this tuning is designed to catch? A business logic attack that extracts customer payment data has a cost, including regulatory penalties, breach notification, remediation, and reputational damage. Under GDPR, the most serious violations can be fined up to €20 million or 4% of global annual turnover, whichever is higher, and violations related to data security and integrity sit in a lower tier capped at €10 million or 2% of global turnover. Real breaches often trigger multiple articles at once, so the upper tier is not a theoretical ceiling. The largest GDPR fine to date is €1.2 billion, imposed on Meta Platforms Ireland in May 2023.

GDPR is the exposure most boards already know about. The one that’s caught fewer fintech teams off guard than it should is DORA, the EU’s Digital Operational Resilience Act, which has applied directly across all 27 member states since January 2025. DORA isn’t primarily a data-protection regime; it’s about operational resilience, and it puts a hard clock on incident reporting. Once you classify an ICT incident as major, you have four hours to send the initial notification to your competent authority, and no later than 24 hours from when you first became aware of it. That makes it the most time-sensitive obligation in the regulation, and the clock starts at detection, not at the point your compliance team gets looped in.

This is where WAF tuning stops being a purely technical concern and becomes a compliance one. You can’t classify an incident in four hours if your security layer can’t tell you, quickly and reliably, whether what you’re seeing is an attack or a payment processor behaving normally. A WAF parked in detection-only mode because nobody tuned it, or one buried in false positives, leaves you exposed to the attack while also slowing down the clock you’re now legally required to beat. The gaps that weaken protection are the same ones that weaken your ability to report on time, and DORA’s four-hour window runs a lot faster than GDPR’s 72-hour one.

So the ROI case is straightforward. A WAF tuning project costs a fraction of a percent of revenue to execute, and it reduces the probability of a regulatory event with seven- or eight-figure exposure while also protecting your ability to meet the reporting deadlines that come with one. The hard part isn’t the maths. It’s getting someone to do the exposure calculation honestly, which means acknowledging that the current configuration has gaps.

Default rules will get you started. Self-tuning AI will take you further than that. For a fintech platform in 2026, with banking now the most-targeted sector for web and API attacks and DDoS campaigns running longer than they ever have, I’d argue that neither is sufficient on its own. Not because the vendors wrote bad rules or built weak models. The threat environment is more specific than what generic rule sets and generic ML can model. The gap between “running defaults with ASE” and “properly tuned for your application” is a project, not a rebuild. It needs time, access to your traffic data, and someone who understands both the WAF platform and your application well enough to write rules that hold up in production without firing every time the payment processor calls a webhook.