v2.1.0 to v2.1.0

---

name: 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

1. **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.

2. **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.

3. **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.

4. **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.

5. **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.

6. **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.

7. **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.

## Related Skills

- `us-reg-nms-order-protection-rule-compliance`

- `eu-market-abuse-regulation-mar-surveillance`

- `mifid-ii-algo-trading-compliance-eu`

- `transaction-cost-analysis-tca-integration`

- `post-trade-execution-quality-scorecard`

- `record-retention-periods-by-jurisdiction`

- `clock-synchronization-ptp-for-trading-hosts`

- `structured-logging-for-post-incident-forensics`