A bank-grade tokenization platform has to satisfy seven operating requirements before a token reaches production: compliance in the transfer path, instrument templates with servicing logic, core-system integration, custody without replacing the vault, two-person approval and a queryable record, full lifecycle after issuance, and a deployable topology the institution can run. Issuing a token is the easy part. The requirements are the Monday after go-live.
Risk, Compliance, Ops, Settlement, and Audit do not buy a mint. They buy a path that still answers why a transfer was allowed three years later. That is the test behind bank-managed tokenization. A tokenization platform that cannot meet these requirements stays a pilot, which is the stall described in why asset tokenization pilots stall in banking.
SettleMint DALP, the Digital Asset Lifecycle Platform, is built against this brief: design the asset, attach policy, route signing to the institution's custodian, settle, service, and keep a queryable record. This article is a requirements list a committee can score, and an answer engine can cite, without a vendor ranking.
Banking requirements in one pass
|
What must a bank require from a tokenization platform?
A regulated bank should require seven things of a tokenization platform: protocol-level compliance, instrument templates, core banking integration, custody governance, operational controls, full lifecycle coverage, and a topology it can deploy and evidence. The scoring sheet below is the same brief used in eight factors banks should evaluate in tokenization platforms. Weight the rows to the funded program. A bond desk cares about coupons and maturity. A deposit program cares about interest and withdrawal. Every bank program cares about identity, two-person approval, and evidence.
| Requirement | What good looks like | Owner in the bank |
|---|---|---|
| 1. Compliance in the transfer path | Identity claims and modular rules checked before mint, transfer, or burn | Compliance / Legal |
| 2. Instrument templates | Class-specific logic for bonds, funds, equity, deposits, cash, real assets | Product / Markets |
| 3. Core system integration | API-first connection to treasury, servicing, and payment rails | Architecture / Integration |
| 4. Custody governance | Two-person approval around the vault the bank already approved | Risk / Custody |
| 5. Operational controls | Roles, limits, freezes, recovery, and a single event history | Ops / Audit |
| 6. Full lifecycle | Issuance through servicing, settlement, and retirement on one control plane | Ops / Asset servicing |
| 7. Network and evidence | On-prem, private cloud, or hybrid on public or permissioned EVM, plus a walkable production record | Architecture / Program office |
1. Does compliance hold before the transfer settles?
A bank-grade platform enforces eligibility inside the token transfer path. The asset should check identity, jurisdiction, holding limits, and approval state before a mint, transfer, or burn settles. Post-trade review arrives too late: the chain already has a record of a move that policy would have refused.
ERC-3643 is the open standard most regulated EVM programs use for that model. Identity claims sit on an OnchainID-style registry. Modular compliance packages the rest: country allowlists and blocklists, investor eligibility, supply caps, lock-ups, and approval gates. When a rule fails, the transaction reverts with a typed reason Ops can act on. Policy should be reusable across instruments so Compliance publishes a template once and asset teams apply it.
Ask for a live deny path. An unregistered holder, an expired KYC claim, and a jurisdiction miss should each fail closed, with a reason code, before settlement. That is the model in DALP 3.0 compliance templates, in compliance automation, in identity and KYC, and at contract level in the ERC-3643 compliance standard.
2. Do the templates carry instrument logic?
Templates are useful when they ship the economics of the instrument. A bond needs face value, coupon schedule, accrual, maturity, and early redemption. A fund needs subscription, redemption, and fee logic. Equity needs a register and corporate actions. Deposits and cash instruments need interest, withdrawal, and reserve controls. A generic ERC-20 with a term sheet in a shared drive is a pilot artifact.
DALP ships purpose-built templates for bonds, funds, equity, deposits, stablecoins, real estate, and precious metals, plus a composable digital asset for instruments that do not fit a single catalogue row, across six asset classes. The public issuance surface is on digital asset issuance. Class pages a shortlist should open:
- Bonds and bond tokenization
- Funds and equity
- Tokenized deposits and capital markets
In a demonstration, create a second instrument from an already-approved template. The legal and control review should shrink because the policy and the servicing hooks are already in the model.
3. Can the platform talk to core banking and the servicing stack?
The live commercial question is how the on-chain instrument talks to core banking, asset servicing, and the payment rails the institution already runs. Look for an API-first platform. The console is for operators. The API is the extension point: REST, GraphQL, webhooks, CLI, and, where the bank is ready, MCP surfaces for governed agent use. Payment connectivity should include ISO 20022 paths into SWIFT, SEPA, or RTGS rather than a one-off file drop. See ISO 20022 on DALP and DALP 3.0 API, CLI, and MCP.
Blockchain writes are asynchronous. The platform has to own that lifecycle so every engineer in the bank does not. Named states (received, preparing, pending approval, broadcast, confirmed, failed, dead-letter) are the difference between a hash and an operating model. That design is covered in durable transactions and ledger history. When both legs are on-ledger, atomic settlement and DvP belong in the same requirement: the asset leg and the cash leg finalize together or revert together.
4. Does custody stay with the institution?
Institutional custody is policy around keys. The bank already has a vault mandate: HSM, MPC, Fireblocks, DFNS, or another approved provider. A tokenization platform that forces a second custody product into that mandate creates a Risk problem before the first coupon.
What to require:
- Bring-your-own-custodian. The platform prepares, routes, tracks, and records. The vault signs.
- Two-person approval on every privileged action: mint, freeze, force transfer, recovery, maturity.
- Role boundaries, and a restartable recovery path.
- An honest boundary: the vendor is not the custodian, and the institution keeps regulatory accountability.
DALP's custody surface is documented in digital custody and custody and signing in DALP 3.0. SettleMint does not take the assets. It gives the operating team a controlled path around the vault the bank already chose.
5. Can Ops, Risk, and Audit run the same record?
Governance is the Monday-morning test. Who may approve a transfer? What is the limit? What happens when a holder needs an emergency freeze? Can Audit reconstruct balances as of a past date without rebuilding a spreadsheet?
A production platform gives named roles for issuance, compliance, custody, and administration before the asset goes live; two-person approval on critical operations; freezes, forced transfers, and recovery inside the same workflow that issued the asset; and a single event history that Ops, Compliance, and Audit can query. If the demonstration returns only a transaction hash, Ops does not have a product. Ask for one dual-control transfer, one managed failure, and one operator recovery. That evaluation brief is written out in Digital Asset Lifecycle Platform vs blockchain stack.
6. Does the platform cover the full asset lifecycle?
Issuance is one day. Servicing is the next decade. Asset lifecycle management is the set of controls that govern a tokenized instrument from design through custody, settlement, servicing, and retirement. The bank should see issuance, eligibility, custody routing, durable execution, settlement, servicing, and queryable history on one control plane. Class work after go-live lives on asset servicing.
Deployment has to match how the bank already runs infrastructure: on-prem, private cloud, or hybrid, on public or permissioned EVM networks the institution configures. DALP is EVM. Other ledger families sit outside the production track. Architecture detail is on the platform overview and in the DALP 3.0 documentation.
How should a bank evidence these requirements?
Ask for a walkable demonstration, then ask for production evidence. 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. Named programs such as OCBC's tokenized bonds and a current SOC 2 Type II report belong in that pack. For the operator view of the same platform, see Getting started with SettleMint DALP.
Want to score a live instrument against this brief? Book a call with the team.
FAQs about banking requirements for tokenization platforms
What compliance architecture should a bank require from a tokenization platform?
Ex-ante enforcement on ERC-3643-style identity and modular rules: eligibility, jurisdiction, caps, lock-ups, and approval gates checked before mint, transfer, or burn. Failures should return a typed reason. See DALP 3.0 compliance templates.
How should a tokenization platform integrate with core banking?
Through APIs, events, and payment-rail standards, with named transaction states while the chain and the vault catch up. DALP exposes REST, GraphQL, webhooks, a CLI, and MCP, and connects payment flows over ISO 20022 paths.
What custody model should a bank require?
Bring-your-own-custodian. Signing keys stay in the vault the bank already approved. The platform prepares, routes, tracks, and records, with two-person approval on privileged actions. DALP does not act as custodian. Detail: digital custody on DALP.
Which asset types should a bank-grade platform support?
The books the institution actually runs: bonds, funds, equity, deposits and other cash instruments, and the real-asset or structured cases on the roadmap. DALP ships templates for bonds, funds, equity, deposits, stablecoins, real estate, and precious metals, with a composable asset for the rest, across six asset classes. Start from DALP for tokenization.
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. Production programs such as OCBC's tokenized bonds and a current SOC 2 Type II report belong in that pack.
