> Disclaimer: This content is for educational and reference purposes for software builders only. It does not constitute medical, legal, financial, or regulatory advice. Consult a qualified professional before making decisions based on this content.
1. Use LEI Validation as a Pre-Transaction Gate
Validate the counterparty LEI against the GLEIF API before accepting any trade input into the transaction reporting pipeline. Reject LEIs with status LAPSED, RETIRED, or PENDING_ARCHIVAL. Implement a LEI cache with a 24-hour TTL to reduce API calls, with immediate invalidation when a status change is detected. A single invalid LEI will cause an RTS 22 report rejection by the ARM and potentially a regulatory breach.
2. Store UTC Timestamps at Every Lifecycle Stage
All trade timestamps in MiFID II systems (order receipt, execution, reporting submission) must be stored in UTC with at least millisecond precision. The RTS 25 clock synchronisation standard (Commission Delegated Regulation 2017/574) requires trading venue systems to synchronise clocks to UTC within 1 millisecond for non-HFT algorithmic systems and record timestamps with millisecond accuracy for equity instruments. For HFT gateway-to-gateway latency, the requirement is tighter: synchronisation within 100 microseconds (Commission Delegated Regulation 2017/574, Annex I). Never convert to local time in the database - store UTC and convert only at the display layer.
3. Separate Transaction Reporting from Business Logic
Implement the transaction reporting pipeline as a separate bounded context or service, not inline with the trade execution flow. This allows: (1) independent failure and retry handling for the reporting service without impacting execution; (2) easier testing of the 65 RTS 22 field mapping against mock data; (3) independent monitoring of report submission SLAs. Use an event-driven architecture where every executed trade publishes a TradeExecuted event consumed by the reporting service.
4. Implement Client Categorisation as a State Machine
Model client categorisation as a formal state machine with valid transitions: UNCATEGORISED → RETAIL → PROFESSIONAL (elected) → ELIGIBLE_COUNTERPARTY. Every transition must require: collected evidence, an assessment decision, an approving officer, and a timestamp. Store each state transition in an immutable log. Apply the categorisation check at every product purchase or service subscription - a retail client must not receive services designed for professional clients.
5. Version KIDs and KIIDs with Delivery Tracking
Every KID and KIID update must create a new document version with a semantic version number and the date it became effective. Before a retail client executes a transaction in any PRIIP or UCITS, verify that: (1) the current version of the KID/KIID has been delivered to the client; (2) delivery occurred before the transaction was confirmed; (3) the delivery timestamp and client acceptance are logged. Treat KID delivery as a hard gate - block execution if delivery cannot be confirmed.
6. Implement ARM Submission with Idempotent Retry
Transaction reports submitted to ARMs may fail due to transient network or ARM-side errors. Implement idempotent retry with exponential backoff and a maximum retry window of T+1 (the regulatory deadline). Assign each transaction report a globally unique report ID before submission. On retry, resend with the same report ID so the ARM can de-duplicate without creating duplicate reports at the NCA. Monitor submission SLAs via a dedicated compliance dashboard that alerts when less than 4 hours remain before the T+1 deadline.
7. Enforce Target Market Compatibility Before Product Sale
For every product offer to a retail or professional client, run a target market compatibility check: compare the client's profile (knowledge, experience, financial situation, risk tolerance, investment horizon) against the manufacturer's target market definition for the product. If the client falls outside the target market, log the incompatibility event, warn the advisor, and require an override with documented justification. Store all compatibility decisions and overrides in an audit log accessible to compliance.
8. Automate Best-Execution Evidence Collection
For every order, capture and store: (1) the execution venue actually used and the MIC code; (2) the alternative venues considered; (3) the price achieved vs. the EBBO at the moment of routing; (4) the rationale for the venue chosen (e.g., price improvement, reduced latency). This evidence must be available on demand for NCA examinations and must support the generation of annual RTS 28 reports. Never rely on post-hoc reconstruction - capture evidence at execution time.
9. Monitor Dark Volume Against DVC Thresholds in Real Time
If operating or connecting to a dark pool using reference price or negotiated transaction waivers, implement real-time DVC monitoring that compares your dark-traded volume against the ESMA-published caps (4% per venue, 8% total EU). When your volume approaches 80% of the applicable cap, generate an alert and switch to alternative execution strategies. When a DVC suspension is announced by ESMA, automatically disable dark-order routing for the suspended instrument within the same trading session.
10. Implement Suitability Assessment as a Pre-Investment Gate
For investment advice and portfolio management services, block execution until a valid suitability assessment confirms the instrument is suitable for the client. A suitability assessment is valid only if: (1) client information was collected within the firm's defined refresh period (typically 1-2 years); (2) all three suitability dimensions (knowledge/experience, financial situation, objectives) are covered; (3) the suitability determination logic has been applied and recorded. Generate a suitability report and deliver it to the client before or with the trade confirmation.
11. Design Position Limit Monitoring for Commodity Derivatives
For commodity derivatives, implement real-time position aggregation that sums all positions (direct holdings, economically equivalent positions, positions held via group entities) against the applicable NCA-published position limit. Implement hard blocks when a client reaches 90% of the limit and absolute blocks at 100%. For large trader positions, automate the daily position report generation and submission to the relevant NCA before the applicable deadline.
12. Test ARM Connectivity and Report Format Against ESMA Schema
Before going live, submit a batch of test transaction reports to your ARM's test environment and validate the responses. Common RTS 22 rejection causes include: invalid ISIN (not in FIRDS), lapsed LEI, missing mandatory field, invalid MIC code for execution venue, timestamp outside expected range, and buyer/seller indicator mismatch with trading capacity. Implement a pre-submission validator that checks all 65 fields against the ESMA schema before sending to the ARM.