Platform — More Trade Finance · Evermore Systems Limited

Product comparison

ILC vs LCR — which product fits your role?

Both products use the same platform services. The difference is the entry point and the message flow direction.

📥

Import LC (ILC)

Entry point: Applicant request to open a credit.

Direction: Outbound-first (MT700, MT707, MT732/752/734).

Events: 9 (REG, PRE, ISS, AMD, ACK, CLMDPE, CLMDIS, CLMREQ, CLMSET).

SWIFT types: 10 (MT700, MT705, MT707, MT730, MT732, MT752, MT734, MT754, MT756, MT202).

Master record: LC Master (tracks available/outstanding/claimed).

Applicant-side · UCP 600

📤

LC Reimbursement (LCR)

Entry point: Incoming MT740 from issuing bank.

Direction: Inbound-first (MT740, MT747, MT742, MT744).

Events: 7 (RAUTH, RAMD, RACK, RCLMV, RRFS, RPAY, RCLS).

SWIFT types: 7 (MT740, MT747, MT799, MT730, MT742, MT744, MT756, MT202).

Master record: ReimbursementMaster (tracks authorized/utilized/outstanding/available).

Interbank · URR latest

🔗

Shared platform services

Both products run on the same operational core — no duplication, consistent behaviour.

Maker–checker workflow queues (Input → Update → Approval → Cancellation)
Release tabs: Posting, Charges, Swift, Advice, Settlement
Inbound SWIFT parsing, validation, matching, Pending → Processed
Outbound SWIFT generation, validation, Generated → Released
Release pipeline prevents double-dispatch and duplicate emails
Amount tracking with audit trail (available/outstanding/claimed)
Product configuration screen defines queues, charges, SWIFT, rules, accounting per event

Import LC pipeline

ILC: From registration to settlement — 9 events

The end-to-end flow models each action on the LC as an event. Every event is captured on a form, passes through maker–checker workflow queues, and — when configured — releases accounting postings, charges and SWIFT messages at approval.

Diagram 1 — ILC End-to-End Lifecycle

Solid arrows = normal flow. Dashed = optional shortcut. Hover stages; details in sections below.

flowchart TD
    APP(["Applicant request"]) --> REG["1 · Register (REG)"]
    REG --> MASTER(["LC Master hub — lifecycle control"])
    MASTER -->|"optional"| PRE["2 · Pre-Advise (PRE) — MT705 out"]
    MASTER --> ISS["3 · Issue (ISS) — MT700 out"]
    PRE -.->|"proceed to full issue"| ISS
    ISS -->|"on approval: accounting initialised"| LIVE(["LC live — advised to beneficiary"])
    MASTER -->|"any number of times"| AMD["4 · Amendment (AMD) — MT707 out"]
    AMD -->|"amounts recalculated"| LIVE
    LIVE -->|"advising bank confirms"| MT730IN["MT730 in"]
    MT730IN --> ACK["5 · Acknowledgement (ACK)"]
    LIVE --> PBS(["Presenting bank presents documents"])
    PBS --> CLMDPE["6a · Document Presentation (CLMDPE)
MT732 / MT752 / MT734 out"]
    PBS -->|"MT750 in"| CLMDIS["6b · Discrepancy (CLMDIS)
waive vs refuse"]
    CLMDIS -->|"waive"| W752["MT752 out"]
    W752 --> CLMREQ["7 · Claim Request (CLMREQ) — MT754 in
MT756 + MT202 out"]
    CLMDIS -->|"refuse"| W734["MT734 out"]
    W734 --> RET(["Documents returned — no settlement"])
    PBS -->|"MT754 in (clean)"| CLMREQ
    CLMREQ --> CLMSET["8 · Claim Settlement (CLMSET) — MT756 out"]
    CLMSET --> PAID(["Settled — LC drawn down"])

Diagram could not be rendered — an internet connection is required for chart display.

1

REG — Registration

Capture customer request, create register record, boot LC Master with applicant, beneficiary, currency, amount. No SWIFT, no postings.

LC Master created

2

PRE — Pre-Advise (MT705)

Optional telegraph of provisional terms before full issuance. MT705 out on approval.

Optional · MT705 out

3

ISS — Issue (MT700)

Formal credit issuance. MT700 out (+ MT740 to reimbursing bank, MT202 where configured). Liability amount = LC amount + tolerance. Accounting initialised: utilised=0, available=liability, outstanding=liability.

MT700 · MT740 · MT202

4

AMD — Amendment (MT707)

Change terms/amounts any number of times. Increase (32B) / decrease (33B) recalculates availability and liability. MT707 out on approval.

MT707 · Amount recalc

5

ACK — Acknowledgement (MT730)

Record advising bank's confirmation (MT730 in). Match to issue/amendment. Reconcile charges (32B/33B). MT202/MT799 out where configured.

MT730 in · Charge recon

6a

CLMDPE — Document Presentation

Record presentation, select honour/refuse. MT732 (honour), MT752 (authorize pay/accept/negotiate), MT734 (refuse) out. Claim case opened.

MT732 · MT752 · MT734

6b

CLMDIS — Discrepancy (MT750)

Incoming MT750 triggers waive (MT752) or refuse (MT734) decision. Waive → CLMREQ. Refuse → documents returned, no settlement.

MT750 in · Waive/Refuse

7

CLMREQ — Claim Request (MT754)

Presenting bank claims reimbursement via MT754. On approval: MT756 + MT202 out. Settlement record staged.

MT754 in · MT756/MT202 out

8

CLMSET — Claim Settlement

Final settlement advice with charges (MT756). Completes a claim cycle — not the LC. LC may have multiple presentations until exhausted.

MT756 · Cycle complete

LC Reimbursement pipeline

LCR: From MT740 authorization to closure — 7 events

LCR is message-driven: the incoming MT740 from the issuing bank is the single entry point. It creates the Reimbursement Master, which becomes the hub for every later event.

Diagram 2 — LCR Lifecycle Overview

Authorization (MT740 in) is the entry point. Arrow labels show what triggers each branch.

flowchart TD
    RAUTH["1 · RAUTH
Authorization (MT740 in)"]
    RM[("Reimbursement Master
created from the MT740
status: AUTHORIZED")]
    RAMD["2 · RAMD
Amendment (MT747 in)"]
    RACK["3 · RACK
Acknowledgment (MT799 / MT730 out)"]
    RCLMV["4 · RCLMV
Claim Verification (MT742 in)"]
    RRFS["5 · RRFS
Claim Refusal (MT744 in / out)"]
    RPAY["6 · RPAY
Payment Advice (MT756 / MT202 out)"]
    RCLS["7 · RCLS
Closure (MT799 out)"]

    RAUTH -->|"creates"| RM
    RM -->|"amend"| RAMD
    RAMD -->|"amended"| RM
    RM --> RACK
    RM -->|"claim"| RCLMV
    RCLMV -->|"clean claim"| RPAY
    RCLMV -->|"discrepant"| RRFS
    RRFS -->|"re-claim"| RCLMV
    RPAY -->|"fully paid / expired"| RCLS
    RCLS -->|"closed"| RM

    classDef startNode fill:#0b1d3a,color:#fff,stroke:#1e6fba,stroke-width:2px
    classDef masterNode fill:#1e6fba,color:#fff,stroke:#0b1d3a,stroke-width:2px
    classDef eventIn fill:#1a5a2a,color:#fff,stroke:#2a7f2a,stroke-width:2px
    classDef eventManual fill:#4a4a4a,color:#fff,stroke:#777,stroke-width:2px
    classDef eventOut fill:#5a3a00,color:#fff,stroke:#6a4c00,stroke-width:2px
    class RAUTH startNode
    class RM masterNode
    class RAMD,RCLMV,RRFS eventIn
    class RACK,RCLS eventManual
    class RPAY eventOut

Diagram could not be rendered — an internet connection is required for chart display.

1

RAUTH — Authorization (MT740)

Entry point. MT740 from issuing bank parsed → ReimbursementMaster created with amount, expiry, parties. Amounts: authorized=32B, utilized=0, outstanding=authorized, available=authorized. Status: AUTHORIZED.

MT740 in · Master created

2

RAMD — Amendment (MT747)

Incoming MT747 amends ceiling, expiry, terms. Increase (32B) / decrease (33B) / new ceiling (34B). Floor: new ceiling ≥ utilized. Expiry forward-only. Amounts recalculated on approval.

MT747 in · Amount recalc

3

RACK — Acknowledgment

Manual event. Send MT799/MT730 to issuing bank acknowledging receipt of auth/amendment. Reconcile charges. No amount changes.

MT799/MT730 out

4

RCLMV — Claim Verification (MT742)

Presenting bank submits MT742 claim. Verified against authorization: amount ≤ available, currency match, date ≤ expiry, duplicate guard. Drawdown: utilized+=claim, outstanding-=claim, available=authorized-utilized-outstanding. Settlement staged.

MT742 in · Drawdown

5

RRFS — Claim Refusal (MT744)

Non-conforming claim via MT744. Record refusal, update master status → REFUSED. Outbound MT744/MT799. May return to RCLMV if presenting bank re-submits corrected claim.

MT744 in/out · Refusal

6

RPAY — Payment Advice (MT756)

Send MT756 + MT202 cover to issuing bank. Postings: debit nostro / credit issuing bank. Master status → PAID. Settlement record → SETTLED.

MT756/MT202 out · Paid

7

RCLS — Closure

Close when fully utilized, expired, or cancelled. MT799 closure advice. Master status → CLOSED, bookOffDate set.

MT799 out · Closed

Amount tracking

Both products track availability with precision

Every event that moves money updates the master record atomically — with audit trail and duplicate guards.

ILC — LC Master amounts

liability = LC amount + tolerance uplift utilised = sum of settled claim amounts available = max(0, liability - utilised) outstanding = max(0, liability - utilised) Amendment recalculates all four from new amount

Registration: only seeds amounts
Issue: liability opened, available = liability
Amendment: new LC amount → liability → available/outstanding recalc
Claim settlement: utilised increases, available/outstanding decrease

LCR — ReimbursementMaster amounts

authorizedAmount = MT740 Field 32B (updated by RAMD 34B) utilizedAmount = sum of verified claims (RCLMV) outstandingAmount = max(0, authorizedAmount - utilizedAmount) availableAmount = max(0, authorizedAmount - utilizedAmount - outstandingAmount) RAMD: newCeiling = current + increase - decrease

RAUTH: all four initialized from MT740
RAMD: ceiling change → outstanding/available recalc
RCLMV: claim verified → utilized up, outstanding/available down
RRFS: no amount change (claim rejected)
RPAY: confirms funds movement, status → PAID

Status machines

Every record has a traceable status lifecycle

ILC — LC Master status

Idle → Acknowledged / Amended → Presented → Paid / Refused → (repeat per presentation) → Formal closure (book-off) tracked separately.

ILC — Event workflow status

Per-event: P — In Progress → AP — Approved (or CN — Cancelled). Workflow reference = event code + sequence, fully traceable in history.

LCR — ReimbursementMaster status

AUTHORIZED → AMEND / ACKNOWLEDGED → CLAIMED → PAID / REFUSED → CLOSED.

Walk the full flows with your own data

The ILC and LCR product pages show every stage with expandable details, SWIFT message maps, and validation rules.

Explore ILC flow →

Two products. One shared platform.