Chapter 2: Payment Architecture & Design

In this chapter: We dive deep into the architectural patterns and design principles for building robust cross-border payment systems using the WIA-FIN-014 standard's 4-phase framework.

2.1 System Architecture Overview

A well-designed cross-border payment system must handle complex workflows, ensure data consistency across borders, maintain security, and provide real-time visibility. The WIA-FIN-014 architecture is built on microservices principles with clear separation of concerns.

WIA-FIN-014 System Architecture

🎯 Application Layer

Client Applications | Admin Dashboards | Mobile Apps | Integration Tools

🔌 API Gateway Layer

Authentication | Rate Limiting | Load Balancing | API Versioning

⚙️ Business Logic Layer

Payment Service | FX Service | Compliance Service | Notification Service

🌐 Integration Layer

SWIFT Connector | SEPA Gateway | Blockchain Bridge | Bank APIs

💾 Data Layer

Transaction DB | User DB | Compliance DB | Analytics DB | Cache Layer

2.2 Core Components

Payment Processing Engine

The heart of the system, responsible for orchestrating payment workflows, managing state transitions, and coordinating with external networks.

Key Responsibilities:

Payment validation and pre-processing
Routing decisions based on corridor, amount, and speed requirements
State machine management for payment lifecycle
Retry logic and error handling
Settlement confirmation and reconciliation

Foreign Exchange (FX) Engine

Manages currency conversion with real-time rates, spreads management, and hedging capabilities.

interface FXEngine {
  // Get real-time exchange rate
  getRate(from: Currency, to: Currency): Promise<FXRate>;

  // Execute currency conversion
  convert(amount: Money, targetCurrency: Currency): Promise<ConversionResult>;

  // Lock rate for future settlement
  lockRate(from: Currency, to: Currency, duration: number): Promise<RateLock>;
}
        

Compliance Engine

Automated compliance checks including AML screening, sanctions verification, and regulatory reporting.

Sanctions Screening: Real-time checks against OFAC, EU, and UN sanctions lists
AML Rules Engine: Pattern detection for suspicious activities and transaction monitoring
KYC Verification: Identity verification and customer due diligence workflows
Regulatory Reporting: Automated generation of required regulatory reports

2.3 The 4-Phase Implementation Framework

Phase 1: Data Format Standards

Foundation layer defining message formats, data schemas, and encoding standards. Based on ISO 20022 with extensions for modern payment rails.

// Payment Message Schema (ISO 20022 Extended)
{
  "messageId": "TXN-20250001",
  "creationDateTime": "2025-12-25T14:30:00Z",
  "numberOfTransactions": 1,
  "controlSum": 1000.00,
  "initiatingParty": {
    "name": "John Doe",
    "identification": "US-123456789",
    "country": "US"
  },
  "paymentInformation": {
    "paymentMethod": "SWIFT",
    "requestedExecutionDate": "2025-12-25",
    "debtorAccount": {
      "currency": "USD",
      "identification": "US123456789012"
    },
    "creditorAccount": {
      "currency": "PHP",
      "identification": "PH098765432109"
    },
    "amount": {
      "instructedAmount": 1000.00,
      "currency": "USD"
    }
  }
}
        

Phase 2: API Specifications

RESTful API layer providing standardized endpoints for all payment operations.

Core API Endpoints:

POST /v1/payments - Initiate payment
GET /v1/payments/{id} - Get payment status
GET /v1/fx/rates - Get current FX rates
POST /v1/beneficiaries - Add beneficiary
GET /v1/corridors - Query available payment corridors
POST /v1/quotes - Get payment quote

Phase 3: Protocol Integration

Integration protocols for connecting to payment networks, banks, and settlement systems.

SWIFT Integration: MT and MX message formats, SWIFT GPI tracking
SEPA Instant: SCT Inst protocol, instant EUR settlements
Blockchain Rails: Ethereum, Stellar, or custom networks for tokenized settlements
Real-Time Payment Systems: FedNow, RTP, UPI integration

Phase 4: Ecosystem Integration

Connectors and adapters for integrating with external systems and enterprise applications.

Integration Points:

Core Banking Systems: Temenos, Finastra, Mambu integrations
ERP Systems: SAP, Oracle, NetSuite connectors
Treasury Management: Kyriba, FIS integration
Compliance Platforms: ComplyAdvantage, Refinitiv screening
Analytics Tools: Tableau, PowerBI dashboards

2.4 Data Models

Payment Transaction Model

class PaymentTransaction {
  id: string;                    // Unique transaction ID
  status: PaymentStatus;         // PENDING | PROCESSING | COMPLETED | FAILED
  sender: Party;                 // Sender information
  recipient: Party;              // Recipient information
  sourceAmount: Money;           // Amount in sender currency
  destinationAmount: Money;      // Amount in recipient currency
  exchangeRate: number;          // Applied FX rate
  fees: Fee[];                   // Transaction fees
  route: PaymentRoute;           // Selected payment rail
  metadata: Map<string, any>;    // Additional metadata
  timestamps: Timestamps;        // Creation, processing, completion times
  compliance: ComplianceCheck;   // Compliance verification results
}
        

Payment Lifecycle States

The payment state machine ensures consistent handling across all payment types:

CREATED: Payment request received and validated
PENDING_COMPLIANCE: Undergoing AML/KYC checks
APPROVED: Compliance checks passed
PROCESSING: Submitted to payment network
PENDING_SETTLEMENT: Awaiting final settlement
COMPLETED: Successfully settled
FAILED: Payment failed (with reason code)
REVERSED: Payment reversed or refunded

2.5 Design Principles

🔄 Idempotency: All API operations must be idempotent to handle retries safely

🎯 Eventual Consistency: Accept eventual consistency for non-critical operations

📊 Audit Trail: Maintain complete audit logs for all state transitions

🔐 Security First: Encrypt sensitive data, implement least privilege access

⚡ Performance: Design for horizontal scalability and sub-second response times

🛡️ Resilience: Circuit breakers, bulkheads, and graceful degradation