How we built a trade finance platform in 12 weeks
A behind-the-scenes look at the architecture decisions, trade-offs, and lessons learned building TradeGuardian, a B2B SaaS platform for SME exporters.
When Dipesh from TradeGuardian first called us, he described the problem in one sentence: "SME exporters are managing letters of credit and bank guarantees in Excel and WhatsApp groups, and it is costing them money."
That sentence contained enough information to start designing a system. The core of the problem was not technology. It was information fragmentation. Documents, deadlines, and bank communications were spread across email, WhatsApp, and physical files. Nobody had a single view of what was open, what was overdue, and what needed action today.
The domain first
Before we wrote any code, we spent two weeks learning trade finance. Letters of credit, bank guarantees, sight drafts, usance bills, documentary collections. This was not optional background reading. Getting the data model wrong in a fintech product means either a rewrite or a brittle system held together with workarounds.
We interviewed four exporters and three trade finance bankers. What we found surprised us: the most painful point was not missing deadlines. It was the scramble to find the right document at the right time when a bank called. Exporters could not instantly answer "what is the current status of the LC for the Fujairah shipment."
The data model
We structured the system around three core entities: TradeInstrument, Document, and TradeEvent.
A TradeInstrument is an LC, bank guarantee, or documentary collection. It has a lifecycle (draft, submitted, active, under amendment, closed), a value, an expiry date, and a set of required documents.
A Document is a file attached to an instrument. Each document has a type (bill of lading, invoice, packing list, certificate of origin), a status (draft, submitted to bank, accepted, rejected), and an expiry if applicable.
A TradeEvent is an immutable log of anything that happened to an instrument: document uploaded, status changed, amendment requested, deadline extended. This audit log was not an afterthought. Banks need to see the full history during disputes.
The deadline system
Trade finance instruments have hard deadlines. An LC expires. A presentation period closes. Missing these deadlines triggers penalties or instrument cancellation. This was the highest-stakes part of the system to get right.
We built a deadline engine using Laravel's scheduler. Every night, the system calculates how many days are left on each active instrument and queues alerts for day 30, day 14, day 7, day 3, and day 1. Alerts go to the account owner by email and in-app notification. The account owner can also add custom alerts for their own internal review dates.
One thing we got right early: we stored all dates in UTC and handled timezone conversion only at display time. This sounds obvious but it is easy to get wrong when clients are in India and their banks are in Singapore or Germany.
The document upload and OCR layer
Exporters upload documents as PDF or image scans. We added a lightweight OCR layer using Python and Tesseract that extracts key fields from uploaded documents: invoice number, amount, date, exporter name. This pre-fills the document metadata form and reduces manual entry errors.
The OCR does not need to be perfect. It is a suggestion, not a decision. The user reviews and corrects the extracted values before saving. This "human in the loop" approach meant we could ship the OCR feature without worrying about edge cases breaking the data.
The invoice discounting marketplace
The second phase of the product was a marketplace where NBFCs and financiers could bid on invoice discounting for verified exporters. An exporter with a confirmed LC could list their receivable and get competitive financing rates.
This required a bidding engine, KYC verification for both exporters and financiers, escrow-style fund handling, and a commission calculation layer. We used Razorpay's payout API to handle disbursements.
The bidding engine was a simple first-price sealed-bid auction with a 24-hour window. Exporters could see the lowest rate in real time and accept when they were satisfied. We deliberately kept the auction mechanics simple because both exporters and financiers were new to digital trade finance tools.
What we would do differently
We underestimated the complexity of the amendment workflow. When an LC gets amended, it affects documents, deadlines, and potentially the financing terms. We modelled amendments as TradeEvents initially, which was too simple. We ended up adding an Amendment model with its own lifecycle. If we were starting over, we would model amendments as first-class entities from day one.
We also would have pushed for a phased rollout more aggressively. We launched with all features at once, which made onboarding harder. Exporters were overwhelmed by the full feature set. A simpler initial version focused only on document tracking and deadline alerts would have driven adoption faster.
The numbers 12 weeks later
40 exporters onboarded in the first 6 months. 800 trade instruments tracked. Zero missed compliance deadlines reported by clients using the platform. The invoice discounting marketplace went live in month 4 and processed its first transaction within the first week.
Dipesh told us the thing users appreciated most was not the deadline alerts or the OCR. It was being able to answer a bank's question about an instrument in 10 seconds instead of 20 minutes.
That is what good software does. It makes the hard parts of someone's job feel easy.