Treasury Infrastructure
BEATOZ Treasury - Treasury Operations Platform
A treasury operations platform for transfers, FX, reserves, settlement, and monitoring. It separates ledger and reserve responsibilities, connects API and Kafka flows, and includes reconciliation, replay, and operator tooling.
01 / Scope
Keep records, funds and transfer progress distinct.
A financial-operations platform connecting transfer, FX, reserve and settlement work. The design separates domain responsibilities while giving operators a place to inspect and recover asynchronous processing.
I built the Treasury API, admin and testbench applications, Kafka integration and single-instance deployment automation within a shared Beatoz dev pilot. CPG and adjacent services remain separate domains.
02 / Responsibilities
Three questions, different responsibilities.
Synchronous API requests and Kafka ingress
- Ledger
What has been recorded?
Accounting records belong to the ledger domain. A recorded entry and a completed external transfer are not interchangeable descriptions.
- Reserve
What funds are available?
Reserve operations are separated from the ledger and transfer modules so that availability can be discussed as its own responsibility.
- Transfer / FX
How far has the operation progressed?
Transfer and FX APIs handle their own work. Their responses need to be interpreted alongside, not substituted for, settlement reconciliation.
Reconciliation and monitoring connect the views
Settlement reconciliation schedulers, admin views and the testbench make discrepancies and recovery paths inspectable. This map does not assert a particular transaction boundary or an exactly-once guarantee.
What the design separates.
Make repeat requests an API concern
The project account records idempotency controls and problem-details responses at the API boundary. They give repeated requests and failures explicit contracts rather than leaving them to the interface.
Keep replay visible to operators
Kafka consumers, DLQ replay and settlement reconciliation are described alongside admin and testbench tools. Recovery is part of the operating workflow, not just an invisible retry.
Build for the deployment constraint
The pilot used single-instance deployment automation. PM2, Nginx and PostgreSQL setup were part of that scope; this is not presented as a multi-region or high-availability deployment.
03 / Review cases
Questions at the boundaries.
Review scenarios, not reported incidents or passing runtime tests.
The caller repeats a transfer request
- Mechanism
- API idempotency controls and a structured error contract are recorded in the project account.
- What to check
- Compare the original and repeated request, the resulting operation identifiers and any financial side effects. No such transaction trace is attached here.
An operator replays a failed Kafka message
- Mechanism
- The account includes Kafka consumers, DLQ replay services and mock producers.
- What to check
- Inspect the failed attempt, prior domain changes and replay outcome together. A message being consumed does not by itself establish financial completion.
Transfer progress and settlement records disagree
- Mechanism
- Settlement reconciliation schedulers and monitoring views are part of the described implementation.
- What to check
- Identify which records are compared, how the discrepancy is surfaced and which action resolves it. These are review questions, not claims about a historical incident.
The implementation scope
BEATOZ Treasury
Treasury API
Core Operations Backend
- Idempotent transfer/FX/reserve APIs
- Problem-details error contract
- Settlement reconcile flows
Admin Web
Operations Dashboard
- Reserve and monitoring views
- Transfer and settlement operations
- OpenBanking integration screens
Testbench + Mock Services
Flow Validation
- Scenario runner UI
- Billing/cross-border mock producers
- Kafka smoke and DLQ replay verification
Technology
- TypeScript
- NestJS
- Next.js
- Prisma
- PostgreSQL
- KafkaJS
- React
- Docker
- AWS
04 / Sources & record
Read the basis of the account.
Based on the existing project account. The original Treasury repository and transaction logs are not available as public evidence in this case study.
This page preserves the author’s recorded implementation scope. The map is explanatory and the scenarios are review questions, not production incidents or passing payment tests. No throughput, availability or settlement-performance result is added.
Read the existing technical record
The problem
Needed treasury transfer, FX, reserve, and settlement flows to remain consistent across synchronous APIs and Kafka-driven ingress while preserving idempotency, DLQ replay, operator visibility, and deployability on a constrained single-instance environment. The domain also had to expose stable interfaces for upstream and downstream systems such as CPG and other compliance/operations services participating in the shared pilot.
The response
Built domain modules for bank/fx/ledger/reserve/transfer/monitoring/treasury-consumers, enforced idempotency and problem-details responses at the API boundary, added Kafka consumer + DLQ replay services and settlement reconciliation schedulers, and shipped admin/testbench apps for day-2 operations. Exposed domain-interface and ingress flows that can receive requests from CPG and adjacent services, while keeping the runtime compatible with the central AWS-based dev-pilot rollout layer and single-instance deployment automation.
Overview
- Solo-built treasury operations monorepo covering transfer, FX, reserve, settlement, and monitoring workflows.
- Includes an API, operator-facing dashboards, a scenario testbench, mock producers, and deployment scripts.
- Served as the financial operations core for a shared Beatoz dev-pilot environment alongside CPG and other connected service domains.
Key Components
Treasury API
- NestJS modules for bank, FX, ledger, reserve, transfer, monitoring, and treasury consumer ingress
- Problem-details filter + idempotency interceptor with in-memory/Prisma-backed stores
- Reconcile endpoints and scheduler hooks for settlement state management
- Domain-interface endpoints for adjacent services such as CPG and compliance-oriented integrations
Kafka Ingress & Replay
- Billing/cross-border ingress handlers for transfer, reserve movement, and FX execution
- DLQ publishing, replay control endpoints, replay status/recent history, and worker lock coordination
- Smoke scripts for Kafka ingress, outbox transaction flow, and DLQ replay validation
Admin + Testbench
- Next.js admin app for monitoring, reserve, FX, transfers, settlements, and operations views
- Next.js testbench app for running scenarios, inspecting logs, and exporting flow history
- Mock billing/cross-border services to validate consumer-driven workflows
Deployment & Operations
- Single-instance AWS deployment script with Postgres, PM2, and Nginx wiring
- Environment bootstrapping for API, admin, and testbench apps
- Default bank-account seeding and profile-based deploy options for test/dev
- Runtime shape aligned with a shared central dev-pilot rollout controller