MicroCustody: Custody Banking Platform

What the platform does

The platform digitizes end-to-end custodian services between Portfolio Management Companies (PMCs) and institutional banks. Role-based access control with PMC-level authorization keeps each company’s users and data segmented, while fund definitions, broker and commission parameters, and IBAN and financial account configurations are all maintained from one central interface instead of being restated per counterparty.

Nothing reaches processing unreviewed. All uploaded data passes through a standard Maker-Checker (Uploader-Approver) workflow, so every change has a submitter, an approver, and a record. The integration layer handles EFT and wire transfer processing into core banking systems, converts PMC-sourced file formats automatically, and exposes financial account query services for balance and transaction data.

Capabilities

MicroCustody is in pilot. The list below is the capability set of the platform as designed; some parts are still being completed with the pilot.

• RBAC and PMC-level authorization — segmented user management across tenants
• Fund definition and management, including broker and commission configuration
• IBAN and financial account management from a single central interface
• Maker-Checker approval workflow applied to every data operation
• EFT and wire transfer integration with core banking systems
• Automatic file format conversion for PMC-sourced documents
• Financial account query services for balance and transaction data
• Multi-tenant architecture serving multiple PMCs from one deployment

How it is built

• .NET microservices deployed on Azure
• PostgreSQL for transactional data, with a full audit trail
• Event-driven integration layer for financial system connectivity
• Reporting and compliance dashboard over the same data

Maker-Checker is a data control, not a screen

The approval gate is enforced in the data model rather than in the interface, because the interface is only one of the ways data arrives — an uploaded file, an API call and a batch job all reach the same tables. A submission does not modify the live record. It writes a pending change carrying the submitter, the target record and the full before/after payload; approval is the transition that promotes it, and that transition is the only path that writes the live version. A rejected change stays in place with its reason attached rather than disappearing.

Two things follow. The audit trail is not assembled from logs after the fact — it is the same rows the workflow already runs on, so “who changed this broker commission, when, and who let it through” is a query rather than an investigation. And separation of duties is enforced at the service boundary: a submitter cannot approve their own change because the transition checks identity, not because a button was hidden from them.

Two independent boundaries: what you may do, and whose rows you may touch

RBAC and PMC scoping deliberately stay separate concerns. Roles decide which operations a user can invoke; the PMC claim decides which rows those operations can reach, applied as a mandatory predicate below the query layer rather than as a filter each screen has to remember to add. Collapsing the two into a single role matrix is the common shortcut, and it costs twice: every new PMC multiplies the number of roles that have to exist, and a forgotten filter stops being a missing menu item and becomes a cross-tenant disclosure.

File conversion is a mapping definition, not parsing spread through the code

Each PMC sends its own layout. Rather than a parser per counterparty living wherever it was first needed, a PMC’s format is expressed as a mapping definition and the pipeline normalizes everything into one canonical instruction record — validation, approval and dispatch downstream only ever see the canonical form. Validation runs per row with a reason attached, so a single malformed line does not reject an otherwise good file and the operator gets a list of what to fix instead of “upload failed”.

The file is retained exactly as received alongside the parsed result. Custody work is audited against what the counterparty actually sent, and a conversion defect is only diagnosable if the original bytes are still there.

A transfer commits and dispatches as one decision

An approved instruction and the intent to send it are written in the same PostgreSQL transaction, and dispatch to core banking is picked up from that record asynchronously. That outbox arrangement exists to rule out the two failure modes that matter here: an instruction approved in the platform that never reached the bank, and a dispatch that no approved instruction accounts for. Retries carry the original instruction reference so a redelivery is recognised rather than executed a second time, and a send whose outcome is unknown is resolved by querying status — never by sending again, because at the bank end a timeout and a rejection are not the same event.

Reporting reads the ledger, not a copy of it

Compliance and reporting views are read models over the same transactional data rather than a separately maintained export. A reporting copy drifts from its source eventually, and in custody a report that disagrees with the record is worse than no report at all.