How to test shared service outages in a universal bank

Shared service outage testing checks how a universal bank’s customer and business workflows behave when a service used across divisions becomes unavailable or degrades. It verifies dependency handling, transaction safety, recovery and data consistency across areas such as retail banking, corporate payments and wealth management, using controlled failures and agreed service expectations.

Why test shared service outages?

A universal bank may rely on common services for customer identity, payment screening, fraud checks, pricing, account data or notifications. A fault in one of these services can affect several products at once. The impact may differ by workflow: a retail transfer could be queued while a corporate payment requires additional approval or status handling.

Testing should establish which customer and operational processes depend on each service, what each process must do during an outage, and how it should recover. This is a form of resilience testing and service dependency testing. It complements [Banking critical business service testing] and [Banking disaster recovery testing], which address wider service impact and recovery concerns.

Prepare a controlled test

Start with a dependency map that identifies service consumers, interfaces, data flows and fallback paths. Confirm the map against current configuration and runtime evidence where available. Environment drift can make a test misleading if the test environment has different service versions, routing rules or timeouts from the intended deployment.

Agree the scope and safety controls before injecting a fault. Use an isolated environment with synthetic or approved test data. Keep real payment rails and customer communications out of scope unless the exercise has explicit approval and safeguards. Define expected behaviour with service owners and business stakeholders, including which operations may continue, which must stop, and how queued work is handled.

Choose fault conditions that reflect the dependency: complete unavailability, slow responses, intermittent errors, rejected requests, stale responses or a failed connection during a transaction. A simulation at the interface can test consumer behaviour; a broader failover exercise can test infrastructure recovery. These approaches answer different questions, so record which layer the test covers.

Run the scenario and check outcomes

For each scenario, exercise representative workflows from more than one division. Observe the request path from the customer or operator channel through the consuming application and shared service. Include relevant retries, timeouts and asynchronous messages. Check that retry policies do not create duplicate transactions, and that queues preserve ordering where the business process requires it.

Verify both the user-visible response and the underlying state. Useful checks include API assertions, transaction status, audit records, queue depth, reconciliation results and alerts. Confirm that controls such as screening and approval remain effective during degraded operation. A fallback must not silently bypass a control that the workflow depends on.

After restoring the service, verify recovery behaviour. Check that queued work is released according to policy, failed requests can be safely retried, and downstream records agree with the authoritative transaction state. Confirm that monitoring identifies the outage and recovery, and that operators receive enough information to distinguish a dependency failure from a consumer defect.

Worked example: payment screening unavailable

Assume a shared screening service supports retail and corporate payment flows. In a test environment, configure the service endpoint to return timeouts for screening requests. Submit a retail transfer and a corporate payment batch containing several test payments.

Expected results should specify the permitted outcome for each workflow. For example, a payment may remain pending with a clear status and a traceable reason until screening is available. The test should confirm that no payment is released without the required screening result, retries do not create duplicate instructions, and the batch reports each item’s status accurately. Restore the service, allow eligible work to resume, then reconcile the payment records against the batch and screening results.

Capture the injected fault, environment and configuration, test data identifiers, timestamps, observed responses, logs and reconciliation evidence. Record any gaps in dependency mapping or recovery behaviour, assign owners, and rerun the affected scenarios after changes. This evidence helps teams assess residual risk and decide whether recovery behaviour meets the agreed business expectations.