In November 2023, LockBit ransomware operators hit the US arm of ICBC, one of the world's largest banks, and disrupted settlement of US Treasury trades so badly that traders had to hand-deliver transaction details on a USB drive. Seven months earlier, a single zero-day in Progress Software's MOVEit file transfer tool let the Cl0p group breach more than 2,700 organizations, including banks and credit unions that never installed MOVEit themselves — they just trusted a vendor who did. Core banking system supply chain security is no longer a theoretical concern for compliance teams; it is the difference between a routine patch cycle and a bank unable to settle trades, post transactions, or answer regulators. This piece walks through why the risk is structural, what it costs when it goes wrong, and what a bank can actually do about it.
Why does core banking system supply chain security matter now?
Core banking system supply chain security matters now because a small number of vendors run the financial plumbing for thousands of institutions, turning any single vendor compromise into a systemic event. Fiserv, FIS, Jack Henry, Temenos, and Finastra collectively provide the core ledger, payments, and account-processing systems behind the vast majority of the roughly 4,500 FDIC-insured banks and thousands more credit unions in the US. That concentration is efficient for banks — nobody wants to build a general ledger from scratch — but it means a vulnerability in one platform doesn't threaten one institution, it threatens the customer deposits, wire transfers, and loan books of every institution running that platform. Regulators noticed the same pattern: the OCC, Federal Reserve, and FDIC jointly issued Interagency Guidance on Third-Party Relationships in June 2023, explicitly calling out the risk that concentrated technology dependencies pose to the banking system, not just to individual banks.
What makes core banking software supply chains uniquely fragile?
Core banking software supply chains are uniquely fragile because the systems are old, deeply interconnected, and rarely built with modern dependency hygiene in mind. Many core platforms trace their lineage to COBOL and mainframe-era architectures from the 1970s and 80s, now wrapped in layers of middleware, APIs, and third-party integrations for mobile banking, fraud scoring, and open banking connectivity. Each integration point — a payments gateway, a KYC vendor, a reporting tool, an open-source logging library like the one at the center of the Log4Shell vulnerability (CVE-2021-44228) in December 2021 — is another dependency the bank doesn't control but is fully exposed to. Finastra itself was hit by ransomware in March 2020, forcing it to take servers offline and disrupting loan processing for client banks for days. When the vendor goes down, downstream banks go down with it, and most banks have no visibility into the dependency tree sitting behind their core provider's login screen.
How much bank software vendor risk sits inside a typical core banking stack?
Bank software vendor risk in a typical core banking stack is larger than most risk registers reflect, because a "core system" is really a bundle of dozens of subcontracted components. A single core banking contract typically pulls in payment rails, statement generation, document management, identity verification, and analytics vendors — each of which has its own subcontractors and open-source dependencies. Examiners increasingly ask banks to map fourth- and fifth-party relationships, not just direct vendors, because the actual point of failure is often two or three layers removed from the contract a bank signed. The MOVEit incident illustrated exactly this: banks that suffered data exposure had frequently never heard of Progress Software directly — it was embedded inside a payroll processor, a lending platform, or a document exchange tool they did trust. Vendor risk in banking isn't a single number on a scorecard; it's a chain, and most chains are longer than the bank realizes.
Why do SBOMs matter for banking software?
SBOMs matter for banking software because you cannot patch, contain, or even explain a vulnerability in a component you don't know you're running. A software bill of materials — a machine-readable inventory of every open-source library, package, and dependency inside an application — turns "is Log4j in our core platform?" from a multi-week vendor phone-tree exercise into a query that returns an answer in minutes. The US federal push for SBOM banking software adoption started with Executive Order 14028 in May 2021, which mandated SBOMs for software sold to federal agencies, and NIST formalized supply chain risk practices in SP 800-161 Revision 1 the following year. Banking regulators have been slower to mandate SBOMs outright, but examiners are increasingly asking vendors for them during due diligence, and banks that can produce one on demand answer incident-response questions in hours rather than the weeks it took many MOVEit-affected organizations to even confirm exposure.
What does effective third-party risk management look like for banks?
Effective third-party risk management in banking looks less like an annual questionnaire and more like continuous, evidence-based monitoring tied to the same 2023 Interagency Guidance the OCC, Fed, and FDIC published. That guidance walks banks through a full lifecycle — planning, due diligence, contract negotiation, ongoing monitoring, and termination — and explicitly expects institutions to assess subcontractors, not just primary vendors. In the EU, the Digital Operational Resilience Act (DORA), enforceable since January 17, 2025, goes further, requiring financial entities to maintain a full register of ICT third-party arrangements and to test resilience against realistic attack scenarios. This is the standard that mature third-party risk management banking programs are now held to: contractual requirements (SBOM delivery, breach notification SLAs, right-to-audit clauses) paired with continuous technical verification — scanning vendor-delivered artifacts, monitoring for newly disclosed CVEs in components the bank knows it depends on, and tracking vendor security posture between renewal cycles rather than only at renewal time.
What happens when core banking supply chain security fails?
When core banking supply chain security fails, the fallout is measured in outages, regulatory findings, and customer trust, not just breach-notification costs. The 2017 Equifax breach — triggered by an unpatched Apache Struts component, another supply chain failure — cost the company more than $1.4 billion in cleanup and settlements and remains the reference case regulators cite when assessing bank exposure to consumer-data vendors. Flagstar Bank disclosed customer data exposure tied to the MOVEit campaign in 2023, on top of an earlier 2021 breach, drawing renewed scrutiny of its vendor oversight. ICBC's ransomware incident didn't just cost the bank operationally — it rattled confidence in a systemically important institution's ability to settle trades, precisely the outcome banking regulators exist to prevent. These incidents share a pattern: the initial compromise happened somewhere in a vendor's code or infrastructure, and the bank absorbed the consequences anyway, because ownership of the risk doesn't transfer just because the code did.
How Safeguard Helps
Safeguard was built for exactly this gap between "we have a vendor contract" and "we actually know what's running inside our core banking stack." Instead of relying on point-in-time questionnaires, Safeguard continuously generates and verifies SBOMs across the software your bank builds and the software your vendors deliver, so a newly disclosed CVE in a payments library or logging framework surfaces as an actionable alert, not a headline you read after the fact. Safeguard maps dependency chains beyond the primary vendor relationship, giving compliance and security teams the fourth-party visibility that examiners under the 2023 Interagency Guidance and DORA increasingly expect. It ties that technical evidence directly to your third-party risk management program, turning vendor risk reviews from an annual paperwork exercise into a living record you can hand an examiner or an incident-response team on short notice. For banks running core platforms from Fiserv, FIS, Jack Henry, Temenos, or any other provider, Safeguard's goal is simple: know what's in your supply chain before an attacker does, and be able to prove it.