Integration Strategy

How Anchita connects to the outside world — real payment APIs, high-fidelity mock services, and a synthetic data pipeline.

The Problem
Three-Layer Integration Architecture
Layer 1 — Real Third-Party APIs
Layer 2 — Mock Services
1. Mock Service Catalogue
Layer 3 — Synthetic Data Pipeline
How It Connects to the Anchita Digital Banking Portal
Architectural Rationale

The Problem

Treasury banking platforms interact with a wide range of external systems — payment rails, core banking ledgers, compliance screening services, and market data feeds. In a production bank, access to these systems requires institutional licensing, proprietary contracts, and in some cases regulatory approval (e.g., Fedwire and SWIFT participation require Federal Reserve membership or correspondent relationships).

A portfolio or greenfield implementation cannot obtain those credentials. The naive response is to stub everything with a simple in-memory mock that always returns 200 OK. The result is a system that looks correct in tests but has never confronted real API behaviour — rate limits, idempotency requirements, webhook sequencing, partial failures, and realistic data shapes.

Anchita takes a different approach.

Three-Layer Integration Architecture

┌──────────────────────────────────────────────────────────────────┐
│              ANCHITA PLATFORM  (Spring Boot + Temporal)             │
│      Onboarding Workflows · AI Agents · Product Provisioning     │
└──────┬──────────────────────┬──────────────────────┬────────────┘
       │                      │                      │
       ▼                      ▼                      ▼
┌─────────────┐   ┌───────────────────────┐   ┌──────────────────┐
│  REAL APIs  │   │   MOCK SERVICES       │   │  SYNTHETIC DATA  │
│ (free tiers)│   │  (built in-repo)      │   │  (generated)     │
│             │   │                       │   │                  │
│ Stripe      │   │ Core Banking Ledger   │   │ Company profiles │
│ Plaid       │   │ Wire Transfer Network │   │ Transaction logs │
│ FRED API    │   │ AML Screening Service │   │ Market rate data │
│ Twilio      │   │ Instant Payments      │   │ AML watchlists   │
│ SendGrid    │   │ BAI2 Generator        │   │                  │
└─────────────┘   └───────────────────────┘   └──────────────────┘

Every adapter in Layer 5 — Integration Services maps to one of these three categories. The adapter interface is identical regardless of category — only the base URL and credentials change between environments.

Layer 1 — Real Third-Party APIs

These are production-quality APIs with free sandbox or test modes. Every call made against them is real HTTP — real request/response cycles, real error codes, real webhook deliveries. This is the most direct way to learn how payment infrastructure actually behaves.

Stripe

Stripe’s test mode is unlimited and fully featured — all APIs behave identically to production; only settlement is simulated.

Stripe Product	Anchita Usage	Product Catalog Mapping
ACH Direct Debit	ACH collection — pull funds from client accounts	ACH Collection (#2)
ACH Payouts	ACH origination — push funds from client accounts	ACH Origination (#1)
Stripe Issuing	Commercial card program setup, spend controls, GL coding	Commercial Card / P-Card (#17)
Stripe Radar	Real-time fraud scoring on payment transactions	All payment products
Stripe Identity	KYC document verification during onboarding	Onboarding Phase 2
Financial Connections	Bank account linking and verification (alternative to Plaid)	Onboarding Phase 1

What this demonstrates: Webhook idempotency, payment retry design, ACH return code handling (R01–R29), card program lifecycle management.

Plaid

Plaid’s Sandbox environment is free and returns realistic, structured financial data.

Plaid Product	Anchita Usage
Link SDK	OAuth bank account linking during onboarding intake
Auth API	Account and routing number verification
Identity API	Identity verification against bank-held data
Transactions API	Account aggregation in the Anchita Digital Banking Portal
Balance API	Real-time balance checks for liquidity dashboards

What this demonstrates: OAuth re-auth flow handling for stale connections, transaction normalisation across institutions, webhook-driven balance update design.

FRED API (Federal Reserve)

The Federal Reserve’s FRED (Federal Reserve Economic Data) API is completely free with no rate limits for reasonable usage. It provides real historical and current time-series data.

Data Series	Anchita Usage
Fed Funds Rate	Investment Sweep threshold modelling (#19)
SOFR (Secured Overnight Financing Rate)	Floating rate benchmark for sweep products
Treasury Yield Curve	Investment analytics in the portal
EUR/USD, GBP/USD, JPY/USD exchange rates	Foreign Currency Account dashboard (#21)

What this demonstrates: Using real market data makes the portfolio realistic — the numbers move like the real world, not like a random number generator.

Notification Infrastructure

Service	Free Tier	Anchita Usage
Twilio	Free trial credits	SMS alerts, 2FA for the Anchita Digital Banking Portal
SendGrid	100 emails/day	Statement delivery, onboarding notifications, alert emails

Layer 2 — Mock Services

These are systems that require financial institution licensing or proprietary commercial agreements — Fedwire participation requires Federal Reserve membership; SWIFT access requires a correspondent bank relationship; DTCC clearing requires broker-dealer registration.

The correct engineering response is not to fake them with a stub that always returns success. It is to build a high-fidelity mock service that replicates the real system’s API contract, state machine, error conditions, and webhook behaviour — so the Anchita workflow code is tested against realistic external system behaviour.

Each mock service is a standalone Spring Boot or FastAPI service with:

A versioned OpenAPI 3.0 spec (the same contract used in tests and production)
A realistic state machine (not just 200 OK on every call)
Webhook / callback delivery for async operations
Configurable failure injection for resilience testing

Mock Service Catalogue

Core Banking Ledger

The foundational truth store — accounts, balances, and transactions. Every product in the catalog reads from and writes to this service.

Accounts:     DDA · ZBA · Money Market · Foreign Currency
Transactions: Event-sourced append-only log; balance computed on read
API:          POST /accounts · POST /transactions · GET /accounts/{id}/balance
Stack:        Python / FastAPI + PostgreSQL

Maps to: ZBA (#18), all account-based provisioning workflows.

Wire Transfer Network (Fedwire + SWIFT stub)

Simulates domestic and international wire settlement with realistic timing and state transitions.

State machine: INITIATED → VALIDATED → SENT → CONFIRMED
               └──────────────────────────────→ REJECTED
                                                → RETURNED

Domestic:      Settlement window — configurable (hours)
International: SWIFT BIC validation · MT103 message stub · 1–2 day settlement simulation
Delivery:      Status webhooks at each state transition

Maps to: Wire Domestic (#3), Wire International (#4).

AML Screening Service

A rule-based compliance screening service backed by a synthetic watchlist modelled on the OFAC SDN list format.

Watchlist:  500 fictional high-risk entities (individuals + organisations)
Screening:  Name fuzzy-match · geography risk · transaction amount thresholds
Response:   { risk_score, match_found, match_details, recommended_action }

Used in: Onboarding Phase 3 — Compliance Gate.

Instant Payments Network (RTP + FedNow stub)

Simulates real-time payment rails with sub-second settlement.

Protocol:  Webhook-driven credit notification to receiving account
Timing:    Configurable settlement delay (default: < 1 second)
Errors:    Insufficient funds · account not found · participant not enrolled

Maps to: RTP (#5), FedNow (#6).

BAI2 / MT940 Report Generator

Produces valid, parseable BAI2 and SWIFT MT940 files from Core Banking Ledger transactions. BAI2 is the industry-standard format for bank-to-corporate account reporting.

Input:   Transactions from Core Banking Ledger (date range + account filter)
Output:  Valid BAI2 file (Type 02/03/16/49/88/98/99 records)
         Valid SWIFT MT940 statement message
Use:     Downloaded by clients from Anchita Digital Banking Portal

Maps to: Information Reporting (#22).

Additional Mock Services (planned)

Service	Replaces	Maps to
Lockbox Processing Service	Physical check / remittance intake	Lockbox Wholesale (#11), Retail (#12), RDC (#13)
Trade Finance Service	LC issuance platform	Trade Finance (#23)
IntraFi / CDARS Placement	Deposit network placement	CDARS / ICS (#20)

Layer 3 — Synthetic Data Pipeline

Realistic data is essential for meaningful demos, load testing, and portfolio presentation. A system that only runs against {"name": "Test Company", "amount": 100} does not demonstrate anything about real-world behaviour.

The Anchita synthetic data pipeline produces:

Dataset	Generator	Approach
Company profiles	Python `Faker` library	Realistic names, TINs, SIC codes, officer names, addresses
Corporate account hierarchies	Custom generator	ZBA parent/child structures — 1 concentration, 3–8 disbursement accounts
Transaction histories	Pattern-based generator	Payroll runs (bi-weekly ACH debits), vendor payments (weekly), wire transfers
AML watchlist	Faker + OFAC SDN templates	500 fictional high-risk entities in standard SDN format
FX rate series	FRED API (real data)	EUR/USD, GBP/USD, JPY/USD — 5 years of real historical rates
Interest rate curves	FRED API (real data)	Fed Funds Rate, SOFR, Treasury yields — real historical series
BAI2 statement files	BAI2 generator (above)	Produced from synthetic transaction histories

Key principle: Market data (FX rates, interest rates) uses real FRED data — not generated numbers. This means the rates in the system move the way real rates move: trending, reverting, volatile during crisis periods. A demo using real rate history is immediately more credible than one using random.uniform(1.0, 1.5).

How It Connects to the Anchita Digital Banking Portal

The Anchita Digital Banking Portal — the React web application that treasury clients use after onboarding — draws on all three integration layers at runtime:

Portal Feature	Integration Source
Account balances	Core Banking Ledger (mock)
ACH payment initiation	Stripe ACH API (real)
Wire transfer initiation	Wire Transfer Network (mock)
External account linking	Plaid Link SDK (real)
Transaction history	Core Banking Ledger (mock)
BAI2 statement download	BAI2 Generator (mock)
FX rate dashboard	FRED API (real)
SMS / email alerts	Twilio + SendGrid (real)

The portal does not know or care which category a service falls into. Every integration is behind a Spring Boot adapter with the same interface — the category distinction is a deployment and credentials concern, not a code concern.

Architectural Rationale

This three-layer approach is a deliberate engineering decision, not a workaround. It enforces several properties that matter in production systems:

Identical adapter interface regardless of backing. The workflow code calls wireTransferAdapter.initiateWire(request) — whether that call hits a real Fedwire participant or the mock Wire Transfer Network is controlled by configuration, not code. This is the same pattern a real bank would use to swap between test and production environments.

Realistic failure modes from day one. Real APIs return 409 Conflict on idempotency violations, 422 Unprocessable Entity on validation failures, and deliver webhook retries with exponential backoff. The mock services are designed to replicate these behaviours — so the circuit breaker, retry, and dead-letter paths in the workflow are tested against real failure shapes, not just happy-path stubs.

Synthetic data that behaves like real data. Transaction patterns follow realistic timing distributions. Market rates follow real historical series. AML watchlists follow standard data formats. A system tested against realistic data surfaces edge cases that fake data never would.