Docs
PATH CROSSWAY
The external-network resolution layer. Which outside registry knows a key, which participant holds it, where to send, and whether the name matches — without PATH becoming a directory of other networks' accounts.
LIVE — specified in PIP-0014,
implemented in @pathprotocol/sdk 0.3.0 and the API MCP server. The API is operated by
Path Global, a private company, and access is closed: it is granted on request at
pathglobal.finance. Registries open one at a time.
What it is for
PATH FINDER reaches destinations held by PATH members. A great many destinations are not. They live in the registries of other networks: a Pix key in the Brazilian DICT, an alias in PI-SPI, a VPA in UPI, an IBAN behind SEPA Verification of Payee.
A PATH address may declare that its subject receives on one of those networks. The PATH resolver stops there: it states what the holder declared. A payer that wants to go further — confirm that the key exists in the external registry, learn which participant holds it, check the name before sending — leaves PATH. Crossway is how it does so through one interface.
PATH resolves PATH participants. Crossway resolves destinations that live on other networks.
What it is not
| Crossway is not | Because |
|---|---|
| A rail | No value moves through it. Payment executes and settles on the external network |
| A pillar | It adds no object to ID, ADDRESS, REQUEST, CONNECT or SETTLEMENT. It is transverse, like FINDER |
| A directory of external accounts | It stores no registry entry. Every answer is read from the registry at the time of the call |
| A resolver answer | A Crossway answer reports what a registry holds. It is nobody's terms, and carries no standing and no commitment |
| A profile lookup | It never returns a subject's other identifiers. See what it never returns |
PATH standardises the interface. The registry stays the authority on its own entries, and the connector that reads it stays responsible for the confidentiality of what it reads.
The two stages
- 01DiscoveryWhich external registry can know this key?From the key’s form and the connector register
- 02SonarDoes that registry hold it, and at which participant?The registry answers, through an attested connector
- 03ResolverWhere to send, on which rail, in which currency?A destination in the rail’s profile
- 04Payee checkIs it the person I think?Match, close match, no match — never a profile
Crossway Discovery answers which external registry can know this key. Crossway Finder is the same composition as PATH FINDER: SONAR then RESOLVER, applied to an external registry. The payee check closes the sequence, as it does in PATH FINDER.
Where it starts
From either of two places.
Crossway never reads a PATH address itself. In case A the caller resolves the address with PATH FINDER first; in both cases what reaches Crossway is an external key. That keeps the two layers apart: a PATH answer is a member's signed statement, a Crossway answer is a registry's.
Discovery
Which external registry can know this key?
Answered from the form of the key and the register of connectors, without querying any
registry. A +55 phone number can be a Pix key. A +225 phone number can be a PI-SPI alias. An IBAN
with a SEPA country code can be verified under SEPA Verification of Payee.
{
"kind": "crossway.discovery",
"key_type": "phone",
"candidates": [
{ "registry": "pix.dict", "rail": "pix", "zone": "BR", "operations": ["sonar", "resolver", "payee_check"] }
]
}Discovery MUST NOT query a registry. A candidate means this registry can hold keys of this form. It never means this key is there.
Crossway SONAR
Does this registry hold this key, and which participant holds it?
The connector queries the registry and returns what the registry returned: found or not, and the participant holding the key — an ISPB for Pix, a participant code for PI-SPI.
{
"kind": "crossway.sonar",
"registry": "pix.dict",
"key_hash": "c41a8f2b…",
"found": true,
"participant": { "id": "12345678", "name": "Example Bank S.A." },
"connector": "pathglobal-br-01",
"attestation": "att_9kq3m7vx2pf8",
"nonce": "9f2c41a8b7e3",
"signed_at": "2026-10-05T10:00:00Z",
"kid": "pg_crossway_2026_01",
"signature": "…"
}Constant shape. A key that is unknown and a key the caller may not see MUST produce the same response, as in PATH SONAR.
Crossway RESOLVER
Where to send, on which rail, in which currency?
{
"kind": "crossway.resolution",
"registry": "pix.dict",
"rail": "pix",
"asset_type": "fiat",
"asset_code": "BRL",
"participant": { "id": "12345678" },
"destination": { "key_type": "phone", "key": "+5511987654321", "account_type": "CACC" },
"registry_reference": "dict-req-7fk2m9pq",
"expires_at": "2026-10-05T10:05:00Z",
"connector": "pathglobal-br-01",
"attestation": "att_9kq3m7vx2pf8",
"signed_at": "2026-10-05T10:00:00Z",
"kid": "pg_crossway_2026_01",
"signature": "…"
}rail takes an identifier from the rail register (pi-spi is added by
PIP-0014). destination follows the
beneficiary format of that rail's profile: what the payer's provider needs to execute,
and nothing more. registry_reference is the registry's own reference for the read, kept for audit.
expires_at is short. An external registry entry can move between participants at any time; a
resolution is a reading, not a pledge. Read it again rather than cache it.
The payment itself is then initiated by the payer's own provider on the external rail. Crossway is not in that path.
Payee check
Is the destination the person I think?
The external networks already answer this, each in its own form: Pix shows the registered name with a partially masked tax number, SEPA Verification of Payee returns match / close match / no match. Crossway maps them onto the same two modes as the PATH payee check.
{
"kind": "crossway.payee_check",
"registry": "pix.dict",
"mode": "verify",
"result": "close_match",
"display_name": "Alice M.",
"connector": "pathglobal-br-01",
"attestation": "att_9kq3m7vx2pf8",
"signed_at": "2026-10-05T10:00:00Z",
"kid": "pg_crossway_2026_01",
"signature": "…"
}| Mode | The caller sends | The answer carries |
|---|---|---|
verify | The name it expects | match, close_match, no_match or unavailable. On close_match, the masked registered name |
display | Nothing more | The masked name, as the registry permits it to be shown |
A registry that offers less is reported as less. Where the external scheme offers no name check,
the answer is unavailable, never an inference.
What Crossway never returns
| Returned | Never returned |
|---|---|
| Which registry can hold a key | Whether a key exists, from Discovery |
| Which participant holds a key | The account holder's full record |
| Where to send, in the rail's format | Any other identifier of theirs — phone, email, tax number in the clear |
| A name check, or a masked name | A full name in display mode |
| A signature and an attestation | A balance, a history, a KYC level |
A key is a way to pay someone. It is not a way to find out who they are.
Trust: attested connectors
A Crossway answer is accepted on two signatures, never on the connector's alone.
A connector is the component that reads one registry, under the access of an authorised participant of that network or of a partner holding such access. Each connector holds a connector attestation, signed by Path Global:
{
"type": "crossway.connector_attestation",
"reference": "att_9kq3m7vx2pf8",
"connector": "pathglobal-br-01",
"registry": "pix.dict",
"operations": ["sonar", "resolver", "payee_check"],
"access": "authorised_participant",
"issued_at": "2026-10-01T00:00:00Z",
"expires_at": "2027-04-01T00:00:00Z",
"status": "active",
"kid": "pg_root_2026_01",
"signature": "…"
}A caller verifies two signatures: the answer, under the connector's key, and the attestation it names, under Path Global's published key. The rules of Trust apply unchanged: Ed25519, RFC 8785 canonical bytes, revocation checked at read. An answer whose attestation is expired, revoked, or does not cover that registry and that operation is discarded.
Normative rules
No central copy
A connector MUST NOT store registry entries beyond the lifetime of the answer that carried them. Crossway is a pass-through to the registry, not a mirror of it.
Limits
Raw keys are accepted, and the limits are stricter than in PATH SONAR.
- Server-side only. Crossway MUST be called from the client's server, with its Path Global credential. Never from an end-user application.
- Bound to a payment. SONAR, RESOLVER and payee check calls carry
purpose: payment_preparation. A key is looked up when a payment is being prepared, never when an address book is imported. - No batch. There is no batch endpoint.
- Budgets. Each client holds a per-registry allowance, set by Path Global.
- The registry's rules prevail. Where a registry imposes its own limits — the DICT does — the stricter of the two applies.
Logging
Every call is recorded against the calling client, with the key hashed, never in the clear. Retention is published by Path Global per registry.
The external scheme's rules prevail
Crossway does not widen what a registry discloses. If a scheme forbids showing a field, Crossway does not show it, whatever the caller asks.
Access
The Crossway API is operated by Path Global. Access is closed and granted per client and per registry, after review. Endpoints are documented in the API reference.