# Budget allocator — Fintech

The budget allocator with three columns a regulated financial product needs: which product a share is for, which market it may be spent in, and the approval rate the share's economics assume.

Everything else is the general allocator, unchanged. One row per destination, a basis for every share, a floor and a ceiling, and a reallocation rule written before it is needed.

## How to use it

1. Copy this file, or the CSV version if you would rather work in a sheet.
2. List the destinations first, at the level the argument is actually being had.
3. Write the basis for each row before the number, and keep measured performance, bets and commitments in separate rows.
4. Set floors before shares: a destination that cannot clear its floor should not be in the split at all.
5. Fill Share of total so the column sums to one whole, per currency.
6. Write the reallocation rule now, while nothing is going wrong.
7. Re-argue each row on its own cadence, and record what changed and why.

## The columns

**Allocation name** (Text). What this split is called and the period it covers, split at any change to a rate, a fee or a term, because such a change resets the economics of every row at once.

**Destination** (Text). What the share goes to: a product in a market, a channel within one, a retargeting audience. One product and one market per row, because approval rates differ enough to make a blend meaningless.

**Basis** (Text). What the share rests on: measured performance read on funded accounts, a bet on a new product, a contractual commitment, or a floor. Performance rows name the window they were read over.

**Share of total** (Percent). This row's proportion of the period's budget. The column is where a portfolio's balance between products and markets becomes arguable rather than inherited.

**Amount (minor units)** (Integer). The share as money, in the smallest unit of its currency, as a whole number, so the rows add to the figure the acquisition plan committed.

**Currency** (ISO 4217 code). The ISO 4217 code the destination bills in, which for a single-market product is one code. A second code in this column usually means a market is missing its own row.

**Floor (minor units)** (Integer). The least this row can hold and still produce a readable approval rate. Ratios of relatively rare events need volume, and a thin row produces a rate that swings enough to justify any conclusion.

**Ceiling (minor units)** (Integer). The most this row can absorb before the money buys duplicate applications rather than new customers. Search demand for a product in one market is finite in a given week.

**Reallocation rule** (Text). What must hold before money moves in or out here, and how much may move at a time. The condition should read on funded accounts rather than applications, so the window is longer than a week.

**Review cadence** (Text). How often this row is re-argued. Weekly on performance, and immediately after any change to a published rate, fee or term, because the assumed approval rate is then out of date.

**Evidence** (Text). What the share rests on, named: the window funded accounts were read over, the underwriting source, the assumed approval rate and when it was measured.

**Owner** (Text). The person who defends the size of this row. Anything resting on an approval-rate assumption needs whoever owns underwriting to have seen the number.

**Notes** (Text). What the next person needs: the approval rate this row assumes and its date, the market where the product is not yet authorised, the retargeting row that is dependent rather than comparable.

**Product** (Text). The financial product this share is for: a card, an account, a loan type, a payments rail. Approval and funding rates differ enough between them to make a blended share meaningless.

**Jurisdiction** (Text). The market this share may be spent in, in the terms your authorisation uses. A share that cannot legally be spent in a market is not a share, it is a rounding error waiting to be found.

**Approval rate assumed** (Text). The rate this row's economics assume, with the window it was read over. It is the assumption most likely to be wrong and the one that changes the answer most.

## The budget allocator

| Allocation name | Destination | Basis | Share of total | Amount (minor units) | Currency | Floor (minor units) | Ceiling (minor units) | Reallocation rule | Review cadence | Evidence | Owner | Notes | Product | Jurisdiction | Approval rate assumed |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |
|   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |
|   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |
|   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |

## Before you commit it

- Every row names one product and one jurisdiction.
- Every row records the approval rate its economics assume, with the window it was read over.
- Shares sum to one whole per currency.
- Every row has a floor, and no row is funded below it.
- No share is allocated to a market the product is not authorised in.
- Every row has a reallocation rule written before it was needed.
- Anything that is an assumption says so, in Notes, in words.