Let Digiqt design deployment evidence that is emitted automatically, stored immutably, and retrievable in minutes.

Evidence That Holds Up Under Examination

# Answering the Examiner Without a Three-Week Evidence Hunt

A regulator or internal auditor picks a production change from four months ago and asks a small number of very reasonable questions. Who approved this. Who reviewed the code. What testing passed before it went out. Is the thing running in production the thing that was approved. And how do you know nothing else was deployed that day.

In most institutions the answers exist, scattered across a source control system, a ticketing system, a scanning tool, a deployment platform, and somebody's inbox, with retention policies that differ across all five. Building an audit ready CI CD financial evidence trail means emitting those answers as a by-product of shipping, rather than assembling them under time pressure months later.

## What does an examiner actually ask for?

A short list of questions, each of which maps to a specific artefact.

| Question | Evidence artefact | Where it should come from |
|---|---|---|
| What business need drove this change? | Change or requirement reference | Work tracking, linked from the commit |
| Who reviewed the code, and were they the author? | Review record with identities | Source control, enforced not conventional |
| Who authorised release to production? | Approval with identity and timestamp | Deployment gate, not an email |
| What testing passed? | Test run results tied to the artefact | Pipeline execution record |
| Was the code scanned for vulnerabilities? | Scan results and disposition of findings | Pipeline execution record |
| Is production running what was approved? | Artefact hash and build provenance | Build platform attestation |
| When and by what identity was it deployed? | Deployment record | Deployment platform log |
| Could it be reversed? | Rollback evidence or forward-fix plan | Change record plus tested procedure |
| Did anything else go out? | Complete change population reconciliation | Pipeline plus production access logs |

The last row is the one that is almost never answerable, and it is often the one that matters most. Everything above it concerns a change you already know about.

## Why does evidence collection usually fail?

Because it is treated as a reporting activity rather than an output of the delivery process.

The common pattern is a compliance analyst who receives an audit request, emails four teams, receives screenshots, assembles a pack, and submits it. That process produces something, and what it produces is weaker than it looks: screenshots have no integrity guarantee, the assembly introduces selection, retention gaps get papered over, and the whole exercise takes weeks of skilled time per examination. It also scales badly, since the effort is linear in the number of changes sampled while the underlying control is either operating or not.

### Why is reconstructed evidence weaker than evidence emitted at the time?

Because a reviewer cannot distinguish an accurate reconstruction from a convenient one.

If the approval record is a screenshot of a chat message, the reviewer is being asked to trust that the message was not edited, that it referred to this change, and that no contrary message exists. If the approval is an immutable pipeline record created at the moment the gate was passed, carrying the approver's authenticated identity and the artefact hash, none of that trust is required. The distinction is not pedantry. It is the difference between evidence that establishes the control operated and evidence that merely does not contradict the claim.

> **Could you produce complete evidence for a randomly chosen production change from six months ago?**
>
> [Talk to Digiqt about deployment evidence design](https://digiqt.com/contact-us/)

## What is the minimum evidence set per change?

Eight artefacts, all linked by a single identifier, all emitted automatically.

The set is the middle column of the table above, and the essential design property is linkage. A change reference that appears on the commit, the artefact metadata, the test run, and the deployment record turns nine separate records into one traceable chain. Without that identifier the evidence exists but cannot be assembled, which is functionally the same as not existing. Enforce the linkage at commit time by rejecting commits without a valid reference, and carry it through the build into the artefact so it survives into production.

Note that the evidence set describes the control operating rather than replacing the control itself. Whether one person can author and approve their own change is a separate design question, addressed in [automating change approval and segregation of duties](https://digiqt.com/blog/segregation-of-duties-ci-cd-banking/). Evidence proves what happened; enforcement determines what can happen.

## How does build provenance work?

The build platform attests to what it built, from what, and how, and signs the attestation.

SLSA, currently at version 1.2 with Approved status, sets out a build track with three levels. Build L1 requires that provenance exists: the platform automatically generates provenance describing the artifact, the entity that built it, and the top-level inputs to the build. Build L2 adds that the hosted build platform generates and signs the provenance itself, which prevents tampering after the build. Build L3 adds hardened builds, requiring that runs cannot influence one another and that the secret material used to sign provenance is inaccessible to user-defined build steps, which protects against tampering during the build.

| Level | Adds | Audit question it answers |
|---|---|---|
| Build L1 | Provenance exists, generated by the platform | What was this artefact built from, and by whom |
| Build L2 | Platform generates and signs the provenance | Has the artefact or its provenance been altered since the build |
| Build L3 | Isolation between runs, signing secrets out of reach of build steps | Could a build step have forged its own provenance |

For a bank the practical value is that provenance turns "is production running the approved code" from an assertion into a verification. It also gives a defensible answer on dependency origin, which is the exposure discussed in [software supply chain attacks](https://digiqt.com/blog/threat-led-penetration-testing-financial/).

### Why does a signed artefact hash answer several questions at once?

Because it collapses source, build, and deployment identity into one verifiable fact.

If the deployment record names an artefact hash, and the signed provenance for that hash names the reviewed commit and the build platform, then a single verification establishes that the deployed binary came from reviewed source through a controlled build. Three separate evidence questions become one cryptographic check that an auditor can repeat independently rather than take on trust. That independence is what distinguishes strong evidence from thorough documentation.

## How do you make evidence immutable and retrievable?

Append-only storage, indexed by change reference, retained for the full period, with synchronised time.

Evidence should be written once to a store that the delivery teams cannot alter, retained for whatever period the institution's record-keeping obligations require, and indexed so a query on a change reference returns the whole chain. Time synchronisation matters more than it sounds, since an approval timestamped after the deployment it authorised is a finding regardless of what actually happened. Event-sourced designs are a natural fit for this shape of problem, as covered in [event sourcing and CQRS for audit trails](https://digiqt.com/blog/event-driven-trading-system-architecture/), and the broader lineage discipline is the subject of data lineage and audit trail design.

### Why is retrieval time the real test?

Because evidence that takes three weeks to assemble has already failed the examination.

A reviewer who asks for a change's evidence and receives it in minutes draws a conclusion about the control environment before reading the contents. A reviewer who waits three weeks draws a different conclusion, correctly, because the delay is itself information about how integrated the controls are. Set an internal target of minutes for a single change and hours for a sampled population, and treat any failure to meet it as a defect in the evidence design rather than a resourcing issue.

## How do you evidence what did not happen?

By proving the change population is complete, which requires closing every path around the pipeline.

This is the hardest requirement and the one most estates cannot meet. It means every production change reconciles to an approved pipeline execution, and that any other route into production is either closed or monitored to the point where its use is detected and investigated. The paths to close are well known: direct server access, manual configuration change, database statements run by a person, vendor-applied patches, and infrastructure changes made through a console rather than code. Each needs either removal or detection, and the detection needs to be reconciled periodically so that an unexplained change is noticed within days rather than at the next audit.

| Bypass path | Control |
|---|---|
| Interactive server access | Removed, or just-in-time with session logging and reconciliation |
| Console-driven infrastructure change | Drift detection against the code definition, alert on divergence |
| Direct database manipulation | Break-glass only, logged, reviewed retrospectively |
| Vendor-applied change | Contractual notification plus independent detection |
| Configuration change outside version control | Configuration drift monitoring |
| Feature flags | Flag changes treated as changes, with their own audit record |

Feature flags deserve the explicit mention. A flag flip that changes customer-facing behaviour is a production change, and an evidence model that captures deployments while ignoring flags has a gap exactly where the behaviour changes fastest.

## How do you map evidence to control frameworks?

Once, deliberately, with the mapping maintained as a first-class artefact.

Build a matrix that maps each evidence artefact to the internal controls and external expectations it supports, so a single pipeline output serves multiple examinations rather than being reproduced in different formats for each. NIST's Secure Software Development Framework, version 1.1 published February 2022, gives a recognised vocabulary of high-level secure development practices aimed at reducing vulnerabilities and addressing root causes, which is useful as an organising spine. The EBA's guidelines on ICT and security risk management, applicable from 20 May 2025 and amended to align with DORA's application from 17 January 2025, establish ICT risk requirements for credit institutions, investment firms, and payment service providers. Mapping to a recognised framework also shortens conversations with supervisors during approval processes such as those described in [cloud migration regulatory approval](https://digiqt.com/blog/cloud-migration-regulatory-approval-banking/).

## How do you handle vendor-delivered change?

By requiring the same evidence contractually and verifying independently.

Where a vendor deploys into the institution's environment, or operates a service the institution depends on, the evidence chain crosses an organisational boundary and usually thins out. Specify what is required in the contract, including notification, artefact identification, and change records; then verify independently through drift detection rather than relying on the vendor's assurance. Concentration makes this sharper, since a single provider's change process becomes a shared dependency, which is the exposure examined in [third-party concentration risk](https://digiqt.com/blog/third-party-concentration-risk-cloud/). Resilience obligations pull in the same direction, as set out in [operational resilience and impact tolerances](https://digiqt.com/blog/operational-resilience-impact-tolerance/).

## How do you keep it honest?

By auditing yourself on the same terms an examiner would, on a schedule.

Run periodic self-tests: pull a random production change, attempt to produce the complete evidence chain within the target time, and record what was missing. Sample the change population reconciliation and investigate anything unexplained. Test the negative assertion specifically, because it decays silently as new deployment paths appear. Publish the results internally, including the failures, since a self-testing programme with no findings is not testing anything. Testing evidence quality is a natural partner to testing the software itself, which is the subject of [core banking regression automation](https://digiqt.com/blog/core-banking-test-automation/).

> **Do your feature flag changes generate the same audit record as your deployments?**
>
> [Talk to Digiqt about change population completeness](https://digiqt.com/contact-us/)

## How should this be sequenced?

Linkage first, then automatic emission, then provenance, then completeness, then self-testing.

| Phase | Duration | Deliverable |
|---|---|---|
| Change reference linkage | 1 month | Enforced reference from commit through artefact to deployment |
| Automatic evidence emission | 2 months | Review, approval, test, and scan records written by the pipeline |
| Immutable evidence store | 1 to 2 months | Append-only, indexed by reference, retention aligned to obligations |
| Build provenance | 2 to 3 months | Signed provenance for every artefact, verified at deploy |
| Bypass path closure | 3 to 4 months | Interactive access, console change, and direct database routes controlled |
| Change population reconciliation | 2 months | Every production change tied to an approved execution |
| Feature flag audit records | 1 month | Flag changes captured with the same rigour as deployments |
| Control framework mapping | 1 month | Matrix from artefact to control, maintained |
| Self-testing programme | Ongoing | Scheduled sampling with published results |

## Which metrics matter?

Evidence retrieval time, evidence completeness rate, unexplained production changes, provenance coverage, and self-test findings.

Retrieval time for a single change and for a sampled population is the operational measure. Evidence completeness, meaning the proportion of sampled changes with a full chain, is the quality measure. Unexplained production changes should be zero and any occurrence investigated, since a single one undermines the completeness assertion for the whole period. Provenance coverage tracks how much of the estate is verifiable rather than asserted. And self-test findings show whether the programme is examining itself honestly.

The goal is not a better evidence pack. It is an environment where the evidence is a by-product of how software ships, so that an examination becomes a query rather than a project.

## Frequently Asked Questions

### What does an examiner actually ask for about a deployment?

Who authorised this change, who reviewed the code, what testing passed, what artefact was deployed, when, by what identity, and how you know nothing else went out.

### Why is evidence assembled afterwards weaker than evidence emitted at the time?

Because reconstructed evidence depends on memory, screenshots, and inference, and a reviewer cannot distinguish an accurate reconstruction from a convenient one.

### What is the minimum evidence set for a single change?

Change reference, code review record, approval identity and timestamp, test results, security scan results, artefact hash with provenance, deployment record, and rollback capability.

### What does build provenance attest?

What entity built the package, what build process was used, and what the top-level inputs to the build were, which lets a consumer verify the artefact was built as expected.

### Why does a signed artefact hash answer several audit questions at once?

Because it links the deployed binary to a specific build, from specific reviewed source, on a specific platform, which collapses three separate evidence questions into one verifiable fact.

### Why is retrieval time the real test of an evidence trail?

Because evidence that exists but takes three weeks to assemble fails the examination in practice, and the delay itself suggests the control is not operating as described.

### How do you evidence that something did not happen?

By proving the completeness of the change population: every production change reconciles to an approved record, and any deployment path that bypasses the pipeline is closed and monitored.

### Who should test whether the evidence works?

The institution itself, through periodic sampling that pulls a random change and attempts to produce full evidence within a defined time, before an examiner does the same thing.

## Sources

- [SLSA v1.2, Build Track Basics](https://slsa.dev/spec/v1.2/build-track-basics)
- [NIST SP 800-218, Secure Software Development Framework (SSDF) Version 1.1](https://csrc.nist.gov/pubs/sp/800/218/final)
- [EBA, Guidelines on ICT and security risk management](https://www.eba.europa.eu/activities/single-rulebook/regulatory-activities/internal-governance/guidelines-ict-and-security-risk-management)

Audit-Ready CI/CD Evidence Trails Financial Regulators Accept

Let Digiqt design entity, goods, and vessel screening with case management that clears alerts fast.

Screen The Shipment, Not Just The Payment

# Checking What Is Being Shipped, By Whom, and On Which Vessel

Banks screen payments well. Names go through a matching engine against current lists, hits go to a queue, and the control is mature. Trade finance asks a harder question: not only whether the parties are permitted, but whether these goods may lawfully go to this destination for this end use, carried on this vessel, along this route, with these intermediaries involved.

That question sits mostly in documents rather than in structured messages, and it requires judgment about goods a bank has never handled. Building a trade compliance screening system means accepting that automation narrows the field and people make the determination, then engineering for that division of labour.

## What does screening actually cover?

Five dimensions, of which most institutions handle two well.

| Dimension | Question | Typical maturity |
|---|---|---|
| Parties | Are any of the parties restricted or connected to restricted persons | High |
| Goods | Are the items controlled, and under what classification | Low |
| Destination and end use | Is this destination or stated use permitted for these goods | Low to moderate |
| Vessel and route | Is the vessel restricted, and does the voyage suggest diversion | Low to moderate |
| Financial flow | Are the payment parties and correspondents permitted | High |

### Why is goods classification the weakest dimension?

Because a description on an invoice is not a classification, and classification requires technical judgment.

Export control regimes classify items by technical characteristics, so whether a component is controlled depends on specifications an invoice line does not carry. The US Bureau of Industry and Security, part of the Department of Commerce, administers the Export Administration Regulations and provides classification of items under Export Control Classification Numbers, alongside a Consolidated Screening List for denied and restricted parties and country groupings that affect what may go where. A bank reading "industrial valves, 40 units" cannot determine from that line whether the item falls within a controlled category, which is why classification support rather than classification automation is the realistic goal.

> **Does your trade screening address goods and destination, or only the parties and the payment?**
>
> [Talk to Digiqt about trade screening coverage assessment](https://digiqt.com/contact-us/)

## How does party screening differ here?

More parties, more roles, and the evidence sits in documents.

A single trade transaction may involve an applicant, a beneficiary, an intermediary bank, a freight forwarder, a carrier, a notify party, an inspection agency, an insurer, and beneficial owners behind several of those. Each is a screening subject, each appears in documents rather than in structured fields, and the roles matter because a restricted party as a notify party carries different implications from a restricted party as a beneficiary. Extract parties with their roles, screen each, and retain the document location where each was found, since an adjudicator's first question is where the name appeared. Document extraction is the enabling capability, described in [financial document intelligence pipelines](https://digiqt.com/blog/financial-document-intelligence-pipeline/).

## How do you handle dual-use goods?

With classification support, red flag detection, and escalation to people who can decide.

Realistic automation does three things. It flags descriptions resembling controlled categories using terminology and specification patterns. It detects red flags in the transaction as a whole: a mismatch between the stated end use and the buyer's business, unusual quantities for the stated purpose, a destination inconsistent with the goods, a buyer with no evident use for the item, or reluctance to provide end-use information. And it assembles the evidence so a specialist can decide quickly. What it should not do is conclude that an item is not controlled, since a false negative there is the failure that matters.

### What should the platform ask the customer?

End use, end user, and specification detail, proportionate to risk.

Where goods may be controlled, the answer usually depends on information only the customer holds. Build the request into the workflow with structured capture rather than free-text email, escalate where answers are evasive or inconsistent, and record what was asked and what was provided. That record is both the basis for the decision and the evidence that due diligence occurred, which is what an examination will look for.

## How does vessel screening work?

Through vessel identity, ownership, flag, restriction status, and voyage behaviour.

| Check | Purpose | Limitation |
|---|---|---|
| Vessel identity and registration | Confirm the named vessel exists as described | Names change, identifiers are reused |
| Ownership and management | Identify restricted ownership or control | Layered ownership obscures control |
| Flag and registry | Assess jurisdiction and registry quality | Reflagging is common and legitimate |
| Restriction status | Vessel-level designations | Lists change frequently |
| Position and voyage history | Consistency with the stated route | Coverage and reporting gaps |
| Transponder continuity | Detect periods without position reporting | Gaps have innocent explanations |
| Ship-to-ship activity | Detect transfers that obscure cargo origin | Inference rather than observation |
| Port call history | Detect calls at unexpected jurisdictions | Data quality varies by region |

### Why are transponder gaps a signal rather than a conclusion?

Because equipment fails, coverage varies, and there are legitimate reasons for interruption.

A gap in position reporting during a voyage that otherwise makes sense is weak evidence. A gap coinciding with a plausible opportunity to call at a restricted jurisdiction, on a vessel with opaque ownership, carrying goods that would be controlled for that destination, is a strong pattern. The engineering lesson is that vessel signals should feed a combined assessment rather than trigger individual alerts, because gap-based alerting alone produces volume without insight. Network analysis across vessels, owners, and counterparties is where the pattern becomes visible, which is the approach described in [using graph databases to uncover networks](https://digiqt.com/blog/graph-database-systemic-risk-analysis/).

## How do you handle transshipment and diversion risk?

By screening the route and the intermediaries rather than only the endpoints.

Diversion works by routing goods through a permitted intermediate destination before onward movement, which means a transaction can look compliant at every documented step. Look for the patterns: a destination with no apparent demand for the goods, an intermediary with no evident role, routing that makes no commercial sense, quantities inconsistent with the stated market, and repeated shipments to the same intermediate party. Then treat those as questions for the customer rather than conclusions, and record the answers. The documentation complexity that makes this hard across jurisdictions is described in [documentation at the border](https://digiqt.com/blog/digital-trade-documents-mletr/).

> **Does your screening flag routing that makes no commercial sense, or only listed parties?**
>
> [Talk to Digiqt about route and intermediary risk detection](https://digiqt.com/contact-us/)

## How should the architecture work?

Seven components, with case management carrying the operational value.

| Component | Responsibility |
|---|---|
| Document ingestion and extraction | Structured data and party roles from trade documents |
| Party screening | Matching against current lists with role context |
| Goods classification support | Category flags, specification prompts, red flag detection |
| Destination and end-use assessment | Country group rules, stated use consistency checks |
| Vessel and route analysis | Identity, ownership, restriction status, voyage behaviour |
| Combined risk scoring | Signals assembled into a case-level assessment |
| Case management | Evidence presentation, decision capture, escalation, audit |

### Why is case management the real product?

Because screening produces alerts and people make determinations.

The quality of adjudication decides whether the control works and what it costs. Present the adjudicator with everything in one place: the transaction, the parties with roles and where each appeared, the goods with classification prompts, the route with anomalies highlighted, the vessel picture, and prior decisions on similar cases. Capture the decision with its reasoning, route escalations by defined criteria, and measure clearance time. A screening engine with excellent detection and a poor case interface produces a backlog, and a backlog is a control that is not operating.

### How do you control false positives without weakening the control?

By tuning matching, using context, and improving evidence rather than raising thresholds.

Raising a matching threshold reduces alert volume and increases the chance of missing a genuine hit, which is the wrong trade in this domain. Better levers are name matching that accounts for transliteration and common variants, contextual suppression where corroborating data distinguishes a common name, deduplication across documents so one party generates one alert, and better evidence presentation so a clear case clears in seconds rather than minutes. Measure both the alert rate and the time per alert, since the second is where most of the cost sits. The distinction between screening and clearing what it produces is the same one in sanctions screening and unpayable claims.

## How should AI be used here?

To extract, match, rank, and surface evidence, with a human deciding and the reasoning recorded.

The useful applications are document extraction, entity and role identification, matching with variant handling, red flag detection across combined signals, and ranking cases so specialists see the most consequential first. The application to avoid is a system that concludes an item is not controlled or a party is not a match, since the consequence of that error is a sanctions or export control breach rather than a service failure. Govern it accordingly: register the models, use a recognised framework such as the NIST AI Risk Management Framework 1.0 with its 2024 Generative AI Profile, keep the human determination explicit, and retain the reasoning. Where intelligence can lawfully be shared across institutions, the mechanics resemble [federated fraud intelligence sharing](https://digiqt.com/blog/federated-fraud-data-sharing/).

## How do you evidence decisions?

With a complete record of what was screened, what was found, what was asked, and why the decision was made.

Retain the documents as received, the extracted data with provenance, the lists and versions screened against, every alert with its disposition and rationale, the questions put to the customer and the answers, the escalation path taken, and the final decision with the decision maker. That record is the entire basis of your position if a transaction is later questioned, and reconstructing it after the fact is not possible. Where digital trade documents are involved, the control and integrity properties of those records matter too, which is covered in [digitising trade documents under MLETR](https://digiqt.com/blog/digital-trade-documents-mletr/).

## How should delivery be sequenced?

Extraction and party screening first, then vessel and route, then goods support, then combined scoring.

| Phase | Duration | Deliverable |
|---|---|---|
| Document extraction and party roles | 3 to 4 months | Structured parties with roles and document provenance |
| Party screening with role context | 2 to 3 months | Matching, deduplication, contextual suppression |
| Case management | 2 to 3 months | Evidence presentation, decision capture, escalation, audit |
| Vessel and route analysis | 3 to 4 months | Identity, ownership, restriction status, voyage anomalies |
| Goods classification support | 3 to 4 months | Category flags, specification capture, red flag rules |
| End-use diligence workflow | 2 months | Structured questions, escalation, recorded answers |
| Combined risk scoring | 2 to 3 months | Case-level assessment across all dimensions |

Case management early rather than late, because the first three phases will generate alerts and an alert without a good adjudication path becomes a backlog that discredits the programme.

## Which metrics matter?

Coverage by dimension, alert rate and clearance time, escalation outcomes, evidence completeness, and detections that changed a decision.

Report coverage by screening dimension rather than as one figure, since the gaps in goods and route screening are the ones that matter. Track alert rate and time per alert separately, because they respond to different fixes. Report escalation volume and outcomes, including transactions declined or restructured, which is the control demonstrably working. Measure evidence completeness on closed cases, since an incomplete record is a future problem. And count detections that changed a decision rather than alerts raised, because that number is the value of the system and it is usually small, which is exactly why the case handling has to be efficient.

Trade compliance screening is where a bank's exposure is broadest and its expertise is thinnest, since it involves judgments about goods, routes, and vessels rather than about payments. The systems that work automate extraction, matching, and evidence assembly, present a case a specialist can decide in minutes, and never let the automation conclude that something is permitted.

## Frequently Asked Questions

### What does trade compliance screening cover?

Five dimensions: the parties involved, the goods themselves, the destination and end use, the vessel and route, and the financial flow. Most banks screen the first and fifth well.

### Why is goods classification the weakest dimension?

Because a description on an invoice is not a classification, and determining whether an item is controlled requires technical judgment banks are not staffed to make at scale.

### How does this differ from payment sanctions screening?

There are more parties in more roles, the goods matter, the route matters, and the evidence sits in documents rather than in a structured payment message.

### What can automation realistically do for classification?

Narrow the field. It can flag descriptions resembling controlled categories and surface red flags for review, and it should not conclude that an item is or is not controlled.

### Why are AIS gaps a signal rather than a conclusion?

Because transponders fail, coverage varies, and legitimate reasons exist. A gap raises a question about the voyage, and the answer requires corroborating evidence.

### What is transshipment risk?

Goods routed through an intermediate jurisdiction to obscure their final destination, which is why routing anomalies and unusual intermediaries deserve their own screening logic.

### Why is case management the real product?

Because screening produces alerts and decisions get made by people. The quality and speed of adjudication determines both the control's effectiveness and its operational cost.

### How should AI be used in this domain?

To assist rather than decide: extract, match, rank, and surface evidence, with a human making the determination and the reasoning recorded.

## Sources

- [US Bureau of Industry and Security, Department of Commerce](https://www.bis.gov/)
- [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework)

Trade Compliance Screening for Dual-Use Goods and Vessels

Let Digiqt design registry verification, cross-document consistency checks, and duplicate financing detection for trade finance.

Verify The Trade, Not Just The Paperwork

# Verifying That the Shipment, the Vessel, and the Warehouse Are Real

Trade finance fraud persists for a structural reason. The bank examines documents against the terms of a credit, and the examination standard is explicitly about whether documents appear on their face to conform, not about whether the goods exist, the vessel sailed, or the warehouse holds anything. A competent forgery that conforms will pass, and a genuine shipment financed simultaneously by four banks will pass all four times.

That is why trade finance document fraud detection has to look outward and sideways rather than harder at the document itself: outward to registries and external sources that can confirm the trade happened, and sideways across documents and across institutions to find contradictions a forger could not eliminate.

## What does the fraud actually look like?

Seven patterns, most of which involve real-looking documents.

| Pattern | Mechanism | Detection angle |
|---|---|---|
| Forged or altered documents | Fabricated or modified originals | Forensics, registry verification |
| Duplicate financing | One shipment financed by several banks | Shared data, electronic records |
| Fictitious trade | No underlying goods, often between related parties | Counterparty network analysis |
| Phantom shipment | Documents for a voyage that did not occur | Vessel and voyage verification |
| Inflated invoicing | Real goods, overstated value | Price benchmarking, quantity plausibility |
| Circular trade | Goods moved between related parties to generate paper | Network and repetition analysis |
| Warehouse receipt fraud | Receipts for goods not held or pledged twice | Operator confirmation, independent inspection |

### Why can the same shipment be financed several times?

Because each bank sees only its own presentation and nothing reveals the others.

A single genuine cargo can support presentations to multiple financiers, each of whom examines a conforming set of documents and finds nothing wrong, because the defect is not in the documents but in the fact of duplication. No amount of internal diligence detects it. That makes duplicate financing the clearest example of a fraud that only shared visibility or a fundamentally different document model can address.

> **Could your bank detect that a shipment you financed was also financed by another institution?**
>
> [Talk to Digiqt about duplicate financing detection](https://digiqt.com/contact-us/)

## Why does document examination not catch fraud?

Because conformity and authenticity are different questions, and examination addresses the first by design.

The examination standard is deliberate rather than negligent: banks are not equipped to verify the underlying commercial reality of every transaction, and the rules acknowledge that by limiting examination to the face of the documents. The consequence is that fraud detection must be a separate capability operating alongside examination rather than an enhancement of it. Treating them as one activity is how banks end up believing their examination process is a fraud control.

## What can be verified against external sources?

More than most institutions attempt, and several checks are cheap.

| Check | Verifies | Cost and yield |
|---|---|---|
| Company registry existence and status | Counterparties are real and active | Low cost, high yield |
| Vessel identity and particulars | The named vessel exists as described | Low cost, high yield |
| Voyage plausibility | The route and timing are consistent | Moderate cost, high yield |
| Container or booking reference | The shipment was booked with the carrier | Low to moderate, very high yield |
| Carrier confirmation of the bill of lading | The carrier issued this document | Moderate, decisive when available |
| Warehouse operator confirmation | Goods are held and not double-pledged | Moderate, essential for receipt finance |
| Certification body verification | Certificates were genuinely issued | Moderate, varies by body |
| Customs or port data where accessible | Movement actually occurred | Varies widely by jurisdiction |

### Which checks give the best return?

Existence checks and booking confirmation, because they eliminate whole classes of fabrication cheaply.

Confirming that the counterparty exists, that the vessel exists, and that a booking reference matches a real shipment with the carrier removes the crudest and surprisingly common frauds at very low cost. Carrier confirmation of a bill of lading is the strongest single check available and is not always obtainable, which is why it should be triggered by risk rather than applied universally. Build the cheap checks into every transaction and reserve the expensive ones for elevated risk, and record which checks were performed so the diligence is evidenced.

### What cannot be verified, and how should that be handled?

Quality, quantity as loaded, and much of the commercial substance, which is why risk-based inspection exists.

No registry confirms that a container holds what the packing list says. That gap is addressed through inspection agencies, through knowing the customer and their trade, and through pattern analysis rather than through document checking. Be explicit internally about what your controls cannot see, because a control framework that implies verification of goods it never inspects creates false comfort.

## How does AI help, and where is it weak?

It is strong on extraction, consistency, and pattern detection, and weak as a judge of authenticity.

Document forensics can detect signs of alteration, inconsistent fonts and metadata, template reuse across supposedly unrelated parties, and reused images. Extraction plus cross-document comparison catches contradictions. Network analysis finds relationships between parties that should be unconnected. What automation cannot reliably do is declare a document genuine, and treating a model's confidence as authenticity is how a well-produced forgery passes with an audit trail saying it was checked. The forensic review approach and its limits are covered in this guide to document forensic review, and the wider forgery problem in document forgery detection.

### Why does cross-document consistency beat single-document analysis?

Because a competent forgery is internally consistent and a set of forgeries rarely is.

A fraudster producing a bill of lading can make it look right. Producing a bill of lading, invoice, packing list, insurance certificate, and certificate of origin that agree with each other on vessel, voyage, dates, quantities, weights, marks, and party details, and that also agree with the credit terms and with external sources, is considerably harder. Extract every document into a common model and compare systematically: dates that must be ordered, weights that must reconcile with quantities and container capacity, vessel and voyage that must match across documents, and party names that must be identical rather than similar. That comparison is mechanical, cheap, and catches a great deal.

### How does generative capability change the picture?

It makes convincing documents cheaper, which shifts detection toward verification and consistency.

If producing a plausible document requires little skill, then appearance-based detection weakens and external verification and cross-document consistency become the load-bearing controls. That is a useful reframing for investment: money spent on registry and carrier verification integrations ages better than money spent on visual forgery detection. Govern the models you do use under a recognised framework such as the NIST AI Risk Management Framework 1.0 with its 2024 Generative AI Profile, and keep the determination with a human.

## What actually solves duplicate financing?

Shared visibility across financiers, or electronic records whose control sits in one place.

Internal deduplication catches only your own duplicates. Industry data sharing, where a financier can check whether an instrument or shipment has been financed elsewhere, is the direct answer and requires governance, privacy handling, and reciprocity. The evidence that collaborative approaches work is encouraging: the BIS Innovation Hub's Project Aurora found that privacy-enhancing technologies combined with network analysis across institutions detected potentially up to three times more complex schemes while reducing false positives by up to eighty percent compared with siloed rules-based approaches. The mechanics of building that kind of sharing are covered in [federated fraud intelligence sharing](https://digiqt.com/blog/federated-fraud-data-sharing/), and network detection within your own data in [using graph databases to uncover fraud networks](https://digiqt.com/blog/graph-database-systemic-risk-analysis/).

> **Is duplicate financing addressed by internal deduplication alone?**
>
> [Talk to Digiqt about shared visibility and network detection design](https://digiqt.com/contact-us/)

## Why are electronic transferable records a fraud control?

Because singularity of control removes the ability to present the same original to several banks.

The UNCITRAL Model Law on Electronic Transferable Records, adopted in 2017, replaces possession with control, requiring a reliable method that establishes exclusive control of the record by an identified person, with functional equivalence resting on identification, capability of control, and maintaining integrity. Applied to a bill of lading, that means one party controls the record at a time and transfer moves control rather than copying it. That property attacks duplicate financing at its root rather than detecting it afterwards, which is a stronger control than any analytics. The implementation considerations are covered in [digitising trade documents under MLETR](https://digiqt.com/blog/digital-trade-documents-mletr/).

## How should the detection architecture work?

Ingest, extract, verify externally, cross-check internally, score at case level, and adjudicate.

| Component | Responsibility |
|---|---|
| Ingestion | Documents in whatever form they arrive, with originals retained |
| Extraction | Structured data per document with provenance to page and location |
| External verification | Registry, vessel, booking, carrier, warehouse, certificate checks |
| Cross-document consistency | Systematic comparison across the presentation and the credit |
| Network analysis | Relationships between parties, vessels, and prior transactions |
| Case scoring | Combined assessment rather than per-document flags |
| Adjudication | Evidence presentation, decision, escalation, recorded rationale |

### Why score at case level rather than flagging documents?

Because individual anomalies are weak evidence and combinations are strong.

A slightly unusual date, a vessel with a common name, and a counterparty registered recently are each unremarkable. Together, on a transaction with an unusual route and a first-time counterparty, they form a pattern. Score the case, present the contributing signals with their evidence, and let the adjudicator see the combination. Document-level flagging produces volume and trains reviewers to dismiss, which is the same dynamic that undermines screening alerts, as discussed in [trade compliance screening](https://digiqt.com/blog/trade-compliance-screening-system/).

## How do you handle suspicion that is not proof?

With graduated responses, documented reasoning, and a route to relationship-level action.

Most detections produce suspicion rather than certainty. Define graduated responses: request additional evidence, require carrier or warehouse confirmation, reduce or decline the specific transaction, apply enhanced diligence to future transactions, or exit the relationship. Record the reasoning at each step, because a decision to continue is as much a decision as a decision to decline and will be examined with hindsight. Then handle the internal politics honestly, since a relationship manager whose client is being questioned will push back and the framework needs to be robust enough to withstand that without being arbitrary.

## How should delivery be sequenced?

Extraction and consistency first, then cheap external checks, then network analysis, then sharing.

| Phase | Duration | Deliverable |
|---|---|---|
| Extraction into a common model | 3 to 4 months | Structured documents with provenance |
| Cross-document consistency engine | 2 to 3 months | Systematic comparison rules with evidence output |
| Low-cost external verification | 2 to 3 months | Registry, vessel identity, booking reference checks |
| Case scoring and adjudication | 2 to 3 months | Combined scoring, evidence presentation, recorded decisions |
| Elevated verification workflow | 2 months | Carrier, warehouse, certificate confirmation on triggers |
| Network analysis | 3 to 4 months | Party, vessel, and transaction relationship detection |
| Shared visibility | Per programme | Industry data participation or electronic record adoption |

Cross-document consistency before external verification, because it is cheap, entirely within your control, and catches a meaningful share of fabrication with no third-party dependency. Where invoice-based financing is involved, the verification discipline overlaps with [invoice financing platform design](https://digiqt.com/blog/invoice-financing-platform/).

## Which metrics matter?

Verification coverage, consistency failures, detections before funding, false positive burden, and duplicate financing found.

Report verification coverage by check type, since a control not performed is not a control. Track cross-document consistency failures and their outcomes, as the ratio of genuine issues to data quality noise tells you where to tune. Measure detections before funding versus after, because the first is prevention and the second is loss recovery. Report the false positive burden in reviewer time, not just in counts. Count duplicate financing cases identified, particularly any found through shared data, since that number justifies participation. And track adjudication time and evidence completeness, because a suspicion recorded without reasoning is worse than no detection when it is examined later.

Trade finance fraud will not be solved by examining documents more carefully, because examination was never designed to establish truth. It is addressed by verifying the trade against sources outside the documents, by comparing documents against each other systematically, and ultimately by document models where the same original cannot be presented twice.

## Frequently Asked Questions

### Why does letter of credit examination not catch fraud?

Because examination checks whether documents conform to the credit's terms on their face, not whether the underlying trade happened. Conformity and authenticity are different questions.

### What are the main fraud patterns?

Forged or altered documents, duplicate financing of one shipment, fictitious trade between related parties, phantom shipments, inflated invoices, and warehouse receipt fraud.

### Why can the same shipment be financed several times?

Because each bank sees only its own presentation, and without shared data there is nothing to reveal that another institution financed the same underlying goods.

### Which verification checks are cheapest and most useful?

Company registry existence checks, vessel identity and voyage plausibility, and container or booking confirmation. Each is inexpensive and eliminates whole classes of fabrication.

### Why does cross-document consistency beat single-document analysis?

Because a competent forgery looks correct in isolation. Contradictions between invoice, bill of lading, packing list, and certificate are far harder for a fraudster to eliminate.

### How does generative technology change forgery detection?

It raises the bar. Convincing documents are cheaper to produce, so detection shifts from appearance toward verification against external sources and internal consistency.

### What actually solves duplicate financing?

Shared visibility across financiers, whether through industry data sharing or through electronic records whose control can sit in only one place at a time.

### Why are electronic transferable records a fraud control?

Because singularity of control means one party holds the document at a time, which removes the ability to present the same original to several banks.

## Sources

- [UNCITRAL Model Law on Electronic Transferable Records (2017)](https://uncitral.un.org/en/texts/ecommerce/modellaw/electronic_transferable_records)
- [BIS Innovation Hub, Project Aurora](https://www.bis.org/about/bisih/topics/fmis/aurora.htm)
- [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework)

Trade Finance Document Fraud Detection With Registry Checks

Let Digiqt design counterparty discovery, data exchange, and missing-information procedures for travel rule compliance.

Make The Data Travel Reliably

# Making Sure the Data Travels With the Transfer

The travel rule sounds like a messaging problem and is really a counterparty problem. Sending originator and beneficiary information alongside a transfer is straightforward once you know who the counterparty is, which protocol they use, and whether they will accept the data. None of those three is discoverable from a ledger address, and all three vary by jurisdiction, provider, and sometimes by transaction.

That is why travel rule compliance VASP programmes spend most of their effort on discovery, exception handling, and policy rather than on the message format. The rule is clear. The environment it operates in is not.

## What does the rule actually require?

That required information accompanies transfers, that missing information is detected, and that procedures exist to handle it.

The EBA's Guidelines on information requirements in relation to transfers of funds and certain crypto-assets transfers under Regulation (EU) 2023/1113, applicable from 30 December 2024 with a compliance deadline of 27 November 2024, specify what payment service providers, crypto-asset service providers, and their intermediaries should do. The guidelines instruct providers to detect missing or incomplete information accompanying a transfer and to establish procedures to manage a transfer that lacks the required information. The specific data elements and thresholds sit in the guidelines themselves, so confirm the current detail with your compliance function per jurisdiction rather than relying on a summary.

### Why is detection the operative obligation?

Because you control what you send and not what arrives.

Sending information is an engineering task with a known answer. Receiving it is not, since the counterparty may use a different protocol, may send partial data, may send nothing, or may not be a regulated provider at all. The obligation therefore lands on your ability to notice the gap and act on it consistently, which makes the detection and exception path the core of the build rather than a fallback.

> **Can your platform tell you today how many inbound transfers arrived without complete information?**
>
> [Talk to Digiqt about travel rule detection and exception design](https://digiqt.com/contact-us/)

## What makes this harder than payment messaging?

No shared rail, no directory, ambiguous counterparties, and personal data crossing borders.

| Difficulty | Why it bites |
|---|---|
| No universal messaging rail | Several competing protocols, none universal |
| No authoritative provider directory | Determining who controls an address is inference, not lookup |
| Jurisdictional asymmetry | Your obligation exists where the counterparty's may not |
| Unhosted wallets | No counterparty provider to exchange data with |
| Address reuse and attribution | An address may serve many customers or none |
| Irreversibility | A transfer sent cannot be recalled if data is refused |
| Data protection | Transmitting identifying data to third parties across borders |
| Screening timing | Lists change continuously, transfers settle in minutes |

### Why is counterparty identification the core unsolved problem?

Because a ledger address carries no information about who controls it.

Determining whether a destination belongs to a regulated provider, and if so which one and how to reach them, is inference from attribution data, provider directories of varying completeness, and analytics. That inference can be wrong in both directions: treating a provider address as unhosted means failing to send required information, and treating an unhosted address as a provider means expecting an exchange that never happens. Build the attribution capability deliberately, record the basis of each determination, and monitor accuracy, because this is the input every downstream decision depends on.

### What is the sunrise issue?

Counterparties whose jurisdictions have not implemented the rule, or implemented it differently.

Your obligation applies regardless of whether the receiving provider has an equivalent one, which produces transfers where you must send information the counterparty cannot receive or will not acknowledge. Policy has to state what you do in that case: proceed with records, apply enhanced monitoring, restrict transfer types, or decline. Make it a written risk-based position approved by compliance rather than a decision made per transaction by an operations analyst, because consistency is what an examiner will test.

## What does the architecture look like?

Seven components, with discovery and exception handling doing most of the work.

| Component | Responsibility |
|---|---|
| Transfer initiation | Capture required data before the transfer is submitted |
| Counterparty discovery | Determine destination type and provider, with recorded basis |
| Data exchange | Send and receive required information over supported protocols |
| Validation | Check completeness and plausibility of received data |
| Screening | Screen parties and addresses against current lists |
| Decision and routing | Proceed, hold, request, reject, or return per policy |
| Records and reporting | Retain what was sent, received, decided, and why |

### Where should the exchange happen relative to the transfer?

Before settlement wherever possible, because a settled transfer cannot be undone.

If you send the asset and then discover the counterparty will not accept or provide the required data, you have an irreversible transfer and a compliance gap with no remedy. Exchange first, confirm the counterparty is willing and able, then transfer. That sequencing costs latency and occasionally loses a transaction, and it is the only order that keeps the control meaningful. Where operational reality forces post-transfer exchange for some flows, document the risk acceptance explicitly and monitor those flows separately.

## How should unhosted wallets be handled?

Risk-based, with verification of customer control where required and honest limits on what can be verified.

Transfers to and from wallets not held by a provider have no counterparty to exchange data with, so the obligation shifts toward verifying that your customer controls the wallet where that is required, applying checks proportionate to risk, and keeping records of what was verified and how. Be realistic about the limits: proving control is possible through signing or micro-transaction methods, and proving who is behind an address is generally not. Set thresholds and enhanced measures by risk rather than treating all such transfers identically, and record the rationale so the approach is defensible as a policy rather than as a series of judgments.

> **Is your unhosted wallet approach a written risk-based policy or a set of case-by-case decisions?**
>
> [Talk to Digiqt about unhosted wallet policy and verification](https://digiqt.com/contact-us/)

## How do you handle missing or incomplete information?

With a written policy applied consistently, and escalation for the cases it does not cover.

| Situation | Typical response |
|---|---|
| Inbound transfer with no information | Hold pending request, per policy and risk |
| Inbound with partial information | Request the missing elements, decide on response |
| Counterparty refuses to provide | Decline future transfers, consider restricting the relationship |
| Repeated deficiencies from one counterparty | Relationship-level action rather than per-transaction |
| Outbound where counterparty cannot receive | Policy decision, recorded, with monitoring |
| Screening hit on either party | Freeze and escalate rather than proceed |

The requirement is consistency. Two analysts facing the same facts should reach the same decision, which means the policy has to be specific enough to apply and the platform has to record which rule drove each outcome. Relationship-level action deserves emphasis: a counterparty that repeatedly sends incomplete data is a relationship problem rather than a queue of individual exceptions, and treating it transaction by transaction guarantees the problem persists.

## How does screening fit?

Screen both parties and the addresses, against current lists, at the moment of transfer.

Names, addresses, and where available additional identifiers all need screening, and the lists change continuously, so screening at onboarding is insufficient for transfers occurring later. Index lists locally for speed, screen at transfer, and route hits to a staffed queue with a clearance target, since a transfer held indefinitely is its own failure. Address-level screening and on-chain analytics add a dimension conventional payment screening lacks, and both produce false positives that need an adjudication process rather than automatic blocking. The distinction between screening in the window and clearing what it produces is the same one described in this guide to [sanctions screening and unpayable claims](https://digiqt.com/blog/trade-compliance-screening-system/).

## What data protection constraints apply?

Transmission of personal data to third parties, frequently across borders, with minimisation obligations.

The travel rule requires sending identifying information about your customer to another provider, which is a disclosure of personal data and often a cross-border transfer. That creates obligations that sit awkwardly alongside the compliance obligation: send what is required and no more, ensure a lawful basis and transfer mechanism, inform customers that their data will be shared, retain only as long as needed, and protect the data in transit and at rest. Over-disclosure is a real risk, since sending extra fields feels safer from an AML perspective and is a breach exposure from a privacy perspective. The multi-jurisdiction dimension is covered in this guide to [privacy compliance across jurisdictions](https://digiqt.com/blog/privacy-enhancing-technologies-finance/), and the identity data foundations in [digital onboarding and KYC automation](https://digiqt.com/blog/digital-account-opening-platform/).

## How do you handle protocol interoperability?

By supporting more than one and abstracting the difference internally.

Several protocols exist for exchanging this information and no single one has universal adoption, so a platform serving a wide counterparty base will support several. Abstract them: one internal representation of a transfer's required information, with adapters per protocol handling format, transport, and acknowledgement semantics. That keeps protocol change contained and lets you add a counterparty's preferred mechanism without touching the core, which is the same adapter discipline that governs payment rail integration. Then monitor per-protocol success rates, because they differ and the differences tell you where to invest.

## How should delivery be sequenced?

Policy first, then outbound, then discovery, then inbound handling, then relationship management.

| Phase | Duration | Deliverable |
|---|---|---|
| Policy and risk framework | 1 to 2 months | Written positions on sunrise, unhosted wallets, missing data, thresholds |
| Outbound information capture and send | 2 to 3 months | Required data captured, sent over at least one protocol |
| Counterparty discovery | 2 to 3 months | Attribution capability with recorded basis and accuracy monitoring |
| Inbound validation and exception handling | 2 to 3 months | Detection, hold, request, decision, records |
| Screening integration | 1 to 2 months | Party and address screening at transfer with adjudication queue |
| Protocol abstraction | 2 months | Multiple protocols behind one internal model |
| Counterparty relationship management | Ongoing | Scorecards, escalation, restriction decisions |

Policy before engineering is the sequencing that matters, because the platform enforces whatever the policy says and building first produces a system that encodes decisions nobody approved. Where transfers involve bank-issued tokens, the controls interact with the design in [tokenised deposits and stablecoin infrastructure](https://digiqt.com/blog/tokenized-deposits-stablecoin-infrastructure/), and the FSB's stablecoin recommendations expect comprehensive risk management including anti-money laundering and counter-terrorist financing measures as part of the arrangement.

## Which metrics matter?

Outbound completeness, inbound completeness by counterparty, discovery accuracy, exception clearance time, and screening performance.

Report outbound completeness, meaning transfers sent with all required information, which should be effectively total. Track inbound completeness by counterparty, since that scorecard is what drives relationship decisions. Measure discovery accuracy, including cases where a destination was misclassified, because that error propagates into every downstream control. Report exception clearance time and volume by category, with ageing, as held transfers are customer-affecting. Track screening hit rates and adjudication time separately from screening latency. And measure protocol success rates per counterparty, which reveals where technical integration rather than policy is the blocker. Where intelligence about counterparties can be shared lawfully between institutions, the mechanics resemble those in [federated fraud intelligence sharing](https://digiqt.com/blog/federated-fraud-data-sharing/).

The travel rule is unusual in that the messaging is the simple part and the environment is the hard part. A platform that discovers counterparties reliably, exchanges data before settlement, applies a written policy consistently to missing information, and sends no more personal data than required will satisfy the obligation. One built around a single protocol and an optimistic assumption about counterparties will spend its life in exception handling.

## Frequently Asked Questions

### What does the travel rule require?

That required originator and beneficiary information accompanies a transfer, that missing or incomplete information is detected, and that procedures exist to manage transfers lacking it.

### Why is detection the operative obligation?

Because you control your own outbound data and not what arrives. The EBA guidelines focus on detecting missing or incomplete information and having procedures to handle it.

### What is the sunrise issue?

Counterparties in jurisdictions where the rule is not yet in force, or not enforced the same way, so your obligations exist while theirs may not. Policy has to cover that asymmetry.

### Why is counterparty identification the hard problem?

Because a ledger address does not announce which provider controls it, so you must determine whether the destination is a regulated provider, an unhosted wallet, or something else.

### How should unhosted wallets be handled?

With a risk-based approach: verification of customer control where required, additional checks proportionate to risk, and records of what was verified and how.

### What should happen when information is missing?

Follow a written policy: hold, request, reject, or return, decided by risk rather than case by case, with escalation and a recorded rationale for every decision.

### Why is sending more data than required a risk?

Because you are transmitting personal data to a third party, often across borders. Over-disclosure is a data protection issue even when it feels safer for compliance.

### Where should the information exchange happen?

Before the transfer settles wherever possible, since an irreversible transfer to a counterparty who then refuses the data leaves no remedy.

## Sources

- [EBA, Guidelines on information requirements for transfers of funds and certain crypto-assets transfers](https://www.eba.europa.eu/activities/single-rulebook/regulatory-activities/anti-money-laundering-and-countering-financing-terrorism/guidelines-information-requirements-relation-transfers-funds-and-certain-crypto-assets-transfers)
- [FSB, High-level Recommendations for the Regulation, Supervision and Oversight of Global Stablecoin Arrangements](https://www.fsb.org/2023/07/high-level-recommendations-for-the-regulation-supervision-and-oversight-of-global-stablecoin-arrangements-final-report/)

Posts tagged with#Compliance

Audit-Ready CI/CD Evidence Trails Financial Regulators Accept

Trade Compliance Screening for Dual-Use Goods and Vessels

Trade Finance Document Fraud Detection With Registry Checks

Travel Rule Compliance Architecture for Virtual Asset Transfers

Our Offices