A draw is a sub-account within a line of credit. Each draw has its own balance, interest rate, fee structure, and transaction history. Draws allow borrowers to segregate different types of borrowing (e.g., purchases at one rate, cash advances at a higher rate) within a single credit line.
This page explains how LOC draws work. To run a migration, see the LOC migration procedure.
A draw is a virtual "bucket" within the LOC. When a purchase is posted or a cash advance is taken, it is assigned to a specific draw. The LOC's total credit limit is shared across all active draws, but each draw independently maintains its own balance, interest rate, promotional rate, draw fees, and minimum payment calculation.
Peach supports four draw types:
| Draw type | Purpose | Typical use | Interest behavior |
|---|---|---|---|
| RegularPurchase | Standard retail purchases | Primary draw type for card activity | Standard APR |
| CashAdvance | Cash withdrawal or equivalent | ATM withdrawals, cash-like transactions | Often higher APR; may have different fees |
| BalanceTransfer | Transferred balance from another card | Promotional offers | Often 0% APR promotional rate |
| Static | Migration draw (historical data) | Created automatically at migration | No interest accrual; no new activity after migration |
Most active LOCs have multiple draws. The Static draw is special and used only during migration.
The LOC has a single credit limit (e.g., $10,000) that applies across all draws:
available_credit = loc.creditLimit - sum(draw.balance for all active draws)Each draw can also have a sub-limit that further restricts that specific draw type. Both the LOC-level limit and the draw-level limit must be satisfied for a new purchase to be approved.
Fees can be charged at draw creation or throughout the draw's lifecycle:
| Fee type | When charged | Example |
|---|---|---|
| Draw fee | At draw creation | $75 cash advance origination fee |
| Transaction fee | Per transaction | 3% foreign transaction fee |
| Periodic fee | Each billing period | $5/month servicing fee |
| Late fee | When draw goes overdue | Automatic, handled by DLM |
Draw fees are tracked separately from LOC-level fees (like annual fees). During migration, draw fee balances must be included in the migration period draw data under the appropriate nonDueDrawFeesAmount, dueDrawFeesAmount, or overdueDrawFeesAmount fields.
When a purchase is posted, it must be assigned to a specific draw. The assignment determines which draw's balance increases, which interest rate applies, and which minimum payment calculation is used.
During migration, historical purchases are posted to the migration draw (static draw) with an originalDrawId field referencing the actual legacy draw they belonged to. Post-migration, new purchases are posted directly to the appropriate draw (RegularPurchase, CashAdvance, etc.).
The static draw is an internal construct created at migration to hold all pre-migration transactions and balances. It exists solely to bootstrap the LOC with historical data.
Creation: Peach automatically creates one static draw per LOC when the loan is created with migrationStatus: "prepMigration". You don't create it manually.
Configuration:
| Property | Value | Why |
|---|---|---|
drawType | Static | Identifies it as the migration draw |
timestamps | Equal to LOC activation date | Appears to have existed since LOC origination |
min_payment_percentage_of_principal | 0 | Static draw doesn't contribute to minimum payment |
migration_status | Synced with LOC | Follows the LOC's migration lifecycle |
What it holds: All pre-migration purchases, transactions (payments, service credits), fees, and obligations.
Behavior after migration: The static draw transitions to Active status (like all other draws) but is effectively disabled — the API rejects any attempt to post new activity to a static draw with "This endpoint is invalid for a static draw." Payment application can still target the static draw if the borrower carries an unpaid balance from pre-migration.
The originalDrawId field on historical purchases references the actual legacy draw, not the static draw. This lets you track which legacy draw each purchase belonged to, even though all historical purchases are stored under the static draw in Peach.
The LOC's minimum payment is the sum of each draw's minimum payment:
loc.minimumPayment = sum(draw.principal * draw.minPaymentPercentage for all active draws)The percentage can vary by draw type (e.g., CashAdvance might require 5% while RegularPurchase requires 2%). The static draw's percentage is 0, so it contributes nothing to the minimum payment. This prevents borrowers from facing unexpectedly high minimums immediately after migration due to old balances.
- The static draw is created automatically — don't create it manually.
- Post all historical purchases to the static draw using
originalDrawIdto reference the actual legacy draw. - Create actual draws (RegularPurchase, CashAdvance, etc.) for any draw types that were active before migration and should continue to accept new activity.
- Populate migration period data for each draw — the system validates that every non-static draw has a ledger update event.
- After migration, all new activity goes to actual draws. The static draw is read-only.
- Draw fees must be configured correctly on each draw's
atOrigination.feesobject, and fee balances must be seeded in the migration period draw data.
- LOC migration procedure — Create the migration draw and active draws during migration.
- How LOC billing cycles work — How draw balances move through billing buckets.
- How grace periods work for lines of credit — Draw-level grace tracking.