Crypto broker infrastructure
for a Swiss financial intermediary
A Swiss crypto broker needed crypto broker platform development. The platform had to hold client-attributable balances, verify its clients, screen incoming funds and connect execution across several venues, with every movement recorded in one internal ledger.
Aetsoft built it for Grinteq between October 2025 and January 2026, and the broker's own team has run it in production since.
- Why the operating record had to be connected
- No provider holds the record the broker is accountable for
- The internal ledger became the system of record
- The architecture decision: what the platform had to build around Fireblocks
- Screening and identity govern what the platform allowss
- Trading across three venues that resolve in one ledger
- Two fiat routes, reconciled the same way
- Delivery and handover
- What the client says
- Frequently asked questions
001
End clientA Swiss crypto broker operating as a financial intermediary and affiliated with a self-regulatory organisation (SRO) recognised by FINMA. Its clients are high-net-worth individuals whose assets the brokerage trades on their behalf
002
ClientGrinteq, a software development and consulting company
003
ChallengeA financial intermediary carries due-diligence and record-keeping duties under the Swiss anti-money-laundering framework. Custody, screening, identity, trading and banking each arrive as a separate provider with its own idea of a transaction. Stack those integrations on top of each other and the operating record scatters across systems that cannot see each other
004
SolutionA digital-asset brokerage platform built around an internal double-entry ledger. Custody, screening, identity, trading and fiat are integrated into it as connected flows
005
Aetsoft's roleBusiness analysis and solution architecture, back office and client application, custody and provider integrations, controls and reporting, QA and DevOps
Engagement lead
Artem Kirylin
Commercial Director, Aetsoft Inc
Led the commercial relationship, product consulting and provider strategy
Why the operating record had to be connected
The end client is a Swiss financial intermediary. It is affiliated with a self-regulatory organisation, or SRO, recognised by FINMA.
Under the Swiss anti-money-laundering framework, the SRO defines the applicable due-diligence requirements and monitors its affiliated members' compliance. FINMA's role here is to recognise and supervise the SRO, which in turn supervises the broker.
The client's legal counsel was responsible for the legal and compliance interpretation, while Aetsoft worked with counsel to translate the resulting requirements into product rules. Such requirements and flows covered:
- verification status,
- transaction screening,
- held and released transactions,
- named approvals,
- ledger records,
- internal reporting.
Requirements of that kind are answered from records, and no single system holds them all. A broker needs to see a client's balances, where the funds came in, what screening returned and who approved the move. Each fact starts life inside a different provider.
Aetsoft builds this class of system for regulated clients across Switzerland and the EU. Its cross-border tokenization work covers the wider regulatory picture across both jurisdictions.
A similar split appeared in a securities tokenization platform Aetsoft built around a German tied-agent model. The platform operator acted on behalf of a licensed institution, which approved the orders.
A separate custodian held the assets, while each issuer remained responsible for its instrument. The software sent each action to the right party and recorded who approved it.
The client's legal counsel was responsible for the legal and compliance interpretation, while Aetsoft worked with counsel to translate the resulting requirements into product rules. Such requirements and flows covered:
- verification status,
- transaction screening,
- held and released transactions,
- named approvals,
- ledger records,
- internal reporting.
Requirements of that kind are answered from records, and no single system holds them all. A broker needs to see a client's balances, where the funds came in, what screening returned and who approved the move. Each fact starts life inside a different provider.
Aetsoft builds this class of system for regulated clients across Switzerland and the EU. Its cross-border tokenization work covers the wider regulatory picture across both jurisdictions.
A similar split appeared in a securities tokenization platform Aetsoft built around a German tied-agent model. The platform operator acted on behalf of a licensed institution, which approved the orders.
A separate custodian held the assets, while each issuer remained responsible for its instrument. The software sent each action to the right party and recorded who approved it.
Aetsoft built the ledger on double-entry accounting and made it the platform's system of record. Customer management, trading, fiat and banking, custody and reporting all write to it, and every write goes through the platform's own posting rules.
of record
Outside providers reach the ledger only as checked events. Provider webhooks are signature-checked and deduplicated before anything is written, because a repeated event in an asset platform means a repeated balance.
Balances are held per currency, and the ledger reserves funds while a movement is in flight. Provider transactions settle asynchronously, so money already committed to a withdrawal or a trade has to show as unavailable while it is still in transit.
Reconciliation runs as a service inside the platform, comparing ledger state against provider state. Where the two differ, the gap is raised as a dated exception with a client and a transaction attached. A compliance officer gets a named client and a named transaction to resolve.
Service fees work the same way. They are set centrally, applied at balance level and kept with their history, so a charge made in March still makes sense in November.
Each system under a brokerage is the authority on its own fragment of the picture.
Fireblocks holds wallet balances and the policy governing them, Chainalysis returns address-risk scores, and Sumsub records verification outcomes.
Line those pieces up and the link between them is still missing. No single provider holds the whole operating record. The broker recognised this early and made it a requirement. The platform would keep its own ledger, and that ledger would be the internal record of balances and movements.
Solution
From a confirmed requirement to system behaviour
The architecture decision: what the platform had to build around Fireblocks
Aetsoft integrated Fireblocks as the platform's custody-infrastructure and transaction-policy layer. Around it, the team built what the broker's operating model required: the wallet lifecycle, the screening flow, ledger posting, reconciliation and exception handling.
Custody and key management had to come from a specialist provider, for cryptographic reasons before commercial ones. MPC signing is a security product on its own, and a brokerage needs a provider whose implementation has been through independent scrutiny.
Through its blockchain consulting work, Aetsoft compared custody providers against the broker’s business requirements and narrowed the field to two credible options. DFNS shaped the early architecture and remains a strong wallet-as-a-service platform, especially where programmable policy and embedded wallets matter.
The delivered platform runs on Fireblocks. Either would have carried the operating model, and the brokerage logic around the custody layer was largely provider-independent by design.
The provider supplies MPC key security, wallet infrastructure and a transaction policy engine, and the Fireblocks custody integration case covers that layer in more depth. The brokerage behaviour around it was Aetsoft's work:
Wallet structure
The platform created segregated custodial wallets for each client account. Each structure included a deposit wallet, a main wallet and network-specific wallets. The wallets were mirrored in the platform database and linked to the same account, so wallet activity and ledger entries could be traced to the relevant client.
Deposit addresses ahead of segregated wallets
Incoming funds land on a deposit wallet the platform controls, and screening runs there before anything is swept into the main wallet. Screen a deposit after it has pooled with other clients' assets and a routine hold becomes an investigation.
Sweeps
Cleared deposits move from the deposit wallet into the main segregated wallet, and the move posts to the ledger as it happens.
Fee estimation
Separate engines cover EVM networks and Bitcoin, so a client sees the cost of a deposit or withdrawal before confirming it.
Gas sponsorship
System wallets are topped up with native crypto, so clients can move assets without holding network tokens. Bitcoin has no sponsorship, so its fees come out of the deposit and settle in the ledger.
The back office grew with the operating model
The back office is the working surface for the broker's staff, and its shape follows who is permitted to change what. Scoped initially as a core set-up, it grew through the engagement as the operating model settled.
For the broker's own clients, the client application covers onboarding and verification, deposits with fee breakdowns and QR codes, withdrawals, balances and statements. The exchange screen described above sits inside it.
Network and token selection sit inside the deposit and withdrawal flows. Onboarding collects company and officer details against country and nationality reference data. Email alerts cover what a client needs to see, such as a deposit arriving.
Delivery
and handover
The engagement ran from October 2025 to January 2026 with a team of six to ten, covering architecture and analysis, backend and frontend, QA and test automation, design, DevOps and delivery. An Aetsoft blockchain development team takes that shape when a platform has a fixed launch date.
Development ran inside the client's own environment from the first sprint. Nothing had to be moved at the end, because the platform was already running where it would live.
The client's team received the code, the system architecture and the specifications, and was already running the infrastructure underneath them. Aetsoft continues to support that team on infrastructure and DevOps when asked.
Results
Two-week sprints, a demo at the end of each, written updates in between. We manage the code, the backlog and the releases inside StreamWolf's own delivery environment, so the team there sees each one firsthand.
“They're a very technical and straightforward team. We had full transparency about when and what was done. We didn't expect that much detail in the documentation, which we liked a lot.”
Sergei Lakishik 
CEO of Grinteq. Verified Clutch review.
The platform has run the brokerage's operations since January 2026 under the broker's own team.
- An internal double-entry ledger as the system of record. It reconciles against the provider state, reserves funds in transit, and keeps service fees with their history.
- A Fireblocks integration for custody. Segregated wallets, deposit addresses, sweeps, fee estimates, gas sponsorship and policy-driven controls.
- A Chainalysis KYT integration through Fireblocks. It scores deposits on arrival, freezes those above the broker's limit, and holds them for a recorded human release.
- A Sumsub integration for KYC and AML, with verification status enforced at the point of action.
- Execution connectivity to Binance, KuCoin and Uniswap, each on its own flow. A client exchange screen runs quote-and-swap pricing with live rates and a price chart.
- Fiat through Paybis and Banxa with rate selection. Virtual IBANs through a banking-as-a-service provider.
- A back office for user and company management, the ledger, reporting and access control.
- A client application covering onboarding and identity checks, deposits, withdrawals, exchange, balances and statements.
Frequently asked questions about crypto broker infrastructure
-
What does crypto broker platform development involve beyond the custody provider?
A custody provider covers key security, wallet infrastructure and transaction policy. A broker still needs the wallet structure its operating model requires. It needs the deposit and sweep logic that lets screening run before funds are pooled. It needs a ledger of client-attributable balances, reconciliation against provider state, exception handling for frozen or failed movements, and the reporting its compliance function depends on. That surrounding platform is the larger part of the work.
-
What is a double-entry ledger in a crypto broker platform?
A double-entry ledger records every movement with matching debit and credit entries. In a crypto broker platform, it links custody, trading and fiat activity to the relevant client account, reserves funds while transactions are in progress and helps identify differences between the platform’s records and provider data.
-
Does human review of every flagged transaction slow the business down?
It slows the flagged ones by design. How much depends on where the freeze happens. Funds already swept into a pooled wallet turn a review into an investigation. Funds held on a deposit address make it a decision with two outcomes and a short record behind it.
-
Where does Aetsoft's responsibility end?
Aetsoft builds the controls, records and workflows from requirements the client’s compliance function has settled. It also integrates the providers of custody, banking, screening and identity services. Regulatory interpretation and the SRO relationship stay with the client and its counsel.
-
How long does a build like this take?
This one ran from October 2025 to January 2026 with a team of six to ten. The client had already settled its operating model. Timelines move most when custody, banking and screening providers are still being chosen. Those choices reshape the architecture around them.
The hardest records to produce are the ones that span providers, and process alone will not close a gap in the architecture. We help digital-asset firms in Switzerland and the EU work out what to buy, what to build, and which system holds the record everything else answers to.
It is general information about how the system was built and is not legal, regulatory or investment advice.
