Skip to main content
When one asset is linked to multiple programs, there are two ways to model member balances: pooled, where each member has one ledger entity and one combined balance, or partitioned, where each membership or account has its own ledger entity and its own balance. You choose a shape through your entity model. There is no configuration flag. The shapes differ in how per-program reporting attributes redemptions, and integrators often discover that difference too late, after issuance, when reporting looks wrong. Pick the shape before you issue value.

​
Pooled: One Entity Per Member

Link the asset to every program, and create one participant per member. Balances and lots are keyed by participant and asset, with no program dimension, so the member sees a single combined balance no matter which program issued the value. 
# Link the shared asset to a second program
POST /v1/programs/{programId}/assets
{"asset_id": "{asset_id}"}
A redemption through any linked ACTIVE program draws on the pooled balance. For LOT-mode assets, lots are consumed FIFO by creation date across everything the member holds, regardless of which program issued each lot. This is the right shape for a one-brand currency earned through multiple channels: a retailer with store and app programs, or an airline whose miles accrue through both flights and a status program. Members expect one number, and they get one number.
Per-program reporting attributes each redemption to the program it was redeemed through, not the program that issued the value. See How reporting attributes redemptions before choosing this shape.

​
Partitioned: One Entity Per Account

Create a separate participant entity for each membership or account, even when they belong to the same person. Each entity accrues into its own balance, and combining value is an explicit transfer. This is how Chase models Ultimate Rewards: Sapphire Reserve and Freedom each accrue points into separate card-account balances, and moving points between cards is a deliberate action the member takes. In Scrip, each card account is its own participant, and the merge is a transfer: 
POST /v1/transfers
{
  "program_id": "program-uuid",
  "source_external_id": "member-123-freedom",
  "asset_id": "asset-uuid",
  "description": "Combine Freedom points into Sapphire account",
  "recipients": [
    {"external_id": "member-123-sapphire", "amount": "25000"}
  ]
}
The transfer requires an ACTIVE program and both participants in ACTIVE status, and it produces a journal entry like any other balance movement. Per-program attribution stays exact because the merge is an auditable ledger event, not an implicit pooling.

​
How Reporting Attributes Redemptions

Journal entries for program operations, such as earning, redemptions, and transfers, carry the program_id of the program the operation ran through. System entries such as expiration carry no program_id and report under a null program row. Per-program reporting reflects the redemption channel, not the issuing program. In the pooled shape, a member can earn through program A and redeem through program B. Program B’s redemption line then includes value program A issued, so per-program cells diverge from per-program issuance, and a program’s individual liability cell can go negative. Asset-level totals remain exact: the itemized lines of the liability rollforward always sum to the change in outstanding liability for the asset as a whole. In the partitioned shape, this divergence cannot happen. Each entity earns and redeems within its own program, and cross-program movement shows up as an explicit transfer line rather than a silent reattribution.

​
Choosing a Shape

If…Choose
Members expect one balance with no merge stepPooled
Balances belong to accounts or partners that need exact per-program attributionPartitioned
A useful test: if a finance or partner team will ever ask “how much of program A’s issuance was redeemed through program A,” you need partitioned. If members would be confused by holding two balances of the same currency, you need pooled, and your reporting consumers should know the attribution semantics up front. For the mechanics of linking assets across programs, see Programs. For FIFO consumption order and lot lifecycle, see Lots and Expiration.