Tokenized assets need market infrastructure beyond issuance: executable liquidity, collateral policy, settlement coordination and accountable operations. An institutional deployment starts by mapping the existing asset and servicing process, then defining the software needed around it. This guide connects a proposed liquidity workflow with deployment choices, responsibility boundaries and concrete engineering deliverables. The examples describe architecture, not an available financing or custody service.
Begin with the asset's existing operating model
A transferable token does not establish an executable market or a borrowing policy. Before adding infrastructure, map what the holder owns, how the asset moves, who can receive it and how value returns through redemption or sale. The issuer's records, custodian's controls and settlement instructions may each remain necessary after a token transfer.
The institutional architecture brief starts from this post-issuance problem. The proposed engineering mandate preserves the agreed issuance and servicing arrangements while adding the liquidity, risk and reconciliation mechanics required by a specific workflow.
State the constraint in measurable terms: a redemption takes time, collateral is fragmented, a permitted buyer cannot settle in the required asset, or operators cannot reconcile a payment to its request. That definition determines which components belong in the build and which existing systems remain authoritative.
Connect immediate liquidity to later issuer redemption
The following five-stage workflow is illustrative. T+0 describes the proposed earlier onchain payment; T+x describes the issuer's later settlement. Neither label guarantees an execution time or the availability of financing. Funding and operating arrangements must be established for the particular deployment.
- Approve the asset
Verify the asset, participant permissions, valuation source and redemption route. Establish which position will control the asset and which limits apply before a quote can be accepted.
- Accept an executable quote
Specify the settlement asset, advance amount, fees and expiry. Account for financing carry and defined uncertainty, and identify the party committed to funding the accepted transaction.
- Settle the earlier payment
Move the approved asset into the agreed control arrangement and deliver the quoted payment. Record the financing obligation and reserve the asset against that obligation.
- Follow issuer redemption
Register the request with its issuer reference, expected window and approved beneficiary. Track acknowledgment, delay or rejection while the issuer or appointed provider follows the existing process.
- Reconcile and close
Match actual proceeds to the request, apply repayment and fees, and complete the permitted transfer or burn. Close only reconciled obligations; partial receipt leaves an explicit residual exposure.
The digital asset credit guide develops the registry, position-control and exception-accounting details. The important distinction is that the earlier payment and final issuer settlement are separate events joined by an open obligation.
Choose the deployment perimeter explicitly
A public network and permissioned participation are separate choices. A workflow can use a public chain while restricting asset recipients, quoting counterparties or operator actions. Participant controls also do not, by themselves, make publicly recorded transaction data confidential. Specify access and information visibility independently.
| Decision | Options to evaluate | What the choice changes |
|---|---|---|
| Execution environment | Public network or a restricted network environment | Network dependencies, transaction access and operating controls |
| Participation | Open or approved participants for each action | Eligibility checks, permissions and recovery counterparties |
| Risk domain | Shared collateral, isolated positions or bounded groups | Which exposures can consume the same supporting assets |
| Settlement rail | Approved onchain asset or an external payment process | Finality evidence, timing, conversion and reconciliation |
| Integration scope | One asset workflow or a broader partner instance | Adapters, interfaces, validation effort and support responsibilities |
The partner-instance brief proposes configurable accounts, solvers and settlement modules. These are architecture choices to assess against a mandate; the brief does not establish that every combination is implemented or available.
Identify the authoritative record at every boundary
A deployment may connect an issuer register, custody system, smart-contract ledger, quote service and payment notification. For each boundary, name the authoritative event and the evidence needed to accept it. An issuer acknowledgment, an onchain transfer and a bank receipt establish different facts.
Define a common request identity across these systems, together with asset identifiers, units, timestamps and status mappings. Decide how corrections, duplicates and out-of-order messages are handled. A process should remain reconstructable when an operator changes or an integration is temporarily unavailable.
Settlement assets require their own design review. Supporting a stablecoin, a tokenized deposit or an external payment rail changes who can send and receive value, how availability is observed and what constitutes completion. Start with the selected rail's actual interface and operating conditions. A general ability to transfer tokens is insufficient evidence for an end-to-end settlement integration.
Assign responsibilities before assigning permissions
The operating map should identify who makes a decision, who executes it and who resolves an exception. Software permissions implement that map; they do not create funding, custody authority or a relationship with an issuer.
| Party or function | Responsibilities to establish |
|---|---|
| FT Inc engineering | Architecture, contract and adapter implementation, risk logic, testing and agreed integration support |
| Client product and risk owners | Permitted workflow, asset policy, exposure limits and acceptance criteria |
| Issuer and custody providers | Asset servicing, control arrangements, transfer instructions and redemption evidence within their assigned roles |
| Financing and execution counterparties | Committed funding or quotes, settlement obligations and defined capacity |
| Appointed operators | Reconciliation, monitoring, exception escalation and approved incident actions |
Confirm contractual and operating authority separately. FT Inc's role is technology development. The prime brokerage architecture guide explains how responsibility boundaries translate into narrower software roles.
Make discovery produce decisions and artifacts
A useful discovery scope starts with sample asset records, the current redemption or trade process, representative settlement timings and the parties involved. Include the awkward cases: rejected transfers, unavailable quotes, late proceeds and manual corrections. These reveal the real integration boundaries earlier than a polished normal-flow demonstration.
The resulting package should include an asset-and-party map, proposed transaction lifecycle, interface inventory, control matrix and unresolved assumptions. It should distinguish software that must be built from permissions, counterparties or operational inputs the client must arrange.
Finish with a bounded validation plan: one named workflow, its exposure limits, required evidence and conditions that would stop expansion. This makes the next engineering decision reviewable and keeps a broad institutional ambition from becoming an undefined integration project.
Validate the workflow with bounded exposure
A proposed pilot should exercise the complete lifecycle within an agreed perimeter. Simulated quotes can validate message formats; they cannot establish that a counterparty will fund a real transaction. Likewise, a successful callback test does not establish that the issuer's operational team will supply the required evidence.
Define acceptance criteria across both technology and operations: every request maps to its asset and obligation; duplicate messages do not create duplicate payments; partial settlement remains open; limits apply at execution; and a failed dependency produces an observable exception with an assigned owner.
Rehearse an overdue redemption, unavailable operator and rejected recipient. Record what happened, how long recovery took and which assumptions remained untested. Those results support a decision about the next scope; they are not interchangeable with a claim of production readiness.
Hand over the means to operate and change the system
An engineering handover should identify the deployed components, configuration, permissions, dependency versions and reconciliation reports. Provide runbooks for ordinary operation, exception handling, incident response and approved changes. Name the owners who can act on alerts and the evidence they need before doing so.
The operating model should explain how an asset is admitted or suspended, a limit changes, a signer rotates and an adapter is replaced while requests remain open. Historical records must retain the configuration that governed each transaction.
Start expansion from observed constraints: settlement reliability, executable capacity, unresolved exceptions and the quality of reconciliation. Add assets or modules only through a defined change process. The objective is a workflow that client teams can understand, supervise and recover, supported by software whose behavior matches the agreed mandate.
Common engineering questions
Does a tokenized asset require a new issuer or custodian?
Not necessarily. The proposed architecture starts by mapping the existing issuance, custody and servicing arrangements, then identifies the interfaces and controls needed around them. The final arrangement is specific to the asset and engagement.
Can permissioned workflows run on a public blockchain?
A design can restrict participants or particular actions while using a public network. The network, asset-transfer rules, counterparty access and information-visibility requirements are separate decisions to assess.
What should the first engineering engagement deliver?
A defined workflow, asset-and-party map, interface specification, controls and responsibility matrix, and a bounded validation plan. These artifacts identify implementation work and the external inputs needed before a deployment can proceed.