United States · SEC · Transfer agents
In the United States, the official record of who owns a security is the transfer agent's master securityholder file, and keeping it is a registered activity. So Tokenistry does not sell to US issuers directly. It licenses the tokenization stack to registered transfer agents, who keep the file, the keys and the responsibility. This page maps the SEC's September 2026 proposal for onchain records to what that stack does, gaps included.
Core runs single-tenant in your own cloud account. Every key that can change the record sits with you, and Tokenistry holds none of them. You tokenize the issues you already service, without handing the file to a platform.
Talk to your transfer agent. Tokenistry does not operate deployments for US issuers or keep US securityholder records. If your transfer agent wants to tokenize your issue, this is the page to send them.
Three SEC texts frame this. In May 2025 the Division of Trading and Markets said in its FAQs that a registered transfer agent may use distributed ledger technology as its official master securityholder file, and may keep personal information off chain. In January 2026 staff of three divisions said tokenized securities remain securities, and described how they are structured. On 1 September 2026 the Commission proposed the first substantive rewrite of the transfer agent rules since the early 1980s, written to accommodate blockchain records. It is a proposal: comments are due by 3 November 2026, and the final rules may differ.
The January 2026 staff statement separates issuer-sponsored from third-party-sponsored tokenized securities, and the proposal would have transfer agents count the issues they service by that split on Form TA-2.
| Model | Where the master securityholder file is | What Core does |
|---|---|---|
| Issuer-sponsored, blockchain as the file | On one or more networks, as the file or a component of it; a transfer on chain is a transfer on the file. | Positions are derived from confirmed chain state, lot by lot, and joined to holder names and addresses kept in your own system. |
| Issuer-sponsored, file kept off chain | In your book-entry system; the token is used to effect transfers that are then recorded on the file. | Token operations follow your system, and the Ownership Engine reports where chain state and the file stop agreeing. |
| Third-party-sponsored | Not the issuer's file: a custodial entitlement or a linked security created by a third party. | Not what this page covers. Those products carry their own broker-dealer and custody questions. |
Paraphrased rather than quoted, taken from the proposed rule text, and not legal advice. The right-hand column is what the software does, not a claim that using it satisfies a rule, and the final rules may change any row.
| Rule | What the proposal asks for | What Core does |
|---|---|---|
| 17ad-9(b) Master securityholder file |
Electronic, possibly multiple linked files or systems, with the technology at the transfer agent's discretion, provided the transfer agent keeps exclusive control of the file at all times. | Every function that changes the record on chain, including mint, burn, freeze, forced transfer, eligibility administration, role grants and contract upgrades, is a separate role. In a licensed deployment each of those keys sits with the transfer agent, and Tokenistry holds none. |
| 17ad-9(a) Position detail |
A unique security identifier, shares or principal amount, the holder's full name, contact information including a physical mailing address, and issue and cancellation dates. | Addresses, quantities and issuance history are on chain. Names and addresses stay in your system: the Ownership Engine maps each wallet to your investor identifier, so the two join into position detail. |
| 17ad-9(g), 17ad-10(g) Record differences, overissuance |
A file that does not match the control book or the transfer journal is a record difference; an overissuance the transfer agent caused must be bought in within 60 days. | Supply on chain gives the outstanding figure to hold against your control book, and the Ownership Engine flags positions whose history does not reconcile with chain state, so differences surface as a queue rather than at examination. |
| 17ad-10(a) Posting |
Post to the file within the shorter of one business day or the settlement cycle under Rule 15c6-1(a). | Where the chain is the file, the transfer is the posting. Positions update once a transfer reaches the confirmation depth you set for the network. |
| 17ad-10(f), 17ad-7(a) Retention |
Keep deleted position detail for six years from deletion, and most records for at least six years, the first two in an easily accessible place. | Chain history is not deleted, and the Ownership Engine keeps lot history and provenance in your database. Retention is your policy, on infrastructure you control. |
| 17ad-7(f)(2) Electronic recordkeeping controls |
Protection against unauthorized change, immediate production in human-readable and usable electronic form, an audit trail recording the identity of the user and the time of each action, and recovery of lost records. | Changes on chain happen only through roles, and every authority operation is recorded with the key that signed it and its parameters. Two gaps: Core records which key signed, not which person asked, so the user-level trail comes from your application; and human-readable reports are built on Core's API rather than shipped with it. |
| 17ad-7(h) Records held by third parties |
A third party keeping the transfer agent's records files a written undertaking with the SEC, and the transfer agent needs independent access without the third party's intervention. The proposal asks whether blockchain records give that access. | A licensed deployment runs in your account against your databases, so Core does not put your records with Tokenistry. You read the chain through a node or RPC provider you choose, and running your own takes that third party out of the path. |
| 17ad-7(i) Ceasing to act |
Deliver the required records to the issuer or its designee, such as a successor transfer agent, within 15 calendar days. | The contracts stay on chain. Handing over is a role transfer to the successor, which is itself an authority operation, plus an export of what your databases hold. |
| 17ad-12 Comprehensive risk management |
Written policies protecting securities and funds against theft, loss, misuse and unauthorized access; managing custody, operational and cybersecurity risk; a "for the benefit of" bank account; and a business continuity plan tested at least annually. | Authority keys stay in your custody workspace; operations survive failed submissions, degraded RPC endpoints and chain reorganizations. The plan and the bank account are yours. No external audit of the contracts has been completed yet, which your risk policies should name. |
| 17ad-31 Restrictive legends |
Act on legend instructions only from a listed set of issuer employees, and do not facilitate unregistered transactions without a reasonable basis under Section 5(a). | Restrictions are enforced in the token: a wallet without permission cannot receive, and lifting a restriction is a permission change signed by a key you hold. The Section 5 judgment and the list of instructing employees are yours. |
| Form TA-2 Questions 4(e), 5(b), 6(b) |
Report issues whose file is kept on distributed ledger technology, name tokenization agents and DLT platforms among service providers, and count issues by tokenization model. | Tokenistry would be listed as a service provider under whichever category your counsel reads it into, the network as the DLT platform, and each issue under the model in the table above. |
Sources: SEC, Transfer Agent Rules, Release No. 34-106246 (proposed 1 September 2026; Federal Register, 4 September 2026); Statement on Tokenized Securities (28 January 2026).
| Firm | Typical starting point | What matters most |
|---|---|---|
| Registered transfer agents | Tokenizing issues they already service, with the file in their own systems | Exclusive control, independent access to the records, a Form TA-2 they can complete |
| Broker-dealers & ATSs | Holding or trading tokenized securities whose file sits with a transfer agent | Eligibility enforced in the token, and reconciliation against chain state |
| Banks & trust companies | Safekeeping tokenized securities for clients | Signing through their own custody, positions per client across wallets |
| US issuers | Not directly | Your transfer agent keeps the file; if it wants to tokenize, it can license this |
Tokenistry is not a registered transfer agent, broker-dealer or investment adviser, does not perform transfer agent functions, and does not operate deployments for US securities. It licenses software to the firms that are registered.
Licensed only: container images, a Helm chart and Terraform modules in the transfer agent's own cloud account, in a US region, against databases it holds and with its keys in its own custody workspace. Source escrow and documented exit provisions are available where continuity has to be evidenced. More on the model under for institutions.
SEC staff said in May 2025 that a registered transfer agent may use distributed ledger technology as its official master securityholder file if it complies with the applicable rules. The September 2026 proposal would write that into Rule 17ad-9(b): any technology, as a whole file or a component of one, provided the transfer agent keeps exclusive control at all times. The proposal is not yet final.
No. The record of ownership for a US security belongs with a registered transfer agent, so Tokenistry licenses its software to transfer agents and does not operate deployments for US issuers. If you are an issuer, the conversation starts with your transfer agent.
The proposal does not prescribe a design. The practical reading is that the transfer agent holds every key that can change the record: minting, burning, freezing, forced transfer, eligibility administration, role grants and upgrades. In Core each is a separate role, and a licensed deployment leaves all of them with the transfer agent. How your counsel reads the requirement is what decides.
SEC staff said in May 2025 that transaction information may sit on a blockchain with personal information off chain, as long as the records are secure, accurate, current and producible to the Commission. The proposal asks how onchain records such as wallet address and quantity should be associated with offchain records such as name and address. Core keeps that association by mapping wallets to your investor identifiers.
Partly. Every authority operation is recorded with the key that signed it and its parameters, and every change on chain is permanent. Which person asked for an operation is not recorded by Core, whose APIs sit inside your network boundary, so that part of the trail comes from the application your staff use.
In a licensed deployment, Core runs in your cloud account against databases you hold, so your records are in your systems rather than ours. How the network or node provider you read the chain through should be treated is a question the proposal itself asks, and one for your counsel.
Both issuer-sponsored models in the SEC staff taxonomy: the blockchain as the master securityholder file or a component of it, and a file kept off chain with the token used to effect transfers. Third-party custodial and synthetic tokenized securities are a different product, with their own broker-dealer and custody questions.
Not yet by an external firm. Rule 17ad-12 as proposed would have your risk policies address operational and cybersecurity risk, so ask where our audit stands before you rely on the contracts.
The proposal would require the records to reach the issuer or a successor within 15 calendar days. The contracts stay on chain, so the handover is a role transfer to the successor, signed by your keys, plus an export of what your databases hold.
No. The September 2026 release is a proposal with comments due by 3 November 2026, and the January 2026 staff statement has no legal force of its own. Check the adopted rules before relying on any row on this page.
Tell us how you keep the master securityholder file today and which issues you have in mind. We will go through the proposal's recordkeeping rules with you and say what Core covers and what stays in your systems.
Talk to us as a transfer agent