About Anchors

Every modern payment network has its own way of identifying where money should go. Pix in Brazil uses keys — a CPF number, a phone number, an email, or a random string. Other real-time payment schemes use similar concepts with different formats, different validation rules, and different protocols for registering and looking up these identifiers.

For any organization connecting to multiple payment networks, this creates a painful integration problem. Each network has its own key format, its own registration API, its own lookup protocol, and its own rules for what metadata must accompany a payment. Building and maintaining these translation layers across every connected network is expensive, error-prone, and slow to change.

Anchors solve this by providing a single abstraction for all of it. An anchor maps a simple, human-readable identifier — a phone number, email, national ID, or QR code — to a specific payment credential, like a bank account. The ledger handles everything else: how to resolve the identifier, which network format to use, how to route the payment to the right system.

One API for every payment network

The most immediate benefit of anchors is what they eliminate. Without anchors, connecting to a key-based payment network like Pix means building a dedicated integration that speaks Pix's specific protocol for key registration, key lookup, and payment routing. Connecting to a second network means building another integration with a different protocol. Each additional network multiplies the work.

With anchors, the integration looks the same regardless of the destination. Register the mapping once in the ledger, and the ledger speaks the right language to each connected system on your behalf. Whether the payment ends up on Pix, on a card network, on a mobile money platform, or on an internal core banking system — the API call is identical.

This is especially powerful for organizations operating across countries or payment schemes. A payment operator connecting banks in Brazil (Pix), Mexico (SPEI), and Colombia (Bre-B) would traditionally need three completely different addressing systems. With anchors, all three use the same registration, lookup, and routing model — only the bridge to each network differs.

Even within a single network, the complexity is significant. Bre-B, for example, relies on outdated ISO 8583 standards wrapped in verbose XML message formats, with cryptic error codes that require specialized knowledge to interpret and handle correctly. Integrating directly means your engineering team has to parse and generate these XML payloads, map dozens of obscure error codes to meaningful responses, and maintain all of that as the network evolves its specification. The ledger absorbs this entirely — the bridge translates between the ledger's clean JSON API and whatever legacy format the network speaks, so your team never touches XML, never parses network-specific error codes, and never rewrites integration logic when the network updates its spec.

Compare what it takes to register a QR code as a payment alias. On the network side, this might involve generating QR payloads according to EMVCo or a national specification, encoding account metadata in a specific binary format, and calling a registration endpoint with network-specific headers and authentication. With the ledger, it's a single API call:

POST /v2/anchors

{
  "data": {
    "wallet": "qr:98a2f1c0-4b3e-4d1a-9f2e-1a2b3c4d5e6f",
    "target": "svgs:42424242@mybank.co",
    "schema": "account",
    "symbol": "cop",
    "custom": {
      "name": "Melissa Ruiz",
      "documentType": "cc",
      "documentNumber": "814282133"
    }
  }
}

That's it. The QR code 98a2f1c0 now resolves to Melissa's savings account at mybank.co for COP payments. The bridge to Bre-B or Pix handles whatever XML, binary encoding, or network-specific ceremony the downstream system requires. Your application never sees it.

One identifier, multiple accounts

People don't have just one bank account. They have a savings account at one bank, a checking account at another, maybe a credit card and a mobile money wallet too. Key-based systems like Pix handle this by letting users register the same key (like a phone number) with different accounts for different purposes — but each network implements this differently.

Anchors handle this natively. A single identifier like a phone number can have multiple anchors, each pointing to a different payment credential and scoped to a specific currency or payment type.

For example, one phone number can simultaneously route:

• USD payments to a savings account at Bank A
• EUR payments to a checking account at Bank B
• Loyalty points to a digital wallet

When a payment arrives targeting that phone number, the ledger checks the currency and routes it to the right destination automatically. No custom routing logic, no middleware to maintain — the routing is configuration on the anchor itself.

Automatic onboarding

One of the most powerful features of anchors is how they handle first-time recipients. When someone sends money to a phone number that hasn't been registered yet, the ledger doesn't reject the payment. Instead, it holds the payment and triggers an onboarding flow.

The recipient gets a notification — an SMS for a phone number, an email for an email address — inviting them to choose which bank account should receive the funds. They open their banking app, select an account, and the payment completes automatically. From that point forward, all future payments to that phone number route to the registered account without any additional setup.

This means the payment network grows organically. Senders don't need to know whether the recipient is already registered. They send money to a phone number, and the system takes care of the rest — either routing immediately if the recipient is already onboarded, or guiding them through a seamless registration if they're new.

Full audit trail

Every anchor is a first-class ledger record — cryptographically signed, timestamped, and independently verifiable. When a payment fails because of an address issue, there's no need to dig through logs across multiple systems to figure out what went wrong. The anchor shows exactly what credential was registered, when it was registered, by whom, and every change that has been made since.

For compliance and operations teams, this is a significant improvement over the typical situation where address mappings live scattered across different network databases with inconsistent audit capabilities. The ledger provides a single, authoritative view of every identifier-to-credential mapping across all connected networks.

How anchors connect to other concepts

Anchors work in concert with the other ledger building blocks:

• Wallets hold the balances that anchors point to — the anchor maps the human-readable identifier to the wallet that receives funds
• Intents use anchors at runtime — when a payment targets an alias, the ledger resolves it through anchors to find the destination wallet
• Bridges connect to external systems where the actual accounts live — anchors tell the ledger which account, bridges tell it how to reach the account
• Policies control who can register, update, or look up anchors — ensuring only authorized participants can modify address mappings

What's next

See About Intents to understand how payments use anchors at runtime, or jump to Collect a Payment to try it hands-on.