Case study · Our own product · Early access
FinoGrid: designing a cross-border payouts SDK for USD to CAD contractor payments
FinoGrid is a developer SDK for platforms that pay contractors in Canada from US balances, using stablecoin rails for the cross-border leg. We designed and built it in the Payments Studio. This case study sets out the problem, the decisions and the architecture.
- Status
- Early access
- Corridor
- USD to CAD
- Funds
- Held and moved by licensed partners
- Owner
- Munro Banting
FinoGrid is owned by Munro Banting. We say so whenever we recommend it.
The problem
A US platform paying a contractor in Canada pays a fee on the transfer and a spread on the currency conversion, and the contractor waits for settlement. We will not publish cost or time comparisons until we have measured them. Building an alternative means choosing ramp providers, keeping a ledger that stays correct across two currencies and a conversion step, and running compliance checks on every payout. We wanted a component a platform could integrate in its own product without holding funds.
Design constraints
- 01
No funds held
FinoGrid never holds funds; licensed partners hold and move them.
- 02
Screen first
Every payout is screened before funds move.
- 03
Daily reconciliation
The ledger must reconcile to partner records daily, including payouts that fail after conversion.
- 04
Human-set limits
AI agents may request payouts only inside limits a human sets in advance.
- 05
One SDK call
The integration must be an SDK call for the platform's engineers.
Decisions and trade-offs
- Ramp model. Separate licensed on-ramp and off-ramp providers rather than one provider for both legs, for corridor coverage [OWNER: confirm decision and reason]. Trade-off: two reconciliations instead of one.
- Ledger. Double-entry and append-only, with a clearing account for each step (on-ramp, in transit, off-ramp) so funds in conversion are visible on a balance sheet at every point. Trade-off: more entries per payout.
- Payout states. Created, screened, funded, converting, in transit, delivered, returned, reversed. A payout that fails after conversion moves to a held state with its stablecoin balance recorded, not to "failed".
- Compliance in the flow. Identity verification at contractor onboarding; sanctions screening at onboarding and again at payout. Screening results are stored against the ledger entry.
- Agent access. An MCP server exposes payout requests to AI agents. Each agent key has a per-payout and a daily limit, a payee allow-list and a human approval threshold [OWNER: confirm the controls as built].
What we built
- SDK [OWNER: languages]
- Settlement ledger
- Payout state machine
- Compliance-check service integrated with [OWNER: vendor names only if contracts allow]
- MCP server with limits and approvals
- Operations views for held and returned payouts
Code excerpt to follow: a single SDK call creating a payout with an idempotency key, and the ledger entries it produces [OWNER: real, reviewed excerpt from the repo].
What building it taught us
To be written
[OWNER: three to four bullets in plain language. Proposed topics: how we compared ramp providers; how the ledger handles a payout that fails after conversion; what a partner bank asked to see before onboarding; what we would design differently.]
What this means for a Payments Studio client
The same work appears in client engagements: ledger models with clearing accounts, payout state machines, screening at payout, and limits for automated requests. When FinoGrid could fit a client's need, we say so and disclose that we own it.
FinoGrid is owned by Munro Banting. We say so whenever we recommend it.
See Payments Studio engagementsStatus and early access
FinoGrid is in early access. Features, corridors and partners may change. FinoGrid does not take deposits; payouts settle through licensed partners [LEGAL]. Speed and pricing figures will be published once they are measured.
Early access
Request access or a demo below. We reply by email; nothing on this page connects to FinoGrid systems.