Regulation in plain English

Gentek

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.

Gentek

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.

Gentek

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.

Gentek

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.

Gentek

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.

Gentek

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.

Gentek

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.

Gentek

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.

Gentek

One record gets rejected: Record 02. Its UTI 549300fm54txuluko729emir26aug0020001 fails on case. EMIR field 2.1 permits only upper-case A–Z and digits 0–9, pattern [A-Z0-9]{18}[0-9]{2}[A-Z0-9]{0,32}. The lower-case characters break it twice over:

• An ISO 20022 schema failure at line 400 (auth.030.001.03_ESMAUG_DATTAR_1.1.0.xsd) — a hard structural reject, not a business-rule warning.
• A field-format failure on 2.1, error codes EMIR-VR-2001-01 through -04.

The fix is a straight upper-casing: 549300FM54TXULUKO729EMIR26AUG0020001. Record 01 passes cleanly, with no Gentek consistency issues.

Worth knowing before you submit. Because the schema error is at document level, most trade repositories reject the whole file rather than the single record. Do not assume Record 01 lands and only 02 bounces — fix the UTI and resubmit both.

Two things came back clean but are worth knowing. All four LEIs are ACTIVE/ISSUED at GLEIF. And ISIN DE0001102309 was not found in FIRDS, EU or UK — a warning rather than a reject, but it meant six Gentek checks could not run, including the CFI-versus-asset-class and venue-admission consistency checks. If that ISIN genuinely is not FIRDS-registered you are flying without those checks, so it is worth confirming it is the right product identifier.

Source: ESMA EMIR REFIT validation rules, sheet Validations_Cpty_derivative, cell L26.

Gentek

Field 2.1 under EU EMIR REFIT: four rules and one schema pattern — and they do not all say the same thing, which is worth understanding.

• EMIR-VR-2001-01 — the general format rule: up to 52 alphanumerical characters, with four special characters allowed (: . - _) but not at the beginning or the end. This is ESMA's generic identifier boilerplate, permissive on case, and it is where the UTI / UTI (Proprietary) choice lives: exactly one of the two must be present.
• EMIR-VR-2001-02 — the case rule, and the one this batch tripped: for action types NEWT and POSC, only the upper-case characters A–Z and the digits 0–9 are allowed. It narrows -01 sharply, but only for those two action types. Both records here were NEWT, which is why the lower-case UTI was fatal rather than tolerated.
• EMIR-VR-2001-03 — immutability: the content of this field may not change once reported. A wrong UTI cannot be corrected with a CORR; it means an EROR and a re-report under the right one. In the Gentek tooling this rule is a placeholder, because it needs the repository's own trade state and a single-file check cannot test it.
• EMIR-VR-2001-04 — uniqueness against its sibling identifier fields: the code must differ from the Report Tracking Number (2.2), the Prior UTI (2.3) and the Subsequent Position UTI (2.4). Record 01 has a Prior UTI populated and it differs, so it passes.

Separately from the rules, ESMA's own Format column for 2.1 states: ISO 23897 UTI, up to 52 alphanumeric characters, only the upper-case characters A–Z and the digits 0–9 allowed.

The schema pattern is stricter than any of the above. The ISO 20022 EMIR usage guideline enforces [A-Z0-9]{18}[0-9]{2}[A-Z0-9]{0,32} — the ISO 23897 construction made mandatory in XML: a 20-character LEI-derived prefix (18 alphanumerics then 2 digits, matching an LEI's body plus its check digits), followed by up to 32 further upper-case alphanumerics. Minimum 20 characters, maximum 52. So a UTI can satisfy VR-2001-01 and still fail the schema: ABC-123 clears the general rule but has no valid prefix, and lands at the XSD as a structural reject before any business rule runs. Which is exactly what happened to Record 02.

Operationally, the layer that catches you is what decides the consequence:

• Lower case, wrong length or bad structure is caught at the XSD — the whole file is rejected, often before any record is processed.
• VR-2001-02 (case, on NEWT/POSC) and VR-2001-04 (a collision with 2.2, 2.3 or 2.4) are caught in the business rules — a record-level reject.
• VR-2001-03 (changed after reporting) is caught by the repository's trade state — a reject at the TR, and one that cannot be pre-validated from the file alone.

The upstream fix here is to upper-case the UTI at the point of generation, not in a pre-submission scrub. Whatever produced 549300fm54txuluko729… is emitting the LEI prefix in the wrong case, and if it did that once it will do it again.

Sources: ESMA EMIR REFIT validation rules, sheet Validations_Cpty_derivative, field 2.1 (cell L26 for NEWT at trade level); rule text via ISDA DRR 7.6.0, ESMA EMIR ValidationRules table 2, data element 1.

Gentek

It passes. VALID against the ISDA DRR rulebook, with no failures. The ISO 20022 schema now passes, every field format passes, and the Gentek checks found nothing inconsistent.

The diff between the two files is exactly one line — line 400, Record 02's UTI, now 549300FM54TXULUKO729EMIR26AUG0020001. Nothing else changed, so nothing else was disturbed.

The ISIN is still not in FIRDS. DE0001102309 does not resolve in either the EU or the UK register. That is not a reject and it did not block the verdict, but it does mean six checks could not run: the CFI-versus-asset-class consistency checks (GENTEK-CFI-01/02/03), venue admission (GENTEK-MIC-02/03), and the counterparty-2 sector check. So the file is clean on everything that could be tested, and the product identifier itself is untested. Worth a look at whether DE0001102309 is the intended identifier, given it is a German government bond ISIN sitting on a GBP SONIA interest-rate contract.

The unchecked count is normal, not a gap you introduced. Of the rules that did not run, most read fields this message format does not carry and the rest needed register records unavailable to this run — the same picture as the first pass. The fix changed only the failure, not the coverage.

One process matter rather than a validation one: the file being byte-identical apart from the case change confirms this was a pure formatting defect at the point of UTI generation. Since VR-2001-03 makes the UTI immutable once reported, that generator is worth fixing upstream — a lower-case UTI that did reach the repository could not be corrected with a CORR, only cancelled with an EROR and re-reported.

Gentek

Nothing is wrong with the file. The world moved underneath it.

Against the ISDA DRR rulebook for ESMA EMIR the report is valid — every checkable rule ran, none failed, and it passes the auth.030 ESMA schema. The single blocking issue is a reference-data one.

Counterparty 2 (field 1.9) is ANGGYXNX0JLX3X63JN86 — Credit Suisse AG. In GLEIF today that LEI has entity status INACTIVE and registration status RETIRED, following a completed merger with effective date 31 May 2024, recorded 3 June 2024. EMIR requires counterparty LEIs to hold a registration status inside the accepted set — Issued, Lapsed, Pending transfer, Pending archival. RETIRED sits outside it, so the repository rejects on the EMIR-VR-1009 family for field 1.9.

Why it used to pass. That check is evaluated against GLEIF as at submission, not as at booking. GLEIF publishes only the current status — there is no as-of history in the feed — so the repository re-reads the LEI on every submission and gets today's answer. The file is byte-identical; the answer to the question it asks is not. The status had to hold as of the event date plus one business day on the TARGET2 calendar, and by then the LEI was already retired.

What to do. Resubmitting will not help — the rejection is not recoverable by retry. The real question is what happened to the trade: a retired counterparty LEI normally means the entity was absorbed and the contract transferred to the surviving entity. That should go to the repository as the lifecycle event that actually occurred — a step-in or novation reported against the successor's LEI — not as a re-send of the original NEWT with the dead LEI swapped out. Note that GLEIF's record for this LEI has an empty successorEntity field, so the surviving entity's LEI needs confirming from your own onboarding or client documentation rather than being inferred from the register.

One secondary note, not the cause. The product ISIN DE0001102309 does not resolve in either EU or UK FIRDS, which also meant six of Gentek's consistency checks — CFI versus asset class, and venue admission — could not run. That is a warning rather than the reason for rejection, but it is worth looking at while the record is open: a German government bond ISIN as the product identifier on a GBP SONIA rates trade looks like a mapping error.

Sources: ESMA EMIR REFIT validation rules, sheet Validations_Cpty_derivative, field 1.9; the GLEIF record for ANGGYXNX0JLX3X63JN86, looked up live.

Gentek

No — and the distinction matters more than "lapsed sounds bad".

LAPSED is an accepted status for Counterparty 2. EMIR_VR_1009_02 requires the field 1.9 LEI to be Issued, Lapsed, Pending transfer or Pending archival. Lapsed is explicitly in that set, so the repository keeps accepting it. That is the opposite of RETIRED, which sits outside the set and is why the Credit Suisse trade fails.

The reason for the asymmetry is that lapsed simply means nobody paid the renewal fee — the entity still exists and is still your counterparty. Retired means the registration was closed because the entity ceased to exist. You cannot stop reporting a live trade because your counterparty was slow with paperwork.

But check which field the lapsed LEI sits in, because the accepted set is not the same across fields:

• 1.4 Counterparty 1 (the reporting counterparty) — Issued, Pending transfer, Pending archival. Lapsed is not accepted.
• 1.9 Counterparty 2 — Issued, Lapsed, Pending transfer, Pending archival. Lapsed is fine.
• 1.2 Report submitting entity — Issued, Lapsed, Pending transfer, Pending archival. Lapsed is fine.

Counterparty 1 is the strict one: ESMA drops Lapsed from that list, because you are expected to keep your own LEI renewed. So if the lapsed LEI is a counterparty you face, you are fine. If it has ever been used as Counterparty 1, or as the entity responsible for reporting on a report you submit, that rejects on EMIR_VR_1004_02 and needs renewing before the next NEWT, MODI, VALU, CORR or POSC.

Two timing points worth knowing. The status is verified as of the reporting timestamp (field 1.1) — not today, and not trade date. And the rule is switched off entirely where the event date (field 2.153) is earlier than the day preceding the reporting timestamp, so backloaded and late-reported records skip the status check. That is also why a retired LEI can pass on some submissions and fail on others.

Separately, for action types TERM, REVI and EROR, these fields require only that the LEI exists in GLEIF, irrespective of registration status (EMIR_VR_1009_03 and EMIR_VR_1004_03). That is the route out on the Credit Suisse trade: you can still terminate or correct it with the retired LEI in place — it is only the NEWT, MODI and VALU family that is blocked.

Note that Gentek's own GENTEK-LEI-01 check still raises a warning on a lapsed LEI, that the registration is not current. That is advisory — it does not change the rulebook verdict and it is not what a repository rejects on. Worth chasing the counterparty about; not worth halting reporting for.

Sources: ISDA DRR 7.6.0 rules EMIR_VR_1002_02, EMIR_VR_1003_02, EMIR_VR_1004_02/03 and EMIR_VR_1009_02/03 (ESMA EMIR Validation Rules, table 1); ESMA EMIR REFIT validation rules.

Gentek

The rulebook passes, and that is the point. Every DRR rule that could be evaluated on this report held, the ISO schema validated and every field format passed — submitted as-is it would very likely be accepted. No rule in the rulebook compares a reported ISIN with what the instrument actually is: the official conditions on 2.7 ISIN govern when the field must be present and that it carries twelve characters with a check digit, and nothing further. The Gentek checks are what disagree, and they sit outside the rulebook, so they do not move the verdict above them.

• GENTEK-CFI-01 (issue) — US9311421039 resolves in FIRDS to an instrument with CFI ESVUFR, category E, a cash instrument consistent with EQUI, while the trade reports 2.11 Asset class of INTR and 2.10 Contract type of FRAS.
• GENTEK-CFI-03 (warning) — the trade's own 2.9 Product classification of EPVRFB disagrees with the FIRDS record on category and group: EP against ES.
• GENTEK-MIC-02 (warning) — 2.41 Venue of execution reports XPAR (Euronext Paris), which appears in none of the FIRDS records retrieved for that ISIN.
• GENTEK-MIC-03 (note) — the ISIN's US country prefix against a venue in FR; cross-listing is routine, so the check reports this as contextual only.

Two fields point at the same bad record rather than one stray value: 2.9 is an equity-category CFI as well, so the product classification came from the same instrument as the ISIN. That is the signature of a whole static-data record mapped onto the trade, which is a question about the rest of the feed run rather than this trade alone.

Gentek

Both registers hold the same instrument, and the answer is the same either way. Across every record returned, EU and UK, the identifying attributes never move: CFI ESVUFR, issuer LEI Y87794H0US1R65VBXU25, currency USD, short name WAL-MART STORES/SH. There is no record in either register under this ISIN carrying a derivative CFI, an interest-rate classification or a GBP denomination.

• The split is jurisdictional, not substantive — ESMA FIRDS reports competent authority DE throughout with every record active; FCA FIRDS reports GB throughout, with a minority of admissions expired.
• The EU venue set is a strict subset of the UK set — every ESMA venue also appears in the FCA register, which carries further UK-supervised venues, the Cboe and Aquis families among them, on top.
• XPAR is absent from both — not expired in one and active in the other, simply not present in either. The venue is not explained by a UK/EU register divergence.
• The conflicts the examination flagged are register texture — varying issuer names, a wide spread of first-trade dates, DE against GB: these are per-venue submissions from many operators plus the post-Brexit fork, not a data quality signal.

Neither register offers a reading under which US9311421039 belongs on an interest-rate FRA. The feed did not hand over a stale or jurisdictionally mismatched record — it handed over a different instrument.

Gentek

Then the problem is larger than the ISIN. Re-examined with 2.41 changed from XPAR to XXXX and nothing else touched, the rulebook verdict flips from valid to invalid and four rules fail at once.

• EMIR_VR_1003_01 — 1.3 Entity responsible for reporting must be populated unless 2.41 names a regulated market, or a third-country market treated as equivalent to one. It is blank.
• EMIR_VR_2037_01 — 2.37 Intragroup carries the same condition on the same venue test. It is blank too.
• EMIR_VR_2002_01 — 2.2 Report tracking number is required only where 2.41 holds the MIC of a venue in the Union. It is populated.
• EMIR_VR_2002_03 — and it must be left blank where 2.41 is XXXX or XOFF, which is now the case.

XPAR is load-bearing. It is a regulated-market MIC in an EU country, and that one value switches off two conditional obligations and switches a third on. The report validates only because 2.41 claims a regulated market: 1.3 blank, 2.37 blank and 2.2 populated are all internally consistent with an EU on-venue trade. That is not one field carrying a bad value — the record is shaped around the assumption, which also inverts the remediation, since any correction to 2.41 has to move the other fields with it.

The uncomfortable part is what caught it. GENTEK-MIC-01 passes XPAR against the bundled ISO 10383 register, because it is a real and active MIC. The only check that questioned the venue was GENTEK-MIC-02, and it could do so only because there was an ISIN to cross-reference; at XXXX that check passes, since a code asserting the instrument is admitted nowhere leaves no admission to check against. Correcting the ISIN to the UPI an OTC FRA would normally carry removes the cross-reference altogether, and a valid-but-wrong MIC then has no deterministic register test left to fail.

Gentek

INVALID — and the rule that fails is the field you changed. EMIR_VR_2033_02 fires on 2.33 Central counterparty: 6SI7IOVECKBHVYBTB459 is CME Clearing Europe Limited, whose GLEIF record is INACTIVE with registration status RETIRED. The rule requires the LEI status to be Issued, Lapsed, Pending transfer or Pending archival as at the reporting timestamp, 2026-08-10. RETIRED is not in that set.

Everything else in the rulebook passed — schema valid, field formats clean, and the other three LEIs (counterparties, submitting agent, clearing member) all resolve ACTIVE/ISSUED. The timing is fine too: event Friday 7 August, reported Monday 10 August, which clears the TARGET2 calendar.

Three things sit alongside the failure, none of which changes the verdict:

• A Gentek check, GENTEK-CCP-01, lands on the same entity independently: it appears on ESMA's list of authorised CCPs only as a struck row — its EU authorisation ceased — and it is not on the Art. 25 third-country register either. That is a question about the clearing arrangement rather than about the filing.
• The document declares the ESMA usage guideline, so it validated as EU EMIR, but it is also schema-valid under the FCA UK guideline, and the trade is GBP/SONIA with GB entities throughout. Worth confirming which repository the run is destined for — the CCP fails under either, but the rest of the run may be pointed at the wrong regime.
• The product ISIN DE0001102309 did not resolve in FIRDS, EU or UK. A German government bond ISIN on a GBP interest-rate FRA looks like a mismatch; no rule fired on it, though several Gentek checks could not run precisely because there was no FIRDS record to read a CFI or venue list from.

No successor LEI is recorded in GLEIF, so there is nothing to map to automatically — which CCP the trades actually cleared at has to come from the clearing records. And if this CCP change was applied across a batch rather than to this one trade, the same failure will hit every cleared record in the file.

Gentek

It does not come from the reporting rules. The rulebook's entire interest in the CCP is whether the LEI is in GLEIF and what state that record is in. Of the rules on 2.33, two matter here. EMIR_VR_2033_01 — when 2.31 Cleared is 'Y', the field must hold a valid LEI included in the GLEIF database maintained by the Central Operating Unit — passed, because retired LEI records stay published in GLEIF, so the record exists and the rule is satisfied. EMIR_VR_2033_02, the registration-status rule, failed. ESMA's own field definition says the same thing: the format is an ISO 17442 LEI included in the LEI data published by GLEIF. None of the rules on that field mentions the authorisation register, and a trade repository will not check the CCP against it when it validates the file. In ESMA's workbook those conditions carry the error codes EMIR-VR-2033-01 through -04.

The register point is ours. It comes from GENTEK-CCP-01, one of the additional checks Gentek runs beyond the rulebook. Its own definition: when 2.31 Cleared = 'Y', the LEI in 2.33 is looked up on the ESMA register; absence, or a struck (withdrawn) row, is an ISSUE, and a recognised third-country CCP is a NOTE. The examination reports it in its own section, separate from the verdict, for exactly this reason.

The rationale for the overlay is substantive rather than procedural: under EMIR a CCP clearing for EU counterparties needs Art. 14 authorisation or Art. 25 third-country recognition, so a struck row is a signal that the clearing arrangement itself may be a problem — not that the report is malformed. Different question, different owner, and not one to settle from validation output alone; it is worth putting to whoever approved the CCP switch.

For tonight, the rulebook failure stands on its own: a RETIRED LEI in a field that is mandatory once the trade is cleared will be rejected. Both findings trace to the same root cause — the LEI points at a company dissolved in January.

Gentek

Clearing touches two layers, and they are worth keeping apart the same way. On the rulebook side, the ESMA EMIR Trade rules reach clearing through several fields: 1.7 and 1.13 clearing threshold for each counterparty, 1.16 Clearing member, 2.30 Clearing obligation, 2.31 Cleared with 2.32 Clearing timestamp, and 2.33 Central counterparty. They test much the same things throughout — populated when required, a valid GLEIF LEI, an acceptable LEI status, and the ordering of the clearing timestamp against execution and reporting. The clearing-member rules mirror the CCP ones almost exactly: EMIR_VR_1016_02 is the same "valid LEI included in the GLEIF database" test as EMIR_VR_2033_01. On this report the clearing member is DTCC Derivatives Repository plc, ACTIVE/ISSUED, so that side passed.

On the Gentek side, these bear on clearing:

• GENTEK-CCP-01 — the CCP named on a cleared trade is looked up on the ESMA register. EU EMIR only. Here: ISSUE.
• GENTEK-CCP-02 — a cleared trade actually carries a CCP LEI. Passed.
• GENTEK-CCP-04 — where counterparty 2 is itself the CCP, its corporate sector should read CCPS. Not run here, because field 1.12 was not reported.
• GENTEK-LEI-03 — the CCP is not counterparty 1; an entity cannot clear its own trade. Passed.

GENTEK-LEI-01 and GENTEK-LEI-04 sweep every LEI in the report, the CCP and the clearing member included, which is how the retired registration surfaces in the Gentek checks as well as in the rulebook.

Given a CCP migration, what is not covered matters as much as what is:

• Nothing verifies that the reported clearing member is actually a clearing member of the CCP named — both LEIs are checked in isolation, never as a pair.
• Nothing reconciles the clearing obligation code against whether the product is genuinely subject to mandatory clearing.
• 2.30 Clearing obligation is UKWN on this trade, which passes validation but tells a reviewer nothing.

One caveat on precision: the catalogue tags each rule by how it is evaluated — against reference data, through a DRR model function, or as a placeholder with no executable check — but those tags cannot be mapped onto which specific clearing rules fired on this run without querying rule by rule, so nothing is asserted here beyond the one that failed. And if the migration changed clearing member alongside CCP, that pairing is worth checking by hand.

Gentek

In time, with nothing to spare. The event is dated 2026-04-02, Maundy Thursday, and the reporting timestamp is 2026-04-07T10:00:00Z. The deadline is the event date plus one working day, counted on the TARGET2 (ECB) closing-days calendar, which the response names rather than assumes.

• Good Friday 2026-04-03 and Easter Monday 2026-04-06 are closing days, and the weekend sits between them, so the first working day after the event is Tuesday 2026-04-07 — the report lands on the deadline day itself.
• The calendar is resolved live from the holidays library at examination time, and every resolution is logged with the library version, the calendar, the year span and a fingerprint of the exact dates used, so a finding issued today can be reconstructed later.
• Why it is a Gentek check rather than a rulebook rule: the DRR rulebook states no timeliness rule at all, and its own business-day arithmetic ignores public holidays, so weekend-only counting would have put the deadline at Friday 2026-04-03.
• One note unrelated to timing: ISIN DE0001102309 does not resolve in FIRDS, which leaves the CFI and venue checks unrun.

Gentek

Late, and said plainly. The same trade a fortnight on: event 2026-04-16, reported 2026-04-21T10:00:00Z. Nothing intervenes this time — Friday 2026-04-17 is an ordinary working day on the same calendar, so that was the deadline, and the report is two working days past it. GENTEK-CAL-01 gives the event date, the deadline, the calendar it counted on and the timestamp, in one line.

• The obligation restated is EMIR Article 9(1) and its onshored UK equivalent: no later than the working day following conclusion, modification or termination.
• The DRR rulebook itself returns VALID on this file. The lateness surfaces only because the Gentek check sits outside the rulebook, and it never changes the rulebook verdict beside it.
• Both reports were filed five calendar days after the event, at 10:00 on a Tuesday. The difference is entirely which public holidays fell in between: calendar-day arithmetic would have passed both, and weekend-only counting would have failed both.

Gentek

The regime is explicit — UK and EU SFTR share identical ISO 20022 messages and the document never names its jurisdiction, so it is passed rather than guessed. Under UK SFTR: INVALID, on one rule.

• GENTEK-SFTR-UK-2.85 — field 2.85, Currency of collateral nominal amount, reads XAU: the ISO 4217 code for a troy ounce of gold, not a currency. The FCA excludes the precious-metal and special codes, and the finding quotes the compiled pattern (?!XAG|XAU|XBA|XBB|XBC|XBD|XEU|XFU|XPD|XPT|XXX)[A-Z]{3} beside the official text and the workbook cell it came from.
• The correct value is GBP, on three independent grounds: FIRDS lists the collateral ISIN GB00BQC82D08 in GBP; the market value in the same block already reads GBP; and the nominal at the reported unit price reproduces both that market value and the value-date principal. A currency tag mistyped on the nominal leg, not a mis-booked trade.
• Nothing else in the collateral block fails. CFI DBFTFR matches a fixed-rate gilt; collateral type, quality, maturity and issuer LEI all hold; the schema passes under the FCA usage guideline.

The gaps are named rather than buried: the two counterparty LEIs do not resolve in GLEIF, so their standing checks stay unverified, and the obligations that need the repository's own records — UTI uniqueness, the reporting timestamp against the receipt — are disclosed as not evaluated rather than quietly passed.

Gentek

Nothing fails. ESMA's text for 2.85 restates the ISO 4217 currency format and stops there, so it compiles to no rule of its own — and XAU is on the official ISO 4217 list, sitting in the precious-metals block beside XAG, XPD and XPT. A rulebook that says "official list only" and stops there admits it; only the FCA's added exclusion catches it. Both publications and their vintages are named on the response, so the split is documented rather than mysterious.

• A second divergence in the same field. For a new repo at trade level the FCA marks 2.85 conditionally mandatory; ESMA marks it optional.
• The data is still wrong. Under EU SFTR it does not bounce at the gate — it lands in the repository and resurfaces later as a data-quality or reconciliation problem, the more expensive way to find it. The GBP fix is correct for both regimes, so there is no reason to hold two versions of the file.

Gentek

2.85 was one instance of a policy, not a one-off. Both rulebooks are compiled end to end — 155 fields across all three report types, identical field numbering, no orphans on either side — so this covers Transaction, Margin and Reuse, not the transaction report alone.

• The FCA's own exclusion list is inconsistent between its own sheets. The Transaction sheet bars eleven special currency codes — XAG, XAU, XBA, XBB, XBC, XBD, XEU, XFU, XPD, XPT, XXX. The Margin and Reuse sheets bar those eleven plus XDR, the IMF Special Drawing Right. The extra code is carried into executable logic on both sides, not just the prose, so XDR is rejectable on a UK margin or reuse report and acceptable on a UK transaction report. That is an FCA-internal defect rather than a UK/EU divergence — and a single scrubbing list for all three reports gets it wrong in one direction or the other.
• The special-currency ban itself is FCA-only, on all seventeen currency fields. Transaction 2.34, 2.39, 2.48, 2.50, 2.70, 2.77, 2.85 and 2.86; Margin 3.9, 3.11, 3.13, 3.15, 3.17 and 3.19; Reuse 4.10, 4.14 and 4.17. ESMA states no special-currency prohibition anywhere in the rulebook — not on any of the seventeen, in any of the three reports. On the EU side they compile to nothing beyond the plain currency format; on the UK side each carries a dedicated sub-rule with no EU counterpart. The XAU rejection above was one of seventeen places this can bite.
• The requirement matrix diverges on the transaction report only. 2.85 and 2.86 are conditionally mandatory in the UK and optional in the EU on every cell where they are reportable; 2.50 the same, on buy-sell-backs and securities lending at both levels; 2.80, 2.81 and 2.82 are conditionally mandatory in the UK for a securities-lending position component at trade level, where the EU marks them not applicable; and 2.99 is mandatory in the UK for margin lending, where the EU again marks it not applicable. Margin and Reuse carry no matrix divergence at all.
• Two more FCA-only obligations, both on the transaction sheet. Where counterparty side is GIVE on a new, modified or corrected report, the FCA requires a negative sign on 2.76, 2.83 and 2.88 and ESMA states nothing equivalent; it is machine-enforced on 2.76 and 2.88, while on 2.83 the message may carry the value in a quantity shape with no sign element at all, so that limb is declared unenforceable rather than reported as a clean pass. And on 2.54 and 2.93, the issuer's LEI, the FCA trigger reads "an EEA country or the UK" and compiles to a country list including GB, where ESMA's is the same list without it.
• "Entity responsible for the report" diverges identically on all three sheets. Fields 1.10, 3.5 and 4.5 are one field in three reports, and the same two splits repeat in each. ESMA's description opens with a population case the FCA omits — a financial counterparty reporting on behalf of the other counterparty under Article 4(3) — where the FCA text starts at the management-company limb. And the FCA extends the Lapsed/Retired LEI relaxation to action types ETRM and ERROR, where ESMA writes EROR: ERROR is not a valid SFTR action-type code, and on the Margin and Reuse sheets ETRM is not a valid action type either, so read literally the FCA relaxation attaches to nothing on those two sheets. Behaviour is unaffected — matrix, format and encoded check are identical, and both regimes delegate to the same LEI check.
• A second FCA labelling defect, this one across the whole Reuse sheet. Its fourth action-type column is headed MARU, the Margin code, on all eighteen field rows, where ESMA's reads REUU. At field 4.18 the FCA marks that column mandatory while the same row's own permitted values read NEWT, REUU, EROR, CORR — the column header names an action type the sheet's own enum rejects. No obligation changes, and we canonicalise it, so no UK Reuse rule mentions MARU; but a vendor mapping the FCA matrix by column header would build a MARU branch that auth.071 never accepts.
• What is clean. Set the currency exclusions aside and Margin and Reuse diverge nowhere: all 20 margin fields and all 18 reuse fields carry identical requirements across every action type, identical formats and lengths, and identical error-code numbering — SFM-nnn and SFR-nnn, the same numbers on both sides, only the regulator's prefix differing. Every matrix split in the entire comparison sits on the transaction sheet.

Gentek

2.85 now reads GBP, and no rule fails under UK SFTR — the same file shape that just bounced holds. Two regime-specific points come with it.

• A UK-only requirement is already satisfied. Because the collateral issuer's jurisdiction (2.92) is GB, the FCA's UK limb on 2.93 fires and calls for the issuer LEI. It is populated with ECTRVYYCEF89VWYS6K36, HM Treasury. The EU limb would not ask for it at all.
• The sign convention does not fire. Counterparty side (1.9) is TAKE, so the FCA's negative-sign requirement does not apply and the positive signs on nominal and market value are right. On the mirror GIVE-side report, 2.83 and 2.88 would need negative signs — and 2.88 is machine-enforced in the UK, where ESMA states no sign convention at all.

Two things the rulebook cannot catch are still flagged. The dates are in the future — the reporting timestamp is 2028 — and FCA field 1.1 requires that timestamp to be no later than the trade repository's receipt of the report; that check needs the repository's own records, so it is disclosed as not evaluated, but a live repository will bounce this. And the economics do not reconcile: Actual/360 on the reported principal at 3.85% over the 31-day term gives 24,706,638.72 at maturity against 24,703,000 reported, an implied 3.678%; while a 2% haircut is reported against collateral whose market value exactly equals the cash principal, which is 100% coverage. SFTR has no rule forcing either to reconcile, so no repository will reject them — they surface in data-quality review, or as a pairing break against the counterparty's own report.

Gentek

Nothing did fail. The schema holds, every format holds, and every requirement-matrix cell and encoded rule that ran, held. NOT EVALUATED is the verdict for exactly that state: no failures among the checks that could run, and a named list of the ones that could not. VALID is reserved for a file where every applicable check actually ran, so it is never used to imply coverage that was not there.

Each unevaluated check is disclosed with its official text and its reason:

• Obligations the FCA wrote against the trade repository's own records — GENTEK-SFTR-UK-1.1 on the reporting timestamp, GENTEK-SFTR-UK-2.98 on which action type the first report for a UTI may carry. One submitted message carries none of that history.
• Obligations that need reference data no message carries: the LEI registration standing and legal-address country behind fields 1.2, 1.3, 1.10, 1.11, 1.12, 1.17, 2.54 and 2.93, covered by GENTEK-LEI-01. The batch's LEIs are synthetic and did not resolve in GLEIF, so the check is reported as unverified rather than assumed either way.
• Official texts only partly machine-encodable, each named with the residue it leaves — GENTEK-SFTR-UK-2.14 on the maturity date, 2.42 and 2.79 on the CFI character carrying asset class, 2.75 on date arithmetic between the event and value dates, 2.83 on a sign convention the message's own XML shape cannot record. The encoded limb of each one ran and held; the residue is stated rather than folded into a clean pass.
• Records that do not state a requirement-matrix axis. The valuation update states neither its SFT type nor its reporting level, and the collateral update states its type but not its level, so each is measured under every candidate assignment the matrix allows instead of one guessed at.

Reference data resolved alongside: GB00BH4HKS39 to Vodafone Group Plc, DE0001102309 to no FIRDS record.

Gentek

Field 2.14 is the maturity (end) date, FCA error code SFT-027. One call returns the complete official text, the workbook cell it was compiled from, the axes it applies to, the encoded logic that runs — and the clause that does not. The text carries four obligations, compiled into three rules:

• GENTEK-SFTR-UK-2.14 — for a repo or a securities loan reported as fixed term (field 2.21 is false), the maturity date must be populated.
• GENTEK-SFTR-UK-2.14.2 — when populated, the maturity date must be on or after the value date, field 2.13.
• GENTEK-SFTR-UK-2.14.3 — for a repo reported as open term (2.21 is true), the maturity date must be blank.

Not checked by this rule: the MODI/CORR clause forbidding a change to a value already reported when the event date (2.3) is earlier than one working day before the day of reporting (1.1). That compares against the trade's previously reported state, which the one message in front of the engine cannot carry. It is disclosed on the file above, against the new-trade record, so the limit is visible before the same UTI returns as a modification.

Gentek

Each routes by its own namespace to its own report type, requirement matrix and error-code series: auth.070 to the Margin report, action type MARU, codes SFM-nnn; auth.071 to the Reuse report, action type REUU, codes SFR-nnn. The reuse report's three collateral components are each validated in their own right, not as one aggregate.

Both read NOT EVALUATED, and for the same two reasons as the transaction batch: the reporting-timestamp and action-type texts that need repository history (3.1 and 3.20, 4.1 and 4.18), and the counterparty LEIs that did not resolve in GLEIF (3.3–3.6, 4.3–4.5). Across all three files nothing in the data failed a rule.

Gentek

Then the verdict is INVALID, and the defect is named.

• The margin copy carries ZZZ as the currency of the initial margin posted. It satisfies the schema's own three-letter pattern, so it clears schema validation, and fails at the format layer: field 3.9, 'ZZZ' is not an active ISO 4217 currency code, measured against the pinned ISO 4217 list.
• The transaction batch carries an element the FCA usage-guideline schema does not define. Schema validation fails at the input's own line number: line 32: NotARealElement: unexpected here; expected TradData. Everything downstream still ran against what could be read and found nothing further, and the verdict stays INVALID — a clean rulebook pass does not paper over a broken schema.

Three outcomes, kept apart: VALID means nothing failed and nothing was left unchecked; NOT EVALUATED means nothing failed but some applicable check could not run, each one named; INVALID means a defect was found. "Nothing failed" and "everything was checked" are never the same claim.

Gentek

INVALID, and one identifier is mangled: Counterparty 2. The value ANGGYXNX0JLX3X63JN99, reported in field 1.9 under OthrCtrPty, has valid ISO 17442 structure but fails the ISO 7064 MOD 97-10 checksum that standard specifies.

• Running the string through mod 97 gives 14. A valid LEI gives 1.
• Recomputing the check digits over the first 18 characters gives 86, so the intended value is almost certainly ANGGYXNX0JLX3X63JN86 — the last two digits were overtyped.
• The finding is GENTEK-LEI-05, which checks every LEI-shaped identifier locally and runs even when GLEIF is unavailable. It is the one supplemental Gentek check allowed to drive the rulebook verdict, because a failed checksum is a malformed input rather than a reference-data opinion.

Nothing else in the file broke. The ISO 20022 schema (auth.030.001.03_ESMAUG_DATTAR_1.1.0.xsd) passed, no field format failed, and no other Gentek check raised anything. The other four LEIs in the file all satisfy their check digits and resolved in GLEIF. One aside that failed nothing: the product ISIN DE0001102309 resolves in neither EU nor UK FIRDS.

Gentek

Nothing, deliberately. The value as written, ANGGYXNX0JLX3X63JN99, belongs to nobody: an identifier that has just failed its own check digits is excluded from lookup entirely, so there is no record to return. Naming an entity under a checksum failure would assert that a string just rejected belongs to a real, registered company.

The corrected form is a different matter. ANGGYXNX0JLX3X63JN86 is CREDIT SUISSE AG — entity status INACTIVE, registration status RETIRED, mergers & acquisitions completed effective 31 May 2024, with no successor LEI recorded, as GLEIF held it when this file was run.

That is a second and separate problem. The trade was executed on 7 August 2026, two years after the entity ceased to exist, so a Counterparty 2 pointing at a retired registration would fail on its own account even once the checksum is fixed. Patching 99 to 86 and resubmitting settles the typo and leaves the real defect in place.

• Was the counterparty genuinely the old Credit Suisse entity? If so, the trade date and the LEI cannot both be right.
• Or is it the surviving UBS entity? GLEIF shows UBS AG as BFM8T61CT2L1QCEMIK50, ACTIVE and ISSUED — the LEI a live 2026 EMIR report would normally carry.

Other reports from the same feed are worth a look for the same retired LEI. A mangled checksum is a one-off typo; a stale entity mapping tends to be systematic.

Gentek

No — it is a MiFIR transaction report, and the response says so by name. The root namespace is auth.016.001.01, the RTS 22 transaction reporting message, and the root element FinInstrmRptgTxRpt spells out the same thing. SFTR is a different message family altogether: auth.052, auth.070, auth.071.

The file is named rather than answered with a generic list of namespaces the tool does not recognise, so the reply tells you what you actually sent, not merely that it was refused. It is not examined here — the MiFIR rulebooks are searchable field by field through the MiFIR rule search, but no document is measured against them. This one looks misfiled.

Gentek

The direction is the other way round. A trade state report is produced by a trade repository and sent to authorities and counterparties: it reports the repository's current state for SFTs submitted earlier, rather than being a submission of yours. The file's own header carries the repository as sender and your entity as recipient.

The verdict is NOT VALIDATED, and the reply explains why rather than leaving a gap. Neither the FCA UK SFTR nor the ESMA EU SFTR rulebook holds a requirement matrix, format table or conditional rule an auth.079 document could be measured against — both define obligations for counterparty submissions only. It is recognised from its namespace alone, which makes it the one SFT document the automatic regime resolves by itself, with no UK or EU choice to make.

What is left is a human read of the content, and the response counts it for you: two state records under TradData. Both carry an unreconciled collateral leg, and one an unreconciled loan leg as well — which is the case for reviewing these on the way in, not on the way out.

Gentek

Not this file: no rulebook holds it. The families that are examined are stated plainly, and the reply lists them beside the refusal so the answer is never just "no".

• Derivatives reports — ISO 20022 auth.030 DerivativesTradeReport and auth.108 MarginReport, and DTCC RDS harmonised submissions, against the ISDA DRR rules.
• SFT reports — auth.052 transactions, auth.070 margin, auth.071 collateral reuse, bare or BizData-wrapped, against the FCA UK SFTR or ESMA EU SFTR rulebook. The regime is named explicitly, because the two use identical messages and a document never identifies its own jurisdiction.
• Trade state reports — auth.079 is recognised and explained, never validated.

On a submission that is examined, a failure cites the official rule id and the regulator's own error code, and the LEIs and ISINs are resolved against GLEIF and FIRDS. Anything outside those families is named for what it is rather than forced through a rulebook it does not belong to.

Gentek

INVALID under CFTC Part 45. This is a DTCC RDS submission — the harmonised format that can carry several jurisdictions at once — so it does not identify whose rulebook applies, and the regime is named in the question rather than guessed. Two Part 45 rules fail, each cited with its official id, its requirement text and the values it read. The DTCC schema passed, and so did every field format checked.

• EventIdentifierCondition (data element 29) — an event identifier is only permitted where the event type is COMP or CREV. This trade reports event type TRAD and an event identifier of SEF123, so the value does not belong on a new-trade submission.
• PlatformIdentifierCondition (data element 98) — a platform identifier is required where Cleared is N or I. This trade is uncleared and reports no platform identifier.

The Gentek checks sit beside that verdict and do not change it. Counterparty 1's LEI comes back from GLEIF with registration status DUPLICATE, outside the set the rulebook accepts (Issued, Lapsed, Pending transfer, Pending archival). Counterparty 2's is Lapsed, which is accepted, so it carries a warning only. The reporting-deadline check is scoped to EU and UK EMIR, so it did not run here — and the response says so rather than leaving it to be assumed.

Gentek

Same format, different rulebook, different failures. Under CSA the file is INVALID on four rules. The event identifier problem recurs, cited now by a CSA rule id rather than the CFTC one, and three obligations the Part 45 rulebook does not carry fail alongside it.

• CSA_VR_0097_01 (data element 97) — the event identifier is populated while the event type is TRAD.
• CSA_VR_0022_01 (data element 22) — a platform identifier is required where Cleared is N or I, and none is reported.
• DTCC_CSA_VR_0020_01 (data element 20) — an inter-affiliate indicator is required where the SEF or DCM anonymous execution indicator is False or blank. The file reports False, and the indicator appears nowhere in it.
• CSA_VR_0128_01 (data element 128) — an underlier ID (other) is required where the underlying is not identified by an ISIN. Leg 2 names USD-LIBOR-BBA as its floating rate index, and neither leg carries an underlier ID.

Three LEIs are read here rather than two, because this submission adds a broker — whose LEI is Lapsed. Counterparty 1's DUPLICATE registration status carries over from the CFTC filing. Outside the rulebook, both counterparties report a local counterparty jurisdiction of NON-CA, which is the field a regulator reads to confirm that CSA applies at all.

Gentek

INVALID, and one item of the three is unambiguous. This file is ISO 20022 and names its own rulebook: the regime comes from the document's own usage-guideline declaration, so no regime parameter is needed. Schema validation passed, and so did every field format checked.

• GENTEK-LEI-05 — the central counterparty LEI JGH3RQQ37UX3UC0PM937 fails the ISO 7064 MOD 97-10 check digits that ISO 17442 specifies. That is a malformed code rather than a lookup result, which is why this single check is cited by the rulebook verdict where the rest never move it. The rejected LEI is not then resolved against GLEIF: nothing is asserted about an entity a check has just rejected. The other LEIs in the message resolved cleanly.
• DTCC_JFSA_BR_0100_01 and DTCC_JFSA_BR_0100_02 — the notional quantity schedule condition, once per leg. The trade is an interest-rate option, the file's own template comments mark the notional quantity block as not applicable for interest-rate products, and notional is reported as an amount instead. One for whoever maintains the JFSA rule mappings to confirm, ahead of any change to the trade.

Two further observations, neither of which any rule fires on. The underlying ISIN was not found in FIRDS, which covers EU and UK instruments — unremarkable for an Australian-issued security, but it means the CFI-versus-asset-class check is reported as not run rather than passed. And the crypto-asset indicator is set to true on an interest-rate option, while the dates do not line up: execution is timestamped 2001, the effective date is 2022, and settlement falls in 2072, after the 2062 expiration date.

Gentek

The rule catalogue answers from the same library the examinations run against: nine derivatives regimes on the ISDA DRR 7.6.0 model, the report types each one carries, and the rule count per report. Narrowed to a single regime, it also gives the split by how each rule is evaluated — direct, reference data, model function or placeholder — with the number of fields format-checked.

• On a trade report: EU EMIR 403 rules and UK EMIR 411; CSA 204; ASIC 169; CFTC Part 45 157; JFSA 150; MAS 147; SEC 133; HKMA 82.
• Those are catalogue sizes, not what fires on any one submission. Each of the three trades above ran a subset of its regime's catalogue, and every examination states which rules did not run and why: fields the message format does not carry, UPI reference data no submission carries, repeated structures the record did not populate.
• EU and UK EMIR are the largest by a distance, mostly through rules that delegate to ISDA DRR model functions this engine does not implement. Those produce no pass or fail, so the actionable count is the direct and reference-data rules rather than the headline figure.
• ASIC and MAS lean on reference-data rules, which resolve through GLEIF and register lookups — only as good as the identifiers in the submission, and reported as not evaluated when a lookup cannot be made. CFTC, CSA, JFSA and SEC are mostly direct rules over the submitted values.

Gentek

Supported directly. The trade report field takes ISO 20022 XML, DTCC RDS XML, or a base64-encoded gzip of either. Detection is not a guess: the payload is treated as compressed only when the decoded bytes begin with the gzip magic number 1f 8b, so plain XML travels unchanged and no other input is mistaken for a compressed document.

The attached emir-batch-gzipped-base64.txt is the base64 of emir-batch-gzipped.xml.gz, which unpacks to a 604-line auth.030.001.03 EMIR batch of 30,289 bytes carrying two records. Sent compressed, it came back INVALID — the schema and the format layer both rejected GENTEKUTIEMIRAUGXXBATCH0000000000000000002 against the required UTI pattern — and that response is byte-for-byte the response the same document produces when sent as plain XML.

Four things in the reply let a desk confirm which bytes were read:

• gzip's own CRC32 and DEFLATE structure must verify in full, and decompression must reach a valid end-of-stream marker, before a single element is parsed.
• The regime resolved to ESMA EMIR from the document's own xsi:schemaLocation, and the reply says that is where it came from.
• Every record is listed by its UTI with its action type, so a finding resolves to a trade in the submitted file rather than to a position in a batch.
• The envelope declared NbRcrds=0 while actually carrying two records, and the reply notes the discrepancy rather than adopting either number.

Gentek

It refuses, and it says where. This file differs from the good payload by one character — position 201, an l written as an A. Base64 decodes it quite happily, because base64 validates an alphabet rather than content. The checksum underneath does not.

The reply reads: the payload is corrupt, a character-level error exists in it, roughly 6% through the 2,158 compressed bytes that arrived. No verdict is issued, no partial document is parsed, and there is no silent fallback to whatever the damaged stream decoded to.

Three failures are told apart, each named for what actually went wrong:

• Corrupt — the checksum fails, and the reply localises how far decompression reached before it broke.
• Truncated — a payload cut off in transport is named as truncated and states how many compressed bytes did arrive, which can be compared against the source file's own size.
• Decodes, but is not the document — valid base64 carrying no gzip stream is refused outright, naming the absent magic number, rather than being read as whatever it happened to decode to.

Packaging that carries no content of its own is repaired instead of refused, since none of it alters a byte of the document: markdown code fences, a data: URI prefix, line wrapping, missing = padding, the URL-safe alphabet, and invisible unicode. All six repair to the identical examination, and the checksum still guards the payload itself, unchanged.

Gentek

Five million bytes for the document itself. A submission above 5,000,000 UTF-8 bytes is refused, and the refusal states both the measured size and the limit rather than truncating the file and examining the part that fitted. One submission may carry many trade reports up to that ceiling.

Compression buys no extra room. A gzip payload's decompressed size is held to the same 5,000,000-byte ceiling, so a compressed call cannot smuggle in a larger document than an uncompressed one — it only makes the same document cheaper to move and safer to transcribe.

Decompression is bounded as output is produced rather than measured once it is finished, so a small payload crafted to expand to something enormous is stopped at the bound instead of being materialised in full.

On this batch, 30,289 bytes of XML compressed to 2,158 bytes and travelled as 2,880 base64 characters, roughly ten times smaller on the wire than the raw document. A production batch, with varied rather than repeated values, will compress less well than a sample like this one.