Written from 11 named sources To: PayForge Executive Leadership & Engineering Leads From: Chief Solutions Architect Subject: Architectural Decision Brief: 1,000 TPS Real-Time Payments vs. 2026 Compliance Mandates This architectural decision brief provides the strategic roadmap for PayForge Inc. as we build the ForgePay Real-Time Ledger. As a Payment Service Provider (PSP), we face a dual-track challenge: achieving the 1,000 TPS throughput required for FedNow/RTP dominance while satisfying the rigorous PCI-DSS Level 1 (Service Provider) and SOC 2 Type II mandates with a pre-seed team of 5–10 engineers. Deliverable 1 — Executive Architecture Brief The Compliance-First Architecture: Navigating the Pre-Seed to Series A Window For a fintech startup operating as a PSP, architectural decisions are regulatory commitments. With a lean engineering team, the primary threat to our MVP launch is not horizontal scalability, but "Evidence Fatigue"—the operational paralysis caused by the need to produce consistent, timestamped proof of controls across a distributed system for SOC 2 and PCI-DSS audits [medium.com]. The Monolith Calibration: Lessons from Prime Video The industry recently observed Amazon Prime Video’s "return to the monolith," where shifting from microservices to a consolidated architecture reduced costs by 90% and simplified orchestration. For PayForge, this lesson is instructive in reverse. While a billion-dollar entity reverts to a monolith to solve cost complexity, a pre-seed startup must avoid the "Microservices Tax" to solve compliance complexity [viprasol.com]. In a microservices environment, every service is a new audit surface. A 10-service mesh requires 10 sets of IAM policies, 10 logging configurations, 10 CI/CD pipeline access reviews, and 10 vulnerability scan reports. For a 5-person team, this "Evidence Fatigue" creates a compliance debt that can delay SOC 2 certification by months, potentially killing the runway before the MVP launches [10], [11]. Real-Time Correctness: FedNow/RTP Rail Demands FedNow and RTP share a defining characteristic: irrevocable settlement in seconds [the-algo.com]. The network specifies a maximum response time of 20 seconds, but practically, transactions must be processed in under 10 seconds. Within this window, PayForge must execute parallel, low-latency compliance pipelines (OFAC 50% rule screening, fraud detection) [the-algo.com]. At 1,000 TPS, a microservices mesh introduces network hop latency (gRPC/REST) and "fan-out" partial failure risks. To guarantee correctness, PayForge must implement a strict Payment Execution State Machine: RECEIVED $\rightarrow$ VALIDATED $\rightarrow$ RESERVED (internal ledger hold) $\rightarrow$ SUBMITTED_TO_RAIL $\rightarrow$ SETTLEMENT_CONFIRMED (async webhook) $\rightarrow$ COMPLETED. To prevent ledger drift during the asynchronous settlement phase, we must utilize the Transactional Outbox pattern and decouple our idempotency store (e.g., Redis) from the primary ledger to prevent database write contention [14]. The 2026 Regulatory Horizon Architectural experimentation is constrained by an aggressive 2026 regulatory horizon: EU Instant Payments Regulation (IPR): Mandates 24/7 instant euro transfers and sub-second "Verification of Payee" (VoP) by 2026 [2], [9]. UK PSR Reforms: Enhanced safeguarding and "Pay by Bank" requirements via Faster Payments [8]. Nacha 2026: Enhanced, real-time risk and fraud monitoring requirements for US rails. Synthesis: The Modular Monolith To resolve the tension between compliance tax and time-to-market, PayForge will adopt a Modular Monolith (or "Macro-service") architecture deployed via AWS Fargate. By organizing the code into strictly bounded domains—Payment Execution, Ledger/Reconciliation, Identity & Auth, and Fraud/Compliance—we achieve: Reduced Audit Surface: Compliance controls (AWS CloudTrail logging, encryption, IAM access) are implemented once at the application level [3], [13]. Performance: 1,000 TPS is achievable within a single optimized runtime, executing state transitions in memory (<1ms) rather than over a network [14]. Future-Proofing: Strict logical boundaries allow us to "peel off" the Ledger or Fraud modules into independent services post-Series A without a full rewrite [4], [6]. Deliverable 2 — Trade-off Matrix Feature Monolith Microservices PayForge Recommended Stance PCI-DSS Scope Management ⚠️ Large, flat CDE ✅ Isolated CDE ✅ Modular Monolith + Tokenization Proxy: Keep logic consolidated but use a token-first ingress to shrink the CDE [12]. SOC 2 Evidence Collection ✅ Uniform & Centralized ❌ Fragmented/High Effort ✅ Centralized: Use AWS Config/Security Hub via Terraform to monitor a single production environment [13]. Time-to-Market (5-10 Eng) ✅ Rapid ❌ Slow (Infra heavy) ✅ Rapid: Focus on business logic and state machines, not Kubernetes service meshes [10]. FedNow/RTP (1,000 TPS) ✅ Low Latency ⚠️ Network Overhead ✅ High Performance: Single-process execution ensures sub-second parallel compliance checks [the-algo.com]. Operational Overhead ✅ Low ❌ High (K8s/Mesh) ✅ Low: Abstract infrastructure using AWS Fargate; avoid on-call blast radius of distributed failures [aws.amazon.com]. Team Cognitive Load ✅ Low ❌ High ✅ Low: One repo, one deployment pipeline, one mental model for the state machine [11]. Future Scalability ⚠️ Vertical only ✅ Horizontal ✅ Hybrid: Modular design allows for future "Macro-service" extraction when the team scales >15 engineers [4]. Deliverable 3 — PCI-DSS Scope Visualization & QSA Strategy As a Level 1 Service Provider, PayForge's fastest path to compliance is QSA-driven Scope Minimization. Raw Primary Account Numbers (PAN) must never touch our core application memory, logs, or telemetry. Diagram A — Monolith PCI Scope (The "Flat" Perimeter) If we ingest raw PAN directly, the entire monolith becomes the Cardholder Data Environment (CDE), placing every developer and pipeline under Level 1 audit scrutiny. Diagram B — Microservices/Isolation Scope (The "Minimized" Perimeter) By utilizing a Tokenization Proxy at the edge and AWS Payment Cryptography, the core Ledger and Fraud modules only process non-reversible tokens. (Note: AWS Nitro Enclaves can further isolate cryptographic operations, but introduce lifecycle/attestation complexity that we will defer to Phase 2). QSA Scoping Strategy: Data Elements: PAN and Sensitive Authentication Data (SAD) are restricted to the Ingress boundary. Only Tokens enter the Non_CDE. Prohibited Areas: PAN is strictly prohibited from CloudWatch logs, APM telemetry (Datadog), and developer crash dumps [medium.com]. Artifacts: We will maintain a continuously updated Data Flow Diagram (DFD) and Data Element Inventory via our Infrastructure as Code (IaC) repository to prove isolation to the QSA. Deliverable 4 — Decision Framework: The Synthesis To finalize the architectural path, engineering leadership must align on the following logic tree: Team Capacity: Do we have at least 2 full-time Platform/DevOps engineers to manage service discovery, mTLS, and distributed tracing? No $\rightarrow$ Proceed to Node 2. Compliance Timeline: Is SOC 2 Type II and PCI Level 1 required within the next 6–9 months to close enterprise deals? Yes $\rightarrow$ Proceed to Node 3. Infrastructure Automation: Are we using Terraform/AWS CDK to automate 100% of AWS Config, Security Hub, and CloudTrail evidence collection? Yes $\rightarrow$ Proceed to Node 4. Data Sensitivity: Can we enforce a strict Token-First ingress so the core Ledger never processes a raw PAN? Yes $\rightarrow$ Proceed to Node 5. State Machine Correctness: Are we implementing a Transactional Outbox pattern to ensure async FedNow settlement callbacks do not cause ledger drift? Yes $\rightarrow$ Final Recommendation. The Three Paths Path A — Modular Monolith (Default Recommendation): Build a single deployment unit on AWS Fargate with strictly separated internal modules. Primary Risk: Tight coupling of code over time if "shortcuts" are taken between logical module boundaries. Path B — Macro-service Architecture: 3–4 services (e.g., Gateway, Ledger, Auth) using shared compliance sidecars. Primary Risk: Increased complexity in maintaining idempotency and outbox patterns across service boundaries for FedNow's sub-second window. Path C — Full Microservices Mesh: 10+ granular services. Primary Risk: Complete audit failure due to "Evidence Fatigue" and inconsistent control implementation across services. SOC 2 Type II Evidence Roadmap (Path A) Trust Services Criteria Control Intent Evidence Artifact Automation Tooling Owner / Cadence Security (CC6.1) Logical Access MFA enforcement logs, Role-based access matrices. AWS IAM / Vanta DevOps / Quarterly Security (CC8.1) Change Mgmt PRs linked to Jira, passing CI/CD vulnerability scans. GitHub Actions / Snyk Eng Lead / Continuous Availability (A1.2) DR & Backups Automated DB snapshot logs, tabletop DR exercise results. AWS Backup Platform / Bi-Annually Processing Integrity Ledger Correctness Reconciliation reports (Ledger State vs. Rail Settlement). Custom Audit Worker Finance / Daily Strategic Note: EU PSP mandatory reporting and IPR requirements take effect April 2026 [2], [9]. This creates a hard external forcing function on our audit readiness timeline. Any architectural experimentation that delays SOC 2/PCI certification beyond late 2025 risks missing the window for cross-border expansion. Sources [2] EU Fintech Regulations 2026: 9 Changes You Must Prepare For — https://www.powens.com/blog/eu-fintech-regulations-2026/ [3] Choosing the Right Core Architecture for a Fintech Startup - OceanoBe — https://oceanobe.com/news/choosing-the-right-core-architecture-for-a-fintech-startup/1787 [4] Modular Monolith vs Microservices Startups and Universities — https://www.linkedin.com/pulse/copy-stop-building-millions-when-you-have-hundreds-your-nithadya-oufqc [6] Microservices vs Modular Monolith in 2026 - ancient.global — https://www.ancient.global/en/blogs-ancient/microservices-vs-modular-monolith-2026 [8] PSD3 and PSR: From provisional agreement to 2026 readiness — https://www.nortonrosefulbright.com/en/knowledge/publications/cedd39c6/psd3-and-psr-from-provisional-agreement-to-2026-readiness [9] EU Payment Regulations 2026: What You Need to Know Brite — https://britepayments.com/resources/article/payment-regulations-2026/ [10] The True Cost of Microservices - Quantifying Operational Complexity — https://www.softwareseni.com/the-true-cost-of-microservices-quantifying-operational-complexity-and-debugging-overhead/ [11] Microservices vs Monolith: What I Learned Building Two Fintech Marketplaces — https://frombadge.medium.com/microservices-vs-monolith-what-i-learned-building-two-fintech-marketplaces-under-insane-deadlines-fe7a4256b63a [12] PCI Scope Reduction: Strategies to Simplify Compliance — https://www.pcicompliance.com/pci-scope-reduction/ [13] Ultimate Guide to PCI DSS Compliance in 2026 - Venn — https://www.venn.com/learn/pci-dss-compliance/ [14] Real-time vs instant payments: Comparing RTP and FedNow — https://www.citizensbank.com/corporate-finance/insights/comparing-instant-payments-and-real-time-payments.aspx