Named parts, not one number
A pool is not a single balance. Available, reserved, operational and contingency are tracked separately, so “how much is there” and “how much can be used” are different questions with different answers.
Infrastructure · LiquidityLiquidity behind
Liquidity behind
every movement.
Conversion and settlement both draw on a position that has to be real, measured and defensible. BINK keeps one pool per currency, divides it into parts that mean different things, and writes down every movement against it.
Anatomy of a pool
AvailableFree to be drawn against
ReservedCommitted, not yet released
OperationalHeld for day-to-day movement
ContingencyHeld back deliberately
Thresholds
Alert thresholdCrossing it marks the pool low
Minimum thresholdCrossing it marks the pool critical
One record per supported currency. Balances are whatever has been moved in — no capacity figure is published.
PoolsOne per supported currency
PartsFour, tracked separately
ThresholdsPer pool, set by an audited change
MovementsAtomic, and never edited
Status
Where the line sits.
A pool’s status is not a judgement — it is the answer to where its balance falls against two thresholds it carries itself. Both are configurable per pool, and changing one is an audited action like any other.
A conversion that crosses a threshold re-derives the status immediately and raises the alert as part of the same flow, rather than waiting for a sweep to notice.
HealthyAbove the alert threshold. The pool is operating normally and nothing is raised.
Alert threshold
LowBetween the two thresholds. The pool still functions, and an alert is raised so it is dealt with before it does not.
Minimum threshold
CriticalBelow the minimum. The pool is treated as unable to meet what is being asked of it.
No level is drawn. A pool holds whatever has been moved into it, and showing a fill here would be inventing a balance.
A movement
Balance and record, together.
The balance change and the record of it are one operation. Either both happen or neither does — which is what makes the event history a reliable reconstruction of the pool.
- PoolA balance per currencyOne record for each currency the platform supports.
- MovementApplied atomicallyThe change is made as an increment, never a read-then-write.
- EventWritten with itBalance before and after, in the same transaction.
- StatusRe-derivedCompared against thresholds; an alert follows a breach.
Sources of movement
What moves a pool.
Three things, and no others. Each one leaves the same kind of trace, so the history does not distinguish between an automatic movement and a deliberate one except by its recorded reason.
These are BINK’s own operating pools. There are no external liquidity providers, correspondent banks or market sweeps behind them, and none are claimed.
- A conversion
- When an FX conversion executes, the pools on both sides move as part of the same flow, and the resulting status is re-derived immediately.
- An operator
- A treasury operator can record a movement against a pool directly. It is written with a reason and is audited like any other action.
- A rebalance
- Moving between two pools checks that the source can cover the amount, then updates both and writes both events — or does none of it.
What the layer does
Measured, not estimated.
A treasury position is only as good as the evidence behind it. Everything here is derived from balances that exist, converted at rates that were actually used.
Thresholds per pool
Each pool carries its own alert and minimum levels. Status is derived from them rather than assessed by eye, and the levels themselves are set through an audited change.
Atomic movements
A movement is applied as a database-level increment inside a transaction, so two movements arriving together cannot both act on the same starting balance.
Append-only history
Every movement writes an event carrying the balance before and after. The history is added to, never edited, so a pool’s balance can be reconstructed from its events.
Alerting with rules
Coverage, currency concentration and survival horizon are evaluated against defined thresholds, with repeat alerts suppressed inside a cooldown window.
Snapshots and forecasts
Positions are captured hourly and daily from real balances, normalised to a single currency through live rates, and projected forward with a stated confidence rather than a bare number.
Operational detail
How it behaves.
- Scope
- These are BINK’s own operating pools — the platform’s internal treasury position, one record per supported currency.
- Starting state
- Pools are created empty. A pool holds exactly what has been moved into it; there is no headline capacity figure and none is published.
- Status
- Healthy, low or critical — derived by comparing the pool against its own thresholds, not against a global rule.
- Rebalancing
- Moving liquidity between pools is an operator action with a sufficiency check. It is not automated, and BINK does not run scheduled sweeps.
- Hedging
- Currency exposure is measured and reported. Hedge positions are recorded by an operator; there is no automatic hedging.
- Normalisation
- Nothing sums across currencies without conversion first — every figure is normalised through live rates before aggregation.
- Stress testing
- Positions are tested against defined outflow scenarios, and the value-at-risk figure is treated as an approximation rather than a guarantee.
- External funding
- BINK does not claim external liquidity providers, correspondent banking relationships, market makers or credit lines behind these pools.
Scope
What this is, and is not.
Liquidity sits underneath the product surfaces rather than beside them, so it is worth being exact about who touches it and how.
- Not a customer surface
- These pools are BINK’s own treasury position. They are not an account a customer holds, and there is no public endpoint that draws on them.
- Movements are derived
- The main automatic source of movement is an executed conversion. Nothing else moves a pool without an operator recording it.
- Status is computed
- Healthy, low and critical are derived by comparing a pool against its own thresholds — not assessed by a person and not set by hand.
- History reconstructs
- Because each movement writes the balance before and after, a pool’s position at any past moment can be rebuilt from its events alone.
In practice
What the structure is for.
Know before it bites
Set the alert threshold high enough that a pool is flagged while there is still room to act, rather than at the point it can no longer cover what is asked.
Separate what is spendable
Track committed and held amounts apart from free balance, so “how much is there” and “how much can be used” never have to be the same answer.
Move between currencies
Rebalance from one pool to another with a sufficiency check first, writing both sides and both events together or not at all.
Explain a position
Reconstruct how a pool reached its current balance from its own event history, without depending on a report that was generated at the time.
In the platform
What draws on it.
Liquidity is the layer underneath the movement surfaces rather than a product of its own.
Infrastructure
Every surface.
RoutingHow a transaction is matched to a processor.FX engineRates, locked quotes and currency conversion.Real-time SettlementThe lifecycle from captured to settled.Liquidity network ·Per-currency pools and the movements against them.ReconciliationChecks that the books agree with the ledger.BankingThe regulated foundation the platform runs on.
Liquidity
A position you can evidence.
Every movement recorded, every threshold explicit, and every cross-currency figure converted before it is summed.