TradeiX Loan Management: Case Study | Saiful Islam
Back to home
CASE / 03 · TRADEIX
010 / OVERVIEW
PRODUCT DESIGNER · 2020 to 2021 · 9 MONTHS

Loan management
on a blockchain

Trade finance still runs on email, fax, and phone calls. TradeiX set out to put buyers, suppliers, and banks on one automated ledger, and I designed the loan management system that made it usable.

TRADE FINANCE BLOCKCHAIN / DLT ENTERPRISE WEB APP ADOPTED BY MITSUBISHI BANK
020 / BACKGROUND

The Marco Polo Network moves trade finance transactions with security built into the ledger itself. The question was what happens when you point that at supply chain logistics, where a buyer, a supplier, and a bank all need to agree on a loan, its interest, and its settlement.

My job was the loan lifecycle: setup, approval, drawdown, and settlement, designed so a banker could trust it on the first pass and a supplier could finish it without training.

I worked on this alongside Shovo Poddar, a designer I shared a team with from 2016 to 2024. Nine months on this product together.

MY ROLE
Stakeholder research · Information architecture · User flows · Interaction design · UI · Prototyping · Design system contribution
TEAM
Two designers, working with the CEO, product owner, product manager, and engineering
TIMELINE
2020 to 2021, nine months
030 / THE PROBLEM

Finance still
runs on fax.

Loans get arranged over email, fax, and phone calls between parties who cannot see each other's records. Every handoff is a chance for a number to drift, and nothing moves quickly when the market does.

01

Three parties, no shared view

  • Buyer, supplier, and bank each work from their own records
  • Status lives in someone's inbox
  • Every step needs chasing
Result: delays nobody owns
02

Manual data, drifting numbers

  • Figures re-keyed at every handoff
  • Stock and loan records disagree
  • Paper settlement slows everything
Result: errors found too late to fix cheaply
03

Banking rules are not optional

  • Every action needs a second pair of eyes
  • Audit trails must hold up to review
  • Security standards constrain the interface
Result: compliance had to be designed, not bolted on
040 / GOALS & RESEARCH

Goals

  • Automate loan setup so parties chase each other less
  • Make every party's position visible to the others
  • Cut cost by making settlement paperless with eSign
  • Design maker-checker approval into the flow, not around it
  • Get stakeholder sign-off fast enough to keep the build moving

Research

STAKEHOLDER INTERVIEWS CEO / PO / PM ALIGNMENT DOMAIN & COMPLIANCE STUDY INFORMATION ARCHITECTURE HAPPY / UNHAPPY PATH MAPPING
  • In banking, the second approver is the product, not an edge case
  • Trust comes from showing state, not from reassuring copy
  • Unhappy paths are where finance software is actually judged
  • Aligning with the CEO early bought speed later
050 / WHAT I DESIGNED

Strategy into
interface

PRINCIPLE A
Make the loan's state legible to every party at a glance.
PRINCIPLE B
Build approval into the path so compliance never feels like a detour.
PRINCIPLE C
Remove paper wherever a signature is the only reason for it.
DELIVERABLE 01

Loan lifecycle

Setup, approval, drawdown, interest, and settlement as one continuous flow, with each party seeing exactly where the loan stands and what it needs from them next.

TradeiX loan lifecycle
TradeiX maker-checker approvals
DELIVERABLE 02

Maker-checker
approvals

Banking requires two people to complete a transaction. I designed the four-eyes principle into every stage of the lifecycle: who submitted, who verified, what changed, and what is still waiting on a second signature.

DELIVERABLE 03

Paperless
settlement

Documents, invoices, and communications generated from templates and signed in place, so a settlement that used to travel by courier now closes inside the platform.

TradeiX paperless settlement
060 / IMPACT
MITSUBISHI
BANK ADOPTION
0→1
SYSTEM DESIGNED END TO END
9MO
CONCEPT TO SIGN-OFF
Figma FIGMA / PROTOTYPE Loan management system Figma FIGMA / DESIGN SYSTEM TradeiX design system
070 / LEARNINGS
  • Regulated products reward designers who learn the rules first
  • Multi-party software lives or dies on shared state
  • Mapping unhappy paths early saved months of rework
  • A shared design system let two designers move like four

Conclusion

A loan process that ran on email and paper became a single automated lifecycle that banks were willing to put their name against. Designing compliance into the flow rather than around it is what made a blockchain trade finance product feel like ordinary, trustworthy software.

080 / CONNECT

Got a complex
product to simplify?

PREVIOUS EventBookings Platform Redesign NEXT CASE STUDY Exsited Billing Platform