Digital banks are built for speed, efficiency and customer convenience. Cloud-native platforms, outsourced operations, fintech partnerships and Software-as-a-Service models allow banks to scale rapidly while operating leaner than traditional institutions.
Yet this operating model introduces a fundamental reality: a digital bank’s ability to continue operating during disruption is only as strong as the third parties that support it.
Over the past decade, many high-impact service disruptions in financial services have not originated within banks themselves, but within external providers that enable critical banking services. When infrastructure providers, payment processors or technology vendors experience outages, customers do not see a vendor failure—they experience it as a banking service outage.
One widely cited example occurred in 2021, when a major disruption at an Amazon Web Services (AWS) data centre affected numerous digital platforms globally, including fintech services, payment platforms and online banking interfaces. Although the banks themselves had not suffered internal system failures, their customer services became unavailable because key components of their digital infrastructure were hosted externally. The incident demonstrated that even highly resilient internal architectures cannot guarantee service continuity if critical infrastructure dependencies are disrupted.
Despite these lessons, many organisations continue to manage Third-Party Risk Management (TPRM) and Business Continuity Management (BCM) as separate disciplines. In a digital banking environment, this separation is increasingly difficult to sustain. To build genuine operational resilience, these capabilities must operate together—cross-functionally, deliberately and continuously.
Shared Infrastructure, Shared Risk: The 2018 Visa Europe Outage
A notable example occurred in June 2018, when a processing failure within Visa’s European payment network caused widespread disruption to card transactions across the region.
Millions of consumers were unable to complete payments for several hours, even though the issuing banks themselves were operating normally. The outage was later attributed to a hardware failure within Visa’s payment processing infrastructure; which highlights:
-
How disruptions within shared financial infrastructure can cascade across multiple institutions simultaneously.
-
Importance of understanding ecosystem dependencies when planning for operational resilience.
The Digital Banking Dependency Model
Traditional banks have evolved over decades with internally hosted systems and vertically integrated operations. Digital banks, by contrast, are ecosystem-driven by design. Core dependencies often include:
- Cloud infrastructure providers
- Core banking platforms
- Payment gateways and card processors
- Identity verification and fraud monitoring vendors
- Managed security and SOC providers
- Outsourced operations and customer support
These third parties are not peripheral; they enable the bank’s critical business services. A disruption at any one of them can directly impact customer access, transaction processing, regulatory obligations, and reputational trust.
In Asia-Pacific, this dependency is further amplified by:
- Cross-border delivery models
- Regional cloud availability zones
- Outsourced support hubs
- Jurisdictional data and recovery constraints
The implication is clear: business continuity in digital banking is inherently inter-organisational.
Why Third-Party Risk and BCM Are Inseparable
At their core, BCM and third-party risk address issues from different angles—but ultimately pursue the same outcome.
- BCM asks: How do we recover swiftly to deliver critical services upon disruption?
- Third-party risk asks: Can our vendors continue supporting us during disruption?
When these questions are addressed separately, blind spots emerge.
A bank may define a recovery time objective (RTO) of two hours for a critical service—only to discover during an incident that the supporting vendor’s recovery capability is eight hours. Similarly, a vendor may have a documented BCP, but have conflicting priorities against the bank’s tolerance, or regulatory expectations.
In practice, a third-party failure should be treated as a business continuity event. In digital banking environments, many service disruptions originate not from internal failures but from dependencies across the technology and service ecosystem. Customers do not experience vendor outages—they experience banking service outages. Treating third-party disruption as an external issue therefore creates a false sense of confidence, particularly when internal recovery strategies are tightly linked with vendor performance.
Practical Challenges in Aligning Third-Party Risk with Business Continuity
While many organisations have mature BCM and third-party risk programmes individually, integrating the two disciplines operationally can present practical challenges.
1. BCM Tools Do Not Assess Dependency
Current BCM practices typically require for the organisation perform risk assessments and Business Impact Analyses (BIAs), followed by the development of recovery strategy within Business Continuity Plan (BCP). While the dependencies are mapped to every business functions on BIA and BCP, the importance of the dependencies, which include vendors, to the business functions is not assessed. Those business functions, especially the critical ones, do not evaluate which of their dependencies may cripple them if unavailable, and which one can have alternative methods or workaround.
2. Third-Party Assessments Limited to Review on Document Artifacts
Due diligence and risk assessments of third parties frequently prioritise document-based reviews, including:
- Policy documentation
- Questionnaire responses
- Contractual clauses
- Supporting assurance reports
- Limited independent evaluation results
While these artefacts help confirm that governance structures exist, they do not necessarily provide assurance of operational recoverability or effective crisis response capability.
Banks often encounter practical challenges when assessing vendor resilience.
For example:
a. Shared infrastructure environments
Technology vendors that operate on multi-tenant cloud platforms may not be able to conduct recovery testing jointly with individual clients due to architectural constraints.
b. Limited transparency in testing outcomes
Third parties frequently provide redacted BC or disaster recovery test results due to confidentiality obligations to other clients. These reports may demonstrate that testing was conducted, but rarely provide meaningful visibility into recovery performance or challenges encountered.
Integrating Third-Party Risk into the BCM Lifecycle
For digital banks, integration must be intentional and lifecycle-based, not ad hoc.
1. Business Impact Analysis: Mapping External Dependencies
The BIA should not stop at internal processes. It must explicitly identify:
- Which critical business services depend on third parties
- Which vendors are essential for time-critical recovery
- Whether dependencies are concentrated on single providers, regions, or platforms
A practical approach is to map:
This allows leadership to see where third-party concentration risk intersects with customer and regulatory impact.
2. Recovery Strategy Design: Aligning Assumptions with Reality
Recovery strategies must be grounded in validated third-party capabilities, not assumptions.
Key questions include:
- Do vendor RTOs and RPOs align with business expectations?
- Are alternate providers realistically available?
- Can recovery strategies function if a vendor is unavailable for an extended period?
For digital banks, this step often reveals that certain “strategies” are theoretical rather than executable.
3. Plan Development: Embedding Vendors into Response Structures
Third parties should be clearly embedded into:
- Crisis management plans
- Technology recovery playbooks
- Operational response procedures
This includes:
- Defined escalation paths
- Named vendor contacts
- Clear roles during incidents
- Communication protocols
During disruption, ambiguity is the enemy of speed.
4. Exercising and Testing: From Paper to Performance
Testing is where integration becomes real.
Effective practices include:
- Including key vendors in table-top exercises
- Conducting call-tree and notification tests involving third parties
- Running scenario-based simulations that assume vendor failure, not availability
The objective of these exercises is not simply to “pass” a test. Rather, they should surface operational friction early and strengthen coordination before real incidents occur. Over time, exercise objectives should evolve to reflect increasing levels of complexity and realism.
Moving from Compliance to Capability
Many digital banks operate in highly regulated environments, where third-party risk and BCM are subject to supervisory scrutiny. While compliance is necessary, compliance alone does not equal resilience.
True resilience requires a shift from asking “Do you have a BCP?”; to asking “Can you recover in line with our critical service expectations?”
Practical enablers include:
- Tiering suppliers based on criticality, not spend
- Focusing deep assurance on the most critical vendors
- Engaging vendors as resilience partners rather than contractual obligations
- Using post-incident reviews to improve joint response, not assign blame
In digital banking ecosystems, resilience is a shared outcome.
Leadership’s Role: Setting the Tone from the Top
Integration between third-party risk and BCM does not happen organically—it requires leadership intent.
Senior leaders play a critical role by:
- Sponsoring cross-functional collaboration between Risk, BCM, IT, Procurement, and Operations
- Encouraging early engagement with vendors on resilience matters
- Supporting transparent discussions on weaknesses and dependencies
- Reinforcing that resilience is a strategic enabler, not a cost centre
When leadership frames resilience as essential to customer trust and long-term sustainability, teams are empowered to move beyond siloed execution.
Resilience in modern banking is no longer confined within the organisation—it extends across the entire ecosystem that enables financial services.
Conclusion: Strengthening the Chain, Not Just the Links
Digital banks are designed to operate within highly interconnected technology ecosystems. Cloud platforms, fintech partners, payment networks, and outsourced service providers enable innovation and scalability—but they also extend the boundaries of operational risk. In this environment, managing business continuity within organisational walls is no longer sufficient. True resilience therefore requires visibility, coordination, and preparedness across the entire service ecosystem.
The most resilient financial institutions are those that recognise a fundamental reality: third-party disruptions are no longer external events—they are operational disruptions that directly affect customer trust and service delivery.
By integrating third-party risk management with business continuity practices, organisations can move beyond compliance and build capabilities that allow them to respond faster, recover stronger, and maintain confidence during disruption.
In an increasingly interconnected financial landscape, resilience is no longer built within a single organisation—it is built collectively with the partners that enable critical services every day.
Rozana is Head of Non Financial Risk Management at AEON Bank (M) Bhd, where she leads operational risk, business continuity, and third-party risk management initiatives.
As part of the team involved in the establishment of the digital bank, she contributed to the development of risk governance frameworks required for regulatory licensing and operational readiness.
She played a key role strengthening BCM and third-party risk practices and translating governance process into structured workflow within enterprise GRC systems.
Rozana binti Zainal Azman
