TL;DR: Over 50% of financial services and insurance organisations manage more than 500 APIs, while 62% saw API growth of 50% or more in the past year and 25% experienced an API breach, according to Salt Security reports. The governance gap is becoming operational risk: discovery, documentation, and posture control are lagging behind API expansion.
NHIMG editorial — based on content published by Salt: the 2024 State of API Security Report findings for financial services and insurance
By the numbers:
- Over 50% of financial services and insurance organisations manage more than 500 APIs for development, delivery, and integration.
- 62% of financial services or insurance organisations have seen APIs increase by 50% or more in the past year.
- 25% of companies in the sector experienced an actual API breach in the past year.
Questions worth separating out
Q: What breaks when API inventories are incomplete?
A: When inventories are incomplete, teams cannot reliably know which APIs exist, what data they expose, or which identities and tokens can reach them.
Q: Why do APIs create identity governance risk across machine and human access?
A: APIs often carry the real access decision for service accounts, tokens, and human sessions.
Q: How can teams tell whether API governance is actually working?
A: A working programme can answer four questions quickly: who owns the consumer, what it can access, where the policy is enforced, and how the call is logged.
Practitioner guidance
- Implement continuous API discovery Build automated discovery across cloud and application environments so new, shadow, and deprecated APIs are identified before they become unmanaged exposure points.
- Tie posture checks to deployment gates Add policy checks for authentication, authorisation, logging, and schema drift into CI/CD and release pipelines so production APIs cannot bypass review.
- Map service identities to API ownership Require every API to have a named owner, a linked service identity, and documented token or secret dependencies so entitlement reviews can be completed with evidence.
What's in the full article
Salt's full report covers the operational detail this post intentionally leaves for the source:
- Sector-by-sector API growth patterns and how they differ across financial services and insurance.
- Production API breach and vulnerability breakdowns that support operational prioritisation.
- Practical posture governance benchmarks for discovery, documentation, and release gating.
- The report's own C-level priority data for teams building executive cases.
👉 Read Salt's report on API security risks in financial services and insurance →
API sprawl in financial services: are your controls keeping up?
Explore further
API posture governance is becoming a control requirement, not a maturity exercise. When only a minority of organisations can say their inventories are complete, the real failure is not that APIs exist, but that defenders cannot prove what is in scope. That uncertainty weakens authorisation, logging, and incident response at the same time. For security leaders, the practitioner conclusion is simple: without posture governance, API security remains reactive rather than enforceable.
A question worth separating out:
Q: Who is accountable when an API exposes regulated data?
A: Accountability usually sits with the business owner, security owner, and operational owner together. For regulated environments, teams need clear assignment for inventory, change approval, incident escalation, and evidence retention. If no one owns the API lifecycle end to end, compliance and response both degrade quickly.
👉 Read our full editorial: API sprawl in financial services is outpacing security governance