Side project : FX Trading (Central bank application for FX Markets and block explorer)

General
,
1

I’ve been developing a smart contract-driven FX trading system aimed at demonstrating improved efficiency, transparency, and auditability for central bank-managed foreign exchange (FX) markets. The project currently leverages DAML smart contracts to enforce FX trade execution, compliance, and liquidity management - with allowance for the use of DAML triggers and other on-ledger automations in the future.

The project is currently offline but more information about the vision can be seen here([Vision: v0-bo-g-fx.vercel.app]( v0 App -Process Charts)),

and here v0 App

and here (https://v0-bo-g-fx-5lm66d.vercel.app/)

The transaction graph made available by daml script (as the sole datasource for the vercel webpage) demonstrates how interbank FX trades, remittances, and liquidity reserves can be handled securely and automatically. With this milestone, the core functionality is communicable, and the system is at a stage where it can be taken to the next level.

The Transaction Graph – What’s Working?

1. Smart Contract-Driven FX Market Transactions

The DAML transaction graph captures and enforces:

  • Bank Registration & Permissions: Ensuring only approved entities participate.
  • Currency Pair Management: Defining and updating FX rates.
  • Liquidity Reserve Management: Tracking USD, EUR, GBP, and GHS holdings across banks.
  • Interbank FX Trades: Automating FX offers, acceptance, and settlements.
  • Remittances & Treasury Operations: Managing cross-border transactions and government securities.

2. Secure & Transparent Audit Trails

Every transaction—whether an FX trade, liquidity adjustment, or remittance—is recorded immutably with cryptographic signatures. This design ensures compliance with:

  • AML/KYC requirements through automated validations.
  • Central bank governance policies with built-in role-based access control.
  • Regulatory reporting standards, with timestamped, traceable records.

What’s Next?

The major challenge at this stage is developer resources and expertise to further:

  • Expand the FX trade logic with more sophisticated liquidity mechanisms.
  • Integrate with global payment networks (e.g., SWIFT, CBDCs, Stablecoins).
  • Enhance AI-driven risk management and market analytics.

Open to Collaboration

With the transaction graph and core codebase functional, the project is at an inflection point where it can evolve into a scalable financial infrastructure solution. I’m open to:

  • Technical feedback from the DAML community.
  • Developer collaborations to refine and scale the system.
  • Investors & partners who see potential in bringing better FX infrastructure to central banks and financial institutions.

If you’re interested in discussing next steps, feel free to reach out. Looking forward to insights from the community!

bogfx overview
bogfx overview1858×694 83.4 KB

3

German, that’s a slick demo. I like all the ways in which you’ve visualized the workflows and transactions.

You say “Side Project” in the title. Are you looking to commercialize this? Are you working on this with a particular customer in mind? Have you tried approaching them?

1 Like
4

Hi Bernhard, thank you very much! I really enjoy modelling stuff with DAML and I have been trying to improve here and there. There’s of course room for improvement which is why I called it a side project… other reason is, it’s a WIP but I am travelling right now so in two weeks I will be in a proper position to have discussions about how I can shape it up for success. Commercializing it would be awesome… I haven’t approached any potential customer yet…

5

Hi @German_Defoe,
Keep in mind that triggers are deprecated, and as of release 2.10, you will have issues with it. You can read about this here: Release of Daml 2.10.0 LTS
There are, of course, other solutions to use instead of triggers, but I just wanted to share that with you.

1 Like
6

Hi @cohen.avraham,

Thank you for highlighting the concern about triggers in Daml 2.10.0 LTS. I understand this was raised because my FX Market application includes components that would traditionally rely on triggers for automation.

After reviewing my codebase, I can confirm that I haven’t implemented triggers yet. Instead, my current approach is as follows:

Current Implementation

  • Uses pure Daml Scripts for testing and initialization
  • Encapsulates core business logic within contracts and choices
  • No trigger dependencies or built-in automation

  1. Current Implementation

    • The codebase uses pure Daml Scripts for testing and initialization
    • Core business logic is in contracts and choices
    • No trigger dependencies or automation are present

  2. Architecture Overview
    daml/
    ├── BoGFxMarket/
    │ ├── Admin/
    │ ├── FXMarket/
    │ ├── Treasury/
    │ └── Remittance/
    ├── Main.daml
    └── BoGFxMarketScript.daml

  3. Current Dependencies
    sdk-version: 2.10.0
    dependencies:

    • daml-prim
    • daml-stdlib
    • daml-script

That said, I recognize that implementing automation—previously handled via triggers—will require some rethinking. Your feedback is therefore timely, especially as commercial readiness is mentioned. From looking at my codebase, some key areas where automation might be necessary include but not limited to:

  1. Real-time FX rate updates
  2. Automated expiry of FX offers
  3. Monitoring of repatriation deadlines
  4. Settlement automation

I appreciate your insights and look forward to exploring alternative approaches. Thanks again!