Technology Stack

ID.Banking is built on a modern, battle-tested technology stack selected for performance, auditability, and operational resilience in regulated financial environments.

Architecture Overview

flowchart TB
  subgraph clients["Client Layer"]
    direction LR
    SPA["Angular SPA"] 
    TPP["Third-party Apps"]
  end
  subgraph api["API Layer (.NET 10)"]
    direction LR
    REST["REST APIs"]
    GRPC["gRPC Internal"]
  end
  subgraph services["Event-Sourced Services"]
    direction LR
    ES["Event Store"]
    CQRS["CQRS Projections"]
  end
  subgraph data["Data Layer (PostgreSQL)"]
    direction LR
    PG["Primary DB"]
    REP["Read Replicas"]
  end
  clients --> api --> services --> data

.NET 10 Runtime & API Layer

The platform API layer runs on .NET 10, delivering sub-millisecond endpoint response times under load. Each service domain exposes RESTful APIs with OpenAPI documentation, enabling third-party integration and developer self-service.

• Minimal API endpoints for low-overhead request handling
• Native dependency injection for testability and modularity
• gRPC inter-service communication for internal high-frequency paths
• Structured logging with correlation IDs across service boundaries

PostgreSQL with Read Replicas

PostgreSQL serves as both the primary transactional database and the event store backing the event sourcing architecture.

• Streaming replication to read replicas for query load distribution
• Connection pooling via PgBouncer for efficient resource utilization
• Partitioned tables for high-volume event streams (transactions, audit logs)
• Point-in-time recovery with continuous WAL archiving

Event Sourcing & Immutable Audit Trail

Every state change in the platform is captured as an immutable event, providing a complete, tamper-evident history of all financial operations.

• Full reconstruction of any account state at any point in time
• Built-in regulatory compliance through append-only event logs
• Event replay for debugging, reconciliation, and disaster recovery
• CQRS pattern separating write models from optimized read projections

BIAN-Aligned Service Domains

The platform’s microservices map directly to BIAN (Banking Industry Architecture Network) service domains, ensuring architectural clarity and standards compliance.

• Ledger → BIAN Current Account, Savings Account
• Payments → BIAN Payment Execution, Payment Order
• Lending → BIAN Consumer Loan, Credit Facility
• Cards → BIAN Card Transaction, Card Authorization
• Treasury → BIAN Treasury Management
• Fraud → BIAN Fraud Detection, Fraud Resolution

Sample Service Configuration

# docker-compose service definition
services:
  ledger-api:
    image: idbanking/ledger-api:latest
    environment:
      - ASPNETCORE_ENVIRONMENT=Production
      - ConnectionStrings__Primary=Host=pg-primary;Database=ledger;
      - ConnectionStrings__ReadReplica=Host=pg-replica;Database=ledger;
      - EventStore__Provider=PostgreSQL
      - EventStore__SnapshotInterval=100
    deploy:
      replicas: 3
      resources:
        limits:
          memory: 512M
          cpus: "1.0"
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8080/health"]
      interval: 10s
      timeout: 5s
      retries: 3

Containerized Deployment

Every service runs as an isolated container, deployed and orchestrated via Kubernetes in production environments.

• Helm charts for repeatable, versioned deployments
• Horizontal Pod Autoscaler for traffic-responsive scaling
• Liveness and readiness probes for zero-downtime rolling updates
• Network policies enforcing least-privilege inter-service communication
• Secrets management via Kubernetes sealed secrets

Infrastructure Characteristics