Why the questions come
Banks are expected to manage the risk of the third parties they rely on, and part of that expectation passes down to their partners and to their partners' suppliers. For a payments company on AWS, that turns into a review of how the platform fails, recovers and changes.
In the United States, the reference point has been the 2023 Interagency Guidance on Third-Party Relationships, issued by the Federal Reserve, the FDIC and the OCC. In September 2026 the agencies proposed replacing it with a lighter, risk-based framework, and rescinding the 2024 joint statement on bank–fintech arrangements. As of November 2026 the proposal is not final and the 2023 guidance still applies.
Whatever the final text, the practical questions do not go away. Under the proposal, operational resilience, such as separately maintained backups and backup providers, is one of the things that lowers how risky a bank considers a relationship. And the concerns behind the 2024 statement, such as accurate ledgers, reconciliation and access to customer records if a partner fails, are still what sponsor banks worry about most. The companies that answer quickly are the ones that prepared the evidence before the review started.
The questions, and the evidence that answers them
The wording changes from bank to bank, but the questions are predictable. Each one has a document or report that answers it, and most of the raw material already exists in your AWS accounts.
| The question | What they really want to know | Evidence that answers it | Where it comes from on AWS |
|---|---|---|---|
| What are your recovery objectives? | How long you can be down and how much data you can lose, and whether the business agreed | RTO and RPO per critical service, signed off by its business owner | Your service catalog; AWS Resilience Hub can assess workloads against these targets |
| When did you last test failover? | Whether recovery works, not whether it was designed | Test report with date, scope, result, actual recovery time and follow-up actions | AWS Fault Injection Service experiments, game-day records, monitoring data |
| How do changes reach production? | Whether a bad change can be caught and reversed | Change policy, approval records, deployment and rollback history | Your CI/CD pipeline logs, AWS CloudTrail |
| Who can access production? | Whether access is limited, strong and reviewed | Access list, MFA enforcement, last quarterly access review and its outcome | AWS IAM Identity Center, IAM Access Analyzer, CloudTrail |
| Where does the data live? | Location, backups and who can see it | Data map: Regions, backup copies, retention, encryption, who has access | AWS Backup reports, AWS Config, AWS KMS key policies |
| Which suppliers support the service? | Concentration and fourth-party risk | Supplier register with role, data access, criticality and assurance reports | AWS Artifact for AWS's own SOC and PCI reports |
| How will you tell us about an incident? | Speed and quality of notification | Incident procedure with severity levels, notification times and contacts | Your incident tooling; AWS Health for provider events |
| Can you reconcile customer funds? | Whether balances can be proven at any time, including after an outage | Daily reconciliation reports and the process behind them | Your reconciliation platform; see our reconciliation guide |
Recovery objectives that mean something
Recovery time objective (RTO) is how long a service can be unavailable. Recovery point objective (RPO) is how much recent data you can afford to lose. Both should be set per service by the business owner, based on what an outage costs, and then the architecture should be checked against them. The order matters: an RTO copied from a vendor brochure is not an objective.
| Tier | Example services | Typical RTO | Typical RPO | Typical AWS pattern |
|---|---|---|---|---|
| 1. Transaction path | Authorization API, ledger writes | Minutes | Near zero | Multi-AZ everywhere; for the strictest targets, a warm standby or active setup in a second Region |
| 2. Money movement support | Settlement, payouts, reconciliation | Hours | Minutes to an hour | Multi-AZ, replayable inputs, cross-Region backup copies |
| 3. Reporting and back office | Dashboards, analytics, internal tools | One business day | Hours to a day | Backups and infrastructure as code to rebuild |
The examples are typical ranges, not targets for your business. What a bank wants to see is that each critical service has a target, that someone accountable agreed it, and that the design and the tests support it. Use our resilience cost calculator to compare the cost of downtime with the cost of a stronger design.
Testing failover, and proving it
"Designed for Multi-AZ" is not the same as "tested last quarter". A test that a bank will accept has a written plan, a defined scope, a measured result and follow-up actions. A first test does not need to be dramatic:
- Pick the most critical workload and write down what you expect to happen and how long recovery should take.
- Run it in a production-like environment first. AWS Fault Injection Service can stop instances, fail over a database or disrupt an Availability Zone in a controlled way, with stop conditions tied to your alarms.
- Measure. Time to detect, time to recover, data lost, customer impact, and whether alerts reached the right people.
- Restore from backup at least once a year, end to end, into a clean account. A backup that has never been restored is a hope.
- Write the report the same day: what was tested, what happened, what will change and by when.
Repeat on a schedule, typically quarterly for the transaction path, and widen the scope each time. Over a year, the reports become the strongest evidence you have.
Change, access and data
Change. Every production change goes through a pipeline with automated tests and an approval that is recorded. Infrastructure is defined as code, so the change history is also the configuration history. Rollback is tested, not assumed. Emergency changes have a documented path and are reviewed afterwards.
Access. People sign in through one identity provider with multi-factor authentication. Nobody uses shared accounts or long-lived access keys for daily work. Production access is granted to named people for named roles, ideally just in time, and reviewed every quarter with the result recorded. IAM Access Analyzer helps find permissions that are broader than intended.
Data. Keep a simple data map: which data sits in which Region and service, how it is encrypted, where backups go and who can read it. Copy backups to a second Region or account, and protect them from deletion with AWS Backup Vault Lock, so that a compromised account cannot also destroy its own backups.
Suppliers and incidents
Your supplier register is a one-page table: each supplier, what it does for the service, what data it can access, how critical it is, what assurance you hold, such as a SOC 2 report, and when you last reviewed it. AWS's own SOC and PCI reports are available in AWS Artifact; AWS is a supplier like any other in this register, governed by the shared responsibility model.
Your incident procedure is a second page: severity levels, who decides the severity, who is notified and within what time, and what information goes into the first notice. Agree the bank's notification expectations in the contract and make sure the procedure meets them. Practice it once with a tabletop exercise, which takes an hour and usually finds a missing phone number.
The gaps reviewers find most often
| Gap | How it shows up in a review | How long it takes to close |
|---|---|---|
| Recovery objectives exist only in engineering documents | The business owner cannot confirm them | Days: a meeting and a signature |
| Failover never tested end to end | Only design documents are offered as evidence | Weeks: plan, run and report one test |
| Backups in the same account as production | A compromised account could delete both | Days to weeks: cross-account copies and Vault Lock |
| Access reviews not recorded | No evidence that anyone checked who has access | Days: run one review and keep the record |
| Supplier list incomplete | Tools with access to production data are missing from it | Days: inventory from billing and identity provider |
| Reconciliation depends on spreadsheets | Balances cannot be shown quickly or reproduced | Months: process and platform work |
Most of these are quick to close once someone owns them. The exception is reconciliation, which is why it is worth starting early if your process still depends on manual work.
The evidence pack
Keep these documents in one place, with an owner and a review date each. When a review starts, you send the pack instead of starting a project.
- Architecture overview of the transaction path, one diagram, current
- Service catalog with RTO and RPO per critical service, with business sign-off
- Latest failover test report and latest restore test report
- Change management policy and a sample of recent change records
- Latest access review, with actions taken
- Data map, backup policy and encryption overview
- Supplier register with assurance reports
- Incident procedure and the record of the last exercise
- Reconciliation process and a sample daily report
Keep them current. A review that finds stale evidence is worse than one that finds a known gap with a plan to close it.
A 90-day plan
| Period | Focus | Output |
|---|---|---|
| Days 1–30 | Agree RTO and RPO for the transaction path; write the supplier register and incident procedure | Three signed documents |
| Days 31–60 | Run and document one failover test and one restore test; complete an access review | Two test reports and an access review record |
| Days 61–90 | Close the gaps the tests found; assemble the evidence pack; set the review calendar | A complete evidence pack and a schedule to keep it current |
An independent architecture assessment is often the fastest way to find the gaps before a partner does, because it looks at the platform the way a reviewer will.
Questions we hear
Do we need a second AWS Region?
Not always. Multi-AZ designs meet many recovery objectives. A second Region becomes necessary when the business needs to survive a Regional outage within its RTO, or when a partner requires it. Decide from the objectives, not the other way round.
Is a SOC 2 report enough?
It helps a lot with access, change and supplier questions. It does not replace recovery test evidence or reconciliation reports, which banks usually ask for separately.
Can we point to AWS's certifications?
For the infrastructure AWS operates, yes, through AWS Artifact. For how you configure and run your workloads on it, the evidence has to be yours.
How often should we test?
Quarterly for the transaction path is a common rhythm, plus a full restore test at least once a year and after major architecture changes.
Does the 2026 proposal mean fewer reviews?
It may change how banks structure their oversight, but it does not remove their need to know how your platform fails and recovers. Preparing the evidence is useful under either version.