Architecture overview
How Banking connects your product to Colombian bank rails.
Banking is Mono's bridge between your product and the Colombian banking network. When you call a Banking endpoint, the request passes through authentication, idempotency check, and routing before being dispatched to one of the available payout rails: ACH, Transfiya, or Mono Turbo. Collections (money in) follow the PSE rail.
This page is the right starting point if you want to understand the path a request takes through Banking, the rail it lands on, and why a single transfer call may end up using a different rail than the one you requested (Mono falls back automatically).
Rails
| Rail | Type | Typical use |
|---|---|---|
| Mono Turbo | Real-time payout | Real-time transfers to participating Colombian banks |
| ACH | Standard payout | Same-day transfers to any Colombian bank |
| Transfiya | Real-time payout | Transfers within a specific bank cluster |
| PSE | Payin | Customer-initiated bank transfer (e-commerce checkout) |
Request lifecycle
- Authenticate — the API key in the
Authorizationheader is validated. - Check idempotency —
X-Idempotency-Keyis looked up against the cache. - Route — the request lands on the rail you requested or its fallback.
- Dispatch — Mono submits the operation to the rail.
- Confirm — webhooks fire as the rail confirms or rejects.
Fallbacks
Mono Turbo can fall back to ACH when the destination does not support real-time settlement. The fallback decision tree will be documented here.
Lifecycle references
Once a request enters the platform it moves through a deterministic state machine, and every transition emits a webhook. The pages below document each state, its transitions, and the corresponding event — read these alongside the architecture above to understand what your integration should be listening for.
- Bank transfer lifecycle — states, webhook events, and terminal outcomes for transfers and batches.