A French cooperative bank recently revealed that an attacker accessed its network through a service provider's platform, using the bank's own account to push transactions to other institutions. Customer assets weren't affected, but the exposure was up to $133 million. The funds were converted into USDC and USDT stablecoins.
This sequence is more significant than the headline number. The attacker didn't need customer credentials; they needed a path through a trusted partner and an account the bank controlled. If you manage vendor risk at a bank, this is your threat model, not an outlier.
Why These Mistakes Keep Happening
Third-party risk programs often focus on audit evidence rather than adversary behavior. A completed questionnaire satisfies an examiner using the FFIEC IT Examination Handbook, so teams optimize for documentation. Meanwhile, real exposure lies in connectivity, privileges, and response speed. The five mistakes below stem from this gap.
Mistake 1: Treating Vendor Due Diligence as a Point-in-Time Event
Why it happens: Onboarding is when you have influence. Contracts are signed, questionnaires are completed, and the relationship shifts to a business owner who isn't a security specialist.
Consequence: A provider's security posture can weaken after onboarding. If an attacker compromises that platform, your network inherits the vulnerability. In the case above, the attacker's entry point was a provider's platform, not the bank's perimeter.
Fix: Tier vendors by what they can access, not by contract size. Any provider with a connection to payment initiation or treasury systems should have continuous monitoring, defined reassessment triggers (such as a change in hosting, a reported incident, or a leadership change in security), and contractual breach notification windows measured in hours. Map each tier against the NIST Cybersecurity Framework's Identify and Govern functions to ensure clear ownership.
Mistake 2: Granting Provider Connectivity Broader Than the Function Requires
Why it happens: Integrations are often built under tight deadlines. A flat, permissive path is faster to establish than a narrow one, and nobody revisits it.
Consequence: Once inside the provider's platform, a wide trust relationship allows attackers to access systems the provider never needed.
Fix: Enforce Least Privilege on every provider connection. Terminate vendor access in a dedicated zone, allow only specific protocols and destinations, and run Segmentation Testing regularly to ensure the boundary holds. Require Multi-Factor Authentication (MFA) for any interactive vendor session, aligned with NIST SP 800-63B, and apply Role-Based Access Control (RBAC) so vendor identities can't inherit internal roles.
Mistake 3: Leaving Your Own Institutional Accounts Outside Fraud Controls
Why it happens: Fraud monitoring is typically designed around customers. Nostro accounts, settlement accounts, and treasury positions are seen as internal operations, not fraud analytics.
Consequence: The attacker initiated transfers from the bank's own account to other banking organizations. Controls tuned for customer behavior didn't flag it as abnormal.
Fix: Extend transaction monitoring to institutional accounts. Set velocity and value thresholds on outbound transfers from treasury and settlement accounts, require dual authorization above a defined limit, and alert on new beneficiary institutions and off-hours initiation. Treat payment messages in ISO 20022 or ISO 8583 flows as monitored events, not trusted traffic.
Mistake 4: Delaying Disclosure and Law Enforcement Contact
Why it happens: Legal and communications teams want facts before speaking. While reasonable, the cost of waiting is high.
Consequence: Public reporting of the incident came from a blockchain investigator before the bank's disclosure. The delay allowed the attacker to launder roughly $30 million that EU law enforcement could have otherwise frozen. Recovery windows close in hours, not days.
Fix: Split your response into two parallel tracks. The recovery track notifies correspondent and receiving institutions, law enforcement, and exchanges immediately, with whatever transaction identifiers you have. The disclosure track follows once facts are confirmed. Pre-draft holding statements and pre-authorize recovery-track notifications so no one waits on approval. File the Suspicious Activity Report (SAR) or local equivalent on its required timeline.
Mistake 5: Assuming Stolen Funds Are Recoverable After the Fact
Why it happens: Fiat rails have reversal and recall mechanisms, so teams plan around them. Stablecoin conversion breaks that assumption.
Consequence: Funds moved into USDC and USDT can cross chains and venues quickly. Once beyond the point where an issuer or exchange can freeze them, recovery depends on tracing speed.
Fix: Build crypto-aware steps into your fraud playbook before you need them. Keep contacts for major exchanges and stablecoin issuers' compliance desks, retain a blockchain analytics provider, and define who can authorize an emergency freeze request. Brief your customers, too. The bank in question warned of heightened phishing risk and advised customers to verify messages by calling their adviser directly. That kind of follow-on fraud is predictable, so prepare the notice in advance.
Prevention Checklist
- Tier every third party by connectivity and privilege, not spend.
- Require breach notification from providers within hours, in writing.
- Reassess providers on defined triggers, not only annually.
- Restrict provider connections to named systems, and verify with Segmentation Testing.
- Require MFA and RBAC for all vendor access.
- Add monitoring, dual authorization, and beneficiary alerts to institutional accounts.
- Run a tabletop exercise that starts with a compromised provider and ends with a stablecoin off-ramp.
- Pre-authorize recovery-track notifications to law enforcement and counterparties.
- Keep exchange and issuer contacts and a blockchain analytics retainer current.
- Draft customer phishing warnings before an incident.
- Confirm Indicator of Compromise (IoC) sharing channels with your providers.
The common thread is simple. Your security perimeter now includes every platform that can reach your payment systems, and your response clock starts when funds move, not when your board meets.
