A build-led guide to designing the secondary-trading layer of a tokenization platform. Written for founders, product owners, and engineering leads. It is not legal advice; the regulatory calls belong to your counsel, and the job of the software is to make their answers easy to apply.
Secondary trading is usually where a tokenization project moves from issuance design into market-infrastructure design. The asset exists, investors hold it, and the question shifts from how to create the tokenized security to how an investor can sell it later without turning the platform into a regulated trading venue.
In our work at Aetsoft building tokenization platforms, this is where teams tend to underestimate the job. The visible part, a screen that shows who wants to buy and sell, is the small part. The real work is the regulated workflow underneath it. This guide walks through that workflow: what a compliant bulletin board is, where the legal line sits, who needs access to the software, how a single trade moves through the system, the custody and ownership choices that shape the build, and the checks you need before you launch.
TL;DR
- A compliant bulletin board is a secondary-trading module added to a tokenization platform after primary issuance. It lets eligible investors see buying and selling interest in a tokenized security.
- It must not match orders, execute trades, or let investors negotiate directly. Under MiFID II, if a system lets multiple third-party buying and selling interests in financial instruments interact, it can move into multilateral-system and trading-venue territory even before a completed trade shows up on the platform.
- The actual trade runs through a regulated workflow: an investment firm reviews and authorises, a custodian or the investor signs the transfer, a registrar records ownership, and reporting runs.
- A tokenized security is a financial instrument under MiFID II and national securities law, not a crypto-asset under MiCA. MiCA only matters at the edges, for example when a regulated stablecoin is used for the cash leg.
- The real cost is not the board. It is connecting that board to everything the platform already does: checking who is allowed to trade, holding the assets, keeping the ownership record straight, settling the cash, reporting, and handling the cases that go wrong.
Why secondary trading becomes the hard part after issuance
Once the tokenized security has been issued and investors hold it, the next challenge is giving them a credible way to sell later. This is where many projects stall, usually for two reasons.
The first is regulatory. A token can be easy to move from one wallet to another, but the security behind it cannot move freely. Every transfer has to respect who is allowed to hold the asset, the resale rules, the ownership record, custody, and reporting. A free wallet-to-wallet transfer is simple to build and almost always wrong for a regulated instrument.
The second reason is commercial, and teams usually notice it last. Even a perfectly compliant venue is empty without buyers. The software does not create liquidity. Liquidity comes from distribution, from having eligible investors who actually want the asset. We come back to this near the end, because it should change what you build first.
What a compliant bulletin board is
A compliant bulletin board is a place where eligible investors can see buying and selling interest in a tokenized security, while the trade itself is reviewed, approved, and settled through a regulated workflow. The key part is that it shows interest and does not complete trades.
That one sentence carries the whole design. Everything else in this guide is about what sits behind the display, so that an indication of interest can become a settled trade without the platform crossing the legal line.
How a primary issuance platform evolves into a secondary trading platform
Most clients do not arrive asking for a bulletin board. They arrive with a primary issuance platform, or a plan for one. That platform onboards the issuer and the investors, runs KYC and AML checks, handles subscriptions and documents, issues the token, sets up custody or wallets, keeps the ownership record, and reports. Its job at that stage is to create the tokenized security and place it with investors.
After issuance, a new question shows up: what happens when an investor wants out? The bulletin board is the answer, and it is best thought of as a new layer on that same platform, not a separate product bolted on beside it. This is the practical core of the tokenization product.
The bulletin board is one stage in a platform’s life, not a separate product.
It works because the issuance platform already holds everything a resale needs. It knows who the investors are, which of them passed onboarding, what they hold, which restrictions apply, who holds the keys, which register is authoritative, and what has to be reported. The secondary layer reuses all of that.
| Platform layer | Primary issuance | Secondary trading extension |
| Investor data | Onboarding, KYC, AML, investor category | Reuse eligibility for secondary visibility and transfer checks |
| Asset data | Offering terms, token details, restrictions | Apply transfer rules, lock-ups, resale limits, jurisdiction checks |
| Investor portal | Subscribe, sign documents, view holdings | Show buying and selling interest, submit an instruction |
| Admin console | Manage issuance and investors | Manage interests, exceptions, approvals |
| Licensed firm workspace | May support primary distribution | Review instructions, decide the trade path |
| Custody / wallet layer | Issue or allocate tokens | Sign or approve secondary transfers |
| Register | Record initial ownership | Update ownership after each transfer |
| Reporting | Subscription records, investor statements | Transaction reports, audit trail, reconciliation |
| Compliance engine | Onboarding and issuance checks | Transfer restrictions, resale rules, cross-border limits |
Architecturally, this means the bulletin board is a thin new layer that plugs into services the platform already runs. The investor and firm log in on top, the new secondary layer sits in the middle, and underneath it are the shared services built at issuance: investor data and eligibility, the compliance rules, custody, the register, and reporting.
The secondary layer is thin. Most of the work is reusing the shared services the platform already runs.
The bulletin board is just the visible part of that extension. The harder work is wiring it into the platform you already have, so that a resale follows the same rules you set at issuance: the same checks on who can hold the asset, the same ownership record, the same custody, and the same compliance controls.
Where the board stops and trading-venue risk starts
The line usually comes from one rule in MiFID II. If your software brings multiple buyers and sellers together so they can interact and agree trades, it is a multilateral system, and a multilateral system has to be licensed as a trading venue. That means a Multilateral Trading Facility (MTF) or an Organised Trading Facility (OTF). Both come with capital requirements, market surveillance, and an authorisation process that takes years and rarely makes sense for a single issuer.
A bulletin board stays compliant only while it stays on the upper side of this line.
| Feature | Lower-risk bulletin board use | Higher-risk trading-venue territory |
| Show security information | Yes | |
| Show buying or selling interest | Yes | |
| Show price and size | Yes | |
| Submit an instruction to the licensed firm | Yes | |
| Buyer-to-seller chat or negotiation | Yes | |
| An accept button | Yes | |
| A match-found alert | Yes | |
| Automatic pairing of orders | Yes | |
| An order book | Yes | |
| In-system execution | Yes |
One point matters more than any single feature. The test is whether the system lets trading interests be brought together, not whether a deal actually completes. A system can cross the line even if no trade ever settles on it. Keeping the display short of any interaction is the heart of staying compliant. ESMA has also said that if the software provider, rather than the licensed firms using it, sets the rules for how orders meet, the provider itself can be running a trading venue. So the platform should display and route, and leave the matching logic to the licensed firm.
There is a second risk that decides whether the design holds. A regulator can look at the arrangement as a whole, not feature by feature. If the bulletin board, the broker workflow, and the custody flow run as one mechanical path, especially where the parties are affiliated or the firm has no real discretion, the structure can start to look like a trading venue in disguise. The protection here is not a clever interface. It is a real review and a real decision by the licensed firm on each trade.
A professional law team should accompany the project throughout architecture design and development phases.
MiFID vs MiCA for tokenized securities
A tokenized security is a financial instrument under MiFID II and national securities law. MiCA governs crypto-assets, and it does not replace securities law for these instruments. When the token stands for a share, a bond, or a fund unit, the securities rules apply: prospectus obligations, conduct rules, the trading-venue line, and transaction reporting.
MiCA can still touch parts of the setup at the edges. The clearest example is the cash leg of a trade. If it settles in a regulated stablecoin or e-money token, MiCA applies to that payment instrument, not to the security. In short, securities law drives the licensing, the perimeter, and most of the integrations, while MiCA shapes a few payment choices. The line between the two is fact-specific, so confirm it with counsel.
Who needs access to the software, and who does what
It helps to clear up one thing first. When the trade moves to a licensed firm, it does not move to a different website. Everyone works inside the same platform, each through their own login and permissions. The regulated decisions are made by the licensed people in their part of the system, not by the bulletin board on its own. The same platform can serve all actors, but the responsibility for each regulated step stays with the party licensed to perform it.
| Actor | What they see | What they do | What they must not control | Module |
| Platform owner | System data and workflow | Run the software | Keys and trade decisions | Whole platform |
| Investor | Listings and own holdings | List interest, submit an instruction | Other parties’ records | Investor portal |
| Investment firm | Instructions in its queue | Check eligibility, decide, authorise | — | Firm console |
| Tied agent, where used | Promotes and transmits | Pass instructions under the umbrella | Execution | Console |
| Custodian | Transfer requests | Approve and sign the transfer | The trade decision | Custody |
| Wallet infrastructure | Signing requests | Provide signing rails | Ownership of keys (in self-custody) | Wallet layer |
| Registrar / transfer agent | The ownership record | Update the authoritative record | The trade decision | Register |
| Compliance and reporting | Full audit view | Run checks, reports, reconciliation | — | Reporting |
Two of these are worth defining. The investment firm is a company licensed to do regulated work like handling client orders and executing trades, and it carries the liability for the trade decision. Many platform operators do not hold that licence, and they have no wish to spend the years and capital it takes to get one. The usual route is to act as a tied agent.
A tied agent is a business that is allowed to do certain regulated activities under the wing of an already-licensed firm, called the principal, which takes legal responsibility for the tied agent and supervises it. In that setup the platform acts as the tied agent for the regulated touchpoints, and the firm makes the decision and carries the liability.
How one secondary trade moves through the system
The flow below is the Alice-and-Bob story product teams know, broken into the steps that do the work. Alice lists a tokenized bond; Bob submits a buy instruction through the platform; it lands in the firm’s console, where someone checks both sides and authorises; the platform then arranges settlement, the token’s own rules check the buyer, the cash moves against the security, and the registrar and reports are updated.
The software carries the messages and runs the checks. The licensed actors make the decisions and move the asset.
A working system also says what happens when a step fails, because steps do fail. The cases to plan for are familiar: the buyer fails an eligibility check, the seller’s holding is locked or pledged, a signature fails or times out, the token’s rules block the move, the cash leg fails after the asset has moved, the chain and the register disagree on ownership, or the reporting data comes in incomplete. Each of these needs a defined, logged path, not an error screen.
The built-in compliance rules in step 5 are usually a permissioned token standard. ERC-3643, often called T-REX, is the established choice for regulated security tokens. It ties identity and transfer restrictions into the token itself, so a transfer to an unapproved holder simply fails on-chain. A newer and more minimal standard, ERC-7943 (also called uRWA), was finalized in 2026 and aims to be a vendor-neutral base layer that different tools can build on; it is meant to complement ERC-3643 rather than replace it, and adoption is still early and vendor-led. The principle is the same either way: the token checks eligibility on every transfer and blocks anything that does not pass. We cover the standards on their own in a separate guide.
Custody models and key control
Custody is the part of the product that most affects licensing, so choose it on purpose.
- In the first model, a regulated custodian holds the keys and signs once the firm authorises the trade.
- In the second, investors hold their own keys in self-custody, which takes the custodian out of the picture but makes recovery harder.
- In the third, the platform uses MPC and passkey wallet infrastructure such as DFNS or Fireblocks with policy controls, so the platform builds the transaction and the investor approves it with a passkey, and the platform never holds the keys on its own.
Whether the platform counts as a custodian in that third model depends on the full picture of control, recovery, and policy, not on the label you give it. It needs legal review, and you should not assume it is licence-light by default.
| Custodian model | Self-custody | MPC / passkey infrastructure | |
| Who controls keys | Custodian | Investor | Shared; investor authorises |
| Who approves a transfer | Custodian, on firm instruction | Investor | Investor passkey plus policy |
| Who can recover access | Custodian | Hard | Recoverable via infrastructure |
| Who can freeze or block | Custodian | Token rules only | Token rules plus policy |
| What must be logged | Every action | Every action | Every action |
The trade-off runs through the whole design. With a custodian, the power to freeze or reverse a transfer sits with a licensed party. With self-custody or passkey signing, that power has to live in the token’s own rules instead.
Ownership records: on-chain, off-chain, or hybrid
The legal record of who owns the security is separate from who holds the keys, and where it lives depends on the country. This is a legal choice with a technical consequence. The common thread is that every model keeps a legal register. What changes is where it lives.
Germany still has a register and a licensed registrar; the register simply lives on the chain.
In Switzerland the ledger entry itself is the record. In Germany the register sits on the blockchain, through a registrar licensed by BaFin under its electronic securities act, so it is on-chain but not registrar-free. In Luxembourg the legal record is kept off-chain by an account keeper or a control agent, and the token mirrors it. Whichever pattern you use, the platform has to say which record is authoritative and keep the other in step with it. Corporate actions, investor statements, and the audit trail all read from the authoritative record. If the chain and the register ever disagree about who owns a security, ownership becomes unclear, so reconciliation is a core feature of the product, not a clean-up task.
Settlement, reporting and reconciliation
Settlement should follow delivery versus payment, where the security and the cash move together so neither side is left exposed. Atomic on-chain settlement against regulated cash is the target. In practice, many setups still settle the cash leg off-chain today, through a bank payment or a regulated stablecoin, while the asset leg moves on-chain. A failed settlement needs a defined way to unwind, so a half-finished trade cannot leave the records in a mess.
Reporting sits under all of it: transaction reporting, investor confirmations, audit logs, and reconciliation across the platform, the chain, and the register. Tax reporting under CRS, CARF, and FATCA follows from how custody is set up, which is one more reason to decide the custody model early rather than late.
Cross-border controls
A MiFID firm’s passport lets it provide its service across the EU. It does not automatically let the security be offered or resold into every country, and it does not reach Switzerland, the United Kingdom, or the United States. A resale into the wrong jurisdiction can break local rules even when the trade looks fine on the platform. So the system has to check, before an instruction can go ahead, the investor’s jurisdiction and category, and whether the security may be offered or resold to that investor there.
We have covered this topic in-depth in our review of the cross-border tokenization problem in Europe.
| Investor | Key question the platform checks | Typical control |
| EU professional | Is the firm’s MiFID service passported into their country? | Usually allowed; record the category |
| EU retail | Same, plus retail protections and resale limits | Tighter checks; may restrict |
| Swiss | No EU passport into Switzerland; Swiss rules apply | Check Swiss eligibility separately |
| UK | No EU passport into the UK; UK rules apply | Check UK eligibility separately |
| US person | US securities and FATCA rules apply | Usually block, unless a US framework is in place |
| Existing holder vs new buyer | Is this trading among approved holders, or a fresh offer? | Run the resale-versus-new-offer check |
Liquidity and distribution: what the board does not solve
This is the point teams find last and should plan first. A bulletin board can help investors find trading interest, but it does not create demand on its own. Liquidity comes from distribution, from having eligible buyers who want the asset, and no amount of infrastructure creates that on its own.
Liquidity usually builds in steps rather than appearing at launch. It often starts with the bulletin board, where holders post interest. Next comes a broker-led workflow, where a licensed firm arranges each trade by hand. Then request-for-quote, where a buyer asks one or more dealers (firms that hold the asset and quote a price) for a price. And eventually a licensed venue with continuous, open trading, if the asset and the demand justify it.
The lesson is simple. Build the controlled transfer first, plan the distribution path on purpose, and do not over-build matching infrastructure before there are buyers to match.
When a bulletin board is enough, and when it is not
A bulletin board is usually enough when the investor base is controlled, when liquidity is occasional rather than continuous, when the issuer wants to offer an exit path rather than run a market, when a licensed firm reviews every trade, and when the asset is a private-market instrument such as a fund, a bond, or a real-estate vehicle.
It stops being enough when investors expect continuous trading, when orders need to be matched, when broader distribution is the goal, when pricing needs a deeper market to form, or when market makers, dealers, or venues are part of the model. That is where ATS-style models and DLT trading venues come in, which is a larger market-structure question we cover separately.
Build, connect, or partner
The platform rarely does everything itself. The realistic options are to build a controlled bulletin board and workflow, connect to a licensed investment firm, connect to custody or wallet infrastructure, connect to a registrar or transfer agent, connect to your KYC, AML, reporting, and settlement providers, and connect to a venue or distribution network where the model needs one.
One caution holds across all of them. An API connection does not solve the operating model. The platform still needs the right permissions, controls, records, and responsibilities built around that connection, which is the work this guide has described.
A compliant bulletin board is rarely just a new screen. It means extending the platform you already use for primary issuance, so the same investor checks, the licensed-firm review, custody or wallet signing, the ownership record, settlement, and reporting all carry through to resale.
You do not have to assemble that on your own. Alongside building the platform, Aetsoft brings the business, legal, and compliance partners a regulated project needs, including the licensed firms and legal umbrellas that let each regulated step run under proper authorisation. That means we can take a project from architecture and licensing through build, integration, and launch, and deliver the whole thing end to end, rather than leaving you to stitch separate vendors together.
Building secondary trading into a tokenization platform? Aetsoft designs and builds these systems end to end. Explore the Aetsoft STO Platform or talk to our blockchain consulting team.
This article is for general information only and does not constitute legal, regulatory, tax or investment advice. You should not construe any such information or other material as legal, tax, investment, financial or other advice. Nothing contained on our Site constitutes а solicitation, recommendation, endorsement, or offer by Aetsoft or any third party service provider to buy or sell any securities, tokens or other financial instruments.
FAQ
-
What is a compliant bulletin board for tokenized securities?
It is a controlled place where eligible investors can see buying and selling interest in a tokenized security, while the trade itself is reviewed, authorised, and settled through a regulated workflow. The board shows interest; it does not match or execute.
-
Is a bulletin board part of a tokenization platform?
Usually, yes. It is most often built as a new layer on the platform that handled primary issuance, reusing the same investor data, custody setup, ownership records, and compliance controls.
-
Can tokenized securities trade without a trading-venue licence?
They can, when the board is display-only and the trade runs through a licensed investment firm. Once the software lets buyers and sellers interact and agree trades in-system, it can need a trading-venue licence.
-
Is a tokenized security regulated under MiFID or MiCA?
It is a financial instrument under MiFID II and national securities law. MiCA governs crypto-assets and only applies at the edges, for example a regulated stablecoin used for settlement.
-
What is the difference between a bulletin board and an MTF?
A bulletin board shows interest. An MTF brings multiple buying and selling interests together so they can interact and trade, which is a licensed activity.
-
Who approves a secondary trade of tokenized securities?
A licensed investment firm checks eligibility and authorises the trade. The platform routes the instruction to it; the firm makes the regulated decision.
-
Who holds the keys in a secondary transfer?
Either a regulated custodian, or the investor in a self-custody or passkey setup using infrastructure such as DFNS or Fireblocks. The choice affects whether the platform counts as a custodian.
-
Which token standard do security tokens use?
Most regulated security tokens use a permissioned standard that checks eligibility on every transfer. ERC-3643 (T-REX) is the established option; ERC-7943 (uRWA) is a newer, more minimal standard meant to act as a neutral base layer. We cover the standards in a separate guide.
-
When is a bulletin board not enough?
When investors expect continuous trading, orders need matching, deeper liquidity or broader distribution is needed, or market makers and venues are part of the model. That points toward ATS-style trading or a DLT trading venue.
