Banks should require a tokenization platform to enforce eligibility in the transfer path, carry instrument logic in templates, fit core banking, route signing to the vault already on the mandate, keep every write in a named state, service the instrument after issuance, and leave evidence Audit can reconstruct. A mint demo does not satisfy that list.
Two Insights pages previously split this into eight evaluation factors and seven banking requirements. This page is the merged brief for Ops, Compliance, Settlement, Risk, and Audit. Weight the rows to the funded program. A bond book cares about coupons. A deposit program cares about interest and withdrawal. Every bank program cares about identity, dual control, and evidence.
SettleMint DALP is built against this list as a digital asset lifecycle platform. The category sentence is what a digital asset lifecycle platform is, and why banks use one. The stack split is tokenization platform versus blockchain infrastructure.
What to require before a token reaches production
|
What banks should evaluate in a tokenization platform
| Requirement | What good looks like | Owner |
|---|---|---|
| Transfer-path compliance | Identity claims and modular rules checked before mint, transfer, or burn. An ineligible holder never reaches settlement. | Compliance / Legal |
| Instrument templates | Class-specific logic for bonds, funds, equity, deposits, cash instruments, and real-asset claims. | Product / Markets |
| Core-system fit | Named states and APIs treasury and servicing can post, so the chain and the core see the same instruction. | Architecture |
| Custody coordination | Maker-checker around the vault already on the mandate. Keys do not move into the application. | Risk / Custody |
| Instruction lifecycle | Idempotent writes, recoverable failures, a terminal verdict. Ops can see pending custody approval. | Ops / Settlement |
| Lifecycle after issuance | Coupons, redemptions, freezes, recovery, and retirement on the same control plane as the mint. | Ops / Product |
| Deployable topology | On-prem, private cloud, or hybrid on networks the institution configures, inside existing pipelines. | IT risk / SRE |
| Production evidence | Balances as of a past date, reason codes, dual-control history, an export Audit can use. | Audit |
Compliance, custody, and settlement in the transfer path
Eligibility that lives in a policy PDF is not enforcement. The platform has to refuse an ineligible holder before settlement, with a reason Compliance can defend later. ERC-3643-style identity and modular rules are how that fail-closed path is usually implemented. The protocol is not the whole stack. KYC, screening, and case management still sit with named vendors. The longer protocol brief is ERC-3643 and the stack a bank still has to run.
Custody is a coordination problem, not a replacement problem. Risk already contracted a vault. The platform prepares the instruction, routes signing, waits on approval, and records the outcome. DALP does not act as custodian. Signing providers in production include DFNS, Fireblocks, and a Thales Luna HSM.
Settlement is a named state machine, not a hash on an explorer. Every write should be received, queued, prepared, signed, pending approval, broadcasting, confirming, completed, or a managed failure. Idempotent retries matter when an institution needs the transaction to happen on chain. Cash in atomic delivery-versus-payment is a token the settlement contract can move. Fiat remains on the bank's rails unless that cash is tokenized.
What a demonstration has to show
Issue from a template. Attempt a transfer to an ineligible holder. Route a dual-controlled send to the vault the bank already uses. Fail a write on purpose. Produce balances as of a past date. If the vendor cannot run that sequence, the brochure is a different category. How the operating day looks after go-live is how banks run tokenized instruments after issuance.
Where DALP maps to these rows: SMART Protocol templates for bond, equity, fund, deposit, stablecoin, precious metal, real estate, and a generic instrument; compliance in the pipeline and again on-chain; a transaction queue; custody routing; operator console, API, CLI, and webhooks; Helm-operable deployment including on-prem and air-gapped patterns. There is no general corporate-actions factory and no fiat RTGS in the product. Do not brief those as shipped.
Operator on-ramp: Getting Started with SettleMint DALP. Technical surface: DALP documentation. A shorter requirements cousin remains at key banking requirements for tokenization platforms.
Related reading
- What a digital asset lifecycle platform is, and why banks use one
- Tokenization platform versus blockchain infrastructure for a bank
- How banks run tokenized instruments after issuance
- Institutional tokenization platforms banks actually evaluate in 2026
- How to industrialize digital asset operations inside a regulated bank
Frequently asked questions
What should banks require from a tokenization platform?
Eligibility in the transfer path, instrument templates with servicing logic, fit to core systems, custody coordination without replacing the vault, named instruction states, lifecycle coverage after issuance, a deployable topology, and evidence Audit can reconstruct.
What should banks evaluate for compliance, custody, and settlement?
Compliance: fail-closed transfer rules with a typed reason. Custody: signing in the approved vault, dual control, keys outside the application. Settlement: a named state for every write, recoverable failure, a terminal verdict.
Should the tokenization vendor also be the custodian?
Usually no. Risk already contracted a vault. The platform should orchestrate policy around that vault rather than take the keys.
How is a tokenization platform different from a blockchain stack?
The stack supplies networks, middleware, and sometimes a first-party vault. The platform supplies regulated issuance, eligibility, custody-routed execution, servicing, and queryable history. Banks often need both, on separate criteria.
How can a bank tell a production platform from a pilot toolkit?
Ask for a dual-control transfer, a blocked ineligible holder, a coupon or redemption through the same rules, a failed broadcast with a named recovery state, and balances as of a past date.
