CrossBorder Settlement Intelligence

AI-assisted cross-border settlement that converts payment requests into structured intent, combines financial and external intelligence, and produces evidence-backed settlement recommendations.

Comment

CrossBorder Settlement Intelligence

An AI-first Value Transfer Engine

Tell us where value needs to go. VTE investigates how it could get there.

CrossBorder Settlement Intelligence explores a different approach to cross-border payments: instead of starting with a predetermined bank, provider, or payment network, start with the transfer requirement and investigate which mechanisms might satisfy it.

The project is an experimental implementation of an AI-first Value Transfer Engine (VTE). It combines AI-driven route discovery, financial and regulatory intelligence, evidence investigation, and eligibility assessment to explore possible ways of moving value across fragmented financial systems.

The ambition is to make value transfer less dependent on a single assumed route while preserving the distinction between what AI suggests, what evidence supports, and what can actually be used.

Inspiration

The idea behind VTE began with a real-world experience: I found that I could not use my Visa card while visiting a country affected by SWIFT-related sanctions.

That experience raised a question:

Should the ability to exchange value depend entirely on the networks and intermediaries available in a particular geopolitical situation?

It led me to explore a different approach. Rather than assuming that a particular bank, payment network, or provider is the only possible path, could an intelligent system discover and evaluate alternative ways for two parties to exchange value?

That question became the starting point for VTE.

The goal is not simply to build another cross-border payment application. It is to investigate how value might move across otherwise disconnected systems, reducing dependence on a single provider or network while respecting applicable legal and regulatory requirements.

Start with the need, not the route.

What it does

A user or business expresses a value-transfer requirement in natural language. The system represents that requirement as a structured payment intent and uses AI to discover candidate mechanisms for further investigation.

The core architecture is:

User / Business → AI Payment Agent → Payment Intent → Intelligence → AI Route Discovery → Evidence Investigation → Eligibility Assessment → Route Selection / Recommendation

The engine does not assume that a particular payment rail is the correct answer. Depending on the corridor and requirements, candidate mechanisms might involve banking services, fintech providers, local payment systems, mobile money, cards, digital assets, or other value-transfer arrangements.

These are possibilities to investigate—not a declaration that every mechanism exists, is available, or is legally usable for a particular transfer.

The prototype focuses on discovering and evaluating candidate routes. Full end-to-end execution and independent confirmation of real beneficiary receipt remain separate integration milestones.

How we built it

We separated the architecture into two major concerns: intelligence and decision-making.

1. Intelligence: What do we know?

The Intelligence Layer gathers, organizes, and preserves information relevant to a transfer. The architecture accommodates several evidence domains:

  • Financial and market intelligence
  • Payment and settlement networks
  • Route and provider information
  • Blockchain and on-chain intelligence
  • Regulatory and compliance evidence
  • Fraud and counterparty-risk signals
  • External intelligence tools and data sources

The purpose is to give the decision process a more useful picture of the transfer environment, including missing information and uncertainty.

2. Decision architecture: What can we do with that information?

AI first discovers candidate value-transfer mechanisms. The candidates are then investigated and evaluated against available evidence and the requirements of the transfer.

The intended process is:

Discover → Investigate → Validate → Determine Eligibility → Select / Recommend

This separation matters. A model can suggest a plausible mechanism without proving that it exists. Structural validation can confirm that a record follows the expected contract without proving that its route is operational. Eligibility must remain distinct from discovery.

Regulatory and compliance assessment is designed around applicable evidence and AI-assisted investigation, rather than assuming that a fixed set of hard-coded route choices covers every situation.

The result is an architecture in which AI expands the search space, evidence makes assumptions inspectable, and downstream decision logic determines what conclusions the available information supports.

Route Discovery Experiments

A major part of the project has been investigating whether different AI models can discover diverse candidate value-transfer mechanisms across a broad set of cross-border corridors.

The evaluation uses a 21-country BRICS-member and partner-country universe, producing 420 directed corridors. Experiments record model responses, execution status, candidate route objects, route attributes, and constraint-related evidence.

We have evaluated multiple local and hosted models and preserved the resulting data so their behavior can be compared rather than hidden behind a single demonstration.

Round 10: Non-SWIFT mechanism discovery

One controlled experiment explicitly excluded SWIFT and correspondent banking from the discovery instructions. This tested whether models could explore alternative mechanism families rather than simply reproduce a conventional correspondent-banking path.

Three hosted-model results in the consolidated Round 10 evidence provide a concrete comparison:

Model Corridor results marked PASS Candidate route objects normalized
Google Gemma 3 27B IT 415 / 420 1,682
NVIDIA Nemotron 3 Super 120B A12B 418 / 420 1,825
Qwen3 30B A3B Instruct 2507 420 / 420 2,980
Total 1,253 / 1,260 6,487

These are experiment-specific results, not proof that the generated candidates are distinct real-world services or usable payment routes. A result marked PASS indicates that the experiment recorded a successful result under its evaluation contract; it does not independently establish operational availability or regulatory eligibility.

The consolidated normalization report recorded 6,487 candidate objects with unique generated candidate IDs and no structurally invalid route records under its required-field checks. Seven source results were recorded as non-PASS. Hard-constraint filtering was not applied during normalization, and eligibility remained UNASSESSED.

These distinctions are central to interpreting the results correctly.

We also conducted a separate raw route-discovery experiment using Yandex AliceAI Foundation 80B to examine how a large base model behaves without forcing every response into the structured VTE route contract.

AI Model Evaluation

The project includes evaluation scripts and experiment records for comparing route-discovery behavior across models and providers.

The evaluation examines information such as:

  • Candidate route objects and route attributes
  • Funding methods and transfer paths
  • Payment rails and delivery methods
  • Route requirements
  • Raw model responses and execution status
  • Provider and model provenance
  • Constraint adherence and semantic validation where enabled

This makes it possible to study not only whether a model returns an answer, but also what kinds of mechanisms it proposes, how consistently it follows the requested constraints, and where its assumptions require further investigation.

The experiments also reveal why raw candidate counts should not be used as a standalone measure of quality. More generated candidates do not automatically mean more valid, distinct, available, or eligible routes.

Evidence-first architecture

One of the project's most important design principles is that candidate discovery and route verification are different problems.

An AI model might suggest a bank transfer, a fintech service, a local payment network, a digital-asset mechanism, or a cash-payout arrangement. The suggestion alone does not establish that the provider operates in the requested corridor, that the service is available to the intended parties, or that the proposed transfer complies with applicable requirements.

VTE therefore preserves the distinction between:

AI-generated candidate → Investigated evidence → Validation → Eligibility determination → Usable route

Evidence records retain provenance so that model claims, missing information, and validation outcomes can be examined. Unsupported assumptions should remain visible rather than being silently promoted to facts.

The architecture is intended to support auditable decisions while making uncertainty explicit. A structurally valid candidate can still be unverified, ineligible, unavailable, or unsuitable for a particular transfer.

Technology

The project is built primarily with Python and AI/LLM infrastructure.

The experimental environment includes:

  • Python-based route-discovery and evaluation scripts
  • Local and hosted language models
  • NVIDIA Nemotron 3 Super through Nebius-hosted inference
  • OpenAI-compatible model APIs and REST integrations
  • JSON-based experiment records and normalized evidence
  • Financial, blockchain, and external intelligence sources
  • Deterministic validation and decision-oriented components
  • Git and GitHub for versioned development

The architecture is designed to be model- and provider-neutral, allowing different models and intelligence sources to be evaluated without making one model the definition of the Value Transfer Engine.

Challenges we ran into

The biggest challenge was discovering that plausible AI-generated routes are not necessarily real routes.

Language models can produce convincing descriptions of providers, payment paths, mechanisms, and requirements without independently establishing that those services exist or are available for the requested corridor.

A second challenge was model variability. Different models returned different numbers and types of candidates, and some responses failed the experiment's output or constraint requirements.

These findings changed how we approached the system. Instead of treating the LLM as the final authority, we designed the workflow to preserve raw outputs, separate candidate generation from evidence investigation, and distinguish structural validity from actual eligibility.

The challenge became not just finding more possibilities, but understanding what the available evidence justified.

Accomplishments we're proud of

We built an experimental AI-first Value Transfer Engine architecture and a route-discovery evaluation environment that makes model behavior observable and comparable.

Key accomplishments include:

  • A 21-country, 420-directed-corridor route-discovery matrix
  • Comparative experiments across multiple local and hosted models
  • A controlled Round 10 experiment excluding SWIFT and correspondent banking
  • A consolidated set of 6,487 normalized candidate route objects across three model results
  • Provenance-aware candidate normalization and structural validation
  • Evidence extraction that preserves the distinction between model claims and verified facts
  • Regulatory evidence and eligibility concepts within the wider architecture
  • A separate raw AliceAI Foundation 80B experiment

Most importantly, the project evolved from asking:

“Which route should we use?”

to asking:

“What mechanisms could exist, what evidence supports them, and which candidates can actually satisfy this transfer requirement?”

That change in the question is the foundation of VTE.

What we learned

We learned that AI is useful for exploring a broad and changing space of possibilities, but model output must not automatically be treated as financial truth.

We also learned that route discovery is sensitive to model behavior and output constraints. Different models can propose different candidate mechanisms for the same corridor, and even a well-formed response may contain unsupported assumptions.

These findings led us to preserve raw model evidence and distinguish:

  • Discovery from verification
  • Hypotheses from facts
  • Intelligence from decisions
  • Structural validation from eligibility
  • Candidate availability from proven operational capability

We also learned that a conversational interface should not define the architecture. It can be one way to express a transfer requirement, while the underlying engine remains responsible for investigating and evaluating possible mechanisms.

What's next for CrossBorder Settlement Intelligence

The current experimental focus is:

Discover → Investigate → Validate → Assess Eligibility → Recommend

The longer-term direction is:

Discover → Investigate → Validate → Select → Execute / Coordinate → Confirm Delivery

Moving from route discovery to reliable value exchange requires more than selecting a candidate. It requires provider integration, execution controls, settlement coordination, recovery, reconciliation, and trustworthy confirmation that the recipient received value in a usable form.

The broader VTE vision is to coordinate value transfer through an appropriate combination of financial networks, payment providers, local payment systems, digital assets, or other mechanisms—where supported, eligible, and verifiable.

This remains a development goal rather than a claim that the current prototype already completes every end-to-end transfer.

The long-term ambition is simple:

Tell us where you need value to go. VTE investigates how. Ultimately, the goal is for value to arrive in a form the recipient can use.

Built With

Share this project:

Updates

posted an update —

I designed and developed the AI-first Value Transfer Engine architecture, including its dynamic multi-node/multi-hop route-discovery approach, evidence-driven validation principles, and deterministic decision boundaries. I built and evaluated the route-discovery experimentation framework across 21 countries and 420 directed corridors, compared local and hosted AI models including NVIDIA Nemotron through Nebius Token Factory, and developed the BRICSPay simulation interface to demonstrate how a transfer requirement can lead to candidate-route investigation and an auditable simulation outcome. I also established the separation between AI-generated candidates, evidence-backed validation, eligibility assessment, and eventual real-world execution.

Submission history