# Banking contact center on Amazon Connect: design checklists

Companion to [Amazon Connect for retail banking contact centers](/blog/amazon-connect-banking-contact-center-2026/). Design material only. There is no code in this folder, nothing was run against a Connect instance, and none of it is legal, regulatory or PCI advice. AWS program scope is not your compliance: your assessor decides what is in scope for you.

Labels: **native** = built into Connect or AWS, **custom** = code or integration you write and operate.

## 1. Authentication tiers by risk

Tier the request, not the caller. Write the tiers down before you open the flow designer. The factors below are examples to adapt, not a standard.

| Tier | Example requests | Minimum check before disclosure or change | How it is built |
| --- | --- | --- | --- |
| 0 | Branch hours, product FAQ | None | native flow, no data lookup |
| 1 | Card activation status, last statement date | Identify by number on file plus one knowledge factor | custom lookup (Lambda) |
| 2 | Balance, recent transactions, card freeze | Tier 1 plus a one-time passcode to the number or channel on file | custom OTP (Lambda + AWS End User Messaging SMS) |
| 3 | New payee, change of address or phone, card replacement to new address, limit increase | Tier 2 plus a recent-change check, and an agent decision | custom checks, human agent |
| 4 | Suspected fraud, account takeover, bereavement, complaint, dispute | Always a trained agent | queue and routing profile |

- [ ] A number changed in the last N days drops the caller one tier stricter (you choose N).
- [ ] The passcode goes to the contact detail on file, never to the inbound caller ID.
- [ ] Passcode: short expiry, attempt counter, hash stored (not the code), resend limited.
- [ ] Failure of any lookup routes to an agent, never to silence or to disclosure.
- [ ] Voice ID is not referenced by any flow (support ended May 20, 2026).
- [ ] Chat only: the native **Authenticate Customer** block (Cognito user pool, Customer Profiles enabled). It returns an error branch for voice, task and email contacts.
- [ ] A caller with no mobile phone has a documented fallback path.

## 2. PCI controls checklist mapped to Connect features

Source for the AWS side: [Best practices for PCI compliance in Connect Customer](https://docs.aws.amazon.com/connect/latest/adminguide/compliance-validation-best-practices-PCI.html).

| Control | Connect feature | Label | Done |
| --- | --- | --- | --- |
| Card digits collected without the agent hearing them | **Store customer input** block, DTMF | native | [ ] |
| Collected digits encrypted | **Encrypt entry** in Store customer input, using your public key and X.509 certificate (up to 2 keys active for rotation) | native | [ ] |
| Digits decrypted only where scoped | Ciphertext goes to a payment service you scope, decrypted with the AWS Encryption SDK; not to a general-purpose Lambda | custom | [ ] |
| Speech capture of card data (if used) | Amazon Lex V2 (AWS names Lex as PCI compliant) | native | [ ] |
| Card data not in recordings | **Set recording and analytics behavior** set to Off for the capture step (IVR recording pauses and can resume) | native | [ ] |
| Agent-side pause | SuspendContactRecording / ResumeContactRecording APIs (suspended period is silence; IVR, agent and screen recording types) | native API, custom button | [ ] |
| Card data not in transcripts | Contact Lens sensitive-data redaction (RedactedOnly vs RedactedAndOriginal policy is your choice) | native | [ ] |
| Recordings encrypted at rest | S3 with the KMS key configured for the instance | native | [ ] |
| MFA on access | IAM / identity provider for the admin and agent sign-in | your IdP | [ ] |
| Downstream integrations encrypted | TLS and encryption at rest on every system the flow calls | custom | [ ] |
| Customer Profiles | Your own KMS key for the profile domain | native | [ ] |
| Eligibility audit | Review every service and third party in the call path | process | [ ] |

- [ ] A test call with a dummy card number: search the recording, transcript, flow logs, CloudWatch logs and contact record for the digits. Result recorded.
- [ ] Your assessor has signed off on scope. This list does not replace that.

## 3. Audit evidence list

| Evidence | Where it comes from | Owner | Kept how long |
| --- | --- | --- | --- |
| Who changed flows, queues, routing profiles, security profiles | CloudTrail (all public Connect APIs are logged) | platform | your policy |
| Per-contact record: channel, queue, timing, attributes | Contact records (CTRs), available 24 months from contact start; stream to Kinesis for longer | platform | 24 months + yours |
| Recording and transcript, who can play them back | S3 + KMS key policy; security profiles | security | your policy |
| Redaction setting actually applied | Contact record `RedactionConfiguration` per contact | security | with CTR |
| Flow execution for a disputed contact | Flow logs in CloudWatch Logs (enable them) | platform | your policy |
| Authentication outcome per contact | Contact attributes you set in the flow (outcome only, never the secret or the code) | platform | with CTR |
| Outbound fraud callback log: trigger id, time, channel, answered or not | Your fraud system plus the Connect contact | fraud ops | your policy |
| Access reviews | Quarterly export of users, security profiles, S3 and KMS grants | security | 12+ months |
| Change tickets for flow edits | Your change process | platform | your policy |

- [ ] One person other than the builder has replayed a single test contact end to end from this evidence.