fsi-channel-contact-center

name	fsi-channel-contact-center
description	Reference architecture for building a secure, compliant, and reliable omnichannel contact center (顧客チャネル / Customer Channel) for Japanese financial institutions on AWS, centered on Amazon Connect. Covers inbound/outbound voice, web chat/web calling, AI assistance (Amazon Q in Connect, Amazon Bedrock), call monitoring/compliance checks, multi-region DR, and FISC compliance mapping. Use this skill when designing, explaining, or deploying a financial contact center / コンタクトセンター / コールセンター workload, when mapping Amazon Connect controls to the FISC 安全対策基準, or when working with the BLEA for FSI guest-customer-channel-sample CDK.
license	MIT No Attribution
metadata	{"author":"aws-jp-fsi-sa","version":"1.0"}

FSI Customer Channel (顧客チャネル)

Workload Overview

The Customer Channel workload is a reference architecture for an omnichannel contact center built for Japanese financial institutions, centered on Amazon Connect. Financial institutions increasingly invest in contact centers that improve both customer experience and employee experience across multiple channels: text chat on a web portal, voice calls with a call-center agent, and chatbots. This workload shows how to combine Amazon Connect with other AWS services and machine-learning technology to build a contact center that meets the security, compliance, and reliability requirements demanded of financial institutions.

Business scenarios covered:

• Channels: public-switched-telephone-network voice, or chat from a web portal.
• Inbound: customer desks, agency desks, automated reception (telephone banking, provisional card-loan screening), and call concentration.
• Outbound: call-backs, telemarketing, and collection/dunning operations.
• Compliance: detecting words that violate internal compliance rules from the transcription of voice-channel conversations.

Significance in financial services: Contact centers handle sensitive customer data (phone numbers, contract details, identity information) and are subject to the FISC 安全対策基準 (Security Guidelines on Computer Systems for Financial Institutions). This workload provides an implementation baseline that addresses encryption, access control, audit logging, disaster recovery, and identity verification, deployed on top of the BLEA for FSI governance base.

Best Practices and Key Components

Best Practices

• MUST: Manage users in the primary region via SAML federation with AWS IAM Identity Center so password policy and MFA are enforced.
• MUST: Encrypt data stored in Amazon S3 (call recordings, chat transcripts, contact trace records) with AWS KMS keys and protect access via IAM policies and S3 bucket policies.
• MUST: Use TLS for all communication with and between AWS services (Amazon Connect, Amazon S3, etc.) for both confidentiality and tamper detection.
• MUST: Control access to sensitive contact history (phone numbers, recordings, contact flows) using Amazon Connect security profiles.
• MUST: Grant IAM policies, resource policies, and SCPs with the least privilege possible, including the roles attached to Lambda functions.
• SHOULD: Enable KMS key rotation and manage key policies; consider separation of duties between the encryption-key administrator and the data owner.
• SHOULD: Back up important settings such as contact flows periodically using Amazon EventBridge and AWS Lambda so they can be restored after unauthorized changes.
• SHOULD: Monitor key Amazon Connect metrics with Amazon CloudWatch (e.g. LongestQueueWaitTime, MissedCalls, CallsBreachingConcurrencyQuota, ContactFlowErrors, ThrottledCalls) to detect quota breaches and errors.
• SHOULD: Export the Amazon Connect login/logout report to S3 because it is limited to 10,000 rows.
• SHOULD: Record Lambda function execution logs, since most other services are managed.
• MAY: Use Amazon Connect Voice ID for voice-based identity verification (voiceprint), with operator confirmation available as an alternative.
• MAY: Adopt a secondary region for wide-area disaster recovery; it is optional and can be omitted when multi-AZ redundancy is sufficient or data-residency is a concern.
• WILL: In the secondary (DR) region, AWS IAM Identity Center is not used, so password policy, MFA, and login-failure logging are not enforced there — account for this.
• WILL: The sample template uses the Amazon Connect Preview API, which is subject to change, and implements only part of the full architecture (e.g. periodic configuration backup is not yet implemented).
• MUST: Apply cdk-nag's AwsSolutionsChecks (via Aspects) to every CDK stack built from this skill, and gate CI (jest etc.) on zero unsuppressed AwsSolutions-* findings; suppress exceptions only with an explicit reason via NagSuppressions (see references/cdk-nag.md).

Key Components

Contact Center Platform

• Component Overview: The core engine that receives inbound/outbound voice, web chat, and web calls, routes contacts to agents, records interactions, and hosts contact flows and the agent workspace. It runs across multiple Availability Zones for high availability.
• Assumed AWS Services: Amazon Connect.

Identity and Authentication

• Component Overview: Enforces password policy and MFA for agents/administrators and centralizes identity, verifying end-customer identity where required.
• Assumed AWS Services: AWS IAM Identity Center (SAML federation), Amazon Connect user management (secondary region), Amazon Connect Voice ID; optionally an external IdP.

Inbound Contact Handling

• Component Overview: Receives incoming voice/chat contacts, performs automated reception and identity prompts, and connects customers to agents. Supports both agent-connected flows and immediate-acceptance flows used by the communication widget.
• Assumed AWS Services: Amazon Connect (contact flows, queues), Amazon Lex (identity bot), Amazon Polly.

Outbound Contact Automation

• Component Overview: Automates outbound dialing via an API and manages the state of each dial (initiated, disconnected) for call-backs, telemarketing, and dunning.
• Assumed AWS Services: Amazon API Gateway (IAM auth), AWS Step Functions, Amazon DynamoDB, Amazon EventBridge, Amazon Connect.

AI Assistance and Compliance Monitoring

• Component Overview: Provides agent assist / self-service answers from a knowledge base, real-time call monitoring, conversation summarization, and compliance checks that detect rule-violating statements in transcripts.
• Assumed AWS Services: Amazon Q in Connect, Amazon Bedrock (Anthropic Claude, Amazon Nova models), Amazon Kinesis Data Streams, AWS Lambda, AWS AppSync, Amazon DynamoDB.

Customer Data and Case Management

• Component Overview: Unifies customer profiles across contacts and manages customer-issue cases integrated with the contact center.
• Assumed AWS Services: Amazon Connect Customer Profiles, Amazon Connect Cases, Amazon AppIntegrations.

Recording Storage, Backup, and DR

• Component Overview: Stores encrypted call recordings, chat transcripts, and contact trace records, and replicates them cross-region for remote backup and disaster recovery.
• Assumed AWS Services: Amazon S3 (KMS-encrypted, versioned, cross-region replication), AWS KMS, Amazon Data Firehose.

Web Frontend and Edge Protection

• Component Overview: Delivers the customer-facing web site (with the communication widget) and the internal call-monitoring UI, protected at the edge by IP-based filtering.
• Assumed AWS Services: Amazon CloudFront, AWS WAF, Amazon S3, Amazon Cognito.

FISC Compliance Summary

The FISC mapping documents how BLEA for FSI addresses the practical standards (実務基準) of the FISC 安全対策基準 (11th edition) for the Customer Channel workload. It covers all 148 items (実 1 through 実 148). Only the measures provided by BLEA for FSI are listed; overall system safety must additionally be considered in the user application and in system-operation/development processes.

Key regulatory considerations addressed by this workload:

• Access control and identity (実 1, 5, 8, 9, 25, 26): SAML federation with IAM Identity Center for password policy and MFA (primary region), least-privilege IAM, Amazon Connect security profiles, and Voice ID for identity verification. Note the DR secondary region does not use IAM Identity Center.
• Data protection (実 3, 4, 5, 7, 13, 30): KMS encryption of S3 data, TLS in transit (confidentiality and tamper detection), and appropriate KMS key policies.
• Audit and monitoring (実 10, 16, 19, 20, 46, 47, 101–103): CloudTrail for Amazon Connect API calls, Connect login/logout reports, CloudWatch monitoring of key metrics, and Lambda execution logging.
• Resilience / DR (実 39, 71, 73, 74, 104): Multi-AZ Amazon Connect, multi-region configuration for wide-area disaster, S3 versioning + cross-region replication, and CDK (IaC) for configuration backup.
• Out of scope: many items are handled by the AWS cloud, by the business application, or by management/operation/development processes, and are marked as such.

Full row-by-row detail (all 148 items, no omissions) is in references/fisc-mapping.md.

Reference Architecture

The reference architecture is a multi-region Amazon Connect contact center. Example region layout used by the sample: primary in Tokyo (ap-northeast-1), an optional secondary DR region, a tertiary region (e.g. Osaka, ap-northeast-3) for backup, and a us-east-1 stack for the CloudFront WAF.

Key design decisions:

• Amazon Connect as the core, with S3 storage configs for call recordings, chat transcripts, and scheduled reports, and Amazon Data Firehose delivery of contact trace records — all KMS-encrypted.
• Identity via SAML/IAM Identity Center in the primary region; Amazon Connect-managed users in the DR region.
• Wide-area DR by pre-provisioning a Connect instance and phone number in the secondary region and replicating recordings/CTR/settings to another region. The secondary region is optional.
• AI capabilities through Amazon Q in Connect (assistant, knowledge base, AI agents with Japanese prompts on Amazon Bedrock models) and real-time call monitoring with Bedrock-based compliance checks and summarization.
• Edge protection via CloudFront + AWS WAF (IP allow-listing).

Architecture diagrams (note: diagrams predate some newly added resources) and full technical detail are in references/architecture.md.

CDK Sample Overview

The CDK sample (TypeScript) provisions a multi-region Amazon Connect contact center under the project prefix BLEAFSI-CustomerChannel:

Sample app security notice: this sample is a reference/functional demo, not production-ready. The call-monitoring sample has no object-level authorization (a known developer TODO): any single authenticated agent can read every customer's call transcripts, AI summaries, and compliance findings. Bedrock invokeModel is also granted on Resource:'*'. Implement per-caller row-level authorization (and scope Bedrock/MFA/WAF) before handling real customer data. The same notice ships as assets/sample-cdk/SECURITY_NOTICE.md and is printed as a warning on every cdk synth / cdk deploy.

• Primary stack: Amazon Connect instance (with S3/KMS recording configs, CTR via Firehose, optional SAML), plus samples for inbound, immediate-inbound, outbound, Amazon Q in Connect, Customer Profiles, and Cases; conditionally the call-monitoring and web-call samples.
• Tertiary stack: backup KMS key and S3 bucket (cross-region replication target).
• Secondary stack (optional): DR Amazon Connect instance.
• WAF stack (us-east-1): CloudFront WAF Web ACL.

It uses the Amazon Connect Preview API and implements only part of the full architecture. Deployment steps (context configuration, CDK bootstrap/deploy, SAML setup, communication widget, testing) are in references/deployment.md. A detailed, source-grounded walkthrough of every stack and construct is in references/cdk-sample.md. The sample source is under assets/sample-cdk/. The copied assets/sample-cdk/test/*.test.ts is the authoritative source of the cdk-nag enforcement pattern; see references/cdk-nag.md for the extracted enforcement layers and suppression ledger (this asset passes with zero suppressions).