How Aetsoft built
a securities tokenization platform
around a German tied-agent model
A German fintech needed to turn its digital-securities model into a production platform for mid-sized issuers and institutional investors.
Between late 2019 and mid-2021, Aetsoft designed and built it: a permissioned Graphene chain carrying instrument-specific logic, the issuance platform with its web and mobile applications, an isolated identity and verification domain, the infrastructure beneath secondary transfers, and post-issuance administration including holder voting. Aetsoft ran the full cycle from business analysis and product management through to delivery. The platform reached production and is still running.
001
ClientA German fintech operating a digital securities platform
002
SectorRegulated digital assets, primary capital markets
003
EngagementQ4 2019 to Q2 2021, business analysis through to delivery
004
DeliveredDigital asset infrastructure. Permissioned chain, issuance platform, web and mobile applications, back office
A fundraising channel, and the operation underneath it
Digital issuance offered mid-sized companies a way to raise capital directly from investors, and gave institutions a way to place instruments with selected investors. Certain smaller or exempt offerings could already follow a lighter disclosure route than a full prospectus, and private placements had their own exemptions, so the legal room existed.
What had to be built was the operation underneath. Someone had to verify every investor, take orders, match incoming bank transfers, allocate the instrument, maintain a holder record, handle interest, and run a holder vote three years later. Each of those is manageable once. Repeated across a portfolio of issuers it becomes a system, and every step has to leave evidence somebody can check afterwards.
The platform also needed a separate institutional route, with repeatable business verification, supervised approvals and a complete audit trail.
Three structures were compared. The platform operator could seek its own investment brokerage and custody permissions. It could hold a brokerage permission and work with a separate custodian. Or it could act as a tied agent under a licensed investment institution, again alongside a custodian. All three assigned custody to a defined custodian role
The client took the third, and that decision shaped everything after it. For the specified investment services performed inside the arrangement, the platform operator acted under the licensed institution's responsibility rather than holding its own investment-firm authorisation. It could promote an offering and transmit instructions. Approval and acceptance of an order sat with the licensed institution, which carried the liability and supervised the tied agent, and the tied agent had to disclose the capacity in which it was acting.
The arrangement is narrower than the shorthand suggests. The licence stayed with the institution, and it was not transferred. It covered defined investment services rather than the technology business or the securities themselves, and the issuer remained responsible for its own instrument and offering documents.
The model drew on the MiFID II framework and was designed to support expansion across the European Economic Area, subject to the licensed institution's permissions and the cross-border notifications that go with them. A passport lets a firm provide its service. It does not by itself permit an instrument to be offered or resold into every country, a distinction we have written about at length in our work on cross-border tokenization in Europe. Germany's implementing statute changed during the engagement, so the design had to hold the principle rather than a section number.
That left a division of responsibility running through the middle of one product, and the software had to make it operational and observable.
Solution
What the model required from the platform
A responsibility split that lives only
in a contract is difficult to supervise
Eligibility had to be settled before a subscription rather than after, drawing on investor type, jurisdiction and verification status together. Certain approvals had to route to a person instead of completing automatically. Offering documents had to be versioned, so an acknowledgement pointed at the version actually shown. Subscription, payment, allocation and the transfer of a holding had to be separate states, because they happen at different moments and can fail independently.
Material approvals needed a named owner, and records had to show who acted, when, and on what evidence.
Not every control described below was a legal obligation. Some came from the regulatory arrangement, some from the licensed partner, some from the client's security policy, and some from the engineering needed to run the system reliably.
What Aetsoft built
The plan had three layers. A chain, an issuance platform, and a venue for secondary trading. The first two shipped, and the chain support and backend beneath the third were built.
The chain and its nodes
Node roles were separated by function in the design. Nodes verifying token transactions were distinct from read-only nodes serving the applications, with payment settlement on its own set, which kept application queries away from validating nodes.
Each instrument type carried its own logic on the chain rather than sharing one generic token. A bond behaves differently from a profit-participation right, which behaves differently again from a convertible. Interest intervals, maturity, voting rights and transfer windows are properties of the instrument, so we encoded them where they could not drift out of step with the offering documents. Tradeability was designed as a chain state, switched by a separate authorised transaction.
Keeping two clocks in agreement
An offering ran on two state machines at once. The platform tracked the project, the chain tracked the offering, and holding those two in agreement through payments that arrived late and soft caps that landed either side of the line was a complex part of the product.
The system read the soft cap outcome from the chain. If the cap was missed, investors were refunded and the tokens burned, because leaving them in place would corrupt the holder record. If the cap was met, the offering either completed or waited for the issuer's approval, and only after that approval did the system complete the allocation and update the platform and ledger records.
That approval gate was not a technical necessity. It is there because the moment a holding is allocated is a moment somebody should be accountable for.
Where identity evidence lived
Identity documents and verification evidence were isolated from the issuance application by design.
They sat in a segmented domain with its own database, encrypted storage, key management and monitoring. The issuance platform asked that domain who a user was and what they were permitted to do, and got back a verified answer rather than the underlying documents.
Verification results and the files behind them were also copied automatically into storage the client controlled directly. That was an operating requirement of this engagement. The separation narrows the blast radius of a compromise.
Two routes in
Retail and institutional investors do not belong in the same funnel.
A retail investor registered at level one, which allowed browsing and little else. Level two followed identity verification through an integrated provider, and the result was reviewed rather than accepted automatically. Several verification providers and payment methods were integrated over the engagement, reducing dependence on any one provider.
Institutional investors took a different route: business verification with beneficial owners disclosed, a contact person verified in their own right, and access ahead of public launch. Each offering carried one date for a whitelisted institutional window and another for general availability.
After the money lands
Post-issuance administration was in scope from the start.
Aetsoft built the holder register and cap table, interest and dividend handling, issuer reporting, and holder governance. Voting weight was calculated from the same on-chain holder record used to administer the instrument, taken as a snapshot when a vote opened. Investors could delegate to a trustee. Each vote was confirmed by SMS TAN before it counted, and the design gave holders a record of what they had submitted.
Delivery
Scope moved once, for regulatory rather than technical reasons. A system that allows multiple third-party buying and selling interests in financial instruments to interact may qualify as a multilateral system and require trading-venue authorisation. The revised design limited the proposed board to displaying indications of interest, with matching, negotiation and execution remaining outside it in a licensed workflow. Aetsoft delivered the chain support and part of the backend, and the user-facing board was not built. We have since set out the approach in full in our guide to compliant bulletin boards for tokenized securities.
Scope moved once, for regulatory rather than technical reasons. A system that allows multiple third-party buying and selling interests in financial instruments to interact may qualify as a multilateral system and require trading-venue authorisation. The revised design limited the proposed board to displaying indications of interest, with matching, negotiation and execution remaining outside it in a licensed workflow. Aetsoft delivered the chain support and part of the backend, and the user-facing board was not built. We have since set out the approach in full in our guide to compliant bulletin boards for tokenized securities.
A client-side CTO owned the product and handled alignment with German legal and technical requirements. Having that knowledge one conversation away kept regulatory and architectural decisions moving together rather than in sequence.
The technology available to tokenization platforms has moved on since 2021. The operating questions have not
A platform still has to control who may invest, decide who approves each material action, hold identity evidence somewhere defensible, reconcile payments against subscriptions, establish the moment a holding is allocated, and administer the instrument for years afterwards. Those questions come from the operating model, and token standards answer only part of it.
They remain among the first questions we work through on an asset tokenization project.
Results
“The platform reached production and has stayed there, still operating years after Aetsoft's original delivery ended. Retail and institutional onboarding, verification and allocation ran inside one platform, with the records the licensed institution needed for oversight held in it.”
Issuers moved from an administrative project to a configured product: a review loop, a signed agreement, a parameter document and a launch date, with the legal work and the licensed institution still in place around it.
Holder governance was built on the same infrastructure that issued the instrument, so voting weight came from the holder record the platform already maintained rather than from a separate list.
Frequently asked questions about securities tokenization platform
-
What is a securities tokenization platform?
A securities tokenization platform is software for issuing and administering securities whose ownership records are held on a distributed ledger.
-
How does a tied-agent arrangement work?
A firm may act on behalf of a licensed investment institution for specified investment services. The licence stays with the institution, which remains responsible for those activities and supervises the tied agent. The tied agent can promote an offering and transmit instructions, and it must disclose the capacity in which it acts. Approval of an order sits with the institution.
-
Why choose a permissioned chain for a securities platform?
It lets the operator control validator admission, retain control over the instruments being issued and how they move, and change the system on its own schedule. Node operation can be extended to other participating institutions. The trade is limited access to external liquidity, and for this primary-issuance model operational control mattered more.
-
Why does secondary trading raise a different licensing question?
A system that allows multiple third-party buying and selling interests in financial instruments to interact may qualify as a multilateral system and require trading-venue authorisation. Displaying an indication of interest sits on one side of that line. Matching, negotiation, an accept button or in-system execution move towards the other. Routing an instruction to a licensed firm does not settle the question on its own, because the test is whether interests are brought together at all.
-
What should be settled before the technology is chosen?
Who may invest, who approves each material action, where identity evidence is held, how payments are reconciled, and when a holding is allocated. Answer those first and the token and custody choices become straightforward.
Define who acts, who approves and what must be recorded before designing the architecture.
Explore our approach to STO development.
This page describes an engagement delivered between 2019 and Q2 2021. It is general information about how the system was built and is not legal, regulatory or investment advice.
