What this chapter covers
RegTech is not KYC/AML. That chapter covers onboarding-time identity verification, sanctions screening, and PEP checks. This chapter covers the supervisory layer that operates continuously after clients are onboarded and trading: how a broker monitors its own activity for market abuse, how it reports transactions to regulators on schedule, how it retains and scans communications for conduct risk, and how it tracks regulatory changes before they become compliance failures.
Most brokers buy this layer late - after the trading stack, the client cabinet, and the dealing room are already live. That sequencing makes sense operationally but creates a trap: the closer you are to a regulator examination, the worse your negotiating position with vendors. This guide covers the four structural choices available to regional and mid-market brokers, the five axes that determine fit, and the RFP questions that distinguish capable vendors from capable sales processes.
The 4 architectures
1. In-house build
Building transaction reporting pipelines, surveillance rule engines, and communications archives internally is technically feasible. It is almost never commercially rational for regional brokers.
The core problem is not initial construction - it is maintenance velocity. MiFIR reporting schemas change with each ESMA technical standard update. FCA MAR rule libraries require calibration against new manipulation patterns as they emerge in enforcement actions. EMIR REFIT introduced new counterparty classification logic in 2024 that required reporting vendors to rebuild ingestion pipelines within a 6-month window. An in-house team that built the original system has to track these changes, source the updated specifications from regulators, build and test updated logic, and deploy within the regulatory deadline - for every jurisdiction the broker is authorised in.
Tier-1 banks with large compliance technology teams do this. They also absorb multi-year build cycles and eight-figure budgets for the privilege. For a CySEC-authorised CIF or a DMCC-registered broker, the calculus is straightforward: the engineer-years required to build and maintain a defensible multi-jurisdiction reporting stack represent a higher cost than two to three years of Cappitech or Trax licensing, with worse regulatory defensibility on the first examination.
The one partial exception is trade surveillance for single-jurisdiction operators with unusual flow profiles - some boutique prop firms build internal pre-trade controls that feed external surveillance vendors rather than relying entirely on third-party rule libraries. Even then, the surveillance alert generation is typically licensed; only the upstream feed customisation is built in-house.
2. Single-vendor platform suites
Vendors such as NICE Actimize (with its Xceed platform, targeted at mid-market) and Nasdaq SMARTS (with its full integrated deployment) offer a single contract covering trade surveillance, transaction reporting connections, and - in some configurations - communications surveillance. The commercial proposition is integration simplicity: one vendor owns the data model, one dashboard shows aggregate compliance status, one contract desk handles renewals.
The practical benefits are real. Alert correlation across surveillance and reporting in a single system can surface patterns that point solutions miss - for example, a trade surveillance alert on a suspicious pattern can be cross-referenced against the transaction report for that security on the same screen. Regulatory examination preparation is faster when all records are held in one place.
The constraints are also real. Minimum spend at NICE Actimize enterprise tier and Nasdaq SMARTS institutional tier is significant - both vendors are quoted commercially rather than listed publicly, but regional brokers should model seven-figure annual total-cost-of-ownership at institutional scale, inclusive of implementation, calibration, and ongoing managed-service fees where applicable. Implementation cycles are measured in quarters, not weeks. A single-vendor deployment means that a product gap in one module - say, weak mobile communications coverage in the comms surveillance component - cannot be solved by swapping that module without renegotiating the whole contract.
This architecture fits brokers that are large enough to absorb the spend and implementation cycle, that value consolidated regulatory reporting over best-in-class point capability, and that have compliance operations teams capable of running the integrated platform after deployment.
3. Best-of-breed point solutions
The alternative is to assemble the compliance stack from specialist vendors: Eventus Validus or Nasdaq SMARTS for trade surveillance, Cappitech (now part of S&P Global) or MarketAxess Trax for transaction reporting, Behavox or Smarsh for communications surveillance. Each vendor competes within its segment on accuracy, coverage, and integration breadth, rather than competing on suite completeness.
The commercial case for this architecture is cost control per component and the ability to upgrade or replace individual modules without renegotiating a platform contract. Cappitech’s transaction reporting pricing is per-report-type and scales with report volume; a broker that only needs MiFIR and EMIR reporting pays for those two coverage sets rather than a bundled suite that includes five other report types it does not use. When Eventus launched Validus as a cloud-native surveillance platform, it entered the market at price points substantially below Nasdaq SMARTS institutional tier - giving mid-market brokers access to sophisticated surveillance capability they could not previously afford.
The operational cost is integration burden. Three vendors mean three data integrations, three contract relationships, three incident-response chains when a submission fails or a surveillance alert cannot be correlated to a transaction record. The gaps between products - the handoff between surveillance alert data and reporting metadata - require internal compliance engineering to bridge. A broker that selects this architecture without the operational capacity to manage the integration is selecting best-in-breed on paper while running an unreliable composite in practice.
This architecture fits brokers that have clear views on which capability dimension matters most (accuracy for reporting, depth for surveillance), that have compliance technology staff capable of owning vendor integrations, and that want contract flexibility as the regulatory perimeter expands.
4. Outsourced managed reporting
Cappitech and Trax both offer managed service arrangements where the vendor takes operational responsibility for the regulatory submission, not just the software. The distinction matters: in a software-only arrangement, the broker’s operations team runs the submission process and troubleshoots failures; in a managed arrangement, the vendor runs the submission process and the broker monitors vendor-reported SLAs.
This architecture shifts operational work and, to a meaningful degree, operational risk. Submission failures, schema validation errors, and regulator gateway outages become the vendor’s problem to resolve before the submission deadline. For brokers that lack compliance operations depth - a single compliance officer covering multiple jurisdictions, for instance - this shift is commercially rational.
The important caveat, addressed separately below, is that the regulator’s accountability relationship runs with the broker, not the vendor. Outsourced reporting reduces operational burden but does not transfer regulatory liability.
Kaizen Reporting occupies a distinct position in this architecture category: it does not replace the primary reporting vendor, but audits the accuracy of whatever flow is already running. ESMA’s 2023 review of MiFIR transaction reporting quality found that roughly 30% of reports contained material errors. Kaizen’s commercial premise is that the existing reporting setup is probably wrong in ways neither the broker nor the primary vendor has identified. Procuring Kaizen alongside - not instead of - the primary reporting vendor is a defensive accuracy layer. This is a separate procurement decision from selecting the primary reporting architecture.
5 selection axes for regulated brokers
1. Regulator footprint matching your authorisation map
CySEC, FCA, DMCC, ASIC, MAS, and FINRA do not share rule sets. A surveillance product calibrated for FCA Market Abuse Regulation may have shallow coverage of Cyprus Securities and Exchange Commission circular requirements, or may have no native configuration for DFSA obligations in Dubai. When vendors describe their surveillance capabilities, the operative question is not whether they cover market abuse generically, but which regulator’s specific rule library is natively preconfigured versus which requires the broker to build custom detection rules.
Custom rule-building shifts compliance risk back to the broker. A natively configured FCA MAR rule library has been tested against FCA enforcement patterns; a custom rule that a mid-market broker builds to approximate the same obligation carries no such validation history. Nasdaq SMARTS is deployed at more than 25 regulatory bodies globally - those regulator-side deployments give it pattern libraries derived from actual enforcement actions, not just regulatory text. That is a material advantage over vendors whose surveillance library is built from rulebook interpretation alone.
For transaction reporting, the picture is different. Cappitech covers MiFIR, EMIR, SFTR, ASIC, MAS, and SEC CAT reporting natively - its multi-regulator coverage is one of its structural differentiators. MarketAxess Trax is heavily MiFID II-focused; brokers with significant non-European reporting obligations need to verify Trax’s non-EU coverage depth before procuring.
2. Lookback depth and alert recall
Surveillance vendors are evaluated commercially on two metrics that have opposing failure modes: false-positive rate (how many alerts require investigation that turn out to be benign) and false-negative rate (how many genuine market abuse events the system missed). Marketing materials for surveillance vendors emphasise false-positive reduction because compliance operations teams complain about alert fatigue. Regulators care about false negatives.
When evaluating any surveillance vendor, request case studies of false-negative recall - examples where the system identified suspicious activity that matched patterns from subsequent enforcement actions in that regulator’s jurisdiction. Generic claims about alert accuracy are not useful; vendor-specific evidence from the broker’s actual regulator footprint is. Eventus Validus was purpose-built as a cloud-native platform and supports custom alert logic that can be tuned by the broker’s compliance team. That flexibility is valuable for sophisticated operators who understand their flow; it is a risk for operators who expect the vendor’s default configuration to be sufficient without calibration.
Lookback depth also matters for pattern detection. Some manipulation patterns - layering, spoofing with intent, wash trading across related accounts - are only visible across days or weeks of order flow, not within a single session. Vendors with shallow intraday lookback will miss multi-day manipulation patterns. Ask each vendor for their maximum lookback window, how it scales with instrument and account count, and whether historical pattern queries are available after an incident rather than only in real time.
3. Comms surveillance scope - channel coverage matters
FCA supervisory work in 2024 and 2025 has focused on off-channel communications: WhatsApp messages between traders and brokers, personal email used for business discussions, Signal conversations, and unmonitored collaboration platforms. Several FCA enforcement actions in 2023 and 2024 turned on communications that were not captured by the firm’s surveillance system because the broker assumed coverage of corporate channels was sufficient. It was not.
The realistic channel inventory for a mid-market regulated broker now includes: corporate email (Exchange or Google Workspace), Bloomberg messaging, Microsoft Teams, Slack, WhatsApp Business, and - in some markets - WeChat and Telegram. Both Smarsh and Behavox have extended coverage to mobile and collaboration platforms, but coverage depth varies by plan tier and licensing arrangement. Smarsh holds a Gartner Magic Quadrant Leader position as of 2025 for its archiving coverage breadth; Behavox’s AI-driven conduct scoring goes beyond retention into active pattern detection across those channels. They are not interchangeable - Smarsh’s strength is archival completeness, Behavox’s is detection analytics.
Before any comms surveillance procurement, build the actual channel inventory for the broker’s operation. Then ask each vendor for line-item confirmation of coverage status for each channel: natively integrated, third-party connector required, not covered. A vendor that covers Outlook and Bloomberg but not WhatsApp Business covers the wrong channels for the current regulatory risk surface.
FCA SYSC 10A, MiFID II Article 16, SEC Rule 17a-4, and FINRA Rules 3110 and 4530 all specify retention periods and retrieval requirements. Data residency matters here too - a broker authorised by CySEC and FCA needs to confirm that communications archives satisfy both jurisdictions’ data location requirements, not just the vendor’s default storage region.
4. Accuracy testing as separate procurement
The premise behind Kaizen Reporting’s market position is that the dominant error mode in transaction reporting is not failure to submit - it is inaccurate submission. ESMA’s quality assessment of MiFIR reporting found that errors are widespread and systematic: wrong counterparty classifications, missing LEI fields, incorrect instrument identifiers, time-stamp format violations. Most of these errors are invisible to the broker because the regulator’s validation gateway accepts the report without flagging the semantic error.
Kaizen runs an audit of the broker’s existing reporting flow - it ingests the same source data, runs it through its own interpretation of the applicable technical standards, and compares the output against what the existing vendor submitted. The delta is the accuracy gap. This is structurally different from what Cappitech or Trax do; it is a verification layer rather than a replacement.
The procurement logic is: procure the primary reporting vendor first (Cappitech, Trax, or another), deploy it, and then procure Kaizen on top to validate that the primary vendor’s output matches regulatory requirements. For brokers under FCA or ESMA jurisdiction that have been live for more than 12 months without an independent accuracy audit, the probability that systematic errors exist in the reporting stream is high. Regulators have begun requesting historical data quality self-assessments as part of examination preparation, and brokers who can present Kaizen accuracy reports are better positioned in those examinations than those who cannot.
5. Regulatory change pace and rule sourcing
Regulatory change intelligence - tracking what rules changed, when, and what internal policies they require updating - is the domain of CUBE Global and Corlytics. Corlytics acquired ClauseMatch in 2023, adding document-level clause mapping to its regulatory change feed, which means a single Corlytics output can identify both which obligation changed and which internal policy clauses require updating.
For multi-jurisdiction operators, the value proposition is clear: a broker authorised by CySEC, FCA, and ASIC faces regulatory change events across three rule sets with different publication cadences, different effective dates, and different obligation granularities. Manual horizon scanning by a compliance counsel is insufficient at scale. CUBE and Corlytics both ingest regulatory publications from primary sources and translate them into structured obligation deltas that compliance teams can action.
For single-jurisdiction brokers - a pure CySEC CIF with no plans to expand - the question is whether the volume of regulatory change events justifies the licensing cost. CySEC’s regulatory publication cadence is lower than FCA’s, and a compliance officer with direct CySEC contact and counsel support may be able to handle manual horizon scanning adequately. The calculus changes when the broker is expanding its authorisation footprint or when the compliance team is operating at capacity. At that point, structured regulatory intelligence is a productivity multiplier, not a luxury.
Cost of ownership
RegTech vendors quote commercially; there are no public price lists. A few reference points are available from market reporting. Cappitech has at times cited mid-six-figure annual range estimates for tier-1 broker deployments, though actual contract values vary significantly with report volume, regulator count, and managed-service scope; verify current pricing directly with S&P Global Market Intelligence’s sales organisation. Nasdaq SMARTS at institutional scale carries seven-figure annual total cost of ownership inclusive of implementation and calibration. Comms surveillance vendors (Smarsh, Behavox) typically price per seat per month, with additional tiers for channel coverage - a 50-seat deployment covering five channels lands materially differently from a 200-seat deployment covering ten.
Implementation costs are a consistent underspend in broker procurement budgets. Rule library calibration for a surveillance deployment requires the broker’s compliance team to validate hundreds of alert scenarios against historical order data. Comms surveillance channel onboarding requires integrations with Microsoft 365, Bloomberg, and mobile archiving partners. Transaction reporting setup requires mapping the broker’s internal trade data to the target report schemas. These implementation activities commonly exceed the first-year licence fee, particularly for best-of-breed deployments where the integration is the broker’s responsibility rather than the vendor’s.
Budget for compliance operations headcount even if the broker selects a managed reporting arrangement. The regulator calls the broker when there is an examination or an incident - not the vendor. Someone at the broker must understand the reporting flow, the surveillance configuration, and the communications archive architecture well enough to answer a regulator’s questions accurately. That knowledge does not reside in the vendor; it resides in the broker’s compliance team.
The “regulator still calls you” principle
Transaction reporting outsourced to Cappitech or Trax, surveillance delegated to Nasdaq SMARTS or NICE Actimize, communications archives managed by Smarsh - none of these arrangements change who holds the regulatory authorisation. The CIF, the LLC, or the authorised entity is the regulated person. The vendor is a service provider.
This has practical consequences for procurement. Vendor SLA penalties for missed submissions are commercially useful but do not translate into regulatory penalty mitigation. If Cappitech misses a MiFIR submission deadline due to a system failure, CySEC’s enforcement action will name the broker, not Cappitech. SLA compensation helps recover direct costs; it does not recover the regulatory cost of a late filing.
Incident response timelines matter for the same reason. When a regulator opens an inquiry, it typically requests records on a compressed timeline - 5 to 10 business days for initial document production. A vendor whose incident response commitment is 48 to 72 hours for material breaches may still leave the broker unable to respond within regulatory timelines if the inquiry is complex. Ask vendors for their documented incident response process specifically for regulator-initiated inquiries, not just for system outages.
ESMA and FCA have both signalled, through supervisory publications and Dear CEO letters, that firms cannot satisfy supervision obligations by pointing at vendor delegations. Brokers must demonstrate active monitoring of vendor performance: periodic accuracy reviews, SLA reporting tracked internally, and documented escalation processes when SLAs are missed. Procurement that stops at contract signature is not sufficient.
3 RFP questions every regulated broker should ask
”Show us your last 3 false-negative cases for our regulator.”
This question tests whether the vendor’s rule library is calibrated for the broker’s specific authorisation, not for the market generically. A vendor with strong FCA MAR coverage should be able to present surveillance cases where its system correctly identified manipulation that matched subsequent FCA enforcement actions. A vendor operating in Dubai should be able to present cases calibrated to DFSA and DMCC obligations. Generic answers - “our system covers all major market abuse typologies” - signal that the vendor has not done the jurisdiction-specific calibration work.
Follow-on: ask for the false-negative rate from a third-party accuracy assessment, not the vendor’s internal self-assessment. Nasdaq SMARTS’s 25-plus regulator deployments mean its pattern libraries are tested against real enforcement outcomes; a vendor with three deployments has a much smaller validation base to draw from.
”What is your incident response SLA when a regulator opens an inquiry against one of your clients?”
This question separates vendors who treat compliance as a 24-by-7 operational responsibility from vendors who treat it as a 9-to-5 software service. Regulatory inquiries do not arrive with advance notice, and regulators for MiFID II and FCA purposes operate across time zones. Industry standard for material compliance breaches is 24 to 48 hours for initial vendor response, but the quality of that response matters more than its speed.
Ask for a documented process: who in the vendor’s organisation is the regulatory liaison, what is the escalation path, and can the broker access a named individual rather than a support ticket queue during an active regulatory action? This is a reasonable ask for any vendor at enterprise contract scale.
”How do you handle a regulator request for our raw data?”
This question surfaces data residency architecture, retrieval timelines, and chain-of-custody. FCA has different data export rules from CySEC; DMCC and VARA in the UAE have their own requirements around data localisation. A vendor that stores all client data in US-region cloud infrastructure may be commercially convenient and technically indefensible for a CySEC-regulated broker under GDPR.
Ask for the vendor’s data architecture: where is client data stored, what are the available export formats, and what is the documented chain-of-custody for data produced in response to a regulator request? For communications surveillance in particular, the integrity of the archive - proof that records have not been altered between capture and production - is a legal standard that the vendor’s export process must satisfy.
Cross-pillar interactions
Three other chapters in this guide intersect with RegTech in ways that matter for procurement sequencing.
The KYC/AML chapter covers ongoing transaction monitoring for money-laundering indicators and sanctions list screening. There is a specific overlap with trade surveillance: unusual trading patterns that trigger market abuse surveillance alerts may also warrant AML review if the trader profile raises layering or structuring concerns. Vendors in both categories increasingly offer data-sharing APIs for this cross-alert correlation. Buying surveillance and AML from vendors that cannot share alert data creates a gap.
The broker analytics chapter covers best execution monitoring, including RTS 27 and RTS 28 reporting. These are regulatory deliverables that overlap with surveillance data - execution quality analysis requires the same order and transaction records that feed trade surveillance systems. Brokers procuring both analytics and surveillance should validate that the data model used by each vendor is compatible, to avoid running two separate extraction processes from the same trade data source.
The risk management chapter covers pre-trade controls - position limits, margin calls, flow classification. These controls generate audit trail data that surveillance vendors need to contextualise alerts. A suspicious order pattern that is consistent with a known A-book hedging strategy in the dealing room looks very different from the same pattern with no documented hedging rationale. Surveillance vendors need access to that context; it should be part of the data integration design.
Editorial close
RegTech is the pillar where overspending and underspending both carry material downside. Long contracts with annual true-ups, hard switching costs once rule libraries and alert configurations are embedded, and professional services retainers that outlast the original contract - these are the overspend failure modes. Regulatory fines for inaccurate reporting, examination failures from missed surveillance alerts, and conduct actions traced to unmonitored communications channels - these are the underspend failure modes. A single FCA or ESMA enforcement fine routinely exceeds multiple years of licensing fees for the vendor that would have prevented it.
The discipline that protects against both failure modes is the same: enter procurement with a regulator-mapped scoping document that lists each authorisation, the specific obligations attached to it, and the data sources required to satisfy those obligations. Select vendors against that document, not against feature lists. Test accuracy as a separate procurement step, not as a trust assumption. The vendor that wins on price alone is almost always the wrong choice in a category where the regulator’s standards are the only performance metric that matters.