Launching an investment product inside a neobank is one of the more technically complex things a fintech can attempt. The neobank's core infrastructure — payments, accounts, card processing, KYC — was built for money transmission, not securities trading. Adding a brokerage product means grafting an entirely different regulatory regime (MiFID II or FCA investment firm authorisation, in addition to the existing payment institution or e-money licence) onto a codebase and organisational structure that was not designed with securities in mind.
This piece is for engineering and product teams at neobanks planning to launch a brokerage or investment product. It covers the infrastructure components that most commonly cause launch delays or post-launch incidents, and the sequencing decisions that tend to matter most.
Investment Licence and Regulatory Architecture
Before any technical integration begins, the regulatory path must be determined. Operating a brokerage product in Europe requires either an MiFID II investment firm licence (passportable across the EEA) or operating under an appointed representative arrangement with an existing authorised firm. The UK requires FCA authorisation under FSMA 2000, which is separate from EEA passporting post-Brexit.
The regulatory architecture decision affects the technical architecture: if the neobank is the authorised firm, it owns the MiFID II obligations end-to-end — suitability assessments, best execution, trade reporting (EMIR and MiFID II transaction reporting), and order record retention. If the neobank uses a white-label brokerage provider as the underlying authorised firm, responsibility for some obligations transfers, but the neobank retains responsibility for the customer-facing relationship and product suitability. The split must be documented in an outsourcing agreement that meets the MiFID II requirements for critical function outsourcing under Article 16.
Custody and Settlement Infrastructure
Retail investment products require custody of securities — the legal holding of assets on behalf of investors. This is distinct from the neobank's existing payment infrastructure, where the bank holds cash. Securities custody requires a relationship with a custodian that holds client assets in segregated accounts per FCA CASS 6 (UK) or MiFID II Article 16(9) (EEA) requirements.
Custodian selection early in the process is critical because: the custodian's connectivity model (which exchanges it connects to, which settlement chains it supports) determines which markets the investment product can offer at launch; the custodian's API and reporting formats shape the platform's technical architecture for position tracking and reconciliation; and the custodian's onboarding timeline — typically 3–6 months — is often the rate-limiting factor in the overall launch timeline.
For neobanks planning multi-exchange products (beyond a single market), the custodian's multi-market coverage must be verified against the intended product scope before signing. Custodians with strong UK equities capability may have limited continental European coverage, and vice versa. Some neobanks have launched with two custodians (one for UK, one for EU markets) — which solves the coverage problem but adds reconciliation complexity.
KYC/AML Integration for Investment Products
The neobank almost certainly has an existing KYC/AML process for its payment product. Investment products require additional due diligence layers: MiFID II suitability assessment (investor experience and risk tolerance), appropriateness assessment for complex instruments, and in some jurisdictions, enhanced AML checks for investment accounts (particularly for products allowing large single transfers into investment accounts).
The existing KYC data — identity verification, address, date of birth — is reusable. The suitability questionnaire, risk profiling, and investment experience assessment are new flows that must be integrated into the onboarding journey. These must not be designed as one-time gates; MiFID II requires periodic suitability review for ongoing advisory and discretionary relationships. The technical design must support suitability record retention and periodic reassessment triggers.
Real-Time Price Feeds and Market Data
Displaying investment products to retail investors requires real-time or near-real-time price data. Exchange market data licences are expensive and often structured around peak concurrent user counts — a growing neobank with rapidly increasing investment product users can face significant market data cost increases as user counts grow. Understanding the market data fee structure for each exchange at the planning stage avoids surprises at scale.
The neobank's existing infrastructure likely does not include a market data normalisation layer. Building or licensing one before launch is essential: different exchanges produce prices in different formats (FIX market data, exchange-proprietary feeds, delayed consolidated feed services), and retail investor-facing displays require consistent price quality, currency handling, and stale price indicators across all securities in the product catalogue.
Order Management System Integration
The OMS (order management system) is the core of the brokerage product. It receives order instructions from the frontend, manages order state through its lifecycle (pending, submitted, partially filled, filled, cancelled, rejected), and produces the execution records required for MiFID II reporting. Neobanks typically use one of three approaches: build an OMS in-house, use the custodian's bundled OMS, or use a specialist brokerage API that includes order management as a service.
Each approach has real trade-offs. In-house OMS gives the most control over order behaviour and optimisation, but requires the neobank to build and maintain FIX connectivity to each exchange, handle partial fills, manage cancel-replace semantics, and process execution reports — the full set of exchange connectivity complexity described in our exchange fragmentation article. The custodian's bundled OMS avoids exchange connectivity work but may have less flexibility for custom order types and may impose order routing choices the neobank cannot override. A specialist brokerage API is the fastest path to market but introduces a critical infrastructure dependency on a third party.
Transaction Reporting: EMIR and MiFID II
MiFID II Article 26 requires investment firms to report transactions to their national competent authority (NCA) by end of the trading day. For a UK FCA-authorised firm, reports go to the FCA's Market Data Processor. For EEA firms, reports go to the relevant NCA via an Approved Reporting Mechanism (ARM). These are mandatory reports for every executed trade, containing specific fields: LEI (Legal Entity Identifier) of the investment firm, client ID, instrument details (ISIN, trading venue MIC code), price, quantity, trade date, and time of transaction.
EMIR trade reporting (for derivative transactions) is a separate regime with different fields and reporting infrastructure. If the investment product includes any derivative instruments (options, CFDs), EMIR reporting must be set up before trading commences. Operating without required transaction reporting is an immediate regulatory breach.
Building transaction reporting infrastructure is non-trivial: the firm needs a Legal Entity Identifier (LEI) from the Global LEI Foundation, an ARM relationship, a system that generates compliant XML or CSV reports in the required format (ISO 20022 for MiFID II transaction reports), and a reconciliation process to ensure every executed trade generates a corresponding report. This infrastructure requires testing against the ARM's conformance testing environment before going live.
Cost Basis Tracking and Tax Reporting Infrastructure
As detailed in our cost basis tracking article, accurate lot-level tracking is required from the first transaction. The neobank's existing accounting infrastructure does not typically handle lot-level securities cost basis. Building this from scratch alongside the rest of the brokerage infrastructure competes for engineering resources at exactly the point when they are most constrained.
For launch, the minimum viable implementation is: lot ledger recording every acquisition with price, date, and quantity; national tax method configuration per investor (FIFO for German investors, s.104 pooling for UK investors); and end-of-year tax reporting capability (Jahressteuerbescheinigung for German investors, consolidated tax certificate for UK investors). The reporting requirement often sets the hard deadline for implementation — failing to produce annual tax certificates is a severe investor experience failure that generates significant support burden.
Customer Communication and Corporate Action Processing
Investment products require corporate action communication to investors — dividend notifications, rights issue decisions, merger elections. These are distinct from the neobank's existing notification infrastructure (payment alerts, fraud notifications) and require content that is accurate, timely, and in some cases requires investor response. Corporate action processing workflows — from receiving the corporate action announcement from the custodian through to updating investor records and sending notifications — must be designed before launch, not retrofitted after an investor misses a rights issue election because the platform did not inform them.
We are not saying that every neobank launching an investment product will hit all of these failure modes — the specific risks depend on the regulatory structure, the custodian, and the scope of the initial product. The pattern that produces the most post-launch incidents is treating the brokerage product as an extension of the payments infrastructure and discovering late that it requires an entirely separate operational track: different compliance obligations, different settlement processes, different tax reporting requirements, and different customer communication standards. Early-stage platforms that treat the investment product as a distinct operating entity within the neobank, with its own infrastructure decisions made explicitly rather than inherited, consistently have smoother launches.