Financial services carries the most developed regulatory expectations of any US sector and attracts adversaries with the clearest motivation. Those two facts pull in the same direction, and the sector is generally better defended than most.
The problems that remain are specific, and they tend to sit in the gap between satisfying a regulator and stopping an attacker.
What Attackers Are After
Payment systems and the paths to them. Wire transfer, ACH origination and payment approval workflows convert access directly into money, which makes them the highest-value target in the environment and the one attackers work toward deliberately.
Business email compromise, which remains among the most financially damaging attack categories and requires no technical sophistication at all. An attacker with mailbox access observes payment conversations, waits for a legitimate transaction and redirects it. No malware, no exploit, and controls oriented toward intrusion detection engage with none of it.
Customer data, for fraud, for resale and for extortion leverage. Financial data is durable in a way that other stolen data is not.
Access for resale. A substantial share of intrusions begin with a broker who obtained a foothold opportunistically and sold it to whoever wanted it, which means an institution can be targeted without ever having been selected.
The Regulatory Picture
The layering here is genuinely complex and depends on charter and activity.
NYDFS Part 500 applies to entities licensed by the New York Department of Financial Services, regardless of where they are headquartered. It is among the most prescriptive US cyber regulations, requiring annual penetration testing from inside and outside the network boundary, bi-annual vulnerability assessment, extensive multi-factor authentication, and personal certification by the CEO and CISO. We have covered it in detail in NYDFS Part 500.
FFIEC guidance shapes examinations for federally supervised institutions through the member agencies, with the Cybersecurity Assessment Tool and the architecture and operations booklets setting expectations examiners work from.
GLBA and the Safeguards Rule apply broadly to financial institutions, with specific requirements including a written information security program, a qualified individual responsible for it, risk assessment, penetration testing and vulnerability assessment, and incident response planning. The FTC enforces against non-bank financial institutions, which reaches considerably further than many firms assume.
SEC rules apply to public companies and registered entities, requiring prompt disclosure of material incidents and annual description of risk management processes.
PCI DSS applies wherever card data is processed, stored or transmitted.
For a multi-state institution, the practical approach is usually to build to the strictest applicable standard, frequently Part 500, and map outward.
Where Testing Finds Problems
Segmentation between corporate and payment environments. This is the most consistent serious finding in the sector. Institutions defend the perimeter well and frequently run flat internal networks, so a compromised laptop provides a route toward core systems. Testing this directly, from the position an attacker would actually occupy, is the single most valuable engagement most institutions can run.
Identity controls at the edges. MFA is generally deployed and generally has gaps: service accounts, legacy applications, vendor accounts and administrative paths. Part 500 makes this explicit for covered entities, and an assessment finding privileged accounts without MFA has found a compliance failure rather than only a weakness.
Payment workflow logic. The controls around approving a payment are business logic, and business logic fails in ways no scanner detects. Whether one compromised identity can both initiate and approve, whether approval thresholds can be circumvented, and whether an attacker with mailbox access can redirect a legitimate payment are all testable questions.
Third-party and vendor access. Core banking platforms, payment processors and managed service providers hold significant access. What each could reach if compromised is a question about your architecture, not their questionnaire.
Detection of lateral movement. Perimeter monitoring in this sector is generally strong. Detection of credential access and lateral movement is frequently much weaker, and those are the stages between a foothold and a payment system.
The Exercise That Changes Most
For institutions with reasonable maturity, an objective-based red team with a payment-adjacent objective answers the question leadership actually has: could someone reach the systems that move money, and would we notice?
That is a different question from whether controls exist, and it is the one that produces architectural change afterward. Institutions that have run one typically emerge with phishing-resistant authentication, meaningful segmentation around payment environments, and detection redirected toward internal movement.
For institutions earlier in their maturity, an assumed breach engagement delivers more per dollar, because it produces actionable findings regardless of detection capability.
For Fintechs Specifically
Fintechs typically encounter serious security requirements through a banking partner or payment processor review rather than through a regulator, and those reviews are frequently more demanding than the firm's direct obligations.
The pattern we see repeatedly is a company that built quickly, has genuine security debt in internal administrative tooling and deployment pipelines, and is facing a partner review in six weeks. The debt is predictable: admin tooling nobody tested, production and staging insufficiently separated, and CI/CD credentials with administrative reach.
Addressing it before the review is considerably easier than during, and the resulting report answers the same questions from every subsequent partner.
To discuss testing for a financial institution, get in touch.
Frequently asked questions
What regulations govern cyber security for US financial institutions?
It depends on charter and activity. NYDFS Part 500 covers entities licensed in New York. FFIEC guidance applies to federally supervised institutions through their regulators. GLBA and the Safeguards Rule cover financial institutions broadly, with the FTC enforcing against non-bank entities. SEC rules apply to public companies and registered entities, and PCI DSS applies wherever card data is handled.
What do attackers actually target in financial services?
Payment systems and the paths to them, customer data for fraud and resale, and increasingly the business email compromise route, which requires no technical sophistication and produces direct financial loss. Wire and payment approval workflows are a specific and recurring target because they convert access into money without needing to defeat any other control.
How often should a financial institution test?
Annually at minimum, and NYDFS Part 500 requires it explicitly for covered entities, from both inside and outside the network boundary, plus bi-annual vulnerability assessment. Institutions with meaningful change rates or complex environments benefit from continuous testing alongside a periodic in-depth engagement.
Are fintechs held to the same standard as banks?
Directly, sometimes not; practically, increasingly yes. Banking partners and payment processors conduct meaningful due diligence and impose requirements contractually, which frequently reaches further than the fintech's own regulatory obligations. Many fintechs first encounter serious security requirements through a partner review rather than a regulator.
What is the most common serious finding in this sector?
Insufficient segmentation between the corporate environment and payment or core banking systems. Institutions generally protect the perimeter well and frequently have flat internal networks, which means a single compromised workstation provides a path toward the systems that matter. It is also the finding that most reliably changes architecture afterward.