fsi-payments-credit-card

Files (4)

• SKILL.md
• SKILL_ja.md
• overview.png · assets/images/
• architecture.md · references/

SKILL.md (first lines)

# Credit Card Issuer Reference Architecture (BLEA for FSI)

## Workload Overview

This case study is a reference for incrementally migrating and operating a **credit
card issuer (イシュア) system** on AWS, moving it in stages from an on-premises
environment to the cloud.

A credit card issuer system processing consists mainly of three processes:

- **Authorization** — real-time approval of card usage. When a customer uses a card,
  information is relayed in the flow merchant → payment processor / acquirer → card
  issuer to make the approval decision.
- **Reconciliation** — exchange and matching of approved transaction data. The
  acquirer sends clearing data (sales information) to the issuer, and it is matched
  against the approval data.
- **Settlement** — the clearing, settlement, and fund movement between acquirer and
  issuer over the payment network.

Purpose / significance of this architecture:

- Flexibly handle high-traffic processing driven by payment demand (e.g., large-scale
  sales or point-reward campaigns) and real-time approval requirements.
- Build an IT foundation that lets services / functions be added or changed
  efficiently when new payment technologies or industry standards are introduced, or
  when financial regulatory requirements change.
- Build a highly resilient architecture that supports business continuity for a
  mission-critical card payment system requiring high availability.

Business / technical drivers (requirements):

- **Performance**: up to 5,000 TPS, response time ≤ 200 msec, processing more than 1
  million transactions per day / over 300 million per month. A microservices
  architecture is adopted so each function scales out independently.
- **Availability**: 99.99%, realized by making maximum use of AWS mechanisms such as
  multi-region / multi-AZ.

Overall composition: this architecture builds **Authorization** and **Reconciliation**
on AWS while building **Settlement** (fund clearing) on-premises. By adopting the
Strangler Pattern to migrate the workload to AWS in stages, migration risk and cost
are reduced while the benefits of the cloud are still enjoyed in a balanced way. On
AWS, reconciled clearing data is created and the file is then handed off to
on-premises where the Settlement process is executed.

## Best Practices and Key Components

### Best Practices

- MUST: Build Authorization (approval) and Reconciliation (matching clearing files
  against approved data) on AWS, and keep Settlement (fund clearing) on-premises.
- SHOULD: Adopt the Strangler Pattern to migrate the workload to AWS in stages,
  reducing migration risk and cost while gaining cloud benefits in a balanced way.
- MUST: Adopt a microservices architecture so each function scales out independently,
  to flexibly meet the credit card industry's high-traffic and real-time approval
  requirements.
- MUST: Adopt a multi-AZ configuration to raise service continuity within a region;
  redundantly deploy ECS compute, Amazon MSK, Amazon EMR, ElastiCache for Valkey, and
  AWS SFTP across multiple AZs.
- MUST: Adopt a multi-region Active-Active configuration; determine, per data content
  (card number, customer ID, etc.), which region on-premises routes to, so that each
  region has a separated processing scope, achieving both consistency and availability.
- MUST: Synchronize data across regions using Aurora Global Database and DynamoDB
  Global Tables (typically replicating within 1 second).
- SHOULD: Prepare countermeasures for data loss caused by replication lag during
  failure recovery — e.g., archive write events to S3 via DynamoDB Streams and Kinesis
  Data Firehose, forward application processing-result logs to S3 and inspect them with
  Athena during regional recovery, reconcile against external payment systems to detect
  and complete unreflected transactions, and recover from store POS systems, EC
  operators' order records, and customer app history.
- MUST: Use AWS Application Recovery Controller (ARC) routing control to achieve
  reliable switchover on regional failure.
- MUST: Connect on-premises and AWS with a redundant configuration using
  multi-location Direct Connect + Direct Connect Gateway + Transit Gateway.
- MUST: Maintain connectivity to the international card brand networks on the
  on-premises side.
- SHOULD: Implement communication from the on-premises side using Route 53 name
  resolution.
- SHOULD: Adopt Amazon ECS deployed across multiple AZs within a VPC; Amazon EKS may be
  selected instead of Amazon ECS to match requirements.
- MUST: Use Amazon MSK to queue data and achieve loose coupling between functions
  (task groups such as "Auth Gateway" to receive external approval requests and "Auth
  Decisioning" to execute approval processing).
- PREFER: Choose Amazon MSK for inter-function messaging, because credit card
  transactions can include large metadata (product info, customer info, risk score,
  etc.) so a large supported message size plus strong throughput / latency
  characteristics make MSK an effective choice.
- MUST: Select the right database for the right job based on the data and processing
  handled.
- MUST: Store and process card-transaction account information (balance / transaction
  data) in DynamoDB, leveraging NoSQL performance characteristics to meet the low
  latency and high throughput requirements.
- MUST: Manage per-customer business rules (card limit amount, allowed PIN error count,
  etc.) in Aurora, leveraging RDB characteristics for complex conditional reference,
  search, and aggregation.
- MUST: Process card-information tokenization in ElastiCache for Valkey; tokenize card
  numbers and authentication codes before sharing data with merchants and payment
  agents (for security / PCI DSS), using the in-memory database to tokenize at
  microsecond-level low latency.
- SHOULD: Introduce request hedging as a countermeasure for DynamoDB tail latency,
  where the application automatically sends a second request when a request exceeds a
  specified time threshold (delta value) and uses the fastest of the two responses,
  improving overall tail latency.
- WILL: DynamoDB is a distributed system, so tail latency can occur at the 99th or
  99.9th percentile due to rare internal-component performance degradation.
- MUST: Run the Reconciliation batch (matching clearing files against approved data)
  on Amazon EMR, export the result to S3, and transfer it to on-premises over SFTP
  using AWS Transfer Family.
- MUST: Rely on AWS handling PCI DSS standards within the AWS responsibility area of
  each managed service, reducing the user-side burden even when regulations change.
- SHOULD: Use the microservices architecture to limit the impact scope of regulatory
  changes on the user-side responsibility area (e.g., a regulatory change about card
  information processing can be addressed by updating only the relevant Authorization
  part).
- SHOULD: Implement comprehensive tokenization, encryption, access control, and audit
  logging of card information on the user-side responsibility area to comply with PCI
  DSS and other financial regulations.
- SHOULD: Use AWS Config, CloudTrail, and Security Hub for compliance monitoring to
  enable continuous monitoring of regulatory requirements and rapid response.

From aws-samples/sample-fsi-reference-architecture-jp, MIT-0.

More from aws-samples/sample-fsi-reference-architecture-jp