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

# Authorization and counterparties

> Enterprise counterparty consent before settlement — what exists today and what is on the roadmap.

## Why authorization exists

A blockchain transfer has no “hold” or “ask the recipient first.” Enterprise payments need counterparty consent before value moves — especially when the recipient is a registered merchant or beneficiary PSP.

## The handshake (roadmap)

Originator PSP and counterparty PSP coordinate through Atum:

1. Originator: my customer wants to pay your customer this amount on these terms
2. Counterparty: accepted — this merchant and amount are allowed
3. Compliance and policy checks run on both sides during this step

## What exists today

On **public testnet**, you can submit and settle payments **without** a separate counterparty authorization step for basic integration.

Counterparty authorization APIs exist in the protocol (`POST /v1/payments/authorizations`) and are exercised in internal environments — not required for the CLI quickstart.

## Custodial vs self-custodial

| Model              | Pattern                                                                                                  |
| ------------------ | -------------------------------------------------------------------------------------------------------- |
| **Custodial PSP**  | User taps send; PSP orchestrates quote and settlement behind one API                                     |
| **Self-custodial** | User signs intent directly; authorization semantics differ — supported, not the current product priority |

## Identity is a different question

[Atum ID](/get-started/identity/overview) answers *who is acting* (and what has been attested about them). Authorization answers *whether this payment may proceed* — funds, policy, and, when enabled, counterparty consent.

A Known to Atum credential does not authorize a transfer. A signed payment request does not, by itself, replace identity credentials.

Choosing which settlement providers may fulfill a payment is also not this handshake. That is an optional identity list on the [payment request](/get-started/concepts/payment-intent#settlement-providers-on-this-payment), set by the originator. Recipient consent (this page) is a separate step.

## Relation to settlement

When enabled, authorization completes **before** settlement is initiated. Settlement follows the model in [Atum payment lifecycle](/get-started/overview/how-an-atum-payment-works).

## Next steps

* [Who owns what](/get-started/support/who-owns-what)
* [Policy enforcement](/get-started/concepts/policy-enforcement) — identity lists vs credential-type trust
* [Payment request](/get-started/concepts/payment-intent#settlement-providers-on-this-payment) — how you set the identity list
* [What is Atum ID?](/get-started/identity/overview)
* [Know Your Agent](/get-started/identity/know-your-agent)
* [Participants](/get-started/concepts/participants)