> ## 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.

# Payments Pipeline Overview

> Real-world payment tracking and classification for stablecoin transfers

## What is the Payments Pipeline?

The Payments Pipeline is Allium's comprehensive framework for identifying, classifying, and analyzing **real-world payments** across blockchain networks. It transforms raw stablecoin transfer data into actionable insights about payment behavior, distinguishing genuine economic activity from noise.

The pipeline is delivered through the **`stablecoins.intelligence`** schema as a set of per-transfer tables enriched with registry metadata, wallet typing, an organic-activity taxonomy, and granular payment categories.

<Note>
  **Migrating from `crosschain.stablecoin`?** The pipeline moved to the `stablecoins.intelligence` schema. Table mapping:

  | Legacy `crosschain.stablecoin.*` | New `stablecoins.intelligence.*`                                                                                                                    |
  | -------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- |
  | `filtered_transfers`             | `enriched_transfers` (filter on `is_adjusted_volume`)                                                                                               |
  | `transaction_classification`     | `organic_activity_classification`                                                                                                                   |
  | `payment_categorization`         | `payment_categorization`                                                                                                                            |
  | `wallet_classification`          | wallet typing is now embedded in `organic_activity_classification` (`from_wallet_type` / `to_wallet_type`, `from_balance_tier` / `to_balance_tier`) |

  The standalone adjusted-volume table is replaced by the `is_adjusted_volume` flag on `enriched_transfers`.
</Note>

## Core Concept: Adjusted Volume

**Adjusted Volume** represents stablecoin transaction volume after filtering out non-organic activity. This provides a more accurate measure of real economic utility by removing:

* **CEX (Centralized Exchange) activity** - Internal exchange operations and market making
* **DeFi Protocol activity** - Smart contract interactions, liquidity provision, and automated trading
* **Infrastructure activity** - Bridge contracts, multisigs, and other operational addresses

In the new schema, adjusted volume is exposed as the **`is_adjusted_volume`** boolean on `enriched_transfers` — filter `WHERE is_adjusted_volume` for economically meaningful activity.

### Why Adjusted Volume Matters

Raw blockchain volume includes significant noise that inflates the actual payment activity:

| Metric                      | Raw Volume | Adjusted Volume |
| --------------------------- | ---------- | --------------- |
| **Includes CEX**            | ✅ Yes      | ❌ No            |
| **Includes DeFi**           | ✅ Yes      | ❌ No            |
| **Includes Infrastructure** | ✅ Yes      | ❌ No            |
| **Real-world payments**     | ✅ Yes      | ✅ Yes           |
| **Reflects true utility**   | ❌ No       | ✅ Yes           |

## Pipeline Architecture

```mermaid theme={null}
graph TD
    A[Raw Stablecoin Transfers]
    B[Enriched Transfers + Adjusted Volume]
    C[Organic Activity Classification]
    D[Payment Categorization]

    A --> B
    B --> C
    C --> D
```

| Step                                   | Description                                                                                                                                                                               | Table                             |
| -------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------- |
| **1. Raw Stablecoin Transfers**        | All chains, all stablecoins, all addresses                                                                                                                                                | source feeds                      |
| **2. Enriched Transfers**              | Per-transfer registry metadata, address labels, flow categories, activity taxonomy, and the `is_adjusted_volume` gate                                                                     | `enriched_transfers`              |
| **3. Organic Activity Classification** | Wallet typing (Consumer / Business / Institutional) and transaction intent (Real-World Payment / Investment-Trade / Store-as-Value) with wallet-type combinations (C2C, C2B, B2C, B2B, …) | `organic_activity_classification` |
| **4. Payment Categorization**          | Granular purpose: P2P, Retail, Payroll, B2B, etc. (Real-World Payment transfers only)                                                                                                     | `payment_categorization`          |

## How Organic Activity Classification Works

Once non-organic activity is filtered out (see [Adjusted Volume](/historical-data/payments/adjusted-volume)), each remaining transfer is classified along two axes — **who** is transacting (wallet types) and **why** (transaction intent). This is the `organic_activity_classification` stage.

### Wallet typing (who)

Every sender and receiver is assigned a wallet type from a daily behavioral profile:

| Wallet type       | Profile                                                                                                         |
| ----------------- | --------------------------------------------------------------------------------------------------------------- |
| **Consumer**      | Retail-sized balances and tickets, P2P-style activity                                                           |
| **Business**      | Commercial throughput — sustained volume **backed by a real working balance**                                   |
| **Institutional** | Treasury / protocol / market-maker scale: very high volume, large or multi-token balances, multi-chain presence |

Typing combines an address's **balance tier**, **30-day volume**, **average ticket size**, **activity cadence**, and entity labels. A key guardrail: a wallet must hold a genuine working stablecoin balance to be typed **Business** — high-velocity wallets that move large volume while holding near-zero balance (e.g. routing / pass-through addresses) are treated as Consumer, not Business. This prevents over-counting business-to-business volume.

Sender × receiver types produce the **`wallet_type_combination`** (C2C, C2B, B2C, B2B, plus institutional pairs I2C, I2B, I2I, C2I, B2I).

```mermaid theme={null}
graph LR
    A[Balance tier]:::in --> T{Wallet typing}
    B[30-day volume]:::in --> T
    C[Avg ticket size]:::in --> T
    D[Activity cadence]:::in --> T
    E[Entity labels]:::in --> T
    G[Working-balance guardrail]:::in --> T
    T --> X[Consumer]
    T --> Y[Business]
    T --> Z[Institutional]
    classDef in fill:#eef,stroke:#88a;
```

### Transaction intent (why)

A prioritized rule stack assigns each transfer a `transaction_type` (first match wins):

| Intent                 | Assigned when                                                                                                                                                                       | Examples                                                     |
| ---------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------ |
| **Investment/Trade**   | Large business-to-business transfers above the payment band, very high average ticket sizes, short-term round-trip ("wash"/routing) patterns, or institutional/exchange-style flows | Treasury settlement, market-making, large B2B value transfer |
| **Store as Value**     | Receiver accumulates an inflow that is large relative to its balance and typical ticket size, with little subsequent outflow                                                        | Savings, balance build-up                                    |
| **Real-World Payment** | A consumer or business is involved and the amount sits within payment-sized bands below the large-ticket trade threshold                                                            | Remittance, retail purchase, payroll, supplier payment       |
| **Unclassified**       | No rule matched with sufficient confidence                                                                                                                                          | Ambiguous flows                                              |

```mermaid theme={null}
graph TD
    S[Organic transfer] --> Q1{Large B2B / high avg ticket / short-term pair / institutional?}
    Q1 -->|yes| IT[Investment/Trade]
    Q1 -->|no| Q2{Inflow large vs receiver balance &amp; typical ticket, low outflow?}
    Q2 -->|yes| SV[Store as Value]
    Q2 -->|no| Q3{Consumer/business involved &amp; within payment band?}
    Q3 -->|yes| RWP[Real-World Payment]
    Q3 -->|no| U[Unclassified]
    RWP --> PC[payment_categorization]
```

Because Investment/Trade rules run **before** payment rules, large speculative and treasury flows are removed before the payment mix is computed — so `payment_categorization` reflects genuine real-world payments rather than large-ticket value transfer. Only transfers typed **Real-World Payment** flow into `payment_categorization` for granular purpose labeling.

## Tables

The pipeline produces three primary tables in the **`stablecoins.intelligence`** schema:

| Table Name                                                                                                                       | Description                                                                                                                            |
| -------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
| [`stablecoins.intelligence.enriched_transfers`](/historical-data/payments/tables#1-enriched_transfers)                           | Per-transfer intelligence: registry metadata, activity classification, directional flow categories, and the `is_adjusted_volume` flag. |
| [`stablecoins.intelligence.organic_activity_classification`](/historical-data/payments/tables#2-organic_activity_classification) | Sender/receiver wallet types, balance tiers, transaction intent, and wallet-type combination.                                          |
| [`stablecoins.intelligence.payment_categorization`](/historical-data/payments/tables#3-payment_categorization)                   | Core payment category and payment purpose for Real-World Payment transfers.                                                            |

<Note>
  **Access tiers.** The full-history tables above are **gated** (available to entitled customers). Each is also published as a rolling **last-30-days** view that is broadly shared — start with these for evaluation and rolling analytics:

  * `stablecoins.intelligence.enriched_transfers_last_30d`

  Same schema as the full table, filtered to `block_timestamp >= dateadd('day', -30, current_timestamp())`. Contact Allium for full-history access.
</Note>

## Use Cases

### 1. Payment Volume Analytics

Track real-world stablecoin payment adoption across chains (adjusted volume):

```sql theme={null}
SELECT
  chain,
  token_symbol,
  DATE_TRUNC('week', block_timestamp) AS week,
  SUM(usd_amount) AS weekly_adjusted_volume
FROM stablecoins.intelligence.enriched_transfers
WHERE is_adjusted_volume
GROUP BY 1, 2, 3
ORDER BY 3 DESC;
```

### 2. Payment Type Distribution

Understand how stablecoins are being used:

```sql theme={null}
SELECT
  transaction_type,
  COUNT(*) AS transfer_count,
  SUM(usd_amount) AS total_volume_usd
FROM stablecoins.intelligence.organic_activity_classification
GROUP BY 1;
```

### 3. Payment Purpose Breakdown

Analyze granular payment categories:

```sql theme={null}
SELECT
  core_payment_category,
  payment_purpose,
  COUNT(*) AS payment_count,
  SUM(usd_amount) AS total_usd
FROM stablecoins.intelligence.payment_categorization
GROUP BY 1, 2
ORDER BY 4 DESC;
```

### 4. Wallet-Type Segmentation

Profile payment activity by counterparty type:

```sql theme={null}
SELECT
  wallet_type_combination,
  COUNT(*) AS transfer_count,
  SUM(usd_amount) AS total_volume_usd
FROM stablecoins.intelligence.organic_activity_classification
WHERE transaction_type = 'Real-World Payment'
GROUP BY 1
ORDER BY 3 DESC;
```

## Next Steps

<CardGroup cols={2}>
  <Card title="Adjusted Volume Methodology" icon="filter" href="/historical-data/payments/adjusted-volume">
    Learn how we calculate adjusted volume and filter non-organic activity
  </Card>

  <Card title="Table Reference" icon="table" href="/historical-data/payments/tables">
    Detailed schema documentation for all pipeline tables
  </Card>
</CardGroup>