One SDK, Ten Banks: The Engineering Behind a Unified FD API

The Engineering Challenge

When we set out to build Blostem's API, we faced a fundamental engineering challenge: every bank has its own API, its own data formats, its own error handling, and its own quirks. How do you create a single, elegant SDK that abstracts all of this complexity?

Our Architecture

At its core, Blostem's API follows a unified adapter pattern. Here's how it works:

Layer 1: Partner SDK

The outward-facing layer that fintech partners interact with. This is a clean, well-documented REST API with consistent request/response formats regardless of which bank is being used under the hood.

Layer 2: Orchestration Engine

The middle layer handles routing, rate selection, compliance checks, and transaction orchestration. When a partner sends an FD booking request, the orchestration engine:

• Validates all inputs against bank-specific rules
• Runs compliance checks (KYC verification, PAN validation)
• Selects the optimal payment method
• Manages the multi-step booking flow

Layer 3: Bank Adapters

Each bank has a dedicated adapter that translates our standardized format into the bank's specific API format. This is where we handle the complexity so our partners don't have to.

Key Design Decisions

Idempotency First: Every API call is idempotent. Network failures, timeouts, and retries are handled gracefully without duplicate transactions.

Event-Driven: We use an event-driven architecture for the booking flow. Each step emits events that partners can subscribe to for real-time status updates.

Schema Validation: Every request is validated against bank-specific schemas before hitting the bank's API. This catches errors early and provides clear, actionable error messages.

The Result

Partners integrate once and get access to all banks. Adding a new bank to our platform doesn't require any changes on the partner side. This is the power of building at the infrastructure layer.

Performance

Our average API response time is under 200ms for non-blocking operations. For operations that require bank callbacks (like KYC verification), we use webhooks to push updates in real-time.

What We Learned

Building a truly unified API across multiple banks taught us that the devil is in the details. Edge cases, error handling, and graceful degradation are what separate a working integration from a production-ready one.