{"id":157,"date":"2026-04-28T10:36:52","date_gmt":"2026-04-28T10:36:52","guid":{"rendered":"https:\/\/blog.osto.one\/?p=157"},"modified":"2026-05-05T10:13:15","modified_gmt":"2026-05-05T10:13:15","slug":"41-8-of-fintech-breaches-dont-start-with-you-they-start-with-your-vendors","status":"publish","type":"post","link":"https:\/\/www.osto.one\/resources\/blog\/41-8-of-fintech-breaches-dont-start-with-you-they-start-with-your-vendors\/","title":{"rendered":"41.8% of Fintech Breaches Don’t Start With You. They Start With Your Vendors."},"content":{"rendered":"

In August 2025, Marquis Software Solutions was hit by a ransomware attack. Marquis provided marketing and compliance services to financial institutions across the United States. The breach was traced to a vulnerability in a SonicWall firewall \u2014 one that had been publicly disclosed and patched months earlier. Within weeks, over 70 banks and credit unions had been notified. At least 400,000 consumers were affected.<\/p>\n

The entry point wasn’t a sophisticated zero-day. It wasn’t an advanced persistent threat. It was an unpatched firewall at a vendor most of those 70 institutions had never thought twice about.<\/p>\n

<\/p>\n

\n

Fintech is living versions of this story constantly \u2014 just with less coverage.<\/p>\n<\/div>\n

The vendor risk problem that nobody maps at seed stage<\/h2>\n

<\/p>\n

\n
41.8%<\/div>\n
of fintech breaches in recent years originated from third-party vendors \u2014 not from the fintech’s own infrastructure. (SecurityScorecard)<\/div>\n<\/div>\n

Almost half of your breach risk isn’t in the code you write, the servers you manage, or the access controls you configure. It’s in the API you use for KYC. The fraud detection service your transactions run through. The data enrichment vendor your onboarding depends on. The embedded analytics tool your operations team added last quarter.<\/p>\n

Each of those vendors has access to your production environment, your customer data, or both. And at seed stage, most fintechs haven’t evaluated any of them with the rigor they’ve applied to their own stack. There simply wasn’t time. You were shipping.<\/p>\n

That’s understandable. It’s also a real liability that compounds as you grow.<\/p>\n

How third-party breaches actually work<\/h2>\n

The mechanics vary, but the common thread is access. A vendor has legitimate access to your environment: read permissions on a database, API keys that can retrieve customer records, authentication credentials that were set up during integration and never rotated. When the vendor gets breached, that access is what the attacker inherits.<\/p>\n

The attacker doesn’t need to breach you. They breach the vendor, find the credentials for your environment in the vendor’s systems, and use those credentials to access your customer data. Your access controls are working as designed. The credentials are legitimate. The breach happened elsewhere.<\/p>\n

This is why your own security posture, however strong, isn’t sufficient on its own. Third-party access creates a perimeter that extends beyond your control.<\/p>\n

The vendor review process most fintechs skip<\/h2>\n

Minimum vendor security review for any third party with access to customer financial data takes about two hours. Here’s what it covers.<\/p>\n

<\/p>\n

\n
\n
01 \u2014 SOC 2 Type II Report<\/div>\n

Not a badge on their website. Not a checkbox saying they’re ‘SOC 2 compliant.’ The actual auditor’s report covering an observation period in the last 12 months. Read the scope section and the exceptions section. The scope tells you what was actually audited. The exceptions tell you what wasn’t working.<\/p>\n<\/p><\/div>\n

\n
02 \u2014 Penetration Test Summary<\/div>\n

From the last 12 months, scoped to the systems that touch your integration. A VAPT that covered their marketing website but not their API infrastructure isn’t useful.<\/p>\n<\/p><\/div>\n

\n
03 \u2014 Data Processing Agreement<\/div>\n

A contract specifying what data the vendor can access, how they must protect it, and what they’re required to do if they experience a breach. Their breach notification obligation to you \u2014 ’72 hours’ versus ’30 days’ is a material difference when you have your own notification obligations to customers and regulators.<\/p>\n<\/p><\/div>\n

\n
04 \u2014 Sub-processor Disclosure<\/div>\n

Who else touches the data you give this vendor? Your KYC provider uses their own cloud infrastructure, their own database vendor, their own analytics tools. Each one is a sub-processor. You need to know who they are and that they’re operating under equivalent protections.<\/p>\n<\/p><\/div>\n<\/div>\n

The access hygiene that changes your risk profile<\/h2>\n

Beyond vetting vendors before you onboard them, access hygiene for active integrations matters as much.<\/p>\n