> ## Documentation Index
> Fetch the complete documentation index at: https://docs.allium.so/llms.txt
> Use this file to discover all available pages before exploring further.

# Merchant Payouts & AP/AR Flows

> Behavioral classification of one-to-many payout runs and recurring B2B settlement relationships

## What are the Behavioral Flow products?

A single transfer cannot reveal whether it is an invoice settlement or a marketplace payout — amount bands cannot distinguish a $40k invoice from a $40k payout. What *can* distinguish them is the **shape of a sender's activity over time**:

* **Payouts are a star** — one platform pays many recipients, in bursts. Measured per **(payer, day)** in `stablecoins.intelligence.merchant_payout_runs`.
* **AP/AR settlement is a line** — one business pays another, repeatedly, over months. Measured per **(payer, payee) relationship** in `stablecoins.intelligence.apar_flows`.

Both are **estimated behavioral activity** — the models report measurable shape (fan-out, recurrence, cadence, ticket uniformity), never inferred intent. "Invoice", "salary", "affiliate" are interpretations you apply; the data gives you cadence and ticket bands. Coverage: ethereum, tron, base, polygon, arbitrum, solana, bsc, plasma, stable, tempo — full history from 2020.

<Note>
  **Consumption rules.** Four rules keep queries honest:

  1. **Never sum the `identified` and `estimated` payout populations** — labeled platforms are identified payment activity; behavioral detections are an estimate that may include unlabeled exchange withdrawal wallets.
  2. **Consume per chain** — per-chain classifier calibration is ongoing; cross-chain totals are not supported.
  3. **Filter `is_established_relationship = true`** for any published AP/AR figure — the rest is discovery data.
  4. Payouts run *from exchange accounts* live in [exchange flows](/historical-data/payments/exchange-flows), not here.
</Note>

## merchant\_payout\_runs

**Purpose:** every day on which a payer disbursed to ≥ 10 distinct real recipients (or ≥ 5 in a single batching transaction), with platform identity, scale, timing, and ticket-uniformity features. DeFi routers, infrastructure sprays, bot-farm recipients, and platform-internal sweeps are excluded by construction.

| Column Name                                     | Data Type      | Description                                                                                                                                       |
| ----------------------------------------------- | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
| `chain` / `activity_date`                       | VARCHAR / DATE | Network and run day                                                                                                                               |
| `payer_address`                                 | VARCHAR        | The economic payer (transaction initiator when a batching contract fanned out — see `payout_run_basis`)                                           |
| `receivers_count` / `legs_count` / `txns_count` | NUMBER         | Distinct real recipients, disbursement legs, transactions                                                                                         |
| `max_txn_receivers`                             | NUMBER         | Largest single-transaction fan-out (disperse-style batching)                                                                                      |
| `total_usd` / `median_ticket_usd`               | NUMBER         | Run volume and typical ticket                                                                                                                     |
| `ticket_mode_share`                             | NUMBER         | Share of legs at the modal amount — high = uniform tickets (payroll-like)                                                                         |
| `disbursement_scale`                            | VARCHAR        | `consumer_scale` (median ticket \< $10k) vs `institutional` (≥ $10k, treasury-style)                                                              |
| `mode_hour_utc` / `mode_day_of_week_iso`        | NUMBER         | Payout timing signals                                                                                                                             |
| `is_round_the_clock`                            | BOOLEAN        | ≥ 20 active hours in the day — automation signal, surfaced not excluded                                                                           |
| `payout_run_basis`                              | VARCHAR        | `direct` vs `contract_mediated` (payer inferred via batching contract, not verified)                                                              |
| `platform_identification`                       | VARCHAR        | `labeled` / `behavioral` / `unattributed`                                                                                                         |
| `platform_type`                                 | VARCHAR        | Registry sub-vertical for labeled platforms: acquirer, payout\_processor, ap\_ar\_platform, on\_off\_ramp, custodial\_fintech, otc\_institutional |
| `population`                                    | VARCHAR        | **`identified`** (labeled platform) vs **`estimated`** — never sum the two                                                                        |

#### Monthly payout volume, populations separate

```sql theme={null}
SELECT chain, DATE_TRUNC('month', activity_date) AS month, population,
       SUM(total_usd) AS usd, COUNT(*) AS runs
FROM stablecoins.intelligence.merchant_payout_runs
GROUP BY 1, 2, 3
ORDER BY 1, 2, 3;
```

#### Payroll-shaped runs (uniform tickets, weekdays, human hours)

```sql theme={null}
SELECT *
FROM stablecoins.intelligence.merchant_payout_runs
WHERE disbursement_scale = 'consumer_scale'
  AND ticket_mode_share >= 0.5
  AND mode_day_of_week_iso BETWEEN 1 AND 5
  AND NOT is_round_the_clock;
```

## apar\_flows

**Purpose:** every business-to-business transfer between wallets with an ongoing relationship, classified **point-in-time** — each transfer carries its pair's trailing-180-day statistics *as of that moment*, so historical analysis has no look-ahead bias. Both sides must type as Business, the sender must not be a payout platform, and protocol-context legs (DEX, lending, bridge), MEV, and bot counterparties are excluded.

| Column Name                                                                | Data Type        | Description                                                                                         |
| -------------------------------------------------------------------------- | ---------------- | --------------------------------------------------------------------------------------------------- |
| `chain` / `unique_id` / `transaction_hash`                                 | VARCHAR          | Transfer identity                                                                                   |
| `block_timestamp` / `activity_date`                                        | TIMESTAMP / DATE | Transfer time (UTC)                                                                                 |
| `token_address` / `token_symbol` / `product_id` / `currency`               | VARCHAR          | Stablecoin identity                                                                                 |
| `usd_amount`                                                               | NUMBER           | USD notional                                                                                        |
| `from_address` / `to_address`                                              | VARCHAR          | Paying / receiving business wallet                                                                  |
| `receiving_entity`                                                         | VARCHAR          | Entity label of the receiver when one exists                                                        |
| `ticket_band`                                                              | VARCHAR          | under\_1k / 1k\_10k / 10k\_100k / 100k\_plus                                                        |
| `transfers_180d` / `distinct_days_180d` / `months_180d` / `span_days_180d` | NUMBER           | The pair's trailing-window history, as of this transfer                                             |
| `avg_interval_days_180d` / `interval_cv_180d`                              | NUMBER           | Measured settlement cadence and its regularity                                                      |
| `is_established_relationship`                                              | BOOLEAN          | ≥ 3 distinct days ∧ ≥ 30-day span ∧ ≥ 2 calendar months — **the published-estimate gate**           |
| `settlement_pattern`                                                       | VARCHAR          | `new_relationship` / `developing` / `recurring_regular` (interval CV ≤ 0.5) / `recurring_irregular` |

<Note>
  **Cadence is measured, not assumed.** Among recurring pairs eligible under this model, observed transfer gaps are \~3–10 days — a statement about the captured population only. Present relationships by their measured cadence and ticket band rather than assuming invoice cycles.
</Note>

#### Published AP/AR-like estimate, monthly by ticket band

```sql theme={null}
SELECT chain, DATE_TRUNC('month', activity_date) AS month, ticket_band,
       SUM(usd_amount) AS usd
FROM stablecoins.intelligence.apar_flows
WHERE is_established_relationship
GROUP BY 1, 2, 3
ORDER BY 1, 2, 3;
```

#### One relationship's full history

```sql theme={null}
SELECT activity_date, usd_amount, transfers_180d,
       avg_interval_days_180d, settlement_pattern
FROM stablecoins.intelligence.apar_flows
WHERE chain = :chain AND from_address = :payer AND to_address = :payee
ORDER BY block_timestamp;
```

#### Top receiving entities of established settlement

```sql theme={null}
SELECT receiving_entity,
       COUNT(DISTINCT from_address) AS payers,
       SUM(usd_amount) AS usd
FROM stablecoins.intelligence.apar_flows
WHERE is_established_relationship AND receiving_entity IS NOT NULL
GROUP BY 1
ORDER BY usd DESC
LIMIT 25;
```