Skip to content
Al Shakib E Elahi
01Trade finance · ISO 20022

SwiftFusion

SwiftFusion is a trade finance application built on the SWIFT ISO 20022 messaging standard, running inside BankUltimus - the core banking platform Leads Corporation ships to financial institutions. Spring Boot on the backend, Angular 19 on the front, Apache Kafka carrying events between services and gRPC handling the synchronous calls. It is containerised with Docker and deployed into the NRBC Bank and Southeast Bank environments.

Year
2025
Role
Software Engineer - Trade Finance team
Context
Leads Corporation Ltd.
Category
Fintech
Ordering bankMT / ISO 20022SwiftFusionSpring Boot · Angular 19ISO 20022 schema validationBeneficiarySettlementAPACHE KAFKA · EVENT BACKBONETwo-Phase CommitBlocking, trusted participantsSagaChoreographed, compensatingHybrid coordinationPer-workflow tradeoffRUST · ACTIX WEB ORCHESTRATORgRPC between services · Prometheus, Grafana, Elasticsearch across all of itpacs.008

Built for banking clients - the interface and message contents are covered by client confidentiality. The diagram below describes the architecture at the level already published in my CV, and shows no institution's data.

01The problem

The payments industry is migrating off MT - a telex-era format of positional, free-text fields - onto ISO 20022, which is structured, richly typed and validated. The migration is not a translation exercise. Every producer, every consumer and every stored record has to agree on the same shape at the same time, while the old format keeps flowing, because a bank cannot stop clearing payments for a quarter to finish a refactor.

02The approach

The message schema is treated as the contract rather than the output. Inbound instructions are validated against ISO 20022 before anything downstream sees them, so a malformed message fails at the boundary with a precise reason instead of three services deep with a null reference. Kafka decouples the parties that produce a message from the ones that act on it, which means a slow downstream consumer creates a lag metric rather than a timeout at the teller. gRPC handles the calls that genuinely need an answer before proceeding, with generated stubs keeping both sides of every contract in step. Because a trade finance transaction spans several services and cannot be wrapped in one database transaction, coordination runs through a dedicated orchestrator - written in Rust on Actix Web - implementing Two-Phase Commit, choreographed Saga and hybrid models, chosen per workflow according to how much blocking that particular flow can tolerate.

03Architecture

How the pieces fit.

  1. Messaging standard

    SWIFT ISO 20022 - structured, validated financial messages replacing positional MT formats. Validation happens at the edge, so an invalid message never becomes partial state.

  2. Backend

    Spring Boot services owning the trade finance domain, message construction and validation against the standard's schemas.

  3. Frontend

    Angular 19 - the operator-facing surface where trade finance instructions are raised, checked and authorised.

  4. Event backbone

    Apache Kafka for event-driven messaging between services. Producers do not know their consumers, so a new downstream reader is a subscription rather than a release.

  5. Service calls

    gRPC for inter-service communication where a caller needs a synchronous answer, with generated stubs holding both ends of the contract to the same definition.

  6. Transaction coordination

    A Rust / Actix Web orchestrator implementing Two-Phase Commit, choreographed Saga and hybrid models, selected per workflow by how much blocking it can afford.

  7. Observability

    Prometheus for metrics, Grafana for dashboards and Elasticsearch for log search - so a stuck message is a question you can answer rather than one you reproduce.

  8. Packaging

    Docker containers, deployed into the NRBC Bank and Southeast Bank environments. An environment is reproducible rather than remembered.

04Tech stack
JavaSpring BootAngular 19Apache KafkagRPCRustActix WebDockerISO 20022PrometheusGrafanaElasticsearch

Deployment

  • Docker containers per service, promoted through environments as images
  • Deployed to the NRBC Bank and Southeast Bank environments
  • Prometheus scraping, Grafana dashboards and Elasticsearch-backed log search
05Key features
  • ISO 20022 message construction and schema validation at the system boundary
  • Event-driven flows over Apache Kafka, decoupling producers from consumers
  • gRPC service-to-service calls with generated, versioned contracts
  • Distributed transaction coordination via 2PC, Saga and hybrid models
  • Metrics, dashboards and log search across every service in the path
  • Containerised deployment into multiple independent bank environments
06Challenges

The parts that were not obvious at the start.

  1. 01

    Correctness is the feature

    In consumer software a bug degrades an experience. In financial messaging a bug moves money to the wrong place, and the fix has to be auditable months later by someone who was not there. Idempotency and reconciliation are designed in at the first commit, because retrofitting them means reconstructing history you no longer have.

  2. 02

    No transaction spans the whole flow

    A trade finance operation touches several services and at least one external network. There is no database transaction that covers it. That is what pushed the work toward an explicit orchestrator: 2PC where blocking is acceptable and the participants are trusted, Saga where a long-running flow has to stay available and compensate instead of lock.

  3. 03

    Two banks, one codebase

    Each institution has its own environment, its own operational constraints and its own release cadence. Anything specific to one of them lives in configuration rather than in a branch, because a branch per customer is a promise to maintain a fork forever.

  4. 04

    Reading the standard twice

    ISO 20022 is large, and the temptation is to implement from an example message. Examples encode one institution's optional-field choices. Working from the schema rather than the sample is slower on day one and considerably faster on the day a counterparty sends something the sample never showed.

07Results
  • Live in the NRBC Bank and Southeast Bank environments
  • Trade finance flows carried on the ISO 20022 standard rather than positional MT formats
  • Event-driven service topology with metrics, dashboards and alerting across the path
08What I took from it
  • Validate at the boundary. A message that fails at the edge costs a rejection; one that fails three services deep costs an investigation.
  • Pick the coordination model per workflow. Reaching for 2PC everywhere trades availability you needed for consistency you already had.
  • Standards exist because every institution that skipped them rebuilt the same integration twice.