Bank of America Software Engineer Case Interview — Secure Real‑Time Payments and Risk Controls

This case mirrors Bank of America’s scenario‑based, panel‑style interview used for software engineering roles. You will design and reason about a secure, highly available real‑time payments authorization and fraud‑check service that integrates with KYC/AML, sanctions screening, and card/bank rails. Expect a structured discussion with a senior engineer and a tech lead focused on: 1) Problem framing and requirements: Clarify functional flows (authorize, post, reverse, refund), idempotency and duplicate detection, transaction state machine, cut‑off and settlement windows, and upstream/downstream integrations (fraud, ledger, notifications). Elicit non‑functional targets (latency/throughput, availability, RTO/RPO, data retention) and SLAs/SLOs. 2) Architecture and design: Propose APIs (REST/gRPC), request/response schemas with idempotency keys and correlation IDs, data model (relational source of truth; event streams for downstream consumers), and core components (auth service, fraud/KYC adapters, ledger writer, outbox/saga for consistency). Discuss patterns relevant to BoA systems: synchronous auth with asynchronous clearing, Kafka‑backed events, exactly‑once‑like processing via idempotency/outbox, backpressure, rate limiting, and rollout strategies (blue/green, canary, feature flags). 3) Security and compliance emphasis (culture‑specific): Design for least privilege, strong authentication/authorization, TLS in transit, encryption at rest with managed keys/HSMs, tokenization of PAN/PII, audit logging with immutable trails, and data minimization/segmentation. Show awareness of controls and regulations commonly encountered in a large U.S. bank (e.g., PCI DSS for card data, GLBA privacy, SOX change controls), threat modeling (STRIDE), segregation of duties, and change‑management gates. BoA interviewers expect a “risk is everyone’s job” mindset aligned with Responsible Growth. 4) Resiliency and operations: Active‑active or active‑passive multi‑region thinking, failover and DR, retries with backoff and idempotent handlers, circuit breakers, timeouts, ledger consistency trade‑offs, incident response playbooks, and observability (metrics/traces/logs, dashboards, SLOs/alerts). Be ready to walk through a production incident and how you would detect, mitigate, and communicate with stakeholders. 5) Implementation depth: Whiteboard an endpoint for idempotent payment authorization and discuss concurrency control, database transactions, and schema evolution. A brief coding or pseudo‑coding segment (often Java/Python) may ask you to implement deduplication with a unique key and handle race conditions safely. 6) Collaboration and communication: Expect behavioral probes using STAR to assess partnering with compliance, security, QA, and business stakeholders, plus how you document decisions, manage trade‑offs, and navigate deadlines without compromising controls. Format guide (typical): 5 min problem setup → 25–30 min system design → 10–15 min risk/security/resiliency deep dive → 5–10 min implementation sketch/coding → 5 min Q&A. Evaluation focuses on clarity, trade‑off reasoning, production readiness, control mindset, and pragmatic design aligned to a large, regulated enterprise.