Context
An institution was assessing how to bring a real-world asset onchain. The decision touched technology, but it was not primarily a software procurement exercise. The asset already existed inside an operating model with custody responsibilities, settlement expectations, compliance processes, reporting obligations, and controls around who could make or approve changes. Any onchain design had to fit those responsibilities or explain how they would change.
The institution needed an RFP that could do more than collect vendor feature lists. It had to turn internal requirements into an evaluation framework, expose dependencies early, and make materially different delivery models comparable. That meant joining advisory, technical architecture, diligence, and engagement design in one piece of work.
Challenge
The starting requirements were expressed in institutional terms: ownership records, service-provider roles, asset servicing, investor eligibility, reconciliation, reporting, business continuity, and accountability. Candidate implementers would naturally answer in platform terms: token standards, wallets, custody products, settlement networks, integration APIs, and deployment services. Without translation, both sides could appear aligned while describing different systems.
Several decisions were tightly coupled. A custody model affected transaction authorization and recovery. Settlement design affected when the institution considered ownership final. Compliance controls affected transferability, exception handling, and data retention. Reporting depended on which system was authoritative and how onchain events were reconciled with internal books. Vendor responsibilities affected the long-term operating model, not just implementation.
The RFP also had to avoid prematurely selecting an architecture. If it prescribed one stack too early, it would reduce the value of the market process. If it remained abstract, responses would be difficult to compare and important risk would be deferred until contracting or delivery.
Approach
We began by mapping the asset's lifecycle rather than drafting a questionnaire. The map covered issuance, distribution, transfer, servicing, redemption or maturity, exceptional events, and record reconciliation. At each stage, we identified the responsible role, the required evidence, the system of record, and the condition that marked the stage complete.
That lifecycle became a set of requirements across six connected areas. The operating model described responsibilities during normal and exceptional conditions. Custody requirements covered authorization, segregation, recovery, and changes of provider. Settlement requirements made timing, finality, cash or asset coordination, and reconciliation explicit. Compliance requirements distinguished policy decisions from technical enforcement and required bidders to explain exceptions. Reporting requirements covered data lineage, completeness, and access. Integration requirements described the boundaries with existing institutional systems.
We translated each important requirement into a response format that could be evaluated. Where possible, bidders had to provide an architecture, dependency, control owner, test method, and evidence rather than a yes-or-no assertion. Decision criteria separated mandatory controls from areas where the institution could compare tradeoffs. Open assumptions were visible so an attractive proposal could not hide an unresolved operating dependency.
The engagement process was designed alongside the document. Clarification questions were grouped and answered consistently. Architecture workshops focused on divergent assumptions rather than repeating written responses. Evaluation materials recorded the reason for each score and the conditions attached to it. This gave stakeholders a common basis for decisions across legal, operational, risk, and technical disciplines without asking every reviewer to become a protocol engineer.
Making dependencies testable
A good RFP changes when uncertainty is discovered. Instead of allowing custody, compliance, data, or settlement dependencies to surface during build, it asks bidders to show how those dependencies affect the proposed system and how they will be verified. It also distinguishes a product capability from a complete operating control.
For example, supporting a transfer restriction is not the same as defining who maintains eligibility, how stale evidence is handled, what happens during provider downtime, and how an exception is reviewed. The RFP used that level of decomposition across the system. This improved comparability while leaving room for different credible architectures.
Outcome
The RFP and engagement process are grounded in the asset's actual operating requirements. Responses are assessed against explicit responsibilities, interfaces, controls, evidence, and decision criteria rather than marketing claims or platform preferences.
The process creates a durable decision record. Stakeholders see which risks are controlled by design, which depend on a service provider, which require institutional process, and which remain choices for later stages. The procurement decision is separated from technical conclusions.
What this demonstrates
Tokenization work often begins before code. Matariki can translate institutional intent into a technical and operating specification, structure a market engagement, and evaluate whether proposed systems make their dependencies and risks testable. The same method applies when an organization needs to make a complex digital-asset decision before committing to a builder or stack.
Confidentiality
This study does not identify the institution, asset, candidate vendors, proposed architectures, evaluation results, or commercial process. It describes the advisory method and the categories of decision involved.