CISO's Guide to API Security in Financial Services

How packet-derived evidence powers modern API defense for banks, insurers, and payment institutions

May 3, 2026

APIs Have Outgrown the Controls Protecting Them

APIs are now the connective fabric of every financial transaction. They link core banking systems with digital channels, insurers with partner networks, payment switches with fintech ecosystems, and every internal microservice with the next. They are also the fastest-growing attack surface in the industry.

Akamai documented 150 billion API attacks globally between January 2023 and December 2024, with 87% of organizations experiencing an API security incident in 2025, and daily API attacks per organization surging 113% year-over-year. According to the May 2024 Gartner Market Guide for API Protection, the average API breach leads to at least 10 times more leaked data than the average security breach.

The number that should worry every CISO: only 27% of enterprises have a complete API inventory that also identifies which APIs return sensitive data — down from 40% the year before. Radware's research adds a sharper edge: 84% of credential-stuffing scripts now target API endpoints, 26% of API-targeted attack configurations focus on older API versions, and only 6% of organizations maintain full documentation of all APIs.

Where Aviz Fits in the API Security Stack

Modern API security is not a single control. It is a layered system, and each component sees a different slice of reality. WAFs inspect North-South traffic in the application path. API gateways enforce policy on registered APIs authentication, routing, rate limits. API security platforms analyze schemas, behavior, and runtime posture. Agents and MELT data reflect what applications choose to expose. Each is necessary. Each is scoped by design to traffic that passes through it, workloads where it is deployed, or APIs that are formally registered.

Aviz Deep Network Observability operates below and across these controls, not in competition with them. The architecture is built to source traffic directly from the network fabric itself across on-premises, data centers, hybrid, multi-cloud, Kubernetes, and containerized workloads via SPAN, physical, and virtual taps as illustrated on Figure 1. This is not a single insertion point. It is a distributed collection layer across every environment where APIs exist.

Network and security components help, but each has its own scope and blind spots.

Because of this, Aviz observes what no single perimeter or registered-traffic control can see on its own: North-South traffic alongside the WAF; East-West service-to-service API calls that workload-to-workload conversations and container-to-container flows are made of; shadow and unmanaged APIs that never registered with a gateway; and outbound API consumption, including third-party services and AI endpoints.

This architecture changes the role Aviz plays in the stack. It is not another control point. It is a continuous evidence layer that validates what WAFs and gateways are actually seeing, exposes what they are structurally not positioned to see, and feeds ground-truth data into SIEM, NDR, fraud, and API security platforms already in the stack. WAFs and gateways enforce policy on known traffic. Aviz delivers visibility into what is actually happening across all traffic strengthening every control above it, replacing none.

How Aviz DNO produces API-aware evidence

Figure 1: Aviz Deep Network Observability Intelligent Stack

### To produce this level of audit-ready evidence, architecture matters

Aviz Deep Network Observability is a five-stage pipeline - Capture → Normalize → Enrich → Stream → Integrate - running on open white-box switches and commodity x86 with DPU-native acceleration up to 400G. TAP or SPAN traffic from hybrid cloud, data center, branch, and IT/OT is normalized, enriched with Deep Packet Inspection, and converted into structured, packet-level metadata — including HTTP method, URL, host, headers, response codes, TLS version and cipher, source and destination, bytes, and timing for every API call.

Aviz is vendor-agnostic by design and streams enriched metadata in open formats (JSON and Kafka) into whichever observability or SIEM platform you already run — Splunk, Elastic, Datadog, Dynatrace, New Relic, Kentik, Chronicle, Sentinel, and others. The dashboards shown in this guide can be rebuilt natively in any of these platforms - the visualizations are downstream of the metadata, not the other way around. For customers who want a turnkey experience, Aviz also offers an Elastic Node visualization platform bundled with the pipeline. The packet-derived metadata and the API security evidence it produces are the same either way.

PCI-DSS 4.0 control mapping at a glance

| Requirement | What it demands | Aviz DNO Evidence (Packet-Derived App Metadata) |
| --- | --- | --- |
| 1.2.6 / 2.2.5 | Detect insecure services and protocols | Network-Insights: live protocol and application distribution |
| 4.2.1 | Strong cryptography in transit | SSL-Insights: TLS version and cipher suite per session |
| 4.2.1.1 | Certificate inventory and validity | SSL-Insights: issuer, common name, expiry |
| 5.2.2 / 5.3.2 | Detect malware behavior on the network | DNS-Insights: raw DNS query telemetry feeding NDR / SIEM detection |
| 6.4.1 | Public-facing web app protection | Public-facing web app activity / App-Insights: HTTP error, URL, server, and session telemetry |
| 8.3.2 | Strong cryptography for authentication | SSL-Insights: TLS posture on auth endpoints |
| 10.2 / 10.3 | Audit logs for all access | Timestamped flow, session, query records |
| 11.5 | Intrusion detection on the network | Enriched telemetry streamed to SIEM & Optimized traffic to NDR/IDS |
| 12.3.1 / 12.5.2 | Targeted risk analysis and scope review | Gen-AI Insights: Shadow AI vs. sanctioned AI traffic visibility |
| 12.3.3 | Document cipher suites and protocols in use | SSL-Insights: continuous cipher inventory |

SSL-Insights Strong Cryptography for Data in Transit (Req 4)

Addresses: 4.2.1 (strong cryptography in transit), 4.2.1.1 (certificate inventory and validity), 8.3.2 (cryptography for authentication), 12.3.3 (documented cipher inventory)

Figure 2: SSL Insights Derived from Network Packets with Aviz Elastic Node

This is the single most important tab in the dashboard for a PCI audit. It provides a live, continuously updated answer to the most-asked question in every audit review: can you prove strong cryptography is in use, and can you prove deprecated protocols and expired certificates are not?

This is where most PCI audits begin and fail

TLS version distribution exposes, at a glance, every protocol version negotiated on the network. Any presence of TLS 1.0 or 1.1 both explicitly prohibited under PCI-DSS 4.0 Req 4.2.1 surfaces immediately, as does any lingering SSLv3 or early TLS. The question moves from "I hope we've deprecated old TLS" to "here is exactly where it still exists and how much traffic it carries.**

Cipher suite ranking shows which cipher suites are actually in use across the environment. The value of this panel is twofold it confirms that strong, NIST-approved suites dominate, and it flags the moment a weak suite reappears. RC4, 3DES, export-grade ciphers, or any cipher subject to known cryptographic vulnerabilities would show up here, at the session level, against a specific app server. That turns Req 12.3.3 (documented cipher inventory) from an annual manual exercise into a continuous, evidence-backed stream.**

Certificate status is the most revealing panel on the dashboard. It breaks down every certificate observed on the wire into three buckets valid, expired, and self-signed and makes it immediately obvious how each bucket is trending. Certificate lifecycle is one of the most silently failed controls in financial services. Certificates issued for partner integrations, legacy middleware, and forgotten endpoints pile up until an outage or an audit finds them. Req 4.2.1.1 requires financial institutions to confirm certificates used for PAN transmission are valid. Aviz turns that from a periodic manual inventory into a continuous passive stream.**

The SSL/TLS Stats table below the charts is the actual audit artifact every row records App Server IP, SNI, SSL version, Issuer, Common Name, Cert Expiry, and Flow count. Filtered to in-scope systems, exported to the evidence store, and signed off by the auditor.

App-Insights Secure Systems and Audit Logging (Req 6 & Req 10)

Addresses: 6.4.1 (public-facing web application activity), 10.2 (audit log content), 10.3 (audit log details and integrity)

Figure 3: App Insights Derived from Network Packets with Aviz Elastic Node

Req 6.4.1 requires protection for public-facing web applications online banking portals, mobile API gateways, and card payment pages. Aviz App-Insights delivers a network-layer view of every HTTP transaction on the monitored path: top URLs, dominant HTTP server agents, response code distribution, and content-type mix.

For PCI evidence, two patterns matter: HTTP error spikes (a sudden rise in 401s or 403s can signal credential-stuffing against a payment page) and unexpected server agents (a new Server: header inside the environment can indicate shadow infrastructure). The HTTP Stats table records every transaction with timestamp, source IP, hostname, URL, response code, and user agent Req 10.2 and 10.3 audit logging at the network layer, with zero application-side instrumentation.

DNS-Insights Malware Detection and Access Monitoring (Req 5 & Req 10)

Addresses: 5.2.2 (anti-malware coverage), 5.3.2 (continuous behavioral analysis), 10.2 (audit log content), 11.5 (network intrusion detection)

Figure 4: DNS Insights Derived from Network Packets with Aviz Elastic Node

DNS is the protocol every attacker uses, and almost no PCI programme actively monitors. Most malware uses DNS for command-and-control. Most data exfiltration begins with a DNS query to an attacker-controlled domain. Req 5 anti-malware controls are usually treated as endpoint-only, but the network sees what the endpoint misses.

Aviz DNS-Insights records every query crossing the network query type, resolver used, domain requested, and resolved IP. Anomalies surface naturally: a spike in queries to an unfamiliar resolver, an internal host bypassing the corporate resolver, or a sudden burst of queries to newly registered domains all stand out against an established baseline. Each pattern is an immediate Req 11.5 signal that gets streamed straight to the SIEM or NDR.

The DNS-Stats table is a continuous log of every outbound name resolution from inside the environment timestamp, destination IP, query type, domain name, and resolved IPv4. That is Req 10.2 and 10.3 evidence for the one protocol that rarely appears in conventional audit log streams.

Network-Insights Network Security Controls and Scope (Req 1 & Req 2)

Addresses: 1.2.6 (security features for insecure protocols), 2.2.5 (justifying insecure services), 10.2 (audit log content), 11.5 (network intrusion detection), 12.5.2 (annual scope review)

Installing network security controls (Req 1) and applying secure configurations to system components (Req 2) are the foundational requirements of PCI-DSS 4.0 controlling which services and protocols are allowed into and out of the environment, and justifying any insecure ones still in use. Network-Insights shows live traffic distribution by application and by protocol alongside top sources and destinations, giving a real-time picture of what is actually flowing across the network. The protocol-distribution view is especially valuable: it highlights the dominant transport mix at a glance and makes any unexpected protocol stand out immediately.**

An unfamiliar protocol in the mix cleartext FTP, SMBv1, Telnet from inside the environment is an immediate Req 2.2.5 finding. Bandwidth baselines turn anomalies into alerts. The Network-Stats table is continuous Req 10.2 evidence at scale, recording every flow with timestamp, source, destination, application, bytes, and packets.

Figure 5: Network Insights Derived from Network Packets with Aviz Elastic Node

Gen-AI Insights Shadow AI as a PCI Risk Surface

Addresses: 12.3.1 (targeted risk analysis), 12.5.2 (scope review), supporting 4.2.1 (data-in-transit hygiene)

Figure 6: Gen-AI Insights Derived from Network Packets with Aviz Elastic Node

PCI-DSS 4.0 does not name generative AI by name. But Req 12.3.1 (targeted risk analysis) and Req 12.5.2 (annual scope review) both apply the moment an employee, application, or partner integration sends sensitive data including PII & cardholder data to an external Large Language Model. For most financial institutions in 2026, this is no longer a hypothetical: it is happening every day, on the corporate network, and most security programs cannot see it.

Gen-AI Insights is the dashboard built for this risk surface. It separates AI traffic into two cleanly labeled categories. Shadow AI Apps captures unsanctioned consumer and prosumer AI services—the public LLMs employees access directly from corporate networks, often without IT or security awareness. Non-Shadow AI Apps captures sanctioned enterprise AI consumption through approved cloud providers and SaaS platforms.

The distinction matters. Sanctioned AI on an enterprise cloud account has contracts, data handling commitments, and audit trails. Shadow AI does not. A line of cardholder data pasted into a public LLM session is, under PCI-DSS scope rules, a transmission of cardholder data over an open public network to a third party with no contract, no data-handling commitment, and no audit trail. That is a Req 12.3.1 finding waiting to happen.

Top APIs for AI Apps ranks the actual AI service endpoints being called from the network public LLM APIs and enterprise cloud AI services alike by flow count. The Gen-AI Stats table records every AI session at the network layer, with timestamp, application, source and destination IP, hostname, bytes, packets, and HTTP method. That is the audit artifact that closes the loop: not just that AI is in use, but which services, from which hosts, and how much data is moving.**

For institutions building targeted risk analyses under Req 12.3.1, this is the only evidence layer that sees the problem comprehensively. Endpoint DLP catches some of it. Cloud access security brokers catch some of it. The network sees all of it, regardless of endpoint, regardless of browser, regardless of whether the user is on a managed device or a personal one connected to corporate Wi-Fi.

For the controls Aviz does not directly address Req 3 (stored data), Req 7 (access control), Req 9 (physical access) Aviz integrates with the IAM, encryption, and physical security platforms that handle them. The packet-derived evidence Aviz produces enriches those tools, not replaces them.

What this means for your next audit

PCI-DSS 4.0 raised the bar from checking quarterly to checking continuously. Aviz Deep Network Observability delivers the evidence that meets that bar every TLS session for cryptography requirements, every HTTP transaction for system and logging requirements, every DNS query for malware and monitoring requirements, every flow for network security requirements, and every AI session for risk analysis requirements. All without agents on the workload, without changes to the application, and without proprietary appliances anywhere in the stack.

The strength of the evidence is what makes the difference. Packet-derived metadata is captured out-of-band, immutable from the moment it crosses the wire, and complete across both North-South and East-West traffic. It produces the audit artifacts continuously, in the format auditors actually want, streamed into the SIEM or observability platform you already run.

**The next audit is not the goal. The goal is the audit after that when continuous monitoring is the default, every cipher and certificate is accounted for in real time, and the question changes from "can we prove this?" to "what else can we see?"