Engineering Reliability at Scale: A Technical Journey into Building a Distributed Fintech Lending Platform

You drop your luggage on an airport baggage conveyor, and it magically appears in another country. But behind that effortless moment are scanners, sorting algorithms, RFID tracking, security checks, conveyor networks, inter-systems, and error-handling workflows. Simple for the traveller, enormously complex underneath.

Similarly, when people imagine a financial lending platform, they picture a clean mobile app where customers tap a few buttons and money appears in their account, but architects and engineers know the truth.

A real-world lending platform is not just an app. It is a distributed organism, a constantly evolving constellation of microservices, event streams, external integrations, partners, scoring engines, rule processors, compliance guards, and payment pipelines.

I worked on architecting such a system, one that needed to support:

• Multiple loan products with drastically different behaviours
• High-volume onboarding through digital and assisted channels
• Dozens of upstream/downstream integrations
• Real-time decisioning and underwriting
• Strict regulatory compliance
• Complex repayment and servicing logic
• Fault tolerance under constant external variability

What follows further is just not theory. It is a practical blueprint of what it takes to build a reliable, scalable, high-performance lending platform, one that operates in the real world, where identity systems go down, credit bureaus time out, payment gateways misfire, customers abandon flows, and regulations evolve every quarter.

This article is meant to be end-to-end. If you are designing or modernising a lending platform (or just curious how a digital financial platform holds beneath), this should serve as your architectural foundation.

---

Understanding the Battlefield: Why Lending Platforms are Hard Nuts

When I first stepped into the world of digital lending, I thought I was building “a platform” like my previous experience in PropTech, e-commerce, and advertising. It didn’t take long to realise I was actually walking into a battlefield, one where every design choice collided with real-world unpredictability, regulatory scrutiny, and the messy nature of human behaviour.

What looks straightforward in a diagram becomes a maze the moment real customers, partners, third-party dependencies, and national-level systems enter the picture. Running a fintech platform is walking a tightrope held up by customer experience, business continuity, and regulatory compliance. Lose tension in even one, and you don't just fall - you fall hard, sometimes very deep.

1. Heavy dependency on external ecosystems

One of my earliest shock was discovering just how much a lending journey depends on systems we don’t control. Identity verification, KYC, credit bureaus, fraud engines, document checks, digital signature providers, payment gateways, each plays a crucial role, and each has a personality of its own. Some are lightning-fast at 3 p.m. and painfully slow at 3:05 p.m. Some throttle traffic without warning. Some timeout randomly and return cryptic error messages that mean one thing today and something entirely different tomorrow.

When a national ID service hiccups, the entire onboarding wave collapses. When a payment gateway delays callbacks, your ledger drifts out of sync. Very quickly, I learnt that building a fintech platform isn’t about perfect code; it’s about engineering resilience around everything you cannot control.

2. High domain complexity

Then came the next realisation: No two loan products behave alike. Merchant financing behaves nothing like cash loans. BNPL-style checkout flows behave nothing like invoice-backed underwriting. Each brings its own scoring criteria, document requirements, risk signals, and repayment logic.

At one point, we were running thousands of rule variations, partner-specific scoring coefficients, product-specific eligibility constraints, exceptions for certain categories, dynamic credit limits, custom verification steps. It became obvious that hardcoding anything was a recipe for disaster. The platform must adapt on the fly, interpret rules like a policy engine, and let partners shape their own product without breaking everyone else’s. Configurability isn’t a nice-to-have; it’s survival.

3. The platform MUST stay consistent across channels

This was the moment where theory truly collapsed and reality took over. Customers weren’t following a nice linear journey. They would start on the mobile app, switch to the website, call customer support, walk into a partner outlet, or complete KYC over an IVR call. And they expected the system to remember exactly where they left off. I learned the hard way that multi-channel consistency isn’t a UI concern - it’s a distributed system challenge.

Keeping experiences consistent required:

• Distributed caches that sync state faster than humans switch screens
• Session orchestration across channels
• Event-driven state propagation so every service sees the same truth
• Optimistic locking and conflict resolution when agents and customers touch the same record
• Role-aware access control behaving consistently across app, web, and partner systems
• Workflow engines capable of pausing, resuming, and surviving hours-long gaps and broken connections
  
  When document uploads failed or IVR verification took too long, we had to guard against duplicate steps and corrupted states. Keeping experiences consistent wasn’t about beauty, it was about discipline in state management and orchestration.

4. Strict regulatory expectations

Just when you think you’ve solved the technical puzzle, the regulators appear, and they never blink. I have had to design systems where every decision, every rule evaluation, every configuration change, every partner override is recorded immutably. Not for the convenience, but because regulators may ask for it years later.. Compliance is baked into architecture:

• Tokenisation so raw national IDs or IBANs never exist in the system
• Encryption at every hop, end to end
• Data residency constraints forcing regional database isolation
• Mandatory KYC/AML gates inside workflows
• Audit logs that cannot be edited or deleted

There’s no “after-the-fact compliance” in lending. If the architecture can’t prove correctness, the business cannot operate.

5. Reliability is existential

Reliability isn’t a technical goal; it’s the heart of the business. If an identity API takes two extra seconds, customers abandon the flow. If the bureau results lag, applications pile up. If payment callbacks fail, you risk double charges or missing disbursements. If one dependency becomes unstable, the entire system feels the tremors.

So we architected defensively:

• Circuit breakers to isolate failing upstream systems
• Timeouts and fallbacks to keep journeys alive
• Asynchronous orchestration to avoid blocking workflows
• Graceful degradation when non-critical checks faltered
• Horizontal scaling to absorb sudden traffic bursts
• Dependency isolation so one product or partner can’t take others down

Over time, reliability stopped being “infra”, it became a product feature, that silently earns customer trust and partner confidence every single day.

---

Architectural Philosophy: Loose Coupling, Strong Orchestration

A large lending platform can’t behave like a polite system waiting for every dependency to answer. In the real world, services slow down, timeout, or fail without warning. The architecture must assume chaos and be built to bend, reroute, and continue, never breaking just because something upstream did, so the platform must be designed to embrace failure without breaking.

Principle 1 - Microservices with clear Bounded Contexts

Key domains become self-contained services:

• Customer Service
  Manages customer profiles, contact details, and identity information so every part of the platform has a single, accurate record of the customer.

• Application Service
  Handles the creation and progress of loan applications, tracking each step from start to approval without mixing business logic from other domains.

• Identity & Verification Service
  Performs ID checks, mobile verification, biometrics, and fraud validations to confirm the applicant is genuinely who they claim to be.

• Credit Bureau Service
  Connects to credit bureaus, fetches reports, and provides clean, standardised credit data to other services for decisioning and risk evaluation.

• Rules Engine
  Executes business rules for eligibility, partner criteria, compliance checks, and loan conditions, ensuring consistent decisions across all products and channels.

• Scoring Engine
  Calculates risk scores using multiple factors to determine affordability, customer risk level, and the likelihood of successful repayment.

• Document Service
  Manages uploading, storing, validating, and retrieving customer documents securely, such as IDs, invoices, contracts, or proof of income.
  -

• Offer Service
  Generates personalised loan offers-amount, tenure, fees-based on rules, scoring results, and partner or product-specific configurations.

• Payment Orchestration
  Handles all payment actions like fee collection, instalments, refunds, and reconciliations while preventing duplicates and ensuring transaction accuracy.

• Loan Management Service
  Manages loan accounts after disbursement, including repayment schedules, dues, settlements, outstanding balances, and customer servicing activities.

• Ledger / Accounting
  Maintains financial records, double-entry logs, and posting rules to ensure every transaction is accurate, auditable, and compliant.

• Notification Service
  Sends SMS, email, in-app alerts, and reminders triggered by events in the platform, ensuring customers and partners stay informed.

• Partner Integration Gateway
  Connects external partners and merchants, applying their custom rules, configurations, onboarding flows, and APIs without disrupting core systems.

• Audit & Compliance Service
  Captures immutable logs of all activities, validates rule adherence, and ensures the platform meets regulatory, security, and reporting requirements.

Each domain evolves, deploys, and fails independently.

Principle 2 - Event-Driven Architecture (EDA) as the system backbone

Microservices publish/consume events such as

• ApplicationSubmitted
• IdentityVerified
• OfferGenerated
• LoanDisbursed
• PaymentCaptured
• ScheduleUpdated

This removes brittle synchronous chains.

Kafka (or Pulsar) acts as:

• Message broker for reliable transport:
  To reliably transports events, like application updates, verification results, and payment outcomes between microservices, ensuring every component receives real-time information without direct, fragile API dependencies.

• Source of truth for workflow progression:
  Every loan journey step is published as an event, allowing the workflow to advance consistently across channels and services, with Kafka maintaining the authoritative record of progression.

• Replay/recovery engine to rebuild state:
  If a service fails or misses events, it can replay Kafka topics to reconstruct its state, preventing data loss and ensuring the lending process never stalls.

• Historic log for audits and dispute resolution:
  Kafka stores a complete chronological history of all customer, application, payment, and verification events, enabling state rebuilding, audits, dispute analysis, and deep regulatory reporting with high accuracy.

Principle 3 - CDC (Change Data Capture) for read scalability and near-real-time sync

A lending platform has huge reporting, servicing, and compliance analytics needs. Direct reads from transactional databases create bottlenecks. CDC keeps OLTP safe:

• DB changes → CDC stream → read models → dashboards
  CDC captures database updates in real time, streams them into read-optimised models, enabling dashboards and analytics to stay instantly updated without impacting transactional systems.
• Core banking updates → CDC pipeline → loan manager → customer app When core banking posts repayments or charges, CDC pipelines push updates to the Loan Management service, ensuring customer apps display accurate balances and schedules within seconds.
• Near-real-time sync without hammering transactional stores CDC eliminates repeated heavy queries on production databases by streaming changes once, allowing multiple services to consume updated data without overloading critical OLTP resources.

Debezium is a strong production-ready option here.

Principle 4 - Workflow Orchestration for long-running processes

Lending journeys are not simple linear processes. Users pause, come back later, submit documents, redo verification, take hours to complete IVR confirmation, etc.

A workflow engine (Camunda, Temporal, Zeebe, Cadence) enables:

• State persistence for pause/resume/recovery:
  The workflow engine remembers every step of the loan journey, so processes can pause, resume, or recover after failures without losing progress or duplicating actions.

• Human-in-loop steps:
  Some tasks require people like agents, underwriters, or customers. The engine waits for human actions, tracks completion, and continues the workflow automatically once input is received.

• Timeouts & Retries: If an external service is slow or unresponsive, the engine automatically retries or triggers timeouts, preventing the entire loan process from getting stuck or failing silently.

• Compensation logic for safe rollbacks:
  When something goes wrong mid-process, the engine runs corrective actions like reversing payments or cancelling approvals, to keep the system consistent and error-free.

• Visualisation for debugging and improvement:
  The engine provides diagrams showing each workflow step, making it easy for teams to understand, debug, and improve complex loan journeys without reading code.

Principle 5 - Everything must be observable

In a distributed fintech platform, observability is vital. Distributed tracing, correlation IDs, and event logs reveal how workflows behave across services. SLO-based alerting, synthetic monitoring, partner dashboards, and error heat-maps expose bottlenecks before they hurt customers. When systems grow complex, visibility becomes the only antidote to operational chaos.

---

C4 Model Architecture

Level 1: System Context

Actors: customers (mobile/web), agents/call-centres, merchants/partners, credit bureaus, identity systems, payment gateways, digital signature providers, banking systems, regulators, internal ops.

Level 2: Container Architecture

When I first mapped out the container architecture for the lending platform, it felt a bit like drawing the blueprint of a bustling city. At the very edge lived the citizens, our users - arriving through mobile apps, web portals, and partner systems. All of them passed through a single controlled entry point, the API Gateway, much like a city gate filtering and routing traffic to the right districts. Inside the walls sat the real heart of the platform: the specialised microservices. Each one behaved like its own neighbourhood with a clear purpose, identity verification, scoring, rules evaluation, payment orchestration, loan management, workflows, notifications. They didn’t shout across the streets at each other; instead, they communicated through the city’s messaging grid, an asynchronous event bus like Kafka, ensuring no one was blocked waiting for a slow neighbour. To keep the city running smoothly, we built observation towers, read models, analytics stores, and CDC pipelines, that watched events in real time and provided dashboards and insights to everyone from risk teams to operations. And deeper underground sat the core banking or lending ERP systems, the vaults and ledgers of the city, holding the authoritative record of every loan, repayment, and financial transaction. Everything else in the platform was built to respect their truth. This layered ecosystem wasn’t just architecture. It became the living map of how the entire lending journey operated reliably, no matter how many users, partners, or processes leaned on it.

+------------------------------------------------------+
|                  API Gateway                         |
+------------------------------------------------------+
       |                |               |
       v                v               v
  Mobile App       Web App         Partner Portal
       |
       v
+------------------------------------------------------+   
|                Digital Lending Platform              |
+------------------------------------------------------+
| Customer Service     | Application Service | Identity Service |
| Rules Engine         | Scoring Engine      | Offer Service    |
| Document Service     | Payment Orchestrator| Loan Manager     |
| Ledger Service       | Notification Svc    | Audit/Compliance |
| Partner Gateway      | Risk Engine         | Workflow Engine  |
+------------------------------------------------------+
                      |
                      v
+------------------------------------------------------+
| Event Bus (Kafka/Pulsar)                             |
+------------------------------------------------------+
                      |
                      v
+------------------------------------------------------+
| Read Models, Analytics DB, CDC Pipelines             |
+------------------------------------------------------+
                      |
                      v
+------------------------------------------------------+
| Core Banking/Lending ERP                             |
+------------------------------------------------------+

Level 3: Component Breakdown

Application Service
Coordinates loan journey steps: submits new applications, publishes ApplicationSubmitted, listens for IdentityVerified, CreditBureauChecked, RulesEvaluated.

Identity Service
Handles national ID checks, face match, mobile ownership, biometrics, fraud signals. Uses caching + async queues to tolerate upstream failures so verification continues smoothly even when providers are slow.

Rules Engine & Scoring Engine
Applies thousands of partner/product/regulatory conditions; evaluates risk and affordability using behavioural, financial, and bureau data - the decisioning brain for instant, consistent, explainable outcomes.
They evaluate:

• Partner-level criteria
• Product-level business rules
• Risk & affordability checks
• Compliance requirements

They are built on:

• Decision tables for auditable, code-free rule changes
• Pre-compiled rule graphs for low-latency execution
• In-memory caches for fast lookups
• Zero-downtime rule publishing to adapt without outages

Payment Orchestration
Supports fee collection, repayment, auto-debit, reconciliation, duplicate prevention, and saga workflows, a critical reliability domain.

Loan Management Service
Servicing capabilities: repayment schedules, early settlement, payment posting, delinquency tracking, charges/penalties-backed by CDC data from core banking.

Workflow Engine
Tracks long-running processes: document submission, IVR confirmation, pending bureau results, merchant-assisted flows, back-office approvals.

---

How the Loan Journey Flows (Event by Event)

Step 1: Application Initiated
User presses “Apply” → API Gateway → Application Service → publishes ApplicationCreated event.

Step 2: Identity Verification (async)
Identity Service consumes event → calls national ID systems → publishes IdentityVerificationSucceeded or IdentityVerificationFailed → workflow updates state.

Step 3: Credit Bureau & Risk Checks
Credit Service runs bureaus → publishes CreditBureauCompleted.
Rules Engine applies partner/product rules → publishes RulesEvaluated.

Step 4: Offer Generation
Offer Service consumes required events → generates offer → publishes OfferGenerated.

Step 5: Acceptance, Signature, Disbursement
Long-running: digital signature, document upload, IVR confirmation, e-mandate setup. Workflow handles timeouts/retries/wait states.

Step 6: Loan Setup in Core Banking
Loan Manager provisions in core banking → CDC updates → customer app reflects instantly.

---

Reliability Patterns Everywhere

Idempotency handling
I learned early that in lending, the same request often arrives twice, maybe the customer tapped twice, maybe the network retried, maybe a service timed out. Without protection, the platform might treat each attempt as new, leading to duplicate payments, repeated bureau checks, or multiple application records. Idempotency became our safety net: no matter how many times a request was sent, the system executed it only once. It turned chaos into predictability, protecting customers from double charges and partners from inconsistent data. Idempotency is mandatory for:

• Payment requests
• Bureau calls
• Identity checks
• Document uploads
• Partner callbacks

The moment we moved to an event-driven architecture, we realised consuming events wasn’t the hard part, consuming them exactly once was. Customers tap twice, networks retry silently, and Kafka may re-deliver messages during failovers. That’s where idempotency became our shield. Here’s the consumer pattern we relied on to keep the lending journey consistent:

public class LoanEventConsumer {

    private final KafkaConsumer<String, String> consumer;
    private final LoanEventHandler handler;
    private final IdempotencyStore idempotencyStore;

    public LoanEventConsumer(Properties props,
                             LoanEventHandler handler,
                             IdempotencyStore idempotencyStore) {

        this.consumer = new KafkaConsumer<>(props);
        this.handler = handler;
        this.idempotencyStore = idempotencyStore;

        consumer.subscribe(List.of("loan-events"));
    }

    public void start() {
        while (true) {
            ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(300));

            for (ConsumerRecord<String, String> record : records) {

                String eventId = record.headers().lastHeader("event-id").value().toString();

                // Idempotency check
                if (idempotencyStore.exists(eventId)) {
                    continue;  // event already processed
                }

                try {
                    handler.process(record.value());
                    idempotencyStore.markProcessed(eventId);
                } catch (Exception ex) {
                    // push to DLQ or retry topic
                    handler.pushToDlq(record, ex);
                }
            }

            consumer.commitSync(); // controlled commit
        }
    }
}

This snippet is an illustrative example to explain the concept, it is not the actual code used in our production systems.

Circuit breakers
I still remember the first time an external identity service slowed to a crawl, our entire loan journey felt the impact instantly. That’s when circuit breakers became indispensable. Instead of letting our system keep calling a failing provider and spiral into cascading timeouts, the circuit would “open,” blocking further calls and protecting the platform. It gave us room to breathe: we could fall back, queue retries, or guide customers gracefully without freezing the entire journey. Circuit breakers became the buffer that kept one unstable dependency from dragging the whole lending experience down.

Bulkheads
There were days when a single partner’s traffic spike or a failing API in one loan product threatened to overwhelm the entire system. That’s when bulkheads proved their worth. By isolating resources-threads, queues, compute, we made sure each product and partner operated in its own compartment. If a checkout flow flooded an external API, invoice or cash loans wouldn’t even feel it. Bulkheads turned localised problems into contained incidents, preserving overall platform stability and keeping the rest of the lending ecosystem running smoothly.

Sagas
For:

• Payment failures
• Refunds
• Reversals
• Partial onboarding rollbacks

When I first watched a payment fail halfway through a disbursement flow, I realised how fragile multi-step processes can be. That’s where sagas changed everything. Instead of treating a journey as one giant transaction, we broke it into smaller, independent steps, each with its own “undo” action. If something failed mid-way, compensating steps would roll back earlier actions automatically. No corrupted loan states, no half-completed disbursements, no messy refunds. Sagas kept complex flows clean and reversible, protecting both the platform’s integrity and the customer’s trust.

Retries with backoff - Only on safe ops, with tracking to avoid loops.
Graceful degradation - If bureaus are down, fallback scoring; if identity is slow, queue and notify; if payments lag, ledger marks pending.

---

Data Architecture: A Fintech’s Powerhouse

Operational databases (OLTP)
There was a learning with me that sharing databases across services is like letting every neighbour share the same mailbox, confusion is guaranteed. Giving each microservice its own database created clean boundaries between domains. Identity couldn’t accidentally tamper with scoring data; payments couldn’t disrupt loan servicing. It meant every service could scale, deploy, or tweak schemas at its own pace without risking platform-wide outages. In a fintech world where different domains evolve at wildly different speeds, isolated databases preserved autonomy and drastically reduced blast-radius failures. It kept the system reliable, maintainable, and always audit-ready.

Change Data Capture
Core banking → CDC → platform loan manager. Platform events → CDC → analytics. Real-time sync without OLTP overload.

Near-real-time read models
Optimised stores for dashboards, customer portals, collections, risk analytics.

Event store for business traceability
Very early on, I realised that memory, human or system wasn’t enough in lending. We needed a perfect record of everything: every application update, every bureau check, every offer generated, every payment made. The event store became that source of truth. By storing each action in strict chronological order, it allowed us to replay history exactly as it happened. Auditors could trace every decision, teams could rebuild system state after failures, and disputes could be resolved with absolute transparency. In a regulated environment, this wasn’t a luxury - it was survival.

Strong governance and metadata
As the platform grew, I realised data without governance becomes a liability. Every rule, field, event, and document needed clear meaning, ownership, and lineage. Strong metadata practices brought order to that chaos. Suddenly, compliance reports weren’t guesswork, they were precise and defensible. Regulators could trace how every decision was made, and internal teams could rely on consistent definitions across the entire ecosystem. In a world where one unclear field can trigger an audit issue, governance became the quiet backbone that kept the platform trustworthy and regulation-ready.

---

Observability: Engineering the Ability to See Everything

• Distributed tracing - every request carries x_correlation_id, partner_id, product_id.
• Event replay monitoring
  In a busy lending platform, not every event makes it through on the first attempt, some fail, some arrive corrupted, others get stuck. Dead-letter queues capture these troubled events, but they’re only useful if someone is watching. Continuous event replay monitoring ensures these failures are spotted and corrected before they disrupt customer journeys. It prevents stalled workflows, missing updates, and inconsistent loan states, keeping the platform stable even when individual services encounter hiccups or temporary outages.
• SLO-based alerting - identity, bureau, payment, disbursement, partner onboarding SLOs tied to customer impact.
• Business dashboards
  Sometimes the first sign of trouble in a lending platform doesn’t appear in logs or alerts, it appears in the numbers. Business dashboards track real-time KPIs that quietly expose technical issues long before monitoring tools catch them. A sudden drop in application submissions, slower identity-verification success rates, or unexpected disbursement delays can reveal that something deep inside the system is struggling. These dashboards become an early warning system, helping teams spot and investigate issues before customers feel the pain. Key metrics include:
  • Application Start → Submission Drop-Off A sudden drop signals UI issues, app crashes, or gateway latency blocking users before requests reach backend services.
  • Identity Verification Success Rate A decline often indicates upstream identity provider failures, timeout spikes, or degraded network connectivity.
  • Credit Bureau Response Time & Success Rate Slower responses point to bureau outages, throttling, or broken integration pipelines impacting loan progression.
  • Offer Generation Rate A drop may mean rules engine failures, scoring engine errors, or downstream event processing delays.
  • Disbursement Success Rate Declines typically reflect payment gateway issues, core banking unavailability, or orchestration failures.
  • Repayment Posting Delays Indicates CDC lag, event-processing backlog, or reconciliation pipeline issues.
  • Partner Conversion Variations A sharp dip for any partner highlights configuration errors, custom rule failures, or API misalignment specific to one integration

---

Partner Integration Framework

• Config-driven onboarding with minimal engineering touch
• Rule versioning for partner/product-specific logic
• Partner-specific event topics for isolation
• Feature flags for controlled rollouts
• Schema governance for backward-compatible integrations

Onboard new partners without modifying core systems-critical for scale.

---

Payment Reliability: The Hardest Part

During my FinTech journey, it became clear that payments aren’t just another service call, they’re the heartbeat of the entire lending experience. When a charge goes through twice or a repayment doesn’t reflect, customers lose confidence instantly. Regulators start asking questions just as quickly. In that moment, a tiny technical flaw becomes a major credibility problem. Payments demand absolute accuracy, and every line of architecture around them must be engineered with the same level of care as a financial institution’s core systems. A duplicate charge, lost confirmation, or un-posted repayment instantly erodes customer trust and raises regulatory risks. Payment orchestration enforces:

• Idempotency keys and hash-based duplicate detection
• Saga-based compensation for refunds/reversals
• Async reconciliation to align gateway and ledger
• Retry queues with poison-pill detection
• Ledger-backed source of truth for financial correctness

Payment outages must be handled with surgical precision to protect trust and compliance.

---

Multi-Product, Multi-Partner Scalability

• Horizontally scale services independently
• Partitioned Kafka topics for isolation
• Per-partner throttling to protect cores during spikes
• Distributed caching for fast config access
• Configurable workflows to adapt without redeploys
• Zero-downtime releases so live transactions never stop

---

The Real Lesson: Reliability is Engineered, Not Hoped For

Reliability is the emergent property of disciplined architecture across hundreds of decisions. What customers experience as a 2-minute loan approval is actually:

• 20+ microservices
• 10+ external systems
• 50+ rule evaluations
• 100+ internal events
• 1000+ observability data points
• All orchestrated in real time
• Under heavy regulatory oversight

When done right, the platform fades into the background. What remains is trust. That is the real product of a well-architected fintech lending platform.