Legacy Core Banking Integration for a Trade Finance Platform
A 14-bank trade-finance platform in three countries uses a permissioned blockchain for import letters of credit. Banks still run COBOL core systems; one can only exchange files by SFTP every 30 minutes, another exposes SOAP, and a third has no API. Daily volume is 2,000 transactions; 3% of messages fail reconciliation because of duplicate reference numbers and time-zone cutoff differences. The platform must exchange ISO 20022 messages, map from legacy MT700, and support a 90-day parallel run. Regulators require an audit trail for 7 years. The program director wants 'real-time APIs for everything' and a single cutover weekend. The platform processes $4.2 billion annually; a failed cutover would stop shipments. Only two banks have dedicated integration teams.
1. Design the integration architecture between the permissioned blockchain and the 14 banks' legacy systems. What should the program director be told about 'real-time APIs for everything'?
Read the worked answer
Use an adapter/gateway layer per bank, not a single 'real-time API for everything.' A canonical message model based on ISO 20022; each bank adapter maps from MT700/SOAP/SFTP/core formats into canonical events and back. The blockchain holds shared state and audit trail; core banking remains system of record for balances.
For the SFTP-only bank, a scheduled adapter with 30-minute batches is acceptable if the business process tolerates it; expose status via API. For the no-API bank, use a secure file drop plus operator workflow, not screen scraping. Place an integration gateway with message queue, retry, dead-letter queue, schema validation, and observability. Use private channels/collections if pricing or bank-specific data must be segregated. This is more realistic than a single weekend cutover.
2. How should the platform achieve idempotency and reconciliation given duplicate reference numbers and time-zone cutoffs?
Read the worked answer
Idempotency and reconciliation:
- Every message gets an end-to-end ID and a business key (LC number, bank, version). Adapters must enforce idempotency on both inbound and outbound; duplicate reference numbers should be rejected or mapped, not overwritten.
- Use an outbox pattern: write to local database and queue atomically; publish to blockchain; record acknowledgement.
- Daily reconciliation compares blockchain state, core banking, and SWIFT/ISO messages; 3% failure rate should be triaged by root cause (duplicate references, time-zone cutoff, schema mapping).
- Define cutoff times in UTC and display local; version messages; keep a 7-year WORM archive of raw messages and blockchain transaction IDs.
- Do not use 'last write wins' for status; use state-machine transitions with validations.
3. What cutover and parallel-run plan should the consortium use instead of a single cutover weekend?
Read the worked answer
Cutover:
- Reject a single weekend. Pilot 2 banks and one trade corridor for 90 days in parallel; run shadow mode where messages are processed but not binding.
- Use feature flags by bank/corridor; keep the legacy path available for rollback.
- Cut over in waves, starting with low-value letters of credit; define exit criteria: reconciliation match >99.5%, no unresolved duplicates, latency within SLA, audit trail complete.
- Avoid dual-write as source of truth; if dual-running, designate one authoritative system and reconcile.
- Freeze changes during cutover; have runbooks, on-call, and a go/no-go committee. Operational readiness includes 7-year retention, key management, and incident response.