{"id":2054,"date":"2026-06-23T16:21:42","date_gmt":"2026-06-23T13:21:42","guid":{"rendered":"https:\/\/aetsoft.net\/blog\/?p=2054"},"modified":"2026-06-23T16:30:50","modified_gmt":"2026-06-23T13:30:50","slug":"compliant-bulletin-board-tokenized-securities","status":"publish","type":"post","link":"https:\/\/aetsoft.net\/blog\/compliant-bulletin-board-tokenized-securities\/","title":{"rendered":"How to build a compliant bulletin board for tokenized securities secondary trading"},"content":{"rendered":"<blockquote><p><span style=\"font-weight: 400;\">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.<\/span><\/p><\/blockquote>\n<p><span style=\"font-weight: 400;\">Secondary trading is usually where a tokenization project moves from issuance design into market-infrastructure design.<\/span> <span style=\"font-weight: 400;\">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.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">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.<\/span><\/p>\n<div id=\"TL;DR\" class=\"anchor\"><\/div>\n<h2><span style=\"font-weight: 400;\">TL;DR<\/span><\/h2>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">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.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">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.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">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.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">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.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">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.<\/span><\/li>\n<\/ul>\n<div id=\"Why secondary trading becomes the hard part after issuance\" class=\"anchor\"><\/div>\n<h2><span style=\"font-weight: 400;\">Why secondary trading becomes the hard part after issuance<\/span><\/h2>\n<p><span style=\"font-weight: 400;\">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.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">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.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">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.<\/span><\/p>\n<div id=\"What a compliant bulletin board is\" class=\"anchor\"><\/div>\n<h2><span style=\"font-weight: 400;\">What a compliant bulletin board is<\/span><\/h2>\n<p><span style=\"font-weight: 400;\">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.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">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.<\/span><\/p>\n<div id=\"How a primary issuance platform evolves into a secondary trading platform\" class=\"anchor\"><\/div>\n<h2><span style=\"font-weight: 400;\">How a primary issuance platform evolves into a secondary trading platform<\/span><\/h2>\n<p><span style=\"font-weight: 400;\">Most clients do not arrive asking for a bulletin board. They arrive with a <a href=\"https:\/\/aetsoft.net\/services\/sto-development\/\">primary issuance<\/a> 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.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">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.<\/span><\/p>\n<p>&nbsp;<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-medium wp-image-2055\" src=\"https:\/\/aetsoft.net\/blog\/wp-content\/uploads\/2026\/06\/1-1200x636.png\" alt=\"Tokenization platform evolving from primary issuance to a compliant bulletin board and secondary trading workflow\" width=\"1200\" height=\"636\" srcset=\"https:\/\/aetsoft.net\/blog\/wp-content\/uploads\/2026\/06\/1-1200x636.png 1200w, https:\/\/aetsoft.net\/blog\/wp-content\/uploads\/2026\/06\/1-768x407.png 768w, https:\/\/aetsoft.net\/blog\/wp-content\/uploads\/2026\/06\/1-1536x814.png 1536w, https:\/\/aetsoft.net\/blog\/wp-content\/uploads\/2026\/06\/1-2048x1086.png 2048w\" sizes=\"auto, (max-width: 1200px) 100vw, 1200px\" \/><\/p>\n<p>&nbsp;<\/p>\n<p><span style=\"font-weight: 400;\">The bulletin board is one stage in a platform&#8217;s life, not a separate product.<\/span><\/p>\n<p>&nbsp;<\/p>\n<p><span style=\"font-weight: 400;\">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.<\/span><\/p>\n<p>&nbsp;<\/p>\n<table>\n<tbody>\n<tr>\n<td><b>Platform layer<\/b><\/td>\n<td><b>Primary issuance<\/b><\/td>\n<td><b>Secondary trading extension<\/b><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Investor data<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Onboarding, KYC, AML, investor category<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Reuse eligibility for secondary visibility and transfer checks<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Asset data<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Offering terms, token details, restrictions<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Apply transfer rules, lock-ups, resale limits, jurisdiction checks<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Investor portal<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Subscribe, sign documents, view holdings<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Show buying and selling interest, submit an instruction<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Admin console<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Manage issuance and investors<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Manage interests, exceptions, approvals<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Licensed firm workspace<\/span><\/td>\n<td><span style=\"font-weight: 400;\">May support primary distribution<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Review instructions, decide the trade path<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Custody \/ wallet layer<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Issue or allocate tokens<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Sign or approve secondary transfers<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Register<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Record initial ownership<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Update ownership after each transfer<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Reporting<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Subscription records, investor statements<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Transaction reports, audit trail, reconciliation<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Compliance engine<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Onboarding and issuance checks<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Transfer restrictions, resale rules, cross-border limits<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>&nbsp;<\/p>\n<p><span style=\"font-weight: 400;\">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.<\/span><\/p>\n<p>&nbsp;<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-medium wp-image-2062\" src=\"https:\/\/aetsoft.net\/blog\/wp-content\/uploads\/2026\/06\/2-1-1200x640.png\" alt=\"Layered tokenization platform with the bulletin board as a new secondary layer on shared issuance services\" width=\"1200\" height=\"640\" srcset=\"https:\/\/aetsoft.net\/blog\/wp-content\/uploads\/2026\/06\/2-1-1200x640.png 1200w, https:\/\/aetsoft.net\/blog\/wp-content\/uploads\/2026\/06\/2-1-768x410.png 768w, https:\/\/aetsoft.net\/blog\/wp-content\/uploads\/2026\/06\/2-1-1536x820.png 1536w, https:\/\/aetsoft.net\/blog\/wp-content\/uploads\/2026\/06\/2-1-2048x1093.png 2048w\" sizes=\"auto, (max-width: 1200px) 100vw, 1200px\" \/><\/p>\n<p>&nbsp;<\/p>\n<p><span style=\"font-weight: 400;\">The secondary layer is thin. Most of the work is reusing the shared services the platform already runs.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">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.<\/span><\/p>\n<div id=\"Where the board stops and trading-venue risk starts\" class=\"anchor\"><\/div>\n<h2><span style=\"font-weight: 400;\">Where the board stops and trading-venue risk starts<\/span><\/h2>\n<p><span style=\"font-weight: 400;\">The line usually comes from one rule in <\/span><a href=\"https:\/\/eur-lex.europa.eu\/legal-content\/EN\/TXT\/?uri=CELEX:32014L0065\"><span style=\"font-weight: 400;\">MiFID II<\/span><\/a><span style=\"font-weight: 400;\">. 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.<\/span><\/p>\n<p>&nbsp;<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-medium wp-image-2057\" src=\"https:\/\/aetsoft.net\/blog\/wp-content\/uploads\/2026\/06\/3-1200x502.png\" alt=\"MiFID trading-venue perimeter: display-only bulletin board features versus features needing a venue licence\" width=\"1200\" height=\"502\" srcset=\"https:\/\/aetsoft.net\/blog\/wp-content\/uploads\/2026\/06\/3-1200x502.png 1200w, https:\/\/aetsoft.net\/blog\/wp-content\/uploads\/2026\/06\/3-768x321.png 768w, https:\/\/aetsoft.net\/blog\/wp-content\/uploads\/2026\/06\/3-1536x642.png 1536w, https:\/\/aetsoft.net\/blog\/wp-content\/uploads\/2026\/06\/3-2048x857.png 2048w\" sizes=\"auto, (max-width: 1200px) 100vw, 1200px\" \/><\/p>\n<p>&nbsp;<\/p>\n<p><span style=\"font-weight: 400;\">A bulletin board stays compliant only while it stays on the upper side of this line.<\/span><\/p>\n<p>&nbsp;<\/p>\n<table>\n<tbody>\n<tr>\n<td><b>Feature<\/b><\/td>\n<td><b>Lower-risk bulletin board use<\/b><\/td>\n<td><b>Higher-risk trading-venue territory<\/b><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Show security information<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Yes<\/span><\/td>\n<td><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Show buying or selling interest<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Yes<\/span><\/td>\n<td><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Show price and size<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Yes<\/span><\/td>\n<td><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Submit an instruction to the licensed firm<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Yes<\/span><\/td>\n<td><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Buyer-to-seller chat or negotiation<\/span><\/td>\n<td><\/td>\n<td><span style=\"font-weight: 400;\">Yes<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">An accept button<\/span><\/td>\n<td><\/td>\n<td><span style=\"font-weight: 400;\">Yes<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">A match-found alert<\/span><\/td>\n<td><\/td>\n<td><span style=\"font-weight: 400;\">Yes<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Automatic pairing of orders<\/span><\/td>\n<td><\/td>\n<td><span style=\"font-weight: 400;\">Yes<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">An order book<\/span><\/td>\n<td><\/td>\n<td><span style=\"font-weight: 400;\">Yes<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">In-system execution<\/span><\/td>\n<td><\/td>\n<td><span style=\"font-weight: 400;\">Yes<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>&nbsp;<\/p>\n<p><span style=\"font-weight: 400;\">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. <\/span><a href=\"https:\/\/www.esma.europa.eu\/press-news\/esma-news\/esma-issues-opinion-trading-venue-perimeter\"><span style=\"font-weight: 400;\">ESMA<\/span><\/a><span style=\"font-weight: 400;\"> 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.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">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.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">A professional law team should accompany the project throughout architecture design and development phases.<\/span><\/p>\n<div id=\"MiFID vs MiCA for tokenized securities\" class=\"anchor\"><\/div>\n<h2><span style=\"font-weight: 400;\">MiFID vs MiCA for tokenized securities<\/span><\/h2>\n<p><span style=\"font-weight: 400;\">A tokenized security is a financial instrument under MiFID II and national securities law. <\/span><a href=\"https:\/\/www.esma.europa.eu\/esmas-activities\/digital-finance-and-innovation\/markets-crypto-assets-regulation-mica\"><span style=\"font-weight: 400;\">MiCA<\/span><\/a><span style=\"font-weight: 400;\"> 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: <\/span><a href=\"https:\/\/eur-lex.europa.eu\/legal-content\/EN\/TXT\/?uri=CELEX:32017R1129\"><span style=\"font-weight: 400;\">prospectus obligations<\/span><\/a><span style=\"font-weight: 400;\">, conduct rules, the trading-venue line, and transaction reporting.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">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 <\/span><a href=\"https:\/\/aetsoft.net\/services\/stablecoin-development-company\/\"><span style=\"font-weight: 400;\">regulated stablecoin<\/span><\/a><span style=\"font-weight: 400;\"> 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.<\/span><\/p>\n<div id=\"Who needs access to the software, and who does what\" class=\"anchor\"><\/div>\n<h2><span style=\"font-weight: 400;\">Who needs access to the software, and who does what<\/span><\/h2>\n<p><span style=\"font-weight: 400;\">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.<\/span><\/p>\n<table>\n<tbody>\n<tr>\n<td><b>Actor<\/b><\/td>\n<td><b>What they see<\/b><\/td>\n<td><b>What they do<\/b><\/td>\n<td><b>What they must not control<\/b><\/td>\n<td><b>Module<\/b><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Platform owner<\/span><\/td>\n<td><span style=\"font-weight: 400;\">System data and workflow<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Run the software<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Keys and trade decisions<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Whole platform<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Investor<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Listings and own holdings<\/span><\/td>\n<td><span style=\"font-weight: 400;\">List interest, submit an instruction<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Other parties&#8217; records<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Investor portal<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Investment firm<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Instructions in its queue<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Check eligibility, decide, authorise<\/span><\/td>\n<td><span style=\"font-weight: 400;\">\u2014<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Firm console<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Tied agent, where used<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Promotes and transmits<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Pass instructions under the umbrella<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Execution<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Console<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Custodian<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Transfer requests<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Approve and sign the transfer<\/span><\/td>\n<td><span style=\"font-weight: 400;\">The trade decision<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Custody<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Wallet infrastructure<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Signing requests<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Provide signing rails<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Ownership of keys (in self-custody)<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Wallet layer<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Registrar \/ transfer agent<\/span><\/td>\n<td><span style=\"font-weight: 400;\">The ownership record<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Update the authoritative record<\/span><\/td>\n<td><span style=\"font-weight: 400;\">The trade decision<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Register<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Compliance and reporting<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Full audit view<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Run checks, reports, reconciliation<\/span><\/td>\n<td><span style=\"font-weight: 400;\">\u2014<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Reporting<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>&nbsp;<\/p>\n<p><span style=\"font-weight: 400;\">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. <\/span><\/p>\n<p><span style=\"font-weight: 400;\">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.<\/span><\/p>\n<div id=\"How one secondary trade moves through the system\" class=\"anchor\"><\/div>\n<h2><span style=\"font-weight: 400;\">How one secondary trade moves through the system<\/span><\/h2>\n<p><span style=\"font-weight: 400;\">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&#8217;s console, where someone checks both sides and authorises; the platform then arranges settlement, the token&#8217;s own rules check the buyer, the cash moves against the security, and the registrar and reports are updated.<\/span><\/p>\n<p>&nbsp;<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-medium wp-image-2056\" src=\"https:\/\/aetsoft.net\/blog\/wp-content\/uploads\/2026\/06\/4-1200x629.png\" alt=\"Seven-step secondary trade flow for tokenized securities, from investor order to firm approval and settlement\" width=\"1200\" height=\"629\" srcset=\"https:\/\/aetsoft.net\/blog\/wp-content\/uploads\/2026\/06\/4-1200x629.png 1200w, https:\/\/aetsoft.net\/blog\/wp-content\/uploads\/2026\/06\/4-768x402.png 768w, https:\/\/aetsoft.net\/blog\/wp-content\/uploads\/2026\/06\/4-1536x805.png 1536w, https:\/\/aetsoft.net\/blog\/wp-content\/uploads\/2026\/06\/4-2048x1073.png 2048w\" sizes=\"auto, (max-width: 1200px) 100vw, 1200px\" \/><\/p>\n<p><span style=\"font-weight: 400;\">The software carries the messages and runs the checks. The licensed actors make the decisions and move the asset.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">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&#8217;s holding is locked or pledged, a signature fails or times out, the token&#8217;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.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">The <a href=\"https:\/\/aetsoft.net\/services\/smart-contract-development-company\/\">built-in compliance rules<\/a> in step 5 are usually a permissioned token standard. <\/span><a href=\"https:\/\/eips.ethereum.org\/EIPS\/eip-3643\"><span style=\"font-weight: 400;\">ERC-3643<\/span><\/a><span style=\"font-weight: 400;\">, 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, <\/span><a href=\"https:\/\/eips.ethereum.org\/EIPS\/eip-7943\"><span style=\"font-weight: 400;\">ERC-7943<\/span><\/a><span style=\"font-weight: 400;\"> (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.<\/span><\/p>\n<div id=\"Custody models and key control\" class=\"anchor\"><\/div>\n<h2><span style=\"font-weight: 400;\">Custody models and key control<\/span><\/h2>\n<p><span style=\"font-weight: 400;\">Custody is the part of the product that most affects licensing, so choose it on purpose.\u00a0<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">In the first model, a regulated custodian holds the keys and signs once the firm authorises the trade.\u00a0<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">In the second, investors hold their own keys in self-custody, which takes the custodian out of the picture but makes recovery harder.\u00a0<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">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.\u00a0<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">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.<\/span><\/p>\n<p>&nbsp;<\/p>\n<table>\n<tbody>\n<tr>\n<td><\/td>\n<td><b>Custodian model<\/b><\/td>\n<td><b>Self-custody<\/b><\/td>\n<td><b>MPC \/ passkey infrastructure<\/b><\/td>\n<\/tr>\n<tr>\n<td>Who controls keys<\/td>\n<td>Custodian<\/td>\n<td>Investor<\/td>\n<td>Shared; investor authorises<\/td>\n<\/tr>\n<tr>\n<td>Who approves a transfer<\/td>\n<td>Custodian, on firm instruction<\/td>\n<td>Investor<\/td>\n<td>Investor passkey plus policy<\/td>\n<\/tr>\n<tr>\n<td>Who can recover access<\/td>\n<td>Custodian<\/td>\n<td>Hard<\/td>\n<td>Recoverable via infrastructure<\/td>\n<\/tr>\n<tr>\n<td>Who can freeze or block<\/td>\n<td>Custodian<\/td>\n<td>Token rules only<\/td>\n<td>Token rules plus policy<\/td>\n<\/tr>\n<tr>\n<td>What must be logged<\/td>\n<td>Every action<\/td>\n<td>Every action<\/td>\n<td>Every action<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>&nbsp;<\/p>\n<p><span style=\"font-weight: 400;\">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&#8217;s own rules instead.<\/span><\/p>\n<div id=\"Ownership records: on-chain, off-chain, or hybrid\" class=\"anchor\"><\/div>\n<h2><span style=\"font-weight: 400;\">Ownership records: on-chain, off-chain, or hybrid<\/span><\/h2>\n<p><span style=\"font-weight: 400;\">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.<\/span><\/p>\n<p>&nbsp;<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-medium wp-image-2059\" src=\"https:\/\/aetsoft.net\/blog\/wp-content\/uploads\/2026\/06\/5-1200x486.png\" alt=\"Where the legal register lives for tokenized securities in Switzerland, Germany, and Luxembourg\" width=\"1200\" height=\"486\" srcset=\"https:\/\/aetsoft.net\/blog\/wp-content\/uploads\/2026\/06\/5-1200x486.png 1200w, https:\/\/aetsoft.net\/blog\/wp-content\/uploads\/2026\/06\/5-768x311.png 768w, https:\/\/aetsoft.net\/blog\/wp-content\/uploads\/2026\/06\/5-1536x622.png 1536w, https:\/\/aetsoft.net\/blog\/wp-content\/uploads\/2026\/06\/5-2048x830.png 2048w\" sizes=\"auto, (max-width: 1200px) 100vw, 1200px\" \/><\/p>\n<p><span style=\"font-weight: 400;\">Germany still has a register and a licensed registrar; the register simply lives on the chain.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">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 <\/span><a href=\"https:\/\/www.arendt.com\/news-insights\/news\/luxembourgs-blockchain-law-iv-groundbreaking-new-options-for-issuing-dlt-securities\/\"><span style=\"font-weight: 400;\">control agent<\/span><\/a><span style=\"font-weight: 400;\">, 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.<\/span><\/p>\n<div id=\"Settlement, reporting and reconciliation\" class=\"anchor\"><\/div>\n<h2><span style=\"font-weight: 400;\">Settlement, reporting and reconciliation<\/span><\/h2>\n<p><span style=\"font-weight: 400;\">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 <a href=\"https:\/\/aetsoft.net\/services\/stablecoin-development-company\/\">regulated stablecoin<\/a>, 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.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">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 <\/span><a href=\"https:\/\/www.oecd.org\/en\/topics\/international-standards-on-tax-transparency.html\"><span style=\"font-weight: 400;\">CRS, CARF<\/span><\/a><span style=\"font-weight: 400;\">, and <\/span><a href=\"https:\/\/www.irs.gov\/businesses\/corporations\/foreign-account-tax-compliance-act-fatca\"><span style=\"font-weight: 400;\">FATCA<\/span><\/a><span style=\"font-weight: 400;\"> follows from how custody is set up, which is one more reason to decide the custody model early rather than late.<\/span><\/p>\n<div id=\"Cross-border controls\" class=\"anchor\"><\/div>\n<h2><span style=\"font-weight: 400;\">Cross-border controls<\/span><\/h2>\n<p><span style=\"font-weight: 400;\">A MiFID firm&#8217;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&#8217;s jurisdiction and category, and whether the security may be offered or resold to that investor there.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">We have covered this topic in-depth in our review of the <\/span><a href=\"https:\/\/aetsoft.net\/blog\/cross-border-tokenization-switzerland-eu\/\"><span style=\"font-weight: 400;\">cross-border tokenization problem in Europe<\/span><\/a><span style=\"font-weight: 400;\">.<\/span><\/p>\n<p>&nbsp;<\/p>\n<table>\n<tbody>\n<tr>\n<td><b>Investor<\/b><\/td>\n<td><b>Key question the platform checks<\/b><\/td>\n<td><b>Typical control<\/b><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">EU professional<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Is the firm&#8217;s MiFID service passported into their country?<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Usually allowed; record the category<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">EU retail<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Same, plus retail protections and resale limits<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Tighter checks; may restrict<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Swiss<\/span><\/td>\n<td><span style=\"font-weight: 400;\">No EU passport into Switzerland; Swiss rules apply<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Check Swiss eligibility separately<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">UK<\/span><\/td>\n<td><span style=\"font-weight: 400;\">No EU passport into the UK; UK rules apply<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Check UK eligibility separately<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">US person<\/span><\/td>\n<td><span style=\"font-weight: 400;\">US securities and FATCA rules apply<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Usually block, unless a US framework is in place<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Existing holder vs new buyer<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Is this trading among approved holders, or a fresh offer?<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Run the resale-versus-new-offer check<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>&nbsp;<\/p>\n<div id=\"Liquidity and distribution: what the board does not solve\" class=\"anchor\"><\/div>\n<h2><span style=\"font-weight: 400;\">Liquidity and distribution: what the board does not solve<\/span><\/h2>\n<p><span style=\"font-weight: 400;\">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.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">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.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">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.<\/span><\/p>\n<div id=\"When a bulletin board is enough, and when it is not\" class=\"anchor\"><\/div>\n<h2><span style=\"font-weight: 400;\">When a bulletin board is enough, and when it is not<\/span><\/h2>\n<p><span style=\"font-weight: 400;\">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 <a href=\"https:\/\/aetsoft.net\/services\/tokenized-funds\/\">fund<\/a>, a bond, or a <\/span><a href=\"https:\/\/aetsoft.net\/services\/real-estate-tokenization\/\"><span style=\"font-weight: 400;\">real-estate vehicle<\/span><\/a><span style=\"font-weight: 400;\">.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">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.<\/span><\/p>\n<h2>Build, connect, or partner<\/h2>\n<p><span style=\"font-weight: 400;\">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.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">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.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">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.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">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.<\/span><\/p>\n<p>Building secondary trading into a tokenization platform? Aetsoft designs and builds these systems end to end. <a href=\"https:\/\/aetsoft.net\/products\/sto-platform\/\">Explore the Aetsoft STO Platform<\/a> or <a href=\"https:\/\/aetsoft.net\/services\/blockchain-consulting\/\">talk to our blockchain consulting team<\/a>.<\/p>\n<p><i>This article is for general information only and does not constitute legal, regulatory, tax or investment advice.\u00a0<\/i><em>You should not construe any such information or other material as legal, tax, investment, financial or other advice. Nothing contained on our Site constitutes \u0430 solicitation, recommendation, endorsement, or offer by Aetsoft or any third party service provider to buy or sell any securities, tokens or other financial instruments.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"<p>A build-led guide to designing the secondary-trading layer of a tokenization platform. Written for founders, product owners, and engineering leads&#8230;.<\/p>\n","protected":false},"author":18,"featured_media":2060,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[7],"tags":[41],"class_list":["post-2054","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog","tag-tokenization"],"aioseo_notices":[],"acf":[],"_links":{"self":[{"href":"https:\/\/aetsoft.net\/blog\/wp-json\/wp\/v2\/posts\/2054","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/aetsoft.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/aetsoft.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/aetsoft.net\/blog\/wp-json\/wp\/v2\/users\/18"}],"replies":[{"embeddable":true,"href":"https:\/\/aetsoft.net\/blog\/wp-json\/wp\/v2\/comments?post=2054"}],"version-history":[{"count":24,"href":"https:\/\/aetsoft.net\/blog\/wp-json\/wp\/v2\/posts\/2054\/revisions"}],"predecessor-version":[{"id":2086,"href":"https:\/\/aetsoft.net\/blog\/wp-json\/wp\/v2\/posts\/2054\/revisions\/2086"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/aetsoft.net\/blog\/wp-json\/wp\/v2\/media\/2060"}],"wp:attachment":[{"href":"https:\/\/aetsoft.net\/blog\/wp-json\/wp\/v2\/media?parent=2054"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/aetsoft.net\/blog\/wp-json\/wp\/v2\/categories?post=2054"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/aetsoft.net\/blog\/wp-json\/wp\/v2\/tags?post=2054"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}