Enrich and reconcile S.06.02 asset data

Who can perform the task

Administrators and preparers can enrich an editable S.06.02 form. Locked or in-review filings cannot be changed.

Before you begin

Keep the customer-controlled security master and its approved mapping. Use checksum-valid identifiers in the filing. GLEIF enrichment accepts an exact LEI or an ISIN covered by GLEIF's ISIN-to-LEI mapping; ECB currency evidence requires a three-letter quote currency and the required conversion date.

Quick path

1. Open the S.06.02 asset-enrichment workspace for the filing.
2. Select the approved public or organization reference source.
3. Review exact and suggested matches together with source dates and confidence.
4. Resolve ambiguous, stale, or conflicting records with human confirmation.
5. Apply the approved changes and reconcile the resulting values and evidence.

Detailed guidance

1. Open S.06.02 and find S.06.02 asset enrichment. The filing-wide queue appears above the active table whenever the filing contains an eligible checksum-valid LEI or ISIN, retained evidence, or an unresolved retrieval.
2. Review the filing-local evidence coverage, eligible ISIN/LEI row counts, conflict rows, and non-current LEI count. These metrics describe retained evidence in this filing; they do not claim that GLEIF or the portfolio is complete.
3. To reconcile a customer security master:
   1. Choose a reusable mapping whose purpose is security_master.
   2. Choose the CSV or XLSX security-master file.
   3. Select Import security master.
   4. Review the retained filename, record count, and SHA-256 checksum.
4. To retain currency-conversion evidence:
   1. Enter the ECB quote currency and required date.
   2. Select Retrieve ECB evidence.
   3. Inspect the selected observation date, rate, series, source URL, payload, checksum, ECB source acknowledgement, and linked reuse terms. A weekend or holiday can use the latest observation from the preceding ten days.
5. To reconcile a BIC:
   1. Enter the exact 11-character BIC on the intended row.
   2. Select Find and retain LEI.
   3. Review the suggested LEI, mapping publication, checksum, and complete month-specific SWIFT/GLEIF notice.
   4. Use the LEI only when the BIC belongs to the intended legal entity. The mapping evidence is retained with the form but does not silently replace a filing value.
6. To retrieve all eligible filing evidence together, select Refresh from GLEIF (n) in the filing-wide queue. Identical identifiers are requested once, source calls are bounded, and exact results are retained for every eligible row. Rate limits, missing records, ambiguity, and unavailable sources remain explicit queue results and do not change a filing value.
7. Alternatively, for a checksum-valid LEI row, select Enrich from GLEIF or Refresh from GLEIF. For a checksum-valid ISIN row, select Find issuer LEI and enrich. When an administrator has activated a daily ISIN mapping, the exact lookup uses that checksum-pinned publication; otherwise it uses the exact GLEIF API filter. Review the retained lookup evidence before relying on the mapped issuer.
8. Review the filing-wide groups for exact suggestions, already verified fields, conflicts, missing coverage, stale evidence, ambiguous results, unavailable sources, rate limits, and rejected suggestions. Compare each existing and suggested field, its state, confidence, reason, observation time, and exact target cell. The panel labels, review states, and explanations follow your selected interface language. Identifiers, authority names, observed status values, source URLs, checksums, and retained payloads remain exactly as supplied so they can be verified against the source.
9. Inspect the exact retained GLEIF source records, GLEIF attribution, and linked CC0 reuse terms. When the LEI record supplies a registration-authority code, review the official authority name, jurisdiction, website, and local entity identifier. An activated Registration Authorities List supplies the authority details and retained publication checksum; the live authority API remains the fallback when the active list has no matching code.
10. If the panel warns that the entity or LEI registration is not current, inspect the exact entity and registration status supplied by GLEIF.
11. Select only exact, semantically mapped suggestions, then select Accept (n) once. The complete selection is refused if any form revision, target value, retained source checksum, or suggestion changed after review. Conflicts, ambiguous matches, stale evidence, calculated targets, and suggestions without an exact target cannot enter the batch.
12. Accept or reject each proposed field explicitly when reviewing one field at a time. Do not accept a value when the target column is not semantically exact or the evidence does not support the filing decision.
13. Re-run validation and reconcile the changed values with the original source.
14. Select Download registry evidence to retain a checksummed JSON summary of filing-wide enrichment coverage, source versions, conflicts, stale fields, decisions, and unresolved fields. The report deliberately excludes filing values, identifiers, row keys, user identities, and raw source payloads.

Expected result

Accepted values are applied only to exact mapped targets. Rejected, conflicting, verified, and missing fields remain visible with their decision and provenance. The customer security master and external evidence remain checksum identifiable.

How to verify

For every accepted value, open its source record and confirm the URL, observed time, checksum, attribution, reason, and target cell. Compare the filing value with the security-master reconciliation and re-run validation. Download the registry evidence report and compare its response checksum header with the checksum inside the report.

Common problems

• Choose mapping is empty until an organization mapping with purpose security_master exists.
• GLEIF requires an LEI means the row does not contain a checksum-valid LEI.
• A missing ISIN mapping does not make the ISIN invalid. GLEIF states that the mapping has incomplete NNA and legacy-ISIN coverage.
• Multiple issuer LEIs for one ISIN remain unresolved; the application does not invent a canonical issuer.
• A missing BIC match does not mean the BIC or entity is invalid. The monthly mapping contains current mapped pairs and omits unmapped and historical pairs.
• An ambiguous BIC match is not suggested; resolve the legal entity manually.
• A conflict is a review state, not permission to overwrite the filing.
• A suggestion without an exact target cell cannot be accepted.
• A non-current LEI warning is not an automatic rejection. Verify the legal entity, renewal or successor record, and intended reporting use.
• ECB rates are quote-currency units per EUR; do not invert or re-date them without an approved calculation basis.
• The registry evidence report summarizes retained evidence. It does not prove that an external source was complete or record transient source outages that were not retained with the filing.

Audit and data consequences

Importing a security master retains its identity but does not automatically accept every proposed filing value. Each single-field enrichment decision records its actor, time, before/after context, source, and outcome. A batch records one attributable decision plus per-target cell, snapshot, field, and source-checksum provenance; ordinary audit metadata excludes filing values and raw source payloads.

Product and regulatory limitations

Reference data assists reconciliation; it does not determine asset classification, reporting applicability, or regulatory correctness. Open-data coverage varies, and licensed-provider enrichment is not implied. Always refer to SWIFT for the latest BIC information and preserve the displayed mapping notice with any copied mapping data.