Mirror's integration points sit inside the bank, where the data is. None of them sends a raw value anywhere.
| Integration point | What it connects | Status |
|---|---|---|
Documentary credits (mirror-connect mt700) | A trade-finance platform's letters of credit, read as the SWIFT MT700 / MT710 / MT720 message every such platform sends | Built; tested (kernel/mirror-mt700.test.js) |
Electronic bills of lading (mirror-connect ebl) | Carriers' and eBL platforms' transport documents in the DCSA eBL 3.0 standard | Built; tested (kernel/mirror-ebl.test.js) |
Origination sidecar (origin/mirror-origin-sidecar.js) | The trade platform, at booking. It posts a document's figures to a loopback service, which mints a document salt and signs the origin commitment with the platform's origination key (a key file, or the platform's HSM). The salt stays with the document; the signed origin goes to the bander. | Built; tested over a real socket (server/origin-sidecar.test.js) |
ISO 20022 ingest (mirror-bander ingest) | Payment messages: pacs.008 / pain.001, read beside the API gateway | Built |
| E-invoice readers | CFDI, NF-e, IRN and FatturaPA registrations | Built as kernels |
Historical exports (mirror-bander import-check, band --mapping) | Any CSV or delimited export with the bank's own headers and document codes. A dry run reports counts and column names only, never a value. | Built; tested (server/import-tooling.test.js) |
Band tables (mirror-bander table-import) | A bank's table, turned into a corridor.propose event ready for signing | Built |
| Push to the bank | Signed webhooks, and a pull-based SIEM export | Built (webhooks, SDK) |
| Infrastructure as code | Terraform: a module and a compiled provider | Built; tested with a real terraform |
The two reference connectors#
Trade platforms differ, but the messages they exchange are standard. Reading the standard message connects to every platform that emits it, at the one layer they share, without integrating with any vendor's product.
node connectors/mirror-connect.js mt700 credit.txt [--decimal comma] [--type MT710]
node connectors/mirror-connect.js ebl transport-document.json
It prints the reading as JSON for the local bander, or the refusal and its reason. Exit codes: 0 read, 2 refused, 64 usage. Neither reader has any network code. Their output is raw, and it stays in the bank. The bander bands it, and the operator refuses every one of those fields at its door (raw_leaked).
Documentary credits: MT700, MT710, MT720#
The credit becomes a leg with the role credit: what the buyer's bank will pay for the goods. It is banded beside the invoice, customs and payment legs.
What it reads:
| Field | Read as |
|---|---|
| 32B | The credit amount, in SWIFT's amount format |
| 45A | One quantity in one unit, the unit price if one is stated, and the Incoterm (2020 rules) with its named place, as a price basis |
| 39A | The amount tolerance. "About" or "approximately" means 10%, per UCP 600 art. 30(a) |
| 44C | The latest shipment date |
| 44E / 44F | The ports, as written |
| 20 (MT700), or 21 (MT710 / MT720) | The credit number, as join material |
Free-text numbers are read with the decimal convention the bank declares (--decimal), never a guessed one.
What it never reads: parties (fields 50 and 59), bank identifiers, and the documents required (46A).
What it refuses, with the reason:
- an MT707, because an amendment changes the terms: band the credit as amended;
- two quantities, or several goods items;
TONS, because metric, short and long tons differ;- a unit price in another currency;
- a stated unit price that disagrees with 32B รท quantity by more than 0.5%;
- a message with no credit number to join on.
Electronic bills of lading: DCSA eBL 3.0#
Each container becomes a cargo key (the ISO 6346 container number, the UN/LOCODE port of loading and the shipped-on-board date) and a declared mass. The cargo key is built by the same function the terminal side uses.
- Field names were checked against the published
EBL_v3.0.4OpenAPI schema. The older 2.x flat weight form is also read. - Weights are summed per container. Pounds become kilograms exactly (0.45359237 kg/lb).
- The weight is the shipper's declaration. A bill of lading's weight is "said to contain", so the reader labels it
shipper-declared. It is never treated as a measurement: a terminal or weighbridge witness supplies that. - What it refuses: a bill that is not shipped on board (no load date, so no cargo key), a container number that fails its ISO 6346 check digit, an unknown document type, and a document with no equipment.
- Nothing is dropped. An item that cannot be read is counted in
unreadablewith its reason, andcompleteis true only when there are none. - What it never reads: parties, charges and free-text clauses.
What is not claimed#
- No named platform is connected. Both readers were written from the published message standards and tested against messages built here. They have not seen any bank's, carrier's or platform's live traffic, and no one has certified them. Until a platform is actually connected, this page will not name one.
- Platform-specific work remains. Mapping a platform's booking event to the origination sidecar, and its exports to
--mapping, is done per platform, with the platform's owner.