Policies
Your policies are the rules your institution sets for its transfers. Notabene evaluates every transfer against them to give a verdict: approve, flag or reject. Notabene runs the evaluation, but the rules, and so the decision, are yours.
What each verdict does
Approve
Your side is authorized once your requirements are met, with nothing for your team to do.
Flag
The transfer waits for a person on your team. The Inbox lists the flagged transactions under Transactions.
Reject
Your side rejects the transfer.
| Verdict | What happens |
|---|---|
| Approve | Your side is authorized once your requirements are met, with nothing for your team to do. |
| Flag | The transfer waits for a person on your team. The Inbox lists the flagged transactions under Transactions. |
| Reject | Your side rejects the transfer. |
The verdict is private, so the other institutions on the transfer see only your status, as Transfers explains. Your audit log records every verdict and keeps a flag even after a person resolves it.
Deciding by hand
On the transaction page, your team resolves the open flags together with one Approve or Reject, and decides the transfer itself with Authorize or Reject. Once the flags are approved, your side is authorized as soon as your requirements are met.
Authorizing while a flag or one of your requirements is still open overrides them. Before it does, the dashboard lists what will be overridden and asks for a reason, which is recorded. Your open requirements then read Skipped, while those the counterparty set for you stay open, and so does the hold on personal data.
How a verdict is reached
Every policy that applies to the transfer, such as one for a jurisdiction, a counterparty institution or an amount, gives a verdict. The strictest one wins, reject over flag over approve, and where none applies, a default decides:
- The default for its group, such as counterparty institutions.
- If that group has none, your general default, so that every transfer gets a verdict.
A new account’s general default is Flag, so every transfer waits for review until you change it in the dashboard, under Authorization Rules › Policies. You set a default for each group too: your customers, your own self-hosted wallet addresses, counterparty institutions, counterparty customers and counterparty wallets. Each group’s default is Flag, Reject or no policy.
Policies use the trust status you give a jurisdiction, an asset, a chain or an institution, and the results of the screening providers you connect, as Integrations explains.
Requirements
Separately from your policies, your requirements decide what must happen before your side can be authorized. You choose them as a preset in the dashboard, under Authorization Rules › Requirements, and Requirements explains each one.
| Preset | Requirements | Your side |
|---|---|---|
| Straight-through processing | Send, transmit and receive the Travel Rule data. | Is authorized as soon as your side is complete, without waiting for the counterparty. |
| Counterparty coordination | The same three, plus the counterparty’s confirmation of the address and its authorization. | Also waits for the counterparty, for up to 1 minute by default. |
| Preset | Requirements | Your side |
|---|---|---|
| Straight-through processing | Send, transmit and receive the Travel Rule data. | Is authorized as soon as your side is complete, without waiting for the counterparty. |
| Counterparty coordination | The same three, plus the counterparty’s confirmation of the address and its authorization. | Also waits for the counterparty, for up to 1 minute by default. |
Every requirement has a time-out after which it is skipped, so no transfer waits forever on a counterparty that does not answer, and every skip is recorded. You can add beneficiary name matching to either preset, and your team then confirms the name on each deposit.
What Notabene does and what you decide
| Stage | Notabene | Your institution |
|---|---|---|
| Before the transfer | Says whether the Travel Rule applies and which data it requires, as Data collection explains. | Collects that data from its customer. |
| The transfer | Finds the counterparty institution from the address. | Creates the transfer, or names the institution itself. |
| The decision | Runs your policies, and the screening providers you connect. | Sets the policies, and approves or rejects the transfers they flag. |
| The data | Sends and receives the Travel Rule data, and notifies your systems. | Confirms that a deposit address belongs to its customer. |
| The funds | Records the transaction hash on the transfer. | Sends the funds and gives Notabene the transaction hash. |
| Your customers | Does not screen your own customers against sanctions lists. | Screens its own customers. |
| Stage | Notabene | Your institution |
|---|---|---|
| Before the transfer | Says whether the Travel Rule applies and which data it requires, as Data collection explains. | Collects that data from its customer. |
| The transfer | Finds the counterparty institution from the address. | Creates the transfer, or names the institution itself. |
| The decision | Runs your policies, and the screening providers you connect. | Sets the policies, and approves or rejects the transfers they flag. |
| The data | Sends and receives the Travel Rule data, and notifies your systems. | Confirms that a deposit address belongs to its customer. |
| The funds | Records the transaction hash on the transfer. | Sends the funds and gives Notabene the transaction hash. |
| Your customers | Does not screen your own customers against sanctions lists. | Screens its own customers. |
Only your policies can flag a transfer, and your team cannot add a flag by hand. Every step is recorded in your audit log, which Security and status explains.
For your developers
Statuses and decisions in the API has the calls that decide a transfer, how your backend reads your policies, and where the verdict is recorded.
Updated 11 days ago