These are the terms you meet when you integrate with Notabene, each with the API field it appears as where there is one.
| Term | What it means |
|---|
| Customer | A person or an organization you have a direct relationship with. In a transfer, your customer is the originator of a withdrawal or the beneficiary of a deposit. Customers explains how to register them. |
| Originator | The customer who sends the funds, a customer of the sending institution. On a transfer, the field is originator. |
| Beneficiary | The customer who receives the funds, a customer of the receiving institution. On a transfer, the field is beneficiary. |
| Institution | An organization that sends or receives transfers for its customers, such as an exchange or a bank. Each has a DID. |
| Counterparty institution | The institution on the other side of a transfer. On a transfer, counterparty holds its DID. |
| Custodian | The institution that holds an address in custody. A discover answer gives it as custodian, the same as owner when the owner holds its own addresses. |
| Self-hosted wallet | A wallet whose keys the person holds themselves, with no institution behind it. |
| Hosted wallet | A wallet whose keys an institution or a wallet provider holds for the person. |
| Term | What it means |
|---|
| Customer | A person or an organization you have a direct relationship with. In a transfer, your customer is the originator of a withdrawal or the beneficiary of a deposit. Customers explains how to register them. |
| Originator | The customer who sends the funds, a customer of the sending institution. On a transfer, the field is originator. |
| Beneficiary | The customer who receives the funds, a customer of the receiving institution. On a transfer, the field is beneficiary. |
| Institution | An organization that sends or receives transfers for its customers, such as an exchange or a bank. Each has a DID. |
| Counterparty institution | The institution on the other side of a transfer. On a transfer, counterparty holds its DID. |
| Custodian | The institution that holds an address in custody. A discover answer gives it as custodian, the same as owner when the owner holds its own addresses. |
| Self-hosted wallet | A wallet whose keys the person holds themselves, with no institution behind it. |
| Hosted wallet | A wallet whose keys an institution or a wallet provider holds for the person. |
| Term | What it means |
|---|
| DID | Short for Decentralized Identifier. An institution’s DID is its identity in the network. |
| did:web | A DID resolved from a domain: did:web:example.com:pt reads its DID document at https://example.com/pt/did.json. |
| did:pkh | A DID made from a blockchain address. It names a self-hosted wallet, for example as beneficiary_id. |
| CAIP-10 | An address with its chain, such as eip155:1:0x5aAeb6053F3E94C9b9A09f33669435E7Ef1BeAed. It is used for settlement_address and source_address. |
| CAIP-19 | An asset on its chain, such as eip155:1/slip44:60 for ETH. asset comes back in this form. |
| CAIP-220 | An on-chain transaction, such as eip155:1:tx/0x7d3c9e1f0a2b4c6d8e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d. It is used for settlement_id. |
| IVMS-101 | The standard data model for the people in a transfer: names, addresses, identifiers and account numbers. In a profile, the field is ivms. |
ref | Your own UUID for a transfer. Notabene never creates two transfers with the same ref, so a retry is safe. |
| Term | What it means |
|---|
| DID | Short for Decentralized Identifier. An institution’s DID is its identity in the network. |
| did:web | A DID resolved from a domain: did:web:example.com:pt reads its DID document at https://example.com/pt/did.json. |
| did:pkh | A DID made from a blockchain address. It names a self-hosted wallet, for example as beneficiary_id. |
| CAIP-10 | An address with its chain, such as eip155:1:0x5aAeb6053F3E94C9b9A09f33669435E7Ef1BeAed. It is used for settlement_address and source_address. |
| CAIP-19 | An asset on its chain, such as eip155:1/slip44:60 for ETH. asset comes back in this form. |
| CAIP-220 | An on-chain transaction, such as eip155:1:tx/0x7d3c9e1f0a2b4c6d8e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d. It is used for settlement_id. |
| IVMS-101 | The standard data model for the people in a transfer: names, addresses, identifiers and account numbers. In a profile, the field is ivms. |
ref | Your own UUID for a transfer. Notabene never creates two transfers with the same ref, so a retry is safe. |
| Term | What it means |
|---|
| Transaction | Any movement of value Notabene tracks. A transfer is one kind of transaction. |
| Transfer | A crypto transaction between two customers, through their institutions. |
| Travel Rule | The rule that makes institutions exchange information about the originator and the beneficiary of a transfer above a threshold. |
| Threshold | The amount above which the Travel Rule applies in a jurisdiction. travel_rule_applies on a transfer says whether it does. |
| Travel Rule data | The information about the originator and the beneficiary that the two institutions exchange. It is separate from the transfer and from the settlement. |
| Settlement | The movement of the funds on chain. Its transaction hash is recorded as settlement_id. |
| My Status | Where your institution stands on a transfer: Pending, Authorized, Rejected or Canceled. Each institution has its own. |
| Transaction status | Where the transfer stands across every institution and the settlement, in the status field. Statuses lists every value. |
ReadyToSettle | Every institution has authorized the transfer. The originator’s institution can send the funds. |
SettledIncompleteAuthorization | The funds moved while an institution had not authorized the transfer yet. It becomes Settled once it has. |
requires_action | A field on a transfer that is true while something waits on you. |
| Term | What it means |
|---|
| Transaction | Any movement of value Notabene tracks. A transfer is one kind of transaction. |
| Transfer | A crypto transaction between two customers, through their institutions. |
| Travel Rule | The rule that makes institutions exchange information about the originator and the beneficiary of a transfer above a threshold. |
| Threshold | The amount above which the Travel Rule applies in a jurisdiction. travel_rule_applies on a transfer says whether it does. |
| Travel Rule data | The information about the originator and the beneficiary that the two institutions exchange. It is separate from the transfer and from the settlement. |
| Settlement | The movement of the funds on chain. Its transaction hash is recorded as settlement_id. |
| My Status | Where your institution stands on a transfer: Pending, Authorized, Rejected or Canceled. Each institution has its own. |
| Transaction status | Where the transfer stands across every institution and the settlement, in the status field. Statuses lists every value. |
ReadyToSettle | Every institution has authorized the transfer. The originator’s institution can send the funds. |
SettledIncompleteAuthorization | The funds moved while an institution had not authorized the transfer yet. It becomes Settled once it has. |
requires_action | A field on a transfer that is true while something waits on you. |
| Term | What it means |
|---|
| Policy | A rule your institution sets that decides whether a transfer is approved, flagged for review or rejected. |
| Flag | Your policies’ verdict that holds a transfer for a person on your team to review: a step on the way, not an outcome. There is no Flagged status, and the transfer reads requires_action: true while it waits. |
| Override | Approving a transfer while a flag or a requirement is still open, with force-authorize and a reason that is recorded. |
| Requirement | One obligation on a transfer that an institution must meet, such as confirming an address. Its status is Pending, Satisfied, Partially satisfied, Skipped, Rejected or N/A, as Statuses explains. Every skip is recorded. |
| Your side | Your institution’s part of a transfer: your status, your policies’ verdict and the requirements you must meet. |
| Requirements preset | The setting that decides whether your side also waits for the counterparty. With straight-through processing it does not, and with counterparty coordination it waits for the counterparty’s address confirmation and authorization, for up to 1 minute by default. |
| Address confirmation | The receiving institution confirms that its customer controls the receiving address. It is kept, so later transfers to that address are confirmed by themselves. The sender’s personal data is only sent after it. As a requirement, it is WalletAddressConfirmation. |
| Proof of ownership | Evidence that a customer controls a self-hosted wallet address. Wallets explains how to record it. |
| Presentation | How the originator’s personal data travels to the counterparty institution once the address is confirmed. |
| Term | What it means |
|---|
| Policy | A rule your institution sets that decides whether a transfer is approved, flagged for review or rejected. |
| Flag | Your policies’ verdict that holds a transfer for a person on your team to review: a step on the way, not an outcome. There is no Flagged status, and the transfer reads requires_action: true while it waits. |
| Override | Approving a transfer while a flag or a requirement is still open, with force-authorize and a reason that is recorded. |
| Requirement | One obligation on a transfer that an institution must meet, such as confirming an address. Its status is Pending, Satisfied, Partially satisfied, Skipped, Rejected or N/A, as Statuses explains. Every skip is recorded. |
| Your side | Your institution’s part of a transfer: your status, your policies’ verdict and the requirements you must meet. |
| Requirements preset | The setting that decides whether your side also waits for the counterparty. With straight-through processing it does not, and with counterparty coordination it waits for the counterparty’s address confirmation and authorization, for up to 1 minute by default. |
| Address confirmation | The receiving institution confirms that its customer controls the receiving address. It is kept, so later transfers to that address are confirmed by themselves. The sender’s personal data is only sent after it. As a requirement, it is WalletAddressConfirmation. |
| Proof of ownership | Evidence that a customer controls a self-hosted wallet address. Wallets explains how to record it. |
| Presentation | How the originator’s personal data travels to the counterparty institution once the address is confirmed. |
| Term | What it means |
|---|
| API credential | A client ID and a client secret for your backend, created in the dashboard. Authentication explains it. |
| Access token | What your backend sends on every call, in the Authorization header. It lasts 24 hours. |
| Delegate token | A token your backend requests for one customer, so your app can call the routes under /api/v1/customers/{customer}/ for them. It lasts 1 hour. |
| Node | The Notabene service that runs your institution’s side: it holds your transfers, keys and policies, and exchanges messages with other institutions’ nodes. |
| Webhook | A message Notabene sends to your endpoint when something happens on a transfer. Webhooks lists them. |
| Term | What it means |
|---|
| API credential | A client ID and a client secret for your backend, created in the dashboard. Authentication explains it. |
| Access token | What your backend sends on every call, in the Authorization header. It lasts 24 hours. |
| Delegate token | A token your backend requests for one customer, so your app can call the routes under /api/v1/customers/{customer}/ for them. It lasts 1 hour. |
| Node | The Notabene service that runs your institution’s side: it holds your transfers, keys and policies, and exchanges messages with other institutions’ nodes. |
| Webhook | A message Notabene sends to your endpoint when something happens on a transfer. Webhooks lists them. |
| Term | What it means |
|---|
| VASP | Older pages and regulations call an institution a VASP, a virtual asset service provider. |
| Agent | The protocol’s word for an institution acting in a transfer. In the API, a transfer’s agents list its institutions, each with the role VASP, and other entries such as the settlement address. |
| Unhosted or non-custodial wallet | Other names for a self-hosted wallet. |
| Transaction hash | What the API calls settlement_id, as CAIP-220 or a bare hash on the asset’s chain. |
| Term | What it means |
|---|
| VASP | Older pages and regulations call an institution a VASP, a virtual asset service provider. |
| Agent | The protocol’s word for an institution acting in a transfer. In the API, a transfer’s agents list its institutions, each with the role VASP, and other entries such as the settlement address. |
| Unhosted or non-custodial wallet | Other names for a self-hosted wallet. |
| Transaction hash | What the API calls settlement_id, as CAIP-220 or a bare hash on the asset’s chain. |
