--- title: Connect for Banking (Oct 2026): Step-Up Auth, PCI, Fraud Callbacks description: On October 28, 2026 a bank can run authentication, card servicing and fraud-alert callbacks on Amazon Connect with 2 encryption keys on card digits, a 60 s outbound ring timeout and 24 months of contact records. Build order, PCI controls, failure modes. url: https://www.factualminds.com/blog/amazon-connect-banking-contact-center-2026/ datePublished: 2026-10-28T00:00:00.000Z dateModified: 2026-10-28T00:00:00.000Z author: palaniappan-p category: Cloud Architecture tags: amazon-connect, contact-center, aws, banking, fintech, pci-dss, authentication --- # Connect for Banking (Oct 2026): Step-Up Auth, PCI, Fraud Callbacks > On October 28, 2026 a bank can run authentication, card servicing and fraud-alert callbacks on Amazon Connect with 2 encryption keys on card digits, a 60 s outbound ring timeout and 24 months of contact records. Build order, PCI controls, failure modes. On October 28, 2026, a retail bank can run caller authentication, card servicing and fraud-alert callbacks on Amazon Connect. The platform will not do two things for you: it will not tell you who the caller is by voice any more, and it will not make a card-handling flow PCI-safe because the service is listed under PCI DSS. This is the retail banking half of the [fintech Connect landing page](https://www.factualminds.com/services/amazon-connect/aws-fintech/). Lending is a different risk profile and lives in [Amazon Connect for loan servicing](https://www.factualminds.com/blog/amazon-connect-loan-servicing-lending-2026/). The shared plumbing, in three sentences: an **Invoke AWS Lambda function** block waits at most 8 seconds, returns a flat map of strings, and should never throw. Every core banking lookup in this post is that pattern, and it is custom engineering you build and operate. The worked version is in the [ERP lookup guide](https://www.factualminds.com/blog/amazon-connect-erp-integration-netsuite-odoo-jd-edwards-2026/). FactualMinds has no banking Connect case studies and quotes no outcome figures. AWS lists Connect under programs such as PCI DSS and SOC. That covers AWS's side of the shared responsibility model, not yours. This is not legal, regulatory or PCI advice. --- ## Three things Connect does, three it does not | Native Connect | Custom engineering | Not in Connect | | --- | --- | --- | | Flows, queues, routing profiles, hours of operation | Core banking lookup behind a Lambda | The system of record for accounts and cards | | Store customer input with encrypted entry | Passcode generation and checking | The decision to block a card | | Recording on or off per flow step, redaction | Fraud trigger from your fraud platform | Regulatory interpretation | | Contact records, CloudTrail, S3 + KMS | Evidence pack for your auditors | Your PCI scope decision | Keep the left column thin and well-tested. Put your effort into the middle one. --- ## Authentication: tier the request, not the caller Voice ID reached end of support on May 20, 2026. The dated detail, flow inventory script and replacement options are in [the Voice ID migration guide](https://www.factualminds.com/blog/amazon-connect-voice-id-end-of-support-migration-2026/). This section only covers how a bank uses the replacements. Write the tiers before you draw a flow. The checklist in the [banking-flows README](https://www.factualminds.com/examples/architecture-blog-2026/connect-commerce-context/banking-flows/README.md) has a five-tier example. In short: - Tier 0 and 1: hours, product FAQ, card activation status. No secret, or a light knowledge check against a custom lookup. - Tier 2: balance, recent transactions, card freeze. Knowledge factor plus a one-time passcode. - Tier 3: new payee, address or phone change, card sent to a new address, limit increase. Passcode plus a recent-change check, then a person decides. - Tier 4: suspected fraud, takeover, bereavement, complaint, dispute. Always a trained agent. **The passcode step (custom engineering).** A Lambda creates a code, stores only a hash with a short expiry and an attempt counter, and sends it with AWS End User Messaging SMS. The code goes to the contact detail on file, never to the inbound caller ID. SMS arrives asynchronously, so the flow must say what is happening, wait, and allow one resend. **The honest limit.** A passcode moves the weak point to the phone number. A SIM swap passes it. The recent-change check (a number or address changed in the last few days drops the caller one tier stricter) matters more than the code itself. Pick the number of days with your fraud team. **Chat is different.** For chat, Connect has a native **Authenticate Customer** block. It needs the customer authentication capability enabled on the instance, an Amazon Cognito user pool tied to your identity provider, and Customer Profiles enabled. It routes to Success, Timeout, Opted out and Error branches, and the timeout is between 3 and 15 minutes. It returns the Error branch for voice, task and email contacts. Do not design a voice journey that depends on it. --- ## Card servicing and PCI: keep digits out of agent ears AWS publishes [best practices for PCI compliance in Connect Customer](https://docs.aws.amazon.com/connect/latest/adminguide/compliance-validation-best-practices-PCI.html). The ones that shape a card flow: 1. Collect payment card information by encrypted DTMF. Amazon Lex V2 can collect it by speech, and AWS says Lex is PCI compliant. 2. Use encryption in the **Store customer input** block for sensitive DTMF. 3. If card data reaches a recording, scrub it from the recording and obfuscate it in logs and transcriptions. 4. Use MFA for any access to PCI, because Connect is a public endpoint. 5. Encrypt downstream integration points in transit and at rest. How each maps to a feature: | Need | Feature | What to know | | --- | --- | --- | | Digits never spoken to an agent | **Store customer input** (DTMF) in the flow | Caller enters digits in an IVR step, not to an agent | | Digits encrypted | **Encrypt entry**, public key plus X.509 certificate | Up to 2 keys active at once, to allow rotation | | Decrypt | AWS Encryption SDK with your private key | Do it in a payment service you have scoped, not a general Lambda | | Recording off for the step | **Set recording and analytics behavior** | For automated interactions, recording starts when On; a later Off pauses it and a later On resumes | | Agent-side pause | SuspendContactRecording / ResumeContactRecording | The paused period is silence in the final recording; IVR, agent and screen types | | Transcript and audio redaction | Contact Lens redaction | Policy is `RedactedOnly` or `RedactedAndOriginal`; you choose who sees the original | | Recordings at rest | S3 with a KMS key | The key configured for the instance | Three judgement calls. First, prefer the IVR capture design: transfer the caller to a payment subflow rather than asking the agent to press pause. A pause button is a human control that fails when the agent forgets. Second, redaction is a second net, not the first. Third, AWS does not document in the pages we read how DTMF tones sound to an agent on a live leg, so if you ever bridge an agent into the digit-entry step, test and let your assessor review the result. We have not verified it. Test with a dummy number. Search the recording, the transcript, flow logs, CloudWatch logs and the contact record for those digits. Record the result as evidence. --- ## Fraud-alert callbacks without training customers to trust callers Your fraud platform flags a transaction. Something must reach the cardholder. Two native routes: - **StartOutboundVoiceContact** places an outbound call and then runs the flow you name. Agents do not dial. If the flow queues the call, it routes to an agent as an inbound call would. The default ring timeout is 60 seconds. A flat set of attributes can be passed in. Custom: your trigger code calls it. - **Outbound campaigns** for volume. Five documented channels: email, agent-assisted voice, automated voice, SMS and WhatsApp. By default the quota for concurrent campaign calls is 0, so you request an increase first. The flow needs a **Check call progress** block to separate a person from a machine. A fraud callback flow in order: the trigger carries a case id (not card data); the flow plays a neutral greeting; it never reads a transaction until the person is verified through an agent; a machine answer gets a callback request with no detail; unanswered or failed attempts go to a retry rule and then a second channel. Here is the shape of a trigger call. Context line: attribute values are flat strings and carry only a case id and a language code. ```json { "DestinationPhoneNumber": "+15555550100", "ContactFlowId": "", "InstanceId": "", "SourcePhoneNumber": "", "RingTimeoutInSeconds": 30, "Attributes": { "caseId": "FRD-1042", "lang": "en" } } ``` **Do not teach customers that a real bank calls and asks for secrets.** A design that holds up: - The outbound call never asks for a full card number, PIN or passcode, and sends no link by SMS. - The greeting says to hang up and call the number on the back of the card, or open the app, to review the alert. An agent only discusses details once the customer initiated or an inbound tier check passed. - Use one caller ID the bank publishes, kept consistent. Consistency is how customers learn the real one. - Never leave transaction detail in voicemail. The block decision stays in the fraud platform. Connect places contacts and records them. --- ## Branch overflow and routing All native. Branches that cannot take a call send it to a shared queue. Queues carry hours of operation, so an after-hours call lands in a flow, not a dead branch queue. Routing profiles decide which agents serve which queues, and in what priority. A practical bank layout: separate queues for general servicing, cards, fraud, complaints and vulnerable customers, plus language. Tier 4 intents never touch an AI agent or a self-service path. --- ## Secure customer context in the agent workspace Show an agent the minimum fields for the tier that passed. For a tier 2 contact that is: first name, last four digits of the account, the verification result and its time, and one recent-change flag. Not the full account number, not the date of birth, not the address. Agents who need more open the core banking system under that system's own access control. The lookup is custom engineering: a Lambda with a short timeout, least-privilege IAM, secrets in AWS Secrets Manager, and a path to an agent on failure. We do not assume your core vendor offers any particular endpoint. Confirm what yours exposes before you promise a screen. For the UI side, see [Customer Profiles and a custom agent UI](https://www.factualminds.com/blog/amazon-connect-custom-agent-ui-customer-profiles-2026/). Put authentication outcomes in contact attributes (outcome and time only, never a code or answer). --- ## Audit evidence and data residency - CloudTrail records Connect API calls, so flow, queue and security profile changes are attributable. - Contact records are available for 24 months from when the contact was initiated. Stream them for longer retention. - Recordings and transcripts sit in your S3 bucket under the KMS key set for the instance. Who can play them back is a security profile decision. - Flow logs in CloudWatch Logs help debug and replay a disputed contact. Turn them on, and keep card digits out of them. - Redaction setting is recorded on the contact record, so you can show it was on. AWS states that data stays in the AWS Region you choose. Choose the Region with your compliance team before you create the instance, because moving later is a migration. Telephony number availability varies by country, so check yours first. The full evidence list with owners is in the [banking-flows README](https://www.factualminds.com/examples/architecture-blog-2026/connect-commerce-context/banking-flows/README.md). --- ## Build order 1. Pick the Region and create the instance with a KMS key you own. 2. Draft the tiers and the escalation list. Get compliance to sign. 3. Build the queues, hours and routing profiles before any automation. 4. Build the lookup Lambda with the never-throw contract and a time budget well under 8 seconds. 5. Build the passcode subflow with a no-mobile fallback. 6. Build the card capture subflow: Store customer input, encryption, recording off, ciphertext to the payment service. 7. Turn on redaction, flow logs, CloudTrail and the evidence exports. 8. Add the fraud callback last. It touches customers first. --- ## Testing Use dummy accounts and dummy card numbers only. Test each tier with the right and wrong secret, expired and reused codes, a number with no mobile, a lookup timeout, and an SMS that arrives after the prompt has gone. Test the card flow with the digit search described above. For callbacks, test answered, machine, busy, wrong person and a number that no longer belongs to the customer. Connect's testing and simulation can validate the data a Lambda action returns. This post links no automated test, because the artifact is a checklist and none of it was run on a live instance. --- ## What could break (modelled, not an incident) A fraud alert fires at 2 a.m. The callback reaches a number that was recycled. The automated voice reads "a charge of $812 at ..." to a stranger. The design flaw is that detail was spoken before any verification. The fix is in the flow, not the dialer: neutral greeting, no detail without a passed tier check, no detail on a machine answer. A second one: the encrypted DTMF step works, but a developer logs the Lambda event to debug a timeout, and ciphertext ends up in logs next to a key id. The data is still encrypted, but now your log store holds more than you scoped. Log presence and length, never values. --- ## Recommendation and trade-off Start with tiers 0 to 2 on voice, a passcode, encrypted IVR card capture and a staffed fraud queue. Delay AI agents on any money movement. The trade-off: more handle time per call, because every sensitive request passes a step-up. An OTP step that adds 45 seconds adds about $0.0285 of Connect voice at the list rate ($0.038 times 0.75 minutes). Arithmetic, not a measurement. Security teams usually accept that, and finance can see it. --- ## Costs (published prices, checked October 28, 2026) Connect Customer lists $0.038 per voice minute, $0.010 per chat message, $0.014 per SMS or third-party message and $0.080 per email. Standard telephony charges are extra. Connect Customer includes AI agents and conversational analytics in the per-channel rate, while Connect Customer Basic excludes those AI features. See [AWS pricing](https://aws.amazon.com/connect/pricing/). Arithmetic, not a measurement: 1,000 two-minute fraud callbacks at the voice rate are about $76 before telephony. SMS delivery through End User Messaging is billed separately and varies by country. Storage, KMS, Lambda and CloudWatch add to this. --- ## What to do this week 1. List every banking intent and assign it a tier. 2. Search your flows for Voice ID references and chat-only blocks used on voice. 3. Decide the recent-change window with your fraud team. 4. Draw the card capture path and mark every system the digits touch. 5. Request the outbound campaign quota increase if you plan to use campaigns. 6. Write the fraud callback script with your fraud and compliance leads. Check it against the "never ask for a secret" rule. FactualMinds is an AWS Select Tier Services Partner. For design and build help, start at [Amazon Connect consulting](https://www.factualminds.com/services/amazon-connect/) or [contact us](https://www.factualminds.com/contact-us/). --- ## What this post doesn't cover - Lending and collections: see [loan servicing](https://www.factualminds.com/blog/amazon-connect-loan-servicing-lending-2026/). - Real outcomes: no handle-time, fraud-loss or cost-saving figures. We have no banking engagement to report. - Regulatory interpretation: strong customer authentication, call recording and consent rules differ by jurisdiction. Use counsel. - Partner voice biometrics: not evaluated here. See the [Voice ID migration guide](https://www.factualminds.com/blog/amazon-connect-voice-id-end-of-support-migration-2026/). - Core banking vendors: we name no vendor APIs and verified none. - Outbound dialer choice: see [outbound campaigns versus a dialer](https://www.factualminds.com/blog/amazon-connect-outbound-campaigns-vs-acqueon-dialer-2026/). --- ## Related reading - [Amazon Connect for fintech and banking](https://www.factualminds.com/services/amazon-connect/aws-fintech/) - [Amazon Connect Consulting](https://www.factualminds.com/services/amazon-connect/) - [Connect AI agents for FAQ and self-service](https://www.factualminds.com/blog/amazon-connect-ai-agents-faq-self-service-2026/) - [PCI DSS on AWS for fintech](https://www.factualminds.com/blog/pci-dss-compliance-aws-architecture-guide-fintech/) ## FAQ ### Does Amazon Connect have a built-in way to authenticate a bank caller by voice? No. Voice ID ended support on May 20, 2026. The native Authenticate Customer block works for chat only and returns an error branch for voice contacts. For phone you build the check yourself, for example knowledge questions plus a one-time passcode sent with AWS End User Messaging SMS, or you evaluate a partner product from AWS Marketplace. ### Is an SMS passcode enough to authorize a payee change or a limit increase? Not on its own in our design. A code sent to a number an attacker controls, through a SIM swap or port, passes the check. Use a recent-change check on the contact detail and send tier 3 requests to an agent. What your regulator expects for strong customer authentication is a question for your compliance team. ### How do we keep card numbers away from agents and recordings? Collect them in the flow with the Store customer input block and its Encrypt entry option, turn recording off for that step, and pass the ciphertext to a payment service you have scoped with your assessor. AWS also recommends scrubbing card data from recordings, logs and transcripts if it is ever captured. Test it with a dummy number and search every store. ### Can Connect decide whether a card should be blocked after a fraud alert? No, and it should not. The decision stays in your fraud platform. Connect places the callback or message and routes the answer to a fraud queue. Your system sends the trigger, and a person or your fraud rules own the block. ### When should a bank not use Amazon Connect for its contact center? When your core vendor mandates a bundled contact center for a certified workflow, when you need specialised recording regimes Connect does not provide, when you have no team to operate AWS and the custom Lambda integrations, or when the only goal is to automate disputes, complaints or bereavement calls. Those stay with trained people. ### What could go wrong with fraud-alert callbacks? The callback itself trains customers to trust an unknown number. Fraudsters imitate it. Never ask for a full card number, a passcode or a PIN on an outbound call, never send a link in the SMS, and tell the customer to hang up and call the number on their card or use the app. A modelled failure is a callback that goes to a recycled number and discloses an alert to a stranger. ### Does AWS listing Connect under PCI DSS make our contact center PCI compliant? No. AWS states support for PCI DSS and publishes best practices. That covers AWS's side of shared responsibility. Your flows, integrations, key handling, access, logging and retention are yours to configure and evidence, and your assessor decides scope. ### Do you have banking case studies on Amazon Connect? No. FactualMinds has no published banking or lending Connect case studies and quotes no outcome figures. This post uses AWS-documented behaviour and a design checklist. --- *Source: https://www.factualminds.com/blog/amazon-connect-banking-contact-center-2026/*