# Cash and the bank rail

Source: https://docs.settlemint.com/docs/changelog/dalp-3-2/bank-rail
Mint a fiat token from each credit your bank confirms over its FIX session, pay redemptions only to approved accounts and reconcile the reserve.

**Your team can mint a fiat-backed token from each confirmed bank credit, pay redemptions only to approved accounts and show that the reserve covers the supply.** DALP logs on over TLS to your bank's own session of FIX, the Financial Information eXchange protocol, so a cash-token team runs the whole cycle, from client payment to reconciliation, on the bank account that holds the reserve.

Spotlight: Each credit the bank confirms mints at most once, and each redemption burns only when the bank reports it paid

- Bank side: Your bank's own FIX session, over TLS
- Each credit: Mints at most once, however often reported
- Payout accounts: Approved by someone other than the proposer
- Reconciliation: On every bank balance report

The rail logs on to your bank with each connection's own identifiers and password, reads credits, balance reports and payment outcomes from that session, and a Bank rail manager runs it from "Asset lifecycle" › **Bank rail** in the Console.

## Before and after [#before-and-after]

**Before 3.2:** A treasury team reads each credit off the bank statement and mints by hand. A payment keyed twice mints twice, a payment with a wrong reference waits in someone's inbox, and redemptions are matched to outgoing payments in a spreadsheet. When the auditor asks whether the reserve covers the supply, the answer is assembled after the fact.

**With 3.2:** the rail records each bank transaction once and mints it to the client's wallet, or holds it as suspense with an operations case when no client matches. A redemption is paid by an instruction the bank acts on once, and its tokens burn when the bank reports the payout settled. Every balance report is compared with the supply, and a difference that stays unexplained on two reports in a row opens a case.

A client can cash out only to a bank account approved by a bank rail manager other than the one who proposed it. The client requests the payout from "Withdraw" in the Investor portal, choosing a requested redemption line or, for a Supply delegate token, an amount whose exact allowance the client approves for the escrow. A retry keeps the same request identity. [Request a bank payout →](https://docs.settlemint.com/docs/concepts/operating/investor-portal-bank-transfers#how-to-cash-out) Each cash-out row shows where its tokens are held, including an escrow lock. A bank rail manager's integration follows each cash-out through its stream, which sends the cash-out each time the lock, the checker step or the burn moves it. [Follow a cash-out →](https://docs.settlemint.com/docs/api-reference/guides/bank-rail#follow-a-cash-out)

[Figure] How the bank rail keeps a cash token in step with its reserve account. Your bank reports a credit over its FIX session with DALP. The rail records each bank transaction once, matches it to a client by reference or virtual IBAN, screens the client's wallet and mints to it at most once. A credit that matches no client mints to the rail wallet as suspense until a manager allocates or returns it. A cash-out goes only to an account someone other than its proposer approved, its instruction goes out once on a business day, and the tokens burn when the bank reports the payout settled. Each balance report is reconciled against supply and suspense, and a difference on two reports in a row opens a case. Labels: Money in; Credit reported; Bank; Over your bank's; own FIX session; Recorded once; Once; A repeat changes; nothing; Match, screen; Checks; Reference or IBAN,; token compliance; Minted to wallet; Client; At most one mint per; bank transaction; Suspense tokens; No match; Allocate or return,; case stays open; Money out; Approved account; Cash-out; Approver is never; the proposer; Sent once; Instruction; On a business day,; before the cut-off; Burnt when paid; Bank report; Rejected: tokens; back to the holder; Reserve vs supply; Reconcile; Each balance report; against supply and; suspense. A case; opens after two; breaks in a row.

A credit mints once to the client it matches, a cash-out burns tokens when the bank reports it settled, and every balance report is reconciled.

## Connect to your bank's own FIX session [#connect-to-your-banks-own-fix-session]

The rail opens one FIX session to your bank for each active bank connection. A Bank rail manager adds the connection under "Asset lifecycle" › "Bank rail" with its CompIDs, the identifiers each side uses on the session, and the reserve account and currency, sets its logon password on the "Settings" tab and chooses **Activate connection**. DALP then dials the bank's FIX acceptor over TLS, checks the bank's certificate and logs on with that connection's identifiers and password. While the line is quiet it sends heartbeats, it logs out when the bank stays silent for 90 seconds, and after a drop it dials again with a wait that doubles up to a limit the operator sets. Both sides keep their message numbers across restarts, so after a drop each side asks the other to resend what it missed, and a payment instruction sent again is marked as a possible duplicate. Suspending a connection ends its session and stops the dialling. The operator sets the bank's FIX address for the whole deployment, so every connection on one deployment reaches the same bank acceptor.

![Payments tab of a bank connection listing each bank credit with its client, amount and status](https://docs.settlemint.com/docs/screenshots/console-bank-rail-payments.light.en.webp)

[Screenshot] Your team sees each bank credit minted to its client and allocates the one with no match.

## Mint each confirmed payment at most once, to the client who paid [#mint-each-confirmed-payment-at-most-once-to-the-client-who-paid]

A client's payment into the reserve account reaches their wallet as tokens without anyone keying it in. Each connection has a token link, the setting that ties one token to that bank connection, and a rail wallet, the wallet DALP keeps for the connection to sign every mint and burn. A Bank rail manager adds a corporate client on the connection's "Clients" tab, and DALP generates the payment reference the client quotes on its transfer. The rail can also match a credit by a virtual IBAN, an account number the bank assigns to one client. The client pays 24.99 USD into the reserve account and the bank confirms the credit over FIX. The rail screens the client's wallet against the token's compliance, mints 24.99 tokens to it, and the credit appears on the **Payments** tab with its mint transaction. If the bank sends the same confirmation again, the rail answers with the acknowledgement it stored and mints nothing. A credit the token cannot represent, or one whose mint fails or is refused approval, mints nothing and is listed with its reason. With the organisation's "Bank rail" approval rule off, every credit that matches a client mints without a second look.

## Hold an unmatched payment as suspense until a manager decides [#hold-an-unmatched-payment-as-suspense-until-a-manager-decides]

A payment whose reference matches no client still mints, but to the rail wallet, as suspense: tokens the rail holds for a payment it cannot place, each listed with its operations case. A manager chooses **Allocate** to move those tokens to the client who paid, or "Return to payer" with the bank's refund reference, which burns them once the bank has refunded the payer. When the organisation turns on the "Bank rail" approval rule, a second Bank rail manager approves each allocation and return. A credit over the token link's checker threshold, counted with the client's credits of the last 24 hours, then waits for approval before it mints. The approval rule starts off, so until an organisation owner or a platform administrator turns it on, one manager allocates or returns suspense alone. On an instance SettleMint operates, a platform administrator may be SettleMint staff.

## Pay redemptions only to accounts a second person approved [#pay-redemptions-only-to-accounts-a-second-person-approved]

A redemption pays out only to a bank account that someone other than its proposer approved. A client proposes a bank account in the Investor portal, or a manager adds one, and it becomes usable only when a Bank rail manager other than the person who proposed it approves it, whether or not the approval rule is on. A token runs in one of two supply modes. In booked movements the rail wallet holds the token's supply management role and books each redemption as a line on the token, and in supply delegate mode the rail wallet is the token's only supply delegate, allowed to mint and burn, and locks redeemed tokens in the rail's escrow. Each row on the "Cash-outs" tab names where the tokens are held. For a booked token a manager chooses **Record cash-out** and picks one of the client's active accounts, and for a token that mints through a supply delegate the client requests the cash-out from their own wallet. With the approval rule on, a cash-out over the threshold, alone or with the client's cash-outs of the last 24 hours, waits for a second manager.

The rail then sends one payment instruction over FIX to the bank, and when it reports the payment settled, the held tokens burn. A rejected payment, or a deadline the bank misses, gives the tokens back to the client. When mail is set up and the client has an email on file, it gets an email when the cash-out is paid, rejected or returned. If a holder cancels the redemption request after the instruction went out and the bank then pays, the cash-out stays unbooked and a critical case opens, because the rail cannot take the tokens back by itself.

## Send payments only on the connection's business days [#send-payments-only-on-the-connections-business-days]

Each connection has a time zone and can follow a holiday calendar and a payment cut-off, so the rail instructs nothing while the bank is closed on that calendar. A Bank rail manager sets them with **Edit payment schedule** on the connection's page. A cash-out approved after the cut-off, or on a closed day, waits until the next business day, and the "Cash-outs" tab shows the value date the client can expect. The client's own cash-out reads carry the same value date. The payout deadline and the settlement window count business time on the connection's calendar, so a long weekend on that calendar raises no overdue case. Without a calendar, every day is a business day, weekends included. A change to the calendar, time zone or cut-off applies only to cash-outs requested after it.

## Take back a payment the bank reverses, even after the client's custody gateway issued receipts [#take-back-a-payment-the-bank-reverses-even-after-the-clients-custody-gateway-issued-receipts]

When the bank reverses a credit, the rail records a recall, stops the credit from minting and opens a critical case. A Bank rail manager asks for the recall through the API and a second manager approves it. The rail then cancels a credit that has not minted, burns or books the tokens it holds, or waits for a token custodian to take the tokens back from the client. A credit already delivered into the client's custody gateway is recalled too: the receipt token's custodian moves the client's receipts into the rail wallet, the rail redeems them at the rail wallet's own custody gateway, and it burns the coins the gateway pays. What the client moved away and the gateway's fees are written down as a reserve adjustment, and the reconciliation shows the receipts waiting for their redemption. A recall of a delivered credit needs the rail wallet set up as a client of a custody gateway first, and the API refuses it with the step that is missing until then. The [recall guide](https://docs.settlemint.com/docs/api-reference/guides/bank-rail#recall-a-delivered-credit) lists each step and refusal.

## Recall a credit the bank reversed, and set credit limits, from the Console [#recall-a-credit-the-bank-reversed-and-set-credit-limits-from-the-console]

When the bank reverses a credit it confirmed, the credit's row on "Payments" shows **Open recall**. A Bank rail manager requests the recall's execution or abandons it, and a second manager approves. While tokens must come back, the sheet shows the target's balances and takes the claw's transaction hash and log index. Abandoning says first that the bank's debit stays a reserve difference until a manager records an adjustment. "Settings" shows the credit threshold and the mint cap in the token's units and lets a manager change them, with a raise waiting for a second manager. "Edit payment schedule" sets the daily report cut-off. A cash-out the bank returned shows each returned amount and links to the credit that re-credits it.

## Show that the reserve and the supply agree [#show-that-the-reserve-and-the-supply-agree]

The **Reconciliation** tab shows two lines: the bank balance against the token's supply, and the rail wallet against the credits it holds as suspense. Each line counts what is still in flight, such as credits waiting to mint and payouts the bank settled that wait to be booked, and shows what is left unexplained. A value the platform cannot read shows as "Not available", never as zero. When a balance report still breaks on the next report, the rail opens a critical operations case. It opens one on the first report when the rail wallet is no longer the token's only supply authority, the one account allowed to mint and burn it. A Bank rail manager records a bank fee or interest posting as a reserve adjustment through the API, with its reason and the bank's reference. With the "Bank rail" approval rule on, a second Bank rail manager approves it, because the manager who proposed it cannot, and from the next balance report on the adjustment explains the difference. The tab lists each open difference and who explained it. With the rule off, a reserve adjustment is approved the moment it is recorded.

Each closed connection date now keeps immutable daily versions of both lines and the evidence behind them: the bank balance report at or before the connection's cut-off and the indexed token facts the run read. A manager can reread a version or export it as CSV, and an earlier version keeps its original values and bytes. The worker retries unavailable days within the last three closed days and warns when a day leaves that window incomplete. The [daily reconciliation API](https://docs.settlemint.com/docs/api-reference/guides/bank-rail#daily-reconciliation) lists the cut-off, routes and refusal reasons.

## Stop a lost rail wallet before it signs again [#stop-a-lost-rail-wallet-before-it-signs-again]

A Bank rail manager can stop the rail wallet at once if its key is lost or leaks. **Contain rail wallet**, on the connection's "Settings" tab, takes the reason lost or compromised and suspends every token link on that network. From then on the rail signs nothing with that wallet: no credit mints with it and every cash-out step it would sign waits. A checklist on the same panel names each step to recovery: register the new wallet's identity, revoke the old wallet's authority on each token, empty the old escrow by forced transfer, grant the authority to the new wallet, set up the new escrow where a token uses one, and move the suspense, which includes the coins of credits still on their way to the client's custody gateway. Those credits are repinned to the new wallet at completion, so their delivery sends from it. The token's administrator, or its governor for a token that mints through a supply delegate, signs the revoke and the grant, and a token custodian empties the old escrow. A manager then chooses "Request completion", and another Bank rail manager approves it. Containment stops the rail signing, but a leaked key keeps its supply authority on each token until the token's administrator or governor revokes it, so revoke it first. A grant of supply authority that was already waiting for approval, a signature or gas when you contained the wallet cannot hand it back its power: the rail refuses completion while such a grant to the old wallet is still queued, and while the old wallet holds authority on any token linked to it, and it opens one security case that names the grant.

## Tell your back office about each bank payment as it happens [#tell-your-back-office-about-each-bank-payment-as-it-happens]

An integration subscribes to `bank-rail.credit.*` and `bank-rail.cash-out.*` instead of polling the rail. A credit reports when it is admitted and how it ends, and a cash-out reports its request, instruction, payment, return or release. The accounting team's ledger posts each client payment and payout from these events with the bank amount, the currency and the time of each step, while approval identities, suspense reasons, recovered amounts and write-down figures stay out of the payload. A payout the bank returns admits a new credit that names its cash-out and reports its own mint, so the ledger links the two without a manual match. The [bank rail event catalogue](https://docs.settlemint.com/docs/api-reference/webhooks/events#bank-rail) lists each trigger, and the [accounting feed](https://docs.settlemint.com/docs/api-reference/guides/accounting-feed#bank-rail-events) says which events to post. The default state subscriptions skip these event names, so an endpoint receives them only after you choose the family.

## Screen each bank payment with your AML provider and check who paid [#screen-each-bank-payment-with-your-aml-provider-and-check-who-paid]

Every confirmed credit that matched a client, and every cash-out before its payment instruction, goes to the AML provider the connection names, and nothing mints or pays until the answer allows it. Sumsub transaction monitoring is the first provider, and others plug in behind the same compliance port. A credit the provider rejects or holds parks with its reason, a cash-out it rejects or holds waits for a manager, and a second Bank rail manager releases either one, even while the **Bank rail** approval rule is off. A credit that came from an account the client has not had approved parks as well, unless the connection turns the payer check off. A compliance officer reads the verdicts through the API or downloads a date range as a CSV file from the connection's "Settings" tab. The provider, the level and the payer check are settings of each connection. A connection starts with the payer check on, so credits from an account the client has not had approved park until you approve the account or turn the check off.

## Upgrading [#upgrading]

The bank rail is new in 3.2 and stays off until the operator turns it on for the deployment, as the [bank rail API guide](https://docs.settlemint.com/docs/api-reference/guides/bank-rail#set-up-a-connection) describes. The operator then points the rail at the bank's FIX acceptor with its address and TLS settings, and the platform refuses to start the rail without that address, or with an unencrypted session to a host outside its own machine. Until then the rail runs a FIX simulator that ships with DALP for local testing, which accepts connections only from the same machine. The **Bank rail** approval rule starts off in every organisation, and an organisation owner or a platform administrator turns it on under "Approvals" in the General settings before the rail handles client money. A bank account always needs approval from a Bank rail manager other than the person who proposed it, whatever the rule says.

## Why it matters [#why-it-matters]

- **Banks:** a team can show that the token's supply follows the reserve account at its own bank payment by payment, and that no payout goes to an account its proposer approved alone.
- **Regulators:** every difference that survives two balance reports in a row is an open case, and with the approval rule on, every adjustment names the manager who proposed it and the one who approved it.
- **Bank integrators:** the [bank FIX session profile](https://docs.settlemint.com/docs/api-reference/guides/bank-rail#bank-fix-session) lists the logon, heartbeat, resend and message rules the rail expects from the bank's acceptor.

## Next steps [#next-steps]

- [Run the bank rail from the Console →](https://docs.settlemint.com/docs/console/asset-lifecycle/bank-rail)
- [Pay by bank transfer in the Investor portal →](https://docs.settlemint.com/docs/concepts/operating/investor-portal-bank-transfers)
- [Understand maker-checker approval →](https://docs.settlemint.com/docs/concepts/custody-and-signing/maker-checker)

Fiat screening exports include provider alerts. A deposit from an unverified payer stays parked until the payer account passes maker-checker approval. Cash-outs above the configured limit require a checker even when the Bank rail approval family is off.