Trade Finance and Documentary Credit Software: Why a Discrepant Document Set Is Still Chased Over Email

Why trade operations breaks the systems a bank already owns

A container of machinery is sitting at a port. The beneficiary presented documents against a letter of credit on Monday. Your examiner has five banking days following presentation to determine whether the presentation complies, and on day three she has found that the bill of lading shows a notify party that does not match the credit, the insurance certificate is dated after the shipment date, and the packing list describes the goods in slightly different words than the credit does. Two of those are discrepancies. One is arguable. The applicant is on the phone saying he wants the goods and does not care about the notify party, which does not by itself waive anything.

What happens next is entirely email. A refusal notice has to be sent with every discrepancy stated, within the period, or your bank loses the right to claim the presentation is discrepant. The applicant's waiver has to be sought and documented. The beneficiary's bank will argue. Meanwhile the exposure, the collateral, the applicant's limit and the accounting entries live in a different system that nobody has touched yet.

The trade platforms are real and mature. Finastra Trade Innovation, Surecomp and CGI Trade360 have been processing documentary credits for decades and they carry the message formats, the product definitions and the accounting. What they generally do not carry is your bank's operational layer: how examination work is distributed and measured, how discrepancy correspondence is generated and tracked, how a corporate client sees the status of its own credit, how screening results are attached to the transaction, and how your limits and collateral are actually calculated under your credit policy rather than a generic one.

So banks build that layer anyway, out of email, spreadsheets and a shared drive, and it becomes the part of trade operations that depends entirely on three experienced people.

Problem 1: examination is a five banking day clock, run from memory

Under UCP 600 the examination period is a maximum of five banking days following the day of presentation, and a refusal must state each discrepancy. Miss the period or state the discrepancies incompletely and the bank can be precluded from claiming the presentation does not comply. That is a real financial consequence attached to an administrative process.

In most desks the clock is tracked on a whiteboard or in an examiner's head, and holidays across two or three jurisdictions make banking day arithmetic error prone. Presentation logging is manual, so the clock starts when someone records it rather than when the courier arrived.

A build should make the clock unambiguous: presentation logged at receipt with a scanned envelope and a timestamp, banking day calendars per jurisdiction maintained as data, a live countdown visible on every open presentation, and escalation when a file is unassigned or approaching the limit. Examination itself should be structured rather than a narrative: a checklist derived from the credit terms and the documents required, so the examiner works through document by document and each finding is recorded as a discrepancy with the credit clause and the applicable rule cited. Then the refusal notice is generated from the findings rather than typed, which is precisely how incomplete refusals get avoided.

Document extraction earns its keep here in a specific way. A bill of lading, an invoice and an insurance certificate are semi structured, and a model can pull shipper, consignee, notify party, ports, dates, amounts and descriptions into a comparison view against the credit. It should never decide compliance. It should put the two versions side by side so the examiner spends her expertise on judgement rather than on reading dates off scans.

Problem 2: the message and the ledger are two systems with a person between them

An issuance goes out as a SWIFT message. An amendment goes out as another. The advising bank replies. A refusal advice, an authorisation to pay, an advice of payment all follow. Every one of those messages contains data that also has to exist in your limits system, your collateral records, your fee billing and your general ledger. In a great many banks a person reads the message and types the data again.

Every re-key is a defect opportunity, and the defects in trade are expensive because they are legal. A tenor typed as 90 days when the credit says 180. An amount entered without the tolerance. A confirmation status recorded wrongly, which changes who is on risk.

What a build should do is treat the message as the source and the internal systems as subscribers. Parse the message once, map the fields, post to limits and accounting through defined interfaces, and reconcile automatically so a mismatch raises an exception rather than sitting quietly. The ongoing migration of correspondent banking messaging to ISO 20022 formats makes this more valuable, not less, because a bank with a clean internal mapping layer absorbs a format change in one place rather than in every downstream process. If your desk still receives instructions by fax or PDF from smaller counterparties, and most do, those go through the same structured intake with a review queue.

Problem 3: limits and contingent exposure move with every event

An issued and unutilised credit is contingent exposure. On presentation and acceptance it becomes something else. A deferred payment undertaking is a dated obligation. A confirmation puts you on the issuing bank's risk rather than the applicant's. A discounted acceptance is funded exposure. Each of those states carries a different limit consumption, a different capital treatment and often different collateral.

Generic limit systems handle drawn and undrawn. Trade needs the states, and it needs them per counterparty, per country, per tenor bucket. The practical failure is a desk that cannot answer, at 3pm on a Tuesday, what its exposure is to a specific issuing bank across all outstanding confirmations, because the answer requires joining a trade system export to a spreadsheet of confirmations.

A build should express exposure as a function of transaction state, so every event updates it automatically: issuance, amendment, presentation, acceptance, discount, payment, expiry. Cash collateral, pledged deposits and margin get held against specific transactions rather than sitting as a note. Country and bank limits are checked before issuance rather than after, and the check that blocks a deal should also tell the officer exactly which limit is the constraint and by how much. That is the difference between a control that helps and a control that gets bypassed.

Problem 4: sanctions and goods screening cannot be a separate step

Trade is the sharpest sanctions surface in a bank because the parties are foreign, the goods may be controlled, the vessel matters, and the route matters. Screening the applicant and beneficiary is the easy part. The exposure sits in vessel names, ports of loading and discharge, transhipment, goods descriptions that may fall under dual use controls, and the possibility that a document set names a party nobody screened.

When screening runs as a separate system that a compliance officer checks manually, two things go wrong. Names that appear only in the shipping documents never get screened at all. And the screening result is not attached to the transaction, so proving what was checked and when becomes an exercise in searching two systems.

A build should orchestrate screening rather than duplicate it. Every party, vessel, port and goods description extracted from the credit and from the presented documents goes to your existing screening engine, and the result attaches to the transaction as an immutable record with the list version used. Hits open a case with a decision, a rationale and an approver, and the transaction cannot proceed while a case is open. Goods descriptions that touch controlled categories raise a flag for review rather than pretending a keyword match is an export control determination. This is one of the clearest returns in the whole build, because the alternative is a manual process defended in an examination with screenshots.

Problem 5: your corporate client can see none of this

The applicant is a treasury team at a manufacturer. They want to raise an amendment, see whether documents have been presented, know whether there are discrepancies and decide on a waiver, all without phoning your operations desk. Today they phone your operations desk.

A corporate portal is often where the commercial case for the build actually sits. Application forms structured from your credit templates so an application arrives complete. Amendment requests with the changed fields visible. Status visibility on every transaction. Discrepancy notices delivered with the documents attached and a waiver decision captured with the authorised signer recorded. Document upload for collections. Trade desks that offer this win mandates from banks that do not, and the operational saving is real: a substantial share of inbound calls to a trade desk are status questions.

Electronic documents are moving in the same direction. Platforms such as Bolero have carried electronic bills of lading for years, and the legal recognition of electronic transferable records has been advancing in several jurisdictions. Build so that a document can be a reference to an electronic record rather than assuming paper, even if most of your volume stays paper for now.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, this shape prices as follows. A focused first release covering presentation intake with the examination clock, structured examination with document extraction and comparison, discrepancy recording and generated correspondence runs $110,000 to $250,000 and ships in 16 to 24 weeks. A full platform adding guarantees and standby credits, collections, limits and contingent exposure by transaction state, screening orchestration, message parsing and posting, and a corporate portal runs $300,000 to $800,000 phased over 10 to 18 months.

What drives cost up in trade finance specifically: integration with the existing trade platform and the core, which is almost always the largest single line and is dictated by what interfaces that platform actually exposes. Message handling, since correspondent messaging has a testing regime and a certification calendar you do not control. Multi entity and multi jurisdiction operation, because practice, language and regulatory reporting differ. Guarantees under demand guarantee rules, which is a different product with different mechanics from documentary credits. And any requirement to connect to an external electronic document platform.

What keeps cost down, and this is the important one: do not replace your trade core. Build the examination, exposure and client layer on top of it. Banks that try to rebuild issuance, messaging and accounting from scratch are taking on decades of accumulated product handling for no commercial gain.

Build versus buy, and when buying is the right call

Buy the core, always. If your bank issues a modest volume of straightforward commercial credits and standbys, Finastra Trade Innovation, Surecomp or CGI Trade360 will serve you well and there is no case for building. The product knowledge embedded in those platforms is worth more than any efficiency you would gain.

Build the layer around it when two or more of these are true. Your examiners re-key message data into limits or accounting and reconciliation breaks are routine. Your discrepancy correspondence is assembled in Word and tracked in email, so you cannot report on discrepancy rates by beneficiary or by examiner. Your corporate clients are asking for visibility you cannot provide and you are losing mandates over it. Your screening runs as a manual step alongside rather than inside the transaction. Or you are a commodity trader rather than a bank, in which case bank trade platforms are the wrong shape entirely and a build around your own trade capture and financing needs is usually the honest answer.

The tipping point is where your differentiated work happens. Issuance and messaging are commodity functions and you should rent them. Examination quality, exposure control and client experience are where trade desks compete, and those are the parts that packaged platforms leave to your operations staff and their inboxes.

How to choose a developer

Ask what they understand about the examination period and the consequences of an incomplete refusal notice. If they treat a discrepancy as a comment field rather than a structured finding tied to a credit clause and a rule reference, the generated notice will not be safe to send and your examiners will go back to Word.

Ask how they would integrate with your specific trade platform, by name. The available interfaces vary a great deal, and the honest answer sometimes involves file based exchange rather than live calls. A developer who has not asked what your platform exposes is guessing at the largest line in the estimate.

Ask how document extraction results are used. The right answer is a side by side comparison for the examiner and never an automated compliance decision. Anyone promising automated determination of compliance under the rules has misunderstood both the rules and the liability.

Ask how screening results attach to a transaction and how they prove what was screened against which list version. Examiners will ask you the same question and the answer should be a record, not a screenshot folder.

Ask who owns the code and settle it before kickoff. You should own the repository, the environments and the right to bring in another firm. At Digital Heroes the client owns the code from the first commit, and in a bank that is also the answer to the vendor concentration question your risk committee will raise.