Best Execution Record Keeping Global

When to Use

Use this skill when capturing trade executions and you need (a) an execution-quality screen that flags outliers against a benchmark, and (b) a tamper-evident record of every trade and every screening decision, retained as evidence.

BestExecutionRecordKeepingGlobalEngine in scripts/best_execution_record_keeping_global.py screens one record at a time, accumulates every exception it finds, and appends the record plus verdict to a hash-chained audit log that verify_audit_log() can re-check.

When NOT to Use

As a determination that best execution was achieved. is_compliant=True means "nothing flagged by this screen". Best execution under MiFID II Article 27(1) and FINRA Rule 5310 is a multi-factor, process-based obligation weighing price, costs, speed, likelihood of execution and settlement, size, and nature. A slippage threshold tests one factor. Never report a green flag as evidence of compliance.
As your archive. export_audit_log() writes a JSON file. Retention obligations differ by regime (see references/standards.md) and no plain file on writable storage satisfies any of them. Hash chaining makes tampering detectable; it does not make records immutable.
To produce Rule 605 or Rule 606 reports. Those are broker-dealer and market-centre obligations with prescribed formats. A buy-side firm is the recipient of a Rule 606(b)(3) report, not the filer. This engine produces neither.
To satisfy a specific jurisdiction out of the box. The engine is deliberately jurisdiction-neutral. Which tags are mandatory, which timestamp granularity applies, and how long records must be kept are all constructor inputs or your own storage decisions, because the answers differ per regime and per firm status.
As a substitute for a periodic execution-quality review. Per-order screening does not replace the regular and rigorous review FINRA expects at minimum quarterly, on a security-by-security and type-of-order basis, from members not reviewing order by order.

Prerequisites

Trade capture producing, per order: identifiers, side, quantity, venue, algo/trader/ client IDs, individual fills with price and quantity, and ISO-8601 UTC timestamps with an explicit offset.
A benchmark price per order (arrival price, interval VWAP, TWAP) captured before or during execution, not reconstructed afterwards from the fills themselves.
A decision, written down, on: which regulatory_tags your regime requires, what slippage_tolerance is defensible per instrument and order type, which TimestampPrecision your trading activity attracts, and your retention period.
Retention-locked or externally anchored storage for the exported log.

Workflow

Configure the engine to your obligation, not to the defaults. Pass required_tags naming the tags your regime actually requires — the default empty tuple only checks that some tag exists, which nearly anything passes. Pass timestamp_precision matching your activity under RTS 25 (1 s voice/RFQ/negotiated, 1 ms other activity, 1 µs high-frequency algorithmic trading); the default checks nothing, because there is no universal figure.
Set slippage_tolerance deliberately and record why. It is a firm risk parameter with no regulatory basis — no regulator prescribes a number. A single tolerance across a large-cap and an illiquid small-cap will generate false positives on one and miss real outliers on the other.
Capture the benchmark before you need it. A record submitted with benchmark_price=None is flagged as not assessed, with slippage set to nan and slippage_evaluated=False. That is the correct outcome — a missing benchmark is an evidence gap, not a clean execution.
Screen each record with run_best_ex_checks(). It returns every violation in violations, not just the last one. Read the list, not only is_compliant: a record can breach slippage and be missing tags, and both belong in the compliance file.
Verify the chain before relying on the log. verify_audit_log() returns an empty list when the log is internally consistent, or one message per problem identifying the entry by sequence number. Run it before any export or examiner request.
Anchor the head hash externally. head_hash is the tip of the chain. Publish or escrow it on a schedule. Without an external anchor, a party who can rewrite the whole log can recompute a self-consistent chain and verification will pass.
Archive under your retention rule. Export, then move the file to storage that meets your regime's requirement, and keep it for the applicable period — five years under MiFID II Article 16(6) (up to seven on a competent authority's request), six years under FINRA Rule 4511 where no other period is specified.

Full procedure: see references/workflows.md. Per-regime rules, current status, and sources: see references/standards.md. Printable sign-off checklist: see assets/checklist.md.

Common Pitfalls

Reading a pass as a best-execution determination. The single most dangerous misreading of this skill. See When NOT to Use.
Treating a missing benchmark as a clean execution. Before version 2.1.0 the engine reported slippage=0.0 and "Best execution standards met" for a record with no benchmark — the check was skipped and the skip looked like a pass. Test slippage_evaluated, never the number.
Reading only the last violation. The engine used to overwrite its own notes, so a 33% slippage breach on a record that was also missing tags was filed as "Missing regulatory tags". Read violations.
Assuming a failed record was logged. It now always is. Previously a missing execution timestamp returned early with an empty hash and no audit entry, discarding precisely the record an examiner asks about.
Believing a per-record hash proves anything. A hash stored next to the record it hashes is recomputable by whoever edits the record. Only the chain plus an external anchor gives evidence.
Citing RTS 28 as a live obligation. Article 27(6) of MiFID II and its RTS 28 annual top-five-venue reports were deleted by Directive (EU) 2024/790; ESMA told national authorities to deprioritise supervision from 13 February 2024.
Citing SEC Regulation Best Execution. It was proposed in December 2022 and withdrawn on 12 June 2025 without being adopted. FINRA Rule 5310 remains the operative US best-execution rule for FINRA members.
Asserting microsecond or nanosecond timestamps are universally mandatory. RTS 25 sets granularity by activity and never mentions nanoseconds. Over-specifying wastes infrastructure; under-specifying breaches.
Assuming WORM is required. SEC Rule 17a-4 has permitted an audit-trail alternative since the October 2022 amendments took effect on 3 January 2023. WORM remains one permitted option, not the only one.
Confusing whose obligation it is. Rule 605 binds market centres and, since the 2024 amendments, broker-dealers introducing or carrying at least 100,000 customer accounts. Rule 606 binds broker-dealers routing customer orders. RTS 27 bound execution venues. A buy-side quant firm is generally none of these.
Naive or local-time timestamps. A timestamp with no offset, or one in local time, is flagged. Recording "10:00:02" with no offset makes cross-venue sequencing unreconstructable after a daylight-saving transition.

Verification

Confirm a record with two simultaneous breaches reports both in violations and both in notes (test_all_violations_recorded_not_just_the_last).
Confirm a record with no benchmark, and one with no fills, are each non-compliant with slippage_evaluated=False and slippage as nan — not 0.0.
Confirm a record failing validation still produces a non-empty record_hash and a single audit-log entry.
Confirm slippage is adverse-cost signed: buying above and selling below the benchmark both yield positive slippage; confirm the volume-weighted average is used, not the simple mean (90@10 and 110@90 against a 100 benchmark gives +8%, not 0%).
Confirm slippage exactly equal to the tolerance does not flag (strict >).
Confirm tampering is detected: edit a logged record, delete an entry, reorder entries, and flip an is_compliant verdict — verify_audit_log() must report each.
Confirm identical records hash identically across engine instances.
Confirm the export round-trips non-ASCII instrument and venue names as UTF-8.
Run python -m unittest discover -s skills/best-execution-record-keeping-global/scripts and confirm a 100% pass rate.

Best Execution Record Keeping Global

When to Use

When NOT to Use

Prerequisites

Workflow

Common Pitfalls

Verification

Hands off to 8

Handed off from 11

When to Use

When NOT to Use

Prerequisites

Workflow

Common Pitfalls

Verification

Related Skills

Hands off to 8

Handed off from 11