--- title: How to Manage Third-Party API Risk for DORA Compliance in EU Finance (2026) slug: how-to-manage-third-party-api-risk-for-dora-compliance-in-the-eu-financial-sector date: 2026-05-08 author: Roopendra Talekar categories: [Security, Guides, General] excerpt: "Learn how to architect SaaS integrations for DORA compliance, avoid the security risks of sync-and-cache unified APIs, and manage third-party ICT risk." tldr: "DORA makes EU financial entities liable for every third-party API in their stack. To pass audits, B2B SaaS companies must abandon sync-and-cache aggregators and adopt zero-data-retention, pass-through API architectures." canonical: https://truto.one/blog/how-to-manage-third-party-api-risk-for-dora-compliance-in-the-eu-financial-sector/ --- # How to Manage Third-Party API Risk for DORA Compliance in EU Finance (2026) If your B2B SaaS or fintech product touches an EU financial entity—a bank, insurer, investment firm, payment provider, or even a regulated crypto venue—your integrations are now fully in scope of the **Digital Operational Resilience Act (DORA)**. DORA is a regulation introduced by the European Union to strengthen the digital resilience of financial entities, and it entered into application on 17 January 2025, ensuring that banks, insurance companies, investment firms and other financial entities can withstand, respond to, and recover from ICT disruptions, such as cyberattacks or system failures. This regulation fundamentally alters the calculus of building software integrations. It is no longer enough to check a box saying you have a SOC 2 report. Every third-party API you ship—your HubSpot connector, your NetSuite sync, your unified accounting endpoint—is a piece of Information and Communication Technology (ICT) supply chain that your customer's CISO must now register, monitor, audit, and be able to exit cleanly. This guide explains how DORA reshapes third-party API risk for SaaS vendors selling into EU financial services, the severe risks of using legacy data-hoarding API providers, and exactly how engineering teams must architect integrations to survive strict enterprise procurement. ## The 2026 DORA Reality for B2B SaaS Integrations **Short answer:** DORA makes financial entities legally responsible for the resilience of every ICT third-party they use, including SaaS vendors and the unified API providers behind them. If your integration architecture cannot prove security, traceability, and clean exit, your enterprise EU deals will stall indefinitely. The enforcement window has closed. The informal tolerance period that characterised 2025 DORA supervision is finished, and national competent authorities are now conducting active enforcement reviews, cross-checking Register of Information data automatically, and issuing the first compulsion payments. According to AQMetrics, 2026 marks the transition from paperwork compliance to proof of operational resilience, with regulators now expecting real-time, data-driven evidence of resilience - not just policy documentation. The new supervisory posture is described as "interventionist supervision." The threat landscape for application programming interfaces has shifted dramatically, and the financial sector is bearing the brunt of it. According to a recent report from F5 and Datos Insights, 57% of financial services firms reported experiencing an API-related data breach in the past two years. The financial impact of these breaches is staggering. Data from DreamFactory indicates that financial services API incidents cost $832,800 on average per event, far exceeding the global average for other industries. The penalties for failing to manage this risk are catastrophic. National competent authorities can impose administrative penalties including fines up to 2% of total annual global turnover or EUR 10 million, whichever is higher, individual fines up to EUR 1 million for responsible persons, cease and desist orders requiring immediate remediation, and public disclosure of the identity of the entity and the nature of the breach. Reputational damage from DORA enforcement may be more costly than the fines themselves, and DORA explicitly places responsibility on the management body for ICT risk management - board members can be held personally liable for systemic failures in digital operational resilience. For financial entities, the cost of achieving DORA compliance is massive, with implementation costs often ranging between €2 million and €5 million according to Digital Chiefs. Because the stakes are so high, financial institutions are pushing this compliance burden down to their vendors. The ESAs have already designated their first wave of critical ICT third-party providers, signalling that the supervisory machinery is fully operational. The companies that will spend 2026 fighting fires are the ones whose integration architectures were designed for speed, not for audit. ## The Hidden DORA Risk in Third-Party SaaS Integrations DORA's third-party risk regime is structurally different from anything we had before. It does not just ask financial entities to vet vendors. It makes them the legal owner of the resilience of those vendors—and the resilience of *their* sub-processors. Article 28 of DORA establishes that financial entities must manage ICT third-party risk as part of their overall ICT risk management framework, with a focus on proportionality. While all entities must manage these risks, the extent and manner of management should align with the entity's size, complexity, and operational importance. Financial entities remain fully responsible for complying with all regulatory obligations, regardless of outsourcing arrangements, and must assess and manage risks considering the potential impact on service continuity and availability at individual and group levels. The operational core is the **Register of Information (RoI)**. With DORA becoming applicable on 17 January 2025, financial entities in its scope need to have a comprehensive register of their contractual arrangements with ICT third-party service providers available at entity, sub-consolidated and consolidated levels, and these registers serve various purposes, including for financial entities as an internal tool to monitor their ICT third-party risk. Your bank customer must list you. They must list every subcontractor you use that touches their data. They must classify whether you support a critical or important function. And they must do this with data-quality discipline that 93.5% of firms fundamentally failed at last year: in the ESAs' 2024 dry-run exercise, only 6.5% of nearly 1,000 firms across the EU successfully passed all 116 data quality checks, with most common failures involving incomplete contract data, missing subcontractor information, and incorrect criticality classifications. Every API integration you build or buy expands this compliance surface area. When your application requests data from a third-party system, data flows out of the secure perimeter of the financial institution, through your infrastructure, and potentially through external integration vendors. Most financial organizations lack the necessary visibility into these data flows. Research from Traceable AI shows that only 39% of financial organizations have the ability to discover and track the use of third-party APIs and the sensitive data transmitted through them. When an auditor reviews your SaaS application under DORA guidelines, they will ask three specific questions about your integrations: 1. Where does the data go? 2. Who stores it? 3. What happens if the connection fails? If you cannot provide absolute certainty that sensitive data is mapped, secured, and isolated, you will fail the audit. > [!WARNING] > **The asymmetry is brutal:** the financial entity carries the regulatory liability, but the practical work of evidencing resilience falls on you, the SaaS vendor. Your security questionnaires just got 3x longer and 10x more technical. ## The Compliance Nightmare of "Sync and Cache" Unified APIs The pressure to ship integrations is immense. Your sales team is losing deals because your application lacks a native Workday or Microsoft Dynamics connector. Engineering is bottlenecked fighting undocumented edge cases and terrible vendor API documentation. A unified API—one interface that normalizes data across dozens of platforms—looks like the obvious shortcut. But speed often comes with a hidden security cost. Most legacy unified API platforms work the same way: they connect to your customer's Salesforce, NetSuite, or BambooHR, pull a copy of the data into their own multi-tenant database on hosting infrastructure they operate, and serve it to you over a normalized endpoint. It feels fast at evaluation. It is a regulatory liability under DORA. Here is what product managers miss in the rush to launch features: every unified API vendor you add to your stack becomes a sub-processor with access to your customers' most sensitive data. The moment a unified API vendor caches your customer's general ledger, employee PII, or customer contact records on its servers, three things become true at once: 1. **The vendor becomes a sub-processor to your sub-processor.** Your customer's RoI now needs to disclose them, their hosting region, their security posture, and their subcontractors. You are now responsible for auditing their data centers, their encryption-at-rest policies, and their access logs. 2. **An incident at the vendor is your incident.** Under DORA's incident reporting regime, breaches in the chain flow upwards. You inherit the timeline. 3. **Exit becomes nearly impossible.** DORA requires a clear exit plan to ensure operational continuity, with contracts including termination triggers such as major breaches or information security failures, defined exit paths, data portability, and vendor lock-in mitigation - and these plans must be realistic and embedded in continuity planning. If your vendor holds copies of your customer's data, "clean exit" requires provable deletion across distributed caches, backups, and replicas. Compare the two architectures from a DORA auditor's seat: ```mermaid flowchart LR subgraph SyncCache[Sync & Cache Unified API] A1[Your SaaS] --> A2[Vendor DB
caches customer data] A2 --> A3[Background sync] A3 --> A4[Customer's
SaaS Provider] end subgraph PassThrough[Pass-Through Unified API] B1[Your SaaS] --> B2[Stateless proxy
no data at rest] B2 --> B3[Customer's
SaaS Provider] end ``` The sync-and-cache box is a permanent entry on your customer's RoI, with permanent audit obligations. The pass-through box is a far smaller compliance surface: there is no data at rest to breach, no cache to reconcile, no copy to delete on exit. For a deeper view of why caching architectures are the wrong default for regulated buyers, see our breakdown of the [security implications of using a third-party unified API](https://truto.one/security-implications-of-using-a-third-party-unified-api/). ## The Playbook: Managing Third-Party API Risk for DORA If you want to ship integrations into EU finance without becoming the reason a deal dies in security review—a common trap we covered in our guide on [how to pass enterprise security reviews with 3rd-party API aggregators](https://truto.one/how-to-pass-enterprise-security-reviews-with-3rd-party-api-aggregators/)—engineering teams must adopt a strict, defense-in-depth approach to API integrations. None of the architectural choices below are optional in 2026. ### 1. Map All Third-Party APIs for the Register of Information You cannot secure what you cannot see. DORA requires a comprehensive inventory of all ICT services. Build an internal catalog of every external API your product calls on behalf of customers—direct integrations, unified API providers, identity vendors, AI vendors. For each, record: the exact data models being transmitted, authentication mechanisms, hosting region, retention policy, sub-processors, criticality classification, and contractual exit terms. This documentation must be living and automated. Relying on manual spreadsheets guarantees drift. Implement API gateways and egress monitoring to automatically log external connections, ensuring your internal RoI matches reality at all times. ### 2. Enforce Zero Data Retention (Pass-Through Architecture) If you [need an integration tool that doesn't store customer data](https://truto.one/need-an-integration-tool-that-doesnt-store-customer-data/), the single highest-leverage decision is to architect on a pass-through model where the integration middleware acts strictly as a proxy. When your application requests data, the proxy forwards the request to the third-party provider, normalizes the response in memory, and streams the result directly back to your application. The data is never written to disk. It is never stored in a multi-tenant database. Logs are minimised and stripped of payload bodies. When evaluating vendors, ask three direct questions: *Where is request and response data persisted, and for how long? Who has access to decrypted payload data in production? Can you produce, on demand, evidence that no customer data exists in your systems after a connection is revoked?* If any answer is hand-wavy, the vendor is not DORA-grade. We cover this extensively in our [vendor-neutral guide to secure unified APIs for financial data](https://truto.one/the-vendor-neutral-guide-to-secure-unified-apis-for-financial-data/). ### 3. Enforce Regional Data Residency on the API Call DORA requires you to know where data flows. EU financial data should not transit US infrastructure unnecessarily. Choose providers that let you pin OAuth flows, API calls, and webhook delivery to an EU region. The diligence question is no longer "do you have an EU region" but "can you prove a single request from my EU customer never left the EU on its way to the upstream SaaS?" ### 4. Demand Sub-Processor Transparency and Audit Rights Under Article 28(6) DORA, ongoing monitoring is required to manage third-party risks during contract duration, including performance monitoring, review of service delivery against KPIs, KRIs, SLAs, and security standards. Your contracts with API providers must mirror what your customers contractually demand from you: written sub-processor lists, advance notification of changes, audit rights, and termination triggers tied to security incidents. ### 5. Normalize Complex Data Models at the Edge Financial data is complex. An invoice in QuickBooks looks entirely different from an invoice in Xero or Oracle NetSuite. Normalizing this data without storing it requires executing transformations at the edge. Modern architectures achieve this by separating the integration mapping logic from the application code. Instead of writing integration-specific code that parses custom vendor payloads, teams use declarative configurations. These configurations define how fields map from the unified model to the provider-specific model in real-time, often using lightweight mapping languages like JSONata. ### 6. Build a Real Exit Plan, Not a Paragraph Write the runbook before you need it. If your unified API vendor disappears tomorrow, what happens to active OAuth connections? Who owns the OAuth apps? Can you re-route traffic to a fallback or in-house implementation without re-authenticating thousands of end users? Vendors that own the OAuth apps on your behalf are often the most painful to exit; vendors that let you bring your own client credentials are not. ### 7. Maintain Strict Access Controls and Token Management DORA mandates rigorous access controls. Managing OAuth tokens across hundreds of customers and dozens of platforms is a massive security risk if handled poorly. Tokens must be encrypted at rest using strong, industry-standard algorithms. Refresh token lifecycles must be managed automatically to prevent unauthorized access windows. Furthermore, scopes must be strictly limited. If your application only needs to read contacts, the OAuth request must never ask for write permissions or access to financial ledgers. ### 8. Reduce Custom Code in Connectors DORA's third-party risk requirements span Articles 28-30 and demand structured oversight of all ICT services. Every line of bespoke integration code is something you must test, patch, and re-attest. Architectures that ship new connectors as configuration rather than handwritten code shrink the surface area of what auditors and pen-testers must examine. For compliance platforms in particular, this matters at scale; we cover the architectural pattern in [scaling GRC integrations beyond point-to-point connectors](https://truto.one/scaling-grc-integrations-why-compliance-platforms-are-abandoning-point-to-point-connectors/). > [!NOTE] > **Architectural Trade-off:** Real-time pass-through APIs mean your application is at the mercy of the upstream provider's latency. If an archaic on-premise ERP takes four seconds to respond, your application waits four seconds. Caching solves latency but destroys compliance. For DORA, you must accept the latency trade-off to maintain zero data retention, mitigating it by moving integration calls to asynchronous background workers. ## Architecting for Operational Resilience: Rate Limits and Error Handling DORA is not just about preventing data breaches; it is about operational resilience. Financial systems must remain available even when third-party dependencies fail. Article 11 of DORA specifically requires mechanisms to promptly detect anomalous activities and handle ICT incidents. When building integrations, the most common operational failure is hitting third-party API rate limits. How your architecture handles HTTP 429 (Too Many Requests) errors dictates whether a minor upstream hiccup cascades into a full system outage. ### The Danger of Absorbing Rate Limits Many integration platforms attempt to "help" developers by automatically absorbing rate limit errors. If the upstream provider returns a 429, the middleware catches it, places the request in a hidden queue, retries it internally with its own backoff, and eventually returns a degraded result or times out. This is a dangerous anti-pattern for enterprise systems under DORA. If the upstream API experiences a prolonged outage, the middleware queue backs up. Memory spikes, connections timeout, and eventually, the system crashes violently. More importantly, the calling application and the financial entity lose visibility into the actual upstream pressure, cannot reason about end-to-end SLAs, and cannot model concentration risk on the upstream provider. ### The Pass-Through Approach to Backpressure To maintain operational resilience, systems must implement explicit backpressure. When an upstream API returns a rate limit error, the integration layer must pass that error directly back to the caller, along with standardized context. The IETF draft for `RateLimit` headers gives you a vendor-neutral protocol. A pass-through API should normalise upstream rate-limit signals into these headers—regardless of whether the upstream is Salesforce, NetSuite, or Xero. ```http HTTP/1.1 429 Too Many Requests ratelimit-limit: 1000 ratelimit-remaining: 0 ratelimit-reset: 47 content-type: application/json { "error": "rate_limit_exceeded", "provider": "salesforce", "retry_after_seconds": 47 } ``` Truto handles this by passing these errors straight through. Truto does not retry, throttle, or apply backoff on rate limit errors. When an upstream API returns HTTP 429, Truto passes that error to the caller with the normalized headers. ```mermaid sequenceDiagram participant SaaS App participant Pass-through API participant Third-Party Provider SaaS App->>Pass-through API: GET /crm/contacts Pass-through API->>Third-Party Provider: GET /v1/customers Third-Party Provider-->>Pass-through API: 429 Too Many Requests
X-RateLimit-Reset: 1710000000 Pass-through API-->>SaaS App: 429 Too Many Requests
ratelimit-reset: 1710000000 Note over SaaS App: Application initiates
exponential backoff ``` By passing these headers back, the integration layer ensures the calling application maintains complete control over retry and backoff logic. The application can decide whether to pause background syncs, alert the user, or execute a fallback process. This explicit control is essential for passing DORA resilience tests. Here is a minimal client-side handler demonstrating how an application might handle this backpressure: ```typescript async function callWithBackoff(req: () => Promise, attempt = 0): Promise { const res = await req(); if (res.status !== 429) return res; const reset = Number(res.headers.get('ratelimit-reset') ?? '1'); const jitter = Math.random() * 250; const delay = Math.min(reset * 1000 + jitter, 30_000); if (attempt >= 5) throw new Error('Upstream rate limit: max retries'); await new Promise(r => setTimeout(r, delay)); return callWithBackoff(req, attempt + 1); } ``` Or, if you are handling this inside a background worker processing a sync queue: ```javascript // Example: Handling normalized rate limit headers in a worker async function fetchWithBackpressure(url, options) { const response = await fetch(url, options); if (response.status === 429) { const resetTime = response.headers.get('ratelimit-reset'); const waitSeconds = Math.max(0, resetTime - Math.floor(Date.now() / 1000)); console.warn(`Rate limited. Pausing worker for ${waitSeconds} seconds.`); await new Promise(resolve => setTimeout(resolve, waitSeconds * 1000)); // Retry logic managed entirely by the caller return fetchWithBackpressure(url, options); } return response; } ``` ### Webhook Health Monitoring and Idempotency Resilience also applies to inbound data. When third-party systems send webhooks to your application, you must handle them securely to prevent replay attacks and ensure data consistency. Under DORA, you must prove that your systems can recover from missed events. This means implementing strict signature verification for all incoming webhooks and requiring idempotency keys. If a provider sends the same webhook twice due to a network partition, your system must recognize the duplicate and discard it without altering the database. ## Why Zero Data Retention is the Future of Financial SaaS Integrations The era of moving fast and ignoring the architectural consequences of third-party APIs is over. DORA does not ban data caching. It just makes it incredibly expensive. A report by Rubrik found that around half of financial organisations in the UK have spent over €1 million on DORA compliance. Most of that cost is the operational tax of managing complexity in the third-party graph. Every persisted byte of customer data is another row on the RoI, another sub-processor disclosure, another exit-plan paragraph, another item in the next pen test, and another question on the next 47-page security questionnaire. This is why evaluating [which integration tools are best for enterprise compliance](https://truto.one/which-integration-tools-are-best-for-enterprise-compliance-soc2-hipaa/) is a critical business decision. The winning architecture for SaaS vendors selling into EU finance is the one that gives you the smallest possible footprint on your customer's RoI: a stateless, pass-through unified API that does not store customer data (which is exactly [why Truto is the best zero-storage unified API for compliance-strict SaaS](https://truto.one/why-truto-is-the-best-zero-storage-unified-api-for-compliance-strict-saas/)), enforces regional data residency, owns no copies, surfaces upstream errors honestly, and can be exited in a single configuration change. That is not a marketing slogan; it is the only model that scales as EU regulators move from "file the paperwork" to "prove the resilience." By eliminating integration-specific code and relying on declarative, stateless transformations at the edge, engineering teams can drastically reduce the risk of code-level vulnerabilities in custom connectors. This aligns perfectly with DORA's strict security and resilience testing requirements, allowing you to close enterprise deals faster while keeping your compliance surface area as small as possible. > Shipping integrations into EU financial customers? Let's walk through your architecture and the DORA implications, end to end. > > [Talk to us](https://cal.com/truto/partner-with-truto)