Bank rail

Read a token page#

A token page opens with the token's name and symbol, the bank, its state, the reserve account and how credits match. Each tab has its own address, so you can link to it. A live or suspended connection with a token link opens on “Payments”. A draft connection, or one with no token link, opens on “Settings”, which is the only tab it shows, and a link to another tab lands there.

The page has five tabs:

• Payments
• Clients
• Cash-outs
• Reconciliation
• Settings, which holds the logon password, the reserve token, the “Rail wallet” card, the “AML screening” block, the payout deadline, the settlement window and the “Payment cut-off” with its calendar and time zone. The two CompIDs are in its collapsed “Technical” section, because you only need them when you configure the bank's side of the FIX session.

The title row carries Edit payment schedule and “Suspend”, or “Activate connection” on a draft or suspended connection.

Set the credit threshold and the mint cap#

On “Settings”, the reserve token card shows the limits in the token's units. Lowering a value saves at once under wallet verification. Raising or clearing it opens a request that shows the old and the new value and when it expires.

• Credit threshold is the amount above which a minted credit waits for a second manager.
• Mint cap shows only in “Supply delegate” mode and limits what the rail wallet may mint. Under the field, the card shows how much the rail wallet has minted minus what it burned, as of the last indexed block. When that amount differs from the cap, the card suggests it as a new cap and a button fills the field with it. Set the cap higher to leave room for new credits.
• Daily report cut-off is a time and a time zone that “Edit payment schedule” also sets: a balance report sent after it belongs to the next day's reconciliation.

A different bank rail manager selects “Approve” or “Reject” on a pending request, and the other limit stays locked until the request is decided. The manager who opened the request sees a note instead of “Approve” and “Reject”.

Set when the bank takes payments#

The connection names a holiday calendar, a time zone and a payment cut-off. A new connection starts on the ADGM business days calendar with the UAE public holidays and the Asia/Dubai time zone, with no cut-off.

To change them, open the connection and select Edit payment schedule. A change applies to new cash-outs only.

• A day is a business day unless the calendar closes it or it is a Saturday or Sunday. With No holiday calendar, every day is a business day.
• A cash-out approved at or after the cut-off, or on a closed day, goes on the next business day. Its row shows the new value date and says it is queued for the next opening.
• The rail sends no new instruction while the bank is closed. A day closed after a cash-out was queued moves its value date to the next open day.
• The payout deadline and the settlement window count business time on this calendar.

Screen payments with your AML provider#

DALP sends every confirmed bank credit that matched a client, and every cash-out before its payment instruction goes out, to the AML provider the connection names. The AML screening block on “Settings” shows the provider ID, the level and whether the payer account is checked, with “Edit settings” and “Export results”.

1. Select Edit settings. Enter the provider ID of the AML provider linked in your compliance settings, as a UUID, and the level name the provider uses for fiat transactions. Leave the level empty to use the provider's default, and leave the provider empty to turn provider screening off.
2. Choose whether to Check the payer account of every credit. It is on for every connection until you turn it off. A credit from an account the client has not had approved waits until a manager retries it and a second manager approves the mint. The check needs no provider.
3. Select Save settings. If another manager saved the settings after you opened the page, DALP refuses the change as stale. Open the page again and repeat it.

A credit the AML check rejects or holds, or whose payer account is not one of the client's approved accounts, shows Parked with that reason and the account it was paid from. Nothing is minted. Select “Retry”, then another bank rail manager approves the mint, even while the “Bank rail” approval row is off. A cash-out the check rejects or holds shows “Waiting for approval” and sends no payment instruction until a manager other than the system approves it. Rejecting the approval releases the cash-out.

To hand the results to your compliance team, select Export results, choose a “From” and a “To” date and select “Download CSV”. The file lists every screening created in that range, with the payer, the verdict, the score, the payer check and who released it. The dates cover whole days in UTC. Leave “From” empty to start at the first screening, or “To” empty to include every screening up to the download. “From” and “To” refuse a typed day that does not exist, such as 2026-02-30, and show a message under that field. “Download CSV” stays unavailable until you correct or clear that date. It also stays unavailable while “To” comes before “From”.

Follow payments#

Open the token and select Payments. The table lists every credit the bank reported, newest first, with the value date, the amount, the client it matched, or the payer's reference when none matched, its status, the “Bank transaction” and the mint transaction once it settles. A copy button beside the bank transaction and the mint transaction copies the whole value. Filter the list by status. The page refreshes every 10 seconds, and “Show more” loads older credits.

A credit that matched a client and passed screening shows “Minted”. When the token link has a credit threshold and the “Bank rail” approval row is on, every credit that exceeds it shows “Waiting for mint approval” first, including a credit that matched no client. With the row off, the credit mints at once. DALP adds the client's credits of the last 24 hours to a matched credit before it compares. A bank rail manager selects Approve or “Reject”. Once approved, the credit mints to the client, or parks with a reason. A rejected or expired request parks it with the reason “Another manager did not approve the mint”. The bank rail API guide describes how to set the credit threshold through the API.

A credit is a bank transfer the rail has recorded. A credit that did not match, or whose wallet the token blocks, mints to the rail wallet, which holds the tokens there as suspense, and shows Parked with the reason. A credit for a client that takes delivery through a custody gateway also mints to the rail wallet, where the tokens wait on their way to the gateway, and shows “Minted”. Each parked credit has an operations case, which Operations cases explains. Parked credits lists each reason and what to do. Once a manager allocates a parked credit, the row shows “Allocated”, names the client that received it and no longer shows the park reason.

ENEnglishARArabic

, opens the full size screenshot

Above the table sit the token header with the bank, the state, the reserve account and how credits match, the “Edit payment schedule” and “Suspend” buttons, and the “Payments”, “Clients”, “Cash-outs”, “Reconciliation” and “Settings” tabs.

Recall a credit#

When the bank reverses a credit it confirmed, the rail records a recall and the credit stops minting. “Payments” shows Open recall on that credit. It opens a sheet with the recall's state, the bank's reversal ID, the amount, the mode, the target wallet, what was recovered, the excess, the written-down amount and every recorded claw.

1. In “Received”, select Request execution. A different bank rail manager selects “Approve” or “Reject”, and the sheet names the action that waits. You cannot decide your own request.
2. In “Clawing”, the tokens must leave the target wallet. For a custodian, the sheet links to the token's forced transfer and shows the target's free and escrow balances. In “Supply delegate” mode, enter the claw's transaction hash and log index, then select Record claw. The button stays off until both are valid. Select “Close claw” when the tokens are back.
3. The rail burns the recovered tokens and the recall ends Recalled.

To drop a recall, select Abandon and enter a reason. The dialog says the bank's debit stays a reserve difference until a manager records a reserve adjustment, and a second manager must approve. An approved abandon lets the credit mint again. A refused step shows its own message, for example that the mint is still in flight or that a cash-out of the client is live.

Allocate or return a parked credit#

1. Select Allocate on a parked credit and, when it matched no client, pick the client to pay. When the credit matched a client whose link was removed from “Clients”, the dialog says so. Pick another link of the same client. The list shows only that client's links, and a client with no link left has to be added again first. To send the money back instead, wait until the bank has refunded the payer, select “Return to payer” and enter the bank's refund reference.
2. Select Request allocation or “Request return”. With the “Bank rail” approval row off, the Console says no second approval is needed and the rail moves or burns the parked tokens at once. With the row on, the credit shows “Waiting for approval”.
3. A different bank rail manager selects Approve or “Reject” on the same row. You cannot decide your own request. Approving moves or burns the parked tokens, and rejecting leaves the credit parked.

While a request waits on a credit that holds parked tokens, Allocate and “Return to payer” stay on the row. A credit that minted nothing hides “Allocate” and “Return to payer” while a request waits. Asking again replaces the open request, which is also how any manager asks again after a request expires.

Review matches from a bank statement#

The Console assistant can read a bank statement and propose which client each unmatched payment belongs to. Open Search, select Draft from a document and choose the statement as a PDF of at most 20 MB. DALP reads the file once and deletes it. It opens the token page of the connection with the most matching payments, where “Matches from your bank statement” lists each proposed match above the “Payments” table. When other connections also have payments on the statement, a line says how many, so you open each one and draft from the document again.

Select Review on a match to open the allocation for that payment with the proposed client filled in, then request the allocation as in Allocate or return a parked credit. Nothing moves until you request it. Select “Dismiss” to close the list. A statement on which no unmatched payment appears says “No unmatched bank rail payment appears on this statement.”

Add a client#

A client is a participant wallet whose bank transfers mint to it. Adding one gives it a payment reference or a virtual IBAN to put on its transfers.

ENEnglishARArabic

, opens the full size screenshot

1. Open the token and select Clients.
2. Select Add client, then choose a “Participant” and one of its wallets in “Wallet”, in the sheet that opens.
3. On a virtual IBAN connection, enter the IBAN the bank assigned in Virtual IBAN. On a payment reference connection, DALP generates the reference and the table shows it under “Deposit instructions”.
4. Select Add client.

The Participant list holds every person who is a member of the organisation, without any extra role. Tokens, companies and other entities are not listed, because they cannot be bank rail clients. A directory role does not change this.

Add client stays unavailable, with the reason popover, until the connection has a token link. DALP refuses a client when the token's compliance blocks the client's wallet for a reason the client cannot fix themselves.

No email carries the reference or IBAN. The client reads it, with the bank name and reserve account to pay, in the Investor portal under the By bank transfer deposit method, as Bank transfers describes, or through GET /api/v2/users/me/bank-links. You can also give it to the client yourself.

No two clients of a connection share a payment reference or a virtual IBAN.

Removing a client asks for confirmation first. The wallet keeps its balance, but the deposit instructions stop working. Remove is unavailable while the client has a proposed or active bank account, so refuse or revoke those first.

Review bank accounts#

A cash-out pays only to an active bank account of the client. A client proposes an account for their own link, or a bank rail manager adds one through the API. It receives nothing until a bank rail manager other than the proposer approves it, whoever proposed it. This rule holds whatever the approval settings say.

On the token's “Clients” tab, open Bank accounts. It lists every account of the connection with the client, the IBAN or account number, the holder and bank, and its status. It reads “Proposed”, “Active”, “Refused” or “Revoked”. Filter the list by status. A refused or revoked account stays listed with the reason.

• On a “Proposed” account, select Approve. The account becomes “Active”. You cannot approve an account you proposed. “Approve” is unavailable in that row's menu and says another manager has to approve, and you can still refuse it from the same menu.
• To turn a proposal down, open the row menu, select Refuse, enter a reason and confirm. The account stays listed as “Refused” and never receives a payout.
• To stop payouts to an “Active” account, open the row menu, select Revoke, enter a reason and confirm. A cash-out the bank has not been instructed to pay is released, and the row shows “The bank account was revoked”.

Pay out a redemption#

In “Booked movements” mode a manager records the cash-out, as this section describes. In “Supply delegate” mode the client records it, as Pay out from an escrow describes.

A client who wants their money back requests a redemption on the token from their own wallet, with Request redemption on the token's Booked movements card in the Investor portal, as Booked movements describes, or POST /api/v2/tokens/{assetId}/features/register-lines/lines, which opens a redemption line. The request holds the tokens, so the client cannot spend them while the bank pays. The bank rail then pays the client's approved bank account and burns the tokens once the bank confirms the payment, so the reserve and the supply go down together. When the bank pays and the burn does not complete, the cash-out shows “Unbooked” until you work its operations case.

1. Open the token, select “Cash-outs” and select Record cash-out.
2. Pick the client, one of its open redemption requests and one of its active bank accounts. The panel shows the amount the bank pays.
3. Select Record cash-out. The rail adds the client's cash-outs of the last 24 hours, leaving out released ones, and compares the total with the token link's “Checker threshold”. At or below it, the cash-out is approved at once. Over it, and only while the “Bank rail” approval row is on, the row shows “Waiting for approval” and a different bank rail manager selects “Approve” or “Reject”. You cannot decide your own cash-out. An approved cash-out goes to the bank in its next opening, as Set when the bank takes payments describes.

DALP refuses a cash-out for a client whose participant account is suspended, closed, terminated or restricted from withdrawals, in either supply mode, and a checker cannot approve one for them. A checker can still reject it. A cash-out already approved when the restriction starts is released before the payment instruction goes out, or before its tokens lock in Supply delegate mode, and the row shows “Released” with the reason. An administrator can lift a suspension, closure or restriction on the participant's account status before the client cashes out again. A terminated account stays terminated, so that client cannot cash out.

The rail sends the payment instruction to the bank once, before the payout deadline less the settlement window. When the bank reports the payment settled, the rail burns the held tokens and the row shows “Paid” with the transaction. When the bank rejects the payment or does not settle it by the deadline, the rail cancels the request, the client gets the tokens back and the row shows Released with the reason. A client can also cancel their own request before the payment goes out.

Under the client's name, the row says where the tokens wait: the redemption line in “Booked movements” mode, or the escrow address with its lock ID, which you can copy, in “Supply delegate” mode. In “Supply delegate” mode, an organisation owner or platform administrator also finds Open escrow in the row menu. It opens the escrow on “Asset lifecycle”, then “Escrows”. Other managers see the address alone.

The bank can send a paid payout back, for example when the client's account was closed. The row then shows Returned, re-crediting and, once the rail has opened a credit for the returned money, “Returned, credit opened”. That credit appears on “Payments” with the bank's return ID. A returned-payout credit always waits for another bank rail manager's mint approval, whatever the credit threshold and even while the “Bank rail” approval row is off. DALP cannot return it to the payer, because the bank already refunded them. Under the amount, the row notes each returned amount, and once the returned payment has arrived it links to that credit on “Payments”.

ENEnglishARArabic

, opens the full size screenshot

Pay out from an escrow#

A token without Booked movements has no redemption request to hold the tokens. In Supply delegate mode an escrow holds them instead: an escrow is a contract that keeps a holder's tokens locked until a set time. The rail wallet controls the escrow and releases or pays each lock. After a lock ends, the holder can take the tokens back. A token custodian can move tokens out with the escrow's forced transfer, locked or not, and the escrow sets no limit. The Platform API refuses a lock whose cash-out the bank may still pay, and returns an unpaid cash-out's lock only to its owner during a compromised rail wallet rotation. Without the lock, a client could spend the tokens after the bank had already paid them.

The rail wallet controls one escrow on each network, which every “Supply delegate” link on that network uses. A “Supply delegate” link shows an Escrow block on the “Settings” tab. A “Booked movements” link has no escrow and shows no block. The block has four states:

• No escrow yet: the block reads “No escrow holds tokens for this link yet” and offers Create escrow. Select it and confirm with your wallet. The manager's acting wallet signs the creation, and the rail wallet controls the new escrow.
• Being created. The page checks again every five seconds and shows the transaction.
• Ready. The block names the escrow. An organisation owner or platform administrator also sees “Open escrow”, which opens the escrow under “Asset lifecycle”, “Escrows”. Other managers see the address alone.
• “More than one escrow matches this token link”: the rail cannot tell which one to use, so the block lists the escrows. The rail refuses cash-outs until only one remains.

Create escrow needs the “Escrow manager” role on the wallet you act through. Without it, the button is unavailable and the reason popover says so, even for a bank rail manager who manages the system. Ask a permission manager to grant “Escrow manager” to that wallet on “Roles and permissions”. “Create escrow” is also unavailable while the link is suspended and while the Console checks your roles. The API route is POST /api/v2/bank-rail/connections/{connectionId}/token-links/{tokenLinkId}/escrow, and it refuses with data.reason escrow-manager-missing for the same case. Any bank rail manager reads the escrow with GET on the same path. The rail refuses cash-outs while the rail wallet controls no escrow, or more than one.

A cash-out in this mode names an amount, not a request, and the client records it through the API for their own account, at POST /api/v2/users/me/bank-cash-outs. A bank rail manager cannot record one for them: on “Cash-outs”, Record cash-out is unavailable, with “This token uses Supply delegate mode, so each client requests a cash-out from their own wallet.” beside it. The manager follows each row on “Cash-outs” and decides the ones over the threshold. The cash-out itself runs in three steps:

1. The client approves the escrow, from their linked wallet, to take at least the amount.
2. The client records the cash-out with the amount and one of their active bank accounts. The request must carry an Idempotency-Key header. DALP refuses it without one, and a retry with the same key returns the same cash-out.
3. The rail moves the tokens into the escrow and locks them until the payout deadline. The same checker threshold and approval setting apply. After a checker approves, the rail locks the tokens again with a new deadline, so the bank gets the full payout time.

When the bank reports the payment settled, the rail takes the locked tokens and burns them, and the row shows Paid. When the bank rejects the payment or the deadline passes, the rail unlocks the tokens and the row shows “Released”, and the client withdraws them from the escrow. When the client's approval does not cover the amount, the request is refused. When the approval drops before the rail moves the tokens, the cash-out is released with the reason “The escrow could not lock the holder's tokens”, no payment goes out, and an operations case says what to do.

The request answers while the rail still locks the tokens. A bank rail manager's integration that waits for the lock, the checker step or the payment follows the cash-out's stream instead of reading it again and again, as the bank rail API guide describes.

Read the reconciliation#

ENEnglishARArabic

, opens the full size screenshot

Below the figures sit two tables, “Bank balance against supply” and “Rail wallet against parked credits”, each with its lines, counts and amounts.

Open the token and select Reconciliation. Two lines are compared per connection:

• Bank balance against supply. The bank's newest balance report against the token's supply, taking credits in flight, payouts the bank settled before or after the report, payouts another supply manager booked before the bank paid, open recalls, recalls the rail completed after the report and approved reserve adjustments into account. A recall is a bank request to take a payment back after it was credited.
• Rail wallet against parked credits. The tokens the rail wallet holds against the credits parked as suspense, the tokens clawed back for a recall that the rail has not burnt yet, and the credits on their way to a client's custody gateway, which the table shows as “Minted, delivering to a custody gateway”.

The page opens with the verdict and the date of the bank balance, then four figures: the bank balance, the token supply and the unexplained amount of each line. Each figure has an info button that explains how it is calculated. Findings follow when something needs attention: other accounts that hold the supply role or are supply delegates, a rail wallet that lost its supply authority, overdue credits and open recalls. A table under each line shows the amounts behind it, and Rail wallets lists each rail wallet with its role, supply authority and token balance.

The bank balance figure also names the business day the report belongs to: “Business day”, then the date and the connection's time zone. A report that arrives on a day the bank is closed belongs to the last open day before it. While a credit is parked, a line under the Rail wallet against parked credits table reads “Oldest parked credit” with the number of business days the oldest one has waited. Both count business days on the connection's holiday calendar. Without a calendar, every day is a business day, weekends included.

Each unexplained figure reads “Adds up” or “Does not add up”. The status is “Clear” when both lines are explained. It is Break when:

• either line has an unexplained difference
• in “Booked movements” mode, another account holds the token's supply management role, unless the link allows other supply managers and the rail wallet still holds it
• in “Supply delegate” mode, any account holds the token's supply management role
• another account is a supply delegate of the token
• the rail wallet lost its own supply authority
• after a rail wallet rotation, the old wallet still holds tokens and is not frozen on the token

Unavailable means the supply, a balance or the token's roles could not be read, or the indexer did not supply an unchanged drained block at or beyond finality, so nothing is judged. The rail retries that report once the facts are available. “No report” means the bank has sent no balance report for the reserve account yet, or the connection has no token link yet.

Keep a daily version#

The daily reconciliation API keeps both lines and their evidence pins as immutable versions per connection date. A manager can reread a version or export its CSV. The bank report is selected at or before the connection's cutoff, and the token facts are the indexed facts available when the run executes. The worker retries unavailable days within the last three closed days and raises one warning if a day leaves that window incomplete, including while the connection is suspended. That warning also covers an attempted date whose cutoff or store failure prevented any version from being stored.

Explain a difference with a reserve adjustment#

A bank fee, interest or a refund to a payer moves the bank balance without a credit or a cash-out, so the reconciliation shows an unexplained difference. A bank rail manager records the posting as a reserve adjustment through the API. While the Bank rail approval row is on, a different manager approves or rejects it. With the row off, it is approved at once. An approved adjustment explains the difference from the next balance report on, and the operations case for the break clears when that report reconciles. The bank rail API guide lists the fields.

Rotate the rail wallet#

The rail wallet is the key the rail uses to sign mints, burns and escrow moves. Rotation replaces the key when it is compromised or lost. It spans several people, because the rail wallet holds supply authority on each linked token, and the people who manage those tokens are often not the bank rail managers. The rail wallet incident runbook defines both cases, gives the order of the steps and says who you need and what each person does.

Open the token and select Settings. The “Rail wallet” card shows the “Generation”, “State” and “Address” of the wallet. The state is “Active”, “Staged”, “Contained” or “Retired”.

Contain the wallet#

1. Select Contain rail wallet.
2. Choose why the key is being replaced. Choose Compromised or “Lost”. A note is optional.
3. Read “What happens” and select Contain rail wallet.

DALP signs nothing new with the key once it is contained, and completion waits until the contained wallet has no queued writes, no grant of supply authority still on its way to it, and no supply authority left on a linked token. Every token link is suspended and no credit is minted. A cash-out the bank has not been instructed to pay is released with “The token link is no longer active”, so the client gets the tokens back. The rail prepares a replacement wallet, which signs nothing until you complete the rotation. On a rotation opened as “Lost”, Report compromised turns it into a compromised rotation at once. It drops any open abandon request, the rail never signs with the old wallet again, and nothing reverses it. Whoever holds a compromised key can still sign with it until each token revokes its authority and the old escrow is emptied.

Work the checklist#

The Rotation checklist lists each step in order, with its status as text. It reads “Done”, “Yours to do”, “Waiting on” a named role, “Blocked by” an earlier step, “Not applicable” or “Failed”. “Next” marks the first step you can act on or, when there is none, the step that holds the others up. A step names the role it needs, the token it applies to and, where the Console can read them, the people who hold that role.

Each step links to the screen where it is done through “Open the token's permissions”, “Open the token's holders”, “Go to the escrow” or “Open identities”. “Go to the escrow” opens the token's “Settings” tab on the bank rail, where the Escrow block sits.

Copy link copies the step's address to send to the person. If you hold the token role yourself, “Revoke authority” or “Grant authority” appears on the step and asks for your wallet. The checklist updates once DALP sees the result on the chain.

The steps are:

1. Contained.
2. New wallet identity registered, by an identity manager. Fund the new wallet with gas before the grant.
3. Then, for each token:
   • Authority revoked, by a token admin or, for a supply delegate link, a token governor.
   • Old escrow protected, by a token custodian, who empties the old escrow with its forced transfer. It appears for a supply delegate link whose old escrow holds tokens, and for every supply delegate link on a compromised rotation.
   • Authority granted, by the same role that revoked it, once the new wallet's identity is registered. On a compromised rotation it stays blocked until no link leaves authority with the old wallet and no old escrow holds tokens.
   • Escrow created, for a supply delegate link, by an escrow manager.
   • Suspense moved, by a token custodian, with the amount and an “Open the token's holders” link, where the custodian makes the forced transfer. The amount covers the credits held in suspense and the coins of credits still on their way to the client's custody gateway. Those coins are repinned to the new wallet when the rotation completes, so their delivery sends from it. A credit that is mid-send from the contained wallet blocks completion until it lands or fails.
4. Request completion, by a bank rail manager.
5. Approve completion, by a second bank rail manager.

On a compromised rotation, every “Authority revoked” and “Old escrow protected” step moves up to follow Contained. Until DALP sees no authority left with the old wallet, the card says the old key still holds supply authority on a number of links.

Request and decide completion#

Request completion stays unavailable, with the reason popover, until every earlier step is done. What blocks completion lists the other refusals.

While the “Bank rail” approval row is on, a different bank rail manager selects Approve or “Reject” on the request. With the row off, the request is approved at once and the rotation completes on the next read. The dialog shows the “Old wallet” and “New wallet” addresses and how many token links move with their open credits. Reject needs a reason, and the requesting manager sees it and can select “Request again”. You cannot decide your own request. On approval, the links, their open credits and the rail's signing key move to the new wallet in one step. Credits that parked while the wallet was contained mint from the new wallet without a manual retry. Requests to allocate or return a parked credit that were still waiting are cancelled, so ask again. Credits waiting for mint approval ask for it again.

A lost key can be abandoned with Request abandon, which a second manager approves while the “Bank rail” approval row is on. Abandoning is refused once a manager has submitted a revoke or grant for the rotation, or once any token link's supply authority has left the contained wallet. A compromised rotation cannot be abandoned.

Read both wallets on the reconciliation page#

During a rotation, Rail wallets on “Reconciliation” has one row per wallet with its address, its role as “Current rail wallet”, “Next rail wallet”, “Contained rail wallet” or “Previous rail wallet”, its supply authority and its token balance. The old wallet's balance moves to the new one at the “Suspense moved” step. The retired wallet stays listed as history. A retired wallet that still holds tokens but is frozen on the token raises an operations case, not a “Break”.

Recover an unbooked delegate cash-out#

When the cause of an “Unbooked” cash-out on a supply delegate link is a compromised escrow, a token custodian first moves the locked tokens to the rail wallet with the escrow's forced transfer. Then select Recover on the cash-out row. “Unbooked” means the bank paid but the tokens were not burnt. The rail records the transfer and burns the tokens, and the row shows “Paid”.

Emails to the client#

The platform emails a client when a bank payment or a cash-out reaches an outcome. The email goes to the client the payment or cash-out belongs to, in the language of that client's account. A client with no email address on file gets none, and so does a platform with no mail transport configured. The credit or the cash-out itself is never affected, and no bank message, credit or approval waits for the email.

Each email shows the amount and the reference. Its button opens Transfers in the client's portfolio, filtered to that reference, or the portfolio for a rejected or paid cash-out. If no Investor portal URL is configured, the button opens the client's portfolio in the Console without a transfer filter. An email goes out at most once per outcome, so a bank message that arrives again sends nothing new, and an email that fails to send is not retried. A credit that was ever held for screening sends no deposit email, even after a manager allocates it, retries its mint or returns it to the payer.

When a second manager decides#

A different Bank rail manager always approves a bank account, and a raise of the credit threshold or the mint cap always waits for a different bank rail manager, whatever the approval settings say. The credit threshold is the amount above which an incoming credit waits for mint approval, and the mint cap limits what the rail wallet may mint.

The organisation's “Bank rail” row under “Approvals” on General settings is off until an organisation owner or platform administrator selects Turn on, and the row then reads “Second person required”. While it is on, a different manager decides:

• a cash-out over the checker threshold
• an allocation or a return of a parked credit
• a credit over the credit threshold
• a reserve adjustment
• the completion or abandoning of a rail wallet rotation

With the row off, these go ahead at once, and “Actions” records each one as “No second approval (approval off)”. A credit that re-credits a returned payout waits for mint approval even then. You cannot approve your own proposal or decide your own request. When Approvals required for the row is greater than 1, each change in this list needs that many different people to approve it, and only an organisation owner who also holds the Bank rail manager role can decide it. A request nobody decides within 7 days expires.

Operations cases#

An operations case records a problem the platform cannot resolve itself. An organisation owner or platform administrator acknowledges the case and resolves it with an investigation note, or the platform resolves it when the problem clears. The webhook events guide describes cases.

An organisation owner or platform administrator opens “Organisation settings”, then “Custody”. The Cases tab appears there only on a deployment with custody operations. The page is titled “Custody”, and the “Operations cases” table lists the cases. Expand a row to see its “Case id” and its “Reason”. A bank rail manager who cannot open the tab asks an organisation owner or platform administrator to work the case.

The Payments table does not show a parked credit's case ID, and on the bank rail screens only an “Unbooked” cash-out shows its case ID. The “Reason” of a parked credit's case starts with “Bank credit”, then the credit's “Bank transaction” value from “Payments”. Give the owner that value to find the case. A manager with an API key can instead list the credits with GET /api/v2/bank-rail/connections/{connectionId}/credits. Each credit's caseId field holds the case ID.

Parked credits#

A parked credit shows its reason on Payments. Each credit has an operations case.

Whatever reason a credit shows, when the client's link was removed from “Clients” after the payment matched, Allocate asks for another link of the same client. A client with no link left has to be added again first, or the credit goes back to the payer.

Fiat screening exports include provider alerts. Each provider decision also creates a case linked to the investor, with the verdict and alerts.

Troubleshooting#

API routes#

Every task on this page also runs through the bank rail routes of the Platform API, and a few run only there:

• changing the bank name, the payout deadline or the settlement window
• adding a bank account for a client
• setting the credit threshold or the mint cap, and approving a raise of either
• recording and deciding a reserve adjustment
• changing the messages the bank may send on a connection

The bank rail API guide covers them, and API keys says how to get a key to call them.