Building Fintech Applications on AWS: Architecture Patterns

Financial technology applications have architectural requirements that distinguish them from typical web applications: every transaction must be recorded immutably, processing must complete within strict latency bounds, regulatory compliance dictates infrastructure decisions, and the cost of a bug can be measured in real money — not just user frustration.

AWS provides the services to meet these requirements, but assembling them into a coherent fintech architecture requires understanding both the technology and the regulatory context. This guide covers the patterns we implement for fintech clients building on AWS.

Core Fintech Architecture Principles

1. Immutability

Every financial transaction, state change, and decision must be recorded in an append-only log. You must be able to answer “what happened, when, and why” for any point in time.

AWS implementation:

• Amazon QLDB — Purpose-built ledger database with a cryptographic journal. Every change is recorded in an immutable, verifiable log. Ideal for transaction histories, audit trails, and regulatory records.

⚠️ Deprecation Notice (2025): Amazon QLDB was discontinued on July 31, 2025. AWS recommends migrating to Amazon Aurora PostgreSQL with the pgaudit extension for tamper-evident audit logging, or using DynamoDB with DynamoDB Streams for append-only ledger patterns. If you are building new fintech applications, use Aurora PostgreSQL with pgaudit for compliance-grade audit trails. Existing QLDB workloads should migrate using the AWS QLDB to Aurora migration guide.

• DynamoDB + DynamoDB Streams — Write transactions to DynamoDB and stream changes to S3 for long-term, immutable archival.
• S3 Object Lock — Store compliance records in S3 with WORM (Write Once Read Many) protection. Even administrators cannot delete or modify locked objects.

2. Exactly-Once Processing

Financial transactions cannot be processed twice. A duplicate payment, a double debit, or a repeated transfer creates real financial impact.

AWS implementation:

• Step Functions Standard workflows — Exactly-once execution semantics for multi-step transaction processing
• DynamoDB conditional writes — Use condition expressions to prevent duplicate processing (e.g., reject a write if the transaction ID already exists)
• SQS FIFO queues — Message deduplication prevents duplicate processing of messages within a 5-minute window
• Idempotency keys — Application-level idempotency where every API request includes a unique key

3. Encryption Everywhere

Financial data is a high-value target. Encryption is not optional:

• At rest — KMS-managed encryption for all data stores (RDS, DynamoDB, S3, EBS). Per-tenant KMS keys for multi-tenant platforms requiring data isolation.
• In transit — TLS 1.2+ for all communication. Certificate management with ACM.
• Payment-specific — AWS Payment Cryptography for payment card operations (PIN translation, card verification, key management) using PCI-certified HSMs.
• Application-level — Encrypt sensitive fields (SSN, account numbers) before writing to the database. Even database administrators cannot read encrypted PII without application-level decryption keys.

Payment Processing Architecture

Synchronous Payment Flow

Client → API Gateway (HTTPS) → Lambda (validate) → Step Functions:
    1. Fraud Check        → SageMaker endpoint (ML scoring)
    2. Balance Check      → DynamoDB (account balance)
    3. Payment Execution  → Third-party payment processor
    4. Ledger Update      → Aurora PostgreSQL + pgaudit (immutable record) [formerly QLDB — discontinued July 2025]
    5. Balance Update     → DynamoDB (conditional write)
    6. Notification       → SES/SNS (confirmation)
    → On failure at any step: compensation (reverse earlier steps)

Key design decisions:

• Step Functions orchestrates the payment flow because it provides built-in retry, timeout, and compensation patterns. If the payment processor succeeds but the ledger update fails, Step Functions automatically triggers the compensation workflow.
• Aurora PostgreSQL with pgaudit stores the immutable audit record. The pgaudit extension provides session and object-level audit logging required for financial audits. (Note: QLDB, previously used for this purpose, was discontinued July 31, 2025.)
• DynamoDB conditional writes prevent double-spending by verifying the account balance has not changed between the balance check and the balance deduction (optimistic locking).

Asynchronous Batch Payment Processing

For payroll, vendor payments, and settlement operations:

Upload CSV/API → S3 → EventBridge → Step Functions (Distributed Map):
    → Validate each payment (Lambda)
    → Score for fraud (SageMaker)
    → Execute payment (Lambda)
    → Record to ledger (Aurora PostgreSQL + pgaudit) [formerly QLDB — discontinued July 2025]
    → Aggregate results (Lambda)
    → Generate report (S3) → Notify (SES)

Step Functions Distributed Map processes thousands of payments in parallel with up to 10,000 concurrent executions, automatically handling failures and retries for individual payments without blocking the batch.

Real-Time Fraud Detection

Fraud detection must execute within the payment flow — latency beyond 100ms degrades user experience, but skipping fraud checks enables fraud.

Feature Engineering Pipeline

Historical Transactions → S3 Data Lake → Glue ETL → Feature Store (SageMaker)
    ↓
Transaction Events → Kinesis → Lambda (real-time feature computation)
    ↓
Combined Features → SageMaker Endpoint (ML model) → Score

Real-time features computed per transaction:

• Transaction velocity (transactions per hour for this account)
• Geolocation anomaly (distance from last transaction)
• Amount deviation (how unusual is this amount for this merchant/account)
• Device fingerprint matching
• Merchant category risk score

Batch features computed daily/hourly and stored in the feature store:

• Account age and history
• Historical fraud rate for merchant category
• Network analysis (connections between accounts)

Model Architecture

• Training: SageMaker training jobs on historical labeled data (S3 data lake → SageMaker)
• Inference: SageMaker real-time endpoint for sub-50ms predictions
• Monitoring: SageMaker Model Monitor detects data drift and model degradation
• Retraining: Automated retraining pipeline triggered when model performance degrades

For data analytics and ML infrastructure design, see our data services.

Regulatory Compliance Architecture

PCI DSS Scope Reduction

The most effective PCI DSS strategy is scope reduction — minimize the systems that handle cardholder data:

Client (browser) → Payment processor JS SDK (Stripe, Adyen) → Tokenized card data
    → Your API receives token only (no raw card data)
    → Your systems are out of PCI DSS scope for card data

By using a PCI-certified payment processor that tokenizes card data in the browser, your backend systems never see raw card numbers. This dramatically reduces your PCI compliance scope and cost.

For systems that must handle card data directly (issuers, processors):

• Dedicated VPC with strict network segmentation
• AWS Payment Cryptography for key management
• Dedicated multi-account setup isolating PCI-scoped workloads
• Annual PCI DSS QSA assessment

SOC 2 for Fintech SaaS

Most fintech SaaS products need SOC 2 Type II certification:

• Security — GuardDuty for threat detection, Security Hub for posture management, WAF for application protection
• Availability — Multi-AZ deployments, disaster recovery, automated failover
• Confidentiality — KMS encryption, IAM least privilege, Secrets Manager for credentials
• Processing integrity — Input validation, reconciliation checks, data quality monitoring
• Privacy — Data retention policies, access logging, consent management

For cloud security and compliance architecture, see our security services.

Audit Trail Architecture

Regulators expect comprehensive audit trails:

All AWS API calls → CloudTrail → S3 (immutable, encrypted, cross-Region replicated)
Application events → Application logs → CloudWatch → S3 (long-term retention)
Database changes → DynamoDB Streams / Aurora pgaudit logs → S3 (immutable archive) [Note: QLDB discontinued July 2025]
Access events → CloudTrail data events → S3 + Athena (query for investigations)

Every action — infrastructure changes, data access, application operations — flows to centralized, immutable storage. Athena enables SQL queries across the audit trail for regulatory investigations.

Cost Considerations for Fintech

Financial applications often have compliance-driven cost overhead:

• Encryption — KMS key usage charges ($1/month per key + $0.03 per 10,000 API calls). Per-tenant keys for multi-tenant platforms can add up.
• Multi-AZ requirements — Compliance often mandates multi-AZ database deployments, approximately doubling database costs.
• Logging and retention — Regulatory retention requirements (7 years for financial records) create long-term storage costs. Use S3 Glacier for archives.
• Security tooling — GuardDuty, Security Hub, Inspector, Macie, WAF — each adds cost but is generally required for regulated environments.

Cost optimization for fintech focuses on right-sizing within compliance constraints rather than eliminating compliance controls.

Getting Started

Building financial applications on AWS requires balancing development speed with regulatory discipline. The organizations that succeed build compliance into their architecture from day one — security controls, audit logging, encryption, and immutable records — rather than retrofitting them before their first audit.

PCI DSS Compliance on AWS for Fintech

Payment Card Industry Data Security Standard (PCI DSS) compliance is a baseline requirement for any fintech application that processes, stores, or transmits cardholder data. On AWS, meeting PCI DSS requires scoping your Cardholder Data Environment (CDE) carefully and applying the right controls at each layer.

Scope reduction is the most important PCI DSS strategy on AWS. By isolating payment processing into a dedicated VPC or set of accounts, you reduce the surface area subject to audit. Services like Stripe or Braintree can handle the CDE entirely, reducing your scope to the integration point only.

Key AWS controls for PCI DSS:

• Network segmentation — Dedicated VPC for payment workloads, private subnets, Security Groups with explicit allow-list rules, no direct internet access to CDE resources
• Encryption — KMS-managed keys for all data at rest (RDS, DynamoDB, S3, EBS), TLS 1.2+ enforced for all data in transit, no unencrypted protocols within the CDE
• Access control — IAM roles with least privilege, MFA enforcement, no shared credentials, service accounts with limited scope
• Audit logging — CloudTrail with log file validation enabled in a separate immutable account, VPC Flow Logs, CloudWatch Logs retention aligned with PCI requirement (1 year minimum)
• Vulnerability management — Amazon Inspector for continuous vulnerability scanning, patch management processes for EC2 and container images
• Intrusion detection — GuardDuty enabled across all CDE accounts, Security Hub PCI DSS standard enabled for automated compliance checks

AWS compliance programs: AWS maintains PCI DSS Level 1 Service Provider certification. The AWS Artifact console provides the AWS PCI DSS Attestation of Compliance (AoC), which your auditor will require. AWS services listed as “in scope” for PCI DSS are documented in the AWS Compliance Programs page.

For organizations building or certifying fintech applications on AWS, our Cloud Compliance Services cover PCI DSS gap assessment, architecture remediation, and audit readiness preparation.

For fintech architecture design and implementation, see our AWS for Fintech & Financial Services industry page.

Contact us to design your fintech cloud architecture →