Securities Platform Development UAE: CMA, DFSA, and ADGM Compliance

Building an investment or securities platform in the UAE means building for one of four regulatory regimes: the Capital Markets Authority (CMA) for mainland UAE, the Dubai Financial Services Authority (DFSA) for the DIFC, the Financial Services Regulatory Authority (FSRA) for the ADGM, and the Virtual Assets Regulatory Authority (VARA) for Dubai virtual asset businesses. Each regime defines a different software architecture, covering AML and KYC workflows, order management, audit trails, sanctions screening, Travel Rule compliance, and regulatory reporting. Choosing the jurisdiction determines the compliance software stack—not just the licence application.

Every legal adviser explains how to obtain a licence. Far fewer explain what your software must actually do once the licence is approved. This guide translates each regulator's requirements into technical architecture decisions, helping CTOs and founders understand the modules required before development begins. Whether you're working with Pixbit Solutions or evaluating another technical partner for fintech software development UAE, understanding the compliance architecture early prevents expensive redesigns later.

---

The Four Regulatory Regimes — Choosing One Is an Architecture Decision

Many founders treat regulator selection as a legal decision. From a software engineering perspective, it is an architectural decision that influences almost every layer of the platform.

A brokerage licensed under the CMA has different reporting obligations from one regulated by the DFSA. A tokenised investment platform operating inside ADGM follows a different compliance model from a VARA-regulated exchange. These differences extend into permission models, investor onboarding workflows, database structures, API integrations, audit retention policies, and transaction processing.

Selecting the wrong architecture at the beginning often means rebuilding major components after licensing advice changes. The regulator effectively dictates how the platform handles identity verification, investor suitability, suspicious transaction reporting, governance workflows, and even data residency.

CMA — Federal Mainland and the Three-Module Framework

The Capital Markets Authority (CMA) became the UAE's federal securities regulator under Federal Decree-Law No. 32 of 2025, replacing the former Securities and Commodities Authority from 1 January 2026. It governs securities markets, brokers, investment firms, fund managers, commodities trading, and virtual asset service providers operating across mainland UAE and most free zones outside DIFC and ADGM.

For developers, the most important regulatory document is CMA Decision No. 4/R.M/2026, issued on 13 February 2026. Rather than treating virtual asset regulation as a single rulebook, the CMA divides operational compliance into three distinct modules that map directly to software architecture.

The General Framework Module establishes governance obligations, capital adequacy rules, local presence requirements, and ownership controls. One particularly important software implication involves controller approval thresholds. Whenever ownership crosses 10%, 30%, or 50%, prior CMA approval becomes mandatory.

A compliant investment platform therefore needs more than a shareholder register. It requires a live cap table capable of monitoring ownership percentages continuously, generating approval workflows automatically, and preventing transfers until regulator approval has been recorded. These controls belong inside the platform rather than relying on manual legal processes.

The Business Regulation Module governs day-to-day operations. This is where most platform functionality originates. Client onboarding, customer due diligence, Know Your Customer (KYC) verification, investor suitability assessments, transaction monitoring, suspicious activity reporting, portfolio permissions, and operational record keeping all stem from this module.

Instead of viewing AML as an isolated feature, developers should think of it as an orchestration layer that interacts with onboarding, payments, trading, reporting, and customer management simultaneously. Every transaction should produce an auditable chain that can later support regulatory inspection or suspicious activity investigations.

The Alternative Trading System (ATS) Module applies to operators providing multi-party trading infrastructure. Unlike discretionary marketplaces, the CMA requires a non-discretionary, rules-based matching engine where execution follows predefined matching logic rather than human judgement.

This affects the design of the order management system. Every order placement, modification, cancellation, and execution requires immutable timestamps, participant attribution, sequencing records, and market surveillance logging. A matching engine cannot simply prioritise business preferences; it must execute according to transparent rules that regulators can reconstruct during an investigation.

Another architectural consideration comes from the CMA's licensing structure. The regulator separates activities into eight distinct licensed categories, including custody, arranging custody, brokerage, exchange services, investment advice, portfolio management, arranging transactions, and fund management.

Developers often assume custody and arranging custody belong under the same permission model because they appear operationally similar. Under CMA regulations they are separate licensed activities. A platform that allows users to perform both without enforcing licence-specific permissions risks enabling unlicensed business activity.

The safest approach is a jurisdiction-aware permission engine that maps every software function to the exact licensed activity held by the regulated entity. This prevents feature expansion from unintentionally creating regulatory exposure as the platform evolves.

DFSA — DIFC and the April 2026 Compliance Review Findings

The Dubai Financial Services Authority (DFSA) regulates financial services conducted inside the Dubai International Financial Centre (DIFC). Unlike mainland UAE, the DIFC operates under a common law legal framework with its own courts, legislation, and regulatory environment.

Although licensing categories remain important, one of the most valuable documents for developers is the DFSA's April 2026 compliance review, which identified recurring operational weaknesses among regulated firms. These findings provide practical guidance for software architecture because every weakness corresponds to a missing platform capability.

The first concern involved governance and board oversight. Compliance cannot exist solely within operational teams. Senior management must receive accurate, timely information about regulatory risks.

Software therefore needs governance dashboards with strict role-based permissions separating board members, compliance officers, operational staff, and administrators. Directors require visibility into compliance indicators without exposing operational controls that belong to management teams.

The second finding focused on monitoring. Firms relying heavily on manual transaction reviews struggled to identify suspicious behaviour consistently.

This shifts transaction monitoring from an administrative activity into an automated system component. Platforms should evaluate transactions continuously against configurable thresholds, behavioural anomalies, geographic risk indicators, sanctions data, and customer profiles before escalating alerts to compliance teams.

The third finding addressed compliance resourcing and accountability. The DFSA emphasised that outsourced compliance functions cannot replace identifiable responsibility within the regulated UAE entity.

Software architecture should therefore support local accountability through detailed attribution. Every compliance action, approval, override, investigation, and reporting decision should identify the responsible UAE-based user rather than simply recording that "compliance approved" the action.

Another significant architectural difference concerns data protection. DIFC entities operate under data protection legislation closely aligned with GDPR principles.

This requires consent management, lawful processing records, data subject access workflows, deletion request handling where legally permissible, and controlled cross-border data transfers. These capabilities should be embedded throughout the platform rather than added as isolated privacy features after deployment.

The DFSA licensing categories also influence software complexity. Category 3A firms managing discretionary investments generally require deeper suitability assessments, portfolio controls, investment approval workflows, and governance reporting than Category 4 advisory businesses.

Instead of maintaining separate products for different licence categories, developers should build configurable permission layers that enable or disable regulated functionality according to the firm's authorised activities. This allows regulated businesses to expand their permissions without rebuilding the underlying application.

FSRA — ADGM and the Digital Securities Distinction

The Financial Services Regulatory Authority (FSRA) regulates financial services conducted within the Abu Dhabi Global Market (ADGM). ADGM has established itself as the UAE's preferred jurisdiction for institutional fund managers, venture capital firms, private equity structures, family offices, and tokenised investment products operating under a common-law legal framework.

The most significant architectural distinction for developers is ADGM's treatment of Digital Securities. Unlike many jurisdictions that classify every blockchain-based asset as a virtual asset, ADGM distinguishes between Digital Securities and Virtual Assets, and that distinction fundamentally changes the compliance software stack.

Tokenised fund interests issued by an investment fund are classified as Digital Securities, not Virtual Assets. The software therefore follows securities regulation rather than virtual asset exchange regulation, resulting in different licensing requirements, reporting obligations, investor protections, and governance controls.

This distinction also affects exchange licensing. A fund manager issuing blockchain tokens representing ownership in a regulated investment vehicle does not automatically require exchange licensing. Exchange permissions become necessary only when the platform operates a secondary trading venue where multiple participants trade those Digital Securities.

From a software architecture perspective, the platform must model at least two regulated entities. The Special Purpose Vehicle (SPV) issues the blockchain-based Digital Securities, while the regulated fund manager oversees investor onboarding, compliance, portfolio administration, and regulatory reporting.

These entities require separate permission structures, audit trails, reporting chains, and operational workflows even though users experience them through a single application. Combining both entities into one permission model creates governance ambiguity that conflicts with ADGM's regulatory expectations.

A well-designed platform therefore separates legal entities at the database level while allowing controlled operational interaction between them. Every approval, token issuance, subscription, redemption, and ownership change should remain attributable to the correct regulated entity.

The FSRA has also proposed a lighter supervisory framework through Consultation Paper No. 12 of 2025 for smaller fund managers controlling less than USD 200 million in committed capital.

Rather than maintaining separate software editions for different licence tiers, developers should build configurable compliance modules. This allows a regulated firm to migrate between supervisory categories by updating permissions and reporting rules instead of rebuilding the application.

Investor onboarding follows the same principle. Different licence tiers require different regulatory obligations, but the onboarding engine should activate or disable compliance steps based on jurisdiction and licence category rather than hardcoding a single workflow.

The result is a platform capable of supporting institutional fund managers as they expand without requiring fundamental architectural changes.

---

VARA — Build Before Licence

The Virtual Assets Regulatory Authority (VARA) regulates virtual asset activities throughout Dubai outside the DIFC. Since introducing its Rulebook Version 2.0, VARA has become one of the world's most detailed regulatory frameworks for virtual asset businesses.

Its Exchange Services Rulebook Version 2.1, effective from 31 March 2026, extends those requirements further by establishing dedicated controls for exchange-traded derivatives, including perpetual contracts, futures, options, and contracts for difference involving virtual assets.

Most software implications mirror traditional regulated exchanges, including enhanced order management, surveillance, market integrity monitoring, and investor protection controls.

The major architectural difference lies in VARA's licensing sequence.

Unlike many financial regulators, VARA expects applicants to demonstrate a functioning platform before granting a full operational licence. The regulator requires a documented Minimum Viable Product (MVP) supported by technology security assessments, operational testing, and sandbox validation rather than relying solely on architectural documentation.

This creates an unusual sequencing challenge for founders.

Under many licensing frameworks, companies obtain regulatory approval before committing significant development budgets. Under VARA, the software itself becomes part of the licensing evidence.

Developers therefore need to build production-quality compliance modules earlier than expected. Identity verification, permission controls, transaction monitoring, wallet infrastructure, audit logging, cybersecurity controls, and reporting functionality must already exist before the regulator evaluates operational readiness.

The technology architecture also needs to demonstrate resilience. Regulators assess authentication controls, operational continuity, infrastructure security, privileged access management, and transaction integrity alongside functional requirements.

Waiting until licence approval before beginning software development delays both licensing and market entry because the regulator cannot evaluate software that has not yet been built.

For project planning, this changes budgeting as well. Development expenditure becomes part of the licensing process rather than an activity that follows approval, making regulatory planning and software architecture inseparable from the first discovery session.

---

Travel Rule — The Cross-Jurisdictional Software Requirement

While the CMA, DFSA, FSRA, and VARA operate different regulatory frameworks, one technical obligation appears across all four: compliance with FATF Recommendation 16, commonly known as the Travel Rule.

The Travel Rule requires virtual asset service providers to exchange originator and beneficiary information whenever qualifying crypto-asset transactions occur. In practice, this makes blockchain transfers resemble traditional SWIFT wire transfers by attaching verified identity information to every regulated transaction.

Many founders assume Travel Rule compliance belongs inside the KYC module because it uses customer identity information. In reality, it operates as an independent compliance infrastructure layer positioned between transaction processing and external settlement.

The Travel Rule engine begins working at transaction initiation. Before assets leave the platform, it captures verified originator information, validates beneficiary details, determines whether the transaction exceeds the applicable reporting threshold, and prepares the required compliance payload.

That payload must then be transmitted securely to the receiving Virtual Asset Service Provider using recognised interoperability protocols such as TRISA, OpenVASP, or another licensed Travel Rule compliance provider.

Only after successful information exchange should the regulated transaction proceed to settlement.

The platform must also retain a complete audit history of every Travel Rule communication. Regulators may request evidence showing exactly what information was transmitted, when it was exchanged, which institution received it, and whether transmission completed successfully.

Because implementation varies slightly across the CMA, DFSA, FSRA, and VARA, the Travel Rule engine should remain jurisdiction-aware rather than relying on one universal configuration.

This architecture allows the same transaction processing engine to satisfy multiple regulatory frameworks while applying the correct reporting logic according to the regulated entity executing the transaction.

AML and Sanctions Screening Across Four Simultaneous Perimeters

Every regulated investment platform operating in the UAE must implement Anti-Money Laundering (AML) controls. The challenge for developers is that AML architecture is not identical across the CMA, DFSA, FSRA, and VARA. A platform serving multiple jurisdictions cannot rely on one global compliance workflow.

The first universal control is asset eligibility. Privacy-focused cryptocurrencies such as Monero (XMR), Zcash (ZEC), and Dash (DASH) are prohibited across all four regulatory frameworks because they prevent effective transaction tracing.

This means the platform should reject unsupported assets before onboarding rather than relying on manual compliance reviews after trading begins. Asset classification belongs within the onboarding layer, where unsupported token types are blocked automatically before wallets, trading pairs, or custody records are created.

Customer screening should occur continuously rather than only during account creation.

Every onboarding workflow should connect to a licensed sanctions intelligence provider such as Refinitiv World-Check, Dow Jones Risk & Compliance, or another recognised screening service capable of monitoring sanctions, Politically Exposed Persons (PEPs), adverse media, and high-risk jurisdictions.

Initial screening is only the beginning.

Customers can become sanctioned after onboarding, beneficial ownership structures may change, and politically exposed status can evolve over time. Continuous monitoring ensures that existing customer records remain compliant without requiring manual periodic reviews.

Transaction monitoring represents another independent module.

Rather than checking only transaction size, the monitoring engine should evaluate customer behaviour, transaction frequency, geographic exposure, velocity patterns, linked counterparties, unusual asset movement, and historical account activity before assigning risk scores or generating investigation alerts.

Each regulator also expects reporting through different supervisory channels.

Under the CMA, suspicious activity reporting integrates with the UAE Financial Intelligence Unit through the goAML platform. The compliance system should therefore generate Suspicious Transaction Reports (STRs) and Real Estate Activity Reports (REARs), where applicable, in formats compatible with goAML submission workflows.

The DFSA applies its own AML and Counter-Terrorist Financing (CTF) requirements through the DFSA Rulebook. Compliance software should support DIFC-specific customer due diligence, ongoing monitoring, investigation records, and regulator-ready audit documentation.

Within the FSRA, reporting follows the ADGM AML and Sanctions Rules and Guidance framework. While many technical controls resemble other UAE regulators, reporting channels and supervisory expectations remain jurisdiction-specific.

VARA similarly applies its own virtual asset compliance framework, particularly around transaction monitoring, customer verification, wallet controls, and Travel Rule implementation.

Instead of building four independent compliance systems, developers should design a single AML engine capable of routing alerts, investigations, reports, and regulatory submissions according to the regulated entity's jurisdiction.

This architecture allows compliance teams to work from one operational dashboard while ensuring every report reaches the correct supervisory authority without duplication or conflicting workflows.

For organisations expanding across multiple UAE regulatory environments, this jurisdiction-aware compliance layer becomes one of the platform's most valuable architectural investments.

---

Client Suitability and KYC Depth by Investor Type

Every UAE financial regulator requires customer due diligence, but not every customer requires the same level of verification. The software should therefore determine onboarding requirements based on investor classification rather than presenting one universal KYC process.

Retail investors typically require the deepest verification.

A compliant onboarding workflow normally includes Emirates ID verification, passport validation, proof of address, source of funds declarations, sanctions screening, politically exposed person screening, identity verification, and suitability assessments before investment products become available.

Suitability assessment is equally important.

The platform should evaluate investment objectives, financial knowledge, investment experience, income level, liquidity requirements, loss tolerance, and risk appetite before recommending or allowing access to higher-risk financial products.

This assessment should not remain static.

Whenever customer circumstances change or new regulated products become available, the suitability engine should request updated information before permitting additional investment activity.

Professional and qualified investors often qualify for simplified onboarding under certain regulatory permissions.

However, enhanced due diligence still applies whenever politically exposed persons, high-risk jurisdictions, complex ownership structures, or elevated transaction risks are identified. Investor classification reduces unnecessary friction but does not eliminate compliance obligations.

Institutional clients introduce an entirely different architectural challenge.

Instead of verifying individuals, the platform must verify legal entities, directors, authorised representatives, and Ultimate Beneficial Owners (UBOs). The database therefore requires a multi-level ownership model capable of tracing corporate structures through subsidiaries until the natural persons exercising ultimate control are identified.

Many existing CRM systems only support one beneficial owner record.

Regulated investment platforms often require multiple ownership layers spanning holding companies, trusts, nominee structures, investment vehicles, and international parent organisations. Supporting these relationships requires recursive ownership modelling rather than flat customer records.

PEP screening applies across every investor category.

Whether onboarding retail investors, professional traders, institutional funds, or corporate entities, politically exposed persons should trigger enhanced due diligence workflows rather than following standard verification procedures.

The onboarding engine should therefore combine identity verification, investor classification, UBO mapping, suitability assessment, sanctions screening, and ongoing monitoring into a single orchestrated workflow instead of treating each compliance activity as an isolated process.

This produces cleaner audit trails while allowing regulated firms to demonstrate consistent decision-making throughout the customer lifecycle.

---

The 9 Core Modules Every UAE-Regulated Investment Platform Needs

A regulated securities or investment platform is ultimately defined by its software modules rather than its licence certificate. Licensing determines what the platform is permitted to do, while software determines whether those permissions can be exercised compliantly.

The first module is a jurisdiction-aware permission engine. Every action available within the platform should map directly to the activities authorised under the applicable CMA, DFSA, FSRA, or VARA licence. This prevents accidental activity expansion that could place the regulated entity outside its authorised scope.

The second module is multi-tier KYC and UBO chain management. Retail, professional, and institutional clients require different onboarding workflows, while corporate customers require ownership structures extending through every legal entity until natural-person beneficial owners are identified.

The third module is real-time AML and sanctions screening. Customer onboarding, transaction monitoring, adverse media detection, politically exposed person screening, sanctions verification, and automated suspicious activity reporting should operate continuously rather than as isolated compliance events.

The fourth module is the Travel Rule compliance engine. Originator and beneficiary information should be collected during transaction initiation, transmitted securely to receiving institutions through recognised interoperability protocols, and retained within an auditable compliance archive.

The fifth module is order management and audit trail recording. Every order, amendment, cancellation, execution, rejection, and administrative override should generate immutable records supporting market surveillance, regulatory inspection, and dispute resolution.

The sixth module handles client suitability and appropriateness assessments. Investment recommendations and product access should depend upon verified customer risk profiles, investment objectives, financial knowledge, and regulatory eligibility rather than simple account registration.

The seventh module manages controller ownership monitoring. Particularly under the CMA framework, ownership changes approaching the 10%, 30%, or 50% regulatory thresholds should generate automated approval workflows and suspend completion until regulatory consent has been obtained.

The eighth module is the ADGM Digital Securities management layer for tokenised investment products. It maintains separate governance models for fund managers and Special Purpose Vehicles while preserving blockchain ownership records that correspond with regulated securities ownership.

The ninth module is the regulatory reporting and governance dashboard. Compliance teams, executives, directors, and regulators require different reporting views, making role-based dashboards, audit exports, goAML reporting, regulator-specific submissions, and long-term record retention essential platform capabilities rather than administrative conveniences.

UAE Investment Platform Compliance at a Glance

Regulator	Jurisdiction	Key Software Requirements	Compliance Chain
Capital Markets Authority (CMA)	Mainland UAE and most free zones outside DIFC and ADGM	Jurisdiction-aware permission engine, controller ownership monitoring (10%/30%/50%), KYC and suitability workflows, order management, goAML reporting, Alternative Trading System controls where applicable	UAE Financial Intelligence Unit (goAML)
Dubai Financial Services Authority (DFSA)	Dubai International Financial Centre (DIFC)	Board-level governance dashboards, GDPR-equivalent consent management, transaction monitoring, local accountability attribution, compliance reporting, investor suitability workflows	DFSA AML/CTF Rulebook
Financial Services Regulatory Authority (FSRA)	Abu Dhabi Global Market (ADGM)	Digital Securities permission model, SPV and fund manager multi-entity governance, FSRA reporting workflows, configurable licence-tier support, institutional KYC	FSRA AML and Sanctions Rules
Virtual Assets Regulatory Authority (VARA)	Dubai (outside DIFC)	Functionally demonstrable MVP, Travel Rule engine, derivatives controls, technology security assessment, exchange surveillance, wallet compliance	VARA Rulebook Version 2.0 and Exchange Services Rulebook 2.1

---

What Does a UAE-Regulated Investment Platform Cost to Build?

Software complexity depends far more on regulatory scope than interface design. A platform supporting only investor onboarding and portfolio management requires a very different architecture from one operating an exchange, custody service, or Digital Securities infrastructure.

Most UAE-regulated investment platforms begin from approximately AED 350,000 for a core brokerage or investment management solution covering customer onboarding, KYC verification, AML monitoring, sanctions screening, order management, audit trails, and regulator-ready reporting.

Costs increase significantly when multiple jurisdictions must operate simultaneously. Supporting the CMA alongside the DFSA, FSRA, or VARA introduces multiple reporting chains, jurisdiction-aware permission models, separate compliance workflows, and regulator-specific governance requirements that extend well beyond standard financial software.

Travel Rule infrastructure also changes project scope considerably.

Unlike conventional payment processing, Travel Rule compliance requires secure communication between regulated Virtual Asset Service Providers, originator and beneficiary identity exchange, protocol interoperability, and long-term compliance archives.

ADGM Digital Securities platforms introduce another layer of complexity.

Supporting Special Purpose Vehicles, token issuance, blockchain ownership records, fund administration, and multi-entity governance requires significantly more architecture than a traditional brokerage platform despite both operating within regulated investment markets.

Projects targeting VARA require additional planning because the regulator expects a working Minimum Viable Product before granting full operational approval.

Instead of licensing first and building later, founders should expect software development and licensing activities to progress together, making early technical planning particularly important.

The most effective approach begins with regulatory perimeter mapping before estimating implementation effort. Every compliance obligation identified during discovery reduces architectural changes later in the project.

If you're planning a regulated investment platform, book a discovery session to identify the regulatory scope before committing to software architecture.

---

5 Mistakes Founders Make Building UAE Investment Platforms

Mistake 1: Treating CMA custody and arranging custody as the same activity.

Although operationally similar, CMA Decision No. 4/R.M/2026 treats custody and arranging custody as separate regulated activities. Permission models that merge both functions can unintentionally enable services outside the firm's licensed scope.

Mistake 2: Assuming ADGM tokenisation requires exchange licensing.

Digital Securities issued by regulated investment structures are not automatically classified as Virtual Assets inside ADGM. Exchange licensing generally becomes necessary only when operating a trading venue rather than issuing tokenised fund interests themselves.

Mistake 3: Building Travel Rule compliance after launch.

Travel Rule obligations begin when the transaction is created, not when compliance reports are generated. Retrofitting originator and beneficiary data into an existing transaction engine usually requires significant redesign of the platform's core data model.

Mistake 4: Using one global sanctions workflow for every regulator.

Each UAE regulatory framework follows its own reporting channels, supervisory expectations, and compliance processes. A single AML configuration cannot automatically satisfy CMA, DFSA, FSRA, and VARA simultaneously without jurisdiction-aware routing.

Mistake 5: Waiting until VARA approval before building the platform.

VARA evaluates functioning software as part of the licensing process. Delaying development until after regulatory approval creates unnecessary licensing delays because the regulator expects operational capability rather than architectural plans alone.

Why Pixbit Solutions

Building a regulated investment platform requires more than implementing trading features. The software architecture must reflect the regulator's expectations from the first database design through every compliance workflow. At Pixbit Solutions, we approach fintech development by mapping regulatory obligations to technical modules before implementation begins.

Our development stack combines Laravel for permission engines, KYC orchestration, Travel Rule integration, AML workflows, and regulatory reporting; React and Next.js for compliance dashboards and governance portals; and Flutter for bilingual investor onboarding and portfolio management applications. With 148+ projects, 85+ clients, and delivery experience across 20+ countries, our team has developed complex financial platforms, including a UAE fintech platform Pixbit delivered supporting payment gateways, e-wallet functionality, and multi-channel financial transactions.

Every engagement starts with regulatory perimeter mapping before software architecture is designed. This discovery-first approach helps define jurisdiction, compliance scope, reporting obligations, and technical modules before development begins.

---

Getting Started

If you're planning a regulated investment or securities platform for the UAE market, the first decision isn't choosing a framework or programming language—it's identifying which regulator governs your business model and translating those obligations into software architecture.

Whether your platform falls under the CMA, DFSA, FSRA, or VARA, book a discovery session with Pixbit Solutions. We begin every project by mapping the regulatory perimeter, identifying the required compliance modules, and producing a technical specification that aligns software architecture with licensing requirements before development starts.