Contact Us

Built a Supply Chain Finance Platform with Privacy-Safe AI Underwriting — Starting with the Client Portal

Itexus built a client portal, a lender operations desk and an AI underwriting module for an insurance-backed supply chain finance lender. The platform covers bulk invoice intake, insurer-gated funding and de-identified credit memos. The lender owns the platform and can license it.

Solution architecture diagram of the supply chain finance platform
Solution architecture diagram of the supply chain finance platform

Key Success Metrics

2 weeks → 4 hours
credit memo preparation
7 months
from discovery to launch

Case Summary for FinTech Leaders

A non-bank lender pays clients' suppliers upfront and extends the clients' payment terms under trade credit insurance. Clients submitted invoices as emailed spreadsheets, and onboarding a new client took about two weeks of manual underwriting. Off-the-shelf AI tools could not meet two constraints: identifying applicant data could not reach a language model, and every credit decision had to be explainable and reproducible. Itexus de-identified documents before any model call and placed deterministic credit rules ahead of the model. Delivery started with the portals.

Technologies: Python, FastAPI, PostgreSQL, React, Keycloak, Temporal, Docling, Presidio

IndustryFinTech — Supply Chain Finance / Commercial Lending
SegmentNon-bank lender, insurance-backed payables finance for mid-market companies
GeographyNorth America and Europe
Deployment ModelCloud, single-tenant deployment on a multi-tenant-capable architecture
Duration7 months
Team Size~9 engineers (Delivery Manager, Business Analyst, Solution Architect, Backend Engineers, Frontend Engineers, QA Engineer, DevOps Engineer, UI/UX Designer)
Delivery ModelPhased delivery: fixed-price discovery → phased build of portals → capped T&M for AI underwriting
ServicesLending Software Development · AI/ML Development · FinTech Product Discovery · UI/UX Design
Technologiessee Technology Stack
ComplianceDesigned for ECOA / Reg B, SR 26-2, GDPR and the EU AI Act; SOC 2 Type II-ready

About the Client

The client is a non-bank lender that finances trade payables for mid-market companies. It pays the client's suppliers directly and later bills the client on extended terms. Facilities are unsecured and wrapped by third-party trade credit insurance. The insurer makes its own independent approval decision before any funding.

The platform handles banking details, audited financial statements and credit decisions for applicants in several jurisdictions. That placed it under US fair-lending rules and, for European applicants, under GDPR. The lender also planned to license the software to other funders. Every architectural and licensing choice had to survive redistribution, not just internal use.

The Challenge

Faster AI underwriting that never exposes applicant identities to a model and keeps every decision explainable.

Business Challenge

  • Clients had no portal and emailed invoices as spreadsheets, so staff re-keyed every row into a third-party legacy system by hand.

  • Underwriters spent about two weeks preparing each new client's memo by hand.

  • No funding could go out without the insurer's approval, and a reduced or withdrawn limit could make already-submitted invoices unfundable.

  • The lender wanted to own the platform and license it under other brands.

  • Declined applicants were owed specific reasons, and any decision had to be reproducible months later under the policy then in force.

Technical Challenge

  • Consistent pseudonymization is cross-document entity resolution: abbreviations, legal-form variants, OCR noise.

  • Identifiers also sit in logos, signatures and letterheads, beyond text-based NER.

  • Multi-page financial tables from scanned PDFs had to be extracted without numeric drift.

  • A 5-minute SLA covered OCR, detection, rules evaluation and the LLM call.

  • Insurer limit revocations had to recompute capacity for in-flight invoices without race conditions.

Constraint diagram

Solution

Itexus delivered the platform with a ~9-person cross-functional team over 7 months, deployed on AWS. Delivery started with a discovery phase and proofs of concept on the two riskiest components. The client and operations portals shipped next, and AI underwriting followed once its accuracy target could be measured.

De-identification pipeline

Client Portal and Facility Visibility

  • Facility overview showing limit, amount outstanding, available capacity and amounts coming due.

  • Bulk CSV/Excel invoice upload with row-level validation, suggested corrections and a check-answers step before submission.

  • Capacity preview that recalculates available funding as failed rows are corrected or excluded.

  • Searchable invoice register with a full status history for every invoice.

  • Supplier management with three bank-detail formats: US routing, UK sort code and IBAN/BIC.

  • Repayment schedule and account statements; the platform records payments and never moves money.

Lender Operations Desk and Insurer Gating

  • Review queue for approving, rejecting with structured reason codes, or requesting more information.

  • Insurer decisions stored as dated, versioned records supporting nil limits, reductions and withdrawals.

  • Funding blocked automatically until an insurer approval is recorded.

  • Facility limit management and portfolio-level exposure views.

  • Append-only, hash-chained audit trail covering every decision and configuration change.

De-Identified AI Underwriting

  • Public application flow with verified sign-up, e-signed NDA and financial-statement upload.

  • Layout-aware extraction for digital PDFs, with an OCR path for scanned statements.

  • Layered entity detection: deterministic patterns, NER models, zero-shot role detection and structural rules for signatures and letterheads.

  • Entity resolution that maps every mention of one company to one stable token across the document set.

  • A post-redaction verification sweep that fails closed and routes any residual hit to human review.

  • Deterministic credit-box rules evaluated before the model, with thresholds stored as data rather than code.

  • A policy-conditioned language model drafts the credit memo; underwriters decide, and borderline cases route to a human rather than being declined automatically.

  • Controlled re-identification for authorized staff, with every reveal written to the audit trail.

Platform Foundation for Future Scale

  • Multi-tenant-capable data model and identity realms, so the lender can run partner programs or license the platform.

  • Tokenized design system that re-brands the portals per tenant without code changes.

  • Documented REST API, so planned intake channels (API, SFTP, ERP connectors) plug into the same validation pipeline.

  • Licence gate in CI that fails the build on copyleft or non-commercial dependencies.

  • Decision log that tags each outcome with its policy version, ready for future model validation.

Input to output example

Use Cases Covered

Use CaseDescriptionOutput
Invoice batch submissionClient CFO uploads a batch and fixes failed rows before submissionValidated batch with ID and capacity impact
Invoice reviewLender staff approve, reject or query submitted invoicesDecision record with structured reason code
Insurer gatingStaff record the insurer's decision for a facilityVersioned insurer record; funding unlocked or blocked
Repayment trackingClient sees what was funded and when it is dueRepayment schedule and account statement
Applicant pre-screeningProspect applies and uploads financial statementsIndicative, non-binding pre-approval
Credit memo draftingModel drafts a memo from de-identified statementsDraft memo tagged with policy version
Controlled re-identificationAuthorized underwriter reveals the real applicantAudit entry with user, time and reason

Problems Solved

  • Credit memo preparation cut from about two weeks to 4 hours.

  • Invoice intake moved out of the inbox. Clients submit and correct batches themselves, so staff no longer re-key spreadsheets.

  • Insurer risk became visible before funding, not after. Staff see which invoices become unfundable if an insurer cuts a limit.

  • AI assistance without identity exposure. The model sees only de-identified content, and every step is logged and reproducible.

  • An owned, licensable asset instead of a rented system. The lender owns the code and every dependency permits sublicensing — the first product on a platform, not a one-off tool.

Before and after

Solution Architecture

The platform separates identity from analysis: identifying data lives in a segregated vault that the model-calling services cannot reach.

LayerComponentsFunction
ExperienceClient portal, operations desk, public application flow (React)User interaction, validation feedback, reporting
Application & WorkflowFastAPI services, invoice state machine, durable workflow engineInvoice lifecycle, insurer gating, async underwriting pipeline
DecisioningRules engine with decision tables, policy versioning, LLM adapterCredit-box evaluation first, memo drafting second
De-IdentificationExtraction, layered entity detection, entity resolution, verification sweepRemoves identity before any model call
Data & AuditPostgreSQL, segregated identity vault, append-only hash-chained logRecords, token mapping, tamper-evident history
SecurityKeycloak (MFA, RBAC), KMS, field-level encryption, zero-retention model endpointAccess control, encryption, provider data isolation
Solution architecture

Integration Landscape

  • E-signature — embedded click-to-sign NDA in the application flow; a simple electronic signature is legally sufficient (Dropbox Sign)

  • LLM service — credit memo drafting on de-identified content only, under zero-retention and no-training terms (Azure OpenAI)

  • Email delivery — account verification and recovery, submission and decision notifications

  • Insurer — no integration by design; the insurer decides independently and staff record its decisions in the operations desk

  • ERP and file channels — planned: API, SFTP and ERP/accounting connectors (e.g. NetSuite) feeding the same validation pipeline; CSV/Excel upload at launch

  • KYC/AML — planned; the provider is chosen once launch compliance requirements are confirmed

  • SSO — planned; email and password with MFA at launch

  • Internal ledger and funding instruction export

Technology Stack

CategoryTechnologies
AI/MLPresidio, spaCy, GLiNER, Azure OpenAI
Document ProcessingDocling, pdfplumber, Tesseract / OCRmyPDF
BackendPython, FastAPI, SQLAlchemy
Decisioning & WorkflowGoRules ZEN, Temporal, XState
FrontendReact, TypeScript
DataPostgreSQL
Infrastructure & SecurityAWS (EKS, RDS, KMS, WAF), Keycloak, Terraform, CI/CD

Compliance & Security

Security was treated as the first design constraint. The architecture had to prove, not just claim, that identity never reaches the model.

Security Measures Implemented

  • MFA for all users and role-based access control on every endpoint.

  • Field-level encryption for banking details and the identity vault.

  • Identity vault on separate storage, credentials and keys, with no network path from model-calling services.

  • Model endpoint configured for zero data retention and no training, confirmed in writing by the provider.

  • Append-only audit trail with hash chaining and attributed re-identification events.

  • Dependency and licence scanning in CI; separate dev, staging and production environments.

Compliance Considerations

  • Fair lending (US): deterministic rules produce specific principal reasons for adverse decisions, as 12 CFR 1002.9(b)(2) requires.

  • Model risk: credit-box rules stay deterministic, and deterministic rule-based processes fall outside the model definition in SR 26-2.

  • GDPR: the design is treated as pseudonymization, not anonymization, with a documented residual-risk review.

  • EU AI Act: corporate credit assessment falls outside Annex III 5(b), and any natural-person path (e.g. guarantors) is gated separately.

  • SOC 2 Type II: the architecture is designed to generate audit evidence continuously. This is readiness for a future audit, not certification.

Delivery Approach

Delivery Model: Phased delivery — fixed-price discovery, fixed price per phase for the portals, capped T&M for AI underwriting until the accuracy threshold was agreed.

Team Composition

Delivery Manager · Business Analyst · Solution Architect · Backend Engineers · Frontend Engineers · QA Engineer · DevOps Engineer · UI/UX Designer

Governance

  • Acceptance criteria agreed for each feature before development.

  • Proofs of concept on the two riskiest components before committing to a build price.

  • AI underwriting accepted against measured entity-detection accuracy on a client-supplied test set.

  • Fixed review windows for milestone acceptance built into the schedule.

  • Licence gate on every build to protect the client's right to sublicense.

  • Weekly progress and budget reports; scope changes approved in writing.

Delivery timeline

Results

The lender prepares a credit memo in 4 hours instead of about two weeks, on a platform it owns and can license.

2 weeks → 4 hours
credit memo preparation
Under 5 minutes
target for indicative pre-approval, end to end, scanned statements included
0 identifying fields
sent to the model — enforced by a fail-closed verification sweep
5,000+ rows
target for invoice rows validated per upload in one pass

How This Expertise Can Help Your Team

Itexus builds lending platforms in which regulatory constraints shape the architecture from the first sprint.

Lending Software Development

Facility, invoice and repayment logic built for a lender that records money flows but never moves funds.

AI/ML Development

A de-identification pipeline and policy-conditioned memo drafting, where the model assists underwriters and deterministic rules own the decision.

UI/UX Design

An exception-first client portal designed to replace spreadsheet workflows for finance teams.

FAQ

What type of organizations is this solution most relevant for?

Non-bank lenders, supply chain finance providers and trade finance funders that underwrite companies from financial statements. It fits best when three conditions meet. The lender wants AI to speed up underwriting. Applicant data is too sensitive to send to a model as-is. And credit decisions must stay explainable. It also suits lenders who plan to license their platform to other funders, because every component was chosen to allow sublicensing.

Why were deterministic rules placed before the language model?

Regulators expect lenders to state the specific reasons behind an adverse credit decision. A language model cannot reliably give those reasons. Deterministic rules can, and every outcome traces to a versioned policy. Under current US supervisory guidance, deterministic rule-based processes also fall outside the definition of a "model", which avoids a full model-validation burden. The language model therefore drafts the narrative and the rules make the call. Borderline cases go to a human underwriter.

Is de-identification the same as anonymization?

No. Because authorized staff can reverse the token mapping, the design is pseudonymization in the GDPR sense, and the platform describes it that way. It is a strong control, not an absolute guarantee. For that reason, acceptance was based on measured detection accuracy against the client's own test documents, plus a documented residual-risk review. Financial figures, dates and statement structure stay intact, so underwriting quality does not suffer.

What were the biggest technical risks, and how were they managed?

Three risks dominated. Consistent token substitution might not hold on real statements. The credit policy might be expert judgment rather than thresholds. And no test set existed to measure accuracy. Itexus ran proofs of concept on the first two during discovery. AI underwriting was scheduled after the portals, so that the client's test set would exist before that module was built. Zero-retention terms with the model provider were started early, because their approval lead time sits with the provider.

Why were the portals delivered before AI underwriting?

The client portal and operations desk solved the most urgent daily problem — invoices arriving by email — and did not depend on any missing input. AI underwriting did depend on one. Its acceptance criterion was accuracy measured on a test set that did not yet exist. Building toward a target that cannot be measured is a delivery risk, so Itexus sequenced the modules on technical grounds rather than commercial ones.

How long does a similar project take and what drives the cost?

This project took about 7 months. The main cost drivers are the de-identification layer, the number of intake channels, and the non-functional bar: encryption, audit, accessibility and uptime. In this type of platform, the shared foundation and security work form a large share of the effort. Cutting screens therefore saves less than phasing modules. A paid discovery phase with proofs of concept is the most reliable way to turn a rough estimate into a committed budget.

Looking for a lending platform partner?

We help lenders speed up underwriting with AI, protect sensitive applicant data, and own the platform they build.