Regulation in plain English

INVALID — six rulebook failures, plus one additional Gentek flag. It would be rejected on six EU EMIR DRR rule breaks:

• EMIR_VR_2002_01 — 2.2 Report Tracking Number left blank. Per ESMA Q&A the RTN is only required when venue of execution (2.41) is an EU trading-venue MIC, so the report as submitted does not reconcile 2.41 and the RTN either way.
• EMIR_VR_2002_03 — the same field, mirror condition: the RTN should be blank when 2.41 is not a trading-venue MIC.
• EMIR_VR_2030_02 — the trade is flagged cleared (2.31 = Y) but 2.30 Clearing Obligation is not set to the required UKWN.
• EMIR_VR_2036_01 — 2.34 Master Agreement Type is populated (ISDA) but the required 2.36 Master Agreement version is missing.
• EMIR_VR_2037_01 — 2.37 Intragroup is missing, and it is required (TRUE/FALSE) whenever venue of execution is not a regulated-market MIC.
• EMIR_VR_2038_01 — 2.38 PTRR is populated with true, false; only a single TRUE or FALSE is allowed, not both.

The two RTN failures point at one root cause: 2.41 Venue of Execution and 2.2 Report Tracking Number are inconsistent with each other, and whichever is correct, the other needs fixing to match.

Beyond the rulebook, one Gentek check flagged something the DRR verdict does not cover: the CCP named on the trade (LEI R0MUWSFPU8MPRO8K5P83, BNP Paribas) is not on ESMA's list of authorised CCPs or the Art. 25 third-country register. That would not cause a NACK on its own — either the CCP LEI is wrong, or the trade is being routed to an entity not authorised to clear it. Everything else was clean: schema validation passed, all three LEIs resolve and are active in GLEIF, and both ISINs resolve in FIRDS.

Straight from ESMA's EU EMIR REFIT validation rules: the workbook esma74-362-2683_emir_refit_validation_rules…xlsx, sheet Validations_Cpty_derivative, field 2.30. That field has three linked conditions, error-coded EMIR-VR-2030-01/02/03; the one that fired is condition 2.

Field 2.30 records whether the contract belongs to a class of OTC derivatives subject to the clearing obligation, and whether both counterparties are themselves subject to it under Regulation (EU) 648/2012. Valid values are TRUE, FLSE or UKWN. Condition 2 ties it to field 2.31: once a trade is marked actually cleared (2.31 = Y), 2.30 must be UKWN, because the report is meant to record unknown rather than assert TRUE or FLSE. The report had 2.31 = Y with 2.30 left blank. It is conditionally mandatory at both trade and position level for a NEWT action, per the requirement matrix cells L55 and U55 on that sheet.

This one clears the DRR rulebook clean: every checkable rule ran, none failed, and schema and field formats both pass. The in-house validation was right that it is structurally sound against EMIR's own rules. Two things surface outside the rulebook check itself.

The counterparty's LEI is dead — the real problem. ANGGYXNX0JLX3X63JN86, reported as Counterparty 2, resolves in GLEIF to Credit Suisse AG with status RETIRED. Credit Suisse AG was absorbed into UBS and its registration lapsed as part of that. A retired LEI is not in the accepted set (Issued, Lapsed, Pending transfer, Pending archival), and this was checked as of the trade's own reporting date against the TARGET2 closing-day calendar, not just today. A trade repository's front-end validation typically will not catch this, because the report is schema-valid and field-format-valid — it just references an entity identifier that is no longer live.

The CCP is not on the register. Central counterparty LEI 549300FM54TXULUKO729 resolves to DTCC Solutions LLC, which does not appear on ESMA's authorised-CCP list or the Art. 25 recognised third-country register. One contextual note needing no action: the ISIN carries a GB prefix while the execution venue is coded XXXX, flagged as a note only because cross-listing is normal.

Only the Counterparty 2 LEI changed; everything else in the trade is untouched — with the flag repeated that the substitution rests on GLEIF showing that entity as UBS's main Swiss entity, not on any confirmed novation or booking mapping for this trade.

Confirmed. GENTEK-LEI-04 (the retired-LEI issue) and GENTEK-LEI-01 (the not-current warning) are both gone, and BFM8T61CT2L1QCEMIK50 resolves clean as UBS AG, Zurich, ACTIVE/ISSUED. The DRR rulebook verdict stays VALID, unaffected either way since it was already passing. Two items remain, unrelated to the LEI swap: GENTEK-CCP-01, the CCP still absent from ESMA's authorised-CCP and third-country registers, and GENTEK-MIC-03, the ISIN and venue country-prefix note, contextual only.

No, and the answer is precise about why: a lapsed registration means the entity stopped renewing, which the standing check flags as not current while the acceptance check passes it, because the regulators permit reporting a lapsed LEI. Retired is a different state with a different consequence. One check warns; the other decides.

INVALID — a three-record batch whose first record, the NEWT securities loan, is broken. Run as UK SFTR, because the test LEIs and BIC point to GB entities and the regime has to be chosen explicitly. Three schema-level failures would bounce the file before any rule logic runs: at line 43 field 1.4 Nature of reporting counterparty appears in a position the schema does not allow; at line 73 field 2.1 UTI carries bad-uti!, which fails the required pattern [A-Z0-9]{1,52}; and at line 128 field 2.15 Termination date sits where the schema does not expect it.

Record 1 also breaks three rules:

• GENTEK-SFTR-UK-MATRIX-1.3 (FCA SFT-003) — field 1.3 not populated, but required for a new securities-loan trade.
• GENTEK-SFTR-UK-MATRIX-2.15 (FCA SFT-028/029) — 2.15 Termination date is populated, but the rulebook requires it blank for a NEWT securities loan.
• GENTEK-SFTR-UK-1.6 (FCA SFT-004) — fund classification XXXX is not in the allowed set (ETFT, MMFT, REIT, OTHR), and is required because 1.5 is UCIT.

So one record carries a bad UTI, a missing mandatory field, a field populated where it must be blank, and an invalid enum value. Records 2 (VALU) and 3 (COLU) passed what could be checked. Reference data is a real gap rather than noise: none of the five LEIs resolved in GLEIF — they look synthetic rather than registered — which also knocked out the downstream checks that depend on GLEIF, and one ISIN has no FIRDS record while the other resolved fine. What did not get evaluated falls into two groups: rules needing prior trade-repository state, which cannot be checked from a single message in isolation, and rules needing date arithmetic or sign conventions the engine does not encode. Neither is a failure, and neither is silently passed.

The findings come back as an interactive page: click any finding and the corresponding line lights up in an XML pane beneath it, auto-scrolled into view, filterable by schema versus rulebook, with arrows to step through each finding in turn. One honest caveat carried on the face of it — the 1.3 finding has no line of its own, because the failure is that the field is absent, so it points at the counterparty block where the field should sit.