Navigating Stablecoin Risks: A Guide for Banking Leaders Dane McFarlin

Navigating Stablecoin Risks: A Guide for Banking Leaders

The Stablecoin Dilemma: Balancing Innovation and Security

Introduction and Context

As of June 28, 2025, stablecoins, which are defined as digital currencies whose value is anchored to stable assets such as the US dollar, are reshaping the financial sector. With a global market capitalization exceeding $250 billion, stablecoins facilitate cross-border payments, power decentralized finance (DeFi), and bridge traditional and digital finance. Their adoption by major U.S. banks and companies like PayPal and Stripe underscores their growing significance. However, their reliance on open source software and third-party providers introduces significant digital risks, necessitating robust risk management and regulatory oversight. This article explores stablecoins’ transformative role in the financial sector, the risks of open source software, Third-Party Risk Management (TPRM) strategies, and the contrasting regulatory approaches in the EU and USA.

‍

The Rise of Stablecoins in Banking

Stablecoins offer price stability, making them an ideal solution for everyday transactions, cross-border payments, and liquidity management. Unlike volatile cryptocurrencies, their connection to assets like the US dollar or gold ensures reliability, enabling banks to streamline operations and access DeFi services. Their programmability and instant settlement capabilities reduce transaction costs and enhance efficiency, positioning stablecoins as a bridge between traditional finance and digital assets. However, their integration into banking systems introduces complexities, particularly in ensuring secure software supply chains to protect customer assets and maintain trust.

Open Source in Banking: Innovation Meets Vulnerability

Open source software, such as npm packages and blockchain smart contracts, is the cornerstone of stablecoin platforms, offering flexibility and cost-effectiveness. Platforms like npm provide libraries for digital wallet management, cryptography, and API integrations, driving innovation. However, this reliance introduces significant risks as it relates to everyone interconnected from Banks, Fintechs, BaaS, Cores, etc (https://www.hoganlovells.com/en/publications/hundreds-of-malicious-packages-posted-to-npm-targeting-cryptocurrency-developers):

Smart Contract Vulnerabilities: Bugs like re-entranc¹y attacks allow attackers to drain banking account reserves by repeatedly withdrawing funds before the contract updates its accounting. Logic errors or improper access controls can also lead to unauthorized transactions.
npm Package Compromises: Attackers can infiltrate development pipelines by uploading malicious packages, such as through “dependency confusion” attacks, injecting code to steal private keys or redirect payments.
Data-Feed (Oracle) Manipulation: Tampering with price oracles can trick smart contracts into unauthorized minting or transferring of stablecoins, destabilizing the system.
Transaction Exploitation: Unauthorized minting, transaction redirection, and laundering through decentralized exchanges (DEXs) or privacy tools like Tornado Cash can obscure stolen assets, making recovery nearly impossible.

A real-world stablecoin banking hack example is a $49.5 million theft from a DeFi protocol, where attackers exploited a smart contract vulnerability, drained reserves, and laundered funds within minutes (https://hoploninfosec.com/stablecoin-bank-hacked/). Such incidents highlight the potential for rapid financial losses and insolvency if banks’ stablecoin systems are compromised. Here is a table of common exploit types, methods of attacking, and how they can impact bank reserves:

‍

‍

Third-Party Risk Management (TPRM) and Continuous Monitoring

Given the financial institutions’ reliance on third-party providers, TPRM is critical for banks adopting stablecoins (and other digital partnerships). The continuous monitoring of software supply chains reduces the window of exposure to attacks and provides significant risk mitigation. Software Bills of Materials (SBOMs), which provide a detailed inventory of software components, are key to identifying vulnerabilities and ensuring compliance with security standards. Where SOC2 Reports and SSDF Self-Attestations are insufficient in today’s age, digital trust begins with a Shared-SBOM.

Accepting “self security guarantees” is Foolish… Ask Tommy Boy!

I often think of a memorable scene from Tommy Boy, where Chris Farley’s character tries to convince a customer to buy his brake pads, despite a competitor offering a “guarantee on the box.” Farley’s pitch highlights that a guarantee is just a comforting label but it doesn’t necessarily mean the product is any good. This is highly relevant to bank TPRM programs evaluating third-party software security. Just as a fancy guarantee on a box doesn’t ensure real quality, security assurances and certifications from vendors, no matter how official they look, should not be accepted at face value. Instead, banks must look beyond the paperwork and focus on verifying the actual security and quality of the software they rely on.

Tommy Boy quote:

"Because they know all they sold ya was a guaranteed piece of shit. That's all it is, isn't it? Hey, if you want me to take a dump in a box and mark it guaranteed, I will. I got spare time. But for now, for your customer's sake, for your daughter's sake, ya might wanna think about buying a quality product from me." - Thomas R. "Tommy" Callahan III

‍

@wastingtimeonsocialmediaTommy Boy guarantee.. #tommyboy #chrisfarley #davidspade #fyp #movieclips #callahanautoparts

Tiktok failed to load.Enable 3rd party cookies or use another browser

The key lesson from this movie quote, as it applies to banks and their TPRM (Third-Party Risk Management) teams, is clear: Banks can no longer rely solely on the assurances and security assessments provided by third-party software partners. Whether it’s outdated SOC 2 reports or self-attestation letters claiming SSDF compliance, these documents are no longer sufficient on their own. To truly safeguard their digital products, banks must maintain real-time inventories of open source packages and actively collaborate with stablecoin providers, SaaS vendors, fintech companies, BaaS platforms, and other middleware partners. This approach enables banks not just to trust, but to verify the security of their technology. By sharing responsibility for open source security, both banks and their partners can strengthen operational resilience across the entire supply chain.

Regulatory Perspectives: EU vs. USA

The regulatory landscape for stablecoins varies significantly between the EU and USA, reflecting different priorities in managing digital risks.

EU: Comprehensive Frameworks

The EU’s Markets in Crypto-Assets Regulation (MiCA), fully implemented by December 2024, establishes a robust framework for stablecoins, focusing on licensing, consumer protection, and market transparency (MiCA Overview). The Digital Operational Resilience Act (DORA), effective since January 17, 2025, mandates:

Software Inventory and Tracking (SBOMs aka Software Bill of Materials): Financial entities must maintain up-to-date inventories of software components, including open source libraries.
Continuous Monitoring: Ongoing vulnerability scanning and open source version updates for all software supply chain components.
Vulnerability Management: Procedures to identify and remediate risks in third-party libraries, with Software Composition Analysis (SCA) as a basic requirement.
Third-Party Oversight: Assessment and monitoring of risks from external software suppliers, including SBOM requirements (DORA Compliance).

USA: Evolving Legislation

In the U.S., the GENIUS Act, passed by the Senate on June 17, 2025, marks a milestone in stablecoin regulation, requiring issuers to hold one-to-one reserves, undergo audits, and comply with anti-money laundering and sanctions rules. The STABLE Act also advances, focusing on financial integrity. However, these regulations do not explicitly address software supply chain security, unlike DORA. The U.S. relies on broader cybersecurity initiatives, such as Executive Order 14028, which promotes SBOM adoption for federal agencies but not specifically for financial institutions (Computer-Security Incident Notification).

Why DORA Sets the Global Standard for Digital Risk Management

DORA’s emphasis on continuous monitoring, open source inventory management (SBOM), and third-party oversight provides a more comprehensive framework for managing digital risks compared to U.S. regulations. The EU’s proactive approach to software supply chain security positions it ahead, while the U.S. focuses on financial stability, with ongoing debates about federal preemption and consumer protections.

DORA’s approach to digital risk management stands out for its comprehensive and mandatory requirements. Unlike U.S. regulations, which often rely on voluntary industry standards, DORA mandates continuous monitoring of third-party vendors, strict oversight of the entire ICT supply chain, and detailed open source inventory management (SBOM). This framework ensures that financial institutions and their technology partners are proactively managing operational and cybersecurity risks, not just responding to incidents after they occur.

The EU’s proactive stance, as seen in DORA, places a strong emphasis on software supply chain security and operational resilience, setting a higher bar than current U.S. regulations, which tend to focus more on financial stability and are shaped by ongoing debates about federal preemption and consumer protection. DORA’s requirements are enforced by law and apply broadly, impacting not just banks but all critical ICT service providers in the financial sector, including those outside the EU if they serve EU institutions.

By integrating continuous oversight, real-time risk assessment, and clear accountability across the supply chain, DORA is shaping the future of digital operational resilience and is likely to influence regulatory frameworks worldwide. US financial institutions should not wait for regulations and start preparing for the best ways to secure their assets and digital infrastructure.

Hypothetical Scenario: npm Supply Chain Attack

Consider a U.S. bank launching a stablecoin platform using common npm packages for wallet management and API integrations. A “dependency confusion” attack compromises a critical package, installing malicious code that steals API keys and mints unauthorized stablecoins. This could lead to financial sabotage, data exfiltration, and regulatory fallout, potentially causing insolvency. Similar risks extend to other sectors like healthcare, where compromised npm packages could disrupt medical systems or steal patient data, highlighting the need for proactive monitoring across industries (https://www.blazeinfosec.com/post/dependency-confusion-exploitation/).

Conclusion and Future Directions

Stablecoins are poised to redefine banking, but their reliance on open source software demands robust TPRM and regulatory compliance. The EU’s DORA and MiCA provide a strong model for managing digital risks, while the U.S. is advancing with the GENIUS Act. Banking Boards, C-Suites, TPRM managers, fintechs, and compliance professionals must adopt continuous monitoring of software supply chains by having immediate access to shared-SBOMs to balance innovation with security. As stablecoins integrate further into global finance, harmonizing regulatory approaches will be crucial for a secure financial ecosystem.

Please feel free to contact me at Dane@Monecity.com for banking governance solutions and platforms to secure software supply chains (TPRM).

Key Citations:

‍

Blog Details