DEV Community

Cover image for How to Design Reliable Multi-Lender Workflows in a Fintech Platform
Sneha Wani
Sneha Wani

Posted on

How to Design Reliable Multi-Lender Workflows in a Fintech Platform

#ai #backend #fintech #architecture

Building a fintech platform that connects users with multiple financial institutions is not just a frontend problem.

A simple user journey might look like this:

User → Application → Verification → Data Processing → Partner Routing → Status Updates
Enter fullscreen mode Exit fullscreen mode

But behind that flow, the system may need to handle different APIs, response formats, validation rules, timeouts, retries, failures, and asynchronous updates.

The real engineering challenge is creating a consistent experience while integrating with systems that may behave very differently.

This article explores some of the architectural principles behind reliable multi-partner fintech workflows.

The Core Challenge: One User Journey, Multiple Systems

Imagine a platform connected to several lending partners.

Each partner may have its own:

  • API structure
  • Authentication method
  • Required fields
  • Response format
  • Status values
  • Processing times
  • Error messages

You don't want the frontend to understand all those differences.

A user should not need to know whether a specific partner expects:

{
  "monthlyIncome": 50000
}
Enter fullscreen mode Exit fullscreen mode

or:

{
  "income": {
    "amount": 50000,
    "frequency": "monthly"
  }
}
Enter fullscreen mode Exit fullscreen mode

The platform should handle that complexity internally.

Use an Internal Canonical Model

One useful approach is to create a standard internal data model.

For example:

LoanApplication
├── applicant
│   ├── name
│   ├── phone
│   └── identityData
├── financialProfile
│   ├── income
│   ├── employmentType
│   └── existingObligations
└── loanRequirement
    ├── amount
    └── purpose
Enter fullscreen mode Exit fullscreen mode

The application works with this internal structure.

Then each external integration transforms the internal model into the format required by that partner.

                Internal Application Model
                         │
          ┌──────────────┼──────────────┐
          ↓              ↓              ↓
     Partner A        Partner B       Partner C
      Adapter          Adapter         Adapter
          ↓              ↓              ↓
       API A           API B          API C
Enter fullscreen mode Exit fullscreen mode

This is effectively an adapter pattern.

The benefit is isolation.

If Partner B changes its API, the change should ideally remain inside the Partner B adapter rather than affecting the entire application.

Separate Business Logic From Partner Logic

A common architectural mistake is allowing external API-specific rules to spread throughout the codebase.

For example:

if partner === "A"
    do X

if partner === "B"
    do Y

if partner === "C"
    do Z
Enter fullscreen mode Exit fullscreen mode

This becomes difficult to maintain as integrations grow.

A better approach is to separate responsibilities.

Application Service
        ↓
Eligibility / Workflow Layer
        ↓
Partner Selection Layer
        ↓
Partner Adapter
        ↓
External API
Enter fullscreen mode Exit fullscreen mode

Each layer should have a clear responsibility.

The workflow layer coordinates the journey.

The adapter handles partner-specific communication.

The external API remains isolated behind the adapter.

Assume External APIs Will Fail

Any external service can fail.

A request may:

  • Timeout
  • Return an error
  • Return an incomplete response
  • Respond slowly
  • Become temporarily unavailable

A production workflow should be designed around that reality.

Instead of:

Send Request → Assume Success
Enter fullscreen mode Exit fullscreen mode

Think:

Send Request
      ↓
Success? ─── Yes → Continue
   │
   No
   ↓
Retry Appropriate Error?
   │
 ┌─Yes───────────────┐
 ↓                   ↓
Retry             Store Failure
                      ↓
                Notify / Recover
Enter fullscreen mode Exit fullscreen mode

Not every failure should be retried.

For example, retrying a validation error repeatedly is unlikely to help.

Transient network failures may justify a carefully controlled retry.

Idempotency Matters

Suppose a user submits an application.

The request reaches the external system.

But the response is lost because of a network timeout.

What happens if your system automatically sends the request again?

Without idempotency, you could accidentally create duplicate requests.

A safer approach is to assign a unique operation ID.

Application ID: APP-12345
Operation ID: OP-98765
Enter fullscreen mode Exit fullscreen mode

The receiving system can use that identifier to recognize repeated requests.

The principle is simple:

Retrying the same operation should not accidentally create a second operation.

This is particularly important when dealing with financial workflows.

Use Queues for Non-Immediate Work

Not every process needs to block the user.

For example:

User submits application
        ↓
Validate immediately
        ↓
Store application
        ↓
Queue downstream processing
        ↓
Return application status
Enter fullscreen mode Exit fullscreen mode

A queue can help decouple slower background work from the immediate request.

Potential background tasks may include:

  • Sending notifications
  • Processing documents
  • Synchronising statuses
  • Calling downstream services
  • Updating internal records

This can make the application more resilient.

Status Mapping Is More Important Than It Looks

Different partners may use completely different status names.

For example:

Partner A → PENDING
Partner B → UNDER_REVIEW
Partner C → IN_PROGRESS
Enter fullscreen mode Exit fullscreen mode

Your frontend probably shouldn't need three different concepts for a similar stage.

Create a normalized internal status model:

RECEIVED
VERIFYING
UNDER_REVIEW
ACTION_REQUIRED
COMPLETED
DECLINED
FAILED
Enter fullscreen mode Exit fullscreen mode

Then map partner-specific responses internally.

Partner A: PENDING      → UNDER_REVIEW
Partner B: UNDER_REVIEW → UNDER_REVIEW
Partner C: IN_PROGRESS  → UNDER_REVIEW
Enter fullscreen mode Exit fullscreen mode

This creates a more consistent product experience.

Observability Should Be Part of the Design

When a user reports that their application is stuck, engineers need answers.

Questions may include:

  • Did the request reach our backend?
  • Did validation succeed?
  • Which partner adapter handled it?
  • Was an external API called?
  • What response was received?
  • Did a retry occur?

This is where observability becomes critical.

Useful tools and practices include:

  • Structured logs
  • Request IDs
  • Correlation IDs
  • Metrics
  • Distributed tracing
  • Error monitoring
  • Health checks

A correlation ID can follow a request across services:

Request
  ↓
correlation_id = abc-123
  ↓
API Gateway
  ↓
Application Service
  ↓
Partner Adapter
  ↓
External Service
Enter fullscreen mode Exit fullscreen mode

This makes debugging significantly easier.

Design the User Experience Around Uncertainty

External financial processes are not always immediate.

A system should avoid giving users misleading status information.

Instead of displaying:

Processing...

for every possible situation, the application can use meaningful states such as:

  • Application received
  • Information being verified
  • Additional information required
  • Under review
  • Update available

Good status design is partly a backend problem and partly a UX problem.

The system needs accurate state management before the interface can communicate clearly.

Where AI Can Help

AI can support operational workflows in areas such as:

  • Document classification
  • OCR-assisted data extraction
  • Fraud detection
  • Customer support
  • Data quality checks
  • Workflow prioritisation

But an important engineering principle remains:

AI output is still system input.

It should be validated before downstream processes rely on it.

A useful pattern is:

AI Processing
      ↓
Confidence Check
      ↓
High Confidence → Automated Workflow
      ↓
Low Confidence → Additional Review
Enter fullscreen mode Exit fullscreen mode

This avoids treating every model output as automatically correct.

Reliability Is Part of the Product

Users may never see:

  • Retry logic
  • Queues
  • API adapters
  • Correlation IDs
  • Status mapping

But they experience the result.

Poor architecture can become:

  • Confusing application statuses
  • Repeated requests
  • Missing updates
  • Duplicate processing
  • Unclear failures

Good architecture creates a simpler experience by hiding unnecessary complexity.

Backend reliability is part of user experience.

A Real-World Marketplace Perspective

At a platform such as SwipeLoan, which operates as a digital loan marketplace rather than a direct lender, the technical challenge includes creating a consistent discovery and application experience while working with multiple participating financial institutions.

The lending partners independently evaluate applications and make lending decisions according to their own criteria and policies.

From an engineering perspective, this makes abstractions, integration boundaries, normalized data models, reliable workflows, and observability especially important.

Final Thoughts

Multi-partner fintech systems are complex because the user sees one journey while the backend may coordinate several independent systems.

The key principles are relatively simple:

  1. Use internal canonical data models.
  2. Isolate partner-specific logic.
  3. Design for external failures.
  4. Use idempotency where duplicate operations matter.
  5. Normalize statuses.
  6. Build observability from the beginning.
  7. Treat AI output as something to validate.
  8. Remember that reliability directly affects user experience.

The best fintech architecture doesn't expose its complexity to users.

It turns many moving parts into one experience that feels clear and reliable.

Top comments (0)