The application layer
Tokenistry Core assumes a product team on the other side of the API. Plenty of issuers do not have one and should not need one. The Backoffice is that layer — investors, the instrument, the register and the day-to-day operations in one place, as a client of the same Core.
An issuing house placing an instrument needs somewhere to record who subscribed, who holds what, and what has been paid — and that record has to agree with the chain. Run it in a spreadsheet beside a token console and the two drift apart, which is the failure the Ownership Engine exists to catch. The Backoffice is the record, with the token operations attached to it rather than standing in a separate tool.
Who may hold, what they have been cleared for by your KYC provider, and which wallets belong to whom — so the register reads as a list of investors rather than a list of hex strings. Added by your staff, or over the API from the system that already holds the list.
Terms, supply, eligibility rules and the target chain, configured once per instrument and reused by every series issued under it.
What was committed, what was allotted, and the arithmetic between them — including scale-back — recorded before anything is minted against it.
Positions with lots and lineage, reconciled against indexed chain state rather than asserted by the application that wrote it. Queryable and exportable at any time.
Eligibility changes, issuance, freezing, forced transfer and redemption run from the record they affect, with the authority operations routed to your custody workspace for approval.
Named users, separated roles, and an append-only record of every operation and the person behind it — so an auditor's question is answered from the log rather than from memory.
The Backoffice is a client of Tokenistry Core, not a different product with its own chain code. An issuer running the Backoffice and an institution integrating Core directly are on the same engines, the same contracts and the same register.
Operations the instrument occasionally requires — freeze, forced transfer, redemption — are proposed here and signed in your own custody workspace. Nothing Tokenistry operates can move an investor's position.
A firm that wants the workflows but has systems to connect can reach the Backoffice over HTTP rather than choosing between the application and its own stack.
A read-only view of the same book, under your own name, is part of the product rather than a separate purchase — and it is started only if you want it. Where you distribute through a bank or a placement agent, your investors already log in somewhere, and a second portal is not an improvement.
For an issuer the deployment is operated by Tokenistry — no environment, no ops team and no deployment on your side. What stays with you is the authority key, in your own custody workspace.
If you build a technology function later, the deployment moves into your own environment and your team integrates Core directly. The instrument does not get rebuilt.
The Backoffice administers a tokenized instrument. It does not take on the roles around it.
Where local law makes register-keeping or safekeeping a licensed activity, that role belongs to your licensed provider and Tokenistry supplies the technology beneath it. Which applies is a question for your jurisdiction.
It is Core plus the application layer, sold as one thing. There is no version of the Backoffice that runs without Core underneath it, and no chain logic in the Backoffice that Core does not already own.
Probably not. Banks, custodians, fund administrators and firms with a product team usually keep their own books and integrate Core directly. The Backoffice exists for issuers who would otherwise administer an instrument in a spreadsheet.
You do. It is your record, exportable at any time, and reconciled against chain state rather than asserted. Where your jurisdiction makes register-keeping a licensed activity, that role belongs to your licensed provider and we supply the technology beneath it.
No. The authority to freeze, force a transfer or redeem sits in your own custody workspace under your approval policy. The Backoffice proposes those operations; it cannot sign them.
It is included and optional. The portal is a read-only view of the same book under your own name, deployed only if you want it — many issuing houses distribute through a bank or agent whose systems investors already use, and a second login helps nobody. It is not priced separately either way.
Yes. The Backoffice has a versioned HTTP API, and creating investors over it is the first thing most firms use it for — the list usually already exists in a KYC provider or a distributor's system, and nobody should be retyping it.
It records what was committed and what was allotted. Payment, banking and the pre-investment workflow stay with you and the providers you already use.
The register exports, the contracts are already on chain and readable without us, and a wind-down includes a runtime licence for a transition period. The instrument does not depend on the engagement continuing.
We will tell you whether you need the Backoffice or only the engines beneath it.
Discuss an issuance