From 11bd37698c2df5e3b3105c5383474b9204a18d6b Mon Sep 17 00:00:00 2001 From: kor Date: Wed, 10 Jul 2024 20:28:14 +0200 Subject: [PATCH] =?UTF-8?q?Search=20and=20scraping=20functionality,=20?= =?UTF-8?q?=E2=80=9Cforked=E2=80=9D=20(copied)=20from=20WOT-terms?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .env.example | 40 + .github/workflows/deploy-to-gh-pages.yml | 28 + .gitignore | 33 + index.html | 22 + indexed-in-KERISSE.html | 18 + package-lock.json | 5145 +++++++++++++++++ package.json | 26 + paths.js | 7 + search-index-typesense/backup.sh | 94 + search-index-typesense/collectScrapedUrls.mjs | 77 + .../README.md | 7 + .../gleifPDF.jsonl | 2417 ++++++++ .../handmade.json | 158 + .../config-sitemaps-exlude-urls/README.md | 14 + .../gleifExcludeUrls.json | 6 + .../wotTermsExcludeUrls.json | 25 + .../config/config-sitemaps-manual/README.md | 7 + .../sitemap-www.gleif.org-pdf.xml | 447 ++ .../slack-keri-archive.xml | 69 + .../config/configOverrides.json | 72 + .../config/configScraperGenericSitemaps.mjs | 416 ++ .../config/config_sitemaps_create.sh | 77 + search-index-typesense/copy_manual_files.sh | 39 + .../countLinesInJsonlFiles.mjs | 61 + .../createHtmlFileWithAllImages.mjs | 56 + .../createSitemapGithub.mjs | 75 + search-index-typesense/extractData-test.mjs | 14 + search-index-typesense/extractData.mjs | 14 + search-index-typesense/extractDataPrio1.mjs | 8 + search-index-typesense/findAllImgs.mjs | 117 + search-index-typesense/import.sh | 104 + search-index-typesense/isLibraryInstalled.mjs | 83 + search-index-typesense/logger.sh | 61 + search-index-typesense/main.sh | 183 + .../make_collection_empty.sh | 30 + .../modules/appendToFile.mjs | 29 + .../modules/createInput.mjs | 109 + .../modules/createOrEmptyFile.mjs | 17 + .../modules/createOutput.mjs | 44 + .../modules/extractMainContent.mjs | 150 + .../modules/general-pdf.mjs | 203 + .../modules/getImageMetaData.mjs | 35 + .../modules/getTextContent.mjs | 17 + search-index-typesense/modules/github-API.mjs | 40 + search-index-typesense/modules/github-pdf.mjs | 166 + search-index-typesense/modules/logger.mjs | 45 + search-index-typesense/modules/scrape.mjs | 172 + .../modules/writeToFile.mjs | 21 + search-index-typesense/overrides.sh | 168 + .../overrides/sortAdjustment.js | 8 + .../prepareScraperGithub.mjs | 46 + ...raperSingleUrlsFromWotTermsGoogleSheet.mjs | 124 + search-index-typesense/prepare_file_system.sh | 50 + .../removeURLsFromSitemap.mjs | 215 + .../renameFilesToLowerCase.mjs | 47 + search-index-typesense/restore.sh | 50 + search-index-typesense/scrape_start.sh | 112 + .../sortAndStyleScrapedIndex.mjs | 95 + search-index-typesense/splitContentJSONL.mjs | 121 + src/custom.css | 903 +++ src/typesenseInstantSearch.js | 559 ++ src/typesenseInstantSearchInit.js | 180 + webpack.config.js | 44 + 63 files changed, 13820 insertions(+) create mode 100644 .env.example create mode 100644 .github/workflows/deploy-to-gh-pages.yml create mode 100644 .gitignore create mode 100644 index.html create mode 100644 indexed-in-KERISSE.html create mode 100644 package-lock.json create mode 100644 package.json create mode 100644 paths.js create mode 100644 search-index-typesense/backup.sh create mode 100644 search-index-typesense/collectScrapedUrls.mjs create mode 100644 search-index-typesense/config/config-search-index-entries-manual/README.md create mode 100644 search-index-typesense/config/config-search-index-entries-manual/gleifPDF.jsonl create mode 100644 search-index-typesense/config/config-search-index-entries-manual/handmade.json create mode 100644 search-index-typesense/config/config-sitemaps-exlude-urls/README.md create mode 100644 search-index-typesense/config/config-sitemaps-exlude-urls/gleifExcludeUrls.json create mode 100644 search-index-typesense/config/config-sitemaps-exlude-urls/wotTermsExcludeUrls.json create mode 100644 search-index-typesense/config/config-sitemaps-manual/README.md create mode 100644 search-index-typesense/config/config-sitemaps-manual/sitemap-www.gleif.org-pdf.xml create mode 100644 search-index-typesense/config/config-sitemaps-manual/slack-keri-archive.xml create mode 100644 search-index-typesense/config/configOverrides.json create mode 100644 search-index-typesense/config/configScraperGenericSitemaps.mjs create mode 100644 search-index-typesense/config/config_sitemaps_create.sh create mode 100644 search-index-typesense/copy_manual_files.sh create mode 100644 search-index-typesense/countLinesInJsonlFiles.mjs create mode 100644 search-index-typesense/createHtmlFileWithAllImages.mjs create mode 100644 search-index-typesense/createSitemapGithub.mjs create mode 100644 search-index-typesense/extractData-test.mjs create mode 100644 search-index-typesense/extractData.mjs create mode 100644 search-index-typesense/extractDataPrio1.mjs create mode 100644 search-index-typesense/findAllImgs.mjs create mode 100644 search-index-typesense/import.sh create mode 100644 search-index-typesense/isLibraryInstalled.mjs create mode 100644 search-index-typesense/logger.sh create mode 100644 search-index-typesense/main.sh create mode 100644 search-index-typesense/make_collection_empty.sh create mode 100644 search-index-typesense/modules/appendToFile.mjs create mode 100644 search-index-typesense/modules/createInput.mjs create mode 100644 search-index-typesense/modules/createOrEmptyFile.mjs create mode 100644 search-index-typesense/modules/createOutput.mjs create mode 100644 search-index-typesense/modules/extractMainContent.mjs create mode 100644 search-index-typesense/modules/general-pdf.mjs create mode 100644 search-index-typesense/modules/getImageMetaData.mjs create mode 100644 search-index-typesense/modules/getTextContent.mjs create mode 100644 search-index-typesense/modules/github-API.mjs create mode 100644 search-index-typesense/modules/github-pdf.mjs create mode 100644 search-index-typesense/modules/logger.mjs create mode 100644 search-index-typesense/modules/scrape.mjs create mode 100644 search-index-typesense/modules/writeToFile.mjs create mode 100644 search-index-typesense/overrides.sh create mode 100644 search-index-typesense/overrides/sortAdjustment.js create mode 100644 search-index-typesense/prepareScraperGithub.mjs create mode 100644 search-index-typesense/prepareScraperSingleUrlsFromWotTermsGoogleSheet.mjs create mode 100644 search-index-typesense/prepare_file_system.sh create mode 100644 search-index-typesense/removeURLsFromSitemap.mjs create mode 100644 search-index-typesense/renameFilesToLowerCase.mjs create mode 100644 search-index-typesense/restore.sh create mode 100644 search-index-typesense/scrape_start.sh create mode 100644 search-index-typesense/sortAndStyleScrapedIndex.mjs create mode 100644 search-index-typesense/splitContentJSONL.mjs create mode 100644 src/custom.css create mode 100644 src/typesenseInstantSearch.js create mode 100644 src/typesenseInstantSearchInit.js create mode 100644 webpack.config.js diff --git a/.env.example b/.env.example new file mode 100644 index 0000000..e49cfa0 --- /dev/null +++ b/.env.example @@ -0,0 +1,40 @@ +######################################## +### SECRET ENVIRONMENT VARIABLES ### +######################################## + +# TYPESENSE +TYPESENSE_ADMIN_API_KEY="" +TYPESENSE_HOST="" +TYPESENSE_COLLECTION_NAME="" + +# GITHUB +GITHUB_AUTH_TOKEN="" +# for creating Github issues: +GITHUB_ISSUE_AUTH_TOKEN="" + + +# DOWNLOADS. Add a trailing slash. +# EXAMPLE FOR MACS: KERISSE_BACKUPS_DIR=$HOME/Downloads/ +KERISSE_BACKUPS_DIR="" + + +######################################## +### NON-SECRET ENVIRONMENT VARIABLES ### +######################################## + +# SEARCH INDEX DIRECTORY +SEARCH_INDEX_DIR="search-index-typesense" +SEARCH_INDEX_ENTRIES_DIR="search-index-entries" +SEARCH_INDEX_SITEMAPS_DIR="sitemaps" +SEARCH_INDEX_TEMP_DIR="search-index-typesense/temp" + +# SITEMAP OF INDEXED WEBSITES VIA FILE SYSTEM +INDEX_OVERVIEW_FILE="docs/02_overview/indexed-in-KERISSE.md" +# SITEMAP OF INDEXED WEBSITES VIA HTTP +INDEX_OVERVIEW_HTTP="/WOT-terms/docs/overview/indexed-in-KERISSE" + +# Typesense Restore dir +KERISSE_RESTORE_DIR="search-index-restore" + + + diff --git a/.github/workflows/deploy-to-gh-pages.yml b/.github/workflows/deploy-to-gh-pages.yml new file mode 100644 index 0000000..feb32ca --- /dev/null +++ b/.github/workflows/deploy-to-gh-pages.yml @@ -0,0 +1,28 @@ +name: Deploy to GitHub Pages + +on: + push: + branches: + - main # Set to your default branch + +jobs: + deploy: + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v2 + + - name: Setup Node + uses: actions/setup-node@v2 + with: + node-version: '21' # Set to your project's node version + + - name: Install and Build + run: | + npm install + npm run build + + - name: Deploy + uses: peaceiris/actions-gh-pages@v3 + with: + github_token: ${{ secrets.GITHUB_TOKEN }} + publish_dir: ./dist diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..f4947bc --- /dev/null +++ b/.gitignore @@ -0,0 +1,33 @@ +# Dependencies +/node_modules + +# Production +/dist + +# Generated files +.cache-loader + +# Misc +.env +.history +.DS_Store +.ds_store +.idea +.vscode/ +npm-debug.log* +yarn-debug.log* +yarn-error.log* + +# logs +search-index-typesense/search-index-entries/* +search-index-typesense/logs/* +search-index-typesense/sitemaps/* +search-index-typesense/overrides/overridesID.json +search-index-typesense/singleUrlsFromWotTermsGoogleSheet/* +.history +# media +# *.mp4 + +copy-to-testsite.sh +docusaurus.paths.*.js +restore.jsonl \ No newline at end of file diff --git a/index.html b/index.html new file mode 100644 index 0000000..0bcd75f --- /dev/null +++ b/index.html @@ -0,0 +1,22 @@ + + + + + + + + Kerisse search + + + + + + + + + + + + + + \ No newline at end of file diff --git a/indexed-in-KERISSE.html b/indexed-in-KERISSE.html new file mode 100644 index 0000000..27f2ffe --- /dev/null +++ b/indexed-in-KERISSE.html @@ -0,0 +1,18 @@ + + + + + + +Indexed in KERISSE | KERISSE.org + + + + + +
+

Indexed in KERISSE

Indexed at 02 April 2024 17:21:40

Number of indexed pages: 119

  1. https://www.gleif.org/about-lei/code-lists/gleif-accepted-legal-jurisdictions-code-list/gleif_acceptedjurisdictions_v1.4.pdf
  2. https://www.gleif.org/about-lei/code-lists/gleif-registration-authorities-list/2022-03-23_overview_changes_ra_list_v1.0_to_v1.7.pdf
  3. https://www.gleif.org/about-lei/code-lists/gleif-registration-authorities-list/2022-03-23_ra_list_v1.7.pdf
  4. https://www.gleif.org/about-lei/code-lists/iso-20275-entity-legal-forms-code-list/2021-10-21-elf-code-list-v1.4.1.pdf
  5. https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf
  6. https://www.gleif.org/about-lei/common-data-file-format/2022-02-22_cdf_questions_and_answers_v2.4.pdf
  7. https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf
  8. https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf
  9. https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf
  10. https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2021-09-30_guiding_document_for_the_transition_period_v1.1-final.pdf
  11. https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2021-09-30_xslt-documentation_v1.1-final.pdf
  12. https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2021-11-23_lei-cdf-3.1-and-rr-cdf-2.1-and-repex-cdf-2.1-samples-description_v1.2-final.pdf
  13. https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2022-02-09_upcoming-cdf-xml-comprehensive-example-description_v1.0-final.pdf
  14. https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/gleif-data-consumers-quick-guide.pdf
  15. https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_reporting-exceptions-format-v1-1.pdf
  16. https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf
  17. https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf
  18. https://www.gleif.org/about-lei/get-an-lei-find-lei-issuing-organizations/how_to_identify_your_new_lou_after_the_termination_of_business_entity_data_b_v.pdf
  19. https://www.gleif.org/about-lei/get-an-lei-find-lei-issuing-organizations/registration-agents/2023_03_28_registration-agents-governance-framework_1.0.pdf
  20. https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2016-02-01-ma-appendix-08-ancillary-duties_final.pdf
  21. https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2016-02-01-ma-appendix-11-swiss-data-protection-act_final.pdf
  22. https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2016-02-01-ma-appendix-13-individual-deviations-from-the-ma_final.pdf
  23. https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2017-09-01-ma-appendix-01-non-disclosure-agreement_final.pdf
  24. https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2017-09-01-ma-appendix-09a-terms-of-use-gleif_final.pdf
  25. https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2018-02-08_ma-appendix-05-lou-contract-requirements.pdf
  26. https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2020-06-01-ma-master-agreement-1.3-final.pdf
  27. https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2021-05-31-ma-appendix-02-accreditation-checklist_final.pdf
  28. https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2021-11-30_ma-appendix-07-payments_v1.4-final.pdf
  29. https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-03-31-ma-appendix-06-sla_2.1.pdf
  30. https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-05-11_ma-appendix-10-accreditation-verification_1.4final.pdf
  31. https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-6-30-ma-appendix-02-accreditation-manual.pdf
  32. https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2023-03-28-ma-appendix-14-third-party-services-v1.3.pdf
  33. https://www.gleif.org/about/gleif-engagement/gleif-stakeholder-groups/gleif-gifi-relationship-group/2018-11-05_gleif_gifi-relationship-group-charter_v1.pdf
  34. https://www.gleif.org/about/gleif-engagement/gleif-stakeholder-groups/gleif-vendor-relationship-group/2022-09-06_gleif-vendor-services-relationship-group-charter_v1.4.pdf
  35. https://www.gleif.org/about/gleif-services/iso-20000-certification/itms_707855.pdf
  36. https://www.gleif.org/about/gleif-services/service-reports/gleif-service-report-june-2023/2023-07-14_gleif_service_report_v1.0.pdf
  37. https://www.gleif.org/about/governance/by-laws/gleif-by-laws-final-27-october-2016.pdf
  38. https://www.gleif.org/about/governance/mou-between-gleif-and-roc/20150923-ROC-GLEIF-MOU-final-signed.pdf
  39. https://www.gleif.org/about/governance/policies/16-09-16_General_Accounting_FIN007_v.1_final.pdf
  40. https://www.gleif.org/about/governance/policies/16-09-16_IA_Charter_v.1_final.pdf
  41. https://www.gleif.org/about/governance/policies/2017-03-01_board-code-of-conduct_v1.0-final-approved.pdf
  42. https://www.gleif.org/about/governance/policies/2020-01-24_whistleblowingpolicy_v1.0-final-approved.pdf
  43. https://www.gleif.org/about/governance/policies/2020-02-05_bod_travelandexpense_policy_v2.0-final-approved.pdf
  44. https://www.gleif.org/about/governance/policies/2023-02-03_conflict_of_interest_policy_1.1final.pdf
  45. https://www.gleif.org/about/governance/regulatory-oversight-committee-roc/roc_20201001-1.pdf
  46. https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf
  47. https://www.gleif.org/lei-data/gleif-concatenated-file/about-the-concatenated-file/2017-02-05_gleif-concatenated-file_v2-4_final.pdf
  48. https://www.gleif.org/lei-data/gleif-data-quality-management/proactive-management/2021-11-10_checkforduplicatedictionary_v1.2-final.pdf
  49. https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf
  50. https://www.gleif.org/lei-data/gleif-golden-copy/2022-02-23_gleif-golden-copy-and-delta-files_v2.2-final.pdf
  51. https://www.gleif.org/lei-data/global-lei-index/download-global-lei-system-business-reports/2022-07-19_background_information_on_global_lei_system_report_v1.2.pdf
  52. https://www.gleif.org/lei-data/global-lei-index/download-global-lei-system-business-reports/2022-07-19_business-report-dictionary_v1.5.pdf
  53. https://www.gleif.org/lei-data/global-lei-index/download-global-lei-system-business-reports/download-global-lei-system-business-report-q2-2023/2023-07-18-quarterly_business_report.pdf
  54. https://www.gleif.org/lei-data/global-lei-index/lei-statistics/2022-07-19_lei_statistics_dashboard-dictionary_v1.1.pdf
  55. https://www.gleif.org/lei-data/lei-mapping/download-bic-to-lei-relationship-files/2017-12-21_annex-2_bic-to-lei-mapping-table-license-agreement_final.pdf
  56. https://www.gleif.org/lei-data/lei-mapping/download-bic-to-lei-relationship-files/2018-03-01_csv_import_guide_v1.1.pdf
  57. https://www.gleif.org/lei-data/lei-mapping/download-bic-to-lei-relationship-files/2023-03-23_bic-to-lei-factsheet_v1.3-final.pdf
  58. https://www.gleif.org/lei-data/lei-mapping/download-isin-to-lei-relationship-files/2018-03-01_csv_import_guide_v1.1.pdf
  59. https://www.gleif.org/lei-data/lei-mapping/download-isin-to-lei-relationship-files/2021-06-08_isin-to-lei_factsheet_v1.pdf
  60. https://www.gleif.org/lei-data/lei-mapping/download-mic-to-lei-relationship-files/2018-03-01_csv_import_guide_v1.1.pdf
  61. https://www.gleif.org/lei-data/lei-mapping/download-mic-to-lei-relationship-files/2022-09-02_mic_to_lei_mapping_table_license_agreement_v1.0.pdf
  62. https://www.gleif.org/lei-data/lei-mapping/download-mic-to-lei-relationship-files/20220902_mic_to_lei_factsheet_v1.0.pdf
  63. https://www.gleif.org/lei-data/lei-mapping/download-oc-to-lei-relationship-files/2018-03-01_csv_import_guide_v1.1.pdf
  64. https://www.gleif.org/lei-data/lei-mapping/download-oc-to-lei-relationship-files/2023-06-29_opencorporatesid-to-lei-factsheet_v1.1-final.pdf
  65. https://www.gleif.org/lei-data/lei-mapping/gleif-certification-process/2018-04-03_nda_gleif_template_v1.1.pdf
  66. https://www.gleif.org/lei-data/lei-mapping/gleif-certification-process/2020-02-13_internal-controls-checklist_v2.0-final.pdf
  67. https://www.gleif.org/lei-data/lei-mapping/gleif-certification-process/2021-09-02_lei_mapping_cooperation_agreement_v1.pdf
  68. https://www.gleif.org/lei-data/lei-mapping/gleif-certification-process/2021-09-10-appendix-2-contact-details.pdf
  69. https://www.gleif.org/lei-data/lei-mapping/s-p-global-company-id-to-lei-relationship/2022-10-10_s_p_global_company_id-to-lei_factsheet_v1.0.pdf
  70. https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-06-01_gleif_bloomberg_sanctions_screening_v1.0_bloomberg_approved_final.pdf
  71. https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-06-06_gleif_element-22_sanctions_screening_v1_approved_final.pdf
  72. https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-06-08_moodys_sanctions_screening_gleif_v1.0_approved.pdf
  73. https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-06-09_gleif_ceviant_kyc_onboarding_v1.0_approved_final.pdf
  74. https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-06-22_gleif_wmd_sanctions_screening_v1.0_final_approved.pdf
  75. https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-06-28_moodys_kyc-onboarding_gleif_v1.0_approved_final.pdf
  76. https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-06-5_gleif_lse_sanctions_screening_v1.0_approved_final.pdf
  77. https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-07-04_japan-eseal_gleif_v1.0_approved-final.pdf
  78. https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/p070722.pdf
  79. https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/swift_global_adoption_of_the_lei_finaldraftv1.pdf
  80. https://www.gleif.org/lei-solutions/gleifs-digital-strategy-for-the-lei/gleif-idc-research-creating-agile-resilient-global-trade-with-the-lei-and-vlei/2023-03-23_driving-business-with-trust-the-sustaining-role-of-secure-and-reliable-identities_final_public.pdf
  81. https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-findings_challenges-onboarding-client-organizations-in-banking-sector_v1.0-final.pdf
  82. https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-report_a-new-future-for-legal-entity-identification_final.pdf
  83. https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-the-pitfalls-of-onboarding/gleif-infographic_the-future-of-legal-entity-identification_final.pdf
  84. https://www.gleif.org/lei-solutions/mckinsey-company-and-gleif-leis-and-client-lifecycle-management-in-banking-a-u-s-4-billion-beginning/2019-10-29_gleif-ebook-leis-and-client-lifecycle-management-in-banking-a-u.s-4-billion-v1.0-approved-public.pdf
  85. https://www.gleif.org/lei-solutions/mckinsey-company-and-gleif-leis-and-client-lifecycle-management-in-banking-a-u-s-4-billion-beginning/gleif-infographic-leis-transforming-banks-client-lifecycle-management/2019-10-29_gleif-infographic-leis-transforming-banks-client-lifecycle-management_v1.0-approved-public.pdf
  86. https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/2021-08-10-foerderung-finanzieller-inklusion-von-unternehmen-in-afrika-globale-initiative-zur-digitalen-identifizierung-von-unternehmen-gestartet_v.1.1-final.pdf
  87. https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/2021-08-10-global-digital-business-identity-initiative-launches-to-boost-financial-inclusion-for-african-businesses_v.1.1-final.pdf
  88. https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/2021-08-10-lancement-de-initiative-identite-numerique-mondiale-de-l-entreprise-en-soutien-a-l-inclusion-financiere-des-entreprises-africaines_v.1.1-final.pdf
  89. https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/le-lei_la-cle-qui-deverrouillera-linclusion-financiere-dans-les-pays-en-developpement_v1.2-final.pdf
  90. https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies_v1.2-final.pdf
  91. https://www.gleif.org/lei-solutions/validation-agents/gleif-ebook-a-closer-look-at-the-validation-agent-trial-process/2021-03-03_gleif-validation-agent-trial-ebook_v1.0-approved-public.pdf
  92. https://www.gleif.org/lei-solutions/validation-agents/gleif-ebook-introducing-the-lei-validation-agent/2020-09-29_gleif-announces-new-va-role-for-fis_v1.0-final-clean.pdf
  93. https://www.gleif.org/lei-solutions/validation-agents/gleif-ebook-introducing-the-lei-validation-agent/2020-09-29_gleif-ebook-lei-validation-agent-framework_v1.1-final.pdf
  94. https://www.gleif.org/vlei/introducing-the-verifiable-lei-vlei/2023-04-03_vlei-q-a-updated_v1.1_final.pdf
  95. https://www.gleif.org/vlei/introducing-the-verifiable-lei-vlei/gleif-ebook-the-vlei-introducing-digital-i-d-for-organizations-everywhere/01-06-2023-gleif_introduction-to-the-vlei_redesign_v2.2.pdf
  96. https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-business-requirements_v1.0_final.pdf
  97. https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-gleif-identifier-governance-framework_v1.0_final.pdf
  98. https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-governance-requirements_v1.0_final.pdf
  99. https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-legal-entity-engagement-context-role-vlei-credential-framework_v.pdf
  100. https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-legal-entity-official-organizational-role-vlei-credential-govern.pdf
  101. https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-legal-entity-vlei-credential-governance-framework_v1.0_final.pdf
  102. https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-primary-document_v1.0_final.pdf
  103. https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-qualified-vlei-issuer-authorization-vlei-credential-framework_v1.pdf
  104. https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-technical-requirements-part2-vlei-credentials_v1.0_final.pdf
  105. https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-technical-requirements-part_3-vlei-credential-schema-registry_v1.pdf
  106. https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-vlei-ecosystem-information-trust-policies_v1.0_final.pdf
  107. https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-glossary_v1.1_final.pdf
  108. https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-qualified-vlei-issuer-identifer-vlei-credential-governance-framewo.pdf
  109. https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-risk-assessment_v1.1_final.pdf
  110. https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-technical-requirements-part1-keri-infrastructure_v1.1_final.pdf
  111. https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-trust-assurance-framework_v1.1_final.pdf
  112. https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-4-vlei-issuer-contact-details_v1.0_final.pdf
  113. https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-5-qualified-vlei-issuer-service-level-agreement_v1.2_final.pdf
  114. https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-6-terms-of-use-qualified-vlei-issuer-trustmark_v1.0_final.pdf
  115. https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-7-qualified-vlei-issuer-legal-entity-contract-terms_v1.0_final.pdf
  116. https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_vlei-issuer-qualification-agreement_v1.0_final.pdf
  117. https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2023-04-03_appendix-1-non-disclosure-agreement_v1.1_final.pdf
  118. https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2023-04-03_appendix-2-vlei-issuer-qualification-program-manual_v1.1_final.pdf
  119. https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2023-04-03_appendix-3-vlei-issuer-qualification-program-checklist_v1.2_final.pdf
+ + + + diff --git a/package-lock.json b/package-lock.json new file mode 100644 index 0000000..191f753 --- /dev/null +++ b/package-lock.json @@ -0,0 +1,5145 @@ +{ + "name": "kerisse", + "version": "1.0.0", + "lockfileVersion": 3, + "requires": true, + "packages": { + "": { + "name": "kerisse", + "version": "1.0.0", + "license": "ISC", + "dependencies": { + "instantsearch.js": "^4.8.3", + "typesense-instantsearch-adapter": "^2.4.1" + }, + "devDependencies": { + "copy-webpack-plugin": "^12.0.2", + "css-loader": "^7.1.2", + "mini-css-extract-plugin": "^2.9.0", + "style-loader": "^4.0.0", + "webpack": "^5.92.1", + "webpack-cli": "^5.1.4", + "webpack-dev-server": "^5.0.4" + } + }, + "node_modules/@algolia/cache-browser-local-storage": { + "version": "4.24.0", + "resolved": "https://registry.npmjs.org/@algolia/cache-browser-local-storage/-/cache-browser-local-storage-4.24.0.tgz", + "integrity": "sha512-t63W9BnoXVrGy9iYHBgObNXqYXM3tYXCjDSHeNwnsc324r4o5UiVKUiAB4THQ5z9U5hTj6qUvwg/Ez43ZD85ww==", + "peer": true, + "dependencies": { + "@algolia/cache-common": "4.24.0" + } + }, + "node_modules/@algolia/cache-common": { + "version": "4.24.0", + "resolved": "https://registry.npmjs.org/@algolia/cache-common/-/cache-common-4.24.0.tgz", + "integrity": "sha512-emi+v+DmVLpMGhp0V9q9h5CdkURsNmFC+cOS6uK9ndeJm9J4TiqSvPYVu+THUP8P/S08rxf5x2P+p3CfID0Y4g==", + "peer": true + }, + "node_modules/@algolia/cache-in-memory": { + "version": "4.24.0", + "resolved": "https://registry.npmjs.org/@algolia/cache-in-memory/-/cache-in-memory-4.24.0.tgz", + "integrity": "sha512-gDrt2so19jW26jY3/MkFg5mEypFIPbPoXsQGQWAi6TrCPsNOSEYepBMPlucqWigsmEy/prp5ug2jy/N3PVG/8w==", + "peer": true, + "dependencies": { + "@algolia/cache-common": "4.24.0" + } + }, + "node_modules/@algolia/client-account": { + "version": "4.24.0", + "resolved": "https://registry.npmjs.org/@algolia/client-account/-/client-account-4.24.0.tgz", + "integrity": "sha512-adcvyJ3KjPZFDybxlqnf+5KgxJtBjwTPTeyG2aOyoJvx0Y8dUQAEOEVOJ/GBxX0WWNbmaSrhDURMhc+QeevDsA==", + "peer": true, + "dependencies": { + "@algolia/client-common": "4.24.0", + "@algolia/client-search": "4.24.0", + "@algolia/transporter": "4.24.0" + } + }, + "node_modules/@algolia/client-analytics": { + "version": "4.24.0", + "resolved": "https://registry.npmjs.org/@algolia/client-analytics/-/client-analytics-4.24.0.tgz", + "integrity": "sha512-y8jOZt1OjwWU4N2qr8G4AxXAzaa8DBvyHTWlHzX/7Me1LX8OayfgHexqrsL4vSBcoMmVw2XnVW9MhL+Y2ZDJXg==", + "peer": true, + "dependencies": { + "@algolia/client-common": "4.24.0", + "@algolia/client-search": "4.24.0", + "@algolia/requester-common": "4.24.0", + "@algolia/transporter": "4.24.0" + } + }, + "node_modules/@algolia/client-common": { + "version": "4.24.0", + "resolved": "https://registry.npmjs.org/@algolia/client-common/-/client-common-4.24.0.tgz", + "integrity": "sha512-bc2ROsNL6w6rqpl5jj/UywlIYC21TwSSoFHKl01lYirGMW+9Eek6r02Tocg4gZ8HAw3iBvu6XQiM3BEbmEMoiA==", + "peer": true, + "dependencies": { + "@algolia/requester-common": "4.24.0", + "@algolia/transporter": "4.24.0" + } + }, + "node_modules/@algolia/client-personalization": { + "version": "4.24.0", + "resolved": "https://registry.npmjs.org/@algolia/client-personalization/-/client-personalization-4.24.0.tgz", + "integrity": "sha512-l5FRFm/yngztweU0HdUzz1rC4yoWCFo3IF+dVIVTfEPg906eZg5BOd1k0K6rZx5JzyyoP4LdmOikfkfGsKVE9w==", + "peer": true, + "dependencies": { + "@algolia/client-common": "4.24.0", + "@algolia/requester-common": "4.24.0", + "@algolia/transporter": "4.24.0" + } + }, + "node_modules/@algolia/client-search": { + "version": "4.24.0", + "resolved": "https://registry.npmjs.org/@algolia/client-search/-/client-search-4.24.0.tgz", + "integrity": "sha512-uRW6EpNapmLAD0mW47OXqTP8eiIx5F6qN9/x/7HHO6owL3N1IXqydGwW5nhDFBrV+ldouro2W1VX3XlcUXEFCA==", + "peer": true, + "dependencies": { + "@algolia/client-common": "4.24.0", + "@algolia/requester-common": "4.24.0", + "@algolia/transporter": "4.24.0" + } + }, + "node_modules/@algolia/events": { + "version": "4.0.1", + "resolved": "https://registry.npmjs.org/@algolia/events/-/events-4.0.1.tgz", + "integrity": "sha512-FQzvOCgoFXAbf5Y6mYozw2aj5KCJoA3m4heImceldzPSMbdyS4atVjJzXKMsfX3wnZTFYwkkt8/z8UesLHlSBQ==" + }, + "node_modules/@algolia/logger-common": { + "version": "4.24.0", + "resolved": "https://registry.npmjs.org/@algolia/logger-common/-/logger-common-4.24.0.tgz", + "integrity": "sha512-LLUNjkahj9KtKYrQhFKCzMx0BY3RnNP4FEtO+sBybCjJ73E8jNdaKJ/Dd8A/VA4imVHP5tADZ8pn5B8Ga/wTMA==", + "peer": true + }, + "node_modules/@algolia/logger-console": { + "version": "4.24.0", + "resolved": "https://registry.npmjs.org/@algolia/logger-console/-/logger-console-4.24.0.tgz", + "integrity": "sha512-X4C8IoHgHfiUROfoRCV+lzSy+LHMgkoEEU1BbKcsfnV0i0S20zyy0NLww9dwVHUWNfPPxdMU+/wKmLGYf96yTg==", + "peer": true, + "dependencies": { + "@algolia/logger-common": "4.24.0" + } + }, + "node_modules/@algolia/recommend": { + "version": "4.24.0", + "resolved": "https://registry.npmjs.org/@algolia/recommend/-/recommend-4.24.0.tgz", + "integrity": "sha512-P9kcgerfVBpfYHDfVZDvvdJv0lEoCvzNlOy2nykyt5bK8TyieYyiD0lguIJdRZZYGre03WIAFf14pgE+V+IBlw==", + "peer": true, + "dependencies": { + "@algolia/cache-browser-local-storage": "4.24.0", + "@algolia/cache-common": "4.24.0", + "@algolia/cache-in-memory": "4.24.0", + "@algolia/client-common": "4.24.0", + "@algolia/client-search": "4.24.0", + "@algolia/logger-common": "4.24.0", + "@algolia/logger-console": "4.24.0", + "@algolia/requester-browser-xhr": "4.24.0", + "@algolia/requester-common": "4.24.0", + "@algolia/requester-node-http": "4.24.0", + "@algolia/transporter": "4.24.0" + } + }, + "node_modules/@algolia/requester-browser-xhr": { + "version": "4.24.0", + "resolved": "https://registry.npmjs.org/@algolia/requester-browser-xhr/-/requester-browser-xhr-4.24.0.tgz", + "integrity": "sha512-Z2NxZMb6+nVXSjF13YpjYTdvV3032YTBSGm2vnYvYPA6mMxzM3v5rsCiSspndn9rzIW4Qp1lPHBvuoKJV6jnAA==", + "peer": true, + "dependencies": { + "@algolia/requester-common": "4.24.0" + } + }, + "node_modules/@algolia/requester-common": { + "version": "4.24.0", + "resolved": "https://registry.npmjs.org/@algolia/requester-common/-/requester-common-4.24.0.tgz", + "integrity": "sha512-k3CXJ2OVnvgE3HMwcojpvY6d9kgKMPRxs/kVohrwF5WMr2fnqojnycZkxPoEg+bXm8fi5BBfFmOqgYztRtHsQA==", + "peer": true + }, + "node_modules/@algolia/requester-node-http": { + "version": "4.24.0", + "resolved": "https://registry.npmjs.org/@algolia/requester-node-http/-/requester-node-http-4.24.0.tgz", + "integrity": "sha512-JF18yTjNOVYvU/L3UosRcvbPMGT9B+/GQWNWnenIImglzNVGpyzChkXLnrSf6uxwVNO6ESGu6oN8MqcGQcjQJw==", + "peer": true, + "dependencies": { + "@algolia/requester-common": "4.24.0" + } + }, + "node_modules/@algolia/transporter": { + "version": "4.24.0", + "resolved": "https://registry.npmjs.org/@algolia/transporter/-/transporter-4.24.0.tgz", + "integrity": "sha512-86nI7w6NzWxd1Zp9q3413dRshDqAzSbsQjhcDhPIatEFiZrL1/TjnHL8S7jVKFePlIMzDsZWXAXwXzcok9c5oA==", + "peer": true, + "dependencies": { + "@algolia/cache-common": "4.24.0", + "@algolia/logger-common": "4.24.0", + "@algolia/requester-common": "4.24.0" + } + }, + "node_modules/@babel/runtime": { + "version": "7.24.7", + "resolved": "https://registry.npmjs.org/@babel/runtime/-/runtime-7.24.7.tgz", + "integrity": "sha512-UwgBRMjJP+xv857DCngvqXI3Iq6J4v0wXmwc6sapg+zyhbwmQX67LUEFrkK5tbyJ30jGuG3ZvWpBiB9LCy1kWw==", + "dependencies": { + "regenerator-runtime": "^0.14.0" + }, + "engines": { + "node": ">=6.9.0" + } + }, + "node_modules/@discoveryjs/json-ext": { + "version": "0.5.7", + "resolved": "https://registry.npmjs.org/@discoveryjs/json-ext/-/json-ext-0.5.7.tgz", + "integrity": "sha512-dBVuXR082gk3jsFp7Rd/JI4kytwGHecnCoTtXFb7DB6CNHp4rg5k1bhg0nWdLGLnOV71lmDzGQaLMy8iPLY0pw==", + "dev": true, + "engines": { + "node": ">=10.0.0" + } + }, + "node_modules/@isaacs/cliui": { + "version": "8.0.2", + "resolved": "https://registry.npmjs.org/@isaacs/cliui/-/cliui-8.0.2.tgz", + "integrity": "sha512-O8jcjabXaleOG9DQ0+ARXWZBTfnP4WNAqzuiJK7ll44AmxGKv/J2M4TPjxjY3znBCfvBXFzucm1twdyFybFqEA==", + "dev": true, + "dependencies": { + "string-width": "^5.1.2", + "string-width-cjs": "npm:string-width@^4.2.0", + "strip-ansi": "^7.0.1", + "strip-ansi-cjs": "npm:strip-ansi@^6.0.1", + "wrap-ansi": "^8.1.0", + "wrap-ansi-cjs": "npm:wrap-ansi@^7.0.0" + }, + "engines": { + "node": ">=12" + } + }, + "node_modules/@jridgewell/gen-mapping": { + "version": "0.3.5", + "resolved": "https://registry.npmjs.org/@jridgewell/gen-mapping/-/gen-mapping-0.3.5.tgz", + "integrity": "sha512-IzL8ZoEDIBRWEzlCcRhOaCupYyN5gdIK+Q6fbFdPDg6HqX6jpkItn7DFIpW9LQzXG6Df9sA7+OKnq0qlz/GaQg==", + "dev": true, + "dependencies": { + "@jridgewell/set-array": "^1.2.1", + "@jridgewell/sourcemap-codec": "^1.4.10", + "@jridgewell/trace-mapping": "^0.3.24" + }, + "engines": { + "node": ">=6.0.0" + } + }, + "node_modules/@jridgewell/resolve-uri": { + "version": "3.1.2", + "resolved": "https://registry.npmjs.org/@jridgewell/resolve-uri/-/resolve-uri-3.1.2.tgz", + "integrity": "sha512-bRISgCIjP20/tbWSPWMEi54QVPRZExkuD9lJL+UIxUKtwVJA8wW1Trb1jMs1RFXo1CBTNZ/5hpC9QvmKWdopKw==", + "dev": true, + "engines": { + "node": ">=6.0.0" + } + }, + "node_modules/@jridgewell/set-array": { + "version": "1.2.1", + "resolved": "https://registry.npmjs.org/@jridgewell/set-array/-/set-array-1.2.1.tgz", + "integrity": "sha512-R8gLRTZeyp03ymzP/6Lil/28tGeGEzhx1q2k703KGWRAI1VdvPIXdG70VJc2pAMw3NA6JKL5hhFu1sJX0Mnn/A==", + "dev": true, + "engines": { + "node": ">=6.0.0" + } + }, + "node_modules/@jridgewell/source-map": { + "version": "0.3.6", + "resolved": "https://registry.npmjs.org/@jridgewell/source-map/-/source-map-0.3.6.tgz", + "integrity": "sha512-1ZJTZebgqllO79ue2bm3rIGud/bOe0pP5BjSRCRxxYkEZS8STV7zN84UBbiYu7jy+eCKSnVIUgoWWE/tt+shMQ==", + "dev": true, + "dependencies": { + "@jridgewell/gen-mapping": "^0.3.5", + "@jridgewell/trace-mapping": "^0.3.25" + } + }, + "node_modules/@jridgewell/sourcemap-codec": { + "version": "1.5.0", + "resolved": "https://registry.npmjs.org/@jridgewell/sourcemap-codec/-/sourcemap-codec-1.5.0.tgz", + "integrity": "sha512-gv3ZRaISU3fjPAgNsriBRqGWQL6quFx04YMPW/zD8XMLsU32mhCCbfbO6KZFLjvYpCZ8zyDEgqsgf+PwPaM7GQ==", + "dev": true + }, + "node_modules/@jridgewell/trace-mapping": { + "version": "0.3.25", + "resolved": "https://registry.npmjs.org/@jridgewell/trace-mapping/-/trace-mapping-0.3.25.tgz", + "integrity": "sha512-vNk6aEwybGtawWmy/PzwnGDOjCkLWSD2wqvjGGAgOAwCGWySYXfYoxt00IJkTF+8Lb57DwOb3Aa0o9CApepiYQ==", + "dev": true, + "dependencies": { + "@jridgewell/resolve-uri": "^3.1.0", + "@jridgewell/sourcemap-codec": "^1.4.14" + } + }, + "node_modules/@jsonjoy.com/base64": { + "version": "1.1.2", + "resolved": "https://registry.npmjs.org/@jsonjoy.com/base64/-/base64-1.1.2.tgz", + "integrity": "sha512-q6XAnWQDIMA3+FTiOYajoYqySkO+JSat0ytXGSuRdq9uXE7o92gzuQwQM14xaCRlBLGq3v5miDGC4vkVTn54xA==", + "dev": true, + "engines": { + "node": ">=10.0" + }, + "funding": { + "type": "github", + "url": "https://github.com/sponsors/streamich" + }, + "peerDependencies": { + "tslib": "2" + } + }, + "node_modules/@jsonjoy.com/json-pack": { + "version": "1.0.4", + "resolved": "https://registry.npmjs.org/@jsonjoy.com/json-pack/-/json-pack-1.0.4.tgz", + "integrity": "sha512-aOcSN4MeAtFROysrbqG137b7gaDDSmVrl5mpo6sT/w+kcXpWnzhMjmY/Fh/sDx26NBxyIE7MB1seqLeCAzy9Sg==", + "dev": true, + "dependencies": { + "@jsonjoy.com/base64": "^1.1.1", + "@jsonjoy.com/util": "^1.1.2", + "hyperdyperid": "^1.2.0", + "thingies": "^1.20.0" + }, + "engines": { + "node": ">=10.0" + }, + "funding": { + "type": "github", + "url": "https://github.com/sponsors/streamich" + }, + "peerDependencies": { + "tslib": "2" + } + }, + "node_modules/@jsonjoy.com/util": { + "version": "1.2.0", + "resolved": "https://registry.npmjs.org/@jsonjoy.com/util/-/util-1.2.0.tgz", + "integrity": "sha512-4B8B+3vFsY4eo33DMKyJPlQ3sBMpPFUZK2dr3O3rXrOGKKbYG44J0XSFkDo1VOQiri5HFEhIeVvItjR2xcazmg==", + "dev": true, + "engines": { + "node": ">=10.0" + }, + "funding": { + "type": "github", + "url": "https://github.com/sponsors/streamich" + }, + "peerDependencies": { + "tslib": "2" + } + }, + "node_modules/@leichtgewicht/ip-codec": { + "version": "2.0.5", + "resolved": "https://registry.npmjs.org/@leichtgewicht/ip-codec/-/ip-codec-2.0.5.tgz", + "integrity": "sha512-Vo+PSpZG2/fmgmiNzYK9qWRh8h/CHrwD0mo1h1DzL4yzHNSfWYujGTYsWGreD000gcgmZ7K4Ys6Tx9TxtsKdDw==", + "dev": true + }, + "node_modules/@nodelib/fs.scandir": { + "version": "2.1.5", + "resolved": "https://registry.npmjs.org/@nodelib/fs.scandir/-/fs.scandir-2.1.5.tgz", + "integrity": "sha512-vq24Bq3ym5HEQm2NKCr3yXDwjc7vTsEThRDnkp2DK9p1uqLR+DHurm/NOTo0KG7HYHU7eppKZj3MyqYuMBf62g==", + "dev": true, + "dependencies": { + "@nodelib/fs.stat": "2.0.5", + "run-parallel": "^1.1.9" + }, + "engines": { + "node": ">= 8" + } + }, + "node_modules/@nodelib/fs.stat": { + "version": "2.0.5", + "resolved": "https://registry.npmjs.org/@nodelib/fs.stat/-/fs.stat-2.0.5.tgz", + "integrity": "sha512-RkhPPp2zrqDAQA/2jNhnztcPAlv64XdhIp7a7454A5ovI7Bukxgt7MX7udwAu3zg1DcpPU0rz3VV1SeaqvY4+A==", + "dev": true, + "engines": { + "node": ">= 8" + } + }, + "node_modules/@nodelib/fs.walk": { + "version": "1.2.8", + "resolved": "https://registry.npmjs.org/@nodelib/fs.walk/-/fs.walk-1.2.8.tgz", + "integrity": "sha512-oGB+UxlgWcgQkgwo8GcEGwemoTFt3FIO9ababBmaGwXIoBKZ+GTy0pP185beGg7Llih/NSHSV2XAs1lnznocSg==", + "dev": true, + "dependencies": { + "@nodelib/fs.scandir": "2.1.5", + "fastq": "^1.6.0" + }, + "engines": { + "node": ">= 8" + } + }, + "node_modules/@pkgjs/parseargs": { + "version": "0.11.0", + "resolved": "https://registry.npmjs.org/@pkgjs/parseargs/-/parseargs-0.11.0.tgz", + "integrity": "sha512-+1VkjdD0QBLPodGrJUeqarH8VAIvQODIbwh9XpP5Syisf7YoQgsJKPNFoqqLQlu+VQ/tVSshMR6loPMn8U+dPg==", + "dev": true, + "optional": true, + "engines": { + "node": ">=14" + } + }, + "node_modules/@sindresorhus/merge-streams": { + "version": "2.3.0", + "resolved": "https://registry.npmjs.org/@sindresorhus/merge-streams/-/merge-streams-2.3.0.tgz", + "integrity": "sha512-LtoMMhxAlorcGhmFYI+LhPgbPZCkgP6ra1YL604EeF6U98pLlQ3iWIGMdWSC+vWmPBWBNgmDBAhnAobLROJmwg==", + "dev": true, + "engines": { + "node": ">=18" + }, + "funding": { + "url": "https://github.com/sponsors/sindresorhus" + } + }, + "node_modules/@types/body-parser": { + "version": "1.19.5", + "resolved": "https://registry.npmjs.org/@types/body-parser/-/body-parser-1.19.5.tgz", + "integrity": "sha512-fB3Zu92ucau0iQ0JMCFQE7b/dv8Ot07NI3KaZIkIUNXq82k4eBAqUaneXfleGY9JWskeS9y+u0nXMyspcuQrCg==", + "dev": true, + "dependencies": { + "@types/connect": "*", + "@types/node": "*" + } + }, + "node_modules/@types/bonjour": { + "version": "3.5.13", + "resolved": "https://registry.npmjs.org/@types/bonjour/-/bonjour-3.5.13.tgz", + "integrity": "sha512-z9fJ5Im06zvUL548KvYNecEVlA7cVDkGUi6kZusb04mpyEFKCIZJvloCcmpmLaIahDpOQGHaHmG6imtPMmPXGQ==", + "dev": true, + "dependencies": { + "@types/node": "*" + } + }, + "node_modules/@types/connect": { + "version": "3.4.38", + "resolved": "https://registry.npmjs.org/@types/connect/-/connect-3.4.38.tgz", + "integrity": "sha512-K6uROf1LD88uDQqJCktA4yzL1YYAK6NgfsI0v/mTgyPKWsX1CnJ0XPSDhViejru1GcRkLWb8RlzFYJRqGUbaug==", + "dev": true, + "dependencies": { + "@types/node": "*" + } + }, + "node_modules/@types/connect-history-api-fallback": { + "version": "1.5.4", + "resolved": "https://registry.npmjs.org/@types/connect-history-api-fallback/-/connect-history-api-fallback-1.5.4.tgz", + "integrity": "sha512-n6Cr2xS1h4uAulPRdlw6Jl6s1oG8KrVilPN2yUITEs+K48EzMJJ3W1xy8K5eWuFvjp3R74AOIGSmp2UfBJ8HFw==", + "dev": true, + "dependencies": { + "@types/express-serve-static-core": "*", + "@types/node": "*" + } + }, + "node_modules/@types/dom-speech-recognition": { + "version": "0.0.1", + "resolved": "https://registry.npmjs.org/@types/dom-speech-recognition/-/dom-speech-recognition-0.0.1.tgz", + "integrity": "sha512-udCxb8DvjcDKfk1WTBzDsxFbLgYxmQGKrE/ricoMqHRNjSlSUCcamVTA5lIQqzY10mY5qCY0QDwBfFEwhfoDPw==" + }, + "node_modules/@types/eslint": { + "version": "8.56.10", + "resolved": "https://registry.npmjs.org/@types/eslint/-/eslint-8.56.10.tgz", + "integrity": "sha512-Shavhk87gCtY2fhXDctcfS3e6FdxWkCx1iUZ9eEUbh7rTqlZT0/IzOkCOVt0fCjcFuZ9FPYfuezTBImfHCDBGQ==", + "dev": true, + "dependencies": { + "@types/estree": "*", + "@types/json-schema": "*" + } + }, + "node_modules/@types/eslint-scope": { + "version": "3.7.7", + "resolved": "https://registry.npmjs.org/@types/eslint-scope/-/eslint-scope-3.7.7.tgz", + "integrity": "sha512-MzMFlSLBqNF2gcHWO0G1vP/YQyfvrxZ0bF+u7mzUdZ1/xK4A4sru+nraZz5i3iEIk1l1uyicaDVTB4QbbEkAYg==", + "dev": true, + "dependencies": { + "@types/eslint": "*", + "@types/estree": "*" + } + }, + "node_modules/@types/estree": { + "version": "1.0.5", + "resolved": "https://registry.npmjs.org/@types/estree/-/estree-1.0.5.tgz", + "integrity": "sha512-/kYRxGDLWzHOB7q+wtSUQlFrtcdUccpfy+X+9iMBpHK8QLLhx2wIPYuS5DYtR9Wa/YlZAbIovy7qVdB1Aq6Lyw==", + "dev": true + }, + "node_modules/@types/express": { + "version": "4.17.21", + "resolved": "https://registry.npmjs.org/@types/express/-/express-4.17.21.tgz", + "integrity": "sha512-ejlPM315qwLpaQlQDTjPdsUFSc6ZsP4AN6AlWnogPjQ7CVi7PYF3YVz+CY3jE2pwYf7E/7HlDAN0rV2GxTG0HQ==", + "dev": true, + "dependencies": { + "@types/body-parser": "*", + "@types/express-serve-static-core": "^4.17.33", + "@types/qs": "*", + "@types/serve-static": "*" + } + }, + "node_modules/@types/express-serve-static-core": { + "version": "4.19.5", + "resolved": "https://registry.npmjs.org/@types/express-serve-static-core/-/express-serve-static-core-4.19.5.tgz", + "integrity": "sha512-y6W03tvrACO72aijJ5uF02FRq5cgDR9lUxddQ8vyF+GvmjJQqbzDcJngEjURc+ZsG31VI3hODNZJ2URj86pzmg==", + "dev": true, + "dependencies": { + "@types/node": "*", + "@types/qs": "*", + "@types/range-parser": "*", + "@types/send": "*" + } + }, + "node_modules/@types/google.maps": { + "version": "3.55.11", + "resolved": "https://registry.npmjs.org/@types/google.maps/-/google.maps-3.55.11.tgz", + "integrity": "sha512-F3VuPtjKj4UGuyym75pqmgPBOHbT/i7I6/D+4DdtSzbeu2aWZG1ENwpbZOd46uO+PSAz9flJEhxxi+b4MVb4gQ==" + }, + "node_modules/@types/hogan.js": { + "version": "3.0.5", + "resolved": "https://registry.npmjs.org/@types/hogan.js/-/hogan.js-3.0.5.tgz", + "integrity": "sha512-/uRaY3HGPWyLqOyhgvW9Aa43BNnLZrNeQxl2p8wqId4UHMfPKolSB+U7BlZyO1ng7MkLnyEAItsBzCG0SDhqrA==" + }, + "node_modules/@types/http-errors": { + "version": "2.0.4", + "resolved": "https://registry.npmjs.org/@types/http-errors/-/http-errors-2.0.4.tgz", + "integrity": "sha512-D0CFMMtydbJAegzOyHjtiKPLlvnm3iTZyZRSZoLq2mRhDdmLfIWOCYPfQJ4cu2erKghU++QvjcUjp/5h7hESpA==", + "dev": true + }, + "node_modules/@types/http-proxy": { + "version": "1.17.14", + "resolved": "https://registry.npmjs.org/@types/http-proxy/-/http-proxy-1.17.14.tgz", + "integrity": "sha512-SSrD0c1OQzlFX7pGu1eXxSEjemej64aaNPRhhVYUGqXh0BtldAAx37MG8btcumvpgKyZp1F5Gn3JkktdxiFv6w==", + "dev": true, + "dependencies": { + "@types/node": "*" + } + }, + "node_modules/@types/json-schema": { + "version": "7.0.15", + "resolved": "https://registry.npmjs.org/@types/json-schema/-/json-schema-7.0.15.tgz", + "integrity": "sha512-5+fP8P8MFNC+AyZCDxrB2pkZFPGzqQWUzpSeuuVLvm8VMcorNYavBqoFcxK8bQz4Qsbn4oUEEem4wDLfcysGHA==", + "dev": true + }, + "node_modules/@types/mime": { + "version": "1.3.5", + "resolved": "https://registry.npmjs.org/@types/mime/-/mime-1.3.5.tgz", + "integrity": "sha512-/pyBZWSLD2n0dcHE3hq8s8ZvcETHtEuF+3E7XVt0Ig2nvsVQXdghHVcEkIWjy9A0wKfTn97a/PSDYohKIlnP/w==", + "dev": true + }, + "node_modules/@types/node": { + "version": "20.14.10", + "resolved": "https://registry.npmjs.org/@types/node/-/node-20.14.10.tgz", + "integrity": "sha512-MdiXf+nDuMvY0gJKxyfZ7/6UFsETO7mGKF54MVD/ekJS6HdFtpZFBgrh6Pseu64XTb2MLyFPlbW6hj8HYRQNOQ==", + "dev": true, + "dependencies": { + "undici-types": "~5.26.4" + } + }, + "node_modules/@types/node-forge": { + "version": "1.3.11", + "resolved": "https://registry.npmjs.org/@types/node-forge/-/node-forge-1.3.11.tgz", + "integrity": "sha512-FQx220y22OKNTqaByeBGqHWYz4cl94tpcxeFdvBo3wjG6XPBuZ0BNgNZRV5J5TFmmcsJ4IzsLkmGRiQbnYsBEQ==", + "dev": true, + "dependencies": { + "@types/node": "*" + } + }, + "node_modules/@types/qs": { + "version": "6.9.15", + "resolved": "https://registry.npmjs.org/@types/qs/-/qs-6.9.15.tgz", + "integrity": "sha512-uXHQKES6DQKKCLh441Xv/dwxOq1TVS3JPUMlEqoEglvlhR6Mxnlew/Xq/LRVHpLyk7iK3zODe1qYHIMltO7XGg==" + }, + "node_modules/@types/range-parser": { + "version": "1.2.7", + "resolved": "https://registry.npmjs.org/@types/range-parser/-/range-parser-1.2.7.tgz", + "integrity": "sha512-hKormJbkJqzQGhziax5PItDUTMAM9uE2XXQmM37dyd4hVM+5aVl7oVxMVUiVQn2oCQFN/LKCZdvSM0pFRqbSmQ==", + "dev": true + }, + "node_modules/@types/retry": { + "version": "0.12.2", + "resolved": "https://registry.npmjs.org/@types/retry/-/retry-0.12.2.tgz", + "integrity": "sha512-XISRgDJ2Tc5q4TRqvgJtzsRkFYNJzZrhTdtMoGVBttwzzQJkPnS3WWTFc7kuDRoPtPakl+T+OfdEUjYJj7Jbow==", + "dev": true + }, + "node_modules/@types/send": { + "version": "0.17.4", + "resolved": "https://registry.npmjs.org/@types/send/-/send-0.17.4.tgz", + "integrity": "sha512-x2EM6TJOybec7c52BX0ZspPodMsQUd5L6PRwOunVyVUhXiBSKf3AezDL8Dgvgt5o0UfKNfuA0eMLr2wLT4AiBA==", + "dev": true, + "dependencies": { + "@types/mime": "^1", + "@types/node": "*" + } + }, + "node_modules/@types/serve-index": { + "version": "1.9.4", + "resolved": "https://registry.npmjs.org/@types/serve-index/-/serve-index-1.9.4.tgz", + "integrity": "sha512-qLpGZ/c2fhSs5gnYsQxtDEq3Oy8SXPClIXkW5ghvAvsNuVSA8k+gCONcUCS/UjLEYvYps+e8uBtfgXgvhwfNug==", + "dev": true, + "dependencies": { + "@types/express": "*" + } + }, + "node_modules/@types/serve-static": { + "version": "1.15.7", + "resolved": "https://registry.npmjs.org/@types/serve-static/-/serve-static-1.15.7.tgz", + "integrity": "sha512-W8Ym+h8nhuRwaKPaDw34QUkwsGi6Rc4yYqvKFo5rm2FUEhCFbzVWrxXUxuKK8TASjWsysJY0nsmNCGhCOIsrOw==", + "dev": true, + "dependencies": { + "@types/http-errors": "*", + "@types/node": "*", + "@types/send": "*" + } + }, + "node_modules/@types/sockjs": { + "version": "0.3.36", + "resolved": "https://registry.npmjs.org/@types/sockjs/-/sockjs-0.3.36.tgz", + "integrity": "sha512-MK9V6NzAS1+Ud7JV9lJLFqW85VbC9dq3LmwZCuBe4wBDgKC0Kj/jd8Xl+nSviU+Qc3+m7umHHyHg//2KSa0a0Q==", + "dev": true, + "dependencies": { + "@types/node": "*" + } + }, + "node_modules/@types/ws": { + "version": "8.5.10", + "resolved": "https://registry.npmjs.org/@types/ws/-/ws-8.5.10.tgz", + "integrity": "sha512-vmQSUcfalpIq0R9q7uTo2lXs6eGIpt9wtnLdMv9LVpIjCA/+ufZRozlVoVelIYixx1ugCBKDhn89vnsEGOCx9A==", + "dev": true, + "dependencies": { + "@types/node": "*" + } + }, + "node_modules/@webassemblyjs/ast": { + "version": "1.12.1", + "resolved": "https://registry.npmjs.org/@webassemblyjs/ast/-/ast-1.12.1.tgz", + "integrity": "sha512-EKfMUOPRRUTy5UII4qJDGPpqfwjOmZ5jeGFwid9mnoqIFK+e0vqoi1qH56JpmZSzEL53jKnNzScdmftJyG5xWg==", + "dev": true, + "dependencies": { + "@webassemblyjs/helper-numbers": "1.11.6", + "@webassemblyjs/helper-wasm-bytecode": "1.11.6" + } + }, + "node_modules/@webassemblyjs/floating-point-hex-parser": { + "version": "1.11.6", + "resolved": "https://registry.npmjs.org/@webassemblyjs/floating-point-hex-parser/-/floating-point-hex-parser-1.11.6.tgz", + "integrity": "sha512-ejAj9hfRJ2XMsNHk/v6Fu2dGS+i4UaXBXGemOfQ/JfQ6mdQg/WXtwleQRLLS4OvfDhv8rYnVwH27YJLMyYsxhw==", + "dev": true + }, + "node_modules/@webassemblyjs/helper-api-error": { + "version": "1.11.6", + "resolved": "https://registry.npmjs.org/@webassemblyjs/helper-api-error/-/helper-api-error-1.11.6.tgz", + "integrity": "sha512-o0YkoP4pVu4rN8aTJgAyj9hC2Sv5UlkzCHhxqWj8butaLvnpdc2jOwh4ewE6CX0txSfLn/UYaV/pheS2Txg//Q==", + "dev": true + }, + "node_modules/@webassemblyjs/helper-buffer": { + "version": "1.12.1", + "resolved": "https://registry.npmjs.org/@webassemblyjs/helper-buffer/-/helper-buffer-1.12.1.tgz", + "integrity": "sha512-nzJwQw99DNDKr9BVCOZcLuJJUlqkJh+kVzVl6Fmq/tI5ZtEyWT1KZMyOXltXLZJmDtvLCDgwsyrkohEtopTXCw==", + "dev": true + }, + "node_modules/@webassemblyjs/helper-numbers": { + "version": "1.11.6", + "resolved": "https://registry.npmjs.org/@webassemblyjs/helper-numbers/-/helper-numbers-1.11.6.tgz", + "integrity": "sha512-vUIhZ8LZoIWHBohiEObxVm6hwP034jwmc9kuq5GdHZH0wiLVLIPcMCdpJzG4C11cHoQ25TFIQj9kaVADVX7N3g==", + "dev": true, + "dependencies": { + "@webassemblyjs/floating-point-hex-parser": "1.11.6", + "@webassemblyjs/helper-api-error": "1.11.6", + "@xtuc/long": "4.2.2" + } + }, + "node_modules/@webassemblyjs/helper-wasm-bytecode": { + "version": "1.11.6", + "resolved": "https://registry.npmjs.org/@webassemblyjs/helper-wasm-bytecode/-/helper-wasm-bytecode-1.11.6.tgz", + "integrity": "sha512-sFFHKwcmBprO9e7Icf0+gddyWYDViL8bpPjJJl0WHxCdETktXdmtWLGVzoHbqUcY4Be1LkNfwTmXOJUFZYSJdA==", + "dev": true + }, + "node_modules/@webassemblyjs/helper-wasm-section": { + "version": "1.12.1", + "resolved": "https://registry.npmjs.org/@webassemblyjs/helper-wasm-section/-/helper-wasm-section-1.12.1.tgz", + "integrity": "sha512-Jif4vfB6FJlUlSbgEMHUyk1j234GTNG9dBJ4XJdOySoj518Xj0oGsNi59cUQF4RRMS9ouBUxDDdyBVfPTypa5g==", + "dev": true, + "dependencies": { + "@webassemblyjs/ast": "1.12.1", + "@webassemblyjs/helper-buffer": "1.12.1", + "@webassemblyjs/helper-wasm-bytecode": "1.11.6", + "@webassemblyjs/wasm-gen": "1.12.1" + } + }, + "node_modules/@webassemblyjs/ieee754": { + "version": "1.11.6", + "resolved": "https://registry.npmjs.org/@webassemblyjs/ieee754/-/ieee754-1.11.6.tgz", + "integrity": "sha512-LM4p2csPNvbij6U1f19v6WR56QZ8JcHg3QIJTlSwzFcmx6WSORicYj6I63f9yU1kEUtrpG+kjkiIAkevHpDXrg==", + "dev": true, + "dependencies": { + "@xtuc/ieee754": "^1.2.0" + } + }, + "node_modules/@webassemblyjs/leb128": { + "version": "1.11.6", + "resolved": "https://registry.npmjs.org/@webassemblyjs/leb128/-/leb128-1.11.6.tgz", + "integrity": "sha512-m7a0FhE67DQXgouf1tbN5XQcdWoNgaAuoULHIfGFIEVKA6tu/edls6XnIlkmS6FrXAquJRPni3ZZKjw6FSPjPQ==", + "dev": true, + "dependencies": { + "@xtuc/long": "4.2.2" + } + }, + "node_modules/@webassemblyjs/utf8": { + "version": "1.11.6", + "resolved": "https://registry.npmjs.org/@webassemblyjs/utf8/-/utf8-1.11.6.tgz", + "integrity": "sha512-vtXf2wTQ3+up9Zsg8sa2yWiQpzSsMyXj0qViVP6xKGCUT8p8YJ6HqI7l5eCnWx1T/FYdsv07HQs2wTFbbof/RA==", + "dev": true + }, + "node_modules/@webassemblyjs/wasm-edit": { + "version": "1.12.1", + "resolved": "https://registry.npmjs.org/@webassemblyjs/wasm-edit/-/wasm-edit-1.12.1.tgz", + "integrity": "sha512-1DuwbVvADvS5mGnXbE+c9NfA8QRcZ6iKquqjjmR10k6o+zzsRVesil54DKexiowcFCPdr/Q0qaMgB01+SQ1u6g==", + "dev": true, + "dependencies": { + "@webassemblyjs/ast": "1.12.1", + "@webassemblyjs/helper-buffer": "1.12.1", + "@webassemblyjs/helper-wasm-bytecode": "1.11.6", + "@webassemblyjs/helper-wasm-section": "1.12.1", + "@webassemblyjs/wasm-gen": "1.12.1", + "@webassemblyjs/wasm-opt": "1.12.1", + "@webassemblyjs/wasm-parser": "1.12.1", + "@webassemblyjs/wast-printer": "1.12.1" + } + }, + "node_modules/@webassemblyjs/wasm-gen": { + "version": "1.12.1", + "resolved": "https://registry.npmjs.org/@webassemblyjs/wasm-gen/-/wasm-gen-1.12.1.tgz", + "integrity": "sha512-TDq4Ojh9fcohAw6OIMXqiIcTq5KUXTGRkVxbSo1hQnSy6lAM5GSdfwWeSxpAo0YzgsgF182E/U0mDNhuA0tW7w==", + "dev": true, + "dependencies": { + "@webassemblyjs/ast": "1.12.1", + "@webassemblyjs/helper-wasm-bytecode": "1.11.6", + "@webassemblyjs/ieee754": "1.11.6", + "@webassemblyjs/leb128": "1.11.6", + "@webassemblyjs/utf8": "1.11.6" + } + }, + "node_modules/@webassemblyjs/wasm-opt": { + "version": "1.12.1", + "resolved": "https://registry.npmjs.org/@webassemblyjs/wasm-opt/-/wasm-opt-1.12.1.tgz", + "integrity": "sha512-Jg99j/2gG2iaz3hijw857AVYekZe2SAskcqlWIZXjji5WStnOpVoat3gQfT/Q5tb2djnCjBtMocY/Su1GfxPBg==", + "dev": true, + "dependencies": { + "@webassemblyjs/ast": "1.12.1", + "@webassemblyjs/helper-buffer": "1.12.1", + "@webassemblyjs/wasm-gen": "1.12.1", + "@webassemblyjs/wasm-parser": "1.12.1" + } + }, + "node_modules/@webassemblyjs/wasm-parser": { + "version": "1.12.1", + "resolved": "https://registry.npmjs.org/@webassemblyjs/wasm-parser/-/wasm-parser-1.12.1.tgz", + "integrity": "sha512-xikIi7c2FHXysxXe3COrVUPSheuBtpcfhbpFj4gmu7KRLYOzANztwUU0IbsqvMqzuNK2+glRGWCEqZo1WCLyAQ==", + "dev": true, + "dependencies": { + "@webassemblyjs/ast": "1.12.1", + "@webassemblyjs/helper-api-error": "1.11.6", + "@webassemblyjs/helper-wasm-bytecode": "1.11.6", + "@webassemblyjs/ieee754": "1.11.6", + "@webassemblyjs/leb128": "1.11.6", + "@webassemblyjs/utf8": "1.11.6" + } + }, + "node_modules/@webassemblyjs/wast-printer": { + "version": "1.12.1", + "resolved": "https://registry.npmjs.org/@webassemblyjs/wast-printer/-/wast-printer-1.12.1.tgz", + "integrity": "sha512-+X4WAlOisVWQMikjbcvY2e0rwPsKQ9F688lksZhBcPycBBuii3O7m8FACbDMWDojpAqvjIncrG8J0XHKyQfVeA==", + "dev": true, + "dependencies": { + "@webassemblyjs/ast": "1.12.1", + "@xtuc/long": "4.2.2" + } + }, + "node_modules/@webpack-cli/configtest": { + "version": "2.1.1", + "resolved": "https://registry.npmjs.org/@webpack-cli/configtest/-/configtest-2.1.1.tgz", + "integrity": "sha512-wy0mglZpDSiSS0XHrVR+BAdId2+yxPSoJW8fsna3ZpYSlufjvxnP4YbKTCBZnNIcGN4r6ZPXV55X4mYExOfLmw==", + "dev": true, + "engines": { + "node": ">=14.15.0" + }, + "peerDependencies": { + "webpack": "5.x.x", + "webpack-cli": "5.x.x" + } + }, + "node_modules/@webpack-cli/info": { + "version": "2.0.2", + "resolved": "https://registry.npmjs.org/@webpack-cli/info/-/info-2.0.2.tgz", + "integrity": "sha512-zLHQdI/Qs1UyT5UBdWNqsARasIA+AaF8t+4u2aS2nEpBQh2mWIVb8qAklq0eUENnC5mOItrIB4LiS9xMtph18A==", + "dev": true, + "engines": { + "node": ">=14.15.0" + }, + "peerDependencies": { + "webpack": "5.x.x", + "webpack-cli": "5.x.x" + } + }, + "node_modules/@webpack-cli/serve": { + "version": "2.0.5", + "resolved": "https://registry.npmjs.org/@webpack-cli/serve/-/serve-2.0.5.tgz", + "integrity": "sha512-lqaoKnRYBdo1UgDX8uF24AfGMifWK19TxPmM5FHc2vAGxrJ/qtyUyFBWoY1tISZdelsQ5fBcOusifo5o5wSJxQ==", + "dev": true, + "engines": { + "node": ">=14.15.0" + }, + "peerDependencies": { + "webpack": "5.x.x", + "webpack-cli": "5.x.x" + }, + "peerDependenciesMeta": { + "webpack-dev-server": { + "optional": true + } + } + }, + "node_modules/@xtuc/ieee754": { + "version": "1.2.0", + "resolved": "https://registry.npmjs.org/@xtuc/ieee754/-/ieee754-1.2.0.tgz", + "integrity": "sha512-DX8nKgqcGwsc0eJSqYt5lwP4DH5FlHnmuWWBRy7X0NcaGR0ZtuyeESgMwTYVEtxmsNGY+qit4QYT/MIYTOTPeA==", + "dev": true + }, + "node_modules/@xtuc/long": { + "version": "4.2.2", + "resolved": "https://registry.npmjs.org/@xtuc/long/-/long-4.2.2.tgz", + "integrity": "sha512-NuHqBY1PB/D8xU6s/thBgOAiAP7HOYDQ32+BFZILJ8ivkUkAHQnWfn6WhL79Owj1qmUnoN/YPhktdIoucipkAQ==", + "dev": true + }, + "node_modules/abbrev": { + "version": "1.1.1", + "resolved": "https://registry.npmjs.org/abbrev/-/abbrev-1.1.1.tgz", + "integrity": "sha512-nne9/IiQ/hzIhY6pdDnbBtz7DjPTKrY00P/zvPSm5pOFkl6xuGrGnXn/VtTNNfNtAfZ9/1RtehkszU9qcTii0Q==" + }, + "node_modules/accepts": { + "version": "1.3.8", + "resolved": "https://registry.npmjs.org/accepts/-/accepts-1.3.8.tgz", + "integrity": "sha512-PYAthTa2m2VKxuvSD3DPC/Gy+U+sOA1LAuT8mkmRuvw+NACSaeXEQ+NHcVF7rONl6qcaxV3Uuemwawk+7+SJLw==", + "dev": true, + "dependencies": { + "mime-types": "~2.1.34", + "negotiator": "0.6.3" + }, + "engines": { + "node": ">= 0.6" + } + }, + "node_modules/acorn": { + "version": "8.12.1", + "resolved": "https://registry.npmjs.org/acorn/-/acorn-8.12.1.tgz", + "integrity": "sha512-tcpGyI9zbizT9JbV6oYE477V6mTlXvvi0T0G3SNIYE2apm/G5huBa1+K89VGeovbg+jycCrfhl3ADxErOuO6Jg==", + "dev": true, + "bin": { + "acorn": "bin/acorn" + }, + "engines": { + "node": ">=0.4.0" + } + }, + "node_modules/acorn-import-attributes": { + "version": "1.9.5", + "resolved": "https://registry.npmjs.org/acorn-import-attributes/-/acorn-import-attributes-1.9.5.tgz", + "integrity": "sha512-n02Vykv5uA3eHGM/Z2dQrcD56kL8TyDb2p1+0P83PClMnC/nc+anbQRhIOWnSq4Ke/KvDPrY3C9hDtC/A3eHnQ==", + "dev": true, + "peerDependencies": { + "acorn": "^8" + } + }, + "node_modules/ajv": { + "version": "6.12.6", + "resolved": "https://registry.npmjs.org/ajv/-/ajv-6.12.6.tgz", + "integrity": "sha512-j3fVLgvTo527anyYyJOGTYJbG+vnnQYvE0m5mmkc1TK+nxAppkCLMIL0aZ4dblVCNoGShhm+kzE4ZUykBoMg4g==", + "dev": true, + "dependencies": { + "fast-deep-equal": "^3.1.1", + "fast-json-stable-stringify": "^2.0.0", + "json-schema-traverse": "^0.4.1", + "uri-js": "^4.2.2" + }, + "funding": { + "type": "github", + "url": "https://github.com/sponsors/epoberezkin" + } + }, + "node_modules/ajv-formats": { + "version": "2.1.1", + "resolved": "https://registry.npmjs.org/ajv-formats/-/ajv-formats-2.1.1.tgz", + "integrity": "sha512-Wx0Kx52hxE7C18hkMEggYlEifqWZtYaRgouJor+WMdPnQyEK13vgEWyVNup7SoeeoLMsr4kf5h6dOW11I15MUA==", + "dev": true, + "dependencies": { + "ajv": "^8.0.0" + }, + "peerDependencies": { + "ajv": "^8.0.0" + }, + "peerDependenciesMeta": { + "ajv": { + "optional": true + } + } + }, + "node_modules/ajv-formats/node_modules/ajv": { + "version": "8.16.0", + "resolved": "https://registry.npmjs.org/ajv/-/ajv-8.16.0.tgz", + "integrity": "sha512-F0twR8U1ZU67JIEtekUcLkXkoO5mMMmgGD8sK/xUFzJ805jxHQl92hImFAqqXMyMYjSPOyUPAwHYhB72g5sTXw==", + "dev": true, + "dependencies": { + "fast-deep-equal": "^3.1.3", + "json-schema-traverse": "^1.0.0", + "require-from-string": "^2.0.2", + "uri-js": "^4.4.1" + }, + "funding": { + "type": "github", + "url": "https://github.com/sponsors/epoberezkin" + } + }, + "node_modules/ajv-formats/node_modules/json-schema-traverse": { + "version": "1.0.0", + "resolved": "https://registry.npmjs.org/json-schema-traverse/-/json-schema-traverse-1.0.0.tgz", + "integrity": "sha512-NM8/P9n3XjXhIZn1lLhkFaACTOURQXjWhV4BA/RnOv8xvgqtqpAX9IO4mRQxSx1Rlo4tqzeqb0sOlruaOy3dug==", + "dev": true + }, + "node_modules/ajv-keywords": { + "version": "3.5.2", + "resolved": "https://registry.npmjs.org/ajv-keywords/-/ajv-keywords-3.5.2.tgz", + "integrity": "sha512-5p6WTN0DdTGVQk6VjcEju19IgaHudalcfabD7yhDGeA6bcQnmL+CpveLJq/3hvfwd1aof6L386Ougkx6RfyMIQ==", + "dev": true, + "peerDependencies": { + "ajv": "^6.9.1" + } + }, + "node_modules/algoliasearch": { + "version": "4.24.0", + "resolved": "https://registry.npmjs.org/algoliasearch/-/algoliasearch-4.24.0.tgz", + "integrity": "sha512-bf0QV/9jVejssFBmz2HQLxUadxk574t4iwjCKp5E7NBzwKkrDEhKPISIIjAU/p6K5qDx3qoeh4+26zWN1jmw3g==", + "peer": true, + "dependencies": { + "@algolia/cache-browser-local-storage": "4.24.0", + "@algolia/cache-common": "4.24.0", + "@algolia/cache-in-memory": "4.24.0", + "@algolia/client-account": "4.24.0", + "@algolia/client-analytics": "4.24.0", + "@algolia/client-common": "4.24.0", + "@algolia/client-personalization": "4.24.0", + "@algolia/client-search": "4.24.0", + "@algolia/logger-common": "4.24.0", + "@algolia/logger-console": "4.24.0", + "@algolia/recommend": "4.24.0", + "@algolia/requester-browser-xhr": "4.24.0", + "@algolia/requester-common": "4.24.0", + "@algolia/requester-node-http": "4.24.0", + "@algolia/transporter": "4.24.0" + } + }, + "node_modules/algoliasearch-helper": { + "version": "3.22.2", + "resolved": "https://registry.npmjs.org/algoliasearch-helper/-/algoliasearch-helper-3.22.2.tgz", + "integrity": "sha512-3YQ6eo7uYOCHeQ2ZpD+OoT3aJJwMNKEnwtu8WMzm81XmBOSCwRjQditH9CeSOQ38qhHkuGw23pbq+kULkIJLcw==", + "dependencies": { + "@algolia/events": "^4.0.1" + }, + "peerDependencies": { + "algoliasearch": ">= 3.1 < 6" + } + }, + "node_modules/ansi-html-community": { + "version": "0.0.8", + "resolved": "https://registry.npmjs.org/ansi-html-community/-/ansi-html-community-0.0.8.tgz", + "integrity": "sha512-1APHAyr3+PCamwNw3bXCPp4HFLONZt/yIH0sZp0/469KWNTEy+qN5jQ3GVX6DMZ1UXAi34yVwtTeaG/HpBuuzw==", + "dev": true, + "engines": [ + "node >= 0.8.0" + ], + "bin": { + "ansi-html": "bin/ansi-html" + } + }, + "node_modules/ansi-regex": { + "version": "6.0.1", + "resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-6.0.1.tgz", + "integrity": "sha512-n5M855fKb2SsfMIiFFoVrABHJC8QtHwVx+mHWP3QcEqBHYienj5dHSgjbxtC0WEZXYt4wcD6zrQElDPhFuZgfA==", + "dev": true, + "engines": { + "node": ">=12" + }, + "funding": { + "url": "https://github.com/chalk/ansi-regex?sponsor=1" + } + }, + "node_modules/ansi-styles": { + "version": "6.2.1", + "resolved": "https://registry.npmjs.org/ansi-styles/-/ansi-styles-6.2.1.tgz", + "integrity": "sha512-bN798gFfQX+viw3R7yrGWRqnrN2oRkEkUjjl4JNn4E8GxxbjtG3FbrEIIY3l8/hrwUwIeCZvi4QuOTP4MErVug==", + "dev": true, + "engines": { + "node": ">=12" + }, + "funding": { + "url": "https://github.com/chalk/ansi-styles?sponsor=1" + } + }, + "node_modules/anymatch": { + "version": "3.1.3", + "resolved": "https://registry.npmjs.org/anymatch/-/anymatch-3.1.3.tgz", + "integrity": "sha512-KMReFUr0B4t+D+OBkjR3KYqvocp2XaSzO55UcB6mgQMd3KbcE+mWTyvVV7D/zsdEbNnV6acZUutkiHQXvTr1Rw==", + "dev": true, + "dependencies": { + "normalize-path": "^3.0.0", + "picomatch": "^2.0.4" + }, + "engines": { + "node": ">= 8" + } + }, + "node_modules/array-flatten": { + "version": "1.1.1", + "resolved": "https://registry.npmjs.org/array-flatten/-/array-flatten-1.1.1.tgz", + "integrity": "sha512-PCVAQswWemu6UdxsDFFX/+gVeYqKAod3D3UVm91jHwynguOwAvYPhx8nNlM++NqRcK6CxxpUafjmhIdKiHibqg==", + "dev": true + }, + "node_modules/asynckit": { + "version": "0.4.0", + "resolved": "https://registry.npmjs.org/asynckit/-/asynckit-0.4.0.tgz", + "integrity": "sha512-Oei9OH4tRh0YqU3GxhX79dM/mwVgvbZJaSNaRk+bshkj0S5cfHcgYakreBjrHwatXKbz+IoIdYLxrKim2MjW0Q==" + }, + "node_modules/axios": { + "version": "1.7.2", + "resolved": "https://registry.npmjs.org/axios/-/axios-1.7.2.tgz", + "integrity": "sha512-2A8QhOMrbomlDuiLeK9XibIBzuHeRcqqNOHp0Cyp5EoJ1IFDh+XZH3A6BkXtv0K4gFGCI0Y4BM7B1wOEi0Rmgw==", + "dependencies": { + "follow-redirects": "^1.15.6", + "form-data": "^4.0.0", + "proxy-from-env": "^1.1.0" + } + }, + "node_modules/balanced-match": { + "version": "1.0.2", + "resolved": "https://registry.npmjs.org/balanced-match/-/balanced-match-1.0.2.tgz", + "integrity": "sha512-3oSeUO0TMV67hN1AmbXsK4yaqU7tjiHlbxRDZOpH0KW9+CeX4bRAaX0Anxt0tx2MrpRpWwQaPwIlISEJhYU5Pw==", + "dev": true + }, + "node_modules/batch": { + "version": "0.6.1", + "resolved": "https://registry.npmjs.org/batch/-/batch-0.6.1.tgz", + "integrity": "sha512-x+VAiMRL6UPkx+kudNvxTl6hB2XNNCG2r+7wixVfIYwu/2HKRXimwQyaumLjMveWvT2Hkd/cAJw+QBMfJ/EKVw==", + "dev": true + }, + "node_modules/binary-extensions": { + "version": "2.3.0", + "resolved": "https://registry.npmjs.org/binary-extensions/-/binary-extensions-2.3.0.tgz", + "integrity": "sha512-Ceh+7ox5qe7LJuLHoY0feh3pHuUDHAcRUeyL2VYghZwfpkNIy/+8Ocg0a3UuSoYzavmylwuLWQOf3hl0jjMMIw==", + "dev": true, + "engines": { + "node": ">=8" + }, + "funding": { + "url": "https://github.com/sponsors/sindresorhus" + } + }, + "node_modules/body-parser": { + "version": "1.20.2", + "resolved": "https://registry.npmjs.org/body-parser/-/body-parser-1.20.2.tgz", + "integrity": "sha512-ml9pReCu3M61kGlqoTm2umSXTlRTuGTx0bfYj+uIUKKYycG5NtSbeetV3faSU6R7ajOPw0g/J1PvK4qNy7s5bA==", + "dev": true, + "dependencies": { + "bytes": "3.1.2", + "content-type": "~1.0.5", + "debug": "2.6.9", + "depd": "2.0.0", + "destroy": "1.2.0", + "http-errors": "2.0.0", + "iconv-lite": "0.4.24", + "on-finished": "2.4.1", + "qs": "6.11.0", + "raw-body": "2.5.2", + "type-is": "~1.6.18", + "unpipe": "1.0.0" + }, + "engines": { + "node": ">= 0.8", + "npm": "1.2.8000 || >= 1.4.16" + } + }, + "node_modules/body-parser/node_modules/bytes": { + "version": "3.1.2", + "resolved": "https://registry.npmjs.org/bytes/-/bytes-3.1.2.tgz", + "integrity": "sha512-/Nf7TyzTx6S3yRJObOAV7956r8cr2+Oj8AC5dt8wSP3BQAoeX58NoHyCU8P8zGkNXStjTSi6fzO6F0pBdcYbEg==", + "dev": true, + "engines": { + "node": ">= 0.8" + } + }, + "node_modules/body-parser/node_modules/qs": { + "version": "6.11.0", + "resolved": "https://registry.npmjs.org/qs/-/qs-6.11.0.tgz", + "integrity": "sha512-MvjoMCJwEarSbUYk5O+nmoSzSutSsTwF85zcHPQ9OrlFoZOYIjaqBAJIqIXjptyD5vThxGq52Xu/MaJzRkIk4Q==", + "dev": true, + "dependencies": { + "side-channel": "^1.0.4" + }, + "engines": { + "node": ">=0.6" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/bonjour-service": { + "version": "1.2.1", + "resolved": "https://registry.npmjs.org/bonjour-service/-/bonjour-service-1.2.1.tgz", + "integrity": "sha512-oSzCS2zV14bh2kji6vNe7vrpJYCHGvcZnlffFQ1MEoX/WOeQ/teD8SYWKR942OI3INjq8OMNJlbPK5LLLUxFDw==", + "dev": true, + "dependencies": { + "fast-deep-equal": "^3.1.3", + "multicast-dns": "^7.2.5" + } + }, + "node_modules/brace-expansion": { + "version": "2.0.1", + "resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-2.0.1.tgz", + "integrity": "sha512-XnAIvQ8eM+kC6aULx6wuQiwVsnzsi9d3WxzV3FpWTGA19F621kwdbsAcFKXgKUHZWsy+mY6iL1sHTxWEFCytDA==", + "dev": true, + "dependencies": { + "balanced-match": "^1.0.0" + } + }, + "node_modules/braces": { + "version": "3.0.3", + "resolved": "https://registry.npmjs.org/braces/-/braces-3.0.3.tgz", + "integrity": "sha512-yQbXgO/OSZVD2IsiLlro+7Hf6Q18EJrKSEsdoMzKePKXct3gvD8oLcOQdIzGupr5Fj+EDe8gO/lxc1BzfMpxvA==", + "dev": true, + "dependencies": { + "fill-range": "^7.1.1" + }, + "engines": { + "node": ">=8" + } + }, + "node_modules/browserslist": { + "version": "4.23.2", + "resolved": "https://registry.npmjs.org/browserslist/-/browserslist-4.23.2.tgz", + "integrity": "sha512-qkqSyistMYdxAcw+CzbZwlBy8AGmS/eEWs+sEV5TnLRGDOL+C5M2EnH6tlZyg0YoAxGJAFKh61En9BR941GnHA==", + "dev": true, + "funding": [ + { + "type": "opencollective", + "url": "https://opencollective.com/browserslist" + }, + { + "type": "tidelift", + "url": "https://tidelift.com/funding/github/npm/browserslist" + }, + { + "type": "github", + "url": "https://github.com/sponsors/ai" + } + ], + "dependencies": { + "caniuse-lite": "^1.0.30001640", + "electron-to-chromium": "^1.4.820", + "node-releases": "^2.0.14", + "update-browserslist-db": "^1.1.0" + }, + "bin": { + "browserslist": "cli.js" + }, + "engines": { + "node": "^6 || ^7 || ^8 || ^9 || ^10 || ^11 || ^12 || >=13.7" + } + }, + "node_modules/buffer-from": { + "version": "1.1.2", + "resolved": "https://registry.npmjs.org/buffer-from/-/buffer-from-1.1.2.tgz", + "integrity": "sha512-E+XQCRwSbaaiChtv6k6Dwgc+bx+Bs6vuKJHHl5kox/BaKbhiXzqQOwK4cO22yElGp2OCmjwVhT3HmxgyPGnJfQ==", + "dev": true + }, + "node_modules/bundle-name": { + "version": "4.1.0", + "resolved": "https://registry.npmjs.org/bundle-name/-/bundle-name-4.1.0.tgz", + "integrity": "sha512-tjwM5exMg6BGRI+kNmTntNsvdZS1X8BFYS6tnJ2hdH0kVxM6/eVZ2xy+FqStSWvYmtfFMDLIxurorHwDKfDz5Q==", + "dev": true, + "dependencies": { + "run-applescript": "^7.0.0" + }, + "engines": { + "node": ">=18" + }, + "funding": { + "url": "https://github.com/sponsors/sindresorhus" + } + }, + "node_modules/bytes": { + "version": "3.0.0", + "resolved": "https://registry.npmjs.org/bytes/-/bytes-3.0.0.tgz", + "integrity": "sha512-pMhOfFDPiv9t5jjIXkHosWmkSyQbvsgEVNkz0ERHbuLh2T/7j4Mqqpz523Fe8MVY89KC6Sh/QfS2sM+SjgFDcw==", + "dev": true, + "engines": { + "node": ">= 0.8" + } + }, + "node_modules/call-bind": { + "version": "1.0.7", + "resolved": "https://registry.npmjs.org/call-bind/-/call-bind-1.0.7.tgz", + "integrity": "sha512-GHTSNSYICQ7scH7sZ+M2rFopRoLh8t2bLSW6BbgrtLsahOIB5iyAVJf9GjWK3cYTDaMj4XdBpM1cA6pIS0Kv2w==", + "dev": true, + "dependencies": { + "es-define-property": "^1.0.0", + "es-errors": "^1.3.0", + "function-bind": "^1.1.2", + "get-intrinsic": "^1.2.4", + "set-function-length": "^1.2.1" + }, + "engines": { + "node": ">= 0.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/caniuse-lite": { + "version": "1.0.30001641", + "resolved": "https://registry.npmjs.org/caniuse-lite/-/caniuse-lite-1.0.30001641.tgz", + "integrity": "sha512-Phv5thgl67bHYo1TtMY/MurjkHhV4EDaCosezRXgZ8jzA/Ub+wjxAvbGvjoFENStinwi5kCyOYV3mi5tOGykwA==", + "dev": true, + "funding": [ + { + "type": "opencollective", + "url": "https://opencollective.com/browserslist" + }, + { + "type": "tidelift", + "url": "https://tidelift.com/funding/github/npm/caniuse-lite" + }, + { + "type": "github", + "url": "https://github.com/sponsors/ai" + } + ] + }, + "node_modules/chokidar": { + "version": "3.6.0", + "resolved": "https://registry.npmjs.org/chokidar/-/chokidar-3.6.0.tgz", + "integrity": "sha512-7VT13fmjotKpGipCW9JEQAusEPE+Ei8nl6/g4FBAmIm0GOOLMua9NDDo/DWp0ZAxCr3cPq5ZpBqmPAQgDda2Pw==", + "dev": true, + "dependencies": { + "anymatch": "~3.1.2", + "braces": "~3.0.2", + "glob-parent": "~5.1.2", + "is-binary-path": "~2.1.0", + "is-glob": "~4.0.1", + "normalize-path": "~3.0.0", + "readdirp": "~3.6.0" + }, + "engines": { + "node": ">= 8.10.0" + }, + "funding": { + "url": "https://paulmillr.com/funding/" + }, + "optionalDependencies": { + "fsevents": "~2.3.2" + } + }, + "node_modules/chokidar/node_modules/glob-parent": { + "version": "5.1.2", + "resolved": "https://registry.npmjs.org/glob-parent/-/glob-parent-5.1.2.tgz", + "integrity": "sha512-AOIgSQCepiJYwP3ARnGx+5VnTu2HBYdzbGP45eLw1vr3zB3vZLeyed1sC9hnbcOc9/SrMyM5RPQrkGz4aS9Zow==", + "dev": true, + "dependencies": { + "is-glob": "^4.0.1" + }, + "engines": { + "node": ">= 6" + } + }, + "node_modules/chrome-trace-event": { + "version": "1.0.4", + "resolved": "https://registry.npmjs.org/chrome-trace-event/-/chrome-trace-event-1.0.4.tgz", + "integrity": "sha512-rNjApaLzuwaOTjCiT8lSDdGN1APCiqkChLMJxJPWLunPAt5fy8xgU9/jNOchV84wfIxrA0lRQB7oCT8jrn/wrQ==", + "dev": true, + "engines": { + "node": ">=6.0" + } + }, + "node_modules/clone-deep": { + "version": "4.0.1", + "resolved": "https://registry.npmjs.org/clone-deep/-/clone-deep-4.0.1.tgz", + "integrity": "sha512-neHB9xuzh/wk0dIHweyAXv2aPGZIVk3pLMe+/RNzINf17fe0OG96QroktYAUm7SM1PBnzTabaLboqqxDyMU+SQ==", + "dev": true, + "dependencies": { + "is-plain-object": "^2.0.4", + "kind-of": "^6.0.2", + "shallow-clone": "^3.0.0" + }, + "engines": { + "node": ">=6" + } + }, + "node_modules/color-convert": { + "version": "2.0.1", + "resolved": "https://registry.npmjs.org/color-convert/-/color-convert-2.0.1.tgz", + "integrity": "sha512-RRECPsj7iu/xb5oKYcsFHSppFNnsj/52OVTRKb4zP5onXwVF3zVmmToNcOfGC+CRDpfK/U584fMg38ZHCaElKQ==", + "dev": true, + "dependencies": { + "color-name": "~1.1.4" + }, + "engines": { + "node": ">=7.0.0" + } + }, + "node_modules/color-name": { + "version": "1.1.4", + "resolved": "https://registry.npmjs.org/color-name/-/color-name-1.1.4.tgz", + "integrity": "sha512-dOy+3AuW3a2wNbZHIuMZpTcgjGuLU/uBL/ubcZF9OXbDo8ff4O8yVp5Bf0efS8uEoYo5q4Fx7dY9OgQGXgAsQA==", + "dev": true + }, + "node_modules/colorette": { + "version": "2.0.20", + "resolved": "https://registry.npmjs.org/colorette/-/colorette-2.0.20.tgz", + "integrity": "sha512-IfEDxwoWIjkeXL1eXcDiow4UbKjhLdq6/EuSVR9GMN7KVH3r9gQ83e73hsz1Nd1T3ijd5xv1wcWRYO+D6kCI2w==", + "dev": true + }, + "node_modules/combined-stream": { + "version": "1.0.8", + "resolved": "https://registry.npmjs.org/combined-stream/-/combined-stream-1.0.8.tgz", + "integrity": "sha512-FQN4MRfuJeHf7cBbBMJFXhKSDq+2kAArBlmRBvcvFE5BB1HZKXtSFASDhdlz9zOYwxh8lDdnvmMOe/+5cdoEdg==", + "dependencies": { + "delayed-stream": "~1.0.0" + }, + "engines": { + "node": ">= 0.8" + } + }, + "node_modules/commander": { + "version": "2.20.3", + "resolved": "https://registry.npmjs.org/commander/-/commander-2.20.3.tgz", + "integrity": "sha512-GpVkmM8vF2vQUkj2LvZmD35JxeJOLCwJ9cUkugyk2nuhbv3+mJvpLYYt+0+USMxE+oj+ey/lJEnhZw75x/OMcQ==", + "dev": true + }, + "node_modules/compressible": { + "version": "2.0.18", + "resolved": "https://registry.npmjs.org/compressible/-/compressible-2.0.18.tgz", + "integrity": "sha512-AF3r7P5dWxL8MxyITRMlORQNaOA2IkAFaTr4k7BUumjPtRpGDTZpl0Pb1XCO6JeDCBdp126Cgs9sMxqSjgYyRg==", + "dev": true, + "dependencies": { + "mime-db": ">= 1.43.0 < 2" + }, + "engines": { + "node": ">= 0.6" + } + }, + "node_modules/compression": { + "version": "1.7.4", + "resolved": "https://registry.npmjs.org/compression/-/compression-1.7.4.tgz", + "integrity": "sha512-jaSIDzP9pZVS4ZfQ+TzvtiWhdpFhE2RDHz8QJkpX9SIpLq88VueF5jJw6t+6CUQcAoA6t+x89MLrWAqpfDE8iQ==", + "dev": true, + "dependencies": { + "accepts": "~1.3.5", + "bytes": "3.0.0", + "compressible": "~2.0.16", + "debug": "2.6.9", + "on-headers": "~1.0.2", + "safe-buffer": "5.1.2", + "vary": "~1.1.2" + }, + "engines": { + "node": ">= 0.8.0" + } + }, + "node_modules/compression/node_modules/safe-buffer": { + "version": "5.1.2", + "resolved": "https://registry.npmjs.org/safe-buffer/-/safe-buffer-5.1.2.tgz", + "integrity": "sha512-Gd2UZBJDkXlY7GbJxfsE8/nvKkUEU1G38c1siN6QP6a9PT9MmHB8GnpscSmMJSoF8LOIrt8ud/wPtojys4G6+g==", + "dev": true + }, + "node_modules/connect-history-api-fallback": { + "version": "2.0.0", + "resolved": "https://registry.npmjs.org/connect-history-api-fallback/-/connect-history-api-fallback-2.0.0.tgz", + "integrity": "sha512-U73+6lQFmfiNPrYbXqr6kZ1i1wiRqXnp2nhMsINseWXO8lDau0LGEffJ8kQi4EjLZympVgRdvqjAgiZ1tgzDDA==", + "dev": true, + "engines": { + "node": ">=0.8" + } + }, + "node_modules/content-disposition": { + "version": "0.5.4", + "resolved": "https://registry.npmjs.org/content-disposition/-/content-disposition-0.5.4.tgz", + "integrity": "sha512-FveZTNuGw04cxlAiWbzi6zTAL/lhehaWbTtgluJh4/E95DqMwTmha3KZN1aAWA8cFIhHzMZUvLevkw5Rqk+tSQ==", + "dev": true, + "dependencies": { + "safe-buffer": "5.2.1" + }, + "engines": { + "node": ">= 0.6" + } + }, + "node_modules/content-type": { + "version": "1.0.5", + "resolved": "https://registry.npmjs.org/content-type/-/content-type-1.0.5.tgz", + "integrity": "sha512-nTjqfcBFEipKdXCv4YDQWCfmcLZKm81ldF0pAopTvyrFGVbcR6P/VAAd5G7N+0tTr8QqiU0tFadD6FK4NtJwOA==", + "dev": true, + "engines": { + "node": ">= 0.6" + } + }, + "node_modules/cookie": { + "version": "0.6.0", + "resolved": "https://registry.npmjs.org/cookie/-/cookie-0.6.0.tgz", + "integrity": "sha512-U71cyTamuh1CRNCfpGY6to28lxvNwPG4Guz/EVjgf3Jmzv0vlDp1atT9eS5dDjMYHucpHbWns6Lwf3BKz6svdw==", + "dev": true, + "engines": { + "node": ">= 0.6" + } + }, + "node_modules/cookie-signature": { + "version": "1.0.6", + "resolved": "https://registry.npmjs.org/cookie-signature/-/cookie-signature-1.0.6.tgz", + "integrity": "sha512-QADzlaHc8icV8I7vbaJXJwod9HWYp8uCqf1xa4OfNu1T7JVxQIrUgOWtHdNDtPiywmFbiS12VjotIXLrKM3orQ==", + "dev": true + }, + "node_modules/copy-webpack-plugin": { + "version": "12.0.2", + "resolved": "https://registry.npmjs.org/copy-webpack-plugin/-/copy-webpack-plugin-12.0.2.tgz", + "integrity": "sha512-SNwdBeHyII+rWvee/bTnAYyO8vfVdcSTud4EIb6jcZ8inLeWucJE0DnxXQBjlQ5zlteuuvooGQy3LIyGxhvlOA==", + "dev": true, + "dependencies": { + "fast-glob": "^3.3.2", + "glob-parent": "^6.0.1", + "globby": "^14.0.0", + "normalize-path": "^3.0.0", + "schema-utils": "^4.2.0", + "serialize-javascript": "^6.0.2" + }, + "engines": { + "node": ">= 18.12.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/webpack" + }, + "peerDependencies": { + "webpack": "^5.1.0" + } + }, + "node_modules/copy-webpack-plugin/node_modules/ajv": { + "version": "8.16.0", + "resolved": "https://registry.npmjs.org/ajv/-/ajv-8.16.0.tgz", + "integrity": "sha512-F0twR8U1ZU67JIEtekUcLkXkoO5mMMmgGD8sK/xUFzJ805jxHQl92hImFAqqXMyMYjSPOyUPAwHYhB72g5sTXw==", + "dev": true, + "dependencies": { + "fast-deep-equal": "^3.1.3", + "json-schema-traverse": "^1.0.0", + "require-from-string": "^2.0.2", + "uri-js": "^4.4.1" + }, + "funding": { + "type": "github", + "url": "https://github.com/sponsors/epoberezkin" + } + }, + "node_modules/copy-webpack-plugin/node_modules/ajv-keywords": { + "version": "5.1.0", + "resolved": "https://registry.npmjs.org/ajv-keywords/-/ajv-keywords-5.1.0.tgz", + "integrity": "sha512-YCS/JNFAUyr5vAuhk1DWm1CBxRHW9LbJ2ozWeemrIqpbsqKjHVxYPyi5GC0rjZIT5JxJ3virVTS8wk4i/Z+krw==", + "dev": true, + "dependencies": { + "fast-deep-equal": "^3.1.3" + }, + "peerDependencies": { + "ajv": "^8.8.2" + } + }, + "node_modules/copy-webpack-plugin/node_modules/json-schema-traverse": { + "version": "1.0.0", + "resolved": "https://registry.npmjs.org/json-schema-traverse/-/json-schema-traverse-1.0.0.tgz", + "integrity": "sha512-NM8/P9n3XjXhIZn1lLhkFaACTOURQXjWhV4BA/RnOv8xvgqtqpAX9IO4mRQxSx1Rlo4tqzeqb0sOlruaOy3dug==", + "dev": true + }, + "node_modules/copy-webpack-plugin/node_modules/schema-utils": { + "version": "4.2.0", + "resolved": "https://registry.npmjs.org/schema-utils/-/schema-utils-4.2.0.tgz", + "integrity": "sha512-L0jRsrPpjdckP3oPug3/VxNKt2trR8TcabrM6FOAAlvC/9Phcmm+cuAgTlxBqdBR1WJx7Naj9WHw+aOmheSVbw==", + "dev": true, + "dependencies": { + "@types/json-schema": "^7.0.9", + "ajv": "^8.9.0", + "ajv-formats": "^2.1.1", + "ajv-keywords": "^5.1.0" + }, + "engines": { + "node": ">= 12.13.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/webpack" + } + }, + "node_modules/core-util-is": { + "version": "1.0.3", + "resolved": "https://registry.npmjs.org/core-util-is/-/core-util-is-1.0.3.tgz", + "integrity": "sha512-ZQBvi1DcpJ4GDqanjucZ2Hj3wEO5pZDS89BWbkcrvdxksJorwUDDZamX9ldFkp9aw2lmBDLgkObEA4DWNJ9FYQ==", + "dev": true + }, + "node_modules/cross-spawn": { + "version": "7.0.3", + "resolved": "https://registry.npmjs.org/cross-spawn/-/cross-spawn-7.0.3.tgz", + "integrity": "sha512-iRDPJKUPVEND7dHPO8rkbOnPpyDygcDFtWjpeWNCgy8WP2rXcxXL8TskReQl6OrB2G7+UJrags1q15Fudc7G6w==", + "dev": true, + "dependencies": { + "path-key": "^3.1.0", + "shebang-command": "^2.0.0", + "which": "^2.0.1" + }, + "engines": { + "node": ">= 8" + } + }, + "node_modules/css-loader": { + "version": "7.1.2", + "resolved": "https://registry.npmjs.org/css-loader/-/css-loader-7.1.2.tgz", + "integrity": "sha512-6WvYYn7l/XEGN8Xu2vWFt9nVzrCn39vKyTEFf/ExEyoksJjjSZV/0/35XPlMbpnr6VGhZIUg5yJrL8tGfes/FA==", + "dev": true, + "dependencies": { + "icss-utils": "^5.1.0", + "postcss": "^8.4.33", + "postcss-modules-extract-imports": "^3.1.0", + "postcss-modules-local-by-default": "^4.0.5", + "postcss-modules-scope": "^3.2.0", + "postcss-modules-values": "^4.0.0", + "postcss-value-parser": "^4.2.0", + "semver": "^7.5.4" + }, + "engines": { + "node": ">= 18.12.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/webpack" + }, + "peerDependencies": { + "@rspack/core": "0.x || 1.x", + "webpack": "^5.27.0" + }, + "peerDependenciesMeta": { + "@rspack/core": { + "optional": true + }, + "webpack": { + "optional": true + } + } + }, + "node_modules/cssesc": { + "version": "3.0.0", + "resolved": "https://registry.npmjs.org/cssesc/-/cssesc-3.0.0.tgz", + "integrity": "sha512-/Tb/JcjK111nNScGob5MNtsntNM1aCNUDipB/TkwZFhyDrrE47SOx/18wF2bbjgc3ZzCSKW1T5nt5EbFoAz/Vg==", + "dev": true, + "bin": { + "cssesc": "bin/cssesc" + }, + "engines": { + "node": ">=4" + } + }, + "node_modules/debug": { + "version": "2.6.9", + "resolved": "https://registry.npmjs.org/debug/-/debug-2.6.9.tgz", + "integrity": "sha512-bC7ElrdJaJnPbAP+1EotYvqZsb3ecl5wi6Bfi6BJTUcNowp6cvspg0jXznRTKDjm/E7AdgFBVeAPVMNcKGsHMA==", + "dev": true, + "dependencies": { + "ms": "2.0.0" + } + }, + "node_modules/default-browser": { + "version": "5.2.1", + "resolved": "https://registry.npmjs.org/default-browser/-/default-browser-5.2.1.tgz", + "integrity": "sha512-WY/3TUME0x3KPYdRRxEJJvXRHV4PyPoUsxtZa78lwItwRQRHhd2U9xOscaT/YTf8uCXIAjeJOFBVEh/7FtD8Xg==", + "dev": true, + "dependencies": { + "bundle-name": "^4.1.0", + "default-browser-id": "^5.0.0" + }, + "engines": { + "node": ">=18" + }, + "funding": { + "url": "https://github.com/sponsors/sindresorhus" + } + }, + "node_modules/default-browser-id": { + "version": "5.0.0", + "resolved": "https://registry.npmjs.org/default-browser-id/-/default-browser-id-5.0.0.tgz", + "integrity": "sha512-A6p/pu/6fyBcA1TRz/GqWYPViplrftcW2gZC9q79ngNCKAeR/X3gcEdXQHl4KNXV+3wgIJ1CPkJQ3IHM6lcsyA==", + "dev": true, + "engines": { + "node": ">=18" + }, + "funding": { + "url": "https://github.com/sponsors/sindresorhus" + } + }, + "node_modules/default-gateway": { + "version": "6.0.3", + "resolved": "https://registry.npmjs.org/default-gateway/-/default-gateway-6.0.3.tgz", + "integrity": "sha512-fwSOJsbbNzZ/CUFpqFBqYfYNLj1NbMPm8MMCIzHjC83iSJRBEGmDUxU+WP661BaBQImeC2yHwXtz+P/O9o+XEg==", + "dev": true, + "dependencies": { + "execa": "^5.0.0" + }, + "engines": { + "node": ">= 10" + } + }, + "node_modules/define-data-property": { + "version": "1.1.4", + "resolved": "https://registry.npmjs.org/define-data-property/-/define-data-property-1.1.4.tgz", + "integrity": "sha512-rBMvIzlpA8v6E+SJZoo++HAYqsLrkg7MSfIinMPFhmkorw7X+dOXVJQs+QT69zGkzMyfDnIMN2Wid1+NbL3T+A==", + "dev": true, + "dependencies": { + "es-define-property": "^1.0.0", + "es-errors": "^1.3.0", + "gopd": "^1.0.1" + }, + "engines": { + "node": ">= 0.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/define-lazy-prop": { + "version": "3.0.0", + "resolved": "https://registry.npmjs.org/define-lazy-prop/-/define-lazy-prop-3.0.0.tgz", + "integrity": "sha512-N+MeXYoqr3pOgn8xfyRPREN7gHakLYjhsHhWGT3fWAiL4IkAt0iDw14QiiEm2bE30c5XX5q0FtAA3CK5f9/BUg==", + "dev": true, + "engines": { + "node": ">=12" + }, + "funding": { + "url": "https://github.com/sponsors/sindresorhus" + } + }, + "node_modules/delayed-stream": { + "version": "1.0.0", + "resolved": "https://registry.npmjs.org/delayed-stream/-/delayed-stream-1.0.0.tgz", + "integrity": "sha512-ZySD7Nf91aLB0RxL4KGrKHBXl7Eds1DAmEdcoVawXnLD7SDhpNgtuII2aAkg7a7QS41jxPSZ17p4VdGnMHk3MQ==", + "engines": { + "node": ">=0.4.0" + } + }, + "node_modules/depd": { + "version": "2.0.0", + "resolved": "https://registry.npmjs.org/depd/-/depd-2.0.0.tgz", + "integrity": "sha512-g7nH6P6dyDioJogAAGprGpCtVImJhpPk/roCzdb3fIh61/s/nPsfR6onyMwkCAR/OlC3yBC0lESvUoQEAssIrw==", + "dev": true, + "engines": { + "node": ">= 0.8" + } + }, + "node_modules/destroy": { + "version": "1.2.0", + "resolved": "https://registry.npmjs.org/destroy/-/destroy-1.2.0.tgz", + "integrity": "sha512-2sJGJTaXIIaR1w4iJSNoN0hnMY7Gpc/n8D4qSCJw8QqFWXf7cuAgnEHxBpweaVcPevC2l3KpjYCx3NypQQgaJg==", + "dev": true, + "engines": { + "node": ">= 0.8", + "npm": "1.2.8000 || >= 1.4.16" + } + }, + "node_modules/detect-node": { + "version": "2.1.0", + "resolved": "https://registry.npmjs.org/detect-node/-/detect-node-2.1.0.tgz", + "integrity": "sha512-T0NIuQpnTvFDATNuHN5roPwSBG83rFsuO+MXXH9/3N1eFbn4wcPjttvjMLEPWJ0RGUYgQE7cGgS3tNxbqCGM7g==", + "dev": true + }, + "node_modules/dns-packet": { + "version": "5.6.1", + "resolved": "https://registry.npmjs.org/dns-packet/-/dns-packet-5.6.1.tgz", + "integrity": "sha512-l4gcSouhcgIKRvyy99RNVOgxXiicE+2jZoNmaNmZ6JXiGajBOJAesk1OBlJuM5k2c+eudGdLxDqXuPCKIj6kpw==", + "dev": true, + "dependencies": { + "@leichtgewicht/ip-codec": "^2.0.1" + }, + "engines": { + "node": ">=6" + } + }, + "node_modules/eastasianwidth": { + "version": "0.2.0", + "resolved": "https://registry.npmjs.org/eastasianwidth/-/eastasianwidth-0.2.0.tgz", + "integrity": "sha512-I88TYZWc9XiYHRQ4/3c5rjjfgkjhLyW2luGIheGERbNQ6OY7yTybanSpDXZa8y7VUP9YmDcYa+eyq4ca7iLqWA==", + "dev": true + }, + "node_modules/ee-first": { + "version": "1.1.1", + "resolved": "https://registry.npmjs.org/ee-first/-/ee-first-1.1.1.tgz", + "integrity": "sha512-WMwm9LhRUo+WUaRN+vRuETqG89IgZphVSNkdFgeb6sS/E4OrDIN7t48CAewSHXc6C8lefD8KKfr5vY61brQlow==", + "dev": true + }, + "node_modules/electron-to-chromium": { + "version": "1.4.823", + "resolved": "https://registry.npmjs.org/electron-to-chromium/-/electron-to-chromium-1.4.823.tgz", + "integrity": "sha512-4h+oPeAiGQOHFyUJOqpoEcPj/xxlicxBzOErVeYVMMmAiXUXsGpsFd0QXBMaUUbnD8hhSfLf9uw+MlsoIA7j5w==", + "dev": true + }, + "node_modules/emoji-regex": { + "version": "9.2.2", + "resolved": "https://registry.npmjs.org/emoji-regex/-/emoji-regex-9.2.2.tgz", + "integrity": "sha512-L18DaJsXSUk2+42pv8mLs5jJT2hqFkFE4j21wOmgbUqsZ2hL72NsUU785g9RXgo3s0ZNgVl42TiHp3ZtOv/Vyg==", + "dev": true + }, + "node_modules/encodeurl": { + "version": "1.0.2", + "resolved": "https://registry.npmjs.org/encodeurl/-/encodeurl-1.0.2.tgz", + "integrity": "sha512-TPJXq8JqFaVYm2CWmPvnP2Iyo4ZSM7/QKcSmuMLDObfpH5fi7RUGmd/rTDf+rut/saiDiQEeVTNgAmJEdAOx0w==", + "dev": true, + "engines": { + "node": ">= 0.8" + } + }, + "node_modules/enhanced-resolve": { + "version": "5.17.0", + "resolved": "https://registry.npmjs.org/enhanced-resolve/-/enhanced-resolve-5.17.0.tgz", + "integrity": "sha512-dwDPwZL0dmye8Txp2gzFmA6sxALaSvdRDjPH0viLcKrtlOL3tw62nWWweVD1SdILDTJrbrL6tdWVN58Wo6U3eA==", + "dev": true, + "dependencies": { + "graceful-fs": "^4.2.4", + "tapable": "^2.2.0" + }, + "engines": { + "node": ">=10.13.0" + } + }, + "node_modules/envinfo": { + "version": "7.13.0", + "resolved": "https://registry.npmjs.org/envinfo/-/envinfo-7.13.0.tgz", + "integrity": "sha512-cvcaMr7KqXVh4nyzGTVqTum+gAiL265x5jUWQIDLq//zOGbW+gSW/C+OWLleY/rs9Qole6AZLMXPbtIFQbqu+Q==", + "dev": true, + "bin": { + "envinfo": "dist/cli.js" + }, + "engines": { + "node": ">=4" + } + }, + "node_modules/es-define-property": { + "version": "1.0.0", + "resolved": "https://registry.npmjs.org/es-define-property/-/es-define-property-1.0.0.tgz", + "integrity": "sha512-jxayLKShrEqqzJ0eumQbVhTYQM27CfT1T35+gCgDFoL82JLsXqTJ76zv6A0YLOgEnLUMvLzsDsGIrl8NFpT2gQ==", + "dev": true, + "dependencies": { + "get-intrinsic": "^1.2.4" + }, + "engines": { + "node": ">= 0.4" + } + }, + "node_modules/es-errors": { + "version": "1.3.0", + "resolved": "https://registry.npmjs.org/es-errors/-/es-errors-1.3.0.tgz", + "integrity": "sha512-Zf5H2Kxt2xjTvbJvP2ZWLEICxA6j+hAmMzIlypy4xcBg1vKVnx89Wy0GbS+kf5cwCVFFzdCFh2XSCFNULS6csw==", + "dev": true, + "engines": { + "node": ">= 0.4" + } + }, + "node_modules/es-module-lexer": { + "version": "1.5.4", + "resolved": "https://registry.npmjs.org/es-module-lexer/-/es-module-lexer-1.5.4.tgz", + "integrity": "sha512-MVNK56NiMrOwitFB7cqDwq0CQutbw+0BvLshJSse0MUNU+y1FC3bUS/AQg7oUng+/wKrrki7JfmwtVHkVfPLlw==", + "dev": true + }, + "node_modules/escalade": { + "version": "3.1.2", + "resolved": "https://registry.npmjs.org/escalade/-/escalade-3.1.2.tgz", + "integrity": "sha512-ErCHMCae19vR8vQGe50xIsVomy19rg6gFu3+r3jkEO46suLMWBksvVyoGgQV+jOfl84ZSOSlmv6Gxa89PmTGmA==", + "dev": true, + "engines": { + "node": ">=6" + } + }, + "node_modules/escape-html": { + "version": "1.0.3", + "resolved": "https://registry.npmjs.org/escape-html/-/escape-html-1.0.3.tgz", + "integrity": "sha512-NiSupZ4OeuGwr68lGIeym/ksIZMJodUGOSCZ/FSnTxcrekbvqrgdUxlJOMpijaKZVjAJrWrGs/6Jy8OMuyj9ow==", + "dev": true + }, + "node_modules/eslint-scope": { + "version": "5.1.1", + "resolved": "https://registry.npmjs.org/eslint-scope/-/eslint-scope-5.1.1.tgz", + "integrity": "sha512-2NxwbF/hZ0KpepYN0cNbo+FN6XoK7GaHlQhgx/hIZl6Va0bF45RQOOwhLIy8lQDbuCiadSLCBnH2CFYquit5bw==", + "dev": true, + "dependencies": { + "esrecurse": "^4.3.0", + "estraverse": "^4.1.1" + }, + "engines": { + "node": ">=8.0.0" + } + }, + "node_modules/esrecurse": { + "version": "4.3.0", + "resolved": "https://registry.npmjs.org/esrecurse/-/esrecurse-4.3.0.tgz", + "integrity": "sha512-KmfKL3b6G+RXvP8N1vr3Tq1kL/oCFgn2NYXEtqP8/L3pKapUA4G8cFVaoF3SU323CD4XypR/ffioHmkti6/Tag==", + "dev": true, + "dependencies": { + "estraverse": "^5.2.0" + }, + "engines": { + "node": ">=4.0" + } + }, + "node_modules/esrecurse/node_modules/estraverse": { + "version": "5.3.0", + "resolved": "https://registry.npmjs.org/estraverse/-/estraverse-5.3.0.tgz", + "integrity": "sha512-MMdARuVEQziNTeJD8DgMqmhwR11BRQ/cBP+pLtYdSTnf3MIO8fFeiINEbX36ZdNlfU/7A9f3gUw49B3oQsvwBA==", + "dev": true, + "engines": { + "node": ">=4.0" + } + }, + "node_modules/estraverse": { + "version": "4.3.0", + "resolved": "https://registry.npmjs.org/estraverse/-/estraverse-4.3.0.tgz", + "integrity": "sha512-39nnKffWz8xN1BU/2c79n9nB9HDzo0niYUqx6xyqUnyoAnQyyWpOTdZEeiCch8BBu515t4wp9ZmgVfVhn9EBpw==", + "dev": true, + "engines": { + "node": ">=4.0" + } + }, + "node_modules/etag": { + "version": "1.8.1", + "resolved": "https://registry.npmjs.org/etag/-/etag-1.8.1.tgz", + "integrity": "sha512-aIL5Fx7mawVa300al2BnEE4iNvo1qETxLrPI/o05L7z6go7fCw1J6EQmbK4FmJ2AS7kgVF/KEZWufBfdClMcPg==", + "dev": true, + "engines": { + "node": ">= 0.6" + } + }, + "node_modules/eventemitter3": { + "version": "4.0.7", + "resolved": "https://registry.npmjs.org/eventemitter3/-/eventemitter3-4.0.7.tgz", + "integrity": "sha512-8guHBZCwKnFhYdHr2ysuRWErTwhoN2X8XELRlrRwpmfeY2jjuUN4taQMsULKUVo1K4DvZl+0pgfyoysHxvmvEw==", + "dev": true + }, + "node_modules/events": { + "version": "3.3.0", + "resolved": "https://registry.npmjs.org/events/-/events-3.3.0.tgz", + "integrity": "sha512-mQw+2fkQbALzQ7V0MY0IqdnXNOeTtP4r0lN9z7AAawCXgqea7bDii20AYrIBrFd/Hx0M2Ocz6S111CaFkUcb0Q==", + "dev": true, + "engines": { + "node": ">=0.8.x" + } + }, + "node_modules/execa": { + "version": "5.1.1", + "resolved": "https://registry.npmjs.org/execa/-/execa-5.1.1.tgz", + "integrity": "sha512-8uSpZZocAZRBAPIEINJj3Lo9HyGitllczc27Eh5YYojjMFMn8yHMDMaUHE2Jqfq05D/wucwI4JGURyXt1vchyg==", + "dev": true, + "dependencies": { + "cross-spawn": "^7.0.3", + "get-stream": "^6.0.0", + "human-signals": "^2.1.0", + "is-stream": "^2.0.0", + "merge-stream": "^2.0.0", + "npm-run-path": "^4.0.1", + "onetime": "^5.1.2", + "signal-exit": "^3.0.3", + "strip-final-newline": "^2.0.0" + }, + "engines": { + "node": ">=10" + }, + "funding": { + "url": "https://github.com/sindresorhus/execa?sponsor=1" + } + }, + "node_modules/express": { + "version": "4.19.2", + "resolved": "https://registry.npmjs.org/express/-/express-4.19.2.tgz", + "integrity": "sha512-5T6nhjsT+EOMzuck8JjBHARTHfMht0POzlA60WV2pMD3gyXw2LZnZ+ueGdNxG+0calOJcWKbpFcuzLZ91YWq9Q==", + "dev": true, + "dependencies": { + "accepts": "~1.3.8", + "array-flatten": "1.1.1", + "body-parser": "1.20.2", + "content-disposition": "0.5.4", + "content-type": "~1.0.4", + "cookie": "0.6.0", + "cookie-signature": "1.0.6", + "debug": "2.6.9", + "depd": "2.0.0", + "encodeurl": "~1.0.2", + "escape-html": "~1.0.3", + "etag": "~1.8.1", + "finalhandler": "1.2.0", + "fresh": "0.5.2", + "http-errors": "2.0.0", + "merge-descriptors": "1.0.1", + "methods": "~1.1.2", + "on-finished": "2.4.1", + "parseurl": "~1.3.3", + "path-to-regexp": "0.1.7", + "proxy-addr": "~2.0.7", + "qs": "6.11.0", + "range-parser": "~1.2.1", + "safe-buffer": "5.2.1", + "send": "0.18.0", + "serve-static": "1.15.0", + "setprototypeof": "1.2.0", + "statuses": "2.0.1", + "type-is": "~1.6.18", + "utils-merge": "1.0.1", + "vary": "~1.1.2" + }, + "engines": { + "node": ">= 0.10.0" + } + }, + "node_modules/express/node_modules/qs": { + "version": "6.11.0", + "resolved": "https://registry.npmjs.org/qs/-/qs-6.11.0.tgz", + "integrity": "sha512-MvjoMCJwEarSbUYk5O+nmoSzSutSsTwF85zcHPQ9OrlFoZOYIjaqBAJIqIXjptyD5vThxGq52Xu/MaJzRkIk4Q==", + "dev": true, + "dependencies": { + "side-channel": "^1.0.4" + }, + "engines": { + "node": ">=0.6" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/fast-deep-equal": { + "version": "3.1.3", + "resolved": "https://registry.npmjs.org/fast-deep-equal/-/fast-deep-equal-3.1.3.tgz", + "integrity": "sha512-f3qQ9oQy9j2AhBe/H9VC91wLmKBCCU/gDOnKNAYG5hswO7BLKj09Hc5HYNz9cGI++xlpDCIgDaitVs03ATR84Q==", + "dev": true + }, + "node_modules/fast-glob": { + "version": "3.3.2", + "resolved": "https://registry.npmjs.org/fast-glob/-/fast-glob-3.3.2.tgz", + "integrity": "sha512-oX2ruAFQwf/Orj8m737Y5adxDQO0LAB7/S5MnxCdTNDd4p6BsyIVsv9JQsATbTSq8KHRpLwIHbVlUNatxd+1Ow==", + "dev": true, + "dependencies": { + "@nodelib/fs.stat": "^2.0.2", + "@nodelib/fs.walk": "^1.2.3", + "glob-parent": "^5.1.2", + "merge2": "^1.3.0", + "micromatch": "^4.0.4" + }, + "engines": { + "node": ">=8.6.0" + } + }, + "node_modules/fast-glob/node_modules/glob-parent": { + "version": "5.1.2", + "resolved": "https://registry.npmjs.org/glob-parent/-/glob-parent-5.1.2.tgz", + "integrity": "sha512-AOIgSQCepiJYwP3ARnGx+5VnTu2HBYdzbGP45eLw1vr3zB3vZLeyed1sC9hnbcOc9/SrMyM5RPQrkGz4aS9Zow==", + "dev": true, + "dependencies": { + "is-glob": "^4.0.1" + }, + "engines": { + "node": ">= 6" + } + }, + "node_modules/fast-json-stable-stringify": { + "version": "2.1.0", + "resolved": "https://registry.npmjs.org/fast-json-stable-stringify/-/fast-json-stable-stringify-2.1.0.tgz", + "integrity": "sha512-lhd/wF+Lk98HZoTCtlVraHtfh5XYijIjalXck7saUtuanSDyLMxnHhSXEDJqHxD7msR8D0uCmqlkwjCV8xvwHw==", + "dev": true + }, + "node_modules/fastest-levenshtein": { + "version": "1.0.16", + "resolved": "https://registry.npmjs.org/fastest-levenshtein/-/fastest-levenshtein-1.0.16.tgz", + "integrity": "sha512-eRnCtTTtGZFpQCwhJiUOuxPQWRXVKYDn0b2PeHfXL6/Zi53SLAzAHfVhVWK2AryC/WH05kGfxhFIPvTF0SXQzg==", + "dev": true, + "engines": { + "node": ">= 4.9.1" + } + }, + "node_modules/fastq": { + "version": "1.17.1", + "resolved": "https://registry.npmjs.org/fastq/-/fastq-1.17.1.tgz", + "integrity": "sha512-sRVD3lWVIXWg6By68ZN7vho9a1pQcN/WBFaAAsDDFzlJjvoGx0P8z7V1t72grFJfJhu3YPZBuu25f7Kaw2jN1w==", + "dev": true, + "dependencies": { + "reusify": "^1.0.4" + } + }, + "node_modules/faye-websocket": { + "version": "0.11.4", + "resolved": "https://registry.npmjs.org/faye-websocket/-/faye-websocket-0.11.4.tgz", + "integrity": "sha512-CzbClwlXAuiRQAlUyfqPgvPoNKTckTPGfwZV4ZdAhVcP2lh9KUxJg2b5GkE7XbjKQ3YJnQ9z6D9ntLAlB+tP8g==", + "dev": true, + "dependencies": { + "websocket-driver": ">=0.5.1" + }, + "engines": { + "node": ">=0.8.0" + } + }, + "node_modules/fill-range": { + "version": "7.1.1", + "resolved": "https://registry.npmjs.org/fill-range/-/fill-range-7.1.1.tgz", + "integrity": "sha512-YsGpe3WHLK8ZYi4tWDg2Jy3ebRz2rXowDxnld4bkQB00cc/1Zw9AWnC0i9ztDJitivtQvaI9KaLyKrc+hBW0yg==", + "dev": true, + "dependencies": { + "to-regex-range": "^5.0.1" + }, + "engines": { + "node": ">=8" + } + }, + "node_modules/finalhandler": { + "version": "1.2.0", + "resolved": "https://registry.npmjs.org/finalhandler/-/finalhandler-1.2.0.tgz", + "integrity": "sha512-5uXcUVftlQMFnWC9qu/svkWv3GTd2PfUhK/3PLkYNAe7FbqJMt3515HaxE6eRL74GdsriiwujiawdaB1BpEISg==", + "dev": true, + "dependencies": { + "debug": "2.6.9", + "encodeurl": "~1.0.2", + "escape-html": "~1.0.3", + "on-finished": "2.4.1", + "parseurl": "~1.3.3", + "statuses": "2.0.1", + "unpipe": "~1.0.0" + }, + "engines": { + "node": ">= 0.8" + } + }, + "node_modules/find-up": { + "version": "4.1.0", + "resolved": "https://registry.npmjs.org/find-up/-/find-up-4.1.0.tgz", + "integrity": "sha512-PpOwAdQ/YlXQ2vj8a3h8IipDuYRi3wceVQQGYWxNINccq40Anw7BlsEXCMbt1Zt+OLA6Fq9suIpIWD0OsnISlw==", + "dev": true, + "dependencies": { + "locate-path": "^5.0.0", + "path-exists": "^4.0.0" + }, + "engines": { + "node": ">=8" + } + }, + "node_modules/flat": { + "version": "5.0.2", + "resolved": "https://registry.npmjs.org/flat/-/flat-5.0.2.tgz", + "integrity": "sha512-b6suED+5/3rTpUBdG1gupIl8MPFCAMA0QXwmljLhvCUKcUvdE4gWky9zpuGCcXHOsz4J9wPGNWq6OKpmIzz3hQ==", + "dev": true, + "bin": { + "flat": "cli.js" + } + }, + "node_modules/follow-redirects": { + "version": "1.15.6", + "resolved": "https://registry.npmjs.org/follow-redirects/-/follow-redirects-1.15.6.tgz", + "integrity": "sha512-wWN62YITEaOpSK584EZXJafH1AGpO8RVgElfkuXbTOrPX4fIfOyEpW/CsiNd8JdYrAoOvafRTOEnvsO++qCqFA==", + "funding": [ + { + "type": "individual", + "url": "https://github.com/sponsors/RubenVerborgh" + } + ], + "engines": { + "node": ">=4.0" + }, + "peerDependenciesMeta": { + "debug": { + "optional": true + } + } + }, + "node_modules/foreground-child": { + "version": "3.2.1", + "resolved": "https://registry.npmjs.org/foreground-child/-/foreground-child-3.2.1.tgz", + "integrity": "sha512-PXUUyLqrR2XCWICfv6ukppP96sdFwWbNEnfEMt7jNsISjMsvaLNinAHNDYyvkyU+SZG2BTSbT5NjG+vZslfGTA==", + "dev": true, + "dependencies": { + "cross-spawn": "^7.0.0", + "signal-exit": "^4.0.1" + }, + "engines": { + "node": ">=14" + }, + "funding": { + "url": "https://github.com/sponsors/isaacs" + } + }, + "node_modules/foreground-child/node_modules/signal-exit": { + "version": "4.1.0", + "resolved": "https://registry.npmjs.org/signal-exit/-/signal-exit-4.1.0.tgz", + "integrity": "sha512-bzyZ1e88w9O1iNJbKnOlvYTrWPDl46O1bG0D3XInv+9tkPrxrN8jUUTiFlDkkmKWgn1M6CfIA13SuGqOa9Korw==", + "dev": true, + "engines": { + "node": ">=14" + }, + "funding": { + "url": "https://github.com/sponsors/isaacs" + } + }, + "node_modules/form-data": { + "version": "4.0.0", + "resolved": "https://registry.npmjs.org/form-data/-/form-data-4.0.0.tgz", + "integrity": "sha512-ETEklSGi5t0QMZuiXoA/Q6vcnxcLQP5vdugSpuAyi6SVGi2clPPp+xgEhuMaHC+zGgn31Kd235W35f7Hykkaww==", + "dependencies": { + "asynckit": "^0.4.0", + "combined-stream": "^1.0.8", + "mime-types": "^2.1.12" + }, + "engines": { + "node": ">= 6" + } + }, + "node_modules/forwarded": { + "version": "0.2.0", + "resolved": "https://registry.npmjs.org/forwarded/-/forwarded-0.2.0.tgz", + "integrity": "sha512-buRG0fpBtRHSTCOASe6hD258tEubFoRLb4ZNA6NxMVHNw2gOcwHo9wyablzMzOA5z9xA9L1KNjk/Nt6MT9aYow==", + "dev": true, + "engines": { + "node": ">= 0.6" + } + }, + "node_modules/fresh": { + "version": "0.5.2", + "resolved": "https://registry.npmjs.org/fresh/-/fresh-0.5.2.tgz", + "integrity": "sha512-zJ2mQYM18rEFOudeV4GShTGIQ7RbzA7ozbU9I/XBpm7kqgMywgmylMwXHxZJmkVoYkna9d2pVXVXPdYTP9ej8Q==", + "dev": true, + "engines": { + "node": ">= 0.6" + } + }, + "node_modules/fsevents": { + "version": "2.3.3", + "resolved": "https://registry.npmjs.org/fsevents/-/fsevents-2.3.3.tgz", + "integrity": "sha512-5xoDfX+fL7faATnagmWPpbFtwh/R77WmMMqqHGS65C3vvB0YHrgF+B1YmZ3441tMj5n63k0212XNoJwzlhffQw==", + "dev": true, + "hasInstallScript": true, + "optional": true, + "os": [ + "darwin" + ], + "engines": { + "node": "^8.16.0 || ^10.6.0 || >=11.0.0" + } + }, + "node_modules/function-bind": { + "version": "1.1.2", + "resolved": "https://registry.npmjs.org/function-bind/-/function-bind-1.1.2.tgz", + "integrity": "sha512-7XHNxH7qX9xG5mIwxkhumTox/MIRNcOgDrxWsMt2pAr23WHp6MrRlN7FBSFpCpr+oVO0F744iUgR82nJMfG2SA==", + "dev": true, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/get-intrinsic": { + "version": "1.2.4", + "resolved": "https://registry.npmjs.org/get-intrinsic/-/get-intrinsic-1.2.4.tgz", + "integrity": "sha512-5uYhsJH8VJBTv7oslg4BznJYhDoRI6waYCxMmCdnTrcCrHA/fCFKoTFz2JKKE0HdDFUF7/oQuhzumXJK7paBRQ==", + "dev": true, + "dependencies": { + "es-errors": "^1.3.0", + "function-bind": "^1.1.2", + "has-proto": "^1.0.1", + "has-symbols": "^1.0.3", + "hasown": "^2.0.0" + }, + "engines": { + "node": ">= 0.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/get-stream": { + "version": "6.0.1", + "resolved": "https://registry.npmjs.org/get-stream/-/get-stream-6.0.1.tgz", + "integrity": "sha512-ts6Wi+2j3jQjqi70w5AlN8DFnkSwC+MqmxEzdEALB2qXZYV3X/b1CTfgPLGJNMeAWxdPfU8FO1ms3NUfaHCPYg==", + "dev": true, + "engines": { + "node": ">=10" + }, + "funding": { + "url": "https://github.com/sponsors/sindresorhus" + } + }, + "node_modules/glob": { + "version": "10.4.5", + "resolved": "https://registry.npmjs.org/glob/-/glob-10.4.5.tgz", + "integrity": "sha512-7Bv8RF0k6xjo7d4A/PxYLbUCfb6c+Vpd2/mB2yRDlew7Jb5hEXiCD9ibfO7wpk8i4sevK6DFny9h7EYbM3/sHg==", + "dev": true, + "dependencies": { + "foreground-child": "^3.1.0", + "jackspeak": "^3.1.2", + "minimatch": "^9.0.4", + "minipass": "^7.1.2", + "package-json-from-dist": "^1.0.0", + "path-scurry": "^1.11.1" + }, + "bin": { + "glob": "dist/esm/bin.mjs" + }, + "funding": { + "url": "https://github.com/sponsors/isaacs" + } + }, + "node_modules/glob-parent": { + "version": "6.0.2", + "resolved": "https://registry.npmjs.org/glob-parent/-/glob-parent-6.0.2.tgz", + "integrity": "sha512-XxwI8EOhVQgWp6iDL+3b0r86f4d6AX6zSU55HfB4ydCEuXLXc5FcYeOu+nnGftS4TEju/11rt4KJPTMgbfmv4A==", + "dev": true, + "dependencies": { + "is-glob": "^4.0.3" + }, + "engines": { + "node": ">=10.13.0" + } + }, + "node_modules/glob-to-regexp": { + "version": "0.4.1", + "resolved": "https://registry.npmjs.org/glob-to-regexp/-/glob-to-regexp-0.4.1.tgz", + "integrity": "sha512-lkX1HJXwyMcprw/5YUZc2s7DrpAiHB21/V+E1rHUrVNokkvB6bqMzT0VfV6/86ZNabt1k14YOIaT7nDvOX3Iiw==", + "dev": true + }, + "node_modules/globby": { + "version": "14.0.2", + "resolved": "https://registry.npmjs.org/globby/-/globby-14.0.2.tgz", + "integrity": "sha512-s3Fq41ZVh7vbbe2PN3nrW7yC7U7MFVc5c98/iTl9c2GawNMKx/J648KQRW6WKkuU8GIbbh2IXfIRQjOZnXcTnw==", + "dev": true, + "dependencies": { + "@sindresorhus/merge-streams": "^2.1.0", + "fast-glob": "^3.3.2", + "ignore": "^5.2.4", + "path-type": "^5.0.0", + "slash": "^5.1.0", + "unicorn-magic": "^0.1.0" + }, + "engines": { + "node": ">=18" + }, + "funding": { + "url": "https://github.com/sponsors/sindresorhus" + } + }, + "node_modules/gopd": { + "version": "1.0.1", + "resolved": "https://registry.npmjs.org/gopd/-/gopd-1.0.1.tgz", + "integrity": "sha512-d65bNlIadxvpb/A2abVdlqKqV563juRnZ1Wtk6s1sIR8uNsXR70xqIzVqxVf1eTqDunwT2MkczEeaezCKTZhwA==", + "dev": true, + "dependencies": { + "get-intrinsic": "^1.1.3" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/graceful-fs": { + "version": "4.2.11", + "resolved": "https://registry.npmjs.org/graceful-fs/-/graceful-fs-4.2.11.tgz", + "integrity": "sha512-RbJ5/jmFcNNCcDV5o9eTnBLJ/HszWV0P73bc+Ff4nS/rJj+YaS6IGyiOL0VoBYX+l1Wrl3k63h/KrH+nhJ0XvQ==", + "dev": true + }, + "node_modules/handle-thing": { + "version": "2.0.1", + "resolved": "https://registry.npmjs.org/handle-thing/-/handle-thing-2.0.1.tgz", + "integrity": "sha512-9Qn4yBxelxoh2Ow62nP+Ka/kMnOXRi8BXnRaUwezLNhqelnN49xKz4F/dPP8OYLxLxq6JDtZb2i9XznUQbNPTg==", + "dev": true + }, + "node_modules/has-flag": { + "version": "4.0.0", + "resolved": "https://registry.npmjs.org/has-flag/-/has-flag-4.0.0.tgz", + "integrity": "sha512-EykJT/Q1KjTWctppgIAgfSO0tKVuZUjhgMr17kqTumMl6Afv3EISleU7qZUzoXDFTAHTDC4NOoG/ZxU3EvlMPQ==", + "dev": true, + "engines": { + "node": ">=8" + } + }, + "node_modules/has-property-descriptors": { + "version": "1.0.2", + "resolved": "https://registry.npmjs.org/has-property-descriptors/-/has-property-descriptors-1.0.2.tgz", + "integrity": "sha512-55JNKuIW+vq4Ke1BjOTjM2YctQIvCT7GFzHwmfZPGo5wnrgkid0YQtnAleFSqumZm4az3n2BS+erby5ipJdgrg==", + "dev": true, + "dependencies": { + "es-define-property": "^1.0.0" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/has-proto": { + "version": "1.0.3", + "resolved": "https://registry.npmjs.org/has-proto/-/has-proto-1.0.3.tgz", + "integrity": "sha512-SJ1amZAJUiZS+PhsVLf5tGydlaVB8EdFpaSO4gmiUKUOxk8qzn5AIy4ZeJUmh22znIdk/uMAUT2pl3FxzVUH+Q==", + "dev": true, + "engines": { + "node": ">= 0.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/has-symbols": { + "version": "1.0.3", + "resolved": "https://registry.npmjs.org/has-symbols/-/has-symbols-1.0.3.tgz", + "integrity": "sha512-l3LCuF6MgDNwTDKkdYGEihYjt5pRPbEg46rtlmnSPlUbgmB8LOIrKJbYYFBSbnPaJexMKtiPO8hmeRjRz2Td+A==", + "dev": true, + "engines": { + "node": ">= 0.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/hasown": { + "version": "2.0.2", + "resolved": "https://registry.npmjs.org/hasown/-/hasown-2.0.2.tgz", + "integrity": "sha512-0hJU9SCPvmMzIBdZFqNPXWa6dqh7WdH0cII9y+CyS8rG3nL48Bclra9HmKhVVUHyPWNH5Y7xDwAB7bfgSjkUMQ==", + "dev": true, + "dependencies": { + "function-bind": "^1.1.2" + }, + "engines": { + "node": ">= 0.4" + } + }, + "node_modules/hogan.js": { + "version": "3.0.2", + "resolved": "https://registry.npmjs.org/hogan.js/-/hogan.js-3.0.2.tgz", + "integrity": "sha512-RqGs4wavGYJWE07t35JQccByczmNUXQT0E12ZYV1VKYu5UiAU9lsos/yBAcf840+zrUQQxgVduCR5/B8nNtibg==", + "dependencies": { + "mkdirp": "0.3.0", + "nopt": "1.0.10" + }, + "bin": { + "hulk": "bin/hulk" + } + }, + "node_modules/hpack.js": { + "version": "2.1.6", + "resolved": "https://registry.npmjs.org/hpack.js/-/hpack.js-2.1.6.tgz", + "integrity": "sha512-zJxVehUdMGIKsRaNt7apO2Gqp0BdqW5yaiGHXXmbpvxgBYVZnAql+BJb4RO5ad2MgpbZKn5G6nMnegrH1FcNYQ==", + "dev": true, + "dependencies": { + "inherits": "^2.0.1", + "obuf": "^1.0.0", + "readable-stream": "^2.0.1", + "wbuf": "^1.1.0" + } + }, + "node_modules/hpack.js/node_modules/readable-stream": { + "version": "2.3.8", + "resolved": "https://registry.npmjs.org/readable-stream/-/readable-stream-2.3.8.tgz", + "integrity": "sha512-8p0AUk4XODgIewSi0l8Epjs+EVnWiK7NoDIEGU0HhE7+ZyY8D1IMY7odu5lRrFXGg71L15KG8QrPmum45RTtdA==", + "dev": true, + "dependencies": { + "core-util-is": "~1.0.0", + "inherits": "~2.0.3", + "isarray": "~1.0.0", + "process-nextick-args": "~2.0.0", + "safe-buffer": "~5.1.1", + "string_decoder": "~1.1.1", + "util-deprecate": "~1.0.1" + } + }, + "node_modules/hpack.js/node_modules/safe-buffer": { + "version": "5.1.2", + "resolved": "https://registry.npmjs.org/safe-buffer/-/safe-buffer-5.1.2.tgz", + "integrity": "sha512-Gd2UZBJDkXlY7GbJxfsE8/nvKkUEU1G38c1siN6QP6a9PT9MmHB8GnpscSmMJSoF8LOIrt8ud/wPtojys4G6+g==", + "dev": true + }, + "node_modules/hpack.js/node_modules/string_decoder": { + "version": "1.1.1", + "resolved": "https://registry.npmjs.org/string_decoder/-/string_decoder-1.1.1.tgz", + "integrity": "sha512-n/ShnvDi6FHbbVfviro+WojiFzv+s8MPMHBczVePfUpDJLwoLT0ht1l4YwBCbi8pJAveEEdnkHyPyTP/mzRfwg==", + "dev": true, + "dependencies": { + "safe-buffer": "~5.1.0" + } + }, + "node_modules/htm": { + "version": "3.1.1", + "resolved": "https://registry.npmjs.org/htm/-/htm-3.1.1.tgz", + "integrity": "sha512-983Vyg8NwUE7JkZ6NmOqpCZ+sh1bKv2iYTlUkzlWmA5JD2acKoxd4KVxbMmxX/85mtfdnDmTFoNKcg5DGAvxNQ==" + }, + "node_modules/html-entities": { + "version": "2.5.2", + "resolved": "https://registry.npmjs.org/html-entities/-/html-entities-2.5.2.tgz", + "integrity": "sha512-K//PSRMQk4FZ78Kyau+mZurHn3FH0Vwr+H36eE0rPbeYkRRi9YxceYPhuN60UwWorxyKHhqoAJl2OFKa4BVtaA==", + "dev": true, + "funding": [ + { + "type": "github", + "url": "https://github.com/sponsors/mdevils" + }, + { + "type": "patreon", + "url": "https://patreon.com/mdevils" + } + ] + }, + "node_modules/http-deceiver": { + "version": "1.2.7", + "resolved": "https://registry.npmjs.org/http-deceiver/-/http-deceiver-1.2.7.tgz", + "integrity": "sha512-LmpOGxTfbpgtGVxJrj5k7asXHCgNZp5nLfp+hWc8QQRqtb7fUy6kRY3BO1h9ddF6yIPYUARgxGOwB42DnxIaNw==", + "dev": true + }, + "node_modules/http-errors": { + "version": "2.0.0", + "resolved": "https://registry.npmjs.org/http-errors/-/http-errors-2.0.0.tgz", + "integrity": "sha512-FtwrG/euBzaEjYeRqOgly7G0qviiXoJWnvEH2Z1plBdXgbyjv34pHTSb9zoeHMyDy33+DWy5Wt9Wo+TURtOYSQ==", + "dev": true, + "dependencies": { + "depd": "2.0.0", + "inherits": "2.0.4", + "setprototypeof": "1.2.0", + "statuses": "2.0.1", + "toidentifier": "1.0.1" + }, + "engines": { + "node": ">= 0.8" + } + }, + "node_modules/http-parser-js": { + "version": "0.5.8", + "resolved": "https://registry.npmjs.org/http-parser-js/-/http-parser-js-0.5.8.tgz", + "integrity": "sha512-SGeBX54F94Wgu5RH3X5jsDtf4eHyRogWX1XGT3b4HuW3tQPM4AaBzoUji/4AAJNXCEOWZ5O0DgZmJw1947gD5Q==", + "dev": true + }, + "node_modules/http-proxy": { + "version": "1.18.1", + "resolved": "https://registry.npmjs.org/http-proxy/-/http-proxy-1.18.1.tgz", + "integrity": "sha512-7mz/721AbnJwIVbnaSv1Cz3Am0ZLT/UBwkC92VlxhXv/k/BBQfM2fXElQNC27BVGr0uwUpplYPQM9LnaBMR5NQ==", + "dev": true, + "dependencies": { + "eventemitter3": "^4.0.0", + "follow-redirects": "^1.0.0", + "requires-port": "^1.0.0" + }, + "engines": { + "node": ">=8.0.0" + } + }, + "node_modules/http-proxy-middleware": { + "version": "2.0.6", + "resolved": "https://registry.npmjs.org/http-proxy-middleware/-/http-proxy-middleware-2.0.6.tgz", + "integrity": "sha512-ya/UeJ6HVBYxrgYotAZo1KvPWlgB48kUJLDePFeneHsVujFaW5WNj2NgWCAE//B1Dl02BIfYlpNgBy8Kf8Rjmw==", + "dev": true, + "dependencies": { + "@types/http-proxy": "^1.17.8", + "http-proxy": "^1.18.1", + "is-glob": "^4.0.1", + "is-plain-obj": "^3.0.0", + "micromatch": "^4.0.2" + }, + "engines": { + "node": ">=12.0.0" + }, + "peerDependencies": { + "@types/express": "^4.17.13" + }, + "peerDependenciesMeta": { + "@types/express": { + "optional": true + } + } + }, + "node_modules/human-signals": { + "version": "2.1.0", + "resolved": "https://registry.npmjs.org/human-signals/-/human-signals-2.1.0.tgz", + "integrity": "sha512-B4FFZ6q/T2jhhksgkbEW3HBvWIfDW85snkQgawt07S7J5QXTk6BkNV+0yAeZrM5QpMAdYlocGoljn0sJ/WQkFw==", + "dev": true, + "engines": { + "node": ">=10.17.0" + } + }, + "node_modules/hyperdyperid": { + "version": "1.2.0", + "resolved": "https://registry.npmjs.org/hyperdyperid/-/hyperdyperid-1.2.0.tgz", + "integrity": "sha512-Y93lCzHYgGWdrJ66yIktxiaGULYc6oGiABxhcO5AufBeOyoIdZF7bIfLaOrbM0iGIOXQQgxxRrFEnb+Y6w1n4A==", + "dev": true, + "engines": { + "node": ">=10.18" + } + }, + "node_modules/iconv-lite": { + "version": "0.4.24", + "resolved": "https://registry.npmjs.org/iconv-lite/-/iconv-lite-0.4.24.tgz", + "integrity": "sha512-v3MXnZAcvnywkTUEZomIActle7RXXeedOR31wwl7VlyoXO4Qi9arvSenNQWne1TcRwhCL1HwLI21bEqdpj8/rA==", + "dev": true, + "dependencies": { + "safer-buffer": ">= 2.1.2 < 3" + }, + "engines": { + "node": ">=0.10.0" + } + }, + "node_modules/icss-utils": { + "version": "5.1.0", + "resolved": "https://registry.npmjs.org/icss-utils/-/icss-utils-5.1.0.tgz", + "integrity": "sha512-soFhflCVWLfRNOPU3iv5Z9VUdT44xFRbzjLsEzSr5AQmgqPMTHdU3PMT1Cf1ssx8fLNJDA1juftYl+PUcv3MqA==", + "dev": true, + "engines": { + "node": "^10 || ^12 || >= 14" + }, + "peerDependencies": { + "postcss": "^8.1.0" + } + }, + "node_modules/ignore": { + "version": "5.3.1", + "resolved": "https://registry.npmjs.org/ignore/-/ignore-5.3.1.tgz", + "integrity": "sha512-5Fytz/IraMjqpwfd34ke28PTVMjZjJG2MPn5t7OE4eUCUNf8BAa7b5WUS9/Qvr6mwOQS7Mk6vdsMno5he+T8Xw==", + "dev": true, + "engines": { + "node": ">= 4" + } + }, + "node_modules/import-local": { + "version": "3.1.0", + "resolved": "https://registry.npmjs.org/import-local/-/import-local-3.1.0.tgz", + "integrity": "sha512-ASB07uLtnDs1o6EHjKpX34BKYDSqnFerfTOJL2HvMqF70LnxpjkzDB8J44oT9pu4AMPkQwf8jl6szgvNd2tRIg==", + "dev": true, + "dependencies": { + "pkg-dir": "^4.2.0", + "resolve-cwd": "^3.0.0" + }, + "bin": { + "import-local-fixture": "fixtures/cli.js" + }, + "engines": { + "node": ">=8" + }, + "funding": { + "url": "https://github.com/sponsors/sindresorhus" + } + }, + "node_modules/inherits": { + "version": "2.0.4", + "resolved": "https://registry.npmjs.org/inherits/-/inherits-2.0.4.tgz", + "integrity": "sha512-k/vGaX4/Yla3WzyMCvTQOXYeIHvqOKtnqBduzTHpzpQZzAskKMhZ2K+EnBiSM9zGSoIFeMpXKxa4dYeZIQqewQ==", + "dev": true + }, + "node_modules/instantsearch-ui-components": { + "version": "0.7.0", + "resolved": "https://registry.npmjs.org/instantsearch-ui-components/-/instantsearch-ui-components-0.7.0.tgz", + "integrity": "sha512-4dHmCFbKWap5iSR2VmF5pSBECGQbAa8sPMoazMihYY2/0ahVzdHrOOtT8/hferG1A/xTT8nzfU7PIg+8lomNsA==", + "dependencies": { + "@babel/runtime": "^7.1.2" + } + }, + "node_modules/instantsearch.js": { + "version": "4.73.1", + "resolved": "https://registry.npmjs.org/instantsearch.js/-/instantsearch.js-4.73.1.tgz", + "integrity": "sha512-sO+eck5STiHiDFaNNoYzd62RDJwINgoi3yyOcEBi7PCs0rrpcj4hw0lTuw30cqloNjcM63exGdcRXX5r7Hl49g==", + "dependencies": { + "@algolia/events": "^4.0.1", + "@types/dom-speech-recognition": "^0.0.1", + "@types/google.maps": "^3.45.3", + "@types/hogan.js": "^3.0.0", + "@types/qs": "^6.5.3", + "algoliasearch-helper": "3.22.2", + "hogan.js": "^3.0.2", + "htm": "^3.0.0", + "instantsearch-ui-components": "0.7.0", + "preact": "^10.10.0", + "qs": "^6.5.1 < 6.10", + "search-insights": "^2.15.0" + }, + "peerDependencies": { + "algoliasearch": ">= 3.1 < 6" + } + }, + "node_modules/interpret": { + "version": "3.1.1", + "resolved": "https://registry.npmjs.org/interpret/-/interpret-3.1.1.tgz", + "integrity": "sha512-6xwYfHbajpoF0xLW+iwLkhwgvLoZDfjYfoFNu8ftMoXINzwuymNLd9u/KmwtdT2GbR+/Cz66otEGEVVUHX9QLQ==", + "dev": true, + "engines": { + "node": ">=10.13.0" + } + }, + "node_modules/ipaddr.js": { + "version": "2.2.0", + "resolved": "https://registry.npmjs.org/ipaddr.js/-/ipaddr.js-2.2.0.tgz", + "integrity": "sha512-Ag3wB2o37wslZS19hZqorUnrnzSkpOVy+IiiDEiTqNubEYpYuHWIf6K4psgN2ZWKExS4xhVCrRVfb/wfW8fWJA==", + "dev": true, + "engines": { + "node": ">= 10" + } + }, + "node_modules/is-binary-path": { + "version": "2.1.0", + "resolved": "https://registry.npmjs.org/is-binary-path/-/is-binary-path-2.1.0.tgz", + "integrity": "sha512-ZMERYes6pDydyuGidse7OsHxtbI7WVeUEozgR/g7rd0xUimYNlvZRE/K2MgZTjWy725IfelLeVcEM97mmtRGXw==", + "dev": true, + "dependencies": { + "binary-extensions": "^2.0.0" + }, + "engines": { + "node": ">=8" + } + }, + "node_modules/is-core-module": { + "version": "2.14.0", + "resolved": "https://registry.npmjs.org/is-core-module/-/is-core-module-2.14.0.tgz", + "integrity": "sha512-a5dFJih5ZLYlRtDc0dZWP7RiKr6xIKzmn/oAYCDvdLThadVgyJwlaoQPmRtMSpz+rk0OGAgIu+TcM9HUF0fk1A==", + "dev": true, + "dependencies": { + "hasown": "^2.0.2" + }, + "engines": { + "node": ">= 0.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/is-docker": { + "version": "3.0.0", + "resolved": "https://registry.npmjs.org/is-docker/-/is-docker-3.0.0.tgz", + "integrity": "sha512-eljcgEDlEns/7AXFosB5K/2nCM4P7FQPkGc/DWLy5rmFEWvZayGrik1d9/QIY5nJ4f9YsVvBkA6kJpHn9rISdQ==", + "dev": true, + "bin": { + "is-docker": "cli.js" + }, + "engines": { + "node": "^12.20.0 || ^14.13.1 || >=16.0.0" + }, + "funding": { + "url": "https://github.com/sponsors/sindresorhus" + } + }, + "node_modules/is-extglob": { + "version": "2.1.1", + "resolved": "https://registry.npmjs.org/is-extglob/-/is-extglob-2.1.1.tgz", + "integrity": "sha512-SbKbANkN603Vi4jEZv49LeVJMn4yGwsbzZworEoyEiutsN3nJYdbO36zfhGJ6QEDpOZIFkDtnq5JRxmvl3jsoQ==", + "dev": true, + "engines": { + "node": ">=0.10.0" + } + }, + "node_modules/is-fullwidth-code-point": { + "version": "3.0.0", + "resolved": "https://registry.npmjs.org/is-fullwidth-code-point/-/is-fullwidth-code-point-3.0.0.tgz", + "integrity": "sha512-zymm5+u+sCsSWyD9qNaejV3DFvhCKclKdizYaJUuHA83RLjb7nSuGnddCHGv0hk+KY7BMAlsWeK4Ueg6EV6XQg==", + "dev": true, + "engines": { + "node": ">=8" + } + }, + "node_modules/is-glob": { + "version": "4.0.3", + "resolved": "https://registry.npmjs.org/is-glob/-/is-glob-4.0.3.tgz", + "integrity": "sha512-xelSayHH36ZgE7ZWhli7pW34hNbNl8Ojv5KVmkJD4hBdD3th8Tfk9vYasLM+mXWOZhFkgZfxhLSnrwRr4elSSg==", + "dev": true, + "dependencies": { + "is-extglob": "^2.1.1" + }, + "engines": { + "node": ">=0.10.0" + } + }, + "node_modules/is-inside-container": { + "version": "1.0.0", + "resolved": "https://registry.npmjs.org/is-inside-container/-/is-inside-container-1.0.0.tgz", + "integrity": "sha512-KIYLCCJghfHZxqjYBE7rEy0OBuTd5xCHS7tHVgvCLkx7StIoaxwNW3hCALgEUjFfeRk+MG/Qxmp/vtETEF3tRA==", + "dev": true, + "dependencies": { + "is-docker": "^3.0.0" + }, + "bin": { + "is-inside-container": "cli.js" + }, + "engines": { + "node": ">=14.16" + }, + "funding": { + "url": "https://github.com/sponsors/sindresorhus" + } + }, + "node_modules/is-network-error": { + "version": "1.1.0", + "resolved": "https://registry.npmjs.org/is-network-error/-/is-network-error-1.1.0.tgz", + "integrity": "sha512-tUdRRAnhT+OtCZR/LxZelH/C7QtjtFrTu5tXCA8pl55eTUElUHT+GPYV8MBMBvea/j+NxQqVt3LbWMRir7Gx9g==", + "dev": true, + "engines": { + "node": ">=16" + }, + "funding": { + "url": "https://github.com/sponsors/sindresorhus" + } + }, + "node_modules/is-number": { + "version": "7.0.0", + "resolved": "https://registry.npmjs.org/is-number/-/is-number-7.0.0.tgz", + "integrity": "sha512-41Cifkg6e8TylSpdtTpeLVMqvSBEVzTttHvERD741+pnZ8ANv0004MRL43QKPDlK9cGvNp6NZWZUBlbGXYxxng==", + "dev": true, + "engines": { + "node": ">=0.12.0" + } + }, + "node_modules/is-plain-obj": { + "version": "3.0.0", + "resolved": "https://registry.npmjs.org/is-plain-obj/-/is-plain-obj-3.0.0.tgz", + "integrity": "sha512-gwsOE28k+23GP1B6vFl1oVh/WOzmawBrKwo5Ev6wMKzPkaXaCDIQKzLnvsA42DRlbVTWorkgTKIviAKCWkfUwA==", + "dev": true, + "engines": { + "node": ">=10" + }, + "funding": { + "url": "https://github.com/sponsors/sindresorhus" + } + }, + "node_modules/is-plain-object": { + "version": "2.0.4", + "resolved": "https://registry.npmjs.org/is-plain-object/-/is-plain-object-2.0.4.tgz", + "integrity": "sha512-h5PpgXkWitc38BBMYawTYMWJHFZJVnBquFE57xFpjB8pJFiF6gZ+bU+WyI/yqXiFR5mdLsgYNaPe8uao6Uv9Og==", + "dev": true, + "dependencies": { + "isobject": "^3.0.1" + }, + "engines": { + "node": ">=0.10.0" + } + }, + "node_modules/is-stream": { + "version": "2.0.1", + "resolved": "https://registry.npmjs.org/is-stream/-/is-stream-2.0.1.tgz", + "integrity": "sha512-hFoiJiTl63nn+kstHGBtewWSKnQLpyb155KHheA1l39uvtO9nWIop1p3udqPcUd/xbF1VLMO4n7OI6p7RbngDg==", + "dev": true, + "engines": { + "node": ">=8" + }, + "funding": { + "url": "https://github.com/sponsors/sindresorhus" + } + }, + "node_modules/is-wsl": { + "version": "3.1.0", + "resolved": "https://registry.npmjs.org/is-wsl/-/is-wsl-3.1.0.tgz", + "integrity": "sha512-UcVfVfaK4Sc4m7X3dUSoHoozQGBEFeDC+zVo06t98xe8CzHSZZBekNXH+tu0NalHolcJ/QAGqS46Hef7QXBIMw==", + "dev": true, + "dependencies": { + "is-inside-container": "^1.0.0" + }, + "engines": { + "node": ">=16" + }, + "funding": { + "url": "https://github.com/sponsors/sindresorhus" + } + }, + "node_modules/isarray": { + "version": "1.0.0", + "resolved": "https://registry.npmjs.org/isarray/-/isarray-1.0.0.tgz", + "integrity": "sha512-VLghIWNM6ELQzo7zwmcg0NmTVyWKYjvIeM83yjp0wRDTmUnrM678fQbcKBo6n2CJEF0szoG//ytg+TKla89ALQ==", + "dev": true + }, + "node_modules/isexe": { + "version": "2.0.0", + "resolved": "https://registry.npmjs.org/isexe/-/isexe-2.0.0.tgz", + "integrity": "sha512-RHxMLp9lnKHGHRng9QFhRCMbYAcVpn69smSGcq3f36xjgVVWThj4qqLbTLlq7Ssj8B+fIQ1EuCEGI2lKsyQeIw==", + "dev": true + }, + "node_modules/isobject": { + "version": "3.0.1", + "resolved": "https://registry.npmjs.org/isobject/-/isobject-3.0.1.tgz", + "integrity": "sha512-WhB9zCku7EGTj/HQQRz5aUQEUeoQZH2bWcltRErOpymJ4boYE6wL9Tbr23krRPSZ+C5zqNSrSw+Cc7sZZ4b7vg==", + "dev": true, + "engines": { + "node": ">=0.10.0" + } + }, + "node_modules/jackspeak": { + "version": "3.4.2", + "resolved": "https://registry.npmjs.org/jackspeak/-/jackspeak-3.4.2.tgz", + "integrity": "sha512-qH3nOSj8q/8+Eg8LUPOq3C+6HWkpUioIjDsq1+D4zY91oZvpPttw8GwtF1nReRYKXl+1AORyFqtm2f5Q1SB6/Q==", + "dev": true, + "dependencies": { + "@isaacs/cliui": "^8.0.2" + }, + "engines": { + "node": "14 >=14.21 || 16 >=16.20 || >=18" + }, + "funding": { + "url": "https://github.com/sponsors/isaacs" + }, + "optionalDependencies": { + "@pkgjs/parseargs": "^0.11.0" + } + }, + "node_modules/jest-worker": { + "version": "27.5.1", + "resolved": "https://registry.npmjs.org/jest-worker/-/jest-worker-27.5.1.tgz", + "integrity": "sha512-7vuh85V5cdDofPyxn58nrPjBktZo0u9x1g8WtjQol+jZDaE+fhN+cIvTj11GndBnMnyfrUOG1sZQxCdjKh+DKg==", + "dev": true, + "dependencies": { + "@types/node": "*", + "merge-stream": "^2.0.0", + "supports-color": "^8.0.0" + }, + "engines": { + "node": ">= 10.13.0" + } + }, + "node_modules/json-parse-even-better-errors": { + "version": "2.3.1", + "resolved": "https://registry.npmjs.org/json-parse-even-better-errors/-/json-parse-even-better-errors-2.3.1.tgz", + "integrity": "sha512-xyFwyhro/JEof6Ghe2iz2NcXoj2sloNsWr/XsERDK/oiPCfaNhl5ONfp+jQdAZRQQ0IJWNzH9zIZF7li91kh2w==", + "dev": true + }, + "node_modules/json-schema-traverse": { + "version": "0.4.1", + "resolved": "https://registry.npmjs.org/json-schema-traverse/-/json-schema-traverse-0.4.1.tgz", + "integrity": "sha512-xbbCH5dCYU5T8LcEhhuh7HJ88HXuW3qsI3Y0zOZFKfZEHcpWiHU/Jxzk629Brsab/mMiHQti9wMP+845RPe3Vg==", + "dev": true + }, + "node_modules/kind-of": { + "version": "6.0.3", + "resolved": "https://registry.npmjs.org/kind-of/-/kind-of-6.0.3.tgz", + "integrity": "sha512-dcS1ul+9tmeD95T+x28/ehLgd9mENa3LsvDTtzm3vyBEO7RPptvAD+t44WVXaUjTBRcrpFeFlC8WCruUR456hw==", + "dev": true, + "engines": { + "node": ">=0.10.0" + } + }, + "node_modules/launch-editor": { + "version": "2.8.0", + "resolved": "https://registry.npmjs.org/launch-editor/-/launch-editor-2.8.0.tgz", + "integrity": "sha512-vJranOAJrI/llyWGRQqiDM+adrw+k83fvmmx3+nV47g3+36xM15jE+zyZ6Ffel02+xSvuM0b2GDRosXZkbb6wA==", + "dev": true, + "dependencies": { + "picocolors": "^1.0.0", + "shell-quote": "^1.8.1" + } + }, + "node_modules/loader-runner": { + "version": "4.3.0", + "resolved": "https://registry.npmjs.org/loader-runner/-/loader-runner-4.3.0.tgz", + "integrity": "sha512-3R/1M+yS3j5ou80Me59j7F9IMs4PXs3VqRrm0TU3AbKPxlmpoY1TNscJV/oGJXo8qCatFGTfDbY6W6ipGOYXfg==", + "dev": true, + "engines": { + "node": ">=6.11.5" + } + }, + "node_modules/locate-path": { + "version": "5.0.0", + "resolved": "https://registry.npmjs.org/locate-path/-/locate-path-5.0.0.tgz", + "integrity": "sha512-t7hw9pI+WvuwNJXwk5zVHpyhIqzg2qTlklJOf0mVxGSbe3Fp2VieZcduNYjaLDoy6p9uGpQEGWG87WpMKlNq8g==", + "dev": true, + "dependencies": { + "p-locate": "^4.1.0" + }, + "engines": { + "node": ">=8" + } + }, + "node_modules/loglevel": { + "version": "1.9.1", + "resolved": "https://registry.npmjs.org/loglevel/-/loglevel-1.9.1.tgz", + "integrity": "sha512-hP3I3kCrDIMuRwAwHltphhDM1r8i55H33GgqjXbrisuJhF4kRhW1dNuxsRklp4bXl8DSdLaNLuiL4A/LWRfxvg==", + "engines": { + "node": ">= 0.6.0" + }, + "funding": { + "type": "tidelift", + "url": "https://tidelift.com/funding/github/npm/loglevel" + } + }, + "node_modules/lru-cache": { + "version": "10.4.3", + "resolved": "https://registry.npmjs.org/lru-cache/-/lru-cache-10.4.3.tgz", + "integrity": "sha512-JNAzZcXrCt42VGLuYz0zfAzDfAvJWW6AfYlDBQyDV5DClI2m5sAmK+OIO7s59XfsRsWHp02jAJrRadPRGTt6SQ==", + "dev": true + }, + "node_modules/media-typer": { + "version": "0.3.0", + "resolved": "https://registry.npmjs.org/media-typer/-/media-typer-0.3.0.tgz", + "integrity": "sha512-dq+qelQ9akHpcOl/gUVRTxVIOkAJ1wR3QAvb4RsVjS8oVoFjDGTc679wJYmUmknUF5HwMLOgb5O+a3KxfWapPQ==", + "dev": true, + "engines": { + "node": ">= 0.6" + } + }, + "node_modules/memfs": { + "version": "4.9.3", + "resolved": "https://registry.npmjs.org/memfs/-/memfs-4.9.3.tgz", + "integrity": "sha512-bsYSSnirtYTWi1+OPMFb0M048evMKyUYe0EbtuGQgq6BVQM1g1W8/KIUJCCvjgI/El0j6Q4WsmMiBwLUBSw8LA==", + "dev": true, + "dependencies": { + "@jsonjoy.com/json-pack": "^1.0.3", + "@jsonjoy.com/util": "^1.1.2", + "tree-dump": "^1.0.1", + "tslib": "^2.0.0" + }, + "engines": { + "node": ">= 4.0.0" + }, + "funding": { + "type": "github", + "url": "https://github.com/sponsors/streamich" + } + }, + "node_modules/merge-descriptors": { + "version": "1.0.1", + "resolved": "https://registry.npmjs.org/merge-descriptors/-/merge-descriptors-1.0.1.tgz", + "integrity": "sha512-cCi6g3/Zr1iqQi6ySbseM1Xvooa98N0w31jzUYrXPX2xqObmFGHJ0tQ5u74H3mVh7wLouTseZyYIq39g8cNp1w==", + "dev": true + }, + "node_modules/merge-stream": { + "version": "2.0.0", + "resolved": "https://registry.npmjs.org/merge-stream/-/merge-stream-2.0.0.tgz", + "integrity": "sha512-abv/qOcuPfk3URPfDzmZU1LKmuw8kT+0nIHvKrKgFrwifol/doWcdA4ZqsWQ8ENrFKkd67Mfpo/LovbIUsbt3w==", + "dev": true + }, + "node_modules/merge2": { + "version": "1.4.1", + "resolved": "https://registry.npmjs.org/merge2/-/merge2-1.4.1.tgz", + "integrity": "sha512-8q7VEgMJW4J8tcfVPy8g09NcQwZdbwFEqhe/WZkoIzjn/3TGDwtOCYtXGxA3O8tPzpczCCDgv+P2P5y00ZJOOg==", + "dev": true, + "engines": { + "node": ">= 8" + } + }, + "node_modules/methods": { + "version": "1.1.2", + "resolved": "https://registry.npmjs.org/methods/-/methods-1.1.2.tgz", + "integrity": "sha512-iclAHeNqNm68zFtnZ0e+1L2yUIdvzNoauKU4WBA3VvH/vPFieF7qfRlwUZU+DA9P9bPXIS90ulxoUoCH23sV2w==", + "dev": true, + "engines": { + "node": ">= 0.6" + } + }, + "node_modules/micromatch": { + "version": "4.0.7", + "resolved": "https://registry.npmjs.org/micromatch/-/micromatch-4.0.7.tgz", + "integrity": "sha512-LPP/3KorzCwBxfeUuZmaR6bG2kdeHSbe0P2tY3FLRU4vYrjYz5hI4QZwV0njUx3jeuKe67YukQ1LSPZBKDqO/Q==", + "dev": true, + "dependencies": { + "braces": "^3.0.3", + "picomatch": "^2.3.1" + }, + "engines": { + "node": ">=8.6" + } + }, + "node_modules/mime": { + "version": "1.6.0", + "resolved": "https://registry.npmjs.org/mime/-/mime-1.6.0.tgz", + "integrity": "sha512-x0Vn8spI+wuJ1O6S7gnbaQg8Pxh4NNHb7KSINmEWKiPE4RKOplvijn+NkmYmmRgP68mc70j2EbeTFRsrswaQeg==", + "dev": true, + "bin": { + "mime": "cli.js" + }, + "engines": { + "node": ">=4" + } + }, + "node_modules/mime-db": { + "version": "1.52.0", + "resolved": "https://registry.npmjs.org/mime-db/-/mime-db-1.52.0.tgz", + "integrity": "sha512-sPU4uV7dYlvtWJxwwxHD0PuihVNiE7TyAbQ5SWxDCB9mUYvOgroQOwYQQOKPJ8CIbE+1ETVlOoK1UC2nU3gYvg==", + "engines": { + "node": ">= 0.6" + } + }, + "node_modules/mime-types": { + "version": "2.1.35", + "resolved": "https://registry.npmjs.org/mime-types/-/mime-types-2.1.35.tgz", + "integrity": "sha512-ZDY+bPm5zTTF+YpCrAU9nK0UgICYPT0QtT1NZWFv4s++TNkcgVaT0g6+4R2uI4MjQjzysHB1zxuWL50hzaeXiw==", + "dependencies": { + "mime-db": "1.52.0" + }, + "engines": { + "node": ">= 0.6" + } + }, + "node_modules/mimic-fn": { + "version": "2.1.0", + "resolved": "https://registry.npmjs.org/mimic-fn/-/mimic-fn-2.1.0.tgz", + "integrity": "sha512-OqbOk5oEQeAZ8WXWydlu9HJjz9WVdEIvamMCcXmuqUYjTknH/sqsWvhQ3vgwKFRR1HpjvNBKQ37nbJgYzGqGcg==", + "dev": true, + "engines": { + "node": ">=6" + } + }, + "node_modules/mini-css-extract-plugin": { + "version": "2.9.0", + "resolved": "https://registry.npmjs.org/mini-css-extract-plugin/-/mini-css-extract-plugin-2.9.0.tgz", + "integrity": "sha512-Zs1YsZVfemekSZG+44vBsYTLQORkPMwnlv+aehcxK/NLKC+EGhDB39/YePYYqx/sTk6NnYpuqikhSn7+JIevTA==", + "dev": true, + "dependencies": { + "schema-utils": "^4.0.0", + "tapable": "^2.2.1" + }, + "engines": { + "node": ">= 12.13.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/webpack" + }, + "peerDependencies": { + "webpack": "^5.0.0" + } + }, + "node_modules/mini-css-extract-plugin/node_modules/ajv": { + "version": "8.16.0", + "resolved": "https://registry.npmjs.org/ajv/-/ajv-8.16.0.tgz", + "integrity": "sha512-F0twR8U1ZU67JIEtekUcLkXkoO5mMMmgGD8sK/xUFzJ805jxHQl92hImFAqqXMyMYjSPOyUPAwHYhB72g5sTXw==", + "dev": true, + "dependencies": { + "fast-deep-equal": "^3.1.3", + "json-schema-traverse": "^1.0.0", + "require-from-string": "^2.0.2", + "uri-js": "^4.4.1" + }, + "funding": { + "type": "github", + "url": "https://github.com/sponsors/epoberezkin" + } + }, + "node_modules/mini-css-extract-plugin/node_modules/ajv-keywords": { + "version": "5.1.0", + "resolved": "https://registry.npmjs.org/ajv-keywords/-/ajv-keywords-5.1.0.tgz", + "integrity": "sha512-YCS/JNFAUyr5vAuhk1DWm1CBxRHW9LbJ2ozWeemrIqpbsqKjHVxYPyi5GC0rjZIT5JxJ3virVTS8wk4i/Z+krw==", + "dev": true, + "dependencies": { + "fast-deep-equal": "^3.1.3" + }, + "peerDependencies": { + "ajv": "^8.8.2" + } + }, + "node_modules/mini-css-extract-plugin/node_modules/json-schema-traverse": { + "version": "1.0.0", + "resolved": "https://registry.npmjs.org/json-schema-traverse/-/json-schema-traverse-1.0.0.tgz", + "integrity": "sha512-NM8/P9n3XjXhIZn1lLhkFaACTOURQXjWhV4BA/RnOv8xvgqtqpAX9IO4mRQxSx1Rlo4tqzeqb0sOlruaOy3dug==", + "dev": true + }, + "node_modules/mini-css-extract-plugin/node_modules/schema-utils": { + "version": "4.2.0", + "resolved": "https://registry.npmjs.org/schema-utils/-/schema-utils-4.2.0.tgz", + "integrity": "sha512-L0jRsrPpjdckP3oPug3/VxNKt2trR8TcabrM6FOAAlvC/9Phcmm+cuAgTlxBqdBR1WJx7Naj9WHw+aOmheSVbw==", + "dev": true, + "dependencies": { + "@types/json-schema": "^7.0.9", + "ajv": "^8.9.0", + "ajv-formats": "^2.1.1", + "ajv-keywords": "^5.1.0" + }, + "engines": { + "node": ">= 12.13.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/webpack" + } + }, + "node_modules/minimalistic-assert": { + "version": "1.0.1", + "resolved": "https://registry.npmjs.org/minimalistic-assert/-/minimalistic-assert-1.0.1.tgz", + "integrity": "sha512-UtJcAD4yEaGtjPezWuO9wC4nwUnVH/8/Im3yEHQP4b67cXlD/Qr9hdITCU1xDbSEXg2XKNaP8jsReV7vQd00/A==", + "dev": true + }, + "node_modules/minimatch": { + "version": "9.0.5", + "resolved": "https://registry.npmjs.org/minimatch/-/minimatch-9.0.5.tgz", + "integrity": "sha512-G6T0ZX48xgozx7587koeX9Ys2NYy6Gmv//P89sEte9V9whIapMNF4idKxnW2QtCcLiTWlb/wfCabAtAFWhhBow==", + "dev": true, + "dependencies": { + "brace-expansion": "^2.0.1" + }, + "engines": { + "node": ">=16 || 14 >=14.17" + }, + "funding": { + "url": "https://github.com/sponsors/isaacs" + } + }, + "node_modules/minipass": { + "version": "7.1.2", + "resolved": "https://registry.npmjs.org/minipass/-/minipass-7.1.2.tgz", + "integrity": "sha512-qOOzS1cBTWYF4BH8fVePDBOO9iptMnGUEZwNc/cMWnTV2nVLZ7VoNWEPHkYczZA0pdoA7dl6e7FL659nX9S2aw==", + "dev": true, + "engines": { + "node": ">=16 || 14 >=14.17" + } + }, + "node_modules/mkdirp": { + "version": "0.3.0", + "resolved": "https://registry.npmjs.org/mkdirp/-/mkdirp-0.3.0.tgz", + "integrity": "sha512-OHsdUcVAQ6pOtg5JYWpCBo9W/GySVuwvP9hueRMW7UqshC0tbfzLv8wjySTPm3tfUZ/21CE9E1pJagOA91Pxew==", + "deprecated": "Legacy versions of mkdirp are no longer supported. Please update to mkdirp 1.x. (Note that the API surface has changed to use Promises in 1.x.)", + "engines": { + "node": "*" + } + }, + "node_modules/ms": { + "version": "2.0.0", + "resolved": "https://registry.npmjs.org/ms/-/ms-2.0.0.tgz", + "integrity": "sha512-Tpp60P6IUJDTuOq/5Z8cdskzJujfwqfOTkrwIwj7IRISpnkJnT6SyJ4PCPnGMoFjC9ddhal5KVIYtAt97ix05A==", + "dev": true + }, + "node_modules/multicast-dns": { + "version": "7.2.5", + "resolved": "https://registry.npmjs.org/multicast-dns/-/multicast-dns-7.2.5.tgz", + "integrity": "sha512-2eznPJP8z2BFLX50tf0LuODrpINqP1RVIm/CObbTcBRITQgmC/TjcREF1NeTBzIcR5XO/ukWo+YHOjBbFwIupg==", + "dev": true, + "dependencies": { + "dns-packet": "^5.2.2", + "thunky": "^1.0.2" + }, + "bin": { + "multicast-dns": "cli.js" + } + }, + "node_modules/nanoid": { + "version": "3.3.7", + "resolved": "https://registry.npmjs.org/nanoid/-/nanoid-3.3.7.tgz", + "integrity": "sha512-eSRppjcPIatRIMC1U6UngP8XFcz8MQWGQdt1MTBQ7NaAmvXDfvNxbvWV3x2y6CdEUciCSsDHDQZbhYaB8QEo2g==", + "dev": true, + "funding": [ + { + "type": "github", + "url": "https://github.com/sponsors/ai" + } + ], + "bin": { + "nanoid": "bin/nanoid.cjs" + }, + "engines": { + "node": "^10 || ^12 || ^13.7 || ^14 || >=15.0.1" + } + }, + "node_modules/negotiator": { + "version": "0.6.3", + "resolved": "https://registry.npmjs.org/negotiator/-/negotiator-0.6.3.tgz", + "integrity": "sha512-+EUsqGPLsM+j/zdChZjsnX51g4XrHFOIXwfnCVPGlQk/k5giakcKsuxCObBRu6DSm9opw/O6slWbJdghQM4bBg==", + "dev": true, + "engines": { + "node": ">= 0.6" + } + }, + "node_modules/neo-async": { + "version": "2.6.2", + "resolved": "https://registry.npmjs.org/neo-async/-/neo-async-2.6.2.tgz", + "integrity": "sha512-Yd3UES5mWCSqR+qNT93S3UoYUkqAZ9lLg8a7g9rimsWmYGK8cVToA4/sF3RrshdyV3sAGMXVUmpMYOw+dLpOuw==", + "dev": true + }, + "node_modules/node-forge": { + "version": "1.3.1", + "resolved": "https://registry.npmjs.org/node-forge/-/node-forge-1.3.1.tgz", + "integrity": "sha512-dPEtOeMvF9VMcYV/1Wb8CPoVAXtp6MKMlcbAt4ddqmGqUJ6fQZFXkNZNkNlfevtNkGtaSoXf/vNNNSvgrdXwtA==", + "dev": true, + "engines": { + "node": ">= 6.13.0" + } + }, + "node_modules/node-releases": { + "version": "2.0.14", + "resolved": "https://registry.npmjs.org/node-releases/-/node-releases-2.0.14.tgz", + "integrity": "sha512-y10wOWt8yZpqXmOgRo77WaHEmhYQYGNA6y421PKsKYWEK8aW+cqAphborZDhqfyKrbZEN92CN1X2KbafY2s7Yw==", + "dev": true + }, + "node_modules/nopt": { + "version": "1.0.10", + "resolved": "https://registry.npmjs.org/nopt/-/nopt-1.0.10.tgz", + "integrity": "sha512-NWmpvLSqUrgrAC9HCuxEvb+PSloHpqVu+FqcO4eeF2h5qYRhA7ev6KvelyQAKtegUbC6RypJnlEOhd8vloNKYg==", + "dependencies": { + "abbrev": "1" + }, + "bin": { + "nopt": "bin/nopt.js" + }, + "engines": { + "node": "*" + } + }, + "node_modules/normalize-path": { + "version": "3.0.0", + "resolved": "https://registry.npmjs.org/normalize-path/-/normalize-path-3.0.0.tgz", + "integrity": "sha512-6eZs5Ls3WtCisHWp9S2GUy8dqkpGi4BVSz3GaqiE6ezub0512ESztXUwUB6C6IKbQkY2Pnb/mD4WYojCRwcwLA==", + "dev": true, + "engines": { + "node": ">=0.10.0" + } + }, + "node_modules/npm-run-path": { + "version": "4.0.1", + "resolved": "https://registry.npmjs.org/npm-run-path/-/npm-run-path-4.0.1.tgz", + "integrity": "sha512-S48WzZW777zhNIrn7gxOlISNAqi9ZC/uQFnRdbeIHhZhCA6UqpkOT8T1G7BvfdgP4Er8gF4sUbaS0i7QvIfCWw==", + "dev": true, + "dependencies": { + "path-key": "^3.0.0" + }, + "engines": { + "node": ">=8" + } + }, + "node_modules/object-inspect": { + "version": "1.13.2", + "resolved": "https://registry.npmjs.org/object-inspect/-/object-inspect-1.13.2.tgz", + "integrity": "sha512-IRZSRuzJiynemAXPYtPe5BoI/RESNYR7TYm50MC5Mqbd3Jmw5y790sErYw3V6SryFJD64b74qQQs9wn5Bg/k3g==", + "dev": true, + "engines": { + "node": ">= 0.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/obuf": { + "version": "1.1.2", + "resolved": "https://registry.npmjs.org/obuf/-/obuf-1.1.2.tgz", + "integrity": "sha512-PX1wu0AmAdPqOL1mWhqmlOd8kOIZQwGZw6rh7uby9fTc5lhaOWFLX3I6R1hrF9k3zUY40e6igsLGkDXK92LJNg==", + "dev": true + }, + "node_modules/on-finished": { + "version": "2.4.1", + "resolved": "https://registry.npmjs.org/on-finished/-/on-finished-2.4.1.tgz", + "integrity": "sha512-oVlzkg3ENAhCk2zdv7IJwd/QUD4z2RxRwpkcGY8psCVcCYZNq4wYnVWALHM+brtuJjePWiYF/ClmuDr8Ch5+kg==", + "dev": true, + "dependencies": { + "ee-first": "1.1.1" + }, + "engines": { + "node": ">= 0.8" + } + }, + "node_modules/on-headers": { + "version": "1.0.2", + "resolved": "https://registry.npmjs.org/on-headers/-/on-headers-1.0.2.tgz", + "integrity": "sha512-pZAE+FJLoyITytdqK0U5s+FIpjN0JP3OzFi/u8Rx+EV5/W+JTWGXG8xFzevE7AjBfDqHv/8vL8qQsIhHnqRkrA==", + "dev": true, + "engines": { + "node": ">= 0.8" + } + }, + "node_modules/onetime": { + "version": "5.1.2", + "resolved": "https://registry.npmjs.org/onetime/-/onetime-5.1.2.tgz", + "integrity": "sha512-kbpaSSGJTWdAY5KPVeMOKXSrPtr8C8C7wodJbcsd51jRnmD+GZu8Y0VoU6Dm5Z4vWr0Ig/1NKuWRKf7j5aaYSg==", + "dev": true, + "dependencies": { + "mimic-fn": "^2.1.0" + }, + "engines": { + "node": ">=6" + }, + "funding": { + "url": "https://github.com/sponsors/sindresorhus" + } + }, + "node_modules/open": { + "version": "10.1.0", + "resolved": "https://registry.npmjs.org/open/-/open-10.1.0.tgz", + "integrity": "sha512-mnkeQ1qP5Ue2wd+aivTD3NHd/lZ96Lu0jgf0pwktLPtx6cTZiH7tyeGRRHs0zX0rbrahXPnXlUnbeXyaBBuIaw==", + "dev": true, + "dependencies": { + "default-browser": "^5.2.1", + "define-lazy-prop": "^3.0.0", + "is-inside-container": "^1.0.0", + "is-wsl": "^3.1.0" + }, + "engines": { + "node": ">=18" + }, + "funding": { + "url": "https://github.com/sponsors/sindresorhus" + } + }, + "node_modules/p-limit": { + "version": "2.3.0", + "resolved": "https://registry.npmjs.org/p-limit/-/p-limit-2.3.0.tgz", + "integrity": "sha512-//88mFWSJx8lxCzwdAABTJL2MyWB12+eIY7MDL2SqLmAkeKU9qxRvWuSyTjm3FUmpBEMuFfckAIqEaVGUDxb6w==", + "dev": true, + "dependencies": { + "p-try": "^2.0.0" + }, + "engines": { + "node": ">=6" + }, + "funding": { + "url": "https://github.com/sponsors/sindresorhus" + } + }, + "node_modules/p-locate": { + "version": "4.1.0", + "resolved": "https://registry.npmjs.org/p-locate/-/p-locate-4.1.0.tgz", + "integrity": "sha512-R79ZZ/0wAxKGu3oYMlz8jy/kbhsNrS7SKZ7PxEHBgJ5+F2mtFW2fK2cOtBh1cHYkQsbzFV7I+EoRKe6Yt0oK7A==", + "dev": true, + "dependencies": { + "p-limit": "^2.2.0" + }, + "engines": { + "node": ">=8" + } + }, + "node_modules/p-retry": { + "version": "6.2.0", + "resolved": "https://registry.npmjs.org/p-retry/-/p-retry-6.2.0.tgz", + "integrity": "sha512-JA6nkq6hKyWLLasXQXUrO4z8BUZGUt/LjlJxx8Gb2+2ntodU/SS63YZ8b0LUTbQ8ZB9iwOfhEPhg4ykKnn2KsA==", + "dev": true, + "dependencies": { + "@types/retry": "0.12.2", + "is-network-error": "^1.0.0", + "retry": "^0.13.1" + }, + "engines": { + "node": ">=16.17" + }, + "funding": { + "url": "https://github.com/sponsors/sindresorhus" + } + }, + "node_modules/p-try": { + "version": "2.2.0", + "resolved": "https://registry.npmjs.org/p-try/-/p-try-2.2.0.tgz", + "integrity": "sha512-R4nPAVTAU0B9D35/Gk3uJf/7XYbQcyohSKdvAxIRSNghFl4e71hVoGnBNQz9cWaXxO2I10KTC+3jMdvvoKw6dQ==", + "dev": true, + "engines": { + "node": ">=6" + } + }, + "node_modules/package-json-from-dist": { + "version": "1.0.0", + "resolved": "https://registry.npmjs.org/package-json-from-dist/-/package-json-from-dist-1.0.0.tgz", + "integrity": "sha512-dATvCeZN/8wQsGywez1mzHtTlP22H8OEfPrVMLNr4/eGa+ijtLn/6M5f0dY8UKNrC2O9UCU6SSoG3qRKnt7STw==", + "dev": true + }, + "node_modules/parseurl": { + "version": "1.3.3", + "resolved": "https://registry.npmjs.org/parseurl/-/parseurl-1.3.3.tgz", + "integrity": "sha512-CiyeOxFT/JZyN5m0z9PfXw4SCBJ6Sygz1Dpl0wqjlhDEGGBP1GnsUVEL0p63hoG1fcj3fHynXi9NYO4nWOL+qQ==", + "dev": true, + "engines": { + "node": ">= 0.8" + } + }, + "node_modules/path-exists": { + "version": "4.0.0", + "resolved": "https://registry.npmjs.org/path-exists/-/path-exists-4.0.0.tgz", + "integrity": "sha512-ak9Qy5Q7jYb2Wwcey5Fpvg2KoAc/ZIhLSLOSBmRmygPsGwkVVt0fZa0qrtMz+m6tJTAHfZQ8FnmB4MG4LWy7/w==", + "dev": true, + "engines": { + "node": ">=8" + } + }, + "node_modules/path-key": { + "version": "3.1.1", + "resolved": "https://registry.npmjs.org/path-key/-/path-key-3.1.1.tgz", + "integrity": "sha512-ojmeN0qd+y0jszEtoY48r0Peq5dwMEkIlCOu6Q5f41lfkswXuKtYrhgoTpLnyIcHm24Uhqx+5Tqm2InSwLhE6Q==", + "dev": true, + "engines": { + "node": ">=8" + } + }, + "node_modules/path-parse": { + "version": "1.0.7", + "resolved": "https://registry.npmjs.org/path-parse/-/path-parse-1.0.7.tgz", + "integrity": "sha512-LDJzPVEEEPR+y48z93A0Ed0yXb8pAByGWo/k5YYdYgpY2/2EsOsksJrq7lOHxryrVOn1ejG6oAp8ahvOIQD8sw==", + "dev": true + }, + "node_modules/path-scurry": { + "version": "1.11.1", + "resolved": "https://registry.npmjs.org/path-scurry/-/path-scurry-1.11.1.tgz", + "integrity": "sha512-Xa4Nw17FS9ApQFJ9umLiJS4orGjm7ZzwUrwamcGQuHSzDyth9boKDaycYdDcZDuqYATXw4HFXgaqWTctW/v1HA==", + "dev": true, + "dependencies": { + "lru-cache": "^10.2.0", + "minipass": "^5.0.0 || ^6.0.2 || ^7.0.0" + }, + "engines": { + "node": ">=16 || 14 >=14.18" + }, + "funding": { + "url": "https://github.com/sponsors/isaacs" + } + }, + "node_modules/path-to-regexp": { + "version": "0.1.7", + "resolved": "https://registry.npmjs.org/path-to-regexp/-/path-to-regexp-0.1.7.tgz", + "integrity": "sha512-5DFkuoqlv1uYQKxy8omFBeJPQcdoE07Kv2sferDCrAq1ohOU+MSDswDIbnx3YAM60qIOnYa53wBhXW0EbMonrQ==", + "dev": true + }, + "node_modules/path-type": { + "version": "5.0.0", + "resolved": "https://registry.npmjs.org/path-type/-/path-type-5.0.0.tgz", + "integrity": "sha512-5HviZNaZcfqP95rwpv+1HDgUamezbqdSYTyzjTvwtJSnIH+3vnbmWsItli8OFEndS984VT55M3jduxZbX351gg==", + "dev": true, + "engines": { + "node": ">=12" + }, + "funding": { + "url": "https://github.com/sponsors/sindresorhus" + } + }, + "node_modules/picocolors": { + "version": "1.0.1", + "resolved": "https://registry.npmjs.org/picocolors/-/picocolors-1.0.1.tgz", + "integrity": "sha512-anP1Z8qwhkbmu7MFP5iTt+wQKXgwzf7zTyGlcdzabySa9vd0Xt392U0rVmz9poOaBj0uHJKyyo9/upk0HrEQew==", + "dev": true + }, + "node_modules/picomatch": { + "version": "2.3.1", + "resolved": "https://registry.npmjs.org/picomatch/-/picomatch-2.3.1.tgz", + "integrity": "sha512-JU3teHTNjmE2VCGFzuY8EXzCDVwEqB2a8fsIvwaStHhAWJEeVd1o1QD80CU6+ZdEXXSLbSsuLwJjkCBWqRQUVA==", + "dev": true, + "engines": { + "node": ">=8.6" + }, + "funding": { + "url": "https://github.com/sponsors/jonschlinkert" + } + }, + "node_modules/pkg-dir": { + "version": "4.2.0", + "resolved": "https://registry.npmjs.org/pkg-dir/-/pkg-dir-4.2.0.tgz", + "integrity": "sha512-HRDzbaKjC+AOWVXxAU/x54COGeIv9eb+6CkDSQoNTt4XyWoIJvuPsXizxu/Fr23EiekbtZwmh1IcIG/l/a10GQ==", + "dev": true, + "dependencies": { + "find-up": "^4.0.0" + }, + "engines": { + "node": ">=8" + } + }, + "node_modules/postcss": { + "version": "8.4.39", + "resolved": "https://registry.npmjs.org/postcss/-/postcss-8.4.39.tgz", + "integrity": "sha512-0vzE+lAiG7hZl1/9I8yzKLx3aR9Xbof3fBHKunvMfOCYAtMhrsnccJY2iTURb9EZd5+pLuiNV9/c/GZJOHsgIw==", + "dev": true, + "funding": [ + { + "type": "opencollective", + "url": "https://opencollective.com/postcss/" + }, + { + "type": "tidelift", + "url": "https://tidelift.com/funding/github/npm/postcss" + }, + { + "type": "github", + "url": "https://github.com/sponsors/ai" + } + ], + "dependencies": { + "nanoid": "^3.3.7", + "picocolors": "^1.0.1", + "source-map-js": "^1.2.0" + }, + "engines": { + "node": "^10 || ^12 || >=14" + } + }, + "node_modules/postcss-modules-extract-imports": { + "version": "3.1.0", + "resolved": "https://registry.npmjs.org/postcss-modules-extract-imports/-/postcss-modules-extract-imports-3.1.0.tgz", + "integrity": "sha512-k3kNe0aNFQDAZGbin48pL2VNidTF0w4/eASDsxlyspobzU3wZQLOGj7L9gfRe0Jo9/4uud09DsjFNH7winGv8Q==", + "dev": true, + "engines": { + "node": "^10 || ^12 || >= 14" + }, + "peerDependencies": { + "postcss": "^8.1.0" + } + }, + "node_modules/postcss-modules-local-by-default": { + "version": "4.0.5", + "resolved": "https://registry.npmjs.org/postcss-modules-local-by-default/-/postcss-modules-local-by-default-4.0.5.tgz", + "integrity": "sha512-6MieY7sIfTK0hYfafw1OMEG+2bg8Q1ocHCpoWLqOKj3JXlKu4G7btkmM/B7lFubYkYWmRSPLZi5chid63ZaZYw==", + "dev": true, + "dependencies": { + "icss-utils": "^5.0.0", + "postcss-selector-parser": "^6.0.2", + "postcss-value-parser": "^4.1.0" + }, + "engines": { + "node": "^10 || ^12 || >= 14" + }, + "peerDependencies": { + "postcss": "^8.1.0" + } + }, + "node_modules/postcss-modules-scope": { + "version": "3.2.0", + "resolved": "https://registry.npmjs.org/postcss-modules-scope/-/postcss-modules-scope-3.2.0.tgz", + "integrity": "sha512-oq+g1ssrsZOsx9M96c5w8laRmvEu9C3adDSjI8oTcbfkrTE8hx/zfyobUoWIxaKPO8bt6S62kxpw5GqypEw1QQ==", + "dev": true, + "dependencies": { + "postcss-selector-parser": "^6.0.4" + }, + "engines": { + "node": "^10 || ^12 || >= 14" + }, + "peerDependencies": { + "postcss": "^8.1.0" + } + }, + "node_modules/postcss-modules-values": { + "version": "4.0.0", + "resolved": "https://registry.npmjs.org/postcss-modules-values/-/postcss-modules-values-4.0.0.tgz", + "integrity": "sha512-RDxHkAiEGI78gS2ofyvCsu7iycRv7oqw5xMWn9iMoR0N/7mf9D50ecQqUo5BZ9Zh2vH4bCUR/ktCqbB9m8vJjQ==", + "dev": true, + "dependencies": { + "icss-utils": "^5.0.0" + }, + "engines": { + "node": "^10 || ^12 || >= 14" + }, + "peerDependencies": { + "postcss": "^8.1.0" + } + }, + "node_modules/postcss-selector-parser": { + "version": "6.1.0", + "resolved": "https://registry.npmjs.org/postcss-selector-parser/-/postcss-selector-parser-6.1.0.tgz", + "integrity": "sha512-UMz42UD0UY0EApS0ZL9o1XnLhSTtvvvLe5Dc2H2O56fvRZi+KulDyf5ctDhhtYJBGKStV2FL1fy6253cmLgqVQ==", + "dev": true, + "dependencies": { + "cssesc": "^3.0.0", + "util-deprecate": "^1.0.2" + }, + "engines": { + "node": ">=4" + } + }, + "node_modules/postcss-value-parser": { + "version": "4.2.0", + "resolved": "https://registry.npmjs.org/postcss-value-parser/-/postcss-value-parser-4.2.0.tgz", + "integrity": "sha512-1NNCs6uurfkVbeXG4S8JFT9t19m45ICnif8zWLd5oPSZ50QnwMfK+H3jv408d4jw/7Bttv5axS5IiHoLaVNHeQ==", + "dev": true + }, + "node_modules/preact": { + "version": "10.22.1", + "resolved": "https://registry.npmjs.org/preact/-/preact-10.22.1.tgz", + "integrity": "sha512-jRYbDDgMpIb5LHq3hkI0bbl+l/TQ9UnkdQ0ww+lp+4MMOdqaUYdFc5qeyP+IV8FAd/2Em7drVPeKdQxsiWCf/A==", + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/preact" + } + }, + "node_modules/process-nextick-args": { + "version": "2.0.1", + "resolved": "https://registry.npmjs.org/process-nextick-args/-/process-nextick-args-2.0.1.tgz", + "integrity": "sha512-3ouUOpQhtgrbOa17J7+uxOTpITYWaGP7/AhoR3+A+/1e9skrzelGi/dXzEYyvbxubEF6Wn2ypscTKiKJFFn1ag==", + "dev": true + }, + "node_modules/proxy-addr": { + "version": "2.0.7", + "resolved": "https://registry.npmjs.org/proxy-addr/-/proxy-addr-2.0.7.tgz", + "integrity": "sha512-llQsMLSUDUPT44jdrU/O37qlnifitDP+ZwrmmZcoSKyLKvtZxpyV0n2/bD/N4tBAAZ/gJEdZU7KMraoK1+XYAg==", + "dev": true, + "dependencies": { + "forwarded": "0.2.0", + "ipaddr.js": "1.9.1" + }, + "engines": { + "node": ">= 0.10" + } + }, + "node_modules/proxy-addr/node_modules/ipaddr.js": { + "version": "1.9.1", + "resolved": "https://registry.npmjs.org/ipaddr.js/-/ipaddr.js-1.9.1.tgz", + "integrity": "sha512-0KI/607xoxSToH7GjN1FfSbLoU0+btTicjsQSWQlh/hZykN8KpmMf7uYwPW3R+akZ6R/w18ZlXSHBYXiYUPO3g==", + "dev": true, + "engines": { + "node": ">= 0.10" + } + }, + "node_modules/proxy-from-env": { + "version": "1.1.0", + "resolved": "https://registry.npmjs.org/proxy-from-env/-/proxy-from-env-1.1.0.tgz", + "integrity": "sha512-D+zkORCbA9f1tdWRK0RaCR3GPv50cMxcrz4X8k5LTSUD1Dkw47mKJEZQNunItRTkWwgtaUSo1RVFRIG9ZXiFYg==" + }, + "node_modules/punycode": { + "version": "2.3.1", + "resolved": "https://registry.npmjs.org/punycode/-/punycode-2.3.1.tgz", + "integrity": "sha512-vYt7UD1U9Wg6138shLtLOvdAu+8DsC/ilFtEVHcH+wydcSpNE20AfSOduf6MkRFahL5FY7X1oU7nKVZFtfq8Fg==", + "dev": true, + "engines": { + "node": ">=6" + } + }, + "node_modules/qs": { + "version": "6.9.7", + "resolved": "https://registry.npmjs.org/qs/-/qs-6.9.7.tgz", + "integrity": "sha512-IhMFgUmuNpyRfxA90umL7ByLlgRXu6tIfKPpF5TmcfRLlLCckfP/g3IQmju6jjpu+Hh8rA+2p6A27ZSPOOHdKw==", + "engines": { + "node": ">=0.6" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/queue-microtask": { + "version": "1.2.3", + "resolved": "https://registry.npmjs.org/queue-microtask/-/queue-microtask-1.2.3.tgz", + "integrity": "sha512-NuaNSa6flKT5JaSYQzJok04JzTL1CA6aGhv5rfLW3PgqA+M2ChpZQnAC8h8i4ZFkBS8X5RqkDBHA7r4hej3K9A==", + "dev": true, + "funding": [ + { + "type": "github", + "url": "https://github.com/sponsors/feross" + }, + { + "type": "patreon", + "url": "https://www.patreon.com/feross" + }, + { + "type": "consulting", + "url": "https://feross.org/support" + } + ] + }, + "node_modules/randombytes": { + "version": "2.1.0", + "resolved": "https://registry.npmjs.org/randombytes/-/randombytes-2.1.0.tgz", + "integrity": "sha512-vYl3iOX+4CKUWuxGi9Ukhie6fsqXqS9FE2Zaic4tNFD2N2QQaXOMFbuKK4QmDHC0JO6B1Zp41J0LpT0oR68amQ==", + "dev": true, + "dependencies": { + "safe-buffer": "^5.1.0" + } + }, + "node_modules/range-parser": { + "version": "1.2.1", + "resolved": "https://registry.npmjs.org/range-parser/-/range-parser-1.2.1.tgz", + "integrity": "sha512-Hrgsx+orqoygnmhFbKaHE6c296J+HTAQXoxEF6gNupROmmGJRoyzfG3ccAveqCBrwr/2yxQ5BVd/GTl5agOwSg==", + "dev": true, + "engines": { + "node": ">= 0.6" + } + }, + "node_modules/raw-body": { + "version": "2.5.2", + "resolved": "https://registry.npmjs.org/raw-body/-/raw-body-2.5.2.tgz", + "integrity": "sha512-8zGqypfENjCIqGhgXToC8aB2r7YrBX+AQAfIPs/Mlk+BtPTztOvTS01NRW/3Eh60J+a48lt8qsCzirQ6loCVfA==", + "dev": true, + "dependencies": { + "bytes": "3.1.2", + "http-errors": "2.0.0", + "iconv-lite": "0.4.24", + "unpipe": "1.0.0" + }, + "engines": { + "node": ">= 0.8" + } + }, + "node_modules/raw-body/node_modules/bytes": { + "version": "3.1.2", + "resolved": "https://registry.npmjs.org/bytes/-/bytes-3.1.2.tgz", + "integrity": "sha512-/Nf7TyzTx6S3yRJObOAV7956r8cr2+Oj8AC5dt8wSP3BQAoeX58NoHyCU8P8zGkNXStjTSi6fzO6F0pBdcYbEg==", + "dev": true, + "engines": { + "node": ">= 0.8" + } + }, + "node_modules/readable-stream": { + "version": "3.6.2", + "resolved": "https://registry.npmjs.org/readable-stream/-/readable-stream-3.6.2.tgz", + "integrity": "sha512-9u/sniCrY3D5WdsERHzHE4G2YCXqoG5FTHUiCC4SIbr6XcLZBY05ya9EKjYek9O5xOAwjGq+1JdGBAS7Q9ScoA==", + "dev": true, + "dependencies": { + "inherits": "^2.0.3", + "string_decoder": "^1.1.1", + "util-deprecate": "^1.0.1" + }, + "engines": { + "node": ">= 6" + } + }, + "node_modules/readdirp": { + "version": "3.6.0", + "resolved": "https://registry.npmjs.org/readdirp/-/readdirp-3.6.0.tgz", + "integrity": "sha512-hOS089on8RduqdbhvQ5Z37A0ESjsqz6qnRcffsMU3495FuTdqSm+7bhJ29JvIOsBDEEnan5DPu9t3To9VRlMzA==", + "dev": true, + "dependencies": { + "picomatch": "^2.2.1" + }, + "engines": { + "node": ">=8.10.0" + } + }, + "node_modules/rechoir": { + "version": "0.8.0", + "resolved": "https://registry.npmjs.org/rechoir/-/rechoir-0.8.0.tgz", + "integrity": "sha512-/vxpCXddiX8NGfGO/mTafwjq4aFa/71pvamip0++IQk3zG8cbCj0fifNPrjjF1XMXUne91jL9OoxmdykoEtifQ==", + "dev": true, + "dependencies": { + "resolve": "^1.20.0" + }, + "engines": { + "node": ">= 10.13.0" + } + }, + "node_modules/regenerator-runtime": { + "version": "0.14.1", + "resolved": "https://registry.npmjs.org/regenerator-runtime/-/regenerator-runtime-0.14.1.tgz", + "integrity": "sha512-dYnhHh0nJoMfnkZs6GmmhFknAGRrLznOu5nc9ML+EJxGvrx6H7teuevqVqCuPcPK//3eDrrjQhehXVx9cnkGdw==" + }, + "node_modules/require-from-string": { + "version": "2.0.2", + "resolved": "https://registry.npmjs.org/require-from-string/-/require-from-string-2.0.2.tgz", + "integrity": "sha512-Xf0nWe6RseziFMu+Ap9biiUbmplq6S9/p+7w7YXP/JBHhrUDDUhwa+vANyubuqfZWTveU//DYVGsDG7RKL/vEw==", + "dev": true, + "engines": { + "node": ">=0.10.0" + } + }, + "node_modules/requires-port": { + "version": "1.0.0", + "resolved": "https://registry.npmjs.org/requires-port/-/requires-port-1.0.0.tgz", + "integrity": "sha512-KigOCHcocU3XODJxsu8i/j8T9tzT4adHiecwORRQ0ZZFcp7ahwXuRU1m+yuO90C5ZUyGeGfocHDI14M3L3yDAQ==", + "dev": true + }, + "node_modules/resolve": { + "version": "1.22.8", + "resolved": "https://registry.npmjs.org/resolve/-/resolve-1.22.8.tgz", + "integrity": "sha512-oKWePCxqpd6FlLvGV1VU0x7bkPmmCNolxzjMf4NczoDnQcIWrAF+cPtZn5i6n+RfD2d9i0tzpKnG6Yk168yIyw==", + "dev": true, + "dependencies": { + "is-core-module": "^2.13.0", + "path-parse": "^1.0.7", + "supports-preserve-symlinks-flag": "^1.0.0" + }, + "bin": { + "resolve": "bin/resolve" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/resolve-cwd": { + "version": "3.0.0", + "resolved": "https://registry.npmjs.org/resolve-cwd/-/resolve-cwd-3.0.0.tgz", + "integrity": "sha512-OrZaX2Mb+rJCpH/6CpSqt9xFVpN++x01XnN2ie9g6P5/3xelLAkXWVADpdz1IHD/KFfEXyE6V0U01OQ3UO2rEg==", + "dev": true, + "dependencies": { + "resolve-from": "^5.0.0" + }, + "engines": { + "node": ">=8" + } + }, + "node_modules/resolve-from": { + "version": "5.0.0", + "resolved": "https://registry.npmjs.org/resolve-from/-/resolve-from-5.0.0.tgz", + "integrity": "sha512-qYg9KP24dD5qka9J47d0aVky0N+b4fTU89LN9iDnjB5waksiC49rvMB0PrUJQGoTmH50XPiqOvAjDfaijGxYZw==", + "dev": true, + "engines": { + "node": ">=8" + } + }, + "node_modules/retry": { + "version": "0.13.1", + "resolved": "https://registry.npmjs.org/retry/-/retry-0.13.1.tgz", + "integrity": "sha512-XQBQ3I8W1Cge0Seh+6gjj03LbmRFWuoszgK9ooCpwYIrhhoO80pfq4cUkU5DkknwfOfFteRwlZ56PYOGYyFWdg==", + "dev": true, + "engines": { + "node": ">= 4" + } + }, + "node_modules/reusify": { + "version": "1.0.4", + "resolved": "https://registry.npmjs.org/reusify/-/reusify-1.0.4.tgz", + "integrity": "sha512-U9nH88a3fc/ekCF1l0/UP1IosiuIjyTh7hBvXVMHYgVcfGvt897Xguj2UOLDeI5BG2m7/uwyaLVT6fbtCwTyzw==", + "dev": true, + "engines": { + "iojs": ">=1.0.0", + "node": ">=0.10.0" + } + }, + "node_modules/rimraf": { + "version": "5.0.9", + "resolved": "https://registry.npmjs.org/rimraf/-/rimraf-5.0.9.tgz", + "integrity": "sha512-3i7b8OcswU6CpU8Ej89quJD4O98id7TtVM5U4Mybh84zQXdrFmDLouWBEEaD/QfO3gDDfH+AGFCGsR7kngzQnA==", + "dev": true, + "dependencies": { + "glob": "^10.3.7" + }, + "bin": { + "rimraf": "dist/esm/bin.mjs" + }, + "engines": { + "node": "14 >=14.20 || 16 >=16.20 || >=18" + }, + "funding": { + "url": "https://github.com/sponsors/isaacs" + } + }, + "node_modules/run-applescript": { + "version": "7.0.0", + "resolved": "https://registry.npmjs.org/run-applescript/-/run-applescript-7.0.0.tgz", + "integrity": "sha512-9by4Ij99JUr/MCFBUkDKLWK3G9HVXmabKz9U5MlIAIuvuzkiOicRYs8XJLxX+xahD+mLiiCYDqF9dKAgtzKP1A==", + "dev": true, + "engines": { + "node": ">=18" + }, + "funding": { + "url": "https://github.com/sponsors/sindresorhus" + } + }, + "node_modules/run-parallel": { + "version": "1.2.0", + "resolved": "https://registry.npmjs.org/run-parallel/-/run-parallel-1.2.0.tgz", + "integrity": "sha512-5l4VyZR86LZ/lDxZTR6jqL8AFE2S0IFLMP26AbjsLVADxHdhB/c0GUsH+y39UfCi3dzz8OlQuPmnaJOMoDHQBA==", + "dev": true, + "funding": [ + { + "type": "github", + "url": "https://github.com/sponsors/feross" + }, + { + "type": "patreon", + "url": "https://www.patreon.com/feross" + }, + { + "type": "consulting", + "url": "https://feross.org/support" + } + ], + "dependencies": { + "queue-microtask": "^1.2.2" + } + }, + "node_modules/safe-buffer": { + "version": "5.2.1", + "resolved": "https://registry.npmjs.org/safe-buffer/-/safe-buffer-5.2.1.tgz", + "integrity": "sha512-rp3So07KcdmmKbGvgaNxQSJr7bGVSVk5S9Eq1F+ppbRo70+YeaDxkw5Dd8NPN+GD6bjnYm2VuPuCXmpuYvmCXQ==", + "dev": true, + "funding": [ + { + "type": "github", + "url": "https://github.com/sponsors/feross" + }, + { + "type": "patreon", + "url": "https://www.patreon.com/feross" + }, + { + "type": "consulting", + "url": "https://feross.org/support" + } + ] + }, + "node_modules/safer-buffer": { + "version": "2.1.2", + "resolved": "https://registry.npmjs.org/safer-buffer/-/safer-buffer-2.1.2.tgz", + "integrity": "sha512-YZo3K82SD7Riyi0E1EQPojLz7kpepnSQI9IyPbHHg1XXXevb5dJI7tpyN2ADxGcQbHG7vcyRHk0cbwqcQriUtg==", + "dev": true + }, + "node_modules/schema-utils": { + "version": "3.3.0", + "resolved": "https://registry.npmjs.org/schema-utils/-/schema-utils-3.3.0.tgz", + "integrity": "sha512-pN/yOAvcC+5rQ5nERGuwrjLlYvLTbCibnZ1I7B1LaiAz9BRBlE9GMgE/eqV30P7aJQUf7Ddimy/RsbYO/GrVGg==", + "dev": true, + "dependencies": { + "@types/json-schema": "^7.0.8", + "ajv": "^6.12.5", + "ajv-keywords": "^3.5.2" + }, + "engines": { + "node": ">= 10.13.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/webpack" + } + }, + "node_modules/search-insights": { + "version": "2.15.0", + "resolved": "https://registry.npmjs.org/search-insights/-/search-insights-2.15.0.tgz", + "integrity": "sha512-ch2sPCUDD4sbPQdknVl9ALSi9H7VyoeVbsxznYz6QV55jJ8CI3EtwpO1i84keN4+hF5IeHWIeGvc08530JkVXQ==" + }, + "node_modules/select-hose": { + "version": "2.0.0", + "resolved": "https://registry.npmjs.org/select-hose/-/select-hose-2.0.0.tgz", + "integrity": "sha512-mEugaLK+YfkijB4fx0e6kImuJdCIt2LxCRcbEYPqRGCs4F2ogyfZU5IAZRdjCP8JPq2AtdNoC/Dux63d9Kiryg==", + "dev": true + }, + "node_modules/selfsigned": { + "version": "2.4.1", + "resolved": "https://registry.npmjs.org/selfsigned/-/selfsigned-2.4.1.tgz", + "integrity": "sha512-th5B4L2U+eGLq1TVh7zNRGBapioSORUeymIydxgFpwww9d2qyKvtuPU2jJuHvYAwwqi2Y596QBL3eEqcPEYL8Q==", + "dev": true, + "dependencies": { + "@types/node-forge": "^1.3.0", + "node-forge": "^1" + }, + "engines": { + "node": ">=10" + } + }, + "node_modules/semver": { + "version": "7.6.2", + "resolved": "https://registry.npmjs.org/semver/-/semver-7.6.2.tgz", + "integrity": "sha512-FNAIBWCx9qcRhoHcgcJ0gvU7SN1lYU2ZXuSfl04bSC5OpvDHFyJCjdNHomPXxjQlCBU67YW64PzY7/VIEH7F2w==", + "dev": true, + "bin": { + "semver": "bin/semver.js" + }, + "engines": { + "node": ">=10" + } + }, + "node_modules/send": { + "version": "0.18.0", + "resolved": "https://registry.npmjs.org/send/-/send-0.18.0.tgz", + "integrity": "sha512-qqWzuOjSFOuqPjFe4NOsMLafToQQwBSOEpS+FwEt3A2V3vKubTquT3vmLTQpFgMXp8AlFWFuP1qKaJZOtPpVXg==", + "dev": true, + "dependencies": { + "debug": "2.6.9", + "depd": "2.0.0", + "destroy": "1.2.0", + "encodeurl": "~1.0.2", + "escape-html": "~1.0.3", + "etag": "~1.8.1", + "fresh": "0.5.2", + "http-errors": "2.0.0", + "mime": "1.6.0", + "ms": "2.1.3", + "on-finished": "2.4.1", + "range-parser": "~1.2.1", + "statuses": "2.0.1" + }, + "engines": { + "node": ">= 0.8.0" + } + }, + "node_modules/send/node_modules/ms": { + "version": "2.1.3", + "resolved": "https://registry.npmjs.org/ms/-/ms-2.1.3.tgz", + "integrity": "sha512-6FlzubTLZG3J2a/NVCAleEhjzq5oxgHyaCU9yYXvcLsvoVaHJq/s5xXI6/XXP6tz7R9xAOtHnSO/tXtF3WRTlA==", + "dev": true + }, + "node_modules/serialize-javascript": { + "version": "6.0.2", + "resolved": "https://registry.npmjs.org/serialize-javascript/-/serialize-javascript-6.0.2.tgz", + "integrity": "sha512-Saa1xPByTTq2gdeFZYLLo+RFE35NHZkAbqZeWNd3BpzppeVisAqpDjcp8dyf6uIvEqJRd46jemmyA4iFIeVk8g==", + "dev": true, + "dependencies": { + "randombytes": "^2.1.0" + } + }, + "node_modules/serve-index": { + "version": "1.9.1", + "resolved": "https://registry.npmjs.org/serve-index/-/serve-index-1.9.1.tgz", + "integrity": "sha512-pXHfKNP4qujrtteMrSBb0rc8HJ9Ms/GrXwcUtUtD5s4ewDJI8bT3Cz2zTVRMKtri49pLx2e0Ya8ziP5Ya2pZZw==", + "dev": true, + "dependencies": { + "accepts": "~1.3.4", + "batch": "0.6.1", + "debug": "2.6.9", + "escape-html": "~1.0.3", + "http-errors": "~1.6.2", + "mime-types": "~2.1.17", + "parseurl": "~1.3.2" + }, + "engines": { + "node": ">= 0.8.0" + } + }, + "node_modules/serve-index/node_modules/depd": { + "version": "1.1.2", + "resolved": "https://registry.npmjs.org/depd/-/depd-1.1.2.tgz", + "integrity": "sha512-7emPTl6Dpo6JRXOXjLRxck+FlLRX5847cLKEn00PLAgc3g2hTZZgr+e4c2v6QpSmLeFP3n5yUo7ft6avBK/5jQ==", + "dev": true, + "engines": { + "node": ">= 0.6" + } + }, + "node_modules/serve-index/node_modules/http-errors": { + "version": "1.6.3", + "resolved": "https://registry.npmjs.org/http-errors/-/http-errors-1.6.3.tgz", + "integrity": "sha512-lks+lVC8dgGyh97jxvxeYTWQFvh4uw4yC12gVl63Cg30sjPX4wuGcdkICVXDAESr6OJGjqGA8Iz5mkeN6zlD7A==", + "dev": true, + "dependencies": { + "depd": "~1.1.2", + "inherits": "2.0.3", + "setprototypeof": "1.1.0", + "statuses": ">= 1.4.0 < 2" + }, + "engines": { + "node": ">= 0.6" + } + }, + "node_modules/serve-index/node_modules/inherits": { + "version": "2.0.3", + "resolved": "https://registry.npmjs.org/inherits/-/inherits-2.0.3.tgz", + "integrity": "sha512-x00IRNXNy63jwGkJmzPigoySHbaqpNuzKbBOmzK+g2OdZpQ9w+sxCN+VSB3ja7IAge2OP2qpfxTjeNcyjmW1uw==", + "dev": true + }, + "node_modules/serve-index/node_modules/setprototypeof": { + "version": "1.1.0", + "resolved": "https://registry.npmjs.org/setprototypeof/-/setprototypeof-1.1.0.tgz", + "integrity": "sha512-BvE/TwpZX4FXExxOxZyRGQQv651MSwmWKZGqvmPcRIjDqWub67kTKuIMx43cZZrS/cBBzwBcNDWoFxt2XEFIpQ==", + "dev": true + }, + "node_modules/serve-index/node_modules/statuses": { + "version": "1.5.0", + "resolved": "https://registry.npmjs.org/statuses/-/statuses-1.5.0.tgz", + "integrity": "sha512-OpZ3zP+jT1PI7I8nemJX4AKmAX070ZkYPVWV/AaKTJl+tXCTGyVdC1a4SL8RUQYEwk/f34ZX8UTykN68FwrqAA==", + "dev": true, + "engines": { + "node": ">= 0.6" + } + }, + "node_modules/serve-static": { + "version": "1.15.0", + "resolved": "https://registry.npmjs.org/serve-static/-/serve-static-1.15.0.tgz", + "integrity": "sha512-XGuRDNjXUijsUL0vl6nSD7cwURuzEgglbOaFuZM9g3kwDXOWVTck0jLzjPzGD+TazWbboZYu52/9/XPdUgne9g==", + "dev": true, + "dependencies": { + "encodeurl": "~1.0.2", + "escape-html": "~1.0.3", + "parseurl": "~1.3.3", + "send": "0.18.0" + }, + "engines": { + "node": ">= 0.8.0" + } + }, + "node_modules/set-function-length": { + "version": "1.2.2", + "resolved": "https://registry.npmjs.org/set-function-length/-/set-function-length-1.2.2.tgz", + "integrity": "sha512-pgRc4hJ4/sNjWCSS9AmnS40x3bNMDTknHgL5UaMBTMyJnU90EgWh1Rz+MC9eFu4BuN/UwZjKQuY/1v3rM7HMfg==", + "dev": true, + "dependencies": { + "define-data-property": "^1.1.4", + "es-errors": "^1.3.0", + "function-bind": "^1.1.2", + "get-intrinsic": "^1.2.4", + "gopd": "^1.0.1", + "has-property-descriptors": "^1.0.2" + }, + "engines": { + "node": ">= 0.4" + } + }, + "node_modules/setprototypeof": { + "version": "1.2.0", + "resolved": "https://registry.npmjs.org/setprototypeof/-/setprototypeof-1.2.0.tgz", + "integrity": "sha512-E5LDX7Wrp85Kil5bhZv46j8jOeboKq5JMmYM3gVGdGH8xFpPWXUMsNrlODCrkoxMEeNi/XZIwuRvY4XNwYMJpw==", + "dev": true + }, + "node_modules/shallow-clone": { + "version": "3.0.1", + "resolved": "https://registry.npmjs.org/shallow-clone/-/shallow-clone-3.0.1.tgz", + "integrity": "sha512-/6KqX+GVUdqPuPPd2LxDDxzX6CAbjJehAAOKlNpqqUpAqPM6HeL8f+o3a+JsyGjn2lv0WY8UsTgUJjU9Ok55NA==", + "dev": true, + "dependencies": { + "kind-of": "^6.0.2" + }, + "engines": { + "node": ">=8" + } + }, + "node_modules/shebang-command": { + "version": "2.0.0", + "resolved": "https://registry.npmjs.org/shebang-command/-/shebang-command-2.0.0.tgz", + "integrity": "sha512-kHxr2zZpYtdmrN1qDjrrX/Z1rR1kG8Dx+gkpK1G4eXmvXswmcE1hTWBWYUzlraYw1/yZp6YuDY77YtvbN0dmDA==", + "dev": true, + "dependencies": { + "shebang-regex": "^3.0.0" + }, + "engines": { + "node": ">=8" + } + }, + "node_modules/shebang-regex": { + "version": "3.0.0", + "resolved": "https://registry.npmjs.org/shebang-regex/-/shebang-regex-3.0.0.tgz", + "integrity": "sha512-7++dFhtcx3353uBaq8DDR4NuxBetBzC7ZQOhmTQInHEd6bSrXdiEyzCvG07Z44UYdLShWUyXt5M/yhz8ekcb1A==", + "dev": true, + "engines": { + "node": ">=8" + } + }, + "node_modules/shell-quote": { + "version": "1.8.1", + "resolved": "https://registry.npmjs.org/shell-quote/-/shell-quote-1.8.1.tgz", + "integrity": "sha512-6j1W9l1iAs/4xYBI1SYOVZyFcCis9b4KCLQ8fgAGG07QvzaRLVVRQvAy85yNmmZSjYjg4MWh4gNvlPujU/5LpA==", + "dev": true, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/side-channel": { + "version": "1.0.6", + "resolved": "https://registry.npmjs.org/side-channel/-/side-channel-1.0.6.tgz", + "integrity": "sha512-fDW/EZ6Q9RiO8eFG8Hj+7u/oW+XrPTIChwCOM2+th2A6OblDtYYIpve9m+KvI9Z4C9qSEXlaGR6bTEYHReuglA==", + "dev": true, + "dependencies": { + "call-bind": "^1.0.7", + "es-errors": "^1.3.0", + "get-intrinsic": "^1.2.4", + "object-inspect": "^1.13.1" + }, + "engines": { + "node": ">= 0.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/signal-exit": { + "version": "3.0.7", + "resolved": "https://registry.npmjs.org/signal-exit/-/signal-exit-3.0.7.tgz", + "integrity": "sha512-wnD2ZE+l+SPC/uoS0vXeE9L1+0wuaMqKlfz9AMUo38JsyLSBWSFcHR1Rri62LZc12vLr1gb3jl7iwQhgwpAbGQ==", + "dev": true + }, + "node_modules/slash": { + "version": "5.1.0", + "resolved": "https://registry.npmjs.org/slash/-/slash-5.1.0.tgz", + "integrity": "sha512-ZA6oR3T/pEyuqwMgAKT0/hAv8oAXckzbkmR0UkUosQ+Mc4RxGoJkRmwHgHufaenlyAgE1Mxgpdcrf75y6XcnDg==", + "dev": true, + "engines": { + "node": ">=14.16" + }, + "funding": { + "url": "https://github.com/sponsors/sindresorhus" + } + }, + "node_modules/sockjs": { + "version": "0.3.24", + "resolved": "https://registry.npmjs.org/sockjs/-/sockjs-0.3.24.tgz", + "integrity": "sha512-GJgLTZ7vYb/JtPSSZ10hsOYIvEYsjbNU+zPdIHcUaWVNUEPivzxku31865sSSud0Da0W4lEeOPlmw93zLQchuQ==", + "dev": true, + "dependencies": { + "faye-websocket": "^0.11.3", + "uuid": "^8.3.2", + "websocket-driver": "^0.7.4" + } + }, + "node_modules/source-map": { + "version": "0.6.1", + "resolved": "https://registry.npmjs.org/source-map/-/source-map-0.6.1.tgz", + "integrity": "sha512-UjgapumWlbMhkBgzT7Ykc5YXUT46F0iKu8SGXq0bcwP5dz/h0Plj6enJqjz1Zbq2l5WaqYnrVbwWOWMyF3F47g==", + "dev": true, + "engines": { + "node": ">=0.10.0" + } + }, + "node_modules/source-map-js": { + "version": "1.2.0", + "resolved": "https://registry.npmjs.org/source-map-js/-/source-map-js-1.2.0.tgz", + "integrity": "sha512-itJW8lvSA0TXEphiRoawsCksnlf8SyvmFzIhltqAHluXd88pkCd+cXJVHTDwdCr0IzwptSm035IHQktUu1QUMg==", + "dev": true, + "engines": { + "node": ">=0.10.0" + } + }, + "node_modules/source-map-support": { + "version": "0.5.21", + "resolved": "https://registry.npmjs.org/source-map-support/-/source-map-support-0.5.21.tgz", + "integrity": "sha512-uBHU3L3czsIyYXKX88fdrGovxdSCoTGDRZ6SYXtSRxLZUzHg5P/66Ht6uoUlHu9EZod+inXhKo3qQgwXUT/y1w==", + "dev": true, + "dependencies": { + "buffer-from": "^1.0.0", + "source-map": "^0.6.0" + } + }, + "node_modules/spdy": { + "version": "4.0.2", + "resolved": "https://registry.npmjs.org/spdy/-/spdy-4.0.2.tgz", + "integrity": "sha512-r46gZQZQV+Kl9oItvl1JZZqJKGr+oEkB08A6BzkiR7593/7IbtuncXHd2YoYeTsG4157ZssMu9KYvUHLcjcDoA==", + "dev": true, + "dependencies": { + "debug": "^4.1.0", + "handle-thing": "^2.0.0", + "http-deceiver": "^1.2.7", + "select-hose": "^2.0.0", + "spdy-transport": "^3.0.0" + }, + "engines": { + "node": ">=6.0.0" + } + }, + "node_modules/spdy-transport": { + "version": "3.0.0", + "resolved": "https://registry.npmjs.org/spdy-transport/-/spdy-transport-3.0.0.tgz", + "integrity": "sha512-hsLVFE5SjA6TCisWeJXFKniGGOpBgMLmerfO2aCyCU5s7nJ/rpAepqmFifv/GCbSbueEeAJJnmSQ2rKC/g8Fcw==", + "dev": true, + "dependencies": { + "debug": "^4.1.0", + "detect-node": "^2.0.4", + "hpack.js": "^2.1.6", + "obuf": "^1.1.2", + "readable-stream": "^3.0.6", + "wbuf": "^1.7.3" + } + }, + "node_modules/spdy-transport/node_modules/debug": { + "version": "4.3.5", + "resolved": "https://registry.npmjs.org/debug/-/debug-4.3.5.tgz", + "integrity": "sha512-pt0bNEmneDIvdL1Xsd9oDQ/wrQRkXDT4AUWlNZNPKvW5x/jyO9VFXkJUP07vQ2upmw5PlaITaPKc31jK13V+jg==", + "dev": true, + "dependencies": { + "ms": "2.1.2" + }, + "engines": { + "node": ">=6.0" + }, + "peerDependenciesMeta": { + "supports-color": { + "optional": true + } + } + }, + "node_modules/spdy-transport/node_modules/ms": { + "version": "2.1.2", + "resolved": "https://registry.npmjs.org/ms/-/ms-2.1.2.tgz", + "integrity": "sha512-sGkPx+VjMtmA6MX27oA4FBFELFCZZ4S4XqeGOXCv68tT+jb3vk/RyaKWP0PTKyWtmLSM0b+adUTEvbs1PEaH2w==", + "dev": true + }, + "node_modules/spdy/node_modules/debug": { + "version": "4.3.5", + "resolved": "https://registry.npmjs.org/debug/-/debug-4.3.5.tgz", + "integrity": "sha512-pt0bNEmneDIvdL1Xsd9oDQ/wrQRkXDT4AUWlNZNPKvW5x/jyO9VFXkJUP07vQ2upmw5PlaITaPKc31jK13V+jg==", + "dev": true, + "dependencies": { + "ms": "2.1.2" + }, + "engines": { + "node": ">=6.0" + }, + "peerDependenciesMeta": { + "supports-color": { + "optional": true + } + } + }, + "node_modules/spdy/node_modules/ms": { + "version": "2.1.2", + "resolved": "https://registry.npmjs.org/ms/-/ms-2.1.2.tgz", + "integrity": "sha512-sGkPx+VjMtmA6MX27oA4FBFELFCZZ4S4XqeGOXCv68tT+jb3vk/RyaKWP0PTKyWtmLSM0b+adUTEvbs1PEaH2w==", + "dev": true + }, + "node_modules/statuses": { + "version": "2.0.1", + "resolved": "https://registry.npmjs.org/statuses/-/statuses-2.0.1.tgz", + "integrity": "sha512-RwNA9Z/7PrK06rYLIzFMlaF+l73iwpzsqRIFgbMLbTcLD6cOao82TaWefPXQvB2fOC4AjuYSEndS7N/mTCbkdQ==", + "dev": true, + "engines": { + "node": ">= 0.8" + } + }, + "node_modules/string_decoder": { + "version": "1.3.0", + "resolved": "https://registry.npmjs.org/string_decoder/-/string_decoder-1.3.0.tgz", + "integrity": "sha512-hkRX8U1WjJFd8LsDJ2yQ/wWWxaopEsABU1XfkM8A+j0+85JAGppt16cr1Whg6KIbb4okU6Mql6BOj+uup/wKeA==", + "dev": true, + "dependencies": { + "safe-buffer": "~5.2.0" + } + }, + "node_modules/string-width": { + "version": "5.1.2", + "resolved": "https://registry.npmjs.org/string-width/-/string-width-5.1.2.tgz", + "integrity": "sha512-HnLOCR3vjcY8beoNLtcjZ5/nxn2afmME6lhrDrebokqMap+XbeW8n9TXpPDOqdGK5qcI3oT0GKTW6wC7EMiVqA==", + "dev": true, + "dependencies": { + "eastasianwidth": "^0.2.0", + "emoji-regex": "^9.2.2", + "strip-ansi": "^7.0.1" + }, + "engines": { + "node": ">=12" + }, + "funding": { + "url": "https://github.com/sponsors/sindresorhus" + } + }, + "node_modules/string-width-cjs": { + "name": "string-width", + "version": "4.2.3", + "resolved": "https://registry.npmjs.org/string-width/-/string-width-4.2.3.tgz", + "integrity": "sha512-wKyQRQpjJ0sIp62ErSZdGsjMJWsap5oRNihHhu6G7JVO/9jIB6UyevL+tXuOqrng8j/cxKTWyWUwvSTriiZz/g==", + "dev": true, + "dependencies": { + "emoji-regex": "^8.0.0", + "is-fullwidth-code-point": "^3.0.0", + "strip-ansi": "^6.0.1" + }, + "engines": { + "node": ">=8" + } + }, + "node_modules/string-width-cjs/node_modules/ansi-regex": { + "version": "5.0.1", + "resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-5.0.1.tgz", + "integrity": "sha512-quJQXlTSUGL2LH9SUXo8VwsY4soanhgo6LNSm84E1LBcE8s3O0wpdiRzyR9z/ZZJMlMWv37qOOb9pdJlMUEKFQ==", + "dev": true, + "engines": { + "node": ">=8" + } + }, + "node_modules/string-width-cjs/node_modules/emoji-regex": { + "version": "8.0.0", + "resolved": "https://registry.npmjs.org/emoji-regex/-/emoji-regex-8.0.0.tgz", + "integrity": "sha512-MSjYzcWNOA0ewAHpz0MxpYFvwg6yjy1NG3xteoqz644VCo/RPgnr1/GGt+ic3iJTzQ8Eu3TdM14SawnVUmGE6A==", + "dev": true + }, + "node_modules/string-width-cjs/node_modules/strip-ansi": { + "version": "6.0.1", + "resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-6.0.1.tgz", + "integrity": "sha512-Y38VPSHcqkFrCpFnQ9vuSXmquuv5oXOKpGeT6aGrr3o3Gc9AlVa6JBfUSOCnbxGGZF+/0ooI7KrPuUSztUdU5A==", + "dev": true, + "dependencies": { + "ansi-regex": "^5.0.1" + }, + "engines": { + "node": ">=8" + } + }, + "node_modules/strip-ansi": { + "version": "7.1.0", + "resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-7.1.0.tgz", + "integrity": "sha512-iq6eVVI64nQQTRYq2KtEg2d2uU7LElhTJwsH4YzIHZshxlgZms/wIc4VoDQTlG/IvVIrBKG06CrZnp0qv7hkcQ==", + "dev": true, + "dependencies": { + "ansi-regex": "^6.0.1" + }, + "engines": { + "node": ">=12" + }, + "funding": { + "url": "https://github.com/chalk/strip-ansi?sponsor=1" + } + }, + "node_modules/strip-ansi-cjs": { + "name": "strip-ansi", + "version": "6.0.1", + "resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-6.0.1.tgz", + "integrity": "sha512-Y38VPSHcqkFrCpFnQ9vuSXmquuv5oXOKpGeT6aGrr3o3Gc9AlVa6JBfUSOCnbxGGZF+/0ooI7KrPuUSztUdU5A==", + "dev": true, + "dependencies": { + "ansi-regex": "^5.0.1" + }, + "engines": { + "node": ">=8" + } + }, + "node_modules/strip-ansi-cjs/node_modules/ansi-regex": { + "version": "5.0.1", + "resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-5.0.1.tgz", + "integrity": "sha512-quJQXlTSUGL2LH9SUXo8VwsY4soanhgo6LNSm84E1LBcE8s3O0wpdiRzyR9z/ZZJMlMWv37qOOb9pdJlMUEKFQ==", + "dev": true, + "engines": { + "node": ">=8" + } + }, + "node_modules/strip-final-newline": { + "version": "2.0.0", + "resolved": "https://registry.npmjs.org/strip-final-newline/-/strip-final-newline-2.0.0.tgz", + "integrity": "sha512-BrpvfNAE3dcvq7ll3xVumzjKjZQ5tI1sEUIKr3Uoks0XUl45St3FlatVqef9prk4jRDzhW6WZg+3bk93y6pLjA==", + "dev": true, + "engines": { + "node": ">=6" + } + }, + "node_modules/style-loader": { + "version": "4.0.0", + "resolved": "https://registry.npmjs.org/style-loader/-/style-loader-4.0.0.tgz", + "integrity": "sha512-1V4WqhhZZgjVAVJyt7TdDPZoPBPNHbekX4fWnCJL1yQukhCeZhJySUL+gL9y6sNdN95uEOS83Y55SqHcP7MzLA==", + "dev": true, + "engines": { + "node": ">= 18.12.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/webpack" + }, + "peerDependencies": { + "webpack": "^5.27.0" + } + }, + "node_modules/supports-color": { + "version": "8.1.1", + "resolved": "https://registry.npmjs.org/supports-color/-/supports-color-8.1.1.tgz", + "integrity": "sha512-MpUEN2OodtUzxvKQl72cUF7RQ5EiHsGvSsVG0ia9c5RbWGL2CI4C7EpPS8UTBIplnlzZiNuV56w+FuNxy3ty2Q==", + "dev": true, + "dependencies": { + "has-flag": "^4.0.0" + }, + "engines": { + "node": ">=10" + }, + "funding": { + "url": "https://github.com/chalk/supports-color?sponsor=1" + } + }, + "node_modules/supports-preserve-symlinks-flag": { + "version": "1.0.0", + "resolved": "https://registry.npmjs.org/supports-preserve-symlinks-flag/-/supports-preserve-symlinks-flag-1.0.0.tgz", + "integrity": "sha512-ot0WnXS9fgdkgIcePe6RHNk1WA8+muPa6cSjeR3V8K27q9BB1rTE3R1p7Hv0z1ZyAc8s6Vvv8DIyWf681MAt0w==", + "dev": true, + "engines": { + "node": ">= 0.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/tapable": { + "version": "2.2.1", + "resolved": "https://registry.npmjs.org/tapable/-/tapable-2.2.1.tgz", + "integrity": "sha512-GNzQvQTOIP6RyTfE2Qxb8ZVlNmw0n88vp1szwWRimP02mnTsx3Wtn5qRdqY9w2XduFNUgvOwhNnQsjwCp+kqaQ==", + "dev": true, + "engines": { + "node": ">=6" + } + }, + "node_modules/terser": { + "version": "5.31.1", + "resolved": "https://registry.npmjs.org/terser/-/terser-5.31.1.tgz", + "integrity": "sha512-37upzU1+viGvuFtBo9NPufCb9dwM0+l9hMxYyWfBA+fbwrPqNJAhbZ6W47bBFnZHKHTUBnMvi87434qq+qnxOg==", + "dev": true, + "dependencies": { + "@jridgewell/source-map": "^0.3.3", + "acorn": "^8.8.2", + "commander": "^2.20.0", + "source-map-support": "~0.5.20" + }, + "bin": { + "terser": "bin/terser" + }, + "engines": { + "node": ">=10" + } + }, + "node_modules/terser-webpack-plugin": { + "version": "5.3.10", + "resolved": "https://registry.npmjs.org/terser-webpack-plugin/-/terser-webpack-plugin-5.3.10.tgz", + "integrity": "sha512-BKFPWlPDndPs+NGGCr1U59t0XScL5317Y0UReNrHaw9/FwhPENlq6bfgs+4yPfyP51vqC1bQ4rp1EfXW5ZSH9w==", + "dev": true, + "dependencies": { + "@jridgewell/trace-mapping": "^0.3.20", + "jest-worker": "^27.4.5", + "schema-utils": "^3.1.1", + "serialize-javascript": "^6.0.1", + "terser": "^5.26.0" + }, + "engines": { + "node": ">= 10.13.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/webpack" + }, + "peerDependencies": { + "webpack": "^5.1.0" + }, + "peerDependenciesMeta": { + "@swc/core": { + "optional": true + }, + "esbuild": { + "optional": true + }, + "uglify-js": { + "optional": true + } + } + }, + "node_modules/thingies": { + "version": "1.21.0", + "resolved": "https://registry.npmjs.org/thingies/-/thingies-1.21.0.tgz", + "integrity": "sha512-hsqsJsFMsV+aD4s3CWKk85ep/3I9XzYV/IXaSouJMYIoDlgyi11cBhsqYe9/geRfB0YIikBQg6raRaM+nIMP9g==", + "dev": true, + "engines": { + "node": ">=10.18" + }, + "peerDependencies": { + "tslib": "^2" + } + }, + "node_modules/thunky": { + "version": "1.1.0", + "resolved": "https://registry.npmjs.org/thunky/-/thunky-1.1.0.tgz", + "integrity": "sha512-eHY7nBftgThBqOyHGVN+l8gF0BucP09fMo0oO/Lb0w1OF80dJv+lDVpXG60WMQvkcxAkNybKsrEIE3ZtKGmPrA==", + "dev": true + }, + "node_modules/to-regex-range": { + "version": "5.0.1", + "resolved": "https://registry.npmjs.org/to-regex-range/-/to-regex-range-5.0.1.tgz", + "integrity": "sha512-65P7iz6X5yEr1cwcgvQxbbIw7Uk3gOy5dIdtZ4rDveLqhrdJP+Li/Hx6tyK0NEb+2GCyneCMJiGqrADCSNk8sQ==", + "dev": true, + "dependencies": { + "is-number": "^7.0.0" + }, + "engines": { + "node": ">=8.0" + } + }, + "node_modules/toidentifier": { + "version": "1.0.1", + "resolved": "https://registry.npmjs.org/toidentifier/-/toidentifier-1.0.1.tgz", + "integrity": "sha512-o5sSPKEkg/DIQNmH43V0/uerLrpzVedkUh8tGNvaeXpfpuwjKenlSox/2O/BTlZUtEe+JG7s5YhEz608PlAHRA==", + "dev": true, + "engines": { + "node": ">=0.6" + } + }, + "node_modules/tree-dump": { + "version": "1.0.2", + "resolved": "https://registry.npmjs.org/tree-dump/-/tree-dump-1.0.2.tgz", + "integrity": "sha512-dpev9ABuLWdEubk+cIaI9cHwRNNDjkBBLXTwI4UCUFdQ5xXKqNXoK4FEciw/vxf+NQ7Cb7sGUyeUtORvHIdRXQ==", + "dev": true, + "engines": { + "node": ">=10.0" + }, + "funding": { + "type": "github", + "url": "https://github.com/sponsors/streamich" + }, + "peerDependencies": { + "tslib": "2" + } + }, + "node_modules/tslib": { + "version": "2.6.3", + "resolved": "https://registry.npmjs.org/tslib/-/tslib-2.6.3.tgz", + "integrity": "sha512-xNvxJEOUiWPGhUuUdQgAJPKOOJfGnIyKySOc09XkKsgdUV/3E2zvwZYdejjmRgPCgcym1juLH3226yA7sEFJKQ==", + "dev": true + }, + "node_modules/type-is": { + "version": "1.6.18", + "resolved": "https://registry.npmjs.org/type-is/-/type-is-1.6.18.tgz", + "integrity": "sha512-TkRKr9sUTxEH8MdfuCSP7VizJyzRNMjj2J2do2Jr3Kym598JVdEksuzPQCnlFPW4ky9Q+iA+ma9BGm06XQBy8g==", + "dev": true, + "dependencies": { + "media-typer": "0.3.0", + "mime-types": "~2.1.24" + }, + "engines": { + "node": ">= 0.6" + } + }, + "node_modules/typesense": { + "version": "1.8.2", + "resolved": "https://registry.npmjs.org/typesense/-/typesense-1.8.2.tgz", + "integrity": "sha512-aBpePjA99Qvo+OP2pJwMpvga4Jrm1Y2oV5NsrWXBxlqUDNEUCPZBIksPv2Hq0jxQxHhLLyJVbjXjByXsvpCDVA==", + "dependencies": { + "axios": "^1.6.0", + "loglevel": "^1.8.1" + }, + "engines": { + "node": ">=18" + }, + "peerDependencies": { + "@babel/runtime": "^7.23.2" + } + }, + "node_modules/typesense-instantsearch-adapter": { + "version": "2.8.0", + "resolved": "https://registry.npmjs.org/typesense-instantsearch-adapter/-/typesense-instantsearch-adapter-2.8.0.tgz", + "integrity": "sha512-2q4QVpHoUV0ncf1XOqIC0dufOTkFRxQ0mHzg//H3WK02ZYqdNNPCAacZODhQlltl1cNJdTI8Y4uuGVd6fJuGzw==", + "hasInstallScript": true, + "dependencies": { + "typesense": "^1.7.2" + }, + "engines": { + "node": ">=16" + }, + "peerDependencies": { + "@babel/runtime": "^7.17.2" + } + }, + "node_modules/undici-types": { + "version": "5.26.5", + "resolved": "https://registry.npmjs.org/undici-types/-/undici-types-5.26.5.tgz", + "integrity": "sha512-JlCMO+ehdEIKqlFxk6IfVoAUVmgz7cU7zD/h9XZ0qzeosSHmUJVOzSQvvYSYWXkFXC+IfLKSIffhv0sVZup6pA==", + "dev": true + }, + "node_modules/unicorn-magic": { + "version": "0.1.0", + "resolved": "https://registry.npmjs.org/unicorn-magic/-/unicorn-magic-0.1.0.tgz", + "integrity": "sha512-lRfVq8fE8gz6QMBuDM6a+LO3IAzTi05H6gCVaUpir2E1Rwpo4ZUog45KpNXKC/Mn3Yb9UDuHumeFTo9iV/D9FQ==", + "dev": true, + "engines": { + "node": ">=18" + }, + "funding": { + "url": "https://github.com/sponsors/sindresorhus" + } + }, + "node_modules/unpipe": { + "version": "1.0.0", + "resolved": "https://registry.npmjs.org/unpipe/-/unpipe-1.0.0.tgz", + "integrity": "sha512-pjy2bYhSsufwWlKwPc+l3cN7+wuJlK6uz0YdJEOlQDbl6jo/YlPi4mb8agUkVC8BF7V8NuzeyPNqRksA3hztKQ==", + "dev": true, + "engines": { + "node": ">= 0.8" + } + }, + "node_modules/update-browserslist-db": { + "version": "1.1.0", + "resolved": "https://registry.npmjs.org/update-browserslist-db/-/update-browserslist-db-1.1.0.tgz", + "integrity": "sha512-EdRAaAyk2cUE1wOf2DkEhzxqOQvFOoRJFNS6NeyJ01Gp2beMRpBAINjM2iDXE3KCuKhwnvHIQCJm6ThL2Z+HzQ==", + "dev": true, + "funding": [ + { + "type": "opencollective", + "url": "https://opencollective.com/browserslist" + }, + { + "type": "tidelift", + "url": "https://tidelift.com/funding/github/npm/browserslist" + }, + { + "type": "github", + "url": "https://github.com/sponsors/ai" + } + ], + "dependencies": { + "escalade": "^3.1.2", + "picocolors": "^1.0.1" + }, + "bin": { + "update-browserslist-db": "cli.js" + }, + "peerDependencies": { + "browserslist": ">= 4.21.0" + } + }, + "node_modules/uri-js": { + "version": "4.4.1", + "resolved": "https://registry.npmjs.org/uri-js/-/uri-js-4.4.1.tgz", + "integrity": "sha512-7rKUyy33Q1yc98pQ1DAmLtwX109F7TIfWlW1Ydo8Wl1ii1SeHieeh0HHfPeL2fMXK6z0s8ecKs9frCuLJvndBg==", + "dev": true, + "dependencies": { + "punycode": "^2.1.0" + } + }, + "node_modules/util-deprecate": { + "version": "1.0.2", + "resolved": "https://registry.npmjs.org/util-deprecate/-/util-deprecate-1.0.2.tgz", + "integrity": "sha512-EPD5q1uXyFxJpCrLnCc1nHnq3gOa6DZBocAIiI2TaSCA7VCJ1UJDMagCzIkXNsUYfD1daK//LTEQ8xiIbrHtcw==", + "dev": true + }, + "node_modules/utils-merge": { + "version": "1.0.1", + "resolved": "https://registry.npmjs.org/utils-merge/-/utils-merge-1.0.1.tgz", + "integrity": "sha512-pMZTvIkT1d+TFGvDOqodOclx0QWkkgi6Tdoa8gC8ffGAAqz9pzPTZWAybbsHHoED/ztMtkv/VoYTYyShUn81hA==", + "dev": true, + "engines": { + "node": ">= 0.4.0" + } + }, + "node_modules/uuid": { + "version": "8.3.2", + "resolved": "https://registry.npmjs.org/uuid/-/uuid-8.3.2.tgz", + "integrity": "sha512-+NYs2QeMWy+GWFOEm9xnn6HCDp0l7QBD7ml8zLUmJ+93Q5NF0NocErnwkTkXVFNiX3/fpC6afS8Dhb/gz7R7eg==", + "dev": true, + "bin": { + "uuid": "dist/bin/uuid" + } + }, + "node_modules/vary": { + "version": "1.1.2", + "resolved": "https://registry.npmjs.org/vary/-/vary-1.1.2.tgz", + "integrity": "sha512-BNGbWLfd0eUPabhkXUVm0j8uuvREyTh5ovRa/dyow/BqAbZJyC+5fU+IzQOzmAKzYqYRAISoRhdQr3eIZ/PXqg==", + "dev": true, + "engines": { + "node": ">= 0.8" + } + }, + "node_modules/watchpack": { + "version": "2.4.1", + "resolved": "https://registry.npmjs.org/watchpack/-/watchpack-2.4.1.tgz", + "integrity": "sha512-8wrBCMtVhqcXP2Sup1ctSkga6uc2Bx0IIvKyT7yTFier5AXHooSI+QyQQAtTb7+E0IUCCKyTFmXqdqgum2XWGg==", + "dev": true, + "dependencies": { + "glob-to-regexp": "^0.4.1", + "graceful-fs": "^4.1.2" + }, + "engines": { + "node": ">=10.13.0" + } + }, + "node_modules/wbuf": { + "version": "1.7.3", + "resolved": "https://registry.npmjs.org/wbuf/-/wbuf-1.7.3.tgz", + "integrity": "sha512-O84QOnr0icsbFGLS0O3bI5FswxzRr8/gHwWkDlQFskhSPryQXvrTMxjxGP4+iWYoauLoBvfDpkrOauZ+0iZpDA==", + "dev": true, + "dependencies": { + "minimalistic-assert": "^1.0.0" + } + }, + "node_modules/webpack": { + "version": "5.92.1", + "resolved": "https://registry.npmjs.org/webpack/-/webpack-5.92.1.tgz", + "integrity": "sha512-JECQ7IwJb+7fgUFBlrJzbyu3GEuNBcdqr1LD7IbSzwkSmIevTm8PF+wej3Oxuz/JFBUZ6O1o43zsPkwm1C4TmA==", + "dev": true, + "dependencies": { + "@types/eslint-scope": "^3.7.3", + "@types/estree": "^1.0.5", + "@webassemblyjs/ast": "^1.12.1", + "@webassemblyjs/wasm-edit": "^1.12.1", + "@webassemblyjs/wasm-parser": "^1.12.1", + "acorn": "^8.7.1", + "acorn-import-attributes": "^1.9.5", + "browserslist": "^4.21.10", + "chrome-trace-event": "^1.0.2", + "enhanced-resolve": "^5.17.0", + "es-module-lexer": "^1.2.1", + "eslint-scope": "5.1.1", + "events": "^3.2.0", + "glob-to-regexp": "^0.4.1", + "graceful-fs": "^4.2.11", + "json-parse-even-better-errors": "^2.3.1", + "loader-runner": "^4.2.0", + "mime-types": "^2.1.27", + "neo-async": "^2.6.2", + "schema-utils": "^3.2.0", + "tapable": "^2.1.1", + "terser-webpack-plugin": "^5.3.10", + "watchpack": "^2.4.1", + "webpack-sources": "^3.2.3" + }, + "bin": { + "webpack": "bin/webpack.js" + }, + "engines": { + "node": ">=10.13.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/webpack" + }, + "peerDependenciesMeta": { + "webpack-cli": { + "optional": true + } + } + }, + "node_modules/webpack-cli": { + "version": "5.1.4", + "resolved": "https://registry.npmjs.org/webpack-cli/-/webpack-cli-5.1.4.tgz", + "integrity": "sha512-pIDJHIEI9LR0yxHXQ+Qh95k2EvXpWzZ5l+d+jIo+RdSm9MiHfzazIxwwni/p7+x4eJZuvG1AJwgC4TNQ7NRgsg==", + "dev": true, + "dependencies": { + "@discoveryjs/json-ext": "^0.5.0", + "@webpack-cli/configtest": "^2.1.1", + "@webpack-cli/info": "^2.0.2", + "@webpack-cli/serve": "^2.0.5", + "colorette": "^2.0.14", + "commander": "^10.0.1", + "cross-spawn": "^7.0.3", + "envinfo": "^7.7.3", + "fastest-levenshtein": "^1.0.12", + "import-local": "^3.0.2", + "interpret": "^3.1.1", + "rechoir": "^0.8.0", + "webpack-merge": "^5.7.3" + }, + "bin": { + "webpack-cli": "bin/cli.js" + }, + "engines": { + "node": ">=14.15.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/webpack" + }, + "peerDependencies": { + "webpack": "5.x.x" + }, + "peerDependenciesMeta": { + "@webpack-cli/generators": { + "optional": true + }, + "webpack-bundle-analyzer": { + "optional": true + }, + "webpack-dev-server": { + "optional": true + } + } + }, + "node_modules/webpack-cli/node_modules/commander": { + "version": "10.0.1", + "resolved": "https://registry.npmjs.org/commander/-/commander-10.0.1.tgz", + "integrity": "sha512-y4Mg2tXshplEbSGzx7amzPwKKOCGuoSRP/CjEdwwk0FOGlUbq6lKuoyDZTNZkmxHdJtp54hdfY/JUrdL7Xfdug==", + "dev": true, + "engines": { + "node": ">=14" + } + }, + "node_modules/webpack-dev-middleware": { + "version": "7.2.1", + "resolved": "https://registry.npmjs.org/webpack-dev-middleware/-/webpack-dev-middleware-7.2.1.tgz", + "integrity": "sha512-hRLz+jPQXo999Nx9fXVdKlg/aehsw1ajA9skAneGmT03xwmyuhvF93p6HUKKbWhXdcERtGTzUCtIQr+2IQegrA==", + "dev": true, + "dependencies": { + "colorette": "^2.0.10", + "memfs": "^4.6.0", + "mime-types": "^2.1.31", + "on-finished": "^2.4.1", + "range-parser": "^1.2.1", + "schema-utils": "^4.0.0" + }, + "engines": { + "node": ">= 18.12.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/webpack" + }, + "peerDependencies": { + "webpack": "^5.0.0" + }, + "peerDependenciesMeta": { + "webpack": { + "optional": true + } + } + }, + "node_modules/webpack-dev-middleware/node_modules/ajv": { + "version": "8.16.0", + "resolved": "https://registry.npmjs.org/ajv/-/ajv-8.16.0.tgz", + "integrity": "sha512-F0twR8U1ZU67JIEtekUcLkXkoO5mMMmgGD8sK/xUFzJ805jxHQl92hImFAqqXMyMYjSPOyUPAwHYhB72g5sTXw==", + "dev": true, + "dependencies": { + "fast-deep-equal": "^3.1.3", + "json-schema-traverse": "^1.0.0", + "require-from-string": "^2.0.2", + "uri-js": "^4.4.1" + }, + "funding": { + "type": "github", + "url": "https://github.com/sponsors/epoberezkin" + } + }, + "node_modules/webpack-dev-middleware/node_modules/ajv-keywords": { + "version": "5.1.0", + "resolved": "https://registry.npmjs.org/ajv-keywords/-/ajv-keywords-5.1.0.tgz", + "integrity": "sha512-YCS/JNFAUyr5vAuhk1DWm1CBxRHW9LbJ2ozWeemrIqpbsqKjHVxYPyi5GC0rjZIT5JxJ3virVTS8wk4i/Z+krw==", + "dev": true, + "dependencies": { + "fast-deep-equal": "^3.1.3" + }, + "peerDependencies": { + "ajv": "^8.8.2" + } + }, + "node_modules/webpack-dev-middleware/node_modules/json-schema-traverse": { + "version": "1.0.0", + "resolved": "https://registry.npmjs.org/json-schema-traverse/-/json-schema-traverse-1.0.0.tgz", + "integrity": "sha512-NM8/P9n3XjXhIZn1lLhkFaACTOURQXjWhV4BA/RnOv8xvgqtqpAX9IO4mRQxSx1Rlo4tqzeqb0sOlruaOy3dug==", + "dev": true + }, + "node_modules/webpack-dev-middleware/node_modules/schema-utils": { + "version": "4.2.0", + "resolved": "https://registry.npmjs.org/schema-utils/-/schema-utils-4.2.0.tgz", + "integrity": "sha512-L0jRsrPpjdckP3oPug3/VxNKt2trR8TcabrM6FOAAlvC/9Phcmm+cuAgTlxBqdBR1WJx7Naj9WHw+aOmheSVbw==", + "dev": true, + "dependencies": { + "@types/json-schema": "^7.0.9", + "ajv": "^8.9.0", + "ajv-formats": "^2.1.1", + "ajv-keywords": "^5.1.0" + }, + "engines": { + "node": ">= 12.13.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/webpack" + } + }, + "node_modules/webpack-dev-server": { + "version": "5.0.4", + "resolved": "https://registry.npmjs.org/webpack-dev-server/-/webpack-dev-server-5.0.4.tgz", + "integrity": "sha512-dljXhUgx3HqKP2d8J/fUMvhxGhzjeNVarDLcbO/EWMSgRizDkxHQDZQaLFL5VJY9tRBj2Gz+rvCEYYvhbqPHNA==", + "dev": true, + "dependencies": { + "@types/bonjour": "^3.5.13", + "@types/connect-history-api-fallback": "^1.5.4", + "@types/express": "^4.17.21", + "@types/serve-index": "^1.9.4", + "@types/serve-static": "^1.15.5", + "@types/sockjs": "^0.3.36", + "@types/ws": "^8.5.10", + "ansi-html-community": "^0.0.8", + "bonjour-service": "^1.2.1", + "chokidar": "^3.6.0", + "colorette": "^2.0.10", + "compression": "^1.7.4", + "connect-history-api-fallback": "^2.0.0", + "default-gateway": "^6.0.3", + "express": "^4.17.3", + "graceful-fs": "^4.2.6", + "html-entities": "^2.4.0", + "http-proxy-middleware": "^2.0.3", + "ipaddr.js": "^2.1.0", + "launch-editor": "^2.6.1", + "open": "^10.0.3", + "p-retry": "^6.2.0", + "rimraf": "^5.0.5", + "schema-utils": "^4.2.0", + "selfsigned": "^2.4.1", + "serve-index": "^1.9.1", + "sockjs": "^0.3.24", + "spdy": "^4.0.2", + "webpack-dev-middleware": "^7.1.0", + "ws": "^8.16.0" + }, + "bin": { + "webpack-dev-server": "bin/webpack-dev-server.js" + }, + "engines": { + "node": ">= 18.12.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/webpack" + }, + "peerDependencies": { + "webpack": "^5.0.0" + }, + "peerDependenciesMeta": { + "webpack": { + "optional": true + }, + "webpack-cli": { + "optional": true + } + } + }, + "node_modules/webpack-dev-server/node_modules/ajv": { + "version": "8.16.0", + "resolved": "https://registry.npmjs.org/ajv/-/ajv-8.16.0.tgz", + "integrity": "sha512-F0twR8U1ZU67JIEtekUcLkXkoO5mMMmgGD8sK/xUFzJ805jxHQl92hImFAqqXMyMYjSPOyUPAwHYhB72g5sTXw==", + "dev": true, + "dependencies": { + "fast-deep-equal": "^3.1.3", + "json-schema-traverse": "^1.0.0", + "require-from-string": "^2.0.2", + "uri-js": "^4.4.1" + }, + "funding": { + "type": "github", + "url": "https://github.com/sponsors/epoberezkin" + } + }, + "node_modules/webpack-dev-server/node_modules/ajv-keywords": { + "version": "5.1.0", + "resolved": "https://registry.npmjs.org/ajv-keywords/-/ajv-keywords-5.1.0.tgz", + "integrity": "sha512-YCS/JNFAUyr5vAuhk1DWm1CBxRHW9LbJ2ozWeemrIqpbsqKjHVxYPyi5GC0rjZIT5JxJ3virVTS8wk4i/Z+krw==", + "dev": true, + "dependencies": { + "fast-deep-equal": "^3.1.3" + }, + "peerDependencies": { + "ajv": "^8.8.2" + } + }, + "node_modules/webpack-dev-server/node_modules/json-schema-traverse": { + "version": "1.0.0", + "resolved": "https://registry.npmjs.org/json-schema-traverse/-/json-schema-traverse-1.0.0.tgz", + "integrity": "sha512-NM8/P9n3XjXhIZn1lLhkFaACTOURQXjWhV4BA/RnOv8xvgqtqpAX9IO4mRQxSx1Rlo4tqzeqb0sOlruaOy3dug==", + "dev": true + }, + "node_modules/webpack-dev-server/node_modules/schema-utils": { + "version": "4.2.0", + "resolved": "https://registry.npmjs.org/schema-utils/-/schema-utils-4.2.0.tgz", + "integrity": "sha512-L0jRsrPpjdckP3oPug3/VxNKt2trR8TcabrM6FOAAlvC/9Phcmm+cuAgTlxBqdBR1WJx7Naj9WHw+aOmheSVbw==", + "dev": true, + "dependencies": { + "@types/json-schema": "^7.0.9", + "ajv": "^8.9.0", + "ajv-formats": "^2.1.1", + "ajv-keywords": "^5.1.0" + }, + "engines": { + "node": ">= 12.13.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/webpack" + } + }, + "node_modules/webpack-merge": { + "version": "5.10.0", + "resolved": "https://registry.npmjs.org/webpack-merge/-/webpack-merge-5.10.0.tgz", + "integrity": "sha512-+4zXKdx7UnO+1jaN4l2lHVD+mFvnlZQP/6ljaJVb4SZiwIKeUnrT5l0gkT8z+n4hKpC+jpOv6O9R+gLtag7pSA==", + "dev": true, + "dependencies": { + "clone-deep": "^4.0.1", + "flat": "^5.0.2", + "wildcard": "^2.0.0" + }, + "engines": { + "node": ">=10.0.0" + } + }, + "node_modules/webpack-sources": { + "version": "3.2.3", + "resolved": "https://registry.npmjs.org/webpack-sources/-/webpack-sources-3.2.3.tgz", + "integrity": "sha512-/DyMEOrDgLKKIG0fmvtz+4dUX/3Ghozwgm6iPp8KRhvn+eQf9+Q7GWxVNMk3+uCPWfdXYC4ExGBckIXdFEfH1w==", + "dev": true, + "engines": { + "node": ">=10.13.0" + } + }, + "node_modules/websocket-driver": { + "version": "0.7.4", + "resolved": "https://registry.npmjs.org/websocket-driver/-/websocket-driver-0.7.4.tgz", + "integrity": "sha512-b17KeDIQVjvb0ssuSDF2cYXSg2iztliJ4B9WdsuB6J952qCPKmnVq4DyW5motImXHDC1cBT/1UezrJVsKw5zjg==", + "dev": true, + "dependencies": { + "http-parser-js": ">=0.5.1", + "safe-buffer": ">=5.1.0", + "websocket-extensions": ">=0.1.1" + }, + "engines": { + "node": ">=0.8.0" + } + }, + "node_modules/websocket-extensions": { + "version": "0.1.4", + "resolved": "https://registry.npmjs.org/websocket-extensions/-/websocket-extensions-0.1.4.tgz", + "integrity": "sha512-OqedPIGOfsDlo31UNwYbCFMSaO9m9G/0faIHj5/dZFDMFqPTcx6UwqyOy3COEaEOg/9VsGIpdqn62W5KhoKSpg==", + "dev": true, + "engines": { + "node": ">=0.8.0" + } + }, + "node_modules/which": { + "version": "2.0.2", + "resolved": "https://registry.npmjs.org/which/-/which-2.0.2.tgz", + "integrity": "sha512-BLI3Tl1TW3Pvl70l3yq3Y64i+awpwXqsGBYWkkqMtnbXgrMD+yj7rhW0kuEDxzJaYXGjEW5ogapKNMEKNMjibA==", + "dev": true, + "dependencies": { + "isexe": "^2.0.0" + }, + "bin": { + "node-which": "bin/node-which" + }, + "engines": { + "node": ">= 8" + } + }, + "node_modules/wildcard": { + "version": "2.0.1", + "resolved": "https://registry.npmjs.org/wildcard/-/wildcard-2.0.1.tgz", + "integrity": "sha512-CC1bOL87PIWSBhDcTrdeLo6eGT7mCFtrg0uIJtqJUFyK+eJnzl8A1niH56uu7KMa5XFrtiV+AQuHO3n7DsHnLQ==", + "dev": true + }, + "node_modules/wrap-ansi": { + "version": "8.1.0", + "resolved": "https://registry.npmjs.org/wrap-ansi/-/wrap-ansi-8.1.0.tgz", + "integrity": "sha512-si7QWI6zUMq56bESFvagtmzMdGOtoxfR+Sez11Mobfc7tm+VkUckk9bW2UeffTGVUbOksxmSw0AA2gs8g71NCQ==", + "dev": true, + "dependencies": { + "ansi-styles": "^6.1.0", + "string-width": "^5.0.1", + "strip-ansi": "^7.0.1" + }, + "engines": { + "node": ">=12" + }, + "funding": { + "url": "https://github.com/chalk/wrap-ansi?sponsor=1" + } + }, + "node_modules/wrap-ansi-cjs": { + "name": "wrap-ansi", + "version": "7.0.0", + "resolved": "https://registry.npmjs.org/wrap-ansi/-/wrap-ansi-7.0.0.tgz", + "integrity": "sha512-YVGIj2kamLSTxw6NsZjoBxfSwsn0ycdesmc4p+Q21c5zPuZ1pl+NfxVdxPtdHvmNVOQ6XSYG4AUtyt/Fi7D16Q==", + "dev": true, + "dependencies": { + "ansi-styles": "^4.0.0", + "string-width": "^4.1.0", + "strip-ansi": "^6.0.0" + }, + "engines": { + "node": ">=10" + }, + "funding": { + "url": "https://github.com/chalk/wrap-ansi?sponsor=1" + } + }, + "node_modules/wrap-ansi-cjs/node_modules/ansi-regex": { + "version": "5.0.1", + "resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-5.0.1.tgz", + "integrity": "sha512-quJQXlTSUGL2LH9SUXo8VwsY4soanhgo6LNSm84E1LBcE8s3O0wpdiRzyR9z/ZZJMlMWv37qOOb9pdJlMUEKFQ==", + "dev": true, + "engines": { + "node": ">=8" + } + }, + "node_modules/wrap-ansi-cjs/node_modules/ansi-styles": { + "version": "4.3.0", + "resolved": "https://registry.npmjs.org/ansi-styles/-/ansi-styles-4.3.0.tgz", + "integrity": "sha512-zbB9rCJAT1rbjiVDb2hqKFHNYLxgtk8NURxZ3IZwD3F6NtxbXZQCnnSi1Lkx+IDohdPlFp222wVALIheZJQSEg==", + "dev": true, + "dependencies": { + "color-convert": "^2.0.1" + }, + "engines": { + "node": ">=8" + }, + "funding": { + "url": "https://github.com/chalk/ansi-styles?sponsor=1" + } + }, + "node_modules/wrap-ansi-cjs/node_modules/emoji-regex": { + "version": "8.0.0", + "resolved": "https://registry.npmjs.org/emoji-regex/-/emoji-regex-8.0.0.tgz", + "integrity": "sha512-MSjYzcWNOA0ewAHpz0MxpYFvwg6yjy1NG3xteoqz644VCo/RPgnr1/GGt+ic3iJTzQ8Eu3TdM14SawnVUmGE6A==", + "dev": true + }, + "node_modules/wrap-ansi-cjs/node_modules/string-width": { + "version": "4.2.3", + "resolved": "https://registry.npmjs.org/string-width/-/string-width-4.2.3.tgz", + "integrity": "sha512-wKyQRQpjJ0sIp62ErSZdGsjMJWsap5oRNihHhu6G7JVO/9jIB6UyevL+tXuOqrng8j/cxKTWyWUwvSTriiZz/g==", + "dev": true, + "dependencies": { + "emoji-regex": "^8.0.0", + "is-fullwidth-code-point": "^3.0.0", + "strip-ansi": "^6.0.1" + }, + "engines": { + "node": ">=8" + } + }, + "node_modules/wrap-ansi-cjs/node_modules/strip-ansi": { + "version": "6.0.1", + "resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-6.0.1.tgz", + "integrity": "sha512-Y38VPSHcqkFrCpFnQ9vuSXmquuv5oXOKpGeT6aGrr3o3Gc9AlVa6JBfUSOCnbxGGZF+/0ooI7KrPuUSztUdU5A==", + "dev": true, + "dependencies": { + "ansi-regex": "^5.0.1" + }, + "engines": { + "node": ">=8" + } + }, + "node_modules/ws": { + "version": "8.18.0", + "resolved": "https://registry.npmjs.org/ws/-/ws-8.18.0.tgz", + "integrity": "sha512-8VbfWfHLbbwu3+N6OKsOMpBdT4kXPDDB9cJk2bJ6mh9ucxdlnNvH1e+roYkKmN9Nxw2yjz7VzeO9oOz2zJ04Pw==", + "dev": true, + "engines": { + "node": ">=10.0.0" + }, + "peerDependencies": { + "bufferutil": "^4.0.1", + "utf-8-validate": ">=5.0.2" + }, + "peerDependenciesMeta": { + "bufferutil": { + "optional": true + }, + "utf-8-validate": { + "optional": true + } + } + } + } +} diff --git a/package.json b/package.json new file mode 100644 index 0000000..cc06431 --- /dev/null +++ b/package.json @@ -0,0 +1,26 @@ +{ + "name": "kerisse", + "version": "1.0.0", + "description": "", + "scripts": { + "test": "echo \"Error: no test specified\" && exit 1", + "build": "webpack", + "start": "webpack serve --open" + }, + "keywords": [], + "author": "", + "license": "ISC", + "devDependencies": { + "copy-webpack-plugin": "^12.0.2", + "css-loader": "^7.1.2", + "mini-css-extract-plugin": "^2.9.0", + "style-loader": "^4.0.0", + "webpack": "^5.92.1", + "webpack-cli": "^5.1.4", + "webpack-dev-server": "^5.0.4" + }, + "dependencies": { + "instantsearch.js": "^4.8.3", + "typesense-instantsearch-adapter": "^2.4.1" + } +} diff --git a/paths.js b/paths.js new file mode 100644 index 0000000..b43df1c --- /dev/null +++ b/paths.js @@ -0,0 +1,7 @@ +const paths = { + url: "https://weboftrust.github.io", + baseUrl: "/kerisse/", + indexedInKERISSE: "indexed-in-KERISSE.html" +} + +module.exports = paths; \ No newline at end of file diff --git a/search-index-typesense/backup.sh b/search-index-typesense/backup.sh new file mode 100644 index 0000000..ac0afd0 --- /dev/null +++ b/search-index-typesense/backup.sh @@ -0,0 +1,94 @@ +#!/bin/bash + +# Author: Kor Dwarshuis +# Created: 2023-08-11 +# Updated: - +# Description: This script backups directories related to scraping and indexing in Typesense to a timestamped directory in the KERISSE_BACKUPS_DIR directory. The name of the directory containing the backups is the timestamp of the backup. + +# Load environment variables from .env file +source .env + +# Logger generates a log file with a timestamp and from which file the message comes from. +source ./${SEARCH_INDEX_DIR}/logger.sh + +# Check if KERISSE_BACKUPS_DIR is set +if [ -z "$KERISSE_BACKUPS_DIR" ]; then + setLogFile "error.log" + log "KERISSE_BACKUPS_DIR is not set in the .env file." + exit 1 +fi + +# Create a human-readable timestamp +TIMESTAMP=$(date +"%Y-%m-%d_%H-%M-%S") + +# Define the destination backup directory with timestamp +BACKUP_DIR="${KERISSE_BACKUPS_DIR}${TIMESTAMP}" + +# Check and create the backup directory +mkdir -p "$BACKUP_DIR" + +# List of directories to backup +declare -a dirsToBackup=("${SEARCH_INDEX_DIR}/logs" "${SEARCH_INDEX_DIR}/search-index-entries" "${SEARCH_INDEX_DIR}/sitemaps" "docs/${OVERVIEW_DIR}") + +for dir in "${dirsToBackup[@]}"; do + SOURCE_DIR="${dir}" + if [ -d "$SOURCE_DIR" ]; then + # Copy directory to backup location + cp -r "$SOURCE_DIR" "$BACKUP_DIR" + + + else + setLogFile "error.log" + log "Warning: Directory $SOURCE_DIR does not exist." + fi +done + +setLogFile "success.log" +log "Backup completed to $BACKUP_DIR" + + +#################### +# BACKUP TYPESENSE COLLECTION +#################### + +setLogFile "success.log" +log "Start export from Typesense" + +# Credentials and settings for Typesense export +local_TYPESENSE_ADMIN_API_KEY="${TYPESENSE_ADMIN_API_KEY}" +local_TYPESENSE_HOST="${TYPESENSE_HOST}" +local_TYPESENSE_COLLECTION_NAME="${TYPESENSE_COLLECTION_NAME}" + +# Create directory for Typesense export +mkdir "${BACKUP_DIR}/typesense-export" + +# Export Typesense data to JSONL file in the backup directory with timestamp in the filename +curl -H "X-TYPESENSE-API-KEY: ${local_TYPESENSE_ADMIN_API_KEY}" \ + "https://${local_TYPESENSE_HOST}.a1.typesense.net/collections/${local_TYPESENSE_COLLECTION_NAME}/documents/export" > "${BACKUP_DIR}/typesense-export/${TIMESTAMP}-typesense-export.jsonl" + +setLogFile "success.log" +log "Finished export from Typesense" + + +setLogFile "success.log" +log "Copy exported Typesense file to second location, for easy restore." + +# Copy the just exported file to a second location, namely a location inside the search-index-typesense directory where a restore from can be done +# Copy the file ${TIMESTAMP}-typesense-export.jsonl from the ${BACKUP_DIR}/typesense-export/ directory +# to the ${SEARCH_INDEX_DIR}/${KERISSE_RESTORE_DIR} directory and name it restore.jsonl. +# If restore.jsonl already exists in the destination directory, it will be overwritten. + +# Define source and destination directories and filenames +src_dir="${BACKUP_DIR}/typesense-export" +src_file="${TIMESTAMP}-typesense-export.jsonl" +dest_dir="${SEARCH_INDEX_DIR}/${KERISSE_RESTORE_DIR}" +dest_file="restore.jsonl" + +# Copy and rename the file +cp "$src_dir/$src_file" "$dest_dir/$dest_file" + +# Print a message to indicate success +echo "Successfully copied $src_file from $src_dir to $dest_dir and renamed it to $dest_file." + +setLogFile "success.log" +log "Typesense export completed to $BACKUP_DIR" diff --git a/search-index-typesense/collectScrapedUrls.mjs b/search-index-typesense/collectScrapedUrls.mjs new file mode 100644 index 0000000..2bf890b --- /dev/null +++ b/search-index-typesense/collectScrapedUrls.mjs @@ -0,0 +1,77 @@ +/* + Author: Kor Dwarshuis + Created: 2023-10-04 + Updated: – + Description: + + This Node.js script is designed to read all .jsonl files in a specified directory, + extract URLs from each entry, and then output them to a file. It offers the following functionalities: + + 1. Reading JSONL Files: The script scans the given directory for .jsonl files and reads them line by line, + parsing each line as a JSON object. + + 2. Extracting URLs: The script looks for a "url" field in each JSON object and collects these URLs into an array. + + 3. Removing Duplicates: It eliminates any duplicate URLs from the array. + + 4. Outputting to File: The unique URLs are then written to a configurable output file, each on a new line. + + Usage: + + node [input_directory] [output_file] + + - input_directory: Optional. Specifies the directory to read .jsonl files from. Defaults to './input'. + - output_file: Optional. Specifies the name of the output file. Defaults to 'output.html'. +*/ + +import fs from 'fs'; +import path from 'path'; + +// Function to read JSONL files in a directory +const readJSONLFiles = (dirPath) => { + const allUrls = []; + const files = fs.readdirSync(dirPath); + + for (const file of files) { + if (path.extname(file) === '.jsonl') { + const content = fs.readFileSync(path.join(dirPath, file), 'utf-8'); + const lines = content.split('\n'); + + for (const line of lines) { + try { + const json = JSON.parse(line); + if (json.url) { + allUrls.push(json.url); + } + } catch (e) { + // Ignore parsing errors for this example + } + } + } + } + return allUrls; +}; + +// Function to remove duplicates +const removeDuplicates = (arr) => [...new Set(arr)]; + +// Function to create HTML from URLs +const createUrls = (urls) => { + return urls.join('\n'); +}; + + +// Main function +const main = () => { + const inputDir = process.argv[2] || './input'; // Default to './input' directory + const outputFile = process.argv[3] || 'output.html'; // Default to 'output.html' + + const allUrls = readJSONLFiles(inputDir); + const uniqueUrls = removeDuplicates(allUrls); + const html = createUrls(uniqueUrls); + + fs.writeFileSync(outputFile, html); + console.log(`HTML list written to ${outputFile}`); +}; + +main(); diff --git a/search-index-typesense/config/config-search-index-entries-manual/README.md b/search-index-typesense/config/config-search-index-entries-manual/README.md new file mode 100644 index 0000000..c4b3058 --- /dev/null +++ b/search-index-typesense/config/config-search-index-entries-manual/README.md @@ -0,0 +1,7 @@ +# Information + +These files can be in .json or .jsonl format. They are directly copied into the directory that holds files that are imported into Typesense. + +You are free to name the files. + +See handmade.json` as an example. diff --git a/search-index-typesense/config/config-search-index-entries-manual/gleifPDF.jsonl b/search-index-typesense/config/config-search-index-entries-manual/gleifPDF.jsonl new file mode 100644 index 0000000..a359df0 --- /dev/null +++ b/search-index-typesense/config/config-search-index-entries-manual/gleifPDF.jsonl @@ -0,0 +1,2417 @@ +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/gleif-services/service-reports/gleif-service-report-june-2023/2023-07-14_gleif_service_report_v1.0.pdf","content":"® nabling global identi\nGLEIF Service Report June 2023 —\nAvailability: The identified breaches were caused by a temporary outage of the Operating: All GLEIF services met their service level targets in the reporting period.\naccess network; GLEIF is implementing measures to avoid recurrence of such an\nevent in the future. All other GLEIF services met the availability targets in the\nreporting period.\nAvailability Operating\n. . . . PROCESSING TIME FOR:\nServices with target =99.9% Services with target = 97.7%\n@ Check for Duplicates < 0.1 Minutes /1Minute\n98.4% | Challenge LEI Data 100% | Customer Portal\n@ Data Governance Pre-Check 1Second | 3 Seconds\n98.5% | Check for Duplicates 98.4% | Data Governance Pre-Check (GUI)\n@ GLEIF API 0.1Seconds /1 Second\n98.4% | Data Governance Pre-Check 98.4% | LOU Communications Portal @ LOU Accreditation - Applicant documentation review 44 Days /45 Days\nLOU Accreditation - Candidate documentation review N/A / 3 Months\n98.4% | GLEIF API\n@ LOU Annual Accreditation Verification 30 Days / 30 Days\n98.4% | GLEIF Website\n@ Manage technical incidents - Priority 1 0.9 Hours [ 24 Hours\n98.4% | LEI Search Manage technical incidents - Priority 2 N/A /2 Days\n@ Manage technical incidents - Priority 3 <1Day / 3 Days\n98.4% | Upload LEI & LE-RD Files\n@ Register an account for gleif.org login <1Day / Next Day\n@ Upload LEI & LE-RD Files < 0.1Hours / 1Hour\nDISCLAIMER: All figures of this Service Report are derived from the Global Legal Entity Identifier Foundation (GLEIF). While every care has been taken in the compilation of this information, GLEIF will not be held responsible for any loss,\ndamage or inconvenience caused as a result of inaccuracy or error within the Service Report. The text and graphic content of the Service Report may be used, printed and distributed ONLY with the copyright information displayed (©\nCopyright Global Legal Entity Identifier Foundation (GLEIF)).\n","contentLength":1919,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:17:54.079Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/gleif-services/iso-20000-certification/itms_707855.pdf","content":"bsi o\n. e 3&\"——‘—\\‘:@@ &4\nBy Royal Charter\nIT SERVICE MANAGEMENT SYSTEM - ISO/IEC 20000-1:2018\nThis is to certify that: Global Legal Entity Identifier\nFoundation (GLEIF)\nBleichstrasse 59\nFrankfurt am Main\n60313\nGermany\nHolds Certificate No: ITMS 707855\nand operates an IT Service Management System which complies with the requirements of ISO/IEC 20000-1:2018 for\nthe following scope:\nhe service management system of Global Legal Entity Identifier Foundation (GLEIF)\nsupporting the provision of Partnership Program Services to LEI Issuers (LOUs) from\nFrankfurt/Main, Germany\nFor and on behalf of BSI: l; Lé 2 : g\nAndrew Launn, EMEA Systems Certification Director\nOriginal Registration Date: 2019-10-18 Effective Date: 2021-08-02\nLatest Revision Date: 2022-07-15 Expiry Date: 2024-08-01\nEEeresm | oly Page: 1 of 2\nE T\nobia \"\"‘-:EF\"J @\ngugfi'%i UKAS . ST\nL REE | MRS ..making excellence a habit.\n0003\nThis certificate was issued electronically and remains the property of BSI and is bound by the conditions of contract.\nAn electronic certificate can be authenticated online.\nPrinted copies can be validated at www.bsigroup.com/ClientDirectory\nInformation and Contact: BSI, Kitemark Court, Davy Avenue, Knowlhill, Milton Keynes MK5 8PP. Tel: + 44 345 080 9000\nBSI Assurance UK Limited, registered in England under number 7805321 at 389 Chiswick High Road, London W4 4AL, UK.\n","contentLength":1370,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:18:01.617Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/gleif-services/iso-20000-certification/itms_707855.pdf","content":"Certificate No: ITMS 707855\nLocation Registered Activities\nGlobal Legal Entity Identifier The service management system of Global Legal Entity\nFoundation (GLEIF) Identifier Foundation (GLEIF) supporting the provision of\nBleichstrasse 59 Partnership Program Services to LEI Issuers (LOUs) from\nFrankfurt am Main Frankfurt/Main, Germany\n60313\nGermany\nOriginal Registration Date: 2019-10-18 Effective Date: 2021-08-02\nLatest Revision Date: 2022-07-15 Expiry Date: 2024-08-01\nPage: 2 of 2\nThis certificate was issued electronically and remains the property of BSI and is bound by the conditions of contract.\nAn electronic certificate can be authenticated online.\nPrinted copies can be validated at www.bsigroup.com/ClientDirectory\nInformation and Contact: BSI, Kitemark Court, Davy Avenue, Knowlhill, Milton Keynes MK5 8PP. Tel: + 44 345 080 9000\nBSI Assurance UK Limited, registered in England under number 7805321 at 389 Chiswick High Road, London W4 4AL, UK.\n","contentLength":958,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:18:01.617Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/gleif-engagement/gleif-stakeholder-groups/gleif-vendor-relationship-group/2022-09-06_gleif-vendor-services-relationship-group-charter_v1.4.pdf","content":"O:GLEIF’ rotarns ciegted e\n\nGLEIF Vendor &\nServices Providers\nRelationship Group\nCharter\n\nGLEIF unrestricted\n","contentLength":109,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:18:16.035Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/gleif-engagement/gleif-stakeholder-groups/gleif-vendor-relationship-group/2022-09-06_gleif-vendor-services-relationship-group-charter_v1.4.pdf","content":"| Introduction\n\nThe Global Legal Entity Identifier Foundation (GLEIF) was established by the\n\nFinancial Stability Board (FSB) as a not-for-profit organization to develop and\n\nmaintain the LEIl as a broad public good for the benefit of the users of the public\n\nand the private sector. Find more about governance structure on www.gleif.org.\n\nGLEIF is subject to the oversight of the ROC (Regulatory Oversight Committee,\n\nwww.leiroc.org) with about 65 financial market regulators and other public\n\nauthorities and 19 observers from over 50 jurisdictions. The ROC references the\n\nprovisions in the GLEIF Statutes for its oversight duties.\n\nGLEIF delivers, under open data terms of use, high quality and free-of-charge\n\nbusiness card information about legal entities.\n\nI GLEIF Vendor & Services Providers\nRelationship Group Objectives\n\nA. To make it possible for GLEIF to understand market and product\nrequirements of the LEI data delivered by GLEIF.\n\nB. To make it possible for the GLEIF Vendor & Services Providers Relationship\nGroup to express their views on GLEIF's existing LEIl services or the\ndevelopments of LEI services and to stipulate the development of\nadditional LEI services.\n\nC. To have an open platform that facilitates communication between GLEIF\nand Vendors and Services providers via representative organizations.\n\nD. To have an efficient means of communicating updates to the Common\nData File Format and other GLEIS standards.\n\nE. To exchange information and to share views on existing or upcoming\ninitiatives in the public or private sector.\n\nIl GLEIF Vendor & Services Providers\nRelationship Group\nGLEIF Vendor & Services Providers Relationship Group Charter Page 2 of 5\n@ GLEIF unrestricted. Author: GLEIF\n","contentLength":1724,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:18:16.035Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/gleif-engagement/gleif-stakeholder-groups/gleif-vendor-relationship-group/2022-09-06_gleif-vendor-services-relationship-group-charter_v1.4.pdf","content":"The Vendor & Services Providers Relationship Group should be composed of\nrepresentative organizations of data and technology vendors and service\nproviders providing, or advising on the LEl data to their customers in their\nproducts and services. Such representative organizations will usually own or\nsupport a significant capability in data and data distribution that is relevant to\nthe GLEIF mission.\n\nThe initial GLEIF Vendor & Services Providers Relationship Group will have up to 2\nrepresentatives of the above organizations. GLEIF is represented by the CEO and\nthe Head of Business Operations.\n\nThe GLEIF, the members and their representatives have no intention to start a\nbusiness cooperation of any kind by participating in the GLEIF Vendor and Service\nProviders Relationship Group.\n\nParticipating in the GLEIF Vendor and Service Providers Relationship Group\ndoesn’t prevent any member to start a business relationship with another current\nor future member or GLEIF.\n\nIf an organization or representative does not attend four consecutive meetings,\nGLEIF reserves the right to check to see if the organization/ representative\ncontinues to have an interest in participating in the Group meetings. Based on\nthe response, GLEIF may remove the organization/ representative from the\nGLEIF Vendor & Services Providers Relationship Group and its name and logo\nfrom GLEIF's website.\n\nA member can leave the GLEIF Vendor and Service Providers Relationship Group\nby simple notice to the chair.\n\nIV Anti-Trust Statement\n\nParticipation in the GLEIF Vendor and Service Providers Relationship Group\nbrings companies together that compete with each other. The competition is\nboth horizontal and vertical. It is the GLEIF's Policy that all its actions are carried\nout in full compliance with applicable anti-trust legislation.\n\nAccordingly, it is necessary to avoid discussions of sensitive competitive topics\nand especially important to avoid recommendations with respect to such\nsubjects. Agreements e.g., to fix prices or fees or to allocate markets are\nautomatically illegal under the anti-trust laws. It does not matter what the\nreason for the agreement might be.\n\nGLEIF Vendor & Services Providers Relationship Group Charter Page 3 of 5\n\n@ GLEIF unrestricted. Author: GLEIF\n","contentLength":2269,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:18:16.035Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/gleif-engagement/gleif-stakeholder-groups/gleif-vendor-relationship-group/2022-09-06_gleif-vendor-services-relationship-group-charter_v1.4.pdf","content":"An anti-trust violation does not require proof of a formal agreement. A discussion\nof a sensitive topic such as fees, followed by parallel action by those involved in\nor present at the discussion is enough to show a price fixing conspiracy.\nViolations of the anti-trust laws can result in injunctions, treble damage\njudgments, heavy fines, and even imprisonment.\n\nTherefore, GLEIF and participants of the GLEIF Vendor and Service Providers\nRelationship Group must always remmember the purpose of the stakeholder group\nis support the implementation and use of the LEl. However, because GLEIF's\nactivity almost always involves the cooperation of competitors, great care must\nbe taken to assure compliance with the anti-trust laws. This means:\nParticipation must be voluntary, and failure to participate shall not be used to\npenalize any company.\n\nThere shall be no discussion of prices, allocation of customers, boycotts, refusals\nto deal, or market share.\n\nIf any participant believes the group is drifting toward impermissible discussion,\nthe topic shall be tabled until the opinion of counsel can be obtained.\n\nMeetings shall be governed by an agenda prepared in advance.\n\nTests or data collection shall be governed by protocols developed in consultation\nwith and monitored by counsel.\n\nThe recommendations coming out of the GLEIF Vendor and Service Providers\nRelationship Group are just that. Individual companies remain free to make\nindependent, competitive decisions.\n\nAny standards developed must (i) be set on a non-discriminatory basis and (ii)\nhave to be objectively necessary to foster the adoption of the LEI.\n\nV Meetings\n\nThe meetings of the GLEIF Vendor and Service Providers Relationship Group may\ntake place by conference call or by an in-person meeting. An in-person meeting\nmight take place once a year at a place and a day where already other meetings\nare planned to avoid travel costs for the members of the GLEIF Vendor and\nService Providers Relationship Group. Members of the Vendor and Service\nProviders Relationship Group may choose to participate in project initiatives and\nworkshops made available by GLEIF.\n\nGLEIF Vendor and Service Providers Relationship Group’s meetings might be\nrecorded solely for the purpose of allowing people who were not present to\n\nGLEIF Vendor & Services Providers Relationship Group Charter Page 4 of 5\n\n@ GLEIF unrestricted. Author: GLEIF\n","contentLength":2393,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:18:16.035Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/gleif-engagement/gleif-stakeholder-groups/gleif-vendor-relationship-group/2022-09-06_gleif-vendor-services-relationship-group-charter_v1.4.pdf","content":"watch the recording. The recording will only be shared with members of this\nGroup.\n\nThe GLEIF Vendor and Service Providers Relationship Group is co-chaired by\nStuart Clark, an independent industry representative, and the GLEIF CEO. The\nCo-Chairs will serve the GLEIF Vendor and Service Providers Relationship Group\nfor the first period of two years.\n\nGLEIF will support the two co-chairs with secretarial services.\n\nEvery member can make suggestions for agenda items in writing to the chair. The\nco-chairs agree on the agenda of the meetings.\n\nVI Communication\n\nGLEIF has the duty to be transparent (Article 6 of the GLEIF Statutes).\n\nAny press or social media work of the GLEIF Vendor and Service Providers\nRelationship Group or of members or GLEIF in relation to the GLEIF Vendor and\nService Providers Relationship Group must be explicitly agreed by GLEIF and the\nmembers of the GLEIF Vendor and Service Providers Relationship Group.\n\nThe members of the GLEIF Vendor and Service Providers Relationship Group\nagree to share their email addresses with each other. GLEIF may setup and\nmanage a mailing list accordingly.\n\nVIl Costs\n\nEvery member of the GLEIF Vendor and Service Providers Relationship Group will\nbear its own costs.\n\nGLEIF Vendor & Services Providers Relationship Group Charter Page 5 of 5\n\n@ GLEIF unrestricted. Author: GLEIF\n","contentLength":1341,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:18:16.035Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/gleif-engagement/gleif-stakeholder-groups/gleif-gifi-relationship-group/2018-11-05_gleif_gifi-relationship-group-charter_v1.pdf","content":"@’ Protecting digital trust.\nGLEIF GIFI Relationship\nGroup Charter\n","contentLength":67,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:18:26.747Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/gleif-engagement/gleif-stakeholder-groups/gleif-gifi-relationship-group/2018-11-05_gleif_gifi-relationship-group-charter_v1.pdf","content":"| Introduction\n\nThe Global Legal Entity Identifier Foundation (GLEIF) was established by the Financial Stability Board\n(FSB) as a not-for-profit organization to develop and maintain the Legal Entity Identifier (LEl) as a\nbroad public good for the benefit of the users of the public and the private sector. Find more about\ngovernance structure on www.gleif.org.\n\nGLEIF is subject to the oversight of the LEI Regulatory Oversight Committee (ROC), with about 60\npublic authorities from over 40 jurisdictions. The LEI ROC references the provisions in the GLEIF\nStatutes for its oversight duties.\n\nGLEIF delivers, under open data terms of use, high quality and free-of-charge business card\ninformation about legal entities.\n\nIl GLEIF GIFI Relationship Group Objectives\n\nTo have an open platform that facilitates communication and research initiatives between GLEIF and\na variety of financial institutions, including asset managers, global banks, insurers, and reinsurers.\n\nTo make it possible for the GLEIF GIFI Relationship Group members to express their views on GLEIF's\nexisting LEI services, or the developments of LEI services and to stipulate the development of\nadditional LEI services.\n\nTo jointly promote the LEIl and related use cases, especially through participating in pilot projects.\n\nTo make it possible for GLEIF to understand the requirements of financial institution users of LEI\n\ndata.\n\nTo exchange information and to share views on existing or upcoming initiatives in the public or\nprivate sector.\n\nTo have an efficient means of communicating updates to the Common Data File Formats and other\nGlobal Legal Entity Identifier System (GLEIS) standards.\n\nIIl GLEIF GIFI Relationship Group\n\nThe GLEIF GIFI Relationship Group is composed of representatives of large banks, global asset\nmanagement firms, insurance companies or other financial institutions who use, or plan to use, the\nLEI data of their customers and business partners in their transactions, products or services.\n\nThe initial GLEIF GIFI Relationship Group will have representatives of large financial institutions. GLEIF\nis represented by the CEO and the Head of Business Operations.\n\nA member can leave the GLEIF GIFI Relationship Group by simple notice to the chair.\n\nGLEIF, the members and their representatives have no intention to start a business cooperation of\nany kind by participating in the GLEIF GIFI Relationship Group.\n\nParticipating in the GLEIF GIFI Relationship Group doesn’t prevent any member to start a business\nrelationship with another current or future member or GLEIF.\n\n! www.leiroc.org\n\nGLEIF GIFI Relationship Group Charter Page 2 of 4\nGLEIF GLEIF unrestricted. Author: GLEIF Version 1.0\n2018-11-05-GLEIF-GIFI-RELATIONSHIP-GROUP-CHARTER-V1.0.docx 31 October 2018\n","contentLength":2763,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:18:26.747Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/gleif-engagement/gleif-stakeholder-groups/gleif-gifi-relationship-group/2018-11-05_gleif_gifi-relationship-group-charter_v1.pdf","content":"IV Anti-Trust Statement\n\nParticipation in the GLEIF GIFI Relationship Group brings companies together that compete with each\nother. The competition is both horizontal and vertical. It is the GLEIF’s Policy that all of its actions are\ncarried out in full compliance with applicable anti-trust legislation.\n\nAccordingly, it is necessary to avoid discussions of sensitive competitive topics and especially\nimportant to avoid recommendations with respect to such subjects. Agreements e.g. to fix prices or\nfees or to allocate markets are automatically illegal under the anti-trust laws. It does not matter what\nthe reason for the agreement might be.\n\nAn anti-trust violation does not require proof of a formal agreement. A discussion of a sensitive topic\nsuch as fees, followed by parallel action by those involved in or present at the discussion is enough to\nshow a price fixing conspiracy.\n\nViolations of the anti-trust laws can result in injunctions, treble damage judgments, heavy fines, and\neven imprisonment.\n\nTherefore, GLEIF and participants of the GLEIF GIFI Relationship Group must always remember the\npurpose of the Relationship Group is to support the implementation and use of the LEl. However,\nbecause GLEIF's activity almost always involves the cooperation of competitors, great care must be\ntaken to assure compliance with the anti-trust laws. This means:\n\nParticipation must be voluntary, and failure to participate shall not be used to penalize any company.\nThere shall be no discussion of prices, allocation of customers, boycotts, refusals to deal, or market\nshare.\n\nIf any participant believes the group is drifting toward impermissible discussion, the topic shall be\ntabled until the opinion of counsel can be obtained.\n\nMeetings shall be governed by an agenda prepared in advance, and recorded by minutes prepared\npromptly after the meeting. Agendas, where appropriate, and minutes are to be reviewed by counsel\nbefore they are circulated.\n\nTests or data collection shall be governed by protocols developed in consultation with and monitored\nby counsel.\n\nThe recommendations coming out of the GLEIF GIFI Relationship Group are just that. Individual\ncompanies remain free to make independent, competitive decisions.\n\nAny standards developed must (i) be set on a non-discriminatory basis and (ii) have to be objectively\nnecessary to foster the adoption of the LEI.\n\nGLEIF GIFI Relationship Group Charter Page 3 of 4\nGLEIF GLEIF unrestricted. Author: GLEIF Version 1.0\n2018-11-05-GLEIF-GIFI-RELATIONSHIP-GROUP-CHARTER-V1.0.docx 31 October 2018\n","contentLength":2560,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:18:26.747Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/gleif-engagement/gleif-stakeholder-groups/gleif-gifi-relationship-group/2018-11-05_gleif_gifi-relationship-group-charter_v1.pdf","content":"V Meetings\n\nThe meetings of the GLEIF GIFI Relationship Group may take place by conference call or by an in-\nperson meeting. An in-person meeting will take place at least once a year at a place and a day where\nalready other meetings are planned so as to avoid travel costs for the members of the GLEIF GIFI\nRelationship Group. Members of the GLEIF GIFI Relationship Group may choose to participate in\nproject initiatives and workshops made available by GLEIF.\n\nThe GLEIF GIFI Relationship Group is co-chaired by Eleanor Hsu, Director, Data & Reporting, at the\nInternational Swaps and Derivatives Association, Inc. (ISDA) , and the GLEIF CEO. The Co-Chairs will\nserve the GLEIF GIFI Relationship Group for the first period of two years.\n\nGLEIF will support the two co-chairs with secretarial services.\n\nEvery member can make suggestions for agenda items in writing to the chair. The co-chairs agree on\nthe agenda of the meetings.\n\nEach meeting will be minuted. The minutes are shared with the members of the GLEIF GIFI\nRelationship Group, the LEI ROC and the GLEIF’s Board of Directors. They will not be published on\nGLEIF's website.\n\nVI Communication\n\nGLEIF has the duty to be transparent (Article 6 of the GLEIF Statutes).\n\nAny press work of the GLEIF GIFI Relationship Group or of members or GLEIF in relation to the GLEIF\nGIFI Relationship Group must be explicitly agreed by the members of the GLEIF GIFI Relationship\nGroup.\n\nThe members of the GLEIF GIFI Relationship Group agree to share their email addresses with each\nother. GLEIF may setup and manage a mailing list accordingly.\n\nVIl Costs\n\nEvery member of the GLEIF GIFI Relationship Group will bear its own costs.\n\n2Since 1985, ISDA has worked to make the global derivatives markets safer and more efficient. Today, ISDA has more than 900 member\ninstitutions from 70 countries. These members comprise a broad range of derivatives market participants, including corporations,\ninvestment managers, government and supranational entities, insurance companies, energy and commodities firms, and international and\nregional banks. In addition to market participants, members also include key components of the derivatives market infrastructure, such as\nexchanges, intermediaries, clearing houses and repositories, as well as law firms, accounting firms and other service providers. Information\nabout ISDA and its activities\n\nGLEIF GIFI Relationship Group Charter Page 4 of 4\nGLEIF GLEIF unrestricted. Author: GLEIF Version 1.0\n2018-11-05-GLEIF-GIFI-RELATIONSHIP-GROUP-CHARTER-V1.0.docx 31 October 2018\n","contentLength":2555,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:18:26.747Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/regulatory-oversight-committee-roc/roc_20201001-1.pdf","content":"Charter of the Regulatory Oversight Committee\nFor the\nGlobal Legal Entity Identifier System\nand\nGovernance of Certain Other Global Data Identifiers and Elements\n\nHaving regard to:\n\n(1) the call of the Heads of State and Government of the Group of Twenty on the Financial\nStability Board (FSB) to take the lead in helping coordinate work among the regulatory\ncommunity to prepare recommendations for the appropriate governance framework,\nrepresenting the public interest, for a global Legal Entity Identifier (LEI) (Cannes\nSummit, November 2011, “Declaration — Building Our Common Future: Renewed\nCollective Action for the Benefit of All”); and,\n\n(2) the endorsement by the Heads of State and Government of the Group of Twenty of the\nFSB recommendations regarding the framework for development of a Global LEI System\nfor parties to financial transactions, with a global governance framework representing the\npublic interest (Los Cabos Summit, June 2012);\n\nRecognizing the need to develop and maintain for the broad public good a Global LEI System\nand harmonized financial data identifiers and other elements for derivatives and other\nreporting to regulators that are to be used: (a) by authorities of any jurisdiction or financial\nsector to, assess systemic risk and maintain financial stability, conduct market surveillance\nand enforcement, supervise market participants, conduct resolution activities, prepare high\nquality financial data and to undertake other official functions; and (b) by the private sector\nto support improved risk management, increased operational efficiency, more accurate\ncalculation of exposures, and other needs.\n\nWe, the Finance Ministers and Central Bank Governors of the Group of Twenty, and the FSB\n\nhave set forth in November 2012 this Charter for the Regulatory Oversight Committee (ROC)\n\nof the Global Legal Identifier System. The Global LEI System is composed of the ROC\ntogether with an operational component, consisting of the LEI foundation (or equivalent legal\nform) operating the Central Operating Unit (LEI COU), and the federated Local Operating\n\nUnits (LOUs) providing registration and other services; and,\n\nWe, the current Members of the ROC, having consulted with the FSB, the Committee on\n\nPayments and Market Infrastructures (CPMI), and the International Organization for\n\nSecurities Commissions (IOSCO), and recognizing the efficiencies and economies of scale\n\nin governing Certain Other Global Data Identifiers and Elements relating to financial\n\ntransaction and product identification, and harmonized OTC derivatives data reporting, have\nset forth amendments in October 2020 to the LEI Charter to include the Certain Other Global\n\nData Identifiers and Elements.\n\n1\n","contentLength":2715,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:19:28.137Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/regulatory-oversight-committee-roc/roc_20201001-1.pdf","content":"1. Mission\n\nThe mission of the ROC is to uphold the governance principles of and to oversee the Global\n\nLEI System, Unique Transaction Identifier (UTI), Unique Product Identifier (UPI), and\n\nCritical Data Elements (CDE) (collectively, the “LEI and Certain Other Global Data\n\nIdentifiers and Elements”),\n\nin the broad public interest, in accordance with:\n\na) the Global LEI System High Level Principles and FSB recommendations, as endorsed\nby the Heads of State and Government of the Group of Twenty (Los Cabos, June\n2012) (Annex A and B);\n\nb) the principles and functions set forth by the FSB and CPMI-IOSCO related to the\nUTI, UPI and the CDE, including the High Level Principles noted by the\naforementioned organizations applying to the UTI, UPI, and CDE (Annex C);\n\nC) any additional principles adopted by this ROC; and\n\nd) any amendment to the provisions of this Charter.\n\nIn furtherance of this mission, the ROC is to take appropriate action to protect the public\n\ninterest through regulatory oversight of the LEI and Certain Other Global Data Identifiers\n\nand Elements.\n\n2. Objectives of the ROC\n\nThe primary objective of the ROC is to oversee the Global LEI System and Certain Other\n\nGlobal Data Identifiers and Elements in accordance with the High Level Principles listed in\n\nAnnex A and C of this Charter. The ROC’s role is to promote the broad public interest by\n\nimproving the quality of data used in financial data reporting, improving the ability to\n\nmonitor financial risk, and lowering regulatory reporting costs through the harmonization of\nthese standards across jurisdictions.\n\na) With regard to the LEIL in protecting the broad public interest, the objectives of the\nROC are to ensure:\n\n(1) open and free access to publicly available data from the Global LEI System,\n\nincluding the following:\n\n1. data should be non-proprietary, with no bundling of services, or\nrestrictions on access, usage, or redistribution;\n\nil. all public data should be readily available on a continuous basis, easily\nand widely accessible using modern technology, and free of charge;\n\niii, confidential data should be safeguarded and with due regard for any\napplicable data protection legislation;\n\nv. data and operating processes should not be subject to any type of\nintellectual property restrictions, except those judged necessary by the\nROC for protecting the broad public interest;\n\n2\n","contentLength":2385,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:19:28.137Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/regulatory-oversight-committee-roc/roc_20201001-1.pdf","content":"d) The Executive Committee is to include representation by authorities from\njurisdictions that have mandated the use, or made specific steps to introduce\nmandatory use, of the UTI, UPI, and CDE in reporting derivative transactions to trade\nrepositories as described in Annex D to this Charter;\n\ne) The Executive Committee is to take forward the work of the ROC including decisions\non operational oversight issues, under specified delegated responsibilities and powers\nprovided by the Plenary.\n\nf) The Executive Committee may establish working groups and panels as needed to take\nforward the work of the Executive Committee.\n\ng) Relating to proposals or other work supporting the ROC's oversight of the UTI, UPI,\nand CDE, discussions during Executive Committee sessions are to follow regular\nprocedures so as to include all Executive Committee Members present. However,\nExecutive Committee decision-making on UTI, UPI, and CDE matters is to be made\nby those authorities from jurisdictions with a Regulatory Interest in the UTI, UPI, and\nCDE as set forth in Annex D to this Charter.\n\nh) In addition to its delegated responsibilities, the duties of the Executive Committee\ninclude the following:\n\n(1) providing regular information and recommendations to the Plenary to keep the\nPlenary fully engaged and capable of action;\n\n(2) informing the Plenary on the fulfilment of the delegated oversight\nresponsibilities provided to the Executive Committee;\n\n3) monitoring and guiding the progress of the ROC’s ongoing work;\n\n(4) preparing options for decision for matters reserved to the Plenary;\n\n(5) conducting ongoing oversight of the Global LEI System and Certain Other\nGlobal Data Identifiers and Elements to monitor adherence to the High Level\nPrinciples and other agreed principles, policies and standards to protect the\nbroad public interest. In furtherance of this mission the Executive Committee\nshall hear at least twice a year, and as deemed necessary by the Executive\nCommittee, a report from the Chair of the Board of Directors of the global LEI\nfoundation operating the LEI COU, and from the UPI service provider(s);\n\n(6) analysing and developing recommendations for principles, standards and\ngeneral policies for the Global LEI System, ensuring that they serve the broad\npublic interest, including, but not limited to:\n\n1. standards for LEI reference data and for other aspects of the Global\nLEI System’s operations;\n\nil. standards for participation of LOUs in the Global LEI System;\n\niii, cost-recovery principles, protocols, and procedures for the LET COU\nbudget formation;\n\nv. material contracts review to ensure that the objectives in section 2 a)\nare respected; and\n\n11\n","contentLength":2683,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:19:28.137Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/regulatory-oversight-committee-roc/roc_20201001-1.pdf","content":"V. standards for business continuity, disaster recovery, and automated\nsystem safeguards.\n\n(7) analysing and developing recommendations for principles, standards, and\ngeneral policies regarding Certain Other Global Data Identifiers and Elements,\nensuring that they serve the broad public interest, including, but not limited\nto:\n\n1. standards for UPI reference data and for other aspects of the UPI and\nUTI,\n\nil. standards, requirements and criteria on which to base the designation\nof UPI service providers;\n\niii, matters of concern common to multiple authorities regarding the use,\ninterpretation, and/or governance of the LEI and Certain Other Global\nData Identifiers and Elements;\n\nv. updates or changes to the UPI and UTI Technical Guidance as\nnecessary, considering the benefits and costs of such revisions.\n\n\\2 updates to the standards for CDE and the CDE Technical Guidance, as\nrequired and in light of evolution in market practices as well as\nauthorities’ needs and the purposes for which these standards and the\nCDE Technical Guidance were developed;\n\nVi. cost-recovery principles, protocols, and procedures for UPI service\nproviders;\n\nvil. material contracts review to ensure that the objectives in sections 2 b),\nc), and d) are respected; and\n\nviii. standards for business continuity, disaster recovery, and automated\nsystem safeguards.\n\n(8) reviewing and commissioning work from the Committee on Evaluation and\nStandards, the Committee on Derivative Identifiers and Data Elements, or\nother committees, working groups and panels and coordinating work across\nthose groups;\n\n9) requesting and receiving independent audits of the system for financial\ncontrol, best business practices and data quality standards;\n\n(10) performing on-site reviews of the LEI COU, subject to LEI COU security\nrequirements;\n\n(11) requesting on as needed basis information from the Directors of the global\nLEI foundation operating the LEI COU;\n\n(12) requesting on an as-needed basis information from the management or\ndirectors of the UPI service provider(s);\n\n(13) issuing guidance to the LEI COU or other parts of the Global LEI System to\nprotect the broad public interest as expressed in the relevant High Level\nPrinciples or in this Charter;\n\n12\n","contentLength":2239,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:19:28.137Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/regulatory-oversight-committee-roc/roc_20201001-1.pdf","content":"(14) issuing guidance to the UPI service provider(s) or other entities involved in\nCertain Other Global Data Identifiers and Elements, to protect the broad\npublic interest as expressed in the relevant High Level Principles or this\nCharter;\n\n(15) considering establishment of an appropriate framework for mediating or\nresolving disputes;\n\n(16) overseeing the work of the ROC Secretariat;\n\n(17) preparing the Plenary meetings, including making recommendations as\nappropriate in order to allow the Plenary to efficiently fulfil its mandate; and,\n\n(18) taking forward, after consultation and consistent with the directions of the\nPlenary, any other work necessary for the ROC to meet its mandate.\n\n12. Committee on Evaluation and Standards (CES)\n\nThe CES has the following responsibilities to support the regulatory oversight functions of\n\nthe ROC and the Executive Committee:\n\na) to evaluate the adequacy of existing standards and protocols for LEI in the light of the\nHigh Level Principles and other principles adopted by the ROC and that serve the broad\npublic interest;\n\nb) to propose revised or additional standards or protocols for LEI as necessary;\n\nc) torecommend to the Executive Committee the development of additional standards and\nprotocols for LEI or the modification of existing standards and protocols for LEI as\nnecessary; and\n\nd) to perform any other tasks and functions as requested by the Plenary or Executive\nCommittee.\n\nMembers of the CES do not necessarily need to be the individuals or organisations\n\nparticipating in the ROC.\n\nThe CES reports to the Executive Committee on a regular basis and to the Plenary when\n\nrequested.\n\n13. Committee on Derivative Identifiers and Data Elements (CDIDE)\n\nThe CDIDE has the following responsibilities to support the regulatory oversight functions of\n\nthe ROC and the Executive Committee:\n\na) to evaluate the adequacy of existing standards and protocols for UPI, UTI, and CDE in\nthe light of the High Level Principles and other principles adopted by the ROC and that\nserve the broad public interest;\n\nb) to propose revised or additional standards or protocols for UPI, UTI, and CDE as\nnecessary, considering the benefits and costs of such revisions;\n\nC) to recommend to the Executive Committee the development of additional standards,\nprotocols, or governance requirements for UPI, UTI, and CDE, or the modification of\n\n13\n","contentLength":2381,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:19:28.137Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/regulatory-oversight-committee-roc/roc_20201001-1.pdf","content":"existing standards, protocols, or governance requirements for UPI, UTI, and CDE, as\nnecessary,\n\nd) to disseminate the UPI, UTI and CDE Technical Guidance and any further technical\nguidance approved in accordance with this Charter to authorities, market participants,\nand the public, in order to better facilitate use and adoption of the UPI, UTI and CDE,\nwhere applicable;\n\ne) to monitor, and make recommendations regarding, implementation of the UPI, UTI,\nand CDE across jurisdictions, and identify any implementation issues that arise that\nmay hinder their adoption or a harmonized approach;\n\nf) to communicate and coordinate with external parties with an interest in the UPI, UTI,\nand CDE, and provide the ROC’s views to other entities involved in setting standards\nfor the UPL, UTI, and CDE; and,\n\ng) to perform any other tasks and functions as requested by the Plenary or Executive\nCommittee.\n\nMembership of the CDIDE is to be drawn primarily from authorities from jurisdictions that\n\nhave a Regulatory Interest in the UTI, UPL, and CDE, as described in Annex D to this Charter.\n\nIn nominating individuals to participate in the CDIDE, Members should prioritize those with\n\nexpertise in derivatives identifiers and data elements and the data aspects of derivative\n\nreporting requirements.\n\nThe CDIDE reports to the Executive Committee on a regular basis and to the Plenary when\n\nrequested.\n\n14. Chair\n\na) The Chair and the Vice Chair(s) are appointed by the Plenary from the Membership of\nthe Executive Committee for a term of 2 consecutive years extendable for a maximum\nof one year. To assure sufficient continuity and/or to avoid turnover of the ROC chairs\nduring the same year as turnover of global LEI foundation Board Chair, the ROC can\nextend the term of one Chair or Vice Chair for an additional year (for a total of 4 years).\n\nb) The Chair convenes and chairs the meetings of the Plenary and of the Executive\nCommittee.\n\nc) The Chair is the principal spokesperson for the ROC and represents the ROC\nexternally. The Chair should be informed of all significant matters that concern the\nROC.\n\nd) The Chair is to take all decisions and act as necessary to achieve the objectives of the\nROC, in accordance with directions given by the Plenary or the Executive Committee.\n\ne) The Chair 1s to act in the best interests of the ROC and ROC Membership.\n\nf) The Chair has a duty to seek as broad a consensus as possible.\n\ng) The Chair is to be supported by up to three Vice-Chair(s). The Chair and Vice-\nChair(s) are to be from different geographic regions. At least two of these Chairs are\nto represent authorities from jurisdictions where the LEI and Certain Other Global\n\n14\n","contentLength":2680,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:19:28.137Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/regulatory-oversight-committee-roc/roc_20201001-1.pdf","content":"Data Identifiers and Elements have been implemented or are planned to be\nimplemented. To ensure the appropriate geographical representation, the Chair should\nrotate at least once during the term.\n\n15. Secretariat\n\na) The Plenary is to appoint a Secretariat to support the ROC, taking account of a\nrecommendation from the Chair and the Executive Committee.\n\nb) The Secretariat is directed by the Chair of the ROC, on behalf of the Plenary and\nExecutive Committee.\n\nc) The duty of the Secretariat is to support the work of the ROC. The Secretariat does\nnot participate in any ROC decision making.\n\nd) The Secretariat is to maintain and publish a list of Plenary Members.\n\ne) The initial Secretariat is to be provided through the establishment of an agreement\nwith an existing public international financial institution that could help the ROC to\nmobilise and organise the necessary secretariat services during the first 3 years of\nformation.\n\nf) The funding arrangement that the ROC Plenary will establish pursuant to Article 16\nwill cover the costs of the Secretariat on an ongoing basis.\n\ng) The Plenary is to review all aspects of Secretariat arrangements every 3 years after\nthe formation of the ROC, or when the remit of ROC’s oversight changes.\n\n16. Funding of the ROC\n\nThe ROC will establish funding arrangements to cover its costs, with modalities to be\n\nestablished by the Plenary.\n\n17. Establishment\n\na) The ROC is to be formed following endorsement of this Charter by the Group of\nTwenty and the FSB, and there being:\n\n(D) at least eleven (11) authorities assenting to this Charter, including:\n\n(2) at least three (3) from each of three regional groupings: North America\n(including Mexico and the Caribbean); FEurope (including the\nCommonwealth of Independent States); and Asia (excluding the Middle\nEast); and\n\n3) at least two (2) from a regional group comprising Central and South America,\nAfrica, Oceania, and the Middle East; and\n\n4) of those authorities assenting within each of the four regions, at least two (2)\nderiving from different jurisdictions.\n\nb) Prior to the formation of the ROC and appointment of the Chair of the ROC by the\nPlenary, assent to the Charter is to be made by letter from eligible authorities to the\nChair of the FSB.\n\n15\n","contentLength":2262,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:19:28.137Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/regulatory-oversight-committee-roc/roc_20201001-1.pdf","content":"C) On formation of the ROC, and appointment of the Chair of the ROC by the Plenary,\nassent to the Charter is to be made by letter from eligible authorities to the Chair of\nthe ROC. Membership becomes active once the Chair has provided confirmation.\n\nd) A Member may terminate its Membership by letter to the Chair of the ROC.\n\ne) A request for Observer status is to be made by letter from eligible authorities to the\nChair of the FSB prior to the formation of the ROC, and thereafter by letter to the\nChair of the ROC.\n\n18. Access to information\n\nThe ROC is to have access to documents of the global LEI foundation operating the LEI\n\nCOU as well as those of the LEI COU, and access to documents of the UPI service\n\nprovider(s). The non-public information contained in these documents is to be treated as\n\nconfidential information by the Members of the ROC. Provisions regarding such access are\nto be reflected in by-laws of the LEI foundation.\n\n19. Confidentiality\n\nThe ROC Members are to treat all non-public information and documents, provided to or\n\nobtained by them under or in connection with Global LEI System and Certain Other Global\n\nData Identifiers and Elements oversight activities and this Charter, as confidential. The\n\nMembers are to ensure that confidential information provided to them in the context of the\n\nregulatory oversight arrangements is to be used only for the oversight of the Global LEI\n\nSystem and Certain Other Global Data Identifiers and Elements, and is not to be used by\n\nthem for any other purpose, including in their capacities as users of the Global LEI System\n\nand Certain Other Global Data Identifiers and Elements services, provided that the foregoing\ndoes not prejudice their responsibilities under national laws or regulatory requirements.\n\n20. Amendment Clause\n\nAmendment of any of the provisions of this Charter may be proposed by the Executive\n\nCommittee or Plenary and if adopted by the Plenary modifies this Charter. Such adoption is\n\nsubject to the decision making framework for the ROC, or by specific procedures to be\n\ndefined by the Plenary.\n\n21. Review Clause\n\nThe ROC may review the Charter as necessary, in an appropriate manner. The review may\n\ncover all aspects of the governance arrangements for the Global LEI System and Certain\n\nOther Global Data Identifiers and Elements. An initial review is to take place by no later than\n\nOctober 2017. By this date, the Plenary is to examine this Charter on the basis of a report\n\nfrom the Executive Committee and is to determine whether the mission and organization of\n\nthe ROC need to be reviewed. The charter shall be reviewed in the same manner every 5\n\nyears thereafter.\n\n16\n","contentLength":2675,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:19:28.137Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/regulatory-oversight-committee-roc/roc_20201001-1.pdf","content":"22. Legal Effect\nThis Charter does not create any legal rights or obligations or modify or supersede any\nnational or international laws or regulatory requirements in force in any applicable\njurisdiction, or applying to, any of the Members.\nNothing in this Charter is to require or to be deemed to require any of the Members to act in\na manner which amounts to or may amount to violation of any of the provisions of any such\nnational or international laws, legal frameworks, or regulatory requirements, or to prejudice\nor affect the exercise of any of their rights and discretions thereunder.\nBy endorsing or assenting to this Charter or becoming a Member of the ROC, no Member\nwaives any immunity from suit or privilege to which it may otherwise be entitled and no\nMember submits to the jurisdiction of any court or arbitral body that would not otherwise\nhave jurisdiction.\n23. Annexes\nThe Annexes to this Charter, are considered part of the Charter:\n\nAnnex A: Global LEI System High Level Principles.\n\nAnnex B: Recommendations for the development and implementation of the Global\n\nLEI System.\n\nAnnex C: UTI, UPI and CDE High Level Principles.\n\nAnnex D: Regulatory Interest and Decision-Making within the ROC Executive\n\nCommittee Regarding UTI, UPI, and CDE Matters.\n\n17\n","contentLength":1271,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:19:28.137Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/regulatory-oversight-committee-roc/roc_20201001-1.pdf","content":"Annex A: Global LEI System High Level Principles\n\n1. The Global LEI system should uniquely identify participants to financial transactions.\n\n2. The LEI system should meet the requirements of the global regulatory community for\naccurate, consistent and unique entity identification.\n\n3. The LEI system should be designed in a manner that provides benefits to financial market\nparticipants.\n\n4. Flexibility must be built into the global LEI system to provide the capability for the\nsystem to expand, evolve, and adapt to accommodate innovations in financial markets.\n\n5. The LEI system should not be “locked-in” with a particular service provider for any key\nsystem functions or processes. The principles of competition should be ensured on both\nglobal and local levels where appropriate.\n\n6. The global LEI system should support a high degree of federation and local\nimplementation under agreed and implemented common standards.\n\n7. The LEI system should meet evolving requirements of both the regulatory community\nand industry participants in terms of information content, scope of coverage, timeliness\nand availability.\n\n8. The LEI Regulatory Oversight Committee should have the responsibility of upholding\nthe governance principles and oversight of the global LEI system functioning to serve\nthe public interest. The Committee has the ultimate power and authority over the global\nLEI system.\n\n9. The mission, role and responsibilities of the ROC shall be specified by the global LEI\nRegulatory Oversight Committee Charter, which shall establish the Committee.\n\n10. Participation in the global LEI Regulatory Oversight Committee shall be open to all\nauthorities subscribing to the High Level Principles and to the objectives and\ncommitments in the Charter.\n\n11. The LEI Central Operating Unit should have the mission and role to ensure the\napplication of uniform global operational standards and protocols set by the ROC and\nact as the operational arm of the global LEI system. It shall be established as a foundation\nor legal equivalent.\n\n12. The LEI Central Operating Unit should have a balanced representation of industry\nparticipants from different geographic areas and sectors of economy. Its Board of\nDirectors should be selected from industry representatives, plus independent\nparticipants.\n\n13. The LEI system should allow the local provision by Local Operating Units of all LEI\nfunctions which the ROC determines are not required to be centralised.\n\n14. The LEI system should promote the provision of accurate LEI reference data at the local\nlevel from LEI registrants and ensure global uniqueness of the registrants.\n\n15. Any global universal intellectual property rights should belong to the global LEI system.\n\n18\n","contentLength":2727,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:19:28.137Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/regulatory-oversight-committee-roc/roc_20201001-1.pdf","content":"Annex B: Recommendations for the development and implementation of the Global LEI\nSystem\nRecommendation 1\nSETTING UP A GLOBAL LEI SYSTEM The FSB strongly supports the development and\nimplementation of a global LEI system that uniquely identifies participants to financial\ntransactions.\nRecommendation 2\nGLOBAL REGULATORY COMMUNITY REQUIREMENTS The LEI system should\nmeet the requirements of the global regulatory community (including supranational\norganisations). The potential benefits of the LEI include: to support authorities in fulfilling\ntheir mandates to assess systemic risk and maintain financial stability; conduct market\nsurveillance and enforcement; supervise market participants; conduct resolution activities;\nprepare high quality financial data and undertake other regulatory functions.\nRecommendation 3\nGLOBAL LEI SYSTEM GOVERNING DOCUMENTS Global LEI system High Level\nPrinciples set out the principles and commitments that specify and define the governance and\nstructure of the global LEI system. A global LEI Regulatory Oversight Committee Charter\nshould specify the mission, role and responsibilities of the Committee as well as the process\nfor its establishment. Support for the High Level Principles agreement and Charter will\nindicate a desire to participate in the global LEI system.\nRecommendation 4\nSUPPORT OF FINANCIAL MARKET PARTICIPANTS The LEI system should be\ndesigned in a manner that provides benefits to financial market participants.\nRecommendation 5\nSYSTEM FLEXIBILITY Flexibility must be built into the global LEI system to provide\nthe capability for the system to expand, evolve and adapt to accommodate innovations in\nfinancial markets. It must also allow the seamless introduction of new participants. To these\nends, critical software and other relevant elements must be defined and made publicly\navailable without any licensing, intellectual property or similar restrictions under open source\nprinciples. The LEI should be portable! within the global LEI system.\n\n1 In this context a portable LEI means that the code could be transferred from one LOU to another LOU. This may be\nnecessary, for example, in case of the LEI being obtained originally from a foreign LOU before a local LOU was\nestablished or if an entity changed its legal address or headquarters, etc.\n\n19\n","contentLength":2311,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:19:28.137Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/regulatory-oversight-committee-roc/roc_20201001-1.pdf","content":"Recommendation 6\nCOMPETITION AND ANTI-TRUST CONSIDERATIONS The LEI system should be\ndesigned to ensure that it is not “locked-in” with a particular service provider for any key\nsystem functions or processes, and that the principles of competition are ensured on both\nglobal and local levels where appropriate. The governance framework should provide\nsafeguards to ensure that competition principles and anti-trust considerations are upheld. The\nlocal implementation of the global LEI system should meet local anti-trust requirements.\nRecommendation 7\nFEDERATED NATURE OF THE LEI SYSTEM The global LEI system should support a\nhigh degree of federation and local implementation under agreed and implemented common\nstandards.\nRecommendation 8\nSCOPE OF COVERAGE Eligibility of ‘legal entities’ to apply for an LEI should be broadly\ndefined, in order to identify the legal entities relevant to any financial transaction. No more\nthan one LEI shall be assigned to any legal entity.\nRecommendation 9\nLEI REFERENCE DATA AT SYSTEM LAUNCH The official name of the legal entity,\nthe address of the headquarters of the legal entity, the address of legal formation, the date of\nthe first LEI assignment, the date of last update of the LEI the date of expiry, business\nregistry information (if applicable), alongside a 20 digit alphanumeric code should form the\nbasis for the global system at the launch of the global LEI initiative. For entities with a date\nof expiry, the reason for the expiry should be recorded, and, if applicable, the LEI of the\nentity or entities that acquired the expired entity.\nRecommendation 10\nREVIEW OF SCOPE OF COVERAGE AND REFERENCE DATA The Regulatory\nOversight Committee should undertake regular reviews of the scope and extent of coverage\nof the LEI to reflect emerging regulatory and market requirements for the LEI use according\nto an agreed schedule. The Regulatory Oversight Committee should undertake regular\nreviews of the LEI reference data according to a set schedule to monitor the required changes,\nadditions, retirements and modifications.\nRecommendation 11\nSTANDARDS FOR THE LEI SYSTEM The LEI system should meet, to the degree\npossible, evolving requirements of both the regulatory community and industry participants\nin terms of information content, scope, timeliness and availability. The Regulatory Oversight\nCommittee is responsible for the final determination for any standards for the LEI to be\nutilised in the global LEI system. When proposing areas for the development of new\nstandards, the Regulatory Oversight Committee should strongly consider utilising existing\nstandard setting organizations to develop such standards, provided that such organizations\n20\n","contentLength":2701,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:19:28.137Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/regulatory-oversight-committee-roc/roc_20201001-1.pdf","content":"V. restrictions should not be placed on a registrant on the use of its own\nLEL\n\n(2) open access to obtaining an LEIL including:\n\n1. by providing that any entities required, or eligible, to obtain an LEI are\nable to acquire one under open and non-discriminatory terms;\n\nil. by providing that fees, where and when imposed by the LEI COU, are\nset on a non-profit cost-recovery basis under the premise that the\noperational model of the LEI COU is efficient and avoids excessive\ncosts and, that where possible, a parallel arrangement holds for the\nLOUs;\n\niii, by providing that the intellectual property necessary for or associated\nwith the operation of the Global LEI System is held in a way that\nfacilitates achievement of the High Level Principles.\n\n3) that the Global LEI System meets broad public and private sector\nrequirements, including:\n\n1. ensuring the uniqueness, consistency, exclusivity, accuracy, reliability,\ntimeliness of access, portability, and persistence of the LEI codes and\nreference data;\n\nil. promoting the use and scope of the Global LEI System to expand the\ncollective benefit from widespread adoption; and\n\niii, allowing use of local languages and character sets in registration, as\nwell as allowing access to the Global LEI System in a common\nlanguage and character set.\n\nb) With regard to the UTI, in protecting the broad public interest, the objectives of the\n\nROC are to ensure:\n\n(1) unrestricted and free access to and use of the UTI for national or regional\nauthorities, trade repositories acting in their capacity as trade repositories, and\nall other stakeholders and those involved in the lifecycle of a derivative\ncontract;\n\n(2) unrestricted access to the UTI Data Standard on a cost-recovery basis;\n\n(3) that the UTI and UTI Data Standard adhere to the characteristics as defined in\nthe UTI Technical Guidance; and,\n\n4) use of and access to the UTI and UTI data standard is free of licensing\nrestrictions, not tied or bundled with any other service offered by a service\nprovider, and that intellectual property necessary for or associated with the\noperation of the UTI is held in a way that facilitates achievement of the\nrelevant High Level Principles.\n\nC) With regard to the UPI, in protecting the broad public interest, the objectives of the\n\nROC are to ensure:\n\n3\n","contentLength":2303,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:19:28.137Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/regulatory-oversight-committee-roc/roc_20201001-1.pdf","content":"incorporate the requirements for the standards as determined and communicated by the\nRegulatory Oversight Committee.\nRecommendation 12\nLEI REFERENCE DATA ON OWNERSHIP The FSB LEI Implementation Group should\nas soon as possible develop proposals for additional reference data on the direct and ultimate\nparent(s) of legal entities and relationship or ownership data more generally and to prepare\nrecommendations by the end of 2012. The group should work closely with private sector\nexperts in developing the proposals.\nRecommendation 13\nLEI OPERATIONAL AND HISTORICAL DATA The LEI system should maintain high\nquality records that retain relevant information on amendments (query, add, modify or delete\nof any data element) to data items as well as additional data to facilitate the surveillance and\ncontrol of the system by the COU where appropriate.\nRecommendation 14\nCENTRAL OPERATING UNIT The mission and role of the Central Operating Unit should\nbe to ensure the application of uniform global operational standards and protocols that deliver\nglobal uniqueness of the LEI, seamless access to the global LEI and to high quality reference\ndata for users with depth of access controlled by appropriate access rights, as well as\nprotocols and methods for how local systems can connect to the Central Operating Unit.\nRecommendation 15\nFORMATION OF THE CENTRAL OPERATING UNIT The LEI Implementation Group\nshould develop a detailed plan for the formation of the Central Operating Unit via the\nestablishment of a not-for-profit LEI foundation? by interested industry participants under\nthe oversight of the formed LEI Regulatory Oversight Committee. The foundation would rely\non industry participants, their expertise and knowledge to identify and develop the most\ntechnologically, financially and legally sound methods to implement the global LEI system\nin line with the standards and framework defined by the Regulatory Oversight Committee.\nRepresentatives from all geographic areas and industry sectors would be invited to participate\nin the preparatory work underpinning the formation of the LEI foundation as the Central\nOperating Unit in a manner defined by the Implementation Group.\nRecommendation 16\nBALANCED REPRESENTATION IN THE CENTRAL OPERATING UNIT The\nRegulatory Oversight Committee and LEI Implementation Group should ensure that the\nglobal LEI foundation takes account of the interests of financial and non-financial industry\nparticipants from different geographic areas and economic sectors.\n2 Or body of equivalent legal form.\n\n21\n","contentLength":2543,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:19:28.137Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/regulatory-oversight-committee-roc/roc_20201001-1.pdf","content":"Recommendation 17\nLOCAL OPERATING UNITS The LEI system should allow the local provision of all LEI\nfunctions which the Regulatory Oversight Committee determines do not need to be\ncentralised. The LEI system should enable the use of local languages, organisation types and\nrelationship structures as required. Procedures to integrate local systems into the global LEI\nsystem should be developed by the LEI Implementation Group in consultation with local\njurisdictions and potential Local Operating Units (when available) in a way and manner that\nmeets the global LEI system High Level Principles. The Central Operating Unit of the LEI\nsystem should be able to provide support to Local Operating Unit operations when necessary\naccording to criteria and requirements established by the Regulatory Oversight Committee\nand administered by the Central Operating Unit.\nRecommendation 18\nLEI DATA VALIDATION The LEI system should promote the provision of accurate LEI\nreference data at the local level from LEI registrants. Responsibility for the accuracy of\nreference data should rest with the LEI registrant, but Local Operating Units have\nresponsibility to exercise due diligence in guarding against errors, as consistent with\nRegulatory Oversight Committee standards, and to encourage necessary updating. The\nCentral Operating Unit has responsibility to check registrations for global uniqueness and to\ncoordinate reconciliation by Local Operating Units where necessary. Accuracy should be\nensured at the local level by the registered entities. Self-registration should be encouraged as\na best practice for the global LEI system.\nRecommendation 19\nLEI ISSUANCE WHEN NO LOCAL REGISTRAR AVAILABLE Whenever possible\nthe LEI registration should take place with the relevant Local Operating Unit. When a Local\nOperating Unit is not available, the Regulatory Oversight Committee and a local jurisdiction\n(when willing to engage) should agree on approaches for local entities to obtain LEIs. The\nImplementation Group should develop proposals for such mechanisms via: (1) establishing\na mechanism of obtaining LEIs through other Local Operating Units; (2) establishing a\nmechanism of obtaining LEIs from a registration facility in the Central Operating Unit; and\n(3) any other mechanisms that are appropriate.\nRecommendation 20\nSUSTAINABLE FUNDING The steady state funding of the global LEI system\nshould be self-sustainable and reliable. The funding system should be based on an efficient\nnon-profit cost-recovery model. The system should have two components: a local\ndiscretionary charge; and a common fee based on the number of registrations in each LOU\nto pay for the centralised operations in the Central Operating Unit, alongside any costs of\nimplementing and sustaining the governance framework. Fees should be sufficiently modest\nnot to act as a barrier to acquiring an LEL\n\n22\n","contentLength":2874,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:19:28.137Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/regulatory-oversight-committee-roc/roc_20201001-1.pdf","content":"Recommendation 21\nGLOBAL REGULATORY OVERSIGHT COMMITTEE CHARTER The governance\nframework of the global LEI system should be developed at the international level in an open\nand transparent manner that supports collective governance of the global system. A global\nLEI Regulatory Oversight Committee Charter should set out the formation and operations of\nthe Regulatory Oversight Committee. The global LEI Regulatory Oversight Committee\nCharter should be prepared by the FSB LEI Implementation Group for endorsement by the\nG-20 at the Finance Ministers and Central Bank Governors meeting in November 2012 or by\nthe FSB Plenary in October.\nRecommendation 22\nREGULATORY OVERSIGHT COMMITTEE A Regulatory Oversight Committee, as\nspecified in the Charter, should have the responsibility of upholding the governance\nprinciples and oversight of the global LEI system functioning to serve the public interest. The\nRegulatory Oversight Committee should be a body representing regulators and other\ngovernment or supranational entities engaged in regulating or monitoring the financial\nsystem or markets. Membership and decision making processes would be established by the\nCharter. Wherever possible, decisions would be reached by consensus.\nRecommendation 23\nPOWER AND AUTHORITY OF THE REGULATORY OVERSIGHT COMMITTEE\nThe Regulatory Oversight Committee has the ultimate power and authority over the global\nLEI system. Any power delegated to the Central Operating Unit, Local Operating Units and\nother entities can be reversed by the Regulatory Oversight Committee®. The Regulatory\nOversight Committee should establish a formal oversight plan to ensure that its directives to\nthe Central Operating Unit or other parts of the system are enforced and that the governance\nprinciples are upheld.\nRecommendation 24\nPARTICIPATION IN THE REGULATORY OVERSIGHT COMMITTEE To\nparticipate in the LEI Regulatory Oversight Committee, an authority should indicate support\nfor the global LEI High Level Principles and Charter for the Regulatory Oversight\nCommittee. Authorities may elect to be a full member of the Regulatory Oversight\nCommittee or an observer. The rights and responsibilities of members and observer status\nparticipants should be defined in the Charter.\nRecommendation 25\nLEVERAGING INFRASTRUCTURE OF AN INTERNATIONAL FINANCIAL\nORGANISATION In developing proposals to establish the Regulatory Oversight\nCommittee following agreement on the Charter, the Implementation Group should if possible\nand, subject to agreement, leverage on the existing infrastructure of an international financial\n3 Local authorities may also reserve rights to be engaged in decisions on local registration operations to the extent that\n\nthey act in accordance with the High-Level Principles of the LEI system.\n\n23\n","contentLength":2779,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:19:28.137Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/regulatory-oversight-committee-roc/roc_20201001-1.pdf","content":"organisation to initiate and stand-up the global LEI governance structure in a timely manner,\nutilising the experience of the international organisation in executing international initiatives.\nRecommendation 26\nGOVERNING DOCUMENTS FOR THE CENTRAL OPERATING UNIT Alongside\nthe development of the global Charter, the Implementation Group should develop legal\ndocuments governing the mandate provided by the Regulatory Oversight Committee to the\nCentral Operating Unit as well as other legal documents needed to specify the full governance\nframework for the global LEI system.\nRecommendation 27\nBOARD OF DIRECTORS OF THE CENTRAL OPERATING UNIT The Central\nOperating Unit shall have a Board of Directors. The Regulatory Oversight Committee has\nthe right to veto membership of the BOD, as well as to remove members. The ROC has the\nright to appoint independent members*.\nRecommendation 28\nFORMATION OF THE INITIAL BOARD OF DIRECTORS OF THE CENTRAL\nOPERATING UNIT The Central Operating Unit’s initial Board of Directors should be\nappointed by the Regulatory Oversight Committee, taking into account the need for\ngeographic and sectoral diversity. The Implementation Group should develop the fitness\ncriteria, size, role etc., for the BOD that should be reviewed in two years by the Regulatory\nOversight Committee.\nRecommendation 29\nPOWERS AND FUNCTIONS OF THE BOD OF THE CENTRAL OPERATING UNIT\nThe Board of Directors of the Central Operating Unit should be granted powers to direct the\nmanagement and operations of the Central Operating Unit in line with the overall standards\nset by the Regulatory Oversight Committee.\nRecommendation 30\nCONTINGENCY ARRANGEMENTS The Regulatory Oversight Committee is\nresponsible for setting and overseeing the application of business continuity standards for the\nglobal LEI system in line with best practices for key financial infrastructure. Rules and\nprocedures should be defined that the Central Operating Unit and Local Operating Units must\nfollow in case of insolvency, bankruptcy, etc., in order to ensure continuity of the global LEI\nsystem. A protocol should also be developed for maintenance of secure parallel copies of the\nLEIL in a manner that respects local laws.\n4 In this context independent members mean non-industry representatives.\n\n24\n","contentLength":2282,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:19:28.137Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/regulatory-oversight-committee-roc/roc_20201001-1.pdf","content":"Recommendation 31\nLEI INTELLECTUAL PROPERTY The LEI Implementation Group should conduct\nanalysis and provide recommendations on the treatment of the “LEI” intellectual property\n(such as the LEI code, software, reference data, any other LEI data, operational protocols,\netc.) according to the principles of open access and the nature of the LEI system as a public\ngood. The objective of this analysis shall be to ensure a regime that assures the availability\nin the public domain, without limit on use or redistribution, of LEI data, reference data, and\nprocesses. Any intellectual property rights should be held by, or licensed to the global LEI\nfoundation unless defined otherwise by the Regulatory Oversight Committee. Copyright\nshould be used to the extent possible to promote the free flow or combination of information\nfrom disparate sources.\nRecommendation 32\nFSB LEI IMPLEMENTATION GROUP Subject to the G-20 supporting further work to\nlaunch the global LEI, and entrusting implementation planning to the FSB, an FSB LEI\nImplementation Group (IG) should be established with a clear mandate to launch the global\nLEI system on a self- standing basis. The LEI Implementation Group should cease to exist\nupon formation of the Regulatory Oversight Committee which should be by 31 March 2013\nat the latest.\nRecommendation 33\nSTRUCTURE OF THE FSB LEI IMPLEMENTATION GROUP A time-limited FSB\nLEI Implementation Group of interested and willing experts (legal, IT, and other) from the\nglobal regulatory community that includes interested parties from the FSB LEI Expert Group\nshould be formed to take the global LEI initiative forward into the global implementation\nphase until the Regulatory Oversight Committee is established. The IG should be led by\nrepresentatives from different geographic areas to reflect the global nature of the LEI\ninitiative and will be supported by the FSB Secretariat. The IG should develop proposals for\nthe global LEI system stand-up as defined in the mandate below for review and endorsement\nby the FSB Plenary in October 2012 and, as appropriate, final review and endorsement by G-\n20 Finance Ministers and Central Bank Governors in November 2012.\nRecommendation 34\nRESPONSIBILITIES OF THE FSB LEI IMPLEMENTATION GROUP The mandate\nof the FSB LEI Implementation Group should be to prepare a draft global LEI Regulatory\nOversight Committee Charter, proposals for the establishment of the LEI Regulatory\nOversight Committee and related structures, develop all necessary legal documents for\nRegulatory Oversight Committee operations, develop necessary intellectual property\nagreements and contracts, conduct research and provide recommendations on LEI related\ninformation sharing arrangements; set up the process and any necessary legal documentation\nnecessary for establishment of the Central Operating Unit and its Board of Directors; and set\nup the process for establishment of the necessary standards, protocols, rules and procedures\nand organizational design for the Central Operating Unit.\n\n25\n","contentLength":3025,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:19:28.137Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/regulatory-oversight-committee-roc/roc_20201001-1.pdf","content":"Recommendation 35\nESTABLISHMENT OF THE GLOBAL LEI SYSTEM The global LEI system will be\nestablished by the endorsement of the high level Charter for the Regulatory Oversight\nCommittee by the G-20 Finance Ministers and Governors in November or by the FSB Plenary\nin October\n\n26\n","contentLength":276,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:19:28.137Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/regulatory-oversight-committee-roc/roc_20201001-1.pdf","content":"Annex C: UTI, UPI, and CDE High Level Principles\n\nUnique Transaction Identifier\n\n1. Public interest. Governance should be driven by public and regulatory interest.\n\n2. Lean. The UTI Governance Arrangements should not be unnecessarily complex or\ncostly.\n\n3. Change only as needed. Revisions to the UTI Governance Arrangements, UTI\nTechnical Guidance and UTI Data Standard should be managed on a need-only basis\nand consider benefits and costs of such revisions, to minimise impact on various\nstakeholders.\n\n4. Consultative change process. Changes to the UTI Governance Arrangements, UTI\nTechnical Guidance, and UTI Data Standard should allow for direct or indirect\ninvolvement of stakeholders and should be made after consultation where appropriate.\n\n5. Economic sustainability. The UTI Governance Arrangements should be consistent with\nthe need to help ensure the economic sustainability of the UTI over time.\n\n6. Open access. Access to and use of the UTI should be unrestricted and free of charge\nfor (1) Authorities; and (ii) TRs acting in their capacity as TRs; and (iii) all other\nstakeholders and those in the lifecycle of a derivative contract. Access to the UTI Data\nStandard should be unrestricted and obtained on a cost-recovery basis.\n\n7. Intellectual property. The UTI Data Standard shall not be subject to any intellectual\nproperty restriction, and any created intellectual property shall be treated in a manner\nconsistent with open source principles and as a public good. Consistent with this, use\nof and access to the UTI and UTI Data Standard shall be free of licensing restrictions.\n\n8. Conflicts of interest. Access to the UTI shall not be tied or bundled with any other\nservices offered by a Service Provider.\n\n9. Fit for purpose. UTI Governance Arrangements should be able to perform the relevant\nfunctions identified (including functions relating to Data Standard determination and\nimplementation) in a timely and efficient manner and should have reasonable access to\nthe necessary resources and information to do this. Governance of the UTI should\nmaintain the fitness of the UTI and UTI Technical Guidance for the needs of\nAuthorities.\n\n10. Consistency with other frameworks. Governance of the UTI should take into account\nother governance frameworks that impact other Data Elements, such as the Legal Entity\nIdentifier and the Unique Product Identifier.\n\nUnique Product Identifier\n\n1. Public interest. Governance should be driven by the public and regulatory interest.\n\n2. Lean. The UPI Governance Arrangements should not be unnecessarily complex or\ncostly.\n\n27\n","contentLength":2586,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:19:28.138Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/regulatory-oversight-committee-roc/roc_20201001-1.pdf","content":"3. Change only as needed. Revisions to the UPI Governance Arrangements, the UPI\nTechnical Guidance and UPI System should be managed on a need-only basis and\nconsider benefits and costs of such revisions to minimise impacts on various\nstakeholders.\n\n4. Consultative change process. Changes to the UPI Governance Arrangements, UPI\nTechnical Guidance, and UPI System (except for the day to day process of updating the\ndata held in the UPI Reference Data Library) should allow for direct or indirect\ninvolvement of stakeholders and should be made after public consultation where\nappropriate.\n\n5. Economic sustainability. The UPI Governance Arrangements should be consistent with\nthe need to help ensure the economic sustainability of the UPI System over time.\n\n6. Open access. Access to, and use of, UPI Codes and the UPI Data Standard should be\nunrestricted. Authorities should have access to, and use of, the UPI Reference Data\nLibrary that is similarly unrestricted. Entities with reporting obligations and TRs should\nhave access to, and use of, the UPI Reference Data Library in a manner that is sufficient\nto at least allow them to associate a specific OTC derivative product to its UPI Code in\na timely manner and facilitate the discharge of reporting obligations for OTC\nderivatives transactions.\n\n7. Cost. Any fees charged by the UPI Service Provider(s) should be based on cost-\nrecovery and should be allocated among stakeholders fairly. For Authorities, use of the\nUPI System should be free.\n\n8. Intellectual property. The UPI Data Standard should not be subject to any intellectual\nproperty restriction. Consistent with this, the use of any UPI Code should be free of\nlicensing restrictions. As to the UPI Reference Data Library, intellectual property\nrestrictions should be applied in a manner consistent with the rules applicable in a given\njurisdiction.\n\n9. Confflicts of interest. UPI service provider(s) should have policies and procedures that\nare reasonably designed to detect and effectively manage any potential conflict of\ninterest. Access to the UPI should not be tied or bundled with any other services offered\nby a UPI service provider.\n\n10. Fit for purpose. UPI Governance Arrangements should be able to perform the relevant\nfunctions identified in a timely and efficient manner and should have reasonable access\nto the necessary resources and information to do this. UPI Governance Arrangements\nshould maintain the fitness of the UPI System and UPI Technical Guidance for the\nneeds of Authorities.\n\n11. Consideration of other governance frameworks. Governance Frameworks for the UPI\nshould take into consideration other Governance Frameworks that impact other data\nelements, such as the LEI, the UTI, and other critical data elements for OTC derivatives.\n\n12. Operational viability and continuity of UPI service provider operations. Governance\nof the UPI System should be such that any UPI service provider should be required to\nhave adequate resources, legal authorities, and reasonable policies and procedures in\nplace designated or adequate to ensure operational viability, system security, and\n\n28\n","contentLength":3125,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:19:28.138Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/regulatory-oversight-committee-roc/roc_20201001-1.pdf","content":"business and system continuity and succession, so as to enable it to operate securely\nand effectively as a UPI service provider.\n\nCritical Data Elements\n\n1. Public interest. Revisions to CDE should be driven by public and regulatory interest.\nThe G20 summit in Pittsburgh agreed to improve transparency, mitigate systemic risk,\nand protect against market abuse by having all OTC derivatives transactions reported\nto TRs. Harmonised CDE and effective CDE Governance Arrangements will support\nthese goals by facilitating the consistent aggregation of OTC derivatives data reported\nto TRs at a global level.\n\n2. Lean. The CDE Governance Arrangements should not be unduly costly or complex.\n\n3. Consultative change process. Stakeholders should be appropriately involved, so that\nthey can provide insight into any new market development affecting the harmonisation\nof CDE and provide expertise on market practices as appropriate.\n\n4. Change only as needed. Change requests for CDE should be approved on a need-only\nbasis (e.g., Authorities’ needs or developments in market practices) and consider the\nbenefits and costs of such changes, to minimise any impact on relevant stakeholders.\n\n5. Open access. Access to and use of CDE (including definitions, formats and allowable\nvalues) should be unrestricted and available free of charge. In particular, the CDE\nTechnical Guidance and CDE Data Standards should remain open source and freely\navailable, to ensure a level playing field for all stakeholders and users of the OTC\nderivatives data.\n\n6. Intellectual property. Use of the CDE (including their definitions, formats and\nallowable values) should not be subject to any intellectual property restriction.\n\n7. Fit for purpose. Bodies to whom CDE governance functions are assigned should be\nable to perform their respective functions in a timely and efficient manner and should\nhave reasonable access to the necessary resources and information to do so. Further, the\nCDE Governance Arrangements should ensure that the CDE Technical Guidance and\nCDE Data Standards remain well adapted to Authorities’ needs.\n\n8. Compatibility. CDE Data Standards should be agnostic to existing communication\nprotocols and should be implementable in any existing syntax.\n\n9. Consideration of other arrangements. The CDE Governance Arrangements should take\ninto account arrangements for other data elements, such as the LEI, UTI and UPL\n\n29\n","contentLength":2415,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:19:28.138Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/regulatory-oversight-committee-roc/roc_20201001-1.pdf","content":"Annex D: Regulatory Interest and Decision-Making within the ROC Executive\nCommittee Regarding UTI, UPI, and CDE Matters\nWithin the Executive Committee, proposals or other work supporting the ROC’s oversight of\nthe Unique Product Identifier, Unique Transaction Identifier, and the Critical Data Elements\nare to be discussed before all members of the Executive Committee.\nExecutive Committee decisions made under Section 11 of the Charter and Article IV of the\nProcedural Guidelines regarding UPI, UTI and CDE matters are to be made by those members\nof the Executive Committee representing authorities from jurisdictions that have a Regulatory\nInterest in the UPI, UTI and CDE.\nThe criteria for whether such a jurisdiction has such a Regulatory Interest are:\n1) Legal requirements mandating the use of the global identifiers and data elements\nin derivative transactions (UTL, UPI and CDE) have been introduced within that\njurisdiction and are applicable within the existing regulatory framework for\nreporting to trade repositories;\nOR\n2) Specific steps have been taken within that jurisdiction in order to introduce the\nmandatory use of the global identifiers and data elements in derivative\ntransactions (UTI, UPI and CDE) within the relevant regulatory reporting\nframework. In particular, such steps could amount to, but are not limited to:\na. Public announcement of a proposal to introduce the UTI, UPI and CDE in\ndetermined and foreseeable future;\nb. Launch of a consultation process with the impacted market participants on\nthe intended introduction of the UTI, UPI, and CDE in determined and\nforeseeable future; or,\nc. Submission of a regulatory or legislative proposal to introduce the UTI, UPI,\nand CDE into the applicable framework of reporting to trade repositories to\na respective legislative body in charge of adopting such proposal.\n30\n","contentLength":1847,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:19:28.138Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/regulatory-oversight-committee-roc/roc_20201001-1.pdf","content":"(1) unrestricted access to, and use of, UPI Codes and UPI Data Standards; and\nthat such access should not be tied or bundled with any other services offered\nby a service provider;\n\n(2) unrestricted and free access to, and use of, the UPI Reference Data Library\nand of the UPI system itself for national or regional authorities;\n\n(3) that the UPI code and reference data adhere to the Technical Principles as\ndefined in the UPI Technical Guidance;\n\n4) access to, and use of, the UPI Reference Data Library for all entities with\nreporting obligations and trade repositories in a manner that is sufficient to\nallow them to associate a specific derivative product to its UPI Code in a\ntimely manner to facilitate the discharge of reporting obligations for derivative\ntransactions;\n\n(5) that any fees, when and where imposed by the UPI service provider(s), are set\non a cost-recovery basis and allocated fairly among stakeholders (excepting\nauthorities, for which use of the UPI system will be free);\n\n(6) that the UPI Data Standard is not subject to any intellectual property/licensing\nrestrictions and intellectual property necessary for or associated with the\noperation of the UPI Reference Data Library is held in a way that facilitates\nachievement of the relevant High Level Principles;\n\n(7) that the UPI service provider has policies and procedures that are reasonably\ndesigned to detect and effectively manage any potential conflict of interest,\nand that access to the UPI is not tied or bundled with any other services offered\nby the UPI service provider(s); and\n\n(8) the operational viability and continuity of UPI service provider operations in\naccordance with the relevant High-Level Principles.\n\nd) With regard to the CDE, in protecting the broad public interest, the objectives of the\n\nROC are to ensure:\n\n(1) unrestricted and free access to, and use of, CDE (including definitions,\nformats, and allowable values), and that the CDE Technical Guidance and the\nCDE Data Standards remain open source and freely available;\n\n(2) thatuse of the CDE (including their definitions, formats, and allowable values)\nshould not be subject to any intellectual property restrictions;\n\n3) that CDE Data Standards are agnostic to existing communication protocols\nand should be implementable in any existing syntax; and,\n\n4) compatibility of CDE data standards with the relevant High-Level Principles.\n\n3. Responsibilities and authorities of the ROC\nIn carrying out its missions and objectives, the ROC has the following responsibilities and\nauthorities:\n\n4\n","contentLength":2553,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:19:28.138Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/regulatory-oversight-committee-roc/roc_20201001-1.pdf","content":"a) to be the ultimate authority for oversight of the Global LEI System and Certain Other\nGlobal Data Identifiers and Elements, including guidance, standards, high level plans,\npolicies, and protocols, and having:\n\n(1) The capacity to review and approve all decisions relating to the governance\nand strategy of the global LEI foundation operating the LEI COU; and,\n\n(2) The capacity to review and approve all decisions relating to the governance\nand strategy concerning the UPI service provider(s) and the operating\nelements for Certain Other Global Data Identifiers and Elements.\n\nb) to facilitate the establishment of, and to designate the global LEI foundation (or body\nof equivalent legal form) as the legal entity that operates the LEI COU;\n\nC) to oversee standards and general policies for the LEI and Certain Other Global Data\nIdentifiers and Elements to ensure that they are in the broad public interest, including,\nbut not limited to:\n\n(1) standards for LEI, UPI reference data, and CDE data and for other aspects of\nthe operations of the LEI and Certain Other Global Data Identifiers and\nElements;\n\n(2) standards for participation of LOUs in the Global LEI System;\n\n3) standards for participation of the UPI service provider(s);\n\n4) cost-recovery principles, protocols, and procedures for the LEI COU budget\nformation;\n\n(5) cost-recovery principles, protocols, and procedures for the UPI service\nprovider(s);\n\n(6) material contracts review to ensure that the objectives in section 2 are\nrespected; and\n\n(7) standards for business continuity, disaster recovery and automated system\nsafeguards.\n\nd) on an ongoing basis, to evaluate the relevance of existing standards, propose new or\nto adapt existing standards under the global LEI and Certain Other Global Data\nIdentifiers and Elements systems, and coordinate and consult with relevant\nstakeholders, as required, so that the global LEI and Certain Other Global Data\nIdentifiers and Elements systems continue to reflect the governance objectives laid\nout in the High Level Principles, serve the broad public interest and reflect changes\nin financial markets or other relevant areas;\n\ne) to consult with relevant stakeholders (as identified by the Plenary or Executive\nCommittee) on major changes (also as identified by the Plenary or Executive\nCommittee) pertaining to the governance of Other Global Data Identifiers and\nElements systems, including the designation or de-designation of the UPI service\nprovider(s);\n\nf) to update the UPI and UTI Technical Guidance as necessary, considering the benefits\nand costs of such revisions, and after public consultation where appropriate.\n\n5\n","contentLength":2643,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:19:28.138Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/regulatory-oversight-committee-roc/roc_20201001-1.pdf","content":"g) to monitor the evolution of market practices and update the CDE Technical Guidance\nas necessary in response to evolving market practices, authorities’ needs, and the\npurposes for which the CDE Technical Guidance was developed;\n\nh) to recommend how the UTI, UPI and CDE Technical Guidance should be\nimplemented,;\n\n1) to monitor the implementation of the LEI and Certain Other Global Data Identifiers\nand Elements and identify implementation issues that may hinder their adoption;\n\ni) to provide that no entity involved in the global LEI and/or Certain Other Global Data\nIdentifiers and Elements systems exploits its relationship with the system in a way\nthat is contrary to the broad public interest;\n\nk) to request and receive independent audits of the Global LEI System for financial\ncontrol, best business practices, and data quality standards;\n\n1) to request and receive independent audits of the UPI service provider(s);\n\nm) to appoint the initial Board of Directors of the global LEI foundation operating the\nLEI COU, to review the appointment and continuance of Directors, and to request (or\ndirect, if consistent with the governing law of the global LEI foundation) removal of\nDirectors for cause, according to public-interest protection criteria established by the\nROC to be reflected in the governing documents of the global LEI foundation;\n\nn) to appoint, public or independent Directors of the global LEI foundation operating the\nLEI COU from outside of the regulatory community with special powers, determined\nby the ROC and to the extent permissible under the law governing the LEI foundation,\nwho as individuals are to act in the broad public interest, (pursuant to the criteria\nestablished by the ROC and reflected in the governing documents of the global LEI\nfoundation);\n\n0) to issue guidance to the LEI COU or other parts of the Global LEI System to protect\nthe broad public interest as expressed in the High Level Principles or in this Charter;\n\nP) to oversee the UPI service provider(s), their adherence to the UPI Technical Guidance\nand the UPI Data Standard, and their performance against their UPI functions in\naccordance to the relevant arrangements between the ROC and the UPI service\nprovider(s);\n\nqQ) to issue guidance to the UPI service provider(s) and entities involved with Certain\nOther Global Data Identifiers and Elements, in order to protect the broad public\ninterest as expressed in the relevant High Level Principles or in this Charter;\n\nr) to communicate and coordinate with other bodies responsible for the publication and\nmaintenance of the standards of Certain Other Global Data Identifiers and Elements\nas international data standards;\n\ns) to monitor the performance of the Global LEI System and Certain Other Global Data\nIdentifiers and Elements, through inspections, hearings, reports and other means,\nwhere applicable;\n\n6\n","contentLength":2869,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:19:28.138Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/regulatory-oversight-committee-roc/roc_20201001-1.pdf","content":"t) to promote a high level of transparency in the operation of the Global LEI System and\nin the operation and development of Certain Other Global Data Identifiers and\nElements;\n\nu) to establish or appoint such special advisory, technical, or professional committees,\nworking groups, or panels, as may be useful in carrying out the mission, objectives,\nand responsibilities of the ROC. The membership of such committees, working\ngroups, or panels may be composed of Members of the ROC, other persons,\n(including from both the regulatory community or private sector), or both;\n\nV) to consider establishment of an appropriate framework for mediating or resolving\ndisputes;\n\nW) to adopt, in addition to the provisions of this Charter, such rules or procedures as may\nbe necessary to carry out the mission, objectives and responsibilities of the ROC; and\n\nX) to undertake any such other functions and actions as may be necessary and permissible\nto carry out the mission, objectives, and responsibilities of the ROC.\n\n4. Members\n\na) The following are eligible to be a Member of the ROC:\n\n(1) any public sector authority and jurisdiction including regulatory and\nsupervisory authorities and central banks;\n\n(2) public international financial institutions;\n\n3) international public sector standard setting, regulatory, supervisory, and\ncentral bank bodies, and supranational authorities; and\n\n4) any other national or regional authority.\n\non condition that they are dedicated to working actively for the broad public interest\n\nin accordance with the Global LEI System High Level Principles and/or the High\n\nLevel Principles of Certain Other Global Data Identifiers and Elements, and to\n\nworking actively towards the objectives specified in this Charter. The public\n\ninternational financial institutions that are so dedicated participate as Members in\n\naccordance with their respective legal and policy frameworks.\n\nb) Membership criteria may be reviewed every 3 years, or earlier under circumstances\nwhere needs for review are identified, by the Plenary in the light of the ROC’s\nmission, objectives and responsibilities.\n\nc) Recognising the need to support effective decision making and thus to contain the\nnumber of decision making Members, jurisdictions are invited to ensure co-ordination\namong authorities that meet the eligibility criteria.\n\nd) In the event that the number of eligible members wishing to join the ROC reaches\nsuch a size that makes decision-making impractical, Plenary Members should review\nwhether new provisions are needed to limit Plenary Membership.\n\n7\n","contentLength":2573,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:19:28.138Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/regulatory-oversight-committee-roc/roc_20201001-1.pdf","content":"S. Commitments of Members\n\nAssent to the Charter means that a Member is to:\n\na) uphold the High-Level Principles and goals set forth in the Charter to protect the\nbroad public interest in relation to the Global LEI System and Certain Other Global\nData Identifiers and Elements;\n\nb) participate actively in the work of the ROC;\n\nC) support the introduction of the Global LEI System for official or international\nidentification purposes; and,\n\nd) support the introduction and use of Certain Other Global Data Identifiers and\nElements, recognizing that not all financial products and services are used or\npermitted in all financial markets.\n\n6. Observers\n\na) Public authorities and jurisdictions, public international financial institutions, and\ninternational public sector standard setting, regulatory, supervisory, and central bank\nbodies and supranational authorities, as defined in 4 a) above, that support the High\nLevel Principles and wish to be informed of the proceedings of the ROC, but do not\nwish to participate actively in the decision making and governance process may\nbecome Observers.\n\nb) An Observer may attend meetings of the Plenary and participate in the ROC in a\nmanner to be determined by the Plenary, Executive Committee, or any other groups,\ncommittees, working groups or panels that invite the Observer.\n\nAn Observer may not participate in the decision making of the Plenary or the Executive\n\nCommittee.\n\n7. Structure\n\nThe ROC is composed of the following:\n\na) the Plenary;\n\nb) the Executive Committee;\n\nC) the Committee on Evaluation and Standards;\n\nd) the Committee on Derivative Identifiers and Data Elements; and,\n\ne) other committees, working groups, or panels as provided for in Section 3 (u) above.\n\n8. Decision making\n\na) Decisions by the Plenary, Executive Committee, and any other groups, committees,\nor bodies established by the ROC should be taken by consensus where possible.\n\nb) Members of the ROC have the duty to work towards consensus.\n\nC) The Chair has the duty to seek as broad a consensus as possible.\n\n8\n","contentLength":2049,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:19:28.138Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/regulatory-oversight-committee-roc/roc_20201001-1.pdf","content":"d) Members who have stated an objection have the right to delay a decision for a fixed,\nshort period and ask the Chair to seek an alternative solution.\n\ne) Voting should only occur in exceptional circumstances where consensus cannot be\nreached using the procedures outlined above. For such an eventuality, the ROC is to\ndevelop voting procedures with a geographically balanced majority for adopting\ndecisions in the event that consensus cannot be reached for either or both the Plenary\nand the Executive Committee.\n\n9. Plenary Membership and Responsibilities\n\na) The Plenary consists of one designated representative of each Member of the ROC.\n\nb) The Plenary is the ultimate decision-making body of the ROC.\n\nC) The Plenary is presided over by the Chair of the ROC.\n\nd) The Plenary:\n\n(1) decides on the manner in which the Plenary conducts its affairs;\n\n(2) approves the work program of the ROC;\n\n3) oversees the standards and general policies for the Global LEI System and\nCertain Other Global Data Identifiers and Elements, to ensure that they protect\nthe broad public interest, taking account of the analysis and recommendations\nof the Executive Committee;\n\n(4) exercises oversight of the adherence of the Global LEI System and Certain\nOther Global Data Identifiers and Elements to the relevant High Level\nPrinciples and the goals specified in this Charter, and promotes transparency\nthroughout the system;\n\n(5) reviews membership criteria every 3 years or earlier where needs for review\nare identified, in the light of the ROC mission, objectives and responsibilities;\n\n(6) appoints the Chair, the Vice Chair(s), and the Executive Committee;\n\n(7) provides the Executive Committee with specific dedicated responsibilities and\npowers to take forward the work of the ROC and assigns responsibility for\ndecisions on operational oversight issues to the Executive Committee;\n\n8) facilitates the establishment of, and designates the global LEI foundation (or\nbody of equivalent legal form) as the legal entity that operates the LEI COU\nand terminates this designation;\n\n9) appoints the initial Board of Directors of the global LEI foundation operating\nthe LEI COU and reviews appointment and continuance of Directors, and\nthereafter requests removal of Directors, as specified in 3 (m) of this Charter,\ntaking due account of the recommendations of the Executive Committee;\n\n(10) appoints, public or independent Directors as foreseen in section 3 (n);\n\n9\n","contentLength":2455,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:19:28.138Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/regulatory-oversight-committee-roc/roc_20201001-1.pdf","content":"(11) hears at least twice a year, and as deemed necessary by the Plenary, a report\nfrom the Chair of the Board of Directors of the global LEI foundation\noperating the LEI COU;\n\n(12) designates, maintains the designation of, or de-designates UPI service\nprovider(s);\n\n(13) establishes the Committee on Evaluation and Standards and appoints its chair;\n\n(14) establishes the Committee for Derivative Identifiers and Data Elements and\nappoints its chair(s);\n\n(15) establishes other committees, working groups and panels, as necessary,\nincluding membership and responsibilities;\n\n(16) appoints the Secretariat;\n\n(17) reviews and approves any amendments to this Charter; and\n\n(18) decides on any other matter governing the business and affairs of the ROC.\n\n10. Plenary Representation and Attendance\n\na) All Members are entitled to attend and participate in the Plenary.\n\nb) The Chair of the ROC presides over the Plenary.\n\nC) The Plenary is expected to meet at least 2 times each year.\n\n11. Executive Committee\n\na) An Executive Committee is established and composed of an initial maximum of\ntwenty three (23) Members selected by, and from among the Plenary Membership.\nRegional Executive Committee Members are to be selected by and from the Plenary\nMembers for that region. Members representing global public international financial\ninstitutions and standard setting bodies are to be selected by the Plenary.\n\nb) Membership of the Executive Committee is to be balanced jurisdictionally and\nregionally. The initial composition of the Executive Committee is to consist of a\nmaximum of five (5) Members from at least 2 jurisdictions in each of the following\nregions: North America (including Mexico and the Caribbean); Europe (including the\nCommonwealth of Independent States); Asia (excluding the Middle East); and\nCentral and South America, Africa, Oceania, and the Middle East. In addition, up to\nthree (3) Members may be appointed to represent global public international financial\ninstitutions and standard setting bodies. The maximum size and composition of the\nExecutive Committee is to be reviewed every 3 years, in accordance with criteria to\nbe developed and approved by the Plenary. The Chair and the Vice Chair(s) are to be\nappointed from the Membership of the Executive Committee.\n\nC) Members of the Executive Committee are to be appointed for a maximum 3 year term,\nsubject to renewal. Initial appointments may include some shorter term appointments\nto facilitate rotation in each region upon the decision of a region.\n\n10\n","contentLength":2528,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:19:28.138Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/mou-between-gleif-and-roc/20150923-ROC-GLEIF-MOU-final-signed.pdf","content":"@d LE I e\nMEMORANDUM OF UNDERSTANDING BETWEEN THE REGULATORY\nOVERSIGHT COMMITTEE OF THE GLOBAL LEGAL ENTITY IDENTIFIER\nSYSTEM AND THE GLOBAL LEGAL ENTITY IDENTIFIER FOUNDATION\n\nPREAMBLE\n\nThe Regulatory Oversight Committee for the Global Legal Entity Identifier System (ROC), a\nCharter-based organization of authorities from multiple jurisdictions, and the Global Legal Entity\nIdentifier Foundation (GLEIF), a Swiss Foundation, together referred to as “Participants’:\nHaving regard to the Governance Principles of the Global Legal Entity Identifier System\n(GLEIS), which contemplate the establishment of the ROC to oversee the GLEIS in the broad\npublic interest and the designation by the ROC of the GLEIF, or a body of equivalent legal form,\nas the Central Operating Unit (COU) of the GLEIS and, if necessary, the termination by the ROC\nof such designation;\n\nHaving regard to the Statutes of the GLEIF, established with the purpose of acting as the\noperational arm of the GLEIS, in accordance with the Governance Principles of the GLEIS;\nRecognizing the need to memorialize the relationship between the ROC and the GLEIF, and the\nprocesses for implementing their respective responsibilities in the functioning of the GLEIS as\ncontemplated in the Governance Principles of the GLEIS and in the GLEIF Statutes;\n\nAffirming and supporting the independence of the GLEIF in overseeing operational aspects of\nthe GLEIS and of the ROC in overseeing the GLEIF and effecting the regulatory oversight of the\nGLEIS in the broad public interest to uphold the Governance Principles of the GLEIS;\n\nHave reached the following understanding:\n\nARTICLE I: DEFINITIONS\n\nFor purposes of this Memorandum of Understanding (MOU),\n\n1. The Governance Principles of the Global Legal Entity Identifier System (GLEIS),\nmeans the Global LEI System High Level Principles and recommendations of the\nFinancial Stability Board (FSB) contained in the 8 June 2012 FSB report, “A Global\nLegal Entity Identifier for Financial Markets,” endorsed by the Leaders of the G20 at\nLos Cabos, Mexico on 19 June 2012; the ROC Charter endorsed by the G20 on 5\nNovember 2012, as well as any amendments thereof;, and any additional principles or\nstandards adopted by the ROC.\n\n2. The Regulatory Oversight Committee (ROC) means the group of public authorities\n","contentLength":2308,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:19:58.239Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/mou-between-gleif-and-roc/20150923-ROC-GLEIF-MOU-final-signed.pdf","content":"2\nthat have, at any given point, assented to the Charter of the ROC.\n\n3. The Committee on Evaluation and Standards (CES) refers to the advisory technical\ncommittee of the ROC.\n\n4. The Global LEI Foundation (GLEIF) means the Swiss foundation established on or\nabout June 26, 2014, and founded by the Financial Stability Board, pursuant to the\nGLEIF Statutes.\n\n5. Observers refers to the representatives of the ROC appointed as ex officio Members of\nthe GLEIF Board with observer status and no voting rights as described in the GLEIF\nstatutes.\n\n6. Board meetings: references to Board meetings in this MOU include all forms of\nmeetings of the GLEIF Board envisaged in Art. 24 of the GLEIF Statutes, which\nprovides that such meetings shall be convened either physically or by any other means,\nsuch as conference calls, video conferences or “otherwise”, which is understood to\ninclude the other forms of decision making described in Art. 23 of the GLEIF Statutes,\nthrough circular letters, emails or any other method of communication. For these other\nforms of decision making, the date of the meeting is considered, in particular for the\ncomputation of notice periods, as the date by which votes or other forms of feedback\nshould be expressed.\n\n7. The Central Operating Unit (COU) refers to the body designated by the ROC to effect\noperational oversight of the GLEIS, to ensure the application within the GLEIS of\nuniform global operational standards and protocols set by the ROC, and to undertake\nother tasks as contemplated in the Governance Principles of the GLEIS. This MOU\nreflects the designation of the GLEIF as the COU (see clause 13).\n\n8. Local Operating Units (LOUs) are the utilities endorsed by the ROC as part of the\nInterim System defined hereunder, and by the COU thereafter, to provide LEI\nregistrations to registrants and other services as contemplated in the Governance\nPrinciples of the GLEIS. The expression “pre-LOUs” is used to specifically refer to the\nLOUs endorsed by the ROC in the Interim System.\n\n9. Legal Entity Identifier (LEI) means an entity identifier in the form of a reference code\nto uniquely identify legally distinct entities that engage in financial transactions and\nassociated reference data, as defined in the Governance Principles of the GLEIS.\n\n10. Global LEI System, or System (GLEIS): The Global LEI System is composed of the\nROC together with an operational component, consisting of the COU and LOUs.\n\n11. Interim System for the LEI: system under which the ROC has assumed certain tasks of\noperational oversight and coordination of the GLEIS, during the period before the\nGLEIF 1s designated as the COU and able to assume its functions.\n","contentLength":2678,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:19:58.239Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/mou-between-gleif-and-roc/20150923-ROC-GLEIF-MOU-final-signed.pdf","content":"11\nARTICLE XI: DISAGREEMENTS AND ESCALATION PROCEDURES\n\n40. The Board should respond within one month to a recommendation made by the ROC\nunder Art 31 of the GLEIF Statutes. The GLEIF Board Chair may request that the period\nto respond be extended by up to two weeks, unless the ROC Chair or a Vice Chairs raise\nexigent circumstances.\n\n41. Pursuant to Art. 31 of the GLEIF Statutes, whenever the Board does not entirely adopt a\nrecommendation delivered by the ROC, the results of the Board's decision and the\nreasonable grounds for such decision shall be made promptly and publicly available,\nunless, as discussed with the ROC Chairs, such publication violates confidentiality and\nprivacy criteria. To enable the ROC to determine the existence of a refusal by the GLEIF\nto adopt its recommendation, and give the opportunity to examine alternatives and avoid\nmere misunderstandings the Participants intend to follow the process described below.\n\n42. The GLEIF should provide in its response to the ROC an explanation for its position\nand/or an alternative proposal. After reviewing this explanation or alternative proposal,\nthe ROC may rescind or modify its recommendation. The deadlines in clause 40 apply\nto the modified recommendation.\n\n43. If a disagreement remains and, in the view of the Participants or their respective Chairs a\nresolution i1s necessary to the well-being of the GLEIS, the Chairs of the respective\nParticipants should seek to negotiate a compromise proposal that can be accepted by\neach body pursuant to their respective decision-making procedures.\n\n44 1f the process in clauses 42 and 43 is unsuccessful or impracticable, the ROC may, at its\ndiscretion, undertake alternatively or successively the following actions:\n\na. confirm its recommendation, so that it can be submitted again to the vote of the\nGLEIF Board according to Art. 31 of the GLEIF Statutes; the deadlines in clause\n40 apply;\n\nb. Publish its disagreement with the GLEIF and the reasons thereof and request the\napplication by the GLEIF of the publication foreseen in the last paragraph of Art.\n31 of the GLEIF statutes, including on the GLEIF website. The GLEIF would be\ngiven by the ROC prior notice of the ROC’s intention to publish its disagreement\nwith the GLEIF.\n\nARTICLE XII: APPOINTMENT AND REMOWAL OF BOARD MEMBERS\n\n45. Under Art. 15 paragraph 4 of the GLEIF Statutes, the FSB, as the Founder of the\n\nGLEIF, has the right to appoint or remove a Board Member after seeking a\n","contentLength":2470,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:19:58.239Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/mou-between-gleif-and-roc/20150923-ROC-GLEIF-MOU-final-signed.pdf","content":"12\n\nrecommendation from the ROC. The ROC foresees that any recommendation by the\nROC to the FSB to appoint or remove Board members would only be made after other\noptions are exhausted and would be motivated by serious circumstances, including, but\nnot limited to, the paralysis of the decision making process of the GLEIF Board, fit and\nproper issues affecting one or more Board members, or a functioning of the GLEIF\nseriously affecting the public interest or objectives set forth in the governance principles\nof the GLEIS referred to in Art. 3 and 4 of the GLEIF Statutes defining the purposes of\nthe GLEIF. However, the ROC’s expectations and examples above do not commit in\nany way the FSB, which is not a Participant in this MOU. The decision to appoint or\nremove a Board Member under Art. 15 paragraph 4 of the GLEIF Statutes belongs to the\nFSB, not to the ROC, and is foreseen as a last resort option subject to the FSB’s own due\ndiligence review. Such a possibility is not intended to affect the independent\nmanagement of the GLEIF by its Board.\n\nARTICLE XIII: TERMINATION OF THE DESIGNATION OF THE GLEIF AS THE\n\nCcou\n\n46. As foreseen in Article 8 of the ROC Charter, the ROC may terminate the designation of\nthe GLEIF as the body that operates the COU. The ROC foresees that this would only\nhappen for a very serious cause and where necessary in the public interest, including, but\nnot limited to, the need to change the architecture of the GLEIS to reach imperative\npublic policy objectives recognised at the highest political level in ROC member\njurisdictions, or to address obstacles affecting the effective operation or oversight of the\nGLEIS as intended in the Governance Principles of the GLEIS. Such a possibility is not\nintended to affect the independent management of the GLEIF by its Board.\n\n47. A decision to terminate the designation of the GLEIF would be taken by the ROC after\nseeking the views of the GLEIF and careful review, including giving notice in a letter\nsigned by the Chair of the ROC to the GLEIF Board Chair identifying the specific\nreasons for terminating the designation, together with an opportunity for the GLEIF to\npropose alternative solutions such as a change of the Chair and/or part of the Board\nMembers within a reasonable time set by the ROC of no less than 3 months absent\nexigent circumstances;\n\nA decision to terminate the designation of the GLEIF should take into consideration the\nparamount objective of preserving the use of the LEI and of the operation of the GLEIS;\nto that effect, the termination of the designation should not, absent exigent circumstances,\nbe expected to result in abandoning the use of LEIs but should involve changing or\ntransferring the operational governance of the GLEIF for the GLEIS with the aim of\navoiding undue market or regulatory disruption and protecting intellectual property rights\nthat are held for the public benefit, and taking into consideration, as appropriate,\n","contentLength":2955,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:19:58.239Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/mou-between-gleif-and-roc/20150923-ROC-GLEIF-MOU-final-signed.pdf","content":"13\nemployment and other agreements entered into by the GLEIF.\n\n48. The decision to terminate the designation takes effect one year after its adoption, or any\nlonger period of time decided by the ROC for the orderly transition of the functions of\nthe COU. However, a shorter period may apply in the circumstance where the GLEIF\nwould be unable to continue its activities as set forth in Art. 39 of the GLEIF Statutes.\n\nARTICLE XIV: INTELLECTUAL PROPERTY AND CONTRACTS\n\n49. As stated in the GLEIS High Level Principle 15 and the FSB Recommendation 31 that\nare part of the Governance Principles of the GLEIS, “Any global universal intellectual\nproperty rights should belong to the GLEIS” and “Any intellectual property rights\nshould be held by, or licensed to the GLEIF unless defined otherwise by the ROC”.\nArticle 8 of the GLEIF Statutes state that “Intellectual property rights should be held for\nthe public benefit and consistent with the attainment of the purposes of the Foundation\nas well as GLEIS principles”.\n\n50. Consistent with these provisions, as well as the representations and agreements made via\nthe endorsement process by the LOUs, the intellectual property rights of the GLEIS\nshould be held by the GLEIF in a way that ensures their assignability in the case of a\nnecessity, such as dissolution of the GLEIF as foreseen in Article 39 of the GLEIF\nStatutes.\n\n51. In entering into any contractual arrangements involving the intellectual property of the\nGLEIS and any other contractual arrangement material to the continuity of the GLEIS,\nthe GLEIF intends to include provisions that allow for the transferring of its roles, rights\nand responsibilities to a successor COU without the need for judicial intervention.\n\n52. In the case of a necessity, such as dissolution of the GLEIF , the GLEIF intends to\ntransfer to another public utility and tax exempt entity pursuing similar objectives, as\ndesignated by the ROC consistently with Art. 39 of the GLEIF Statutes , within a\ntimeframe specified by the ROC and without the need for judicial intervention:\n\n— any and all rights, interests and ownership in any intellectual property\n— any and all contractual or other rights, interests and responsibilities material to the\ncontinuity of the GLEIS.\nARTICLE XV: MISCELLANEOUS\n\n53. Any modifications or amendments to this MOU must be made in writing, signed by the\nthen-serving ROC Chair and GLEIF Board Chair, respectively, pursuant to the decision\nmaking processes of the ROC and GLEIF, respectively.\n","contentLength":2509,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:19:58.239Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/mou-between-gleif-and-roc/20150923-ROC-GLEIF-MOU-final-signed.pdf","content":"14\n54. This MOU is concluded for five years and is automatically extended for additional\nperiods of two years without limitation, unless both Participants decide to terminate it or\nto replace it with another MOU. Notwithstanding the above, this MOU expires in the\ncase of a necessity, such as dissolution of the GLEIF or a transfer of COU designation\nand functions takes effect.\n55. This MOU is a public document.\nSigned in two originals in Beijing on 23 September 2015\nMatthew Reed, Gerard Hartsink\nChairman Chairman of the Board\nLegal Entity Identifier Global Legal Entity Identifier Foundation\nRegulatory Oversight Committee\n","contentLength":628,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:19:58.239Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/mou-between-gleif-and-roc/20150923-ROC-GLEIF-MOU-final-signed.pdf","content":"15\nAnnex I\nSpecific preconditions for the termination of the interim system\nThe decision of the ROC to terminate the interim system is predicated on the satisfactory\nfulfillment of the following items:\n\n1. The drafting of a Master Agreement that will be executed by the GLEIF and the pre-\nLOUs containing provisions addressing the sustainable funding of the GLEIF, clear\ndeliverables by the LOUs and GLEIF and associated standards and metrics supporting\nhigh data quality within the GLEIS, an enforcement mechanism, and provisions designed\nto uphold the Governance Principles of the GLEIS (particularly those related to\nintellectual property);\n\n2. Establishment by the GLEIF of a pre-LOU on-boarding plan that provides for fair\ntreatment and objective on-boarding criteria for existing pre-LOUs that culminates in the\nexecution of the above-described Master Agreement by pre-LOUs in an orderly fashion;\n\n3. The GLEIF having defined and made public an endorsement process that provides for\nobjective criteria for the GLEIF to evaluate and recognize or endorse new candidate\nLOUs; and the GLEIF having hired at least 1 member of staff to carry out this task;\n\n4. The provision by the GLEIF of a (virtual or actual) lookup and download database for\nLEIs on a concatenated basis;\n\n5. Establishment by the GLEIF of web presence to carry out communications with users of\nthe GLEIS, LOUs and the public;\n\n6. The GLEIF having defined a process and hired at least 2 members of staff for monitoring\non an ongoing basis compliance by the LOUs with the governance principles of the\nGlobal Legal Entity Identifier System (GLEIS) and the operational norms defined in\nArticle IX relevant to them.\n","contentLength":1682,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:19:58.239Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/mou-between-gleif-and-roc/20150923-ROC-GLEIF-MOU-final-signed.pdf","content":"3\nARTICLE II: GENERAL PURPOSES\n\n12. This MOU describes the common understanding between the ROC and the GLEIF, of\nthe implementation of the Governance Principles of the GLEIS and GLEIF Statutes, in\nparticular the expected division of responsibilities for overseeing various parts of the\nGLEIS. This MOU creates no legal rights between, by, or against the Participants or any\nof their respective Members or officers or employees, is not legally binding, and is not\nsubject to judicial review or enforcement\n\n13. This MOU reflects the “Designation” by the ROC of the GLEIF as the Central\nOperating Unit of the Global LEI system. This Designation shall continue until a\ndecision by the ROC to terminate the Designation of the GLEIF as described in Article\nXIIT.\n\n14. This MOU describes the oversight of the GLEIS by the ROC and defines specific\naspects of the ROC’s relationship with the GLEIF, including appropriate communication\nchannels, notice, and resolution of disagreements. This MOU is intended to provide\nclarity on how the provisions of the GLEIF statutes on the oversight of the GLEIF by the\nROC will operate in practice, but is not meant to modify in any way the GLEIF Statutes\nand the Governance Principles of the Global Legal Entity Identifier System referred to\nin the GLEIF Statutes.\n\nARTICLE III: TERMINATION OF THE INTERIM SYSTEM\n\n15. The ROC and the GLEIF agree to terminate the Interim System and to implement the\ndivision of responsibilities between the ROC and the GLEIF contemplated by the\nGovernance Principles of the GLEIS and further specified in this MOU in a staged\nprocess, as defined below:\n\na. Before steps b, ¢ and d below can take place, conditions 4 and 5 in Annex 1\nshould have been fulfilled to the satisfaction of the ROC;\n\nb. Subject to GLEIF having hired at least 2 member of staff to support this task, the\nROC transfers to the GLEIF the definition of operational norms as defined in\nArticle IX,\n\nc. Subject to conditions 1, 2 and 6 described in Annex I being fulfilled to the\nsatisfaction of the ROC, the ROC transfers to the GLEIF responsibility for the\nongoing monitoring of LOUs’ compliance with the Governance Principles of the\nGLEIS, subject to the ROC’s continued oversight of the GLEIF and the GLEIS.\n","contentLength":2246,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:19:58.239Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/mou-between-gleif-and-roc/20150923-ROC-GLEIF-MOU-final-signed.pdf","content":"4\nThis transfer is effective for a given pre-LOU as of the date when the Master\nAgreement is effected between the GLEIF and this pre-LOU; pre-LOUs having\nsigned the Master Agreement become LOUs;\n\nd. Subject to condition 3 in Annex I [endorsement process and resources] being\nfulfilled to the satisfaction of the ROC, the ROC transfers to the GLEIF\nresponsibility for endorsing new candidate LOUs that wish to enter the GLEIS.\n\ne. The other provisions of this MOU apply immediately.\n\nSteps b, ¢, and d may take place concurrently or in a different order than the one indicated above,\ndepending on when their respective conditions are met.\nThe transfer or responsibilities under steps ¢ and d are without prejudice to the continuation of\nthe functions any ROC members may have towards LOUs under their domestic framework.\nARTICLE IV: OVERSIGHT OF THE GLEIF BY THE ROC\n16. The ROC will oversee the GLEIF in accordance with the Governance Principles of the\nGLEIS, the GLEIF Statutes and the laws governing Swiss foundations, as well as this\nMOU. The ROC and the GLEIF should consult the “Committee on Payments and\nMarket Infrastructures — CPMI) and the International Organization of Securities\nCommissions (IOSCO) Principles for Financial Market Infrastructures” for guidance\nwhen determining the policy standards for the operations of the GLEIF and when\noverseeing the GLEIS.\nARTICLE V: COMMUNICATIONS AND NOTICES\n17. Unless specified otherwise in this MOU, all official notices and communications between\nthe ROC and the GLEIF will be conducted respectively through:\n\n— a message by the Chair or a Vice Chair of the ROC to the Chair of the Board of the\nGLEIF and to any other person designated by the GLEIF Board Chair for that\npurpose;\n\n— a message by the GLEIF Board Chair to the Chair and Vice Chairs of the ROC and to\nthe ROC Secretariat and any other person designated by the ROC Chair or Vice\nChairs for that purpose.\n\n18. This Article applies in particular to:\n1. Notice of GLEIF Boards meetings and agendas (Art. 24 of the GLEIF Statutes);\n\nBoard agendas should clearly distinguish items for information and items for\n","contentLength":2124,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:19:58.239Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/mou-between-gleif-and-roc/20150923-ROC-GLEIF-MOU-final-signed.pdf","content":"5\ndecision; the text of any proposed decision should be included in the documentation\nreferred to in item vii;\n\nii. Pending and actual Board vacancies (Art. 31); this includes informing the ROC of\nany designation of GLEIF Board members by the GLEIF Board Chair for the\nextended 3 year term foreseen in Art. 17 of the GLEIF Statutes, or of any Board\nMember resignation in application of Art. 21 of the GLEIF Statutes or any other\ninability of a Board member to complete his or her term, as envisaged in Art. 17 of\nthe GLEIF Statutes; in addition, an updated schedule of Board members terms expiry\nshould be communicated to the ROC at least 3 months before the first scheduled\nexpiry;\n\n1. Proposed appointment and removal of Board members (Art. 15 and 31); this includes\nthe curriculum vitae of any candidate having applied for Board membership and the\nreasons for selecting the proposed appointee from among them, as well as the reasons\nfor removing an existing Board member;\n\niv. All proposed and adopted annual budgets of the GLEIF, including cost-recovery\nprinciples, protocols and procedures underpinning the budget (Art. 31); this includes\nthe proposed amount of any fee to be paid by the LOUs to the GLEIF;\n\nv. All strategic plans of the GLEIF (Art. 31);\n\nvi. All GLEIF audit results (Art. 31);\n\nvii. As foreseen in Art. 31 of the GLEIF Statutes, the ROC may request other materials.\nBy way of this MOU, the ROC expresses a standing request to have the following\ndocuments communicated by the GLEIF: the minutes of GLEIF Board meetings,\ndocumentation supporting agenda items to be discussed at Board meetings, including\nthe proposed recognition and de-recognition of an LOU as contemplated in Art. 33 of\nthe GLEIF Statutes, the draft protocols and methods in Art. 5 of the GLEIF Statutes\nand any other draft operational norm developed under the responsibility of the GLEIF\npursuant to Art. IX of this MOU\n\nviii. Any other ad hoc request in application of Art. 31 of the GLEIF Statutes; for such\nrequests, the notice period in clause 19 refers to the time between the request by the\nROC and the communication of documents by the GLEIF.\n\nix. An explanation for the position by the GLEIF Board not to adopt, in whole or in part,\na recommendation delivered by the ROC, and/or an alternative proposal, in\naccordance with clause 42; in this case, the notice period in clause 19 starts from the\ndate of the Board meeting where this position is taken.\n","contentLength":2456,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:19:58.239Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/mou-between-gleif-and-roc/20150923-ROC-GLEIF-MOU-final-signed.pdf","content":"6\n\n19. Except when the ROC Chair or one of the Vice Chairs recognises that exigent\ncircumstances apply and accepts a request by the GLEIF Board Chair to set a shorter\nnotice period, the notice period is:\n\n— For items (iv) and (v) in clause 18, a minimum of three weeks before the Board\nmeeting;\n\n— For the resignation of a Board member or the inability of a Board member to\ncomplete his or her term, notice should be given no later than two weeks after the\nevent is known to the GLEIF;\n\n— For any other items, and unless specified otherwise in this MOU, a minimum of two\nweeks before a Board Meeting.\n\nHowever, on request by the ROC Chair or a Vice Chair, and absent exigent\n\ncircumstances raised by the GLEIF Board Chair, an additional period of two (2) weeks\n\nshould be provided by the GLEIF, resulting where necessary in postponing the decision\nto the next physical meeting, conference call or video-conference, or to a decision by\nwritten procedure.\n\nThe objective of this notice period is to enable the ROC to review matters and, where\n\nrelevant, to issue a recommendation for the consideration of the GLEIF, as foreseen in\n\nArt. 23 of the GLEIF Statutes, before the GLEIF Board takes an independent decision.\n\nThe notice periods in this Article are without prejudice to the longer notice period in\n\nclause 25 of this MOU, which applies when an official position or recommendation of the\n\nROC is being sought by the GLEIF.\n\n20. Nothing in this Article should prevent, in addition to the official notices and\ncommunications required above, informal discussions and information exchange\nbetween, on the one hand, ROC members and secretariat and, on the other hand, GLEIF\ndirectors or the GLEIF Secretariat, or among members of joint working groups,\nparticularly regarding the development of the standards and norms foreseen in Art. IX of\nthis MOU.\n\nARTICLE VI: MEETINGS AND ROC OBSERVERS\n\n21. To facilitate coordination between the ROC and the GLEIF, to the extent practicable, in-\nperson meetings of the ROC Plenary and Executive Committee (two and three each year\nrespectively and on a regionally rotating basis) and the GLEIF Board (four each year)\nshould be conducted at the same time and location so that joint sessions and other forms\nof interaction can take place in addition to the meetings of the bodies of the ROC and\nthe GLEIF.\n","contentLength":2342,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:19:58.239Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/mou-between-gleif-and-roc/20150923-ROC-GLEIF-MOU-final-signed.pdf","content":"7\n\n22. An annual schedule is to be developed jointly by the ROC Executive Committee and the\nGLEIF Board in October for the upcoming calendar year.\n\n23. At the request of the GLEIF Chair, the ROC Observers may agree that a portion of a\nmeeting of the GLEIF be conducted outside of the presence of the ROC Observers in\norder to facilitate more candid discussions. However, nothing in this provision relieves\neither Participant of their respective communication or notice obligations.\n\n24. As provided in the GLEIF Statutes, the representatives of the ROC may observe all\nmeetings of the Board of Directors of the GLEIF. In this capacity, the ROC observers\nwill not participate in any voting or deliberations.\n\n25.If an official position or recommendation of the ROC is being sought by the GLEIF in\nadvance of a Board meeting pursuant to Art. 31 of the GLEIF Statutes, the GLEIF\nshould provide the ROC with a minimum of 30 days’ notice, except when the ROC\nChair or one of the Vice Chairs recognises that exigent circumstances apply and accepts\na request by the GLEIF Board Chair to set a shorter notice period.\n\n26. As foreseen in Article 16 of the GLEIF Statutes, at the request of an Observer, an item\nbeing considered by the GLEIF Board should be deferred, so that the Observer may take\nthe matter to the ROC to obtain the ROC position. The deferral should be for a\nminimum period of 2 weeks, except when the ROC Chair or one of the Vice Chairs\nrecognizes that exigent circumstances apply and accepts a request by the GLEIF Board\nChair to set a shorter deferral period. The ROC agrees that this possibility for Observers\nto request that a decision be deferred will not be used when the proposed decision and\naccompanying documentation have been duly notified to the ROC according to Article\nV, unless the decision to be adopted differs from the proposal notified to the ROC, or\nnew information arise.\n\nARTICLE VII: MUTUAL SUPPORT\n\n27. Consistent with Art. 13 and 14 of the ROC Charter annexed to the GLEIF Statutes\nconsideration of the modalities of ROC funding will be discussed and mutually agreed at\na later time\n\n28. The GLEIF agrees to organize the hosting of the ROC website or dedicated pages of a\njoint website, including providing any technical support, if requested by the ROC.\n\n29. The ROC will give due consideration to requests by the GLEIF for action and support\nand will continue to promote the GLEIS and the use of the LEI to expand the collective\nbenefit from widespread adoption, in accordance with the objectives of the ROC set forth\nin the ROC Charter.\n","contentLength":2574,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:19:58.239Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/mou-between-gleif-and-roc/20150923-ROC-GLEIF-MOU-final-signed.pdf","content":"8\n\n30. Article 10 of the GLEIF Statutes state that “No substantial part of the activities of the\nFoundation shall be the carrying on of propaganda, or otherwise attempting to influence\nlegislation or rulemaking.” ROC members understand that the objective of this provision\nwas not to prevent the GLEIF from otherwise communicating with public authorities,\nespecially when this is at the request of authorities, for instance responding to a public\nconsultation or to a parliamentary committee. To facilitate coordination, the GLEIF\nagrees to inform the ROC members of the relevant jurisdiction prior to delivering such\ninformation and to make clear the informational purposes in any speech, presentation or\nother material provided to public authorities. The GLEIF may also wish to develop a\nform letter that can be delivered in response to request for consultation that the ROC\ncould judge to not constitute propaganda.\n\n31. The ROC and GLEIF will coordinate to the greatest extent possible their actions to\ninform the public about the GLEIS and promote the use of the LEI, including through\ntheir respective webpages and other means. In particular, the ROC and GLEIF will cross-\nlink their respective webpages. However, the ROC and GLEIF will each keep the\nresponsibility of determining and posting the content of their respective webpages.\n\nARTICLE VIII: INFORMATION\n\n32. Under Article 30 of the GLEIF Statutes, “the ROC may request to inspect and monitor\nthe activities of the Foundation, including to undertake on-site reviews, conduct\nhearings, request reports and other means, as well as to request information from the\nBoard as specified in the ROC Charter”. This may include accessing information\nobtained by the GLEIF from LOUs or third party service providers, to the extent\nnecessary for the ROC to conduct its oversight functions to uphold the Governance\nPrinciples of the GLEIS and to assess the performance by the GLEIF of its operational\noversight of the GLEIS, including but not limited to evaluating data quality and data\nstandards, ensuring public access to key data and safeguarding of any non-public data,\nand confirming the application of cost-recovery limitations by the GLEIF and the LOUs.\nThe GLEIF should ensure, in the contracts the GLEIF concludes with the LOUs and\nthird party service providers, that the ROC will be able to access this information.\n\n33. Where warranted by the sensitivity of information that would be considered to be a trade\nsecret of an LOU or third party service provider, access to information as contemplated\npursuant to clause 32 could be limited or subject to a non-disclosure agreement.\n\n34. An annual report by the GLEIF to the ROC and the public is to be provided to contribute\nto the implementation of the transparency requirements in Art. 6 of the GLEIF Statutes.\nThe annual report should include:\n","contentLength":2855,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:19:58.239Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/mou-between-gleif-and-roc/20150923-ROC-GLEIF-MOU-final-signed.pdf","content":"9\n\n— the annual budgets and annual accounts;\n\n— an overview of the activities of the GLEIF, including decisions to recognize and\nderecognize LOUs and an overview of new operational norms and changes in\noperational norms;\n\n— any change to the governance materials, criteria for the recognition or de-recognition\nof LOUs or conflict of interest policy, significant audit results, information on the\ndata quality and its evolution compared to the previous year.\n\nThis 1s without prejudice to the detailed disclosure of the individual items organized by the\nGLEIF Statutes, in particular Art. 6 and 24, and to general policies on transparency to be\napproved by the ROC pursuant to Art. 6 of the GLEIF Statutes and Art 2 b) (3) of the ROC\nCharter.\n\n35. This Article is not intended to address how the GLEIS will ensure the access by public\nauthorities — including a ROC member authority — to any non-public LEI reference data\nthat may be collected in the future, such as information on the relationships between\nentities. Such access will be organized by operational norms to be developed by the\nGLEIF in consultation with the ROC and in accordance with the policy standards\nadopted by the ROC. More generally, this Article is without prejudice to the access to\ndata and information by public authorities under their domestic frameworks.\n\nARTICLE IX: STANDARDS AND NORMS\n\n36. The Governance Principles of the GLEIS and the GLEIF Statutes contemplate, and the\nParticipants agree, that the responsibility for developing standards and norms for the\nGLEIS should be coordinated as follows:\n\na. Policy standards concerning data or information to be collected or used for\nofficial or regulatory purposes are to be developed by the ROC in consultation\nwith the GLEIF and other relevant stakeholders. Examples of such policy\nstandards include, but are not limited to: the definition of the eligibility to obtain\nan LEI and conditions for obtaining an LEI; the definition of reference data and\nany extension thereof, such as the addition of information on relationships\nbetween entities; the frequency of update for some or all the reference data; the\nnature of due diligence and any other standard necessary to ensure sufficient data\nquality; principles governing data and information access.\n\nb. Operational and technical standards for the GLEIS necessary for consistent\nimplementation in a federated system, or respecting specific schemas or\ntransmission protocols, are to be developed by the GLEIF in consultation with the\nROC and other relevant stakeholders. Examples of such operational and technical\n","contentLength":2593,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:19:58.239Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/mou-between-gleif-and-roc/20150923-ROC-GLEIF-MOU-final-signed.pdf","content":"10\n\nstandards include, but are not limited to: data file formats and the normalization of\nreference data, such as business registry naming conventions; operational\nmanuals, methods and procedures for the GLEIF (eg: manual for inspecting\nLOUs; assessment criteria and methodology for the recognition and de-\nrecognition of LOUs) or for LOUs (eg: portability procedures), contracts between\nthe GLEIF and third parties (eg: Master Agreement between the GLEIF and\nLOUs).\n\n37. In all instances, the development of standards as described in clause 36 should include\ninput from relevant stakeholders. The extent to which input for standards development is\nbroad and formalized should be set in consideration of the costs associated with one\nstandard or another, the existence of disparate user needs and benefits associated with\ndifferent choices, and associated efficiencies.\n\nARTICLE X: HEARINGS AND INSPECTIONS\n\n38. If the ROC decides that its Plenary or Executive Committee should conduct a hearing as\nforeseen in Art. 30 of the GLEIF Statutes, notification is provided by the ROC to the\nGLEIF as described in clause 17 at least 2 weeks before the intended date of the hearing,\nspecifying the members of GLEIF Secretariat staff or GLEIF Board members to be\nheard and the topic of the hearing. Unless justified by the urgency of the matter as\ndetermined by the ROC Chair, hearings take place at the same time and location as joint\nsessions between the GLEIF Board and the ROC Plenary or Executive Committee\nforeseen in clause 21. The GLEIF Board Chair may request that a hearing be postponed\nby up to two weeks, unless the ROC Chair or a Vice Chairs raise exigent circumstances.\n\n39. If the ROC decides that an on-site inspection of the GLEIF should be conducted as\nforeseen in Art. 30 of the GLEIF Statutes, the ROC will provide notice to the GLEIF as\ndescribed in clause 17 at least 2 weeks before the intended start date of the inspection.\nThe process described in clause 33 of this MOU may apply to the selection of members\nof the ROC inspection team and the preservation of the confidentiality of any information\nobtained during the inspection. A draft report of the ROC inspection team should be\nsubmitted to the GLEIF for comments no less than 2 weeks before it is sent to ROC\nExecutive Committee and Plenary. Upon the request of the GLEIF Board Chair, the\ncomment period may be extended by up to two weeks, unless the ROC Chair or a Vice\nChairs determines that exigent circumstances apply. The GLEIF Board Chair may also\nrequest that the GLEIF response be annexed to the final report of the ROC inspection\nteam.\n","contentLength":2616,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:19:58.239Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"AsupERUNG £10 SEEA e hae\n) gemiss Beschluss vom\nA9 OKT. 2008 Heli’a@tfi?&b\nLeiterin\nGLOBAL LEGAL ENTITY IDENTIFIER\nFOUNDATION\nStatutes of August 7, 2018\n","contentLength":152,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.381Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"\\\n\nI. NAME, DURATION AND SEAT ..o et teveseces et sae s D\nArticle 1 Name and Duration ... et D\nATECIE 2 S oot e e e e an et eene s D\n\n1I. PURPOSE, MEANS AND TRANSPARENCY ...t D\nAFCIC 3 PUIPOSE .ottt e s O\nAFCle S MEANS oot ettt b rree e smenenenne\nArticle 6 TEANSPATCICY ...ooorrveerieiirrrtreersveerieieecesresrae e raessevnseesrasseenresreesanesaaseessvesnsaraess O\n\nII1. INITIAL CAPITAL, ASSETS, SUSTAINABLE FUNDING, LIMITATIONS\nArticle 7 Imitial capital ... ]\nArticle 8 T T OO T VSR TOT PP USR U TRPTORRORPRRRNY |\nArticle 9 Sustainable funding ...t 1\nArticle 10 Limiitations .......cooooiiiiiiiiie e et ras e e O\nArticle 11 ACCOURLS ..ot crae et e s e e et s maes e enes e ieerreens O\nArticle 12 The Foundation Bodies ... 8\n\nV.A: THEBOARD OF DIRECTORS ..ottt cnnas s B\nArticle 13 Composition of the Board ..., 8\nArticle 14 Appointment of the initial Board and of the Chair............................... 9\nArticle 15 Appointment and removal of Board Members................coo 9\nArticle 16 Appointment of ex officio Board Members..............cccococcrinvviinncccnnn 10\nArticle 17 Terms of office and term Lmits ... 10\nArtiele 18 Conflicts of interest... ..o sres e e neinees L)\nArticte 19 Action on an unpaid hasis ...\nArticle 20 CRAIF ..ot nneeneees ] ]\nArticle 21 Resignation of Board Members.......o.oco i 11\nArticle 22 Competences and functions of the Board ... 11\nArticle 23 Board decision-making...........cccocoooriirriiiinie et srrvsaes s essneseaeeeens 12\n\n2\n","contentLength":1477,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.381Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"Article 18 Conflicts of intercst\nThe Board shall adopt a \"conflicts of interest\" policy to preserve transparency in financial\narrangements and relcasc it together with any updates publicly on its website. This shall covor\nin particular all Board Members including ex officio Members.\nIn particular, the policy shall provide that alt actual and petential conflicts of interest must be\ndisclosed to the Board as well as being managed in compliance with the published policy. The\npolicy shall comprise all necessary measures, including recusal, which shall be taken in such a\ncase.\nArticle 19 Action on an unpaid basis\nBoard Members shall act on an unpaid basis and be entitled only to the reimbursement of their\ncifective costls and travelling expenses. Any compensation made in respect of attendance, as\nthe case may be, may not excecd that paid for atlendance to official commissions in Bascl-\nStadt. For activities excceding the usual scope of the Foundation, each Member of the Board\nmay receive appropriate compcensation according to the principle of \"usual in the market\".\nArticle 20 Chair\nIn accordance with Board of Directors' decision making as outlined in Article 23, the Chair of\nthe Board may be sclected by a simple majority vote of all Board Members from among its\nMembcrs. The term of the Chair corresponds to Article 17 para. 1.\nArticle 21 Resignation of Board Members\nBoard Mcmbers can resign at any time by subinitling a written declaration to the Chair\nspecifying when the resignation shall take effect.\nArticle 22 Competences and functions of the Board\nThe Board shall be the supreme governing body of the Foundation. [t shall possess all powers\nthat are not expressly delegated to other bodies in the present Statutes or By-laws of the\nFoundation and it shall exercise its powers in the best intercsts of the Foundation.\nThe Board shali posscss the highest and most cxtensive authority concerning decision-making\nand administration of thc Foundation and shall exercise all other lawful powers required to\ncarry out the purpose of the Foundation.\n\n1\n","contentLength":2068,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.381Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"should also be developed for maintenance of secure parallel copies of the LEL, in a manner\nthat respects local laws. '\nThe Global LEI system should be available on.a continuous basis and should meet best _\npractice standards for business continuity and contingency planning for key financial market\ninfrastructure. The system should also be able to function in the event of insolvency and\nbankruptcy of a component, through the identification and application of rules and procedures\nthat must be followed in such a case.\n\" Recommendation 31\n. LEI INTELLECTUAL PROPERTY The LEI Implementation Group should conduct\n\nanalysis and provide recommendations on the treatment of the “LEI” intellectual property\n(such as the LEI code, software, reference data, any other LEI data, operational protocols, etc)\naccording to the principles of open access and the nature of the LEI system as a public good.\nThe objective of this analysis shall be to ensure a regime that assures the availability in the\npublic domain, without limit on use or redistribution, of LEI data, reference data, and\nprocesses. Any intellectual property rights should be held by, or licensed to the global LEI .\nfoundation unless. defined otherwise by the Regulatory Oversight Committee. Copyright |\nshould be used to the extent possible to promote the free flow or combination of information\nfrom disparate sources.\nDevelopment of the global system of unique entity identifiers is likely to entail the creation of\n\n: specific intellectual property rights in relation to certain key operational features of the\n'system. It is important that such IP rights do not provide privileges that act against the public\ninterest, for example, by providing power to market providers that ensures that the system\nrelies on their services, or that the system cannot function in the event that the particular\nvendor enters insolvency. To avoid adverse incentives and to ensure continuity of the system\nand thus that the system is ‘vendor independent’, the IP rights should reside ultimately with\nthe global LEI system, as embodied by the proposed global governance arrangements. .\nThe LEI is deemed to be a public good and available to the public at large for free. LEIs may\nbe freely reproduced, distributed, transmitted, used, modified, built upon, or otherwise\nexploited by anyone for any purpose, commercial or non-commercial, and in any way,\nincluding methods that have not yet been invented or conceived. It will be important to\nspecify clear rules and guidelines on the use of the LEI to make sure that the principles of free\nand open access are protected and that the system is not abused.\n\n\" VI Implementation and next steps\nThe FSB strongly supports the rapid implementation of a global -LEI system under the\nframework set out above. Early delivery of the system would provide manifold benefits to the\nglobal regulatory community and to the private sector. |\nThis section sets out an implementation plan framework. The aim is to adopt the Charter of\nthe Regulatory Oversight Committee of an independent, open, fair and transparent global LEI\nsystem in November 2012, with the Committee fully and independently functional by March\n55\n","contentLength":3190,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.381Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"_ 2013. Achieving this objective will require substantial high political level support) and a\n' strong commitment to provide expert resources to undertake the necessary work, as well as ’\n~ strong engagement and co-operation with the wide range of the private sector participants on\n“the COU development. - R : '\nTo advance the global LEI initiative into the implementation phase, the FSB recommends .\nsetting up an LEI Implementation Group with a clear mandate to ‘launch’ the system on a self\nstanding basis as soon as possible.\nTwo immediate strands of work were identified that need to be addressed by the FSB LEI\nImplementation ‘Group:\n\n) Governance: Undertaking all the legal, policy, organisational and administrative\n\nwork to establish the permanent governance arrangements for the global LEI system\n. as well as the necessary legal and administrative work to stand-up the COU;\n\no Operations: In close co-ordination with the private sector, to undertake and oversee\nthe necessary technical work to develop, launch, and implement an operational\nsystem for the COU of the global LEJ, that delivers agreed technical and operational\n\n' _standards, and that enables open access to the system and federation of local\noperations.\nA third strand is continued policy development. Until the new governance arrangements are in\nplace that will address outstanding policy issues at that time, policy development, such as\n' work on corporate ownership structures and business hierarchies, will take place under the.\nImplementation Group. _\nThe FSB LEI Expert Group is an ad hoc group which has a time-limited mandate. It has now :\nbeen disbanded. If the proposals and recommendations in this report are accepted, and the :\nFSB is tasked to support the first step of the global LEI system implementation, the proposed\nFSB LEI Implementation Group will be created immediately after the G-20 Summit to take\nthe project forward. Although the Group will build on the Expert group, in terms of\n' membership and skills, additional legal expertise and additional technical and operational\nskills will be needed, relative to the membership of the Expert Group. The Implementation\nGroup should cease to exist upon formation of the ROC, which should be by March-31 2013\nat the latest. .\nMembership of the Implementation Group will be open to authorities and jurisdictions willing\nto support the development and implementation of the global LEI system, and to supply\nsuitable expertise to the project.\n' Recommendation 32 .\nFSB LEI IMPLEMENTATION GROUP Subject to the G-20 supporting further work to\nJaunch the global LEL and entrusting implementation planning to the FSB, an FSB LEI\n] Implementation Group should be established with a clear mandate to launch the global LEI 7\nsystem on a self- standing basis. The LEI Implementation Group should cease to exist upon\nformation of the Regulatory Oversight Committee which should be by 31 March 2013 at the\nlatest. _\n- ' 56\n","contentLength":2954,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.381Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"Recommendation 33 . '\nSTRUCTURE OF THE FSB LEI IMPLEMENTATION GROUP A time-limited FSB\nLEI Implementation Group (IG) of interested and willing experts (legal, IT, and other) from\nthe global regulatory community that includes interested parties from the FSB LEI Expert\nGroup should be formed to take the global LEI initiative forward into the global\nimplementation phase until the Regulatory Oversight Committee is established. The IG\nshould be led by representatives from different geographic areas to reflect the global nature of :\nthe LEI initiative and will be supported by the FSB Secretariat. The IG should develop\n‘| proposals for the global LEI system stand-up as defined in the mandate below for review and\nendorsement by the FSB Plenary in October 2012 and, as appropriate, final review and\nendorsement by G-20 Finance Ministers and Central Bank Governors in November 2012.\nRecommendation 34 ' : ‘\nRESPONSIBILITIES OF THE FSB LEI IMPLEMENTATION GROUP The mandate of:\nthe FSB LEI Implementation Group should be to prepare a draft global LEI Regulatory\nOversight Committee Charter, proposals for the establishment of the LEI Regulatory\n' Oversight Committee and related structures, develop all necessary legal documents for\nRegulatory Oversight Committee operations, develop necessary intellectual property\nagreements and contracts, conduct research and provide recommendations on LEI related\ninformation sharing arrangements; set up the process and any necessary legal documentation\n: necessary for establishment of the Central Operating Unit and its Board of Directors; and set\nup the process for establishment of necessary standards, protocols, rules and procedures and\n' organizational design for the Central Operating Unit.\nLaunch of the global goVérnance framework\nThe High Level Principles and proposed Charter for the ROC will frame the governance\narrangements for the global LEI system. Subject to high level support for the approach, the\nCharter will be developed by the Implementation Group for endorsement by the FSB in\nOctober, as appropriate, final sign off and endorsement by the G-20 Finance Ministers and\nCentral Bank. Governors in November (see Annexes 1-4). A very provisional list of elements\nfor inclusion in such a Charter is outlined in Annex 4, Suggested initial components, include:\n. Mission of the Regulatory Oversight Committee\n. Objectives of the Charter\n. Commitments and Obligations\n. Membership :\n. Mandate and Responsibilities of the Regulatory Oversight Committee :\n. Functions and Powers ’ :\n. Structure of the ROC _\ne Decision Making\no Sub — Committees and Advisory Panels\n57\n","contentLength":2619,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.381Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":". Secretariat and Administration\n. Establishment\n- As well as preparation of a draft Charter, the Implementation Group will also need to prepare\nall the supporting legal documents governing the global LEI system. A preliminary list is set\nout above under recommendation 26.\nDrafts of these documents could also be taken forward by the proposed group in consultation, -\nif necessary, with financial industry specialists and private sector legal experts with relevant\nexperience in those areas. The aim will be to prepare all of the necessary legal documentation\nto support the launch of the ROC by March 2013 at the latest.\nRecommendation 35 .\n\n: ESTABLISHMENT OF THE GLOBAL LEI SYSTEM The global LEI system will be\nestablished by the endorsement of the high level Charter for the Regulatory Oversight\nCommittee by the G-20 Finance Ministers and Governors in November or by the FSB Rlenary\nin October. ,\n\nEndorsement of the Charter will establish the global LEI system. That will include the\ngovernance framework including: the creation of the ROC, potentially housed in an\ninternational organisation; and appointment of the Chair and Secretariat of the ROC. Once the\nROC has been created from jurisdictions and regulatory authorities indicating support for the\nCharter, by March 2013 at the latest, it will have responsibility for the endorsement of the\nCOU and for the launch of the system on a self-standing basis as soon as possible, which\nshould be by the end of 2012 ideally and by March 2013 at the latest.\nLaunch of the operational framework :\nThe principal focus in relation to the creation of the COU is on the speedy development and\nimplementation of a central platform that will facilitate the integration of local identification\nsystems (whether currently existing or emerging) into a logically central database of unique\nLEIs based on consistent standards, protocols, procedures, etc). The technology stream of the\nImplementation Group will work with a wide group of private industry representatives to\ndevelop a global LEI system that will allow the rapid integration of federated local systems\ninto the logically centralised database and that will appear to be seamless to end users. In\nother words, any user will be able to access the global LEI system and obtain the LEls or\nreference data of any entity registered with the system from across the globe — subject to\nprivacy or confidentiality restrictions. being maintained. Indeed, in the latter respect, the\ntechnology stream will need to ensure that the system meets the highest standards in relation\nto data integrity and security, business continuity and access controls. ‘\nThe Implementation Group will work closely with private industry experts to design and build\nan efficient system for the Central Operating Unit. The preferred approach is for the ROC\n(initially the Implementation Group) to direct the creation of a global LEI industry foundation\nor body of equivalent legal form to develop and operate the COU. »\nFollowing agreement to proceed with implementation, regulators would immediately solicit\ninterest from a broad spectrum of private industry that includes financial companies (i.e.\n- 58\n","contentLength":3177,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.381Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"banks, financial intermediaries) and non-financial companies (i.e. standard setting bodies,\ndata vendors, commercial companies, consulting companies) to participate in a global\n' foundation that would be tasked to develop technical solutions for the implementation of the\n‘ global LEI system, under the broad guidance and proposed legal framework provided by the\nImplementation Group. Participants would be sought on a global basis and from a broad set of\nexperience, including from experts from outside the financial sector with experience of :\nsuccessfully introducing entity identification schemes. The Implementation group will\n: provide a framework (outlining the main requirements and standards) and guidance for the\nprivate sector, enabling interested parties to work together within a foundation framework to\ndeliver open access implementation processes and solutions that will quickly develop a\n: central ‘plug in’ platform that local systems will link into. Once the ROC has been\nestablished, and the parallel legal work to set up the foundation completed, the ROC would\nset the eligibility criteria for membership and would select the global foundation to act as the\n' COU. An initial BOD could then be selected by the ROC from the foundation members\n: (supplemented potentially by independent members) to oversee the preparatory work and to\n' act as the BOD of the self-standing COU. The BOD per validation by the ROC would decide\nfor each part of the system whether to develop and operate the component within the\n. foundation, or whether in some cases to buy in services or facilities from third party vendors.\nThe provision of seed-corn funding for the development of the system would need early\n~ resolution. The various possibilities include: private foundation funding (preliminary .\ndiscussions indicate interest on the part of such foundations and other non-governmental\norganisations); contributions/loan from the public sector or an international financial .\ninstitution; public funding and/or a private sector loan (that is the funding method suggested\nby GFMA/SWIFT/DTCC). Seed-corn funding would be repaid out of subsequent revenues of\nthe system. An important early task of the Implementation Group will be to pursue seed-corn\nfunding options, for consideration and decision by the ROC. The proposed implementation\nplan and timelines are summarised in the annexed Charts 5-7.\n59 : .\n","contentLength":2409,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.381Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"Annex 5: LEI Implementation Group work plan diagram\ni§ FSB LEI implementstion group work plan [ _\ni b e N h RS I T A R 205 e 9o e S it vt Wi T el ST L\nbl D i e R R e R e R T T S ]\n- e “riffi;u i Delenbled oo O Dielwenbleds\nL oy oy isati il | ST eI ESH USRS o T T e\n- Legal wogk for | firfigfim Emideropeniis o SROCHTEEAl s s bioiTdaeale e\n\" ROC and COU el “La'@d—'& e S R R S\ns = st S D e SR e e e [ eaigep iy\n. fi e e Wfi*é’*uifi%i&ég- B B e\n; 7%3”§1flfi%4rrflf*>i4;\"% s FIOUSE BT RO0G ol it i 2 i\nSt R LR IO | Sttt Uit =i, 40 0 0 it i e e\nEiip i v el Bih, o) S T T Ay e R e B\n] e u@x,}}%fifi;,rfifi?(%&@flifi% 4 fi,{;hfiiwfiq&,chmfi» e D S e\nA e R R et o R it T T e s e e\n3 R N R RO IRIRER e R S i, e N e e e e B e e e e\ni F TR Rl S e T A DR B T e I e R R e e e R S el e Tl\n: ' fi;fifi“«ihffiflf‘&%flfifl% B e R el e\n| o ; ] R e b G T e T R e e s e\nl ; [ i | R e e S e R\n. FSB LEI Implementation ';\\fia%fifiifi*fiég,wfi e e e e e e e ey\n3 X e e T D ) SR e e G S ST (I S e e e\n| Grovp\n|\n[\n_ ; .\nw w 1 | '\nPR AL g 1 ; IS S R ST SN i T R o e 8 S R s S\nKo LA Al 1 i fit SR e R [ T R s S M S 2 s\n0 = Rl i + ; M‘T’L»flsfifl SRR o e e\net T ST T L | ) n“fl‘fi_‘.{{fa‘?fig*aw e s L R L e\ni e e i T e S L A R T Sedilesgra\n“%E!;‘mgw”rjmfifimw i ] ] ] 'fi;hs@m‘fmgiwl“fi«fl\"‘:113?’:5‘2«57;-;3rfléfi*fiffl'—':zl}f‘wfet[é D e e\ng ierla] AR Hilbeth ANl 1 f g i oy 7 el e N e L N i g e A e\nA e i Legal experis ] }.TXIechnoIogy work forCOT *@fiflffl@',}'i:fi{;;:‘ ) ,r’jfl?;u«;é 51:-‘.<1;i:;fi;;’s:.Lfigur:‘;?:,‘w%wyg‘r;‘/ e R e S\n= [ R AT e e B R L e SR L T e gl S e I imtin Sl i S B\n: ] fio i il ORa U S et ol e R G ol\n| + : - anmouncement of the ,fi;;fi%‘*@y}’g@fié oot cn s BeliveraBladil oo it\n. ! [ A . ey e R e e e L e\n] [ o pliat b e bt Il 4fi3< FRE S e i e L TR\n; establishment of e giobal a—rwtfimw{}:@”*%b%{%fi ol CONTT Technolomyt .\n— ] [ : T ) B o D TE T L N s\nT Technology experts | mdustry LEE fourdation fl\\,f%“igim;‘&lw i ifi;fi@[’%}“fSfiE:“E‘W”‘ e\n; ] . - - —ia_fi«gg;ifi B L e MR s B lie s e B g e e e ey\n] { oonsulfative growg; Jo i wfifigfiéfi \" tcentral P Dl pint development |\n-mandate: global industry s ‘}fixfiéfi:l e S Re et al Qperaag Ity e\n] : | SRR AR e e D T LS L\n{ development and T prshang S eeiopiment prodess e\n; el psepsend beinag v o UCVEODEIEIMLAWOCESS o o cies 2ab\nestablishment of the global [EISESRBEHONIOboMiL 0 e e\n| L] i : i %‘ i L P e e R\n, | LEI foundationTT solutions |l GOTMMRRRNT .« Covi) it sl\nOt 0173 1 ot £y i e e e e dhait ke e e I R\n13-‘: ber 2 df.f i s gl b fin it L i o e el e iR TR SR e T LR\n¥ Octaber 2012 (under the J%W‘flu{pn‘fik»&}flfl:fmi e e\n: ar ; DO < et s B L e i sl e e G e Bl e R A\nguidance of the FSBLEIIGY, | *’@ffi%fiwflfi%:{ffifii s e R TR e\n] I e e e e e O S s b e D\nel e gl GRS\ni et P e e\n- gy Jg:jeérfl‘:‘r\"]‘f-‘;'?‘;‘*“r.il‘.@‘»ff 31‘{ »,.t_,_-,';k”r:g %%‘?«Jfi'm»4,~ T e TS s\nel e R e M DR B Ui Rl i bl B P S S ottt SR T L\n| B R e\n] [ R e L e S S e\nR o P R ] U S S s B e 0 DR T i L\n] Pt b s RSRSR Il Tl sl S B e\nfdl A !;5[%‘;2'~\",.-'1.’-“411L wl,.p“;_wz.{rgv RE I e e B R e (e\nbl ::an‘;?fiffiffi,f?:\"’r‘“mlfi;:{ujfi%*?fihi?fl-g,qh'a‘?ff;i‘vé_!flli P Lo b e e\no et e e e\n) .\n-\n-\n","contentLength":3045,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.381Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"Annex 6: Global LEI system Charter development diagram\n' Global LEI system Regulatory Oversight Committee | ' '\n\nCharter development\n\n: | -FSB LELIG gevelops charter:\n\n{ - FSBA3-28 reviews and endorses chattes\n\ns ‘ : i - Endorsement establishes global LF system ]\n\nooy ; I G-20 mandates , o (Eclnding ROCY; |\n\n, E5B LET p can for global LET i SR AL j - ROC is housed in intecnationsd organizaiion;\n\n| ExperttGroup | ] E system — FSB/G-20 - - ROC Iras secretariat;\n\n‘ ‘ | ] - ROC endorses COU;\n\nROC — October/MNovember 2012 B\n_ _ | COU-—NovemberDecember 2012 |\n61 .\nT e —————————— e e et et et oo\n","contentLength":596,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.382Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"Annex 7: LEI Central Operating Unit development process diagram\n| Centeal Operating Unit i Central Qperating Unit {C01F) establishment\n\ni Aomndation. :\n\n~ srmoumcertent of fie estebishment of o globsl ndestey LEY foundstion conseltative sronp oF =5 | ’\n\nimterested pardes ;,\n\n- 3 to mupuiste the estabHshement of the plmn for fie globel LET Sonndstion;\n\n- 1G to develop tegal famework: for the slobel LRI faumiaron; .\n\n- 13 szty-up initind =B gib@Ry iters for particivation in e giobel L1 Somndetiom; A\n\n- formaion of RO Followed by COU esizhilishnreny; : . . .\n\n- BOI} 5 formed Som: the global LEE foumsation pins indspendent directors; | '\n\n62 .\nM\n","contentLength":650,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.382Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"- Annex 3 '\n' Global LEIX System High Level Principles . | _ '\n1. The Global LEI system should uniquely identify part_icipants to financial transactions.”\n- 2. TheLEl system should meet the requirements of the global regulatory community for\n: accurate, consistent and unique entity identification. : ,\n3. The LEI system should be dcsignéd in a manner that provides benefits to financial\nmarket participants. : :\n4. Flexibility must be built into the global LEI system to provide the capability for the ‘\nsystem to expand, evolve, and adapt to accommodate innovations in financial markets.\n5. The LEI system should not be \"locked-in\" with a particular service provider for any key\nsystem functions or processes. The principles of competition should be ensured on both\nglobal and local levels where appropriate. '\n6. .The global LEI system should support a high degree of federation and local T\n- implementation under agreed and implemented common standards. :\n7. The LEI system should meet e‘vollving requirements of both the regulatory community o -\n_ and industry participants in terms of information content, scope of coverage, timeliness\n' and availability. o . :\n8. The LEI Regulatory Oversight Committee should have the responsibility of upholding .\nthe governance principles and oversight of the global LEI system functioning to serve ‘\nthe public interest. The Committee has the ultimate power and authority over the global\nLEI system. ' . -\n9. The miséion, role and responsibilities of the ROC shall be specified by the global LEI\n Regulatory Oversight Committee Charter, whieh shall establish the Committee.\n10. Participation in the global LEI Regulatory Oversight Committee shall be opentoall\n- authorities subscribing to the High Level Principles and to the objectives and\ncommitments in the Charter. ' .\n11, The LEI Central Operating Unit should have the mission and role to ensure the _ '\napplication of uniform global operational standards and protocols set by the ROC.and\nact as the operational arm of the global LEI system. It shall be established asa -\nfoundation or legal equivalent. -\n12. The LEI Central Operating Unit should have a balanced répresentation of industry\nparticipants from different geographic areas and sectors of economy. Its Board of\n4 ' :\n","contentLength":2282,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.383Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"' Directors should be selected from industry rc;pres’entativés‘, plus independent | _ '\nparticipants. ' . :\n| TRICH Notariat Zrich (Altstadt) -\n\n| S=W | ST\n\nA /A B D\n. & % S O -\n\n. z= Y B ) ; SR\n: . N\\ ¥ — * : - '\n| G RS M Muller-Smit, Notar\n","contentLength":242,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.383Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"The Board may delegate its powers, execpt where governing law or these Statutes or By-laws\nas the casc may be otherwise prohibit delcgation, and except that no committee or person\nshal] be given thc power to:\n\n. cxercise the oversight authonty of the Foundation;\n\n» file an application to the Supervisory Authority regarding the amendment or\n\nmadification of the Statutes;\n\n. adopt By-laws of the Foundation;\n\n. amend or modify By-laws;\n\n. appoint or remove any Member of the Board, with respect to Article 14 of the\n\nStatutes and without prejudice to the competences of the Founder;\n\n. appoint the external auditors;\n\n. determine signatory powers and representation authonty of the Foundation;\n\n. approve the aunual audited accounts of the Foundation.\nAll Board Members shall at all times seek to uphold the objectives of the GLEIF as set out in\nthese Statules and to cnsure the operation of the GLEIF in the broad public interest in line\nwith the High Level Principles and FSB recommendations, as endorsed by the Heads of State\nand Govermment of the G20 at the 2012 Los Cabos Summit, as well as any additional\nprinciples or standards adopted by the ROC.\nArticle 23 Board decision-making\n'The Board should try to find consensus. If all reasonable efforts by the Board and the Chair\nhave not led to a consensus, the Chair may call for a vote. In order to be approved, and unless\notherwise provided for herein, votes and resolutions require a simple majority of all Board\nMembers participating in the meeting. Each Board Member shall bave onc vote. In case of\nequality of votes, the Chair shall have a deciding vote.\nA quorum is cstablished 1f a simple majority of the Board Members is present. Representation\nof a Board Mcember 1s not admissibie.\nRecommendations delivered by the ROC shall be given due consideration without undue\ndelay but are not binding for the Board. The Board's responsc {o each recommendation shall\nbe provided to the ROC without undue delay.\nWhenever the Board does not entirely adopt a rccommendation dclivered by the ROC, the\nresults of the Board's decision and the reasonable grounds for such decision shall be made\n\n12\n","contentLength":2147,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.383Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"Annex 4 , :\n, The Membérs and the Chair of the initial Board of the Foundation :\n' o tt\\\\ Notariat Zlirich (Altstadt) .\nA P IR\\ o\n@ J CIANE : _\n= f-; ) B _r\nA R T\ne, _\nNG S M Mller-Srmit, Notar\n","contentLength":194,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.383Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"Inaugural Board of Directors of the Global Legal Entity Identifier Foundation '\n'\nChina Financial Computerisation Corporation ' ‘\nManagement: Goethe University Frankfurt L\n'\nil G il\n'\nNetherlands ' : _\n-\n-\ne pem——]\n' Chase .\n. .\n","contentLength":229,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.383Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"promptly and publicly available, unlcss, as discussed with the ROC chairs, such publication\nviolates confidentiality or privacy criteria.\nThe Board shall be empowered to pass resolutions and vote by means of circular letter only if\nno Member asks for a meeting and in which each Board Member gives his/her written\nresponse to a proposition, or by teleconference, or e-mail or any other method of\ncommunjcation according to a pracedurc laid out in the By-laws.\nArticle 24 Meetings\n'The mectings of the Board shall be convened cither physically or by any other means, such as\nconference calls, video conferences, or otherwise.\nThe Board shall mect as often as required by the Foundation but not less than once per year in\nperson. Notice of meetings and agendas shall be provided to Board Members and to the entire\nROC via the ROC Secretariat in advance, with due time for review, as to be provided in the\nBy-laws.\nThe Chatr can convene a meeting of the Board at any time, at his/her own discretion, The\nChair must convene a meeting at the written request of two Board Members.\nAll discussions of the Board will be recorded in the minutes of the Board mectings, approved\nby the Board and retained in the permanent records of the Foundation.\nAs a general rule, the Board deliberations and its decisions must be transparent in accordance\nwith Article 5 here above.\n\nY. B: THE EXTERNAL AUDITORS\nArticle 25 Appointment\nThe Board shall appotnt an external firm of avditors {the \"Auditors\").\nThe Auditors shall be appointed for renewable terms of three (3) years.\nThe terms of office of the Audilors cun always be terminated at any other time.\nArticle 26 Audit Report\nThe Auditors shall conduct an annual audit of the accounts of the Foundation. The Auditors\nshall deliver a written report of the audit findings to the Board within five (5) months after the\nend of cach excrcise.\n\n13\n","contentLength":1875,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.383Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"V. C: THE SECRETARIAT AND THE CHIEF EXECUTIVE OFFICER\nArticle 27 The Secretariat\nThe Board may be assisted by a Secretariat composed of the number of staff rcquired to\nadminister the day-to-day opcrations of the Foundation,\nArticle 28 Functions of the Secretariat\nThe Secreiariat is responsible for the day-to-day administration of the Foundation. Its\nfunctions and powers are based upon tasks assigned by the Board.\nThe {unctions as well as the competences of the Secretariat shall be specificd in By-laws,\nArticle 29 The Chief Executive Officer\nUpon the proposal of the Chair, the Board shall appoint a Chief Exccutive Officer (the\n\"CEO\") to renewable terms of three years.\nThe CEQ shall have the responsibility for the general supcrvision of the Secretariat, which\nshall be recruited and appointed by the CEQ, under policics and procedurcs approved by the\nBoard. In particular, the CEQ ghall have the authority, within limits and guidelines decided by\nthe Board, to enter into contracts and administer funds on behalf of the Foundation.\nThe Board may authorise the CEO to appoint one or more deputies to perform the functions\nand duties of the CEQ in his or her absence.\nVI. A: INTERACTION WITH THE REGULATORY OVERSIGHT COMMITTEE\n\nArticle 30 Role\nThe mission of the ROC is to uphold the governance principles of and to oversee the Global LEI\nSystem, in the broad public interest, in accordance with:\n\na) the Global LEL System High Level Principles and FSB recommendations, as endorsed by\n\nthe Heads of State and Government of the Group of Twenty (Los Cabos, Junc 2012)\nb} any additicnal principles or standards adopted by the ROC; and\n¢) the ROC charler and any amendnient to the provisions of the ROC Charter,\n14\n","contentLength":1719,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.383Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"In furtherance of this mission, the ROC is to take appropriate action to protect the puhlic interest\nthrough regulatory oversight of the Global LET System.\n\nWhile the ROC is not a body of the Foundation, it defincs the framework, principics and\nstandards under which the GLEIS shall operate, in accordance with (he purpose clavsc of the\nFoundation, and oversees the respect thereof. For the purpeses of the Foundation and its\npresent statutes, the ROC is undersiood to refer to (he Members of the ROC acting in concert\npursuant to the Charter of the ROC for the GLEIS originated on November 5, 2012, and does\nnot include the observers of the ROC.\n\nThe ROC may request to inspect and monitor (he activities of the Foundation, inciuding to\nunderiake on-site reviews, conduct hearings, request reports and other means, as well as to\nrequest information from the Board as specified in the ROC Charter.\n\nArticle 31 Duty to give notice and provide documents to the ROC to enable ROC\nConsultations and Recommendations\n\nThe Board or its Chair shall give notice to the Chair of the ROC, in sufficient time to allow\nthe ROC considcration and coansultation, of the following:\n\n. pending and actual Board vacancies;\n\n. proposcd appoiniment and removal of Board Mcembers;\n\nThe Board or its Chair shall provide to the Chair of the ROC, in sufficient time to allow the\nROC consideration and consultation, the following documents:\n\n. all proposed and adopted annual budgets, including cost-recovery principles,\nprotocols and procedures underpinning the budget;\n\n. all strategic plans;\n\n. all audit results;\n\n. other materials on request of the ROC for dclivery or inspection,\nnotwithstanding the opportunity for the ROC to gather more information\nthrough a hearing process..\n\nThe Chair shall invite the Board to vote on any recommendation delivered by the ROC\nwithout undue dclay. The ROC shall deliver a recommendation within the timeframe\ndesignated by the Board or its Chair, in consultation with the ROC Chair, and such timeframe\nshall be rcasonable in light of the global and conscnsus-based nature of the ROC. Should the\nROC have not delivered a recommendation within this timefraine, the ROC will be decmed io\nhave waived the possibility to deliver a recommendation. The Board's response to cach\nrecommendation shall be provided to the ROC without undue delay.\n15\n","contentLength":2355,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.383Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"Whenever the Board does not catirely adopt a recommendation dclivered by the ROC, the\nresults of thc Board's decision and the reasonable grounds for such decision shall be made\npromptly and publicly available, unless, as discussed with the ROC Chairs, such publication\nviolates confidentiality and privacy criteria.\nVI. B: LOCAL OPERATING UNITS\n\nArticle 32 Role\n\nLOUs ussist the Foundation in the implementation of the GLFEIS by conducting due diligence\non registrants seeking LEIs, assigning the LEIs consisient with GLEIS standards, maintaining\nthe LEls and associated reference data, and making those data publicly available.\n\nThe LOUs will provide the primary intcrlace for entities wishing to register for an LEL In\ntum, the Foundation shall provide support 1o the LOU operations when necessary, and\noversight to ensurc that the LOUs are conducting their {functions consistent with global\noperalional standards and protocols as administcred by the GLEIFE.\n\nThe GLEIF should provide that no LOU exploits its relationship with the system in a way\ncontrary to the broad public intercst and adheres to globally agreed LET standards as endorsed by\nthe ROC.\n\nArticle 33 Process for recognition and de-recognition\n\nIn accord with ROC principles and standards the Board shall specify in By-laws the criteria\nand the process under which LOUs shall be recognised and, as the case may be, under which\nthe recognition of a LOU shall be revoked.\n\nAny dispute arising out of the recognition or de-recognition ol a LOU shall be resolved by an\ninternal disputc resolution mechanism which will be specified in By-laws. In the absence of\nsuch a mechanism, the partics shall resort to the competent Swiss court to hear the dispute\npursuant to Swiss law.\n\nVII. REPRESENTATION, SIGNATURES AND INDEMNIFICATION\n\nArticle 34 Representation\n\n‘The Foundation shall in principle be ropresented by the Chair of the Board or any other\nrepresentative authorised by the Board.\n\n16\n","contentLength":1954,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.383Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"Article 35 Signaturcs\nExcept the Chair of the Board who has sole signatory power, the Members of the Board have\njoint signatory power at two,\nArticle 36 Indemnification\nAll persons involved in the administration, management or audit of the Foundation shall be\nheld rcsponsible for any loss or damage that they cause through willful or negligent violation\nof their duties. If several persons arc liable for loss or damage, each of them shall be held\njointly and sevcrally liable to the extent that such loss or damage can be attributed to them\npersonally owing to their own fault and to the circumstances.\nHowever, to the fullcst extent permitted by law, except cases of willful or criminal\nmisconduct, gross negligencc or reckless misconduct, the Foundation will indemnify any\nMember of the Board or any other body of the Foundation or the Ex officio Memnbers or ihe\nFounder (in particular regarding the appointing or removing of Board Members) (each an\n\"Indemnified Person\") (and that Indcminified Person's heirs, executors, administrators,\nassigns and any other legal representative of that Indemaificd Person) who was or is a party or\nis threatened lo be made a party to or is involved in (including as a wilness) any threatened,\npending, or completcd action, suil, proceeding or inguiry, whether civil, criminal,\nadministrative, or investigative, and whether formal or informal, including appeals, by reason\nof the fact that the Indemaified Person is or was a Membher of the Board or any other body of\nthe Foundation, or an ex officio Mcmber, or the Founder, or an organisation or constitucncy\nrepresented by a member of the Board or any other body of the Foundation or an ex officio\nMember for and against all expenses (including attorneys' fces), judgments, lings and amounts\npaid in settlement actually and reasonably incurred by that Indemnified Person or that\nIndemnificd Person's heirs, executors, administrators, assigns or legal rcpresentatives in\nconnection with that action, suit, procceding or inquiry, including appcals.\nThe Foundation may purchase and maintain insurance on behall of any Indemnified Person\nagainst any liability asserted against that Indemnified Person, whether or not the Foundation\nwould have the powcr to indemnify the Indennified Person against that liability under the\nprovisions of this Article or otherwise.\nVIlI. AMENDMIENT OF THE STATUTES, BY-LAWS, DISSOLUTION AND\nAPPLICABLE LAW\nArticle 37 Amendment of the Statutes\n17\n","contentLength":2463,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.383Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"The Board can request the Supervisory authority to amend the Statutes in accordance with\nArticles 85 and 86b of the Swiss Civil Code.\nSuch request regarding the amendment of the Statutes requires a three-fourths majority vote\nof all Board Members.\nThe purpose clause of the Statutes may be modified by the Founder in accordance with\nArticle 86a of the Swiss Civil Code.\nArticle 383 By-laws\nThe Board shall in due time and after consultation with the ROC fix the details of\norganisation of the Foundation in By-laws which shall be subject to the prior approval of the\nSupervisory Authority. Any subsequent modification of the By-laws shall also be submitted\nto the prior approval of the Supervisory Authority. ‘\nPrior to the submission of the By-laws or any modification thereof to the Supervisory\nAuthority, the ROC will deliver a recommendation.\nArticle 39 Dissolution\nIf the Foundation is unable to continue its activities, the Board shall consult with the ROC\nwho will deliver a recommendation. As the case may be, the Board shall subsequently notify\nthe Supervisory Authority of the situation.\nThe Foundation may be dissolved in accordance with Articles 88 and 89 of the Swiss Civil\nCode. The Founder shall carry out the liguidation of the Foundation.\nIn the event of liquidation of the Foundation, its remaining assets shall be entirely assignable\nto another public utility and tax exempt entity pursuing similar objectives to those of the\nFoundation. In no case shail the Foundation's assets be returned to the Founder or Board\nMembers or to any of their successors or assignees or be used in any way for their profit, be it\nin whole or in part.\nThe dissolution of the Foundation, to any degree, and particularly at the stage of liquidation,\nshall only be carried out with the express consent of the Supervisory Authority, the decision\nof which shall be based on a detailed written report.\nArticle 40 Applicable Law\nThe laws of Switzerland, in particular Article 80 et seq. of the Swiss Civil Code, shall apply\nto any matter not covered by the provisions of these Statutes.\n18\n","contentLength":2085,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.383Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":". * . . l ] )\nAnnex 1 : _ ' _ :\n' _Chai'fér of the Regulatory Oversight Committee (\"ROC Chartér\") of November 5, 2(')1'2 | _\n| | L . .fi)p\\g(; P . Notariat Ziirich (Altstadit)\n: P * B . T T\n: \"f?‘ Zfl\\:\\\\(}z\\ _._-_.'M-, Miller-Smit, Notar »\n","contentLength":239,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.383Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"\" CHARTER OF THE REGULATORY OVERSIGHT\nCOMMITTEE FOR THE GLOBAL LEGAL ENTITY |\n| IDENTIFIER (LEI) SYSTEM |\n- 5NOVEMBER 2012 =~ |\n","contentLength":129,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.383Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"Article 24 MEETIMES. ...ccoiiiiiiiiiiiirniin e e e et LD\nh V. B: THE EXTERNAL AUDITORS ..ot eernn s seeeraesnieee L3\nArticle 25 APPOIRTIIENt..... ... et een e 1O\nArticle 26 Audit Report ...ttt e 13\nV. C: THE SECRETARIAT AND THE CHIEF EXECUTIVE OFFICER................... 14\nArticle 27 The Sceretariat. ... s e L4\nArticle 28 Functions of the Secretariat................... 14\nArticle 29 The Chief Executive Officer ..ol 14\nVILA: INTERACTION WITII THE REGULATORY OVERSIGHT COMMITTEN 14\nArticle 30 Role oo sraes e aeeeaeceneens 1D\nArticle 31 Duty to give notice and provide documents to the ROC to enable ROC\nConsultations and Recommendations ..............coocociiiviioiiniiinnn e s 13\nVL B: LOCAL OPERATING UNITS ..o sees et sveareannns 1O\nArticle 32 ROle oot saa e renreesreas 1O\nArticle 33 Process for recognition and de-recognition..............cceiicnce 10\nVII. REPRESENTATION, SIGNATURES AND INDEMNIFICATION .................. 16\nArticle 34 Representation ... iereeeens 16\nArticle 35 Sigmatuires oot e e erasasaas e rves 1]\nArticle 36 Indemnification ... e, LT\n\nV. AMENDMENT OF THE STATUTES, BY-LAWS, DISSOLUTION AND\nArticle 37 Amendment of the Statutes..................ccciiin e 17\nArticle 38 By-Jaws...o e et anns 18\nArticle 39 DHSSOIUHIOM ...cccoiiiiiiiiiiii et ar e e se e emr e sreeenes L8\nArticle 40 Applicable Law ... et revnenan LS\n\n3\n","contentLength":1351,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.383Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"1 Charter of the Regulatory Oversight Committee\n\n2 For the\n\n3 o ~ Global Legal Entity Identifier System | :\n\n4 | | |\n\n5 Havingregardto: ,\n\n6 ' :\n\n7 (1) the call of the Heads of State and Government of the Group of Twenty on the Financial\n\n8 Stability Board (FSB) to take the lead in helping coordinate work among the regulatory\n\n9 community to prepare recommendations for the appropriate governance framework, '\n10 representing the public interest, for a global Legal Entity Identifier (LEI) (Cannes - -\n11 . Summit, November 2011, “Declaration — Building Our Common Future: Renewed\n12 . Collective Action for the Benefit of All”); and :\n13 . '\n14 (2) the endorsement by the Heads of State and Government of the Group of Twenty of the\n15 FSB recommendations regarding the framework for development of a global LEI system\n16 for parties to financial transactions, with a global governance framework representing the\n17 public interest (Los Cabos Summit, June 2012); and\n18\n19 Recognizing the need to develop and maintain for the broad public good a Global LEI\n20 System that is to be used: (a) by authorities of any jurisdiction or financial sector to, assess\n21 systemic risk and maintain financial stability, conduct market surveillance and enforcement,\n22 supervise market participants, conduct resolution activities, prepare high quality financial\n23 data, and to undertake other official functions; and (b) by the private sector to support\n24 improved risk management, increased operational efficiency, more accurate calculation of\n25 exposures, and other needs.\n26\n27 We, the Finance Ministers and Central Bank Governors of the Group of Twenty, and the\n28 Financial Stability Board have set forth this Charter for the Regulatory Oversight Committee\n29 (ROC) of the Global Legal Identifier System. The Global LEI System is composed of the\n30 ROC together with an operational component, consisting of the LEI foundation (or equivalent\n31 legal form) operating the Central Operating Unit (COU), and the federated Local Operating\n32 Units (LOUs) providing registration and other services. T _\n33 '\n34 1. Mission ;\n35 The mission of the ROC is to uphold the governance principles of and to oversee the Global\n36 LEI System, in the broad public interest, in accordance with: '\n37 a) the Global LEI System High Level Principles and FSB recommendations, as endorsed\n38 by the Heads of State and Government of the Group of Twenty (Los Cabos, June 2012)\n39 (Annex A and B);\n40 b) any additional principles adopted by this ROC; and -\n41 ¢) any amendment to the provisions of this Charter. 7\n42 In furtherance .of this mission, the ROC is to take appropriate action to protect the public ‘\n43 interest through regulatory oversight of the Global LEI System.\n\n1\n","contentLength":2765,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.383Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"44 2, Objectives and responsibilities of the ROC\n45 a) In protecting the broad public interest, the objectives of the ROC are to ensure:\n- 46 (1)° open and free access to publicly available data from the Global LEI System,\n47 including the following: .\n48 i data should be non-proprietary, with no bundling of services, or\n49 restrictions on access, usage, or redistribution; _ :\n50 ii. - all public data should be readily available on a continuous basis, easily\n51 : and widely accessible using modern technology, and free of charge;\n52 iii. confidential data should be safeguarded and with due regard for any\n53 . applicable data protection legislation;\n54 : iv. data and operating processes should not be subject to any type of -\n55 : intellectual property restrictions, except those judged necessary by the\n56 A . ROC for protecting the broad public interest;\n57 V. restrictions should not be placed on a registrant on the use of its own\n58 LEL |\n59 (2) open access to obtaining an LEI, including: - o\n60 1. by providing that any entities required, or eligible, to obtain an LEI are\n61 able to acquire one under open and non-discriminatory terms;\n62 - . ii. . by providing that fees, where and when imposed by the COU, .are set '\n63 on a non-profit cost-recovery basis under the premise that the\n64 operational model of the COU is efficient and avoids excessive costs\n65 and, that where possible, a parallel arrangement holds for the LOUs; -\n66 iii. by providing that the intellectual property necessary for or associfated\n67 . with the operation of the Global LEI System is held in a way that\n68 facilitates achievement of the High Level Principles. _ _\n69 (3) thatno entity involved in the Global LEI System exploits its relationship with\n70 the system in a way contrary to the broad public interest;\n71 4) that the Global LEI System meets broad public and private sector\n72 requirements, including:\n73 : i. © ensuring the uniqueness, consistency, exclusivity, aécuracy, reliaBiIity,\n74 timeliness of access, portability, and persistence of the LEI code and\n75 reference data; ‘ o :\n76 ii. evaluating continually the relevance of existing™ standards, and\n77 ' ' proposing new or adapting existing standards for the Global LEIX\n78 System that serve the broad public interest or reflect changes in\n79 financial markets or other relevant areas as required;\n80 ili. promoting the use and scope of the Global LEI System to expand the\n81 ’ collective benefit from widespread adoption; and :\n2\n","contentLength":2500,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.383Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"82 : iv. allowing use of local languages and character sets in registration, as\n83 well as allowing access to the Global LEI System in a common\n84 language and character set,\n85 b) . In carrying out its mission and objectives, the ROC has the following respohsibilities |\n86 and authorities: ' _ .\n87 . . (1) to be the ultimate authority for oversight of the Global LEI System, including ,\n88 guidance, standards, high level plans, policies, and protocols. The capacity to\n89 ' review and approve all decisions relating to the governance and strategy of\n90 , the global LEI foundation operating the COU; .\n91 (2) o facilitate the establishment of, and to designate the global LEI foundation\n92 (or body of equivalent legal form) as the legal entity that operates the COU;\n93 (3) tooversee standards and general policies for the Global LEI System to ensure\n94 that they are in the broad public interest, including, but not limited to:\n95 -1 standards for LEI reference data and for other aspects of the operations .\n96 - of the Global LEI System; :\n97 ii. standards for participation of LOUs in the Global LEI System;\n98 ik cost-recovery principles, protocols, and procedures for the ‘COU\n99 budget formation; : :\n100 ' iv. material contracts review to ensure that the objectives in section 2 a) . _\n101 ' are respected; and _ A\n102 , V. standards for business continuity, disaster récovery and automated\n103 ~ system safeguards. o ‘ ’ '\n104 (4) to request and receive independent audits of the Global LEI System for\n105 financial control, best business practices, and.data quality standards;\n106 (5) to appoint the initial Board of Directors of the global LEI foundation operating\n107 the COU, to review the appointment and continuance of Directors, and to\n108 request (or direct, if consistent with the governing law of the global LEI :\n109 foundation) removal of Directors for cause, according to public-interest\n110 protection criteria_established by the ROC to be reflected in the governing\n111 ' documents of the global LEI foundation; ‘ :\n112 (6) to appoint, public or independent Directors of the global LEI foundation\n113 opetating the COU from outside of the regulatory community with special\n114 powers, determined by the ROC and to the extent permissible under the law\n115 governing the LEI foundation, who as individuals are to act in the broad public\n116 interest, (pursuant to the criteria established by the ROC and reflected in the '\n117 governing documents of the global LEI foundation); _\n118 (7) to issue guidance to the COU or other parts of the Global LEI System to\n119 protect the broad public interest as expressed in the High Level Principles or\n120 in this Charter; '\n3 .\n","contentLength":2703,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.383Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"121 @ to monitor the performance of the Global LEI System, through inspections,\n122 hearings, reports and other means;\n123 (9) to promote a high level of transparency in the operation of the Global LEI\n124 System; , ' ' ,\n125 (10) to establish or appoint such special advisory, technical, or professional\n126 committees, working groups, or panels, as may be useful in carrying out the\n127 mission, objectives, and responsibilities of the ROC. The membership of such\n128 committees, working groups, or panels may be composed of Members of the\n129 R ROC, other persons, (including from both the regulatory community or private\n130 sector), or both; '\n131 - (11) to conmsider establishment of an appropriate framework for mediating or\n132 ' resolving disputes; '\n133 (12) to adopt, in addition to the provisions of this Charter, such rules or procedures\n134 as may be necessary to carry out the mission, objectives and responsibilities of _\n135 the ROC; and '\n136 (13) to undertake any such other functions and actions as may be necessary and _\n137 permissible to carry out the mission, objectives, and responsibilities of the\n138 ROC. _ :\n139 ' |\n140 3. Members ' '\n141 . a) The following are eligible to be a Member of the ROC:\n142 (1) any public sector authority and jurisdiction including regulatory and\n143 supervisory authorities and central banks;\n144 (2) - public international financial institutions; and |\n145 3) ifitemational public sector standard setting, regulatory, supervisory, and\n146 central bank bodies and supranational authorities. '\n147 on condition that they are dedicated to working actively for the broad public interest\n148 in accordance with the Global LEI System High Level Principles and to working _\n149 actively towards the objectives specified in this Charter. The public international\n150 financial institutions that are so dedicated participate as Members in accordance with\n151 their respective legal and policy frameworks.\n152 .b) Membership criteria may be reviewed every 3 years, or earlier under circumstances\n153 where needs for review are identified, by the Plenary in the light of the ROC’s\n154 mission, objectives and responsibilities.\n155 ¢ Recognising the need to support effective decision making and thus to contain the\n156 number of decision-making Members, jurisdictions are invited to ensure co-ordination\n157 among authorities that meet the eligibility criteria.\n158 d) In the event that the number of eligible members wishing to join the ROC reaches\n159 such a size that makes decision-making impractical, Plenary Members should review\n160 whether new provisions are needed to limit Plenary Membership.\n\n4\n","contentLength":2657,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.383Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"161 4. Commitments of Members\n\n162 Assent to the Charter means that a Member is to: ,\n\n163 a) uphold the High-Level Principles and goals set forth in the Charter to protect the\n\n164 broad public interest in relation to the Global LEI System;\n\n165 b) participate actively in the work of the ROC; and\n\n166 ¢ support the introduction of the Global LEI System for official or international\n\n167 identification purposes.\n\n168 : ' | .\n\n169 5. Observers . '\n\n170 a) Public authorities and jurisdictions, public international financial institutions, and\n\n171 international public sector standard setting, regulatory, supervisory, and central bank\n\n172 bodies and supranational authorities, as defined in 3 a) above, that support the High\n\n173 + Level Principles and wish to be informed of the proceedings of the ROC, but do not\n\n174 wish to participate actively in the decision making and governance process may\n\n175 become Observers. ' '\n\n176 b) ° An Observer may attend meetings of the Plenary and participate in the ROC in a\n\n177 manner to be determined by the Plenary, Executive Committee, or any other groups,\n\n178 committees, working groups or panels that invite the Observer.\n\n179 :\n\n180 An Observer may not participate in the decision making of the Plenary or the Executive\n\n181 Committee. . :\n\n182\n\n183 6. Structure - K\n\n184 The ROC is composed of the following: ‘ :\n\n185 a) the Plenary; ' : .\n\n186 b) the Executive Committee;\n\n187 ¢) - the Committee on Evaluation and Standards; and : -\n\n188 d) other committees, working groups, or panels as provided for in Section 2 (b) (10)\n\n189 above.\n\n190 :\n\n191 7. Decision making ' '\n\n192 a) Decisions by the Plenary, Executive Committee, and any other groups, committees, or\n\n193 bodies established by the ROC should be taken by consensus where possible.’\n\n194 b) Members of the ROC have the duty to work towards consensus.\n\n195 ¢) The Chair has the duty to seek as broad a consensus as possible.\n\n196 d) Members who have stated an objection have the right to delay a decision for a fixed,\n197 - shoxt period and ask the Chair to seek an alternative solution. '\n\n' 5\n","contentLength":2115,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.383Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"198 ) Voting should only occur in exceptional circumstances where consensus cannot be\n\n199 . reached using the procedures outlined above. For such an eventuality, the ROC is to\n\n200 develop voting procedures with a geographically balanced majority for adopting\n\n201 decisions in the event that consensus cannot be reached for either or both the Plenary\n\n202 - and the Executive Committee. : o\n203 : o\n\n204 8. Plenary Membership and Responsibilities : :\n205 a) The Plenary consists of one designated representative of each Member of the ROC. ,\n206 b) The Plenary is the ultimate decision-making body of the ROC. -\n207 ¢) The Plenary is presided over by the Chair of the ROC. :\n208 d) The Plenary: _ ‘ '\n\n209 © (1) decides on the manner in which the Plenary conducts its affairs; '\n210 (2) approves the work program of the ROC; . ' '\n211 . (3) oversees the standards and general policies for the Global LEI System, to\n212 ensure that they protect the broad public interest, taking account of the :\n213 ~ analysis and recommendations of the Executive Committee; ‘\n\n214 . (4) exercises oversight of the adherence of the Global LEI System to the High\n\n215 Level Principles and the goals specified in this Charter, and promotes\n\n216 . transparency throughout the system; '\n\n217 (5) reviews membership criteria every 3 years or earlier where needs for review\n\n218 are identified, in the light of the ROC mission, objectives and responsibilities;\n\n219 (6) appoints the Chair, the Vice Chair(s), and the Executive Committee; .\n\n220 (7) provides the Executive Committee with specific dedicated responsibilities and\n\n221 powers to take forward the work of the ROC and assigns responsibility for\n\n222 decisions on operational oversight issues to the Executive Committee;\n\n223 '. (8) facilitates the establishment of, and designates the global LEI foundation (or\n\n224 body of equivalent legal forin) as the legal entity that operates the COU and\n\n225 terminates this designation; , .\n\n226 (9) appoints the initial Board of Directors of the global LEI foundation operating\n\n227 the COU and reviews appointment and continuance of Directors, and\n\n- 228 thereafter requests removal of Directors, as specified in 2 (b) (5) of this\n\n229 Charter, taking due account of the recommendations of the Executive\n\n230 : Committee;\n\n231 (10) appoints, public or independent Directors as foreseen in section 2 (b) (6);\n\n232 (11) hears at least twice a year, and as deemed necessary by the Plenary, a report '\n233 from the Chair of the Board of Directors of the global LEI foundation\n\n234 ' operating the COU; _ '\n\n235 (12) establishes the Committee on Evaluation and Standards and appoints its chair; -\n\n: ) _ .\n","contentLength":2694,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.383Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"236 - (13) establishes other committees, working groups and panels, as necessary,\n237 including membership and responsibilities;\n238 . (14) appoints the Secretariat;\n239 (15) reviews and approves any amendments to this Charter; and\n240 (16) decides on any other matter governing the business and affairs of the ROC.\n241 9. Plenary Representation and Attendance : '\n\n: 242 a) All Members are entitled to attend and participate in the Plenary. ' '\n243 b) The Chair of the ROC presides over the_Plenary.\n244 ¢ The Plenary is expected to meet at least 2 times each year.\n245 ' ,\n246 10. Executive Committee '\n247 a) An Executive Committee is established and composed of an initial maximum of\n248\" * twenty-three (23) Members selected by, and from among the Plenary Membership.\n249 Regional Executive Committee Members are to be selected by and from the Plenary\n250 . Members for that region. Members representing global public international financial\n251 _ institutions and standard setting bodies are to be selected by the Plenary.\n252 b) Membership of ‘the Executive Committee is to be balanced jurisdictionally and\n253 regionally. The initial composition of the Executive Committee is to consist of a -\n254 maximum of five (5) Members from at least 2 jurisdictions in each of the following\n255 - regions: North America (including Mexico and the Caribbean); Europe (including the\n256 Commonwealth of Independent States); Asia (excluding the Middle East); and Central\n257 - ~and South America, Africa, Oceania, and the Middle East. In addition, up to three (3)\n258 Members may be appointed to represent global public international financial\n259 ' institutions and standard setting bodies. The maximum size and composition of the\n260 Executive Committee is to be reviewed every 3 years, in accordance with criteria to\n261 be developed and approved by the Plenary. The Chair and the Vice Chair(s) are to be\n262 appointed from the Membership of the Executive Committee.\n263 «¢) Members of the Executive Committee are to be appointed for a maximum 3 year\n264 térm, subject to renewal. Initial appointments may include some shorter term\n265 appointments to facilitate rotation in each region upon the decision of a region.\n266 d) The Executive Committee is to take forward the work of the ROC including decisions\n267 on operational oversight issues, under specified delegated responsibilities and powers\n268 - provided by the Plenary.\n269 = e) The Executive Committee may establish working groups and panels as needed to take\n270 forward the work of the Executive Committee. ’\n271 ) In addition to its delegated responsibilities, the duties of the Executive Committee\n272 include the following: . -\n273 (1) providing regular information and recommendations to the Plenary to keep the\n274 Plenary fully engaged and capable of action;\n\n. - |\n","contentLength":2838,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.383Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"275 (2) informing the Plenary on the fulfilment of the delegated oversight |\n276 responsibilities provided to the Executive Committee;\n277 (3) monitoring and guiding the progress of the ROC’s ongoing work;\n278 (4) preparing options for decision for matters reserved to the Plenary; c\n279 (5) conducting ongoing oversight of the Global LEI System to monitor adherence\n280 to the High Level Principles and other agreed principles, policies and\n281 standards to protect the broad public interest. In furtherance of this mission the\n282 Executive Committee shall hear at least twice a year, and as deemed necessary\n283 by the Executive Committee, a report from the Chair of the Board of Directors\n284 of the global LEI foundation operating the COU; :\n285 (6) analysing and developing recommendations for principles, standards and\n286 general policies for the Global LEI System, ensuring that they serve the broad\n287 public interest, including, but not limited to:\n288 i. standards for LEI reference data and for other aspects of the Global\n289 ' LEI System’s operations;\n290 il. standards for participation of LLOUs in the Global LEI System;\n291 iil. cost-recovery principles, protocols, and procedures for the COU\n292 budget formation; ,\n293 iv. material contracts review to ensure that the objectives in section 2 a)\n294 are respected; and . _ 4\n295 V. standards for business continuity, disaster recovery, and automated\n296 : system safeguards. :\n297 7 reviewing and commissioning work from the Committee on Evaluation and\n298 ' Standards or other committees, working groups and panels and co-ordinating\n299 work across those groups; _\n300 (8) requesting and receiving independent audits of the system for: financial\n301 control, best business practices, and data quality standards;\n302 9 performing on site reviews of the COU, subject to COU security\n303 requirements;\n304 (10) requesting on as needed basis information from the Directors of the global\n305 LEI foundation operating the COU;\n306 (11) issuing guidance t0 the COU or other parts of the Global LEI System to\n307 protect the broad public interest as expressed in the High Level Principles or\n308 in this Charter;\n309 (12) considering establishment of an appropriate framework for mediating or\n310 resolving disputes;\n311 (13) overseeing the work of the ROC Secretariat;\n312 (14) preparing the Plenary meetings, including making recommendations as\n313 . appropriate in order to allow the Plenary to efficiently fulfil its mandate; and\n8\n","contentLength":2507,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.383Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"314 (15) taking forward, after consultation and consistent with the directions of the -\n315 . - Plenary, any other work necessary for the ROC to meet its mandate. ,\n316 | - :\n317 11 Committee on Evaluation and Standards (CES)\n318 The CES has the following responsibilities to support the regulatory oversight functions of\n319 the ROC and the Executive Committee: _\n320 a) to evaluate the adequacy of existing standards and protocols in the light of the High\n321 -~ Level Principles and other principles adopted by the ROC and that serve the' broad\n322 ° public interest; : :\n323 b)) to proiaose revised or additional standards, or protocols as necessary; .\n324 ¢) torecommend to the Executive Committee the development of additional standards and\n325 . protocols or the modification of existing standards and protocols as necessary; and\n326 d) to perform any other tasks and functions as requested by the Plenary or Executive\n327 - Committee. : :\n328 Members of the CES do not necessarily need to be the individuals or organisations '\n329 participating in the ROC. . ' .\n330 The CES reports to the Executive Committee on a regular basis and to the Plenary when :\n331 requested. L ‘\n332 o .\n333 12, Chair\n334 &) The Chair and the Vice Chair(s) are appointed by the Plenary from the Membership of\n335 . the Executive Committee for a term of 2 consecutive years extendable for a maximum\n336 of one-year. .\n337 b) \" The Chair convenes and chairs the méetings of the Plenary and of the Executive\n338 Committee. : .\n339 ¢ The Chair is the principal spokesperson for the ROC and represents the ROC\n340 externally. The Chair should be informed of all significant matters that concern the\n341 ROC. o : o\n342 d) The Chair is to take all decisions and act as necessary to achieve the objectives of the '\n343 - ROC, in accordance with directions given by the Plenary or the Executive Committee.\n344 o) The Chair is to act in the best interests of the ROC and ROC Membership. ' .\n345 ) The Chair has a duty to seek as broad a consensus as possible. '\n346 g) The Chair is to be supported by up to two Vice-Chair(s), appointed by the Plenary\n347 . from the Membership of the Executive Committee for a term concurrent to the Chair. '\n348 The Chair and Vice-Chair(s) are to be from different geographic regions.\n349 ,\n. { . . )\n9 .\n","contentLength":2323,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.383Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"350 13. Secretariat\n351 a) = The Plenary is to appoint a Secretariat to support the ROC, taking account of a\n352 recommendation from the Chair and the Executive Committee.\n353 b) The Secretariat is directed by the Chair of the ROC, on behalf of the Plenary and\n354 Executive Committee. :\n355 ©) The duty of the Secretariat is to support the work of the ROC. The Secretariat does\n356 not participate in any ROC decision making. _ :\n357 d) The Secretariat is to maintain and publish a list of Plenary Members.\n358 ) The initial Secretariat is to be provided through the establishment of an agreement :\n359 with an existing public international financial institution, that could help the ROC to .\n360 mobilise and organise the necessary secretariat services during the first 3 years of\n361 formation. . S ‘\n362 D) On an ongoing basis, the costs of the Secretariat are 1o be provided from registration\n363 fees levied on registrants consistent with modalities to be established by the Plenary.\n364 g) The Plénary is to review all aspects of Secretariat arrangements 3 years after the '\n365 formation of the ROC. .\n366 ' ' _ .\n367 14. Funding of the ROC :\n368 On an ongoing basis, the funding of the ROC is to be provided from registration fees levied -\n369 on registrants consistent with modalities to be established by the Plenary.\n370 -\n371 15. Establishment - . ' .\n372 a) The ROC is to be formed following endorsement of this Charter by the Group of\n373 Twenty and the FSB, and there being: : _ .\n374 ‘ '\n375 (1) at least eleven (11) authorities assenting to this Charter, including: '\n376 ' '\n377 (2) at least three (3) from each of three regional groupings: North America\n378 (including Mexico and the Caribbean); Europe (including the Commonwealth\n379 - of Independent States); and Asia (excluding the Middle East); and '\n380 - ‘\n381 (3) at least two (2) from a regional group comprising Ceniral and South America,\n382 Africa, Oceania, and the Middle East; and :\n383 | . |\n384 (4) of those authorities assenting within each of the four regions, at least two (2) :\n385 . deriving from different jurisdictions. : -\n386 : '\n387 b) Prior to the formation of the ROC and appointment of the Chair of the ROC by the\n388 Plenary, assent to the Charter is to be made by letter from eligible authorities to the\n389 Chair of the FSB. :\n390\n' _ 0 '\n","contentLength":2344,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.383Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":". PREAMBLE\n\nWhereas the Heads of State and Government of thc Group of Twenty called at the\n2011 Cannes Summit on the Financial Stability Board (\"FSB\") to takc the lead in helping,\ncoordinate work among the regulatory commmunity to prepare reconunendations for the\nappropriate governance framework, represcnting the public interest, for a global Legal Entity\nTdentifier (\"LLEI\") in the form of a reference code o uniquely identify legally distinct entities\nthal enpage in financial transactions;\n\nWhereas the Heads of State and Government of the Group of Twenty endorscd at the\n2012 Yos Cabos Summit the FSB rccommendations reparding the framework for\ndevclopment of a Global LEI System (\"GLEIS\"} for parties to financial transactions, with a\nglobal governance framework representing the public interest;\n\nWhereas the Finance Ministers and Central Bank Governors of the Group of Twenty\nand the FSB have recognised the need to develop and maintain for the broad public good a\nGLEIS thal is to be used:; (a) by authoritics of any jurisdiction or financial sector o assess\nsystemic risk and maintain financial stability, conduct market surveillance and enforcement,\nsupervise market pariicipants, conduct resolution activitics, prepare high quality financial\ndata, and to undertake other official functions; and (b) by the private sector to support\ntmproved risk management, increased operational ciliciency, more accurate calculation of\nexposures, and other needs;\n\nWhereas, according to the Charter of the Regulatory Oversight Committec (\"RQC\"),\nthe GLEIS shall be composed of the ROC together with an operational component, consisting\nof the Global LEI Foundation (\"GLEIF\"} operating the Central Operating Unit (\"COU™), and\nederated Local Operating Units (\"LOUs\") providing registration and other services;\n\nWhereas the ROC's mission is to uphold the governance principles of and to oversee\nthe GLEIS, in the broad public intcrest, in accordance with: (a) the GLEIS High Level\nPrinciples and the ROC Charter as well as (b) any additional principles adopted by the ROC\nto serve the public interest in the GLEIS and (c) any amendment 1o the provisions of the ROC\nCharter; in furtherance of this mission, the ROC is to take action to protect the public interest\nthrough regulatory oversight of the GLEIS;\n\nWhereas, under the supcrvision of the ROC, the GLEIF operating the COU will\nconstilute the contracting and operational body of the GLEIS; it will support the application\naround the world of uniform operational standards and protocels set by the ROC and support\nthe maintenance of a 'logically' centralised databasc of identifiers and corresponding reference\ndata;\n\nWhereas the FSB, an association undcr Swiss law, acting as the I'ounder of the\nGLEIF, hereby resolves the constitution of the GLEIF and adopts its Statutes as follows:\n\n4\n","contentLength":2838,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.383Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"391 ¢ On formation of the ROC, and appointment of the Chair of the ROC by the Plenary,\n392 assent to the Charter is to be made.by letter from eligible authorities to the Chair of\n393 the ROC. Membership becomes active once the Chair has provided confirmation.\n394 ' ‘\n395 d) A Member may terminate its Membership by letter to the Chair of the ROC.\n396\n397 e A request for Observer status is to be made by letter from eligible authorities to the\n398. . Chair of the FSB prior to the formation of the ROC, and thereafter by letter to the\n399 Chair of the ROC.\n400 16. Access to information | :\n401 The ROC is to have access to documents of the global LEI foundation operating the COU as\n402 well as those of the COU. The non-public information contained in these documents is to be\n403 treated as confidential information by the Members of the ROC. Provisions regarding such\n404 . access are to be reflected in by-laws of the LEI foundation. .\n405 17. Confidentiality - |\n406 The ROC Members are to treat all non-public information and documents, provided to or .\n407 obtained by them under or in connection with LEI oversight activities and this Charter, as '\n408 confidential. The Members are to ensure that confidential information provided to them in the\n409 context of the regulatory oversight arrangements is to be used only for the oversight of the\n410 Global LEI System, and is not to be used by them for any other purpose, including in their\n411 capacities as users of the LEI services, provided that the foregoing does not prejudice their\n412 responsibilities under national laws or regulatory requirements.\n413 :\n414 18. Amendment Clause |\n415 . Amendment of any of the provisions of this Charter may be proposed by the Executive\n416 Committee or Plenary and if adopted by the Plenary modifies this Charter. Such adoption is\n417 subject to the decision-making framework for the ROC, or by specific procedures to be :\n418 defined by the Plenary.\n419 19. Review Clause : _\n420 - The ROC may review the Charter as necessary, in an appropriate manner. The review may\n421 cover all aspects of the governance arrangements for the Global LEI System. An initial\n422 review is to take place by no later than October 2017. By this date, the Plenary is to examine\n423 this Charter on the basis of a report from the Executive Committee and is to determine\n424 whether the mission and organization of the ROC need to be reviewed.\n. 11\n","contentLength":2448,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.384Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"425 20. Legal Effect , : :\n426 This Charter does not create any legal rights or obligations or modify or supersede any\n427 national or international laws or regulatory requirements in force in any applicable\n428 jurisdiction, or applying to, any of the Members. A '\n429 : .\n430 Nothing in this Charter is to require or to be deemed to require any of the Members to act in a\n431 manner which amounts to or may amount to violation of any of the provisions of any. such\n432 . national or international laws, legal frameworks, or regulatory requirements, or to prejudice\n433 or affect the exercise of any of their rights and discretions thereunder.\n434 :\n435 By endorsing or assenting to this Charter or becoming a Member of the ROC, no Member\n436 waives any immunity from suit or privilege to which it may otherwise be entitled and no\n437 Member submits to the jurisdiction of any court or arbitral body that would not otherwise\n438 have jurisdiction. : . ‘\n439 : oo '\n440 21. Annexes\n441 :\n442 The Annexes to this Charter, are considered part of the Charter:\n443 ‘\n444 Annex A: Global LEI System High Level Principles. :\n445 Annex B: Annex B: Recommendations for the development and implementation of the\n446 Global LEI System. ' \"\n447 '\n448\n\n' 12 _\n","contentLength":1263,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.384Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"449 Annex A: Global LEI System High Level Principles : ’\n\n450 , '\n\n451 _ - :\n\n452 1. The Global LEI system should uniquely identify participants to financial transactions.\n\n453 : - :\n\n454 2. The LEI system should meet the requirements of the global regulatory community for\n\n455 accurate, consistent and unique entity identification. )\n\n456 :\n\n457 3. The LEI system should be designed in a manner that provides benefits to financial\n\n458 market participants. _ ‘\n\n459 : - ] . . '\n\n460 4. Flexibility must be built into the global LEI system to provide the capability for the\n\n461 system to expand, evolve, and adapt to accommodate innovations in financial\n\n462 markets. :\n\n463 | '\n\n464 5. The LEI system should not be “locked-in” with a particular service provider for any\n\n465 key system functions or processes. The principles of competition should be ensured\n\n466 on both global and local levels where appropriate.\n\n467 ,\n\n468 6. The global LEI system should support a high degree of federation and local\n\n469 implementation under agreed and implemented common standards.\n\n470 : :\n\n471 7. The LEI system should meet evolving requirements of both the regulatory community\n\n472 . and industry participants in terms of information content, scope of coverage,\n\n473 timeliness and availability. :\n\n474 .\n\n475 8. The LEI Regulatory Oversight Committee should have the responsibility of upholding\n\n476 the governance principles and oversight of the global LEI system functioning to serve\n\n477 the public interest. The Committee has the ultimate power and authority over the\n\n478 global LEI system. :\n\n479 : .\n\n480 9. The mission, role and responsibilities of the ROC shall be specified by the global LEI\n\n481 Regulatory Oversight Committee Charter, which shall establish the Committee. :\n\n482\n\n483 10. Participation in the global LEI Regulatory Oversight Committee shall be open to all\n\n484 authorities subscribing to the High Level Principles and to the objectives and\n\n485 commitments in the Charter. |\n\n486\n\n487 11. The LEI Central Operating Unit should have the mission and role to ensure the\n\n488 application of uniform global operational standards and protocols set by the ROC and\n\n489 act as the operational arm of the global LEI systein. It shall be established as a\n\n490 foundation or legal equivalent. .\n\n491 : :\n\n492 12. The LEI Central Operating Unit should have a balanced representation of industry\n\n493 participants from different geographic areas and sectors of economy. Its Board of\n\n494 Directors should be selected from industry representatives, plus independent\n\n495 participants. .\n\n496 ) : E\n: 13\n","contentLength":2614,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.384Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"497 13. The LEI system should allow the local provision by Local Operating Units of all LET\n498 functions which the ROC determines are not required to be centralised. .\n499\n500 . 14. The LEI system should promote the provision of accurate LEI reference data at the .\n501 ‘ local level from LEI registrants and ensure global uniqueness of the registrants.\n502\n503 15. Any global universal intellectual property rights should belong to the global LEI\n504 system.\n505 .\n14\n","contentLength":470,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.384Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"506 Annex B: Recommendations for the development and implementation of the Global LEX\n507 : System '\n508 Recommendation 1 _ : ' '\n509 | SETTING UP A GLOBAL LEI SYSTEM The FSB strongly supports the development and\n510 | implementation of a global LEI system that uniquely identifies participants to financial\n511 | transactions. , S\n512 Recommendation 2 ' | ‘ .\n513 GLQBAL REGULATORY COMMUNITY REQUIREMENTS The LEI system should | -\n514 | meet the requirements of the global regulatory community (including supranational\n515 | organisations). The potential benefits of the LEI include: to support authorities in fulfilling\n516 | their mandates to assess systemic risk and maintain financial stability; conduct market |\n517 | surveillance and enforcement; supervise market participants; conduct resolution activities;\n518 | prepare high quality financial data and undertake other regulatory functions.\n519 Recommendation 3 : . '\n520 | GLOBAL LEI SYSTEM GOVERNING DOCUMENTS Global LEI system High Level\n521 | Principles set out the principles and commitments that specify and define the governance and\n522 | structure of the global LEI system. A global LEI Regulatory Oversight Committee Charter\n523 | should specify the mission, role and responsibilities of the Committee as well as the process |\n524 | for its establishment. Support for the High Level Principles agreement and Charter will\n' 525 | indicate a desite to participate in the global LEI system.\n\n526 Recommendation 4\n527 | SUPPORT OF FINANCIAL MARKET PARTICIPANTS The LEI system should be\n528 | designed in a manner that provides benefits to financial market participants. S\n529 Recommendation 5 '\n530 | SYSTEM FLEXIBILITY Flexibility must be built into the global LEI system to provide the\n531 | capability for the system to expand, evolve and adapt to accommodate innovations in\n532 | financial markets. It must also allow the seamless introduction of new participants. To these\n533 | ends, critical software and other relevant elements must be' defined and made publicly\n534 | available without any licensing, intellectual property or similar restrictions under open source\n535 | principles. The LEI should be portable’ within the global LEI system. '\n536 Recommendation 6 . _\n537 | COMPETITION AND ANTI-TRUST CONSIDERATIONS The LEI system shotild be\n538 | designed to ensure that it is not “locked-in” with a particular service provider for any key\n539 | system functions or processes, and that the principles of competition are ensured on both\n540 | global and local levels where appropriate. The governance framework should provide\n\nv In this context a portable LEI means that the code could be transferred from one LOU to another LOU. . 7\n\nThis may be necessary, for example, in case of the LEI being obtained originally from a foreign LOU before a\n\nlocal LOU was established or if an entity changed its legal address or headquarters, etc.\n\n. 15\n","contentLength":2914,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.384Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"541 | safeguards to ensure that competition principles and anti-trust considerations are upheld. The\n542 | local implementation of the global LEI system should meet local anti-trust requirements. .\n543 Recommendation 7\n544 | FEDERATED NATURE OF THE LEI SYSTEM The global LEI system should support a\n545 | high degree of federation and local implementation under agreed and implemented common\n546 | standards.\n547 Recommendation 8 ' :\n548 | SCOPE OF COVERAGE Eligibility of ‘legal entities’ to apply for an LEI should be\n549 | broadly defined, in order to identify the legal entities relevant to any financial transaction. No '\n550 | more than one LEI shall be assigned to any legal entity. \"\n551 Recommendation 9 '\n552 | LEI REFERENCE DATA AT SYSTEM LAUNCH The official name of the legal entity,\n553 | the address of the headquarters of the legal entity, the address of legal formation, the date of _\n554 | the first LEI assignment, the date of last update of the LEI, the date of expiry, business\n555 | registry information (if applicable), alongside a 20 digit alphanumeric code should form the\n556 | basis for the global system at the launch of the global LEI initiative. For entities with a date\n557 | of expiry, the reason for the expiry should be recorded, and, if applicable, the LEI of the '\n558 | entity or entities that acquired the expired entity. _\n559 -Recommendation 10 '\n560 | REVIEW OF SCOPE OF COVERAGE AND REFERENCE DATA The Regulatory\n561 | Oversight Committee should undertake regular reviews of the scope and extent of coverage\n562 | of the LEI to reflect emerging regulatory and market requirements for the LEI use according\n563 | to an agreed schedule. The Regulatory Oversight Committee should undertake regular\n564 | reviews of the LEI reference data according to a set schedule to monitor the required changes,\n565 | additions, retirements and modifications.\n566 Recommendation 11 : )\n5 67 STANDARDS FOR THE LEI SYSTEM The LEI system should meet, to the degfee\n568 | possible, evolving requirements of both the regulatory community and industry participants\n.569 | in terms of information content, scope, timeliness and availability. The Regulatory Oversight\n570 | Committee is responsible for the final determination for any standards for the LEI to be\n571 | utilised in the global LEI system. When proposing areas for the development of new\n572 | standards, the Regulatory Oversight Committee should strongly consider utilising existing\n573 | standard setting organizations to develop such standards, provided that such organizations\n574 | incorporate the requirements for the standards as determined and communicated by the\n575 | Regulatory Oversight Committee. :\n576 Recommendation 12 . B\n| 577 | LEI REFERENCE DATA ON OWNERSHIP The FSB LEI Implementation Group should\n578 | as soon as possible develop proposals for additional reference data on the direct and ultimate\n' _16- )\n","contentLength":2910,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.384Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"579 | parent(s) of legal entities and relationship or ownership data more generally and to prepare\n580 | recommendations by the end of 2012. The group should work closely with private sector\n581 | experts in developing the proposals.\n582 Recommendation 13 :\n583 | LEI OPERATIONAL AND HISTORICAL DATA The LEI system should maintain high\n584 | quality records that retain relevant information on amendments (query, add, modify or delete :\n585 . | of any data element) to data items as well as additional data to facilitate the surveillance and\n586 | control of the system by the COU where appropriate. :\n587 Recommendation 14 | ,\n588 | CENTRAL OPERATING UNIT The mission and role of the Central Operating Unit should\n589 | be to ensure the application of uniform global operational standards and protocols that deliver\n590 | global uniqueness of the LEI, seamless access to the global LEI and to high quality reference\n591 | data for users with depth of access controlled by appropriate access rights, as well as\n592 | protocols and methods for how local systems can connect to the Central Operating Unit.\n593 Recommendation 15 ' _ , '\n594 | FORMATION OF THE CENTRAL OPERATING UNIT The LEI Implementation Group '\n595 | should develop a detailed plan for the formation of the Central Operating Unit via the '\n596 | establishment of a not-for-profit LEI foundation” by interested industry participants under the\n597 | oversight of the formed LEI Regulatory Oversight Committee. The foundation would rely on\n598 | industry participants, their expertise and knowledge to identify and develop the most\n599 | technologically, financially and legally sound methods to implement the global LEI system in\n600 | line with the standards and framework defined by the Regulatory Oversight Committee.\n601 | Representatives from all geographic areas and industry sectors would be invited to participate\n602 | in the preparatory work underpinning the formation of the LEI foundation as the Central\n603 . | Operating Unit in 2 manner defined by the Implementation Group.\n604 Recommendation 16 \"\n605 | BALANCED REPRESENTATION IN THE CENTRAL OPERATING UNIT The\n606 | Regulatory Oversight Committee and LEI Implementation Group should ensure that the\n607 | global LEI foundation takes account of the interests of financial and non-financial industry\n608 | participants from different geographic areas and economic sectors. _\n609 Recommendation 17 - ‘\n610 | LOCAL OPERATING UNITS The LEI system should allow the local provision of all LEI\n611 | functions which the Regulatory Oversight Committee determines do not need to be\n612 | centralised. The LEI system should enable the use of local languages, organisation types and\n613 | relationship structures as required. Procedures to integrate local systems into the global LEI\n614 | system should be developed by the LEI Implementation Group in consultation with local\n615 | jurisdictions and potential Local Operating Units (when available) in a way and manner that\n\n2 Or body of equivalent legal form.\n\n17\n","contentLength":3033,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.384Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"616 | meets the global LEI system High Level Principles. The Central Operating Unit of the LEI\n617 | system should be ablé to provide support to Local Operating Unit operations when necessary\n618 | according to criteria and requirements established by the Regulatory Oversight Committee\n619 | and administered by the Central Operating Unit. . . : '\n620 Recommendation 18 ’\n621 | LEI DATA VALIDATION The LEI system should promote the provision of accurate LEI -\n622 | reference data at the local level from LEI registrants. Responsibility for the accuracy of :\n623 | reference data should rest with the LEI registrant, but Local Operating Units have\n624 | responsibility to exercise due diligence in guarding against errors, as consistent with '\n625 | Regulatory Oversight Committee standards, and to encourage necessary updating. The\n626 | Central Operating Unit has responsibility to check registrations for global uniqueness and to '\n627 | coordinate reconciliation by Local Operating Units where necessary. Accuracy should be\n. 628 | ensured at the local level by the registered entities. Self-registration should be encouraged as\n629 - | a best practice for the global LEI system. : _\n630 Recommendation 19 - '\n631 | LEI ISSUANCE WHEN NO LOCAL REGISTRAR AVAILABLE Whenever possible\n632 | the LEI registration should take place with the relevant Local Operating Unit: When a Local\n633 | Operating Unit is not available, the Regulatory Oversight Committee and a local jurisdiction\n634 | (when willing to engage) should agree on approaches for local entities to obtain LEIs. The\n635. | Implementation Group should develop proposals for such mechanisms via: (1) establishing a\n636 | mechanism of obtaining LEIs through other Local Operating Units; (2) establishing a .\n637 | mechanism of obtaining LEIs from a registration facility in the Central Operating Unit; and\n638 | (3) any other mechanisms that are appropriate. ,\n639 Recommendation 20 '\n640 | SUSTAINABLE FUNDING The steady state funding of the global LEI system should be\n641 | self-sustainable and reliable. The funding system should be based-on an efficient non-profit\n642 | cost-recovery model. The system should have two components: a local discretionary charge;\n643 | and a common fee based on the number of registrations in each LOU to pay for the\n644 | centralised operations in the Central Operating Unit, alongside any costs of implementing and\n645 | sustaining the governance framework. Fees should be sufficiently modest not to act as a |\n646 | barrier to acquiring an LEL _ 7 '\n647 Recommendation 21 ' ‘\n648 | GLOBAL REGULATORY OVERSIGHT COMMITTEE CHARTER The governance\n649 | framework of the global LEI system should be developed at the international level in an open ,\n650 | and transparent manner that supports collective governance of the global system. A global ,\n651 | LEI Regulatory Oversight Committee Charter should set out the formation and operations of\n652 | the Regulatory Oversight Committee. The global LEI Regulatory Oversight Committee |\n653 | Charter should be prepared by the FSB LEI Implementation Group for endorsement by the G- '\n654 | 20 at the Finance Ministers and Central Bank Governors meeting in November 2012 or by\n655 | the FSB Plenary in October. .\n' 18 .\n","contentLength":3260,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.384Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"656 Recommendation 22 ' :\n\n657 | REGULATORY OVERSIGHT COMMITTEE A Regulatory Oversight Committee, as\n\n658 | specified in the Charter, should have the responsibility of upholding the governance\n\n659 | principles and oversight of the global LEI system functioning to serve the public interest. The-| = -\n\n660 | Regulatory Oversight Committee should be a body representing regulators and other\n\n661 | government or supranational entities engaged in regulating or monitoring the financial system\n\n662 | or markets. Membership and decision making processes would be established by the Charter.\n\n663 - | Wherever possible, decisions would be reached by consensus. .\n\n664 Recommendation 23 : ,\n\n665 | POWER AND AUTHORITY OF THE REGULATORY OVERSIGHT COMMITTEE\n\n666 | The Regulatory Oversight Committee has the ultimate power and authority over the global =\n667 | LEI system. Any power delegated to the Central Operating Unit, Local Operating Units and\n\n668 | other entities can be reversed by the Regulatory Oversight Committee’. The Regulatory '\n669 | Oversight Committee should establish a formal oversight plan to ensure that its directives to\n\n670 | the Central Operating Unit or other parts of the system arc enforced and that the governance\n\n671 | principles are upheld.\n\n672 Recommendation 24 : .\n\n673 | PARTICIPATION IN THE REGULATORY OVERSIGHT COMMITTEE To\n\n674 | participate in the LEI Regulatory Oversight Committee, an authority should indicate support\n\n675 | for the global LEI High Level Principles and Charter for the Regulatory Oversight\n\n676 | Committee. Authorities may elect to be a full member of the Regulatory Oversight\n\n677 | Committee or an observer. The rights and responsibilities of members and observer status\n\n678 | participants should be defined in the Charter. : : '\n679 Recommendation 25 | , '\n680 | LEVERAGING INFRASTRUCTURE OF AN INTERNATIONAL FINANCIAL\n\n681 | ORGANISATION In developing proposals to establish the Regulatory Oversight\n\n682 | Committee following agreement on the Charter, the Implementation Group should if possible |\n683 | and, subject to agreement, leverage on the existing infrastructure of an international financial _\n684 | organisation to initiate and stand-up the global LEI governance structure in a timely manner,\n\n685 | utilising the experience of the international organisation in executing international initiatives.\n\n686 Recommendation 26 . ) . - )\n\n687 | GOVERNING DOCUMENTS FOR THE CENTRAL OPERATING UNIT Alongside\n\n688 | the development of the global Charter, the Implementation Group should develop legal\n\n689 | documents governing the mandate provided by the Regulatory Oversight Committee to the _\n690 | Central Operating Unit as well as other legal documents needed to specify the full\n\n691 | governance framework for the global LEI system.\n\n692 Recommendation 27 ' - -\n\n3 Local authorities may also reserve rights to be engaged in decisions on local registration operations to\nthe extent that they act in accordance with the High-Level Principles of the LEI system.\nB _ 19 : | - o\n","contentLength":3045,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.384Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"693 | BOARD OF DIRECTORS OF THE CENTRAL OPERATING UNIT The Central\n\n694 | Operating Unit shall have a Board of Directors. The Regulatory Oversight Committee has the\n695 | right to veto membership of the BOD, as well as to remove members. The ROC has the right\n696 | to appoint independent members”. '\n\n697 Recommendation 28 '\n\n698 | FORMATION OF THE INITIAL BOARD OF DIRECTORS OF THE CENTRAL\n699 | OPERATING UNIT The Central Operating Unit’s initial Board of Directors should be\n700 | appointed by the Regulatory Oversight Committee, taking into account the need for\n701 | geographic and sectoral diversity. The Implementation Group should develop the fitness\n. 702 | criteria, size, role etc for the BOD that should be reviewed in two years by the Regulatory\n703 | Oversight Committee. ' .\n\n704 Recommendation 29 - _\n\n705 | POWERS AND FUNCTIONS OF THE BOD OF THE CENTRAL OPERATING UNIT\n706 | The Board of Directors of the Central Operating Unit should be granted powers to direct the\n707 | mandgement and operations of the Central Operating Unit in line with the overall standards\n708 | set by the Regulatory Oversight Committee. 7\n\n709 Recommendation 30 o\n\n710 | CONTINGENCY ARRANGEMENTS The Regulatory Oversight Committee is responsible\n711 | for setting and overseeing the application of business continuity standards for the global LEI\n712 | system in line with best practices for key financial infrastructure. Rules and procedures\n713 | should be defined that the Central Operating Unit and Local Operating Units must follow in\n714 | case of insolvency, bankruptcy, etc in order to ensure continuity of the global LEI system. A\n715 | protocol should also be developed for maintenance of secure parallel copies of the LEI, in a\n716 | manner that respects local laws.\n\n717 Recommendation 31 ‘\n\n718 | LEI INTELLECTUAL PROPERTY The LEI Implementation Group should conduct .\n719 | analysis and provide recommendations on the treatment of the “LEI” intellectual property\n720 | (such as the LEI code, software, reference data, any other LEI data, operational protocols,\n721 | etc) according to the principles of open access and the nature of the LEI system as a public\n722 | good. The objective of this analysis shall be to ensure a regime that assures the availability in\n723 | the public domain, without limit on use or redistribution, of LEI data, reference data, and\n724 | processes. Any intellectual property rights should be held by, or licensed to the global LEI\n725 | foundation unless defined otherwise by the Regulatory Oversight Committee. Copyright\n726 - | should be-used to the extent possible to promote the free flow or combination of information\n727. | from disparate sources. :\n\n728 Recommendation 32 7 '\n729 | FSB LEI IMPLEMENTATION GROUP Subject to the G-20 supporting further work to\n730 | launch the global LEI, and entrusting implementation planning to the FSB, an FSB LEI :\n\n4 In this context independent members mean non-industry representatives.\n20\n","contentLength":2975,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.384Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":": I NAME, DURATION AND SEA'T\nArticle 1 Name and Duration\nA foundation within the meaning of Articles 80 et seq. of the Swiss Civil Code, named\n\"Global Legal Entity Identifier Foundation” (thc \"GLEIF\" or \"Foundation\"), is hereby\ncreated by the Financial Stability Board (the \"Founder\").\nThe Foundation is created for an unlimited period of time.\nArticle 2 Scat\nThe seat of the Foundation is Basel-Stadt, Switzerland.\nThe Foundation shall be registered in the Registry of commerce of the Canton of Basel Stadt\nand placed under the supervision of the Swiss Supervisory Board of Foundations (thc\n“Supervisory Authority\"),\n11 PURPOSE, MEANS AND TRANSPARENCY\nArticle 3 Purpose\nThe Foundation has no profit motive.\nThe Foundation's purpose 1s to act as the opcrational arm of a global Legal Entity Tdentifier\nsystem, and thereby support on a not-for-prefit basis the implementation of a global Legal\nEntity Identifier (\"LEI\"} in the [orm of a rcference code to identify uniquely legally distinct\nentities that cngage in financial transactions. The Foundation shall thereby contribute to and\nfacilitate many [inancial stability objectives, including: improved risk management; better\nassessment of micro and macroprudential risks; facilitation of orderly resolution; containing\nmarket abuse and curbing financial fraud; higher ovcrall quality and accuracy of financial\ndata; as well as meeting purposes set out in thc Charter of the Regulatory Oversight\nCommittec (\"ROC Charter\") of November 5, 2012 (sec annex 1) and the G20 endorsed\nFinancial Stability Board report on June 8, 2012 \"A Global Legal Entity Identifier for\n[Financial Markets\" (see anncx 2).\nArticle 4 Implementation of the purpose\nIn pursuing its purpose, the Foundation shall ensure that the governance principles of the\nglobal LEI system (\"GLEIS\") (the global LEl system High Level Principles (see annex 3),\nthe Financial Stability Board Recommcndations (Annex 2} and the ROC Charter (Annex 1}),\n5\n","contentLength":1958,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.384Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"731 | Implementation Group (IG) should be established with a clear mandate to launch the global\n732 | LEI system on a self- standing basis. The LEI Implementation Group should cease to exist\n733 | upon formation of the Regulatory Oversight Committee which should be by 31 March 2013\n734 | at the latest. _\n735 Recommendation 33 _ '\n736 | STRUCTURE OF THE FSB LEI IMPLEMENTATION GROUP A time-limited FSB _\n737 | LEI Implementation Group of interested and willing experts (legal, IT, and other) from ‘the :\n738 | global regulatory community that includes interested parties from the FSB LEI Expert Group\n739 | should be formed to take the global LEI initiative forward into the global implementation\n740 | phase until the Regulatory Oversight Committee is established. The IG should be led by\n. 741 | representatives from different geographic areas to reflect the global nature of the LEI\n742 | initiative and will be supported by the FSB Secretariat. The IG should develop proposals for\n743 | the global LEI system stand-up as defined in the mandate below for review and endorsement\n744 | by the FSB Plenary in October 2012 and, as appropriate, final review and endorsement by G-\n745 | 20 Finance Ministers and Central Bank Governors in November 2012. v\n746 Recommendation 34 ' ‘\n747 | RESPONSIBILITIES OF THE FSB LEI IMPLEMENTATION GROUP The mandate\n748 | of the FSB LEI Implementation Group should be to prepare a draft global LEI Regulatory\n749 | Oversight Committee Charter, proposals for the establishment ‘of the LEI Regulatory ,\n750 | Oversight Committee and related -structures, develop all necessary legal documents for\n751 °| Regulatory Oversight Committee operations, develop necessary intellectual property\n752 | agreements and contracts, conduct research and provide recommendations on LEI related\n753 | information sharing arrangements; set up the process and any necessary legal documentation\n754 | necessary for establishment of the Central Operating Unit and its Board of Directors; and set\n755 | up the process for establishment of the necessary standards, protocols, rules and procedures .\n756 | and organizational design for the Central Operating Unit. '\n757 Recommendation 35 ' ' ' . :\n758 | ESTABLISHMENT OF THE GLOBAL LEI SYSTEM The global LEI system will be '\n759 | established by the endorsement of the high level Charter for the Regulatory Oversight\n760 | Committee by the G-20 Finance Ministers and Governors in November or by the FSB\n761 | Plenary in October _\n21\n","contentLength":2493,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.384Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"\" Annex2 - _ o ‘ . : )\nA Global Legal Entity Identifier for Financial Markets of June §, 2012\no | SAARICH Notariat Zrich (Altstadt;\nsaN\nw = —— % : :\n\"{?\" Z{m\\@z\\ . M. Muller-Smit, Notar\n","contentLength":186,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.384Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"\\ FINANCIAL\nSTABILITY\nBOARD\n_ . _ : 8 June 2012 _ »\nA Global Legal Entity Identifier for Financial Markets |\n","contentLength":109,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.384Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"- ’\n","contentLength":4,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.384Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"| | | Table of Contents\nAbbreviations l :\nEXECULIVE SUIMIMALY .v.veviverereveressmsesenseseesesessesssisssssssssessessmasssesssssesnirosssssssbesssssronssssasorssmsansnese 1\nTEEOTUCTION 1evevviereierreirrenscrbesieesstsnessessesstessontessessasssassrntsnssserassressnsassssassesssaassassnssssasesnessnssnstenie |\nKey considerations and challenges to OVEICOME everveesreesssseneersessssenesseessessssmsessassssrnsoneens 2\nProposals and recommendafions 3\n‘ Implementation and NEXE SEEPS .....rvereerererrrssesssssessssssssessessssesassessrssessasesssersinissesessssessssesssses O\nAnnex 1: Global LEIL system diagran......c.cccererererrerereeresrisessoressinmmsssimnsssssessesesessisssssssssssnssisnns 8\n\" Annex 2: Recommendations for the development and implementation of the global LEI |\nSYSEEIM . etruivererrerernrereesssrerereesssnsionssersrstssesestssnsssesssasnestssesssesibnstonssesassasnsnssssaresesisneshoses 9\nAnnex 3: Global LEI System High Level Principles.......ceiveeneereresseseserensessseseesssnsensessesssnse 17\nAnnex 4: Initial elements for inclusion in a Charter for the global LEI Regfilatory Oversight\n: : Committee (ROC) ..cvverriieeirerrerenresisissesisnessssesssesssseeserasssessssssssssesssssossosssssesssrsssesanss 19 _\nA Global Legal Entity Identifier for Financial Markets........coecvvvvninniniiniiinnnnieenn 23\nL TOEOAUCEION cevveeerreerereroreresreesseerssssseessessresssessnsssonsesessssesstesssssesaseassssssissasssasessreasssnssrasnersses 24\n‘ II. Objectives of the global LEL SYSteM........cuiveruvisrinesiciniisiuismnsssiniisssesiiisemssaessssessise 29\nI1I. Key considerations and challenges to overcome in building a global LEI system............. 28\nIV.: Principles underpinning the framework and design of the global LEI system ..........c....... 32\nV. Scope, scale and initial AMbItiONS ......icvcveveriiiniiseiiinriicee e s 39\nVI. Pulling the LEI system t0gether......coccevinrnecicesnnermenesnmmeniseseniasiienssesismmesis 39\nVII. Governance and the rules of the game 48\nVIIIL Implementation and next steps OO &\nAnnex 5: LEI Implementation Group work plan diagram .......c.eereeserercsessssersensersessensersenanss 60 -\nAnnex 6: Global LEI system Charter development diagram .........ecovereerserseenssenssenssrssensens 61\nAnnex 7: LEI Centrél Operating Unit development process diagram ........coceeverenriviiereenrinnnns 62\ni\n","contentLength":2365,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.384Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"Abbreviations\n. BOD —Board of Directors . _ _\nCOU - Central Operating Unit\nIFI — International Financial Institution\nLEI — Legal Entity Identifier\nLOU - Local Operating Unit\nROC —Regulatory Oversight Committee\nSIFI — Systemically Important Financial Institution - _\n","contentLength":266,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.385Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"Executive summary o '\nThis report sets out recommendations and proposals to implement a global Legal Entity\nIdentifier (LEI) system that will uniquely identify parties to financial transactions. The report\n\n- is provided to the Los Cabos Summit, to meet the mandate provided by the G-20 to the FSB-\nat the Cannes Summit.\n\nIntroduction\n\nThere is widespread agreement among the public authorities and financial indusiry\n\nparticipants on the merits of establishing a uniform global system for legal entity\n\nidentification. Such a system would provide a valuable ‘building block’ to contribute to and\nfacilitate many financial stability objectives, including: improved risk management in firms;\nbetter assessment of micro and macroprudential risks; facilitation of orderly resolution;\ncontaining market abuse and curbing financial fraud; and enabling higher quality and\n\naccuracy of financial data overall. It would reduce operational risks within firms by mitigating .\n\n: the need for tailored systems to reconcile the identification of entities and to support\naggregation of risk positions and financial data, which impose substantial deadweight costs\nacross the economy. It would also facilitate straight through processing. But despite numerous\npast attempts, the financial industry has not been successful in establishing a common global\nentity identifier, The finance sector consequently lags well behind many other industries in\nagreeing and introducing a consistent global framework for entity identification.\n\nThe financial crisis has provided a renewed spur to the development of a global LEI system.\n\nInternational regulators have recognised the importance of the LEI as a key component of\n\nnecessary improvements in financial data systems.! To provide additional impetus, the FSB\n\nwas given a mandate by the G-20 to lead the co-ordination of international regulatory work\nand to deliver concrete recommendations on the LEI system by June 2012: '\n\n' “We support the creation of a global legal entity identifier (LEI) which uniquely identifies\n\n‘ parties to financial transactions. We call on the FSB to take the lead in helping coordinate\nwork among the regulatory community to prepare recommendations for the appropriate\ngovernance framework, representing the public interest, for such a global LEI by our next\n\nSummit.” (Cannes Summit Declaration)\n\nTo take the work forward, the FSB set up a time-limited Expert Grouprof key stakeholders\n\nwith the following mandate:\n\no To deliver clear recommendations with respect to the implementation of a global LEI\nsystem to the FSB Plenary for endorsement. Specific recommendations should be\npresented for the following package:\n\n0 Governance framework for a global LEI\n0 Operational model ' _\n0 Scope of LEI reference data, access and confidentiality\n0 Funding model .\n\n: 0 Implementation and phasing\n\n! Committee on Payment and Settlement Systems and Technical Committee of the International Organization of Securities\nCommissions, Report on OTC derivatives data reporting and aggregation requirement, final report, January 2012,\n) 1\n","contentLength":3085,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.385Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"The value of strong co-operation between private sector stakeholders and the global\nregulatory community in developing an LEI system is widely accepted. The Expert Group\nbenefited from extensive input from an Industry Advisory Panel and discussions at a :\n_ workshop in Basel in March. The FSB is very grateful for the support. _\nThe FSB Plenary has reviewed and approved the recommendations of the Expert Group.?\nThis Report provides the recommendations of the FSB to the G20 Summit for the\ndevelopment and implementation of the global LEI system. '\nKey considerations and challenges to overcome '\nGiven that a unique LEI system for financial markets offers manifold benefits, an obvious\nquestion is why such a system is not already in place? The principal reason is that the benefits\nof the system are collective and accrue to users and the broader public as a group. There are\ninsufficiently strong incentives in private markets to overcome two sources of market failure.\nThe first is a problem of collective. action and co-ordination, reflecting the challenges of '\ngaining agreement that a particular identification scheme offers the best approach. The second\nreflects the problem of launching a network. The benefits from the system increase as more\nand more parties acquire an LEL At the launch, however, as with other examples of network\ngoods such as the telephone, the private incentives for potential early movers to acquire an .\nLEI are low. To date it has proved impossible to get over this initial hurdle relying purely on\nvoluntary adoption and market incentives. . '\nThese market failures support the view that the LEI is by nature a public good, offering\ncollective benefits that are hard to capture by private market incentives alone. In practice,\npublic intervention, for example, that mandates the use of the LEI for reporting of exposures\nor positions may be needed to break down such barriers and take the initiative forward.\nRemoving such barriers provides an opportunity for a co-ordinated approach between the.\npublic and private sector in delivering a global LEI system. That is why the recent CPSS-\nIOSCO Report on data reporting and aggregation requirements emphasised that: “as a\nuniversally available system for uniquely identifying legal entities in multiple financial data\napplications, LEIs would constitute a global public good.” .\nThere are many areas where public and private sector interests in the global LEI system are\nfully aligned (such as unique identification of entities, high quality reference data, integrity of\nsystems, etc). But since the LEI system is by nature a public good, there is a need to make\nsure that the gains for the broader public are captured and that provision of the LEI is not\nexploited in ways that do not benefit the public. For example, if regulators mandate use of the\nLEI system, then both LEI registrants and users have no alternative but to use it. Absent any '\n' choice, the market is captive. There are consequently incentives for suppliets of the LEI to\nexploit their privileged position and hence risks that suppliers face incentives to overcharge :\nregistrants, restrict access, cut corners on data quality, or to use a position of privileged access\nto LEI information to supply other revenue-generating services on non-competitive terms.\nThese arguments provide the motivation for the mandate provided to the FSB to produce\nrecommendations for a governance framework for the LEI that identifies and provides strong\n2 Membership of the Expert Group comptised representatives from both FSB members and key non-members from the 7\nglobal regulatory community with a major stake in the initiative such as the CFTC and ESMA. The Group greatly\nbenefited from the active input and advice of a private sector Industry Advisory Panel of 34 experts from across the globe\nas well as from participants in a public/private sector workshop in Basel in March. .\n2 .\n","contentLength":3929,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.385Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"protection of the public interest, while encouraging competitive market forces and mitigating\nmonopoly threats. . ‘\nTo foster confidence in the quality of the LEI and soundness of the LEI system, it is important\n: that there is a unique identifier for each entity that registers, and-that there are reliable, while\nflexible, operational principles and standards applied to the origination and maintenance of an\nLEL Such principles and standards will facilitate the consistent integration into a global\nsystem of entities from jurisdictions with different regulatory, legal systems and local\nlanguage character sets. It is important to reflect and take into account such characteristics if\nall such jurisdictions are to feel comfortable in joining the system over time. Moreovet, in '\norder to generate the maximum network benefits from broad coverage, it is important that the\nsystem has the capacity to expand quickly to include new jurisdictions and new registrants .\nacross the globe. Clear processes and protocols should be in place to facilitate the integration\nof registrars and registrants from new members into the system. It is also crucial that the\nglobal system is flexible and adaptable to take account of changes in financial markets and\nnew potential uses. It must also provide appropriate protection of data covered by\nconfidentiality and privacy restrictions governing some potentially important reference data in\nsome countries, particularly regarding information on corporate relationships and ownership\nstructures.\nDeveloping and implementing a global LEI system will require active support and\ninvolvement from both the global regulatory community and from the private sector,\nincluding potential LEI registrants (both from the financial and non-financial sectors),\nstandard setters, data and system suppliers, academics and consultants. To ensure global\nacceptance and the long-term future of the LEI system, the public sector must put in place a\n' ~ governance framework with a number of key objectives: to support the delivery of a public\ngood; to ensure that public interests in the system are protected; to promote common\nstandards; and to facilitate widespread global adoption. Such a framework will provide a\ntransparent, open and fair system, that protects against the risk of abuse of dominant market\npositions, and that facilitates quick adoption. Under this broad governance framework, it is\nimportant to provide competitive market incentives for the private sector to develop and\n- implement effective operational and technical solutions: to draw on expertise and specialism\nin local jurisdictions and globally in the development and operation of registration,\nidentification and information systems; to establish collaboration methods to learn from the\nsuccessful development of similar identification systems in other industries; to gain from the\nbenefits of competition while facilitating co-operative solutions where appropriate; and to\npromote standardisation of approaches across the globe that benefit international financial\nmarkets, global financial integration and economic growth. The proposals and\n: recommendations in the report consequently set out a framework that attempts to capture in a\npractical manner the benefits of both public sector and private sector involvement in taking\nforward the global LEI initiative, while attempting to bridge different views on the\nappropriate boundary between public and private sector responsibilities.\nProposals and recommendations\n' The FSB strongly supports the development and implementation of a global LEI system. The\nreport sets out 35 ‘Recommendations for the Development and Implementation of the Global :\nLEI System’ (Annex 2) to advance the practical implementation of such a system.\n: 3 :\n","contentLength":3786,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.385Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"These recommendations are guided by a set of ‘Global LEI System High Level Principles’\nthat set out the objectives that the design of a global LEI system must meet (Annex 3).\n\nThe broad aim of the proposals is to put in place a strong global governance framework to\nprotect the public interest, while promoting an open, flexible, and adaptable operational model\nfor the global LEI system. To be successful, the global LEI system should support the needs\nand interests of both the regulatory community and the private sector, and encourage\nwidespread adoption and take up across the globe in a phased manner.\n\nWidespread (and ultimately global) adoption will maximise the benefits of the global system.\nTo support this objective, the FSB recommends that the global system should support a high\ndegree of federation and extensive reliance on local implementation under agreed and\ncommonly applied global standards. In particular, the global LEI system should be designed,\noperated and governed in a manner that ensures unique entity identification and consistency at\nthe global level, while drawing on distributed local elements and local infrastructures where\npossible. Drawing on such local arrangements provides additional flexibility to deliver a high\nlevel of local validation of reference data for the legal entities registering for an LEIL, as well\nas meeting local jurisdictional requirements.\n\nThe FSB recommends a three-tier structure for the global LEI system to meet the broad\nobjectives (see attached Chart in Annex 1):\n\n) Regulatory Oversight Committee (ROC). The ROC will have the ultimate\nresponsibility for the governance of the global LEI system. It would comprise '\nauthorities which support the core principles and purposes of the system (as set out in :\nthe High Level Principles) and that are committed to support the governance in the\npublic interest. The FSB recommends that the governance principles and obligations\nare set out in a global LEI Regulatory Oversight Committee Charter that should be\ndrawn up by the autumn. Endorsement of the Charter by the FSB or G-20 would\nestablish the ROC. Membership of the ROC will be open to all authorities wishing to\n\n' participate in the global LEI system and that are committed to the objectives and\n\ncommitments highlighted in the Charter. An Executive Committee would be\n\n: appointed by the Plenary to steer the work under guidelines to be set out in the\nCharter. .\n\n. Central Operating Unit (COU). The Central Operating Unit is the pivotal :\noperational arm of the global LEI system and has responsibility for delivering high\nquality operations. In particular, the COU has responsibility for ensuring the\napplication of uniform global operational standards and protocols that deliver: global\nuniqueness of the LEI; seamless, open access to the global LEI and to high quality\nreference data for users (with the depth of access controlled by appropriate access\nrights®); as well as protocols and methods for how local systems can connect to the\nCOU, including the necessary support of the local systems. The COU will be a legal\nentity in the form of a not for profit foundation* that will rely on broad industry\n\n3 The COU will support the maintenance of a ‘logically’ centralised database of identifiers and corresponding reference\n\ndata — as with the Internet, the database will appear to users to be from a single seamless system, but again as with the -\n\nInternet, the data will be physically stored on different systems across the globe. Technology will deliver the logical\n\ncentralisation.\n\n4 Orbody of equ{valent legal form. »\n4\n","contentLength":3603,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.385Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"arc upheld, under the regulatory oversight of the ROC, in the broad public interest to the\n* extent permitted under Swiss law.\nArticle 5 Means\nThe Foundation inay carry out all such lawful activities as shall further the attainment of the\npurpese of the Foundation, such as in particular:\n- support the application of uniform global operational standards and protocols\nsct by the ROC in the GLEIS;\n. support the maintenance of a ceniralised database of identifiers and\ncorresponding refercnce data;\n. draft protocols and methods for how 1.OUs can connect to the COU, including\nthe necessary support of the local systems;\n. oversee the adherence of 1.OUs to the globally agreed standards as endorsed by\nthe ROC;\n. identify and sccure funding including setting the fees to be paid by the LOUs\nas a contribution to the financing of the GLEII in accordance with the\ngovernance principles of the GLEIS defined in Article 3;\n. provide recommendations to the ROC; and\n. any other activities necessary to atlain the purposes of the Foundation as\ndescribed in these Statutes.\nArticle 6 ‘Transparency\nThe GLEIT must ensure the application of uniform global operational standards and protocols\nthat deliver global uniqueness of the LEI, seamless access to the global LEI and to high\nquality reference data for uscrs.\nThe Foundation should operatc with a high degree of transparency and publish all relevant\ninformation in line with the governance principles of the GLEIS and general policies as\napproved by the ROC, in accordance with Article 2 b) (3) of the ROC Charter.\nThe Foundation shall, in particular, inake publicly available the following items:\n. all governance materials including bylaws and Board Member information and\nBoard selcction processes;\n. all proposed and adopted annual budgets and annual accounts;\n6\n","contentLength":1813,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.385Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":": participation, expertise and knowledge to identify and develop the most\ntechnologically, financially and legally sound methods to implement the global LEI\nsystem in line with the standards and framework defined by the ROC. A Board of :\nDirectors (BOD) will direct the operations of the COU. The Board may include both\nindustry representatives and independent participants. The COU’s BOD, in\n\n_consultation with the ROC, will provide recommendations on whether to outsource\nany particular function or operation of the global LEI system or whether to develop a\nparticular solution “in-house.” Those recommendations should be consistent with the\nHigh Level Principles of the global LEI system and reflect the public good nature of\n' the system. '\n\n. Local Operating Units (LOU). Local Operating Units will provide the primary °\ninterface for entities wishing to register for an LEI. They will be the local\nimplementers of the global system. LOUs will offer facilities such as local\nregistration, validation, and maintenance of reference data; protection of information\n\n- that must be stored locally; and will facilitate the use of local languages and\norganisation types. LOUs could build on local business registry or numbering \\\nservices to maximise the utilisation of local infrastructures. In some jurisdictions,\nthere may be multiple LOUs to encourage competition, in others there may be one\nwhich could reside or be operated in the private or public sector, in yet others there\nmay be no LOU and entities wishing to acquire an LEI will need to apply across\n\n' borders or to the COU until the local infrastructure is established. In the latter case, if\n' an LOU is subsequently created, it will be important to ensure that the LEI is\nportable (transferable) to the local jurisdiction.\nAn important objective in the system design is to ensure that the global LEI system has a self-\nsustaining funding model. The model must ensure that the system is based on non-profit cost\nrecovery® and that there are no monopoly rents accruing to service providers. The proposed\nsteady state funding system® has two components: a local discretionary charge; and a\ncommon fee for support of central functions of the COU and ROC. The cost of obtaining an\nLEI should be modest and not a barrier to acquisition. Access to the LEI and associated\nreference data will be free and open to all users, and there should be no ‘bundling’ of other\nservices alongside the LEI by providers which forces users to pay directly or indirectly for the\nLEIL : :\nThe FSB encourages widespread adoption of LEIs and consequently supports that the\neligibility of ‘legal entities’ to apply for an LEI should be broadly defined, in order to ensure\nthat all relevant entities can apply now and in the future as financial markets evolve and adapt.\nUniqueness must be guaranteed, however, and so only one LEI may be assigned to any\nfinancial market counterparty. ,\nThe initial reference data available at the launch of the” LEI will enable the unique\nidentification of the eligible legal entity. The subject reference elements are outlined in the ’\nrecently issued standard ISO 17442:2012, Financial Services — Legal Entity Identifier (LED)’.\nThe FSB endorses the recommendation of the Expert Group that, as specified in ISO\n3 Albeit with provisions to ensure efficiency and avoid any gold-plating of costs. i\n6 Start up funding is covered below. )\ni \" The standard was published by the International Organisation for Standardisation on 30 May 2012.\n' 5\n","contentLength":3513,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.385Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"17442:2012, the official name of the legal entity, the address of the headquarters of the legal\n. entity, the address of legal formation, the date of the first LEI assignment, the date of last\nupdate of the LEI, the date of expiry®, business registry information (if applicable), alongside\na 20 digit alphanumeric code® should form the basis for the system at the launch of the global\n-LEI initiative.\nThe FSB concluded that it is very important that the system is adaptable and expandable and\nthat new reference data can be added into the global system. In particular, the FSB\nrecommends the rapid development of the standards for LEI reference data on ownership and '\ncorporate hierarchies, as these data are essential to achieve one of the key objectives of risk\naggregation for the global LEI system. The FSB consequently recommends that work is taken\nforward urgently to develop proposals and, if necessary, global standards for additional\nreference data on the direct and ultimate parents of legal entities to address the current\noperational constraints that prevent timely and effective data aggregation. The next step in\nthis work will need to address the challenge that some jurisdictions may not, at least-\nimmediately, be able to share such information due to confidentiality and privacy restrictions.\nThat will also affect where such data can be stored in the global LEI system (locally or\ncentrally). Ideally, legal and technical arrangements can be put in place to enable sharing of\nconfidential information among the global regulatory community, although this warrants\nadditional scrutiny. :\nImplementation and next steps\nThe FSB strongly supports rapid implementation of the global LEI system. Early delivery of\nthe system would advance multiple G-20 financial market initiatives and provide manifold\n: benefits to the global regulatory community as well as to the private sector.\nThe FSB recommends adoption of an implementation plan with the goal of establishing an\nindependent, open, fair and transparent global LEI system by the end of 2012 with the system\nindependently functional by March 2013. Achieving this ambitious objective will require high\nlevel political support and strong engagement and co-operation with a wide range of private\nsector stakeholders on the development of the COU. That in turn will build on the successful\ninteraction over the past four months between the FSB LEI Expert Group and the private\nsector, through the LEI Industry Advisory Panel and the workshop. ' :\nSubject to the G-20 supporting further work to launch the global LEI, and entrusting\npreparatory work to the FSB, the FSB recommends establishing an LEI Implementation\nGroup with a time and task-limited mandate to launch the global LEI system on a self\nstanding basis by no later than March 2013.\nThe Implementation Group (IG) would build on and replace the current Expert Group and\nwould comprise interested and willing experts (legal, IT and other) from the global regulatory\ncommunity. To reflect the global nature of the LEI initiative, the group would be led by\n& TFor entities with a date of expiry, the reason for the expiry should be recorded, and, if applicable, the LEI of the entity or\nentities that acquired the expired entity. -\n9 The technical code of the LEI should be a 20 digit alphanumeric number as set out in the ISO standard 17442:2012. The\ncode should not incorporate any intentional embedded intelligence (such as a country reference) which would lead to the\ncode becoming out of date.\n6\n","contentLength":3523,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.385Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"representatives from different geographical regions. There are two principal strands of work '\n(as shown in Chart 1 overleaf):\n. Legal and policy work to develop the proposed Chatter for the ROC together with\nthe necessary documents governing the creation and operation of the ROC and the\n_ COU.\n. Technology work with the private sector to establish the COU.\nThe initial objective of the legal workstream will be to develop the Charter for the ROC (see\nAnnex 4: Initial Elements for Inclusion in a Charter for the Global Regulatory Oversight\n\" Committee) as well as other key legal documents such as the bylaws of the ROC and the legal\nframework for the establishment of a global LEI foundation charged with developing and\noperating the COU. The G-20 may either assign the FSB the task of preparing and endorsing\nthe Charter, or could decide to undertake the final endorsement itself at the Finance Ministers\nand Central Bank Governors meeting in November. Endorsement of the Charter will establish '\nthe ROC!. A small secretariat may be recruited to support the ROC as determined by the\nROC. International financial institutions would be approached to see if they would be\nprepared to support the establishment of the ROC. Once in place, the ROC will be able to '\n. endorse and establish the COU, including appointing the first BOD according to criteria\ndeveloped by the Implementation Group. An early task is to analyse and develop practical\nmethods for seed-corn funding for development of the global system (the preferred option is\nto approach charitable foundations that are interested in the area about funding a global LEI ‘\nfoundation which will form the COU'2 — other options, which could be complementary,\ninclude loans from IFIs or from the private sector).\nIn parallel, the technology stream will undertake preparatory work with a wide range of\nprivate industry representatives interested in joining a global industry LEI foundation\nconsultative group'® to develop a central platform that will facilitate the integration of a local\n- identification schemes (whether currently existing or emerging) into a logically centralised\n. database of unique LEIs based on consistent standards, protocols, procedures etc that appears\nseamless to users. This work will be taken over by the global LEI foundation or body of\nequivalent legal form under the direction of its BOD, once the ROC is in place to formally\nestablish the foundation/CO_U and appoint the Board'. Once in place, the Board will then\nhave responsibility under the guidance of the ROC for finalising the development and\nimplementation of the necessary systems, including decisions on whether to build or buy\nparticular components and services (including the option of complete contracting out).\nThe attached report sets out the recommendations and implementation plan.\n10 Takir(;g forward the development of recommendations for additional reference data to reflect ownership will form a third .\nstrand.\nY The Charter will spell out the timeline and process to form the ROC as an operational Committee (eg membership,\npomination of Chairman, secretariat, etc).\n2 Preliminary discussions indicate interest on the part of such foundations and other non-governmental organizations.\n- 13 An open invitation and solicitation of interest would be made by the Implementatibn Group via a public announcement\n’ upon endorsement of the Report by the G-20. -\n14 Once the ROC has established the COU and appointed the Board, the COU will also have responsibility for the\noperational integration of any existing pre-LEI solutions operated by potential LOUs (eg the CFTC CICI solution - which\nis expected to be launched in mid 2012).\n. » ;\n","contentLength":3694,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.385Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":": , Annex 1: Global LEI system diagram\nCREATION i ] GOVERNANCE COMPONENT l ’ . FUNCTION\n1. Developed by the FSB and présented: in 1. Setsevip global LFL\n‘ the regort. e T e a o | systeny frarework\n. ) B e I IO R AT AR S-S EN TG HEEVE PR INGI P LS thiaie i >y StenY 1 Or\n2. To be developed by the ESB LEI @.\\_ T e DG A Erohs T 7@ I 'fiifi S| | 2. Establislies ROC\nlcmm'ta’u\"o a 'Group (I G‘J e e T e T e e TR R T e ) I .\n3, ROC is established per Charter appraval — — : 3. ROC is theulimate: global\nby G-20 andfor FSB. ROC Chairman 3. REGULATORY OE%%IGI—I'T.COWHI 1EE authority of the global TEL - '\nselection eriteris are established by the ) . = . systeny | - :\n4. ROC Plenary is composed of'all , ,, 2 5‘«,»&%%}%%z,«e,,;'gm“@,gww F-gflfigfim, decision making body of the\naithbrities committing to the global LET - = n global LEFsystein.\nftstive as defined iathe Charter b R | |5 roc e Comine\n5. ROC Fxecutive Cotnniitied selection o Wffifi%fiz% Lfi;fl;\" g@?&%@lfiflfi%* %m Q@%fi%fi% : steers thekorkiof the ROC,\nSriteria are established by:fhe Charter. e e e UL\n6. COU is recognized by e ROC. ' @ :\n7' COU iS formed as. afOMda‘&Qn or i A R R e e e P e L S s iy o] in oo . P\n- equivalent Iegal form under by-Jaws. as e CENIRATORIRARNGUNIIICOBI 1 | | 6. COUisibeperational sy\ndeveloped by IG. ROC will recognize the 2 LEGATEORUSEOUNDATION OREQUINATENT ‘of e global LETSystenii.\nO Y . = S i fima e o e e e e A T e B LI SR VTR o = SY A\nfoundation as.the global LEI system COUL GEl e S e e B T | 7. Foundation.or equitvalent is\n8. BOD of thie foundation is formed from o R CU RO fij@@%fl e alépalentity,\n. ' . foundation members pls tidependent e el e 3. BOD directs flie COU. .\n. directors. L e e R o e e e e ‘\n’ E e e e R e R B \" :\net it S R o D s e e s T A R L s SR e g\n9, Local élement is contracted by the COU. : — , .8, BOW s local _\n. which recognized it ss-a LOU. & LOU can 9.LOCAL 9. LOCAT, 9. LOCAL impleirientes of the\ne single on auuliplepe juisdiction OPERATING UNIT | OPERATING UNIT | OPERATING UNIT clobl LET syetent\n- | putlic or private, couritry specific or Loeu) 1 xowmz FouN . o T\n’ tegiouai.\n_ 8\nR R R R —E————E——————————————\n","contentLength":2127,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.385Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"Annex 2: Recommendations for the development and implementation of the global LEI\n\n' , system\n\nThe following 35 recommendations are proposed by the FSB in order to develop and\nimplement the global LEI system. They also include steps to be addressed by the\nrecommended FSB LEI Implementation Group in the implementation phase of the global LEI\ninitiative. v '\nRecommendation 1 :\nSETTING UP A GLOBAL LEI SYSTEM The FSB strongly supports the development and | .\nimplementation of a global LEI system that uniquely identifies participants to financial\ntransactions. , '\nRecommendation 2\nGLOBAL REGULATORY COMMUNITY REQUIREMENTS The LEI system should\nmeet the requirements of the global regulatory community (including supranational\norganisations). The potential benefits of the LEI include: to support authorities in fulfilling\ntheir -mandates to assess systemic risk and maintain financial stability; conduct market\nsurveillance and enforcement; supervise market participants; conduct resolution activities;\nprepare high quality financial data and undertake other regulatory functions.\n\nRecommendation 3 ‘\n\nGLOBAL LEI SYSTEM GOVERNING DOCUMENTS Global LEI system High Level\n\nPrinciples set out the principles and commitments that specify and define the governance and\n\nstructure of the global LEI system. A global LEI Regulatory Oversight Committee Charter\n\nshould specify the mission, role and responsibilities of the Committee as well as the process\nfor its establishment. Support for the High Level Principles agreement and Charter will\nindicate a desire to participate in the global LEI system. -\n\nRecommendation 4 ' _\n\n. SUPPORT OF FINANCIAL MARKET PARTICIPANTS The LEI system should be\n\ndesigned in a manner that provides benefits to financial market participants.\nRecommendation 5 '\nSYSTEM FLEXIBILITY Flexibility must be built into the global LEI system to provide the\ncapability for the system to expand, evolve and adapt to accommodate innovations in\nfinancial markets. It must also allow the seamless introduction of new participants. To these\nends, critical software and other relevant elements must be defined and made publicly\navailable without any licensing, intellectual property or similar restrictions under open source\nprinciples. The LEI should be portable’® within the global LEI system. ‘\n\n5 1In this context a portable LEI means that the code could be transferred from one LOU to another LOU. This may be\nnecessary, for example, in case of the LEI being obtained originally from a foreign LOU before a local LOU was\nestablished or if an entity changed its legal address or headquarters, etc.\n\n9\n","contentLength":2615,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.386Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"Recommendation 6\nCOMPETITION AND ANTI-TRUST CONSIDERATIONS The LEI system should be\ndesigned to ensure that it is not “locked-in” with a particular service provider for any key _\nsystem functions or processes, and that the principles of competition are ensured on both\nglobal and local levels where appropriate. The governance framework should provide\nsafeguards to ensure that competition principles and anti-trust considerations are upheld. The\nlocal implementation of the global LEI system should meet local anti-trust requirements. .\nRecommendation 7\nFEDERATED NATURE OF THE LEI SYSTEM The global LEI system should support a\nhigh degree of federation and local implementation under agreed and implemented common\nstandards.\nRecommendation 8\nSCOPE OF COVERAGE Eligibility of ‘legal entities’ to apply for an LEI should be broadly\ndefined, in order to identify the legal entities relevant to any financial transaction. No more\nthan one LEI shall be assigned to any legal entity.\nRecommendation 9\nLEI REFERENCE DATA AT SYSTEM LAUNCH The official name of the legal entity,\nthe address of the headquarters of the legal entity, the address of legal formation, the date of\nthe first LEI assignment, the date of last update of the LEI, the date of expiry, business\nregistry information (if applicable), alongside a 20 digit alphanumeric code should form the\nbasis for the global system at the launch of the global LEI initiative. For entities with a date of\nexpiry, the reason for the expiry should be recorded, and, if applicable, the LEI of the entity or\n\n| entities that acquired the expired entity. , S\nRecommendation 10 _\nREVIEW OF SCOPE OF COVERAGE AND REFERENCE DATA The Regulatory\nOversight Committee should undertake regular reviews of the scope and extent of coverage of\nthe LEI to reflect emerging regulatory and market requirements for the LEI use according to\nan agreed sch_edu}e. The Regulatory Oversight Committee should undertake regular reviews\nof the LEI reference data according to a set schedule to monitor the required changes,\nadditions, retirements and modifications.\nRecommendation 11\nSTANDARDS FOR THE LEI SYSTEM The LEI system should meet, to the degree |\npossible, evolving requirements of both the regulatory community and industry participants in\nterms of information content, scope, timeliness and availability. The Regulatory Oversight\nCommittee is responsible for the final determination for any standards for the LEI to be\nutilised in the global LEI system. When proposing areas for the development of new 7\nstandards, the Regulatory Oversight Committee should strongly consider utilising existing\nstandard setting organizations to develop such standards, provided that such organizations\n\n10 ‘\n","contentLength":2723,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.386Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"incorporate the requirements for the standards as determined and communicated by the\nRegulatory Oversight Committee.\n: - Recommendation 12 - ' : : ' :\n: LEI REFERENCE DATA ON OWNERSHIP The FSB LEI Implementation Group should\n: | as soon as possible develop proposals for additional reference data on the direct and ultimate\nparent(s) of legal entities and relationship or ownership data more generally and to prepare\nrecommendations by the end of 2012, The group should work closely with private sector\nexperts in developing the proposals. |\nRecommendation 13 :\nLEI OPERATIONAL AND HISTORICAL DATA The LEI system should maintain high\nquality records that retain relevant information on amendments (query, add, modify or delete\n\" | of any data element) to data items as well as additional data to facilitate the surveillance and | -\ncontrol of the system by the COU where appropriate. ,\nRecommendation 14\nCENTRAL OPERATING UNIT The mission and role of the Central Operating Unit should\nbe to ensure the application of uniform global operational standards and protocols that deliver\nglobal uniqueness of the LEL, seamless access to the global LEI and to high quality reference\n' data for users with depth of access controlled by appropriate access rights, as well as\nprotocols and methods for how local systems can ¢onnect to the Central Operating Unit.\nRecommendation 15 ‘\nFORMATION OF THE CENTRAL OPERATING UNIT The LEI Implementation Group\nshould develop a detailed plan for the formation of the Central Operating Unit via the\nestablishment of a not-for-profit LEI foundat.ion16 by interested industry participants under\nthe oversight of the formed LEI Regulatory Oversight Committee. The foundation would rely\non industry participants, their expertise and knowledge to identify and develop the most\ntechnologically, financially and legally sound methods to implement the global LEI system in\nline with the standards and framework defined by the Regulatory Oversight Committee.\n: Representatives from all geographic areas and industry sectors would be invited to participate\n| in the preparatory work underpinning the formation of the LEI foundation as the Central\nOperating Unit in a manner defined by the Implementation Group.\nRecommendation 16 ’\nBALANCED REPRESENTATION IN THE CENTRAL OPERATING UNIT The\nRegulatory Oversight Committee and LEI Implementation Group should ensure that the '\n' global LEI foundation takes account of the interests of financial and non-financial industry | -\nparticipants from different geographic areas and economic sectors. '\n16 Or body of equivalent legal form. .\n11 .\n","contentLength":2605,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.386Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"Recommendation 17 _ ;\nLOCAL OPERATING UNITS The LEI system should allow the local provision of all LEI\n| functions which the Regulatory Oversight Committee determines do not need to be,\ncentralised. The LEI system should enable the use of local languages, organisation types and\nrelationship structures as required. Procedures to integrate local systems into the global LEI .\n- | system should be developed by the LEI Implementation Group in consultation with local\n' jurisdictions and potential Local Operating Units (when available) in a way and manner that\n- | meets the global LEI system High Level Principles. The Central Operating Unit of the LEI\nsystem should be able to provide support to Local Operating Unit operations when necessary\naccording to criteria and requirements established by the Regulatory Oversight Committee\nand administered by the Central Operating Unit. _\n: Recommendation 18\nLEI DATA VALIDATION The LEI system should promote the provision of accurate LEI\nreference data at the local level from LEI registrants. Responsibility for the accuracy of\n-| reference data should rest with the LEI registrant, but Local Operating Units have\nresponsibility to exercise due diligence in guarding against errors, as conmsistent with\nRegulatory Oversight Committee standards, and to encourage necessary updating. The\nCentral Operating Unit has responsibility to check registrations for global uniqueness and to\ncoordinate reconciliation by Local Operating Units where necessary. Accuracy should be\nensured at the local level by the registered entities. Self-registration should be encouraged as a\nbest practice for the global LEI system.\nRecommendation 19 _ .\nLEI ISSUANCE WHEN NO LOCAL REGISTRAR AVAILABLE Whenever possible the\nLEI registration should take place with the relevant Local Operating Unit. When a Local '\nOperating Unit is not available, the Regulatory Oversight Committee and a local jurisdiction )\n(when willing to engage) should agree on approaches for local entities to obtain LEIs. The\nImplementation Group should develop proposals for such mechanisms via: (1) establishing a\nmechanism of obtaining LEIs through other Local Operating Units; (2) establishing a\nmechanism of obtaining LEIs from a registration facility in the Central Operating Unit; and\n(3) any other mechanisms that are appropriate.\nRecommendation 20\nSUSTAINABLE FUNDING The steady state funding of the global LEI system should be\n| self-sustainable and reliable. The funding system should be based on an efficient non-profit\ncost-recovery model. The system should have two components: a local discretionary charge;\nand a common fee based on the number of registrations in each LOU to pay for the centralised\noperations in the Central Operating Unit, alongside any costs of implementing and sustaining\n| the governance framework. Fees should be sufficiently modest not to act as a barrier to\nacquiring an LEL\n12\n","contentLength":2912,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.386Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"Recommendation 21\nGLOBAL REGULATORY OVERSIGHT COMMITTEE CHARTER The governance\n, framework of the global LEI system should be developed at the international level in an open\n\n' and transparent manner that supports collective governance of the global system. A global\nLEI Regulatory Oversight Committee Charter should set out the formation and operations of\nthe Regulatory Oversight Committee. The global LEI Regulatory Oversight Committee\nCharter should be prepared by the FSB LEI Implementation Group for endorsement by the G-\n20 at the Finance Ministers and Central Bank Governors meeting in November 2012 or by the |\nFSB Plenary in October. , )\nRecommendation 22 :\nREGULATORY OVERSIGHT COMMITTEE A Regulatory Oversight Committee, as\nspecified in the Charter, should have the responsibility of upholding the governance principles\nand oversight of the global LEI system functioning to serve the public interest. The\nRegulatory Oversight Committee should be a body representing regulators and other\ngovernment or supranational entities engaged in regulating or monitoring the financial system .\nor markets, Membership and decision making processes would be established by the Charter.\nWherever possible, decisions would be reached by consensus.\nRecommendation 23\nPOWER AND AUTHORITY OF THE REGULATORY OVERSIGHT COMMITTEE '\n\n| The Regulatory Oversight Committee has the ultimate power and authority over the global | -\nLEI system. Any power delegated to the Central Operating Unit, Local Operating Units and\nother entities can be reversed by the Regulatory Oversight Committee'’. The Regulatory\nOversight Committee should establish a formal oversight plan to ensure that its directives to\nthe Central Operating Unit or other parts of the system are enforced and that the governance\nprinciples are upheld.\nRecommendation 24 .\nPARTICIPATION IN THE REGULATORY OVERSIGHT COMMITTEE To\nparticipate in the LEI Regulatory Oversight Committee, an authority should indicate support\nfor the global LEI High Level Principles and Charter for the Regulatory Oversight\nCommittee. Authorities may elect to be a full member of the Regulatory Oversight Committee\nor an observer. The rights and responsibilities of members and observer status participants\nshould be defined in the Charter. _\n17\" Tocal authorities may also reserve rights to be engaged in decisions on local registration operations to the extent that they\nact in accordance with the High-Level Principles of the LEI system.\n13 .\n","contentLength":2475,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.386Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":", Recommendation 25 : :\nLEVERAGING INFRASTRUCTURE OF AN INTERNATIONAL FINANCIAL |\n_ ORGANISATION In developing proposals to establish the Regulatory Oversight Committee |\nfollowing agreement on the Charter, the Implementation Group should if possible and, subject\nto agreement, leverage on the existing infrastructure of an international financial organisation\nto initiate and stand-up the global LEI governance structure in a timely manner, utilising the\nexperience of the international organisation in executing international initiatives.\nRecommendation 26 '\n‘ GOVERNING DOCUMENTS FOR THE CENTRAL OPERATING UNIT Alongside the\ndevelopment of the global Charter, the Implementation Group should develop legal\ndocuments governing the mandate provided by the Regulatory Oversight Committee to the\n- Central Operating Unit as well as other legal documents needed to specify the full governance\nframework for the global LEI system.\nRecommendation 27\n- | BOARD OF DIRECTORS OF THE CENTRAL OPERATING UNIT The Central\nOperating Unit shall have a Board of Directors. The Regulatory Oversight Committee has the :\nright to veto membership of the BOD, as well as to remove members. The ROC-has the right\nto appoint independent members'®. . ~ :\nRecommendation 28\nFORMATION OF THE INITIAL BOARD OF DIRECTORS OF THE CENTRAL\nOPERATING UNIT The Ceniral Operating Unit’s initial Board of Directors should be '\nappointed by the Regulatory Oversight Committee, taking. into account the need for\ngeographic and sectoral diversity. The Implementation Group should develop the fitness\ncriteria, size, role etc for the BOD that should be reviewed in two years by the Regulatory\nOversight Committee. '\n\" Recommendation 29\nPOWERS AND FUNCTIONS OF THE BOD OF THE CENTRAL OPERATING UNIT\nThe Board of Directors of the Central Operating Unit should be granted powers to direct the\nmanagement and operations of the Central Operating Unit in line with the overall standards\nset by the Regulatory Oversight Committee.\nRecommendation 30 '\nCONTINGENCY ARRANGEMENTS The Regulatory Oversight Committee is responsible\nfor setting and overseeing the application of business continuity standards for the global LEI\nsystem in line with best practices for key financial infrastructure. Rules and procedures should :\nbe defined that the Central Operating Unit and Local Operating Units must follow in case of\n18 Tn this context independent members mean non-industry representatives. .\n14 A\n","contentLength":2448,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.386Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":") . all criteria and decisions rclating to the rccognition or de-recognition of LOUS;\n. a conflicts of interest policy; and\n. all audit results.\nThe Foundation shall make arrangements to provide access, as nccessary, to restricted data\nthrough well-defined access conltrols and data sharing protocols.\nHI. INITIAL CAPITAL, ASSETS, SUSTAINABLE FUNDING, LIMITATIONS\nAND ACCOUNTS\nArticle 7 Initial capital\nThe Founder allocates to the Foundation initial funds of CHF 50°000.\nArticle 8 Assets\nThe Foundation's initial capital inay be increased at any time by further contributions of the\nFounder or other third parties as shall be approved by the Board. Coniributions of third\npartics, whether potential or actual, shall not convey any additional rights 1o the contrihutors.\nThe Foundation may own tangible or intangible assets, including intellectual property rights,\n(encompassing all and any righis defined in Article 2 (viii) of the Convention Establishing the\nWorld Intellectual Property Organization; signed at Stockholm on July 14, 1967). Intellectual\nproperty rights should be held for the public benefit and consistent with the attainment of the\npurposes of the Foundation as well as the GLEIS principles. The Foundation shall have the\nexclusive ownership of all those intellectual property rights and the enjoyment and use of\nthose intellectual property rights shall accrue to the benefit of the Foundation. In order to\nattain the purposcs of the Foundation, the Foundation is entitled 1o grant to LOUs royalty-free\nliccnses or, if decmed necessary or appropriatc for the attainment of the purposes of the\nFoundation, licenses subject to payment consistent with the GLEIS principles.\nArticle 9 Sustainable funding\nThe ongoing tunding of the GLEIS should be self-sustainable and rehable. The funding of the\nGLETF should be based on a financial fee bascd on the number of registrants. Any GLEIF\nfunding sources in addition to Lhe above fee must be consistent with public good principles\nand, as a conscquence, must not inure to the benefit of the provider beyond customary\nconunercially available provisions (cost recovery principle). In particular, data access shall\nremain {rce to users.\n7\n","contentLength":2197,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.386Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"insolvency, bankruptcy, etc in order to ensure continuity of the global LEI system. A protocol\nshould also be developed for maintenance of secure parallel copies of the LEL, in a manner\nthat respects local laws. ‘ _\nRecommendation 31\nLEI INTELLECTUAL PROPERTY The LEI Implementation Group should conduct\n| analysis and provide recommendations on the treatment of the “LEI” intellectual property\n(such as the LEI code, software, reference data, any other LEI data, operational protocols, etc)\naccording to the principles of open access and the nature of the LEI system as a public good.\nThe objective of this analysis shall be to ensure a regime that assures the availability in the\npublic domain, without limit on use or redistribution, of LEI data, reference data, and\nprocesses. Any intellectual property rights should be held by, or licensed to the global LEI\nfoundation unless defined otherwise by the Regulatory Oversight Committee. Copyright\nshould be used to the extent possible to promote the free flow or combination of information\nfrom disparate sources. .\nRecommendation 32\nFSB LEI IMPLEMENTATION GROUP Subject to the G-20 supporting further work to\nlaunch the global LEI, and entrusting implementation planning to the FSB, an FSB LEI\nImplementation Group (IG) should be established with a clear mandate to launch the global\nLEI system on a self- standing basis. The LEI Implementation Group should cease to exist\nupon formation of the Regulatory Oversight Committee which should be by 31 March 2013 at\nthe latest.\nRecommendation 33 '\nSTRUCTURE OF THE FSB LEI IMPLEMENTATION GROUP A time-limited FSB\nLEI Implementation Group of interested and willing experts (legal, IT, and other) from the\nglobal regulatory community that includes interested parties from the FSB LEI Expert Group\nshould be formed to take the global LEI initiative forward into the global implementation\nphase until the Regulatory Oversight Committee is established. The IG should be led by :\nrepresentatives from different geographic areas to reflect the global nature of the LEI\ninitiative and will be supported by the FSB Secretariat. The IG should develop proposals for\nthe global LEI system stand-up as defined in the mandate below for review and endorsement |\nby the FSB Plenary in October 2012 and, as appropriate, final review and endorsement by G-\n20 Finance Ministers and Central Bank Governors in November 2012.\nRecommendation 34 '\nRESPONSIBILITIES OF THE FSB LEI IMPLEMENTATION GROUP The mandate of\n, the FSB LEI Implementation Group should be to prepare a draft global LEI Regulatory\nOversight Committee Charter, proposals for the establishment of the LEI Regulatory\nOversight Committee and related structures, develop all necessary legal documents for\nRegulatory Oversight Committee operations, develop necessary intellectual property\nagreements and contracts, conduct research and provide recommendations on LEI related\ninformation sharing arrangements; set up the process and any necessary legal documentation\n. necessary for establishment of the Central Operating Unit and its Board of Directors; and set\n15\n","contentLength":3104,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.387Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"up the process for eétablishment of the necessary standards, protocols, rules and procedures\nand organizational design for the Central Operating Unit.\n\nRecommendation 35 _ » ' .\nESTABLISHMENT OF THE GLOBAL LEI SYSTEM The global LEI system will be\nestablished by the endorsement of the high level Charter for the Regulatory Oversight\nCommittee by the G-20 Finance Ministers and Governors in November or by the FSB Plenary\nin October.\n\n] ' 16\n","contentLength":441,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.387Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"_ | Annex 3: Global LEI System High Level Principies\nThe global LEI system High Level Principles have been prepared to guide the development of\n. the global LEI system, in line with the G-20 mandate of developing a governance framework\nthat represents the public interest. The recommendations for the development and\nimplementation of the global LEI system in Annex 2 draw on the High Level Principles.\n‘ 1. The Global LEI system should uniquely identify. participants to financial\ntransactions.\n2. The LEI system should meet the requirements of the global regulatory community\nfor accurate, consistent and unique entity identification.\n3. The LEI system should be designed in a manner that provides benefits to financial\n' market participants.\n4. . Flexibility must be built into the global LEI system to provide the capability for the\n. system to expand, evolve, and adapt to accommodate innovations in financial\nmarkets. . A\n5. . The LEIL syétem should not be “locked-in” with a particular service provider for any\nkey system functions or processes. The principles of competition should be ensured\non both global and local levels where appropriate. _\n6. The.global LEI system should support a high degree of federation and local '\nimplementation under agreed and implemented common standards.\n' 7. The LEI system should meet evolving requirements of both the regulatory -\ncommunity and industry participants in terms of information content, scope of\n. coverage, timeliness and availability.\n8. The LEI Regulatory Oversight Committee should have the responsibility of\nupholding the governance principles and oversight of the global LEI system\n: functioning to serve the public interest. The Committee has the ultimate power and\nauthority over the global LEI system.\n9. The mission, role and responsibilities of the ROC shall be specified by the global\nLEI Regulatory Oversight Committee Charter, which shall establish the Committee.\n10. Participation in the global LEI Regulatory Oversight Committee shall be open to all\n. authorities subscribing to the High Level Principles and to the objectives and\ncommitments in the Charter. '\n11. The LEI Central Operating Unit should have the mission and role to ensure the\napplication of uniform global operational standards and protocols set by the ROC\nand act as the operational arm of the global LEI system. It shall be established as a\nfoundation or legal equivalent. ‘\n12. The LEI Central Operating Unit should have a balanced representation of industry\nparticipants from different geographic areas and sectors of economy. Its Board of\nDirectors should be selected from indusiry representatives, plus independent\nparticipants. '\n17 -\n","contentLength":2685,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.387Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"\" 13. The LEI system should allow the local provision by Local Operating Units of all LEI\nfunctions which the ROC determines are not required to be centralised.\n14. The LEI system should promote the provision of accurate LEI reference data at the\nlocal level from LEI registrants and ensure global uniqueness of the registrants. '\n15. Any global universal intellectual property rights should belong to the global LEI\n~ system. :\n18\n","contentLength":432,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.387Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"Annex 4: Initial elements for inclusion in a Charter for the global LEI Regulatory\nOversight Committee (ROC) '\nThe initial elements for inclusion in a Charter for the global LEI Regulatory Oversight '\nCommittee (ROC) outlines a number of high level elements that could be considered for\nincorporation in the development of the proposed Charter.\nMission of the ROC : ' '\n\n. To govern the global LEI system in the public interest in accordance with the global\nLEI system High Level Principles. _\n\n. To take any action deemed necessary to protect the public interest in respect of the :\nglobal LEI system.\n\nObjectives of the Charter\n\n. To provide high levél agreement on the governance framework for the global LEI\nsystem.\n\n. To establish the ROC as the regulatory governance body for the global LEI system.\n\nL To specify the mandate and objectives of the ROC.\n\n) To provide the ROC with authority and power to take any action necessary to protect\n\n» the public interest in respect of the global LEI system.\nCommitments and Obligations\nAuthorities abiding by the Charter agree to:\n\n. Uphold the agreed, global, governance principles to protect the public interest in\nrelation to the global LEI system. '\n\n. Participate in the work of the Regulatory Oversight Committee. :\n\n. Support the introduction of the global LEI for regulatory purposes.\n\nMembership\n\n) Participation in the ROC shall be open to all regulatory authorities, jurisdictions and\n\nsupranational authorities that agree to the High Level Principles for the global LEI\n_ system and that are willing to subscribe to the commitments specified in this Charter.\nMandate and Responsibilities of the Regulatory Oversight Committee\n\n. The ROC shall have responsibility for upholding the governance principles and\noversight of the global LEI system functioning to serve the public interest. '\n\n. The ROC shall have responsibility for protection of the public interest: to protect the\npublic good of the global LEI system and to mitigate any potential for the\nexploitation of privilege and market power. Specific objectives include:\n\no Assuring open and free access to publicly available data.\n19\n","contentLength":2149,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.387Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":". Data should be non-proprietary, with no ‘bundling of services', or\nrestrictions on aceess or redistribution;\n\n' . - All public data should be readily available on a continuous basis, free .\nof charge;\n\n\" Confidential data must be suitably protected,; '\n\n- Data and’ operating processes should not be subject to any type of\nIntellectual Property restrictions; '\n\no Assuring open access to the acquisition of an LEI. Entities required to, or\nwishing to, obtain an LEI should be able to acquire one under open, and non-\ndiscriminatory terms:\n\n. \" Fees, where and when imposed, should be modest and set on a non-\nprofit cost-recovery basis®®, The operational model must be efficient\nand avoid excessive costs. Budgeting frameworks should be clear and\nconsistent. :\n\n. No restrictions should be placed on the use of the LEI by the registrant.\n\n-0 No competitive advantage should apply to any entity involved in the LEI\n\nsystem. _\n\no Ensuring that the LEI system meets public sector requireménts, including:\n\n' . Ehsuring uniqueness, accuracy, reliability, portability and persistence -\nof the LEI code and reference data. ‘\n\n. Proposing new standards for the LEI system that serve the public\ninterest and reflect market changes. Modifying existing standards as\nrequired.\n\n. = Promoting the use and scope of the LEI to expand the collective benefit\n: “from widespread adoption. }\n\n. Utilising local language and character sefs, as well as ensuring access\nto the whole system in a common language.\n\n. The ROC shall have the ultimate responsibility for developing standards and general\npolicies and overseeing the functioning of the global LEI system in the public\ninterest irrespective of whether those functions are delegated or not. This should\ninclude the following:\n\no Plans, policies, and strategy for the global LEI system ,\n\n' o Standards for LEI reference data - :\n. o Approval of budgets of the Central Operating Unit\n. o Approval of material contracts to avoid ‘vendor dependence’ '\ni 9 The LEX should be freely and openly available and should not be tied (or ‘bundled’) to the provision of other services. -\n20 1t is possible that some jurisdictions could be willing to fund the LEI issuance from public sources and provide LEIs to its\nlocal entities free of charge.\n20\n","contentLength":2282,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.387Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"' 0 Business continuity standards :\no Audit of the system for financial control, best business practices, data quality '\n» standards, etc. o _\n0 Recognition and termination of Local Operating Units and registration\nagenciesm. i\nFunctions and Powers\n. The ROC has the ultimate power and authority over the global LEI system. Any\npower delegated to the Central Operating Unit, Local Operating Units and other\nentities can be reversed by the ROC.\n) The ROC has responsibility for establishing the global LEI foundation or body of\nequivalent legal form as a legal form that will operate the Central Operating Unit as\n} well as the criteria for participation in the foundation. ‘\ne The ROC shall appoint the initial Board of Directors of the Central Operating Unit\nand has the power to veto or remove Directors thereafter. The ROC has the power to\nappoint independent Directors to the Board of the COU.\n. The ROC should establish a formal oversight plan to ensure that its directives to the\nCOU or to other parts of the global LEI system are enforced and that the governance\nprinciples are upheld.\n) The ROC has the right and should have the ability to audit the parties engaged in the\nglobal LEI system and appoint independent auditors. _\n- o The ROC should have the ability to adjudicate disputes. '\n' Structure of the ROC _\ne The ROC should be composed of the ROC Plenary and ROC Executive Committee. |\n. Plenary: All participating authorities shall be members of the Plenary. The Plenary is\nthe ultimate decision making body of the ROC.\n. Executive Committee: An Executive Committee shall be selected from among the '\nPlenary membership to direct the functioning of the ROC.\no Membership shall be balanced jurisdictionally and regionally and also in terms\nof expertise and functions (eg prudential regulators, market regulators, central\nbanks, etc). Criteria to be determined.\no Responsibilities of the Executive Committee to be determined.\n. Chair: A chair of the ROC shall be appointed. Role, terms, appointment procedure,\netc to be determined.\n. Observer status: Authorities may participate as observers in the ROC. Role of\nobservers and criteria for participation to be determined.\n2l Tocal authorities may also reserve rights to be engaged in decisions on local registration operations to the extent that they\nact in accordance with the High Level Principles of the LEI system. i\n21\n","contentLength":2394,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.387Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"Decision making - _ '\n. Decisions shall be made by consensus, wherever possible.\nS Voting arrangements to be decided in cases where consensus is not possible. :\nSub-Committees and Advisory Panels\n\n. The ROC will create Sub-Committees to undertake key functions as it judges '\nnecessary. The mandate and responsibilities of any such Sub-Committees shall be\ndecided by the ROC.\n\n. The ROC may also appoint public or private sector Advisory Panels as it judges\nnecessary.. :\n\nSecretariat and Administration\n\n. A ROC Secretariat should be formed to support ROC activities as required.\n\n. Size, role, and location of any central secretarial function for the ROC to be\ndetermined.\n\n. The cost of any central governance function shall be provided from centrally\ncollected registration fees. .\n\n| Establishment\ne The ROC shall be established upon endorsement of this Charter by the G-20/ FSB.\n: The Charter will spell out the timeline and process to form the ROC as an operational\nCommittee (eg membership, nomination of Chairman, secretariat, etc).\n22 '\n","contentLength":1047,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.387Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"A Global Legal Entity Identifier for Financial Markets\n' .23 | |\n","contentLength":65,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.387Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"I. Introduction :\nIntroducing a single global system for uniquely identifying parties to financial transactions\n' would offer many benefits. There is widespread agreement among the global regulatory\ncommunity and financial industry participants on the merits of establishing such a legal entity '\n“identifier (LEI) system. The system would provide a valuable ‘building block’ to contribute to\nand facilitate many financial stability objectives, including: improved risk management in\nfirms; better assessment of micro and macroprudential risks; facilitation of orderly resolution;\ncontaining market abuse and curbing financial fraud; and enabling higher quality and\naccuracy of financial data overall. But despite numerous past attempts, the financial industry\nhas not been successful in establishing a common global entity identifier and lags well behind '\nmany other industries in agreeing and introducing a common global approach to entity\nidentification. '\nThe financial crisis has provided a renewed spur to the development of a global LEI system.\nInternational regulators have recognised the importance of the LEI as a key component of\nnecessary improvements in financial data systems?. The value of strong co-operation\nbetween private sector stakeholders and the global regulatory community is widely accepted.\n~ To provide additional impetus, the FSB was given a mandate by the G-20 to lead the co-\n ordination of international regulatory work and to deliver concrete recommendations on the\nLEI system by June 2012: _\n“We support the creation of a global legal entity identifier (LEI) which uniquely identifies\nparties to financial transactions. We call on the FSB to take the lead in helping coordinate\nwork among the regulatory community to prepare recommendations for the appropriate\ngovernance framework, representing the public interest, for such a global LEI by our next\n: ‘Summit.” (Cannes Summit Declaration)\nTo take the work forward, the FSB set up a time-limited Expert Group of key stakeholders\nwith the following mandate:\n) To deliver clear recommendations with respect to the implementation of a global LEI\nsystem to the FSB Plenary for endorsement. Specific recommendations should be\npresented for the following package: -\no Governance framework for a global LEI;\no Operational model; ‘\no Scope of LEI reference data, access and confidentiality;\no Funding model; ‘ ’\no Implementation and phasing. '\n22 Committee on Payment and Settlement Systems and Technical Committee of the International Organization of Securities\nCommissions, Report on OTC derivatives data reporting and aggregation requirement, final report, January 2012.\n24 ' :\n","contentLength":2663,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.387Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"Article 10 Limitations\nThe revenues, if any, which may be realised by the Foundation shall be used exclusively in\nfurthcrance of the Foundation's not-for-profit purpose.\nNo substantial part of the activities of the Foundation shall be the carrying on of propaganda,\nor otherwise attempting to influence legislation or rulemaking. The Foundation shall not\nparticipatle in, or intervene in (including the publishing or distribution of statements) any\npolitical campaign on behalf of (or in opposition to) any candidate for public office in any\njurisdiction.\nNo part of the net carnings of thc Foundation shall inure to the bencfit of, or be distributable\nto, any dircctor, officer, or other private person except that (he Foundation s authorised or\nempowered upon approval of the Board to make payments and distributions in furtherance of\nits purpose.\nArticle 11 Accounts\nThe Foundation's financial year runs from January 1st to December 31st. The first financial\nyear ends on Deccmber 31, 2014,\nThe Foundation's accounts shall he beld in Swiss francs (C11I) or a foreign currency such as\nUS dollars (USD) and in compliance with international accounting standards admitted under\nSwiss law.\nIV. GOVERNANCE\nArticle 12 The Foundation Bodies\nThe corporate bodies of the Foundation are:\n. the Board of Dircctors (tbe \"Board\" see V. A below);\n. the Auditors (sce V., B below);\nV. A: THE BOARD OF DIRECTORS\nArticle 13 Composition of the Board\n8\n","contentLength":1436,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.388Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"The FSB Plenary has reviewed and approved the recommendations of the Expert Group®.\nThis Report provides the recommendations of the FSB to the G20 Summit for the\ndevelopment and implementation of the global LEI system. It has eight sections. Section II\n: outlines the objectives of the global LEI system and the potential benefits and uses.\nChallenges to overcome in developing and implementing a global system are addressed in\nSection III. The subsequent section sets out principles underpinning the framework and\ndesign of the global LEI system. Section V outlines the potential coverage of the LEI and the\nreference data associated with it. Section VI describes the operational framework for the\nglobal LEI system, highlighting the key operations and functions. The following section\noutlines the specific regulatory objectives required to protect the public interest and sets out\nproposals for a global governance framework to deliver them. Section VIII provides concrete\nrecommendations on the launch of the global LEI system, including setting:out the way\nforward and next steps. '\nIL Objectives of the global LEI system :\nThe current problem The lack of a common, accurate and sufficiently comprehensive\nidentification system for parties to financial transactions raises many problems. For example,\nas outlined in the recent report by CPSS-IOSCO on OTC derivatives data reporting and\naggregation requirements®*, a single firm may be identified by different names or codes which\nan automated system may interpret as references to different firms. Thus in the example\noutlined, the firm J.P.Morgan may be identified as “Morgan”, “JP Morgan”, “J.P.Morgan”,\n»JPM>, or “J.P. Morgan” which an automated system may ascribe to different entities, thus\nrendering data aggregation and validation very difficult. Individual firms may resolve this by\nspending large amounts of money on “data cleaning” and on developing bespoke IT and data\nmanagement systems to enable internal reconciliation and data aggregation. Such systems are\ncostly and cannot be reconciled across firms. Deadweight costs across the economy from such )\nan approach are high. . ‘\nObjectives of the global LEI system The ultimate aim is to put in place a system that could\ndeliver unique identifiers to all legal entities participating in financial markets across the\nglobe. Each entity would be registered and assigned a unique code that would be associated .\nwith a set of reference data (e.g. basic elements such as name and address, or more complex\n. data such as corporate hierarchical relationships). Potential users, both regulators and _\nindustry, would be granted free and open access to the LEI and to shared reference\ninformation for any entity across the globe and could build this into their internal automated\nsystems. A high quality LEI would thus offer substantial benefits to financial firms and\nmarket participants that currently spend large amounts of money on reconciling and validating\n2 Membership of the Expert Group comprised representatives from both FSB members and key non-members from the\nglobal regulatory community with a major stake in the initiative such as the CFTC and ESMA. The Expert Group greatly\nbenefited from the active input and advice of a private sector Industry Advisory Panel of 34 experts from across the globe\nas well as from participants in a public/private sector workshop in Basel in March.\n2% Commiitee on Payment and Settlement Systems and Technical Committee of the International Organization of Securities\n‘ Commissions, Report on OTC derivatives data reporting and aggregation requirement, final report, January 2012.\n25\n","contentLength":3642,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.388Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"counterparty information, as well as offering major gainis to risk managers and the regulatory\n‘ community in relation to the identification, aggregation and pooling of risk information.\n\n_ Public sector interests and uses A system enabling unique identification of legal entities, -\nsupported by high quality reference data, offers substantial benefits across a wide range of\nregulatory work and financial stability analysis. The LEI provides a powerful foundational\ntool to enhance the monitoring and management of systemic risks. Among the potential\nbenefits are:\n\no Improved data aggregation and analysis: It will be easier to combine and verify\ndata, both within individual firms, supporting microprudential risk assessment, and '\nacross firms, supporting the mapping of system-wide risks and macroprudential\nassessment. That should also improve the quality, accuracy and integrity of\nregulatory data capture systems and of financial data overall. The first use of the LEI\n\n\" in a number of jurisdictions will be for the reporting and aggregation of data on OTC\n: derivatives as recommended by CPSS-IOSCO?. -\n\ne Enhanced prudential supervision: As well as supporting better internal risk\n\nmanagement, a common identifier will facilitate information sharing about legal\n: entities between regulators and across borders. That will enable better supervision of\n\ncross-border firms and firms whose business lines are overseen by multiple\n\nregulators. ‘ ’\n\n. Support for orderly resolution: Improved clarity on internal structures of complex '\nfirms and on exposures by individual legal entity will support enhanced crisis\nmanagement and resolution®. ' '\n\ne Protection against market abuse: Clear and unique identification of parties to -\nfinancial transactions should act as a bulwark against market abuse and help to curb :\nfinancial fraud. - .\n\nPrivate sector interests and uses Introduction of a high quality global LEI system would\nalso provide substantial gains to private sector participants in financial ‘markets. Particular :\nbenefits include: '\n\n) Improved risk management: The LEI would enable firms to strengthen the\naccuracy, integrity, and aggregation of data across entities and subsidiaries and thus\nimprove counterparty risk data and management, as well as supporting enhanced data\nmodelling and analysis. Better data would also facilitate limit setting and position . '\nmonitoring.\n\n° Operational efficiency: Many firms spend large sums of money on data cleaning\nand reconciliation of data and positions across different business lines and internal -\n\n- entities. An accurate global LEI system with widespread take up among financial\n- market participants could lead to large gains in processing and settlement efficiency,\nby enabling and underpinning automated straight through processing of information. :\n% Committee on Payment and Settlement Systems and Technical Committee of the International Organization of Securities\nCommissions, Report on OTC derivatives data reporting and aggregation requirement, final report, January 2012, ’\n% FSB, Key Atiributes of Effective Resolution Regimes for Fifiancial Institutions, October 2011,\n26 . .\n","contentLength":3163,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.388Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"Such gains would benefit all financial market users, as efficiency savings are passed\non to customers.\n\n. Enhanced regulatory reporting: A global LEI system should lead to more precise\nand accurate regulatory reporting, as well as supporting the production of data for\nrecovery and resolution planning.\n\nGlobal coverage The benefits of a legal entity identification system arise from widespread\nadoption. As with other identification systems and networks, users obtain additional benefits\nthe more other users adopt the system. The maximum benefits consequently accrue from\neventual implementation across the whole global financial system. To support that ultimate\naim, an important objective is consequently to ensure that widespread take up of the system is\nencouraged and that appropriate account is taken of important national characteristics in\ndesigning the governance and operational characteristics of the global system. -\nGlobal unique number The benefits also arise from a guarantee of uniqueness — that the LEI\n_ code provides an accurate and unique link to the particular registrant, and that the associated\n\nreference data are up to date and reliable. The existence of multiple LEIs for the same entity\nwould quickly lead to a breakdown of trust and confidence in the system that would lead to\nrapid obsolescence and a loss of all the potential benefits. Ensuring that each entity has a _\nunique code is an essential objective of the system.\n\nCORE LEI DATA ELEMENTS\n\n(see Recommendation 9 for a complete list) LEGAL ENTITY IDENTIFIER \\\n\n: o Legal entity name\n\nL Addre—ss of the headquarters - YUVS8PRHOZSRFRC4T0269\n\ne Address of legal formation\n\no Business registry ID (where\n\napplicable) L\n\ne Business registry name (where\nGlobal consistency Users are looking for high quality reliable information on all entities\nregistered in the global LEI system. An important objective is consequently to ensure that\nhigh standards apply to the registration of entities and to the granting of the LEI, and that\nthere is consistency of approach across the whole system. _\n\n- Examples from other industries There are a number of examples of successful introduction\nof identification schemes in other industries from which the financial sector can draw.\nProminent examples are supply chain management in the consumer goods industry (using bar\ncode technology), transportation of hazardous chemicals, and recent initiatives to identify and\ncodify products in the entertainment and music industries. In each case there was sufficient\n\n27\n","contentLength":2535,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.388Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"co-ordination and collective interest to overcome the inertial forces outlined above, and to\ncapture the benefits from a common, unique, identification scheme.\nRecent private sector initiatives to introduce an LEI in the financial sector Over the past\nseveral years, there has been renewed interest in the financial sector in the introduction of an\nLEI, stimulated by regulatory proposals to improve the reporting and aggregation of data on\nOTC derivatives in line with G-20 recommendations, but also stemming from the recognition -\nof the collective benefits to financial market participants of a unique identification system.\nThe private sector is undetstandably very keen to harness such benefits and to offer proposals\n\n\" for the design and implementation of the system that draw on private sector expertise in\nbuilding and running financial market infrastructure. It is important to draw on. private sector\nexpertise in such operations and to marshal competitive forces where possible to promote\nefficiency and encourage innovation. A number of proposals were put forward in response to\nthe CPSS-IOSCO consultation paper on the reporting and aggregation of OTC derivatives\ndata. A recurring aspect, however, in the responses is that regulatory support for the initiative -\nis an important element, to provide comfort that there will be sufficient take up to overcome ,\nthe disincentives that inhibit early adoption described above.\nIII. Key considerations and challenges to overcome in building a global LEI system\nIn designing and implementing a unique entity identification system for parties to financial\ntransactions, there are a number of challenges to overcome. This section addresses a number\nof market failures that have to date prevented the introduction of such a system and how they\nmay be resolved. It also highlights a number of issues that need to be taken account of in the\ndesign and implementation, to ensure that the maximum benefits are captured and that\nperverse incentives are mitigated and do not undermine the system. .\nWhy is there not a comimon, accurate and comprehensive global identification system in\nfinancial markets? Given that a unique LEI system is a simple idea which offers manifold\n\n- benefits, an obvious question is why is such a system not already in place? The principal.\n\nreason is that the benefits of the system are collective and accrue to users and the broader\npublic as a group. There are insufficiently strong incentives in private markets to overcome\ntwo sources of market failure:\n\n. Collective action and co-ordination problems: To take the initiative forward, there\nfirst needs to be collective agreement that a particular identification system is the\nright one. Each individual firm has a natural incentive to promote their own system\nas that would minimise the costs of adoption. Gaining widespread agreement on a\ncommon system to be used by all parties is difficult. But without it, there is no\nincentive to move. ‘\n\n. Network effects: As highlighted above, the benefits from the system increase as more\nand more parties acquire an LEL The larger the network, the larger the gains. At the\nlaunch, however, as with other examples of network goods such as the telephone, the\nprivate incentives for potential early movers to acquire an LEI are low. For example,\nwithout extensive coverage of financial entities, there would clearly be little potential\nbenefits provided from better codification and aggregation of counterparty trades and\n\n: 28\n","contentLength":3501,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.392Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":": risk positions. To date, it has consequently proved impossible to get over this initial\nhurdle relying purely on market incentives and voluntary adoption.\nThese market failures support the view that the LEI is by nature a public good, offering\ncollective benefits that are hard to capture by private market incentives. Overcoming them\nwithin the private sector alone relies on strong co-operation and co-ordination among key\nstakeholders. That is necessary to ensure that there is sufficient adoption and take up by\nmarket participants to generate critical mass and to provide network benefits. In practice, ,\npublic intervention, for example, that mandates the use of the LEI for reporting of exposures\n- or positions, may be needed in some cases-to break down such barriers and take the initiative\n' forward. Removing such barriers would provide an opportunity for a co-ordinated approach\nbetween the public and private sector in delivering a global LEI system. The role of the public\n, sector is to put in place a governance framework that protects the public interest. That in turn\nprovides a platform to harness the technical skills of the private sector to deliver an effective\noperational system, underpinned by market forces and incentives. _\nWhy public sector governance is required There are many areas where public and private ‘\nsector interests in the global LEI system are fully aligned (such as unique identification of\nentities, high quality reference data, integrity of systems, etc). But as the LEI system is by\nnature a public good; there is a need to make sure that the gains for the broader public are '\ncaptured and that provision of the LEI is not exploited in ways that do not benefit the public.\nIn particular, while offering many benefits, a potential undesired consequence of active\nregulatory promotion of the system is that it also provides substantial power to the provider(s)\n.of the system. Abuse of such power could work against the fundamental public interest. For\nexample, if regulators mandate use of the LEI system, then both LEI registrants and users\nhave no alternative but to use it. The market is captive. There are consequently incentives for\nsuppliers of the LEI to exploit their privileged position and hence risks that suppliers face\nincentives to overcharge registrants, restrict access, cut corners on data quality, or to use a\n' position of privileged access to LEI information to supply other revenue-generating services\non nop-competitive terms. These arguments provide the motivation for the mandate provided\nto the FSB to produce recommendations for a governance framework for the LEI that\nidentifies and provides strong protection of the public interest. ‘\nThe case for public intervention As highlighted above, public intervention promoting the\nuse of the LEI is likely to be needed to overcome the market failures outlined above. For\nexample, mandatory use of the LEI for public reporting would encourage respondents to adapt\n' their internal systems to meet the new demands. A major associated benefit is that consistent\nintroduction of the public requirement resolves the collective action problem (as all reporters\nare required to use the chosen system) and helps to solve the network problem (as the public\nintervention eliminates the initial disincentives to adopt the system at the start). Promotion of\nthe LEI by the global regulatory community would consequently offer multiple benefits to\nboth the public and private sectors.\nUniformity of principles, standards, and operational approaches To foster confidence in\nthe quality of the LEI which is essential if there is to be widespread adoption and usage, it is\nimportant that there is a unique identifier for each acquiring entity, and that there are high, _ 7\nconsistent operational principles and standards applied to the origination and maintenance of\nan LEL Such principles and standards will facilitate the consistent integration into a global\n' _ _ 29 ‘\n","contentLength":3975,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.392Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"system of entities from jurisdictions with different regulatory, legal systems and local\nlanguage character sets that are important to reflect and take into account if all such\njurisdictions are to feel comfortable in joining the system. The governance framework and\noperational model implementation must ensure that the common standards are applied across\nthe system to deliver the necessary consistency, and enable users to access the whole system\nfrom a common source. . .\nThe global reach: expandability and adaptability In order to generate the maximum\nnetwork benefits from broad coverage, it is important that the system has the capacity to\nexpand quickly to include new jurisdictions and new registrants. Clear processes and\nprotocols should be in place to facilitate the integration of registrars and registrants from new\nmembers into the system. It is also crucial that the global system is flexible, extendible and\nadaptable to take account of changes in financial markets and new potential uses. For\nexample, there must be clear procedures for the identification and introduction of new\nreference data where warranted.\nConfidentiality challenges The gains from the introduction of the global LEI arise from\nunique identification of entities, from the links to high quality reference data relating to the\nentities, and from widespread adoption of the system. The provision of open and free access\nto publicly available data is an important objective. One challenge is that there are\nconfidentiality and privacy restrictions governing some potentially important reference data in\nsome countries, particularly regarding information on corporate relationships and ownership\nstructures. Such data are important to both the global regulatory community and private firms\nas they enable aggregation of information within complex financial groups which is essential\nto the analysis of exposures and to the development of improved systemic risk measures. The\ngovernance system design must, therefore, take account of the legal constraints on the storage\nand transmission of such data, for example, by ensuring that the data are stored in particular :\njurisdictions and that there are rigorous controls on access.\nIncentives for regulatory and industry adoption As highlighted above, support from the\nregulatory community for the adoption of the LEI in different areas of regulatory reporting\nwould help to break down the collective action problems and stimulate usage and take up. A -\n- key consideration in the design of the proposed governance framework and operational model\nis consequently to ensure that the approach meets the requirements and needs of the\nregulatory community across the globe, in order to deliver widespread buy in. Equally, it is\nimportant that the adopted approach meets the needs of financial market participants for a\nunique entity identification scheme, so that voluntary take up is encouraged alongside usage\n. promoted by financial regulators. Ensuring that there are incentives fo atfract market\nparticipants to register voluntarily for an LEI is consequently an important goal.\nThe role of the private sector in delivering the global LEI system While the public sector\nhas a key role to play in overcoming market failures and providing an accompanying strong '\ngovernance framework to protect the public interest, the private sector has an equally\nimportant role in building and operating the system that delivers the global LEIL Experience\nfrom many other industries in developing, designing and successfully implementing\nidentification systems clearly demonstrates that the challenge of building a global LEI system\nfor the financial sector is not primarily technological. But equally, it is essential to draw\neffectively on private sector expertise and know how to make sure that the operational\n. _ 30\n","contentLength":3841,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.392Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"framework is efficient, technically sound and robust, and benefits wherever possible from\n\nmarket forces and competition.\n\nA key aim of the governance framework is to set out a platform of objectives, guidelines, and -\nstandards for the global LEI system which then enables the private sector to innovate in '\ndelivering technical and operational solutions. The challenge is to ensure that the framework\nprovides the appropriate incentives to leverage private sector expertise and experience, and to\n\nbenefit from market forces wherever possible across a range of issues:\n\ne _Technical and operational expertise: the private sector has considerable expertise in\ndesigning, building and operating identification schemes in other industries, as well\nas in some areas of the financial services sector (such as schemes for identification of\nsecurities and systems for bank transfers).\n\n. Local expertise: to deliver a truly global system, specialist knowledge of local legal\n\n' frameworks, corporate structures, as well as availability of the system in local\nlanguages, etc is critical.\n\n. Encouraging competition and innovation: subject to ensuring accordance with the\nagreed common standards, encouragement of competition and innovation is desirable\nto promote efficiency and lower costs. )\n\no Promoting consistent standards: the private sector has considerable experience in the\ndesign and operation of consistent technical standards. : _\n\nPublic — private sector co-ordination Drawing on the elements above, developing and\n\nimplementing a global LEI system requires active support and involvement from both the\n\nglobal regulatory community and from the private sector. The public sector must put in place\n\na governance framework with a number of key objectives: to support the delivery of a public\n\ngood; to ensure that public interests in the system are protected; to promote common\nstandards; and to facilitate widespread global adoption. Such a framework will provide a\n\ntransparent, open system,. that protects against the risk of abuse of monopoly power and\n\n7 privilege, and that facilitates adoption. Under this broad governance framework, it is\n\nimportant to provide market incentives for the private sector to develop and implement\n\neffective operational solutions: to draw on expertise and specialism in local jurisdictions and\n\nglobally in the development and operation of registration, identification and information\n\nsystems; to gain from the benefits of competition while facilitating co-operative solutions\n\n\" where appropriate; and to promote standardisation of approaches across the globe.that benefit\n\n~ international financial markets and global financial integration. The proposals and\n\nrecommendation in the report consequently set out a framework that attempts to capture the\n\nbenefits of both public sector and private sector involvement in taking forward the global LEI\n\ninitiative, while attempting to bridge different views on the appropriate boundary between\n\npublic and private sector responsibilities.\n31\n","contentLength":3034,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.392Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"IV. Principles underpinning the framework and design of the global LEI system\nBased on the above analysis of the main challenges and options to overcome them, the FSB\nhas set out a number of recommendations and principles that help to set out the framework '\nand design of the global LEI system and to take the initiative forward. Subsequent sections\nprovide a series of practical recommendations for implementation in each of the areas of the '\ndetailed mandate that draw on these principles. '\nRecommendation 1 -\nSETTING UP A GLOBAL LEI SYSTEM The FSB strongly supports the development and\n| implementation of a global LEI system that uniquely identifies participants to financial\ntransactions. _\n| Recommendations for the public sector\n\nRecommendation 2 '\nGLOBAL REGULATORY COMMUNITY REQUIREMENTS The LEI system should _\nmeet the requirements of the global regulatory community (including supranational\norganisations). The potential benefits of the LEI include: to support authorities jn fulfilling\ntheir mandates to assess systemic. risk and maintain financial stability; conduct market -\nsurveillance and enforcement; supervise market participants; conduct resolution activities;\nprepare high quality financial data and undertake other regulatory functions.\nAs set out earlier, the global LEI system offers substantial potential benefits to the global\nregulatory community. It is important that the governance framework and system design\nprovide a framework that enables regulatory requirements to be fulfilled-and that offers\nflexibility to adapt to changing regulatory requirements as financial markets adjust. The\nframework must also provide flexibility for expansion, as jurisdictions and regulatory\nauthorities will implement the LEI system on a phased basis. :\nRecommendation 3 . -\nGLOBAL LEI SYSTEM GOVERNING DOCUMENTS Global LEI system High Level\nPrinciples set out the principles and commitments that specify and define the governance and\nstructure of the global LEI system. A global LEI Regulatory Oversight Committee Charter\nshould specify the mission, role and responsibilities of the Committee as well as the process\nfor its establishment. Support for the High Level Principles agreement and Charter will\nindicate a desire to participate in the global LEI system. o\nTo provide high level commitment and support for a global governance framework for the\nLEJ, the FSB recommends support for High Level Principles for the global LEI system and\nthat a global LEI Regulatory Oversight Committee Charter should be drawn up in the coming |\nmonths. The Charter would establish a Regulatory Oversight Committee (ROC) to represent\nthe public interest in the functioning of the LEI system. As discussed further below, the\nCommittee would serve as the primary governing body. The Charter would specify the\n\n' mission, responsibilities, and powers of the ROC, as well as the commitments attached to the\n\n. 32 . .\n","contentLength":2918,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.392Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"proposed governance framework which is set out in Section VII below. The principal idea\nbehind the High Level Principles document and the ROC Charter is to embed high level\nsupport for the system and its guiding principles and to garner commitment to implement a\nglobal governance framework in order to maximise the benefits. : :\nAll authorities and jurisdictions willing to participate in the development of the global LEI\nCharter should be able to do so without any hindrance.\n\nRecommendations for the Private Sector\n\nRecommendation 4\n\nSUPPORT OF FINANCIAL MARKET PARTICIPANTS The LEI system should be\ndesigned in a manner that provides benefits to financial market participants.\n\nAs emphasised above, widespread adoption of a common LEI system offers substantial\n\npotential benefits to private financial market participants. These include: fulfilling domestic\n\nand multi-jurisdictional regulatory and statistical reporting requirements; facilitating straight-\n\nthrough processing; improving internal risk management and other business purposes. Such a\n\nsystem should accommodate the business needs of all financial market participants, including\n\nfinancial and non-financial companies of different sizes and type, sited in different geographic :\n\nlocations across the globe and provide open access to the global LEI data in a common\nlanguage, while accommodating local jurisdictional differences such as local language and\n, legal framework. It is important that the design and operation of the system enables such\n\nbenefits to be captured effectively and efficiently.\n\nRecommendation 5\n\nSYSTEM FLEXIBILITY Flexibility must be built into the global LEI system to provide the\n\ncapability for the system to expand, evolve and adapt to accommodate innovations in\n\nfinancial markets. It must also allow the seamless introduction of new participants. To these\nends, critical software and other relevant elements must be defined and made publicly\navailable without any licensing, intellectual property or similar restrictions under open source\n\nprinciples. The LEI should be portable®” within the global LEI system. ,\n\nA key objective is to ensure that the system can expand to incorporate new users and new uses )\n\nand that sufficient flexibility is built into the system design to facilitate adaptation to financial\n\nmarket innovations and associated changes in regulatory and market requirements. '\n\nA second key element is that the design should be open and not proprietary, so that any\n\npotential candidate wishing to offer relevant services can do so, subject to meeting the agreed '\n\ncommon standards necessary to deliver an integrated system. This objective is also essential\n\nto promote competition and to foster innovation.\n\n21 In this context a portable LEI means that the code could be transferred from one LOU to another LOU. This may be\nnecessary, for example, in case of the LEI being obtained originally from a foreign LOU before a local LOU was\nestablished or if an entity changed its legal address or headquarters, etc.\n\n33\n","contentLength":3039,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.392Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"Recommendation 6 :\nCOMPETITION AND ANTI-TRUST CONSIDERATIONS The LEI system should be\n| designed to ensure that it is not “locked-in” with a particular service provider for any key .\nsystem functions or processes, and that the principles of competition are ensured on both\nglobal and local levels where appropriate. The governance framework should provide\n_ safeguards to ensure that competition principles and anti-trust considerations are upheld. The\nlocal implementation of the global LEI system should meet local anti-trust requirements.\nIt is important that protections are built into the system to avoid ‘vendor or third party\n: supplier dependence’ that is associated with a build up of market concentration and power.\nFlexible system design and control of intellectual property rights are important tools to avoid\nproviding power to the providers that ensures that the systém relies on their services, or that\nthe system cannot function in the event that a particular supplier of services enters insolvency.\nGiven the risks that mandatory regulatory use of the LEI could create privileged positions in\nthe market place, it is important that due consideration is given to anti-trust obligations in\nterms of the arrangements for the provision of identifiers. In particular, it is important that\ncompetition law and anti-trust considerations are factored in and that appropriate protections\nare put in place to prevent abuse of monopoly positions. :\nSubject to meeting the common standards of the global LEI system, éncouraging competition,\nwherever appropriate, is highly desirable to control monopoly privileges, to help contain\ncosts, stimulate efficiency and promote innovation. :\nRecommendation 7\nFEDERATED NATURE OF THE LEI SYSTEM The global LEI system should support a\nhigh degree of federation and local implementation under agreed and implemented common\nstandards. ‘\nA key objective is to encourage widespread global take up of the LEI system. Subject to\nmeeting the common protocols and standards that are needed to tie the system together to\nprovide a logically consistent database that guarantees unique identification (provided by the\nCOU); the FSB recommends that the global LEI system should support a high degree of\n: federation and local implementation. That is likely to provide additional flexibility, for\nexample to map and incorporate existing local registration and identification schemes into the\nglobal system and thus support the key objective. The federated system will also allow the\naccommodation of local jurisdictional differences such as a local language, legal framework,\nete. _ '\nIn particular, the FSB recommends that the global LEI system should be designed, operated\n_ and governed in a manner that ensures unique identification and consistency at the global\nlevel, while drawing on distributed local elements and local infrastructures that give\nadditional flexibility to provide a high level of validation of the local registration data and to\nmeet local jurisdictional requirements. Although local operations may operate flexibly, all |\nmust meet a common requirement of presenting a common interface between local data\nsystems and the global registry system. :\n. 34 '\n","contentLength":3212,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.392Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"The Board shall be composed of 2 minimum of fiftcen (15) and a maximum of twenty-five\n) (25) Board Members.\n\nAt least one Member of the Board with signatory power shall be a Swiss citizen or citizen of\n\nan EU/EFTA Member State with histher domicile in Switzerland.\n\nIn order to cnsure the right balance of excellence and diversity in the composition of the\n\nBoard, the recruitment of Board Members shall be guided by the following principles:\n\n. Required_skills: To balance strategic creative thinking with strong pragmatic\nskills, the successful candidates should have collective expertise spanning\nacross organisational {opcration, negotiation, planning, international expcrience\nand cross-culiural awareness ete.), technical (data management, identification\nsystem knowledge, etc.) and legal (IP law and practice, privacy legislation,\nnon-profit sector, etc.) matiers;\n\n. Scctor representation: To ensurc a diversity of knowledge, the expertise of\nBoard Members should collectively span across the data and technology,\nfinancial, nonfinancial industry and non-profit sectors and include one or more\npublic or independent Members who, as individuals, are to act in the broad\npublic intercst, as outlined in the ROC Charter;\n\n. Geographic representation: There should be a minimum number of three (3)\nMembers from each of the four (4) regional groupings: North America\n(including Mexico and the Caribbean); Europe (including the Commonwealth\nof Independent States); Asia (excluding the Middle East); Central and South\nAmcrica, Africa, Oceania, and the Middle East.\n\nBoard Members shall at all umes be subject to fitncss and properness criteria, and in\n\nparticular will not be appointed if they have been disbarred from participating or acting in any\n\nnon-for-profit, for-profit, professional charitable or other organization by any national or\n\ninternational bodies or determined to be guilty of any unethical or illegal activity.\n\nThc Board sbould undertake periodic recommendations on the principles [or recruitment of\n\nBoard Members in close consultation with the ROC.\n\nArticle 14 Appointment of the initial Board and of the Chair\n\nThe Meinbers as well as the Chair of the mitial Board of the Foundation shall be appointed by\n\nthe Founder in the Foundation deed (sce annex 4).\n\nArticle 15 Appointment and removal of Board Members\n\nFor all subsequent Board Members, a nomination procedure shall be coordinated by the Chair\n\nof the Board from a pool of candidates subject to an open, transparent process, in consultation\n9\n","contentLength":2526,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.392Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"V. Scope, scale and initial ambitions . ]\nAn LEI comprises a unique machine readable code identifying the entity, that points to a set\n~ of key reference data relating to the entity, such as the name, address, etc. Users should have\nopen access to any LEI issued by the system, and to reference data that can be readily shared\nand that are not subject to privacy restrictions. This section of the report addresses’ the\nquestions: What is an LEI? Which entities are eligible for an LEI (ie What is the potential '\n\" scope of coverage)? What form should the code take and what reference data should be\nattached both at the launch of the system, as well as in the short to medium term? And what\n: - processes should be introduced to support the review and phased expansion of the reference\ndata over time as financial markets adapt and as usage of the LEI system grows? '\n- Recommendation 8 ' '\nSCOPE OF COVERAGE Eligibility of ‘legal entities’ to apply for an LEI should be broadly\ndefined, in order to identify the legal entities relevant to any financial transaction. No more\nthan one LEI may be assigned to any legal entity.\nFor purposes of this definition, the term ‘legal entity’ refers to a legal person or structure\n' organised under the laws of any jurisdiction. Legal entities include, but are not limited to,\nunique parties that are legally responsible for the performance of financial fransactions or\n\" have the legal right in their jurisdiction to enter independently into legal contracts, regardless\nof whether they are incorporated or constituted in some other way (eg trust, partnership, .\ncontractual, etc). It excludes natural persons, but includes governmental organizations; and\nsupranationals, defined as governmental or non-governmental entities established by '\ninterriational law or treaty or incorporated at an international level. Examples of eligible legal\nentities include, without limitation: all financial intermediaries; banks and finance companies; o\nall entities that issue equity, debt or other securities for other capital structures; all entities\nlisted on an exchange; all entities that trade stock or debt; investment vehicles, including\nmutual funds, pension funds and alternative investment vehicles constituted as corporate\nentities or collective investment agreements (including umbrella funds as well as funds under\nan umbrella structure, hedge funds, private equities, etc); all entities under the purview of a:\nfinancial regulafor and their affiliates, subsidiaries and holding companies; and counterparties\nto financial transactions.\nThe definition above corresponds to the ISO standard 17442:2012 for a Legal Entity\nIdentifier. It takes into account the possibility that in some jurisdictions, asset pools or other\nsegregated parts of a legal entity may nevertheless carry separate rights.and obligations at a\nsufficient level of independence of that legal entity. In such cases, for example, any claim in\ninsolvency would apply to the asset pool alone. The Expert Group supports the view that.in\nsuch jurisdictions, the asset pool or fund would be eligible for an LEL The LEI\nImplementation Group should further study the scope of application with respect to entities\nthat are not strictly legal entities to ensure that only one LEI is assigned to any particular\nentity for example in a structure of an umbrella fund, associated funds, and a fund manager, to\naddress the cases similar to those discussed above. ’ _ ' :\nThe Expert Group is also aware that detailed definitions of legal entities may depend on local\nlaws and that further specification considering local circumstances may be needed in some\ncases as the LEI system is implemented.\n35 i\n","contentLength":3694,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.392Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"Recommendation 9 ’\nLEI REFERENCE DATA AT SYSTEM LAUNCH The official name of the legal entity,\n\n_ the address of the headquarters of the legal entity, the address of legal formation, the date of\nthe first LEI assignment, the date of last update of the LEI, the date of expiry, business\nregistry information (if applicable), alongside a 20 digit alphanumeric code should form the\nbasis for the global system at the launch of the global LEI initiative. For entities with a date of\nexpiry, the reason for the expiry should be recorded, and, if applicable, the LEI of the entity or\nentities that acquired the expired entity.\n\nAs previously announced?®, the technical code for the LEI should be a 20 digit alphanumeric\nnumber as set out in the LEI standard recently published by the International Organisation for\nStandardisation . The code should be a unique dumb alphanumeric string and not incorporate\nany intentional embedded intelligence (such as a country reference) which could lead to the\ncode becoming out of date. The code should be persistent, in the sense that the code would\nnever be assigned to another entity.\n\" The following set of reference data attributes are regarded as the minimum set of information\n\nthat should be available at the launch of the LEI as specified in ISO 17442:2012: ‘\n\n. The official name of the legal entity; -\n\n. The address of the headquarters of the legal entity;\n\ne The address of legal formation; ,\n\n. The date of the first LEI assignment;\n\n. The date of last update of the LEI;\n\no The date of expiry, if applicable; :\n\n. For entities with a date of expiry, the reason for the expiry should be recorded, and if\n\napplicable, the LEI of the entity that acquired the expired entity®’;\n. The official business registry where the foundation of the legal entity is mandated to\nbe recorded on formation of the entity, where applicable;\n. The reference in the official business registry to the registered entity, where\n. applicable.\nThe first six items have been previously announced by the FSB, as items belonging in the set\nof minimum reference data at the launch of the LEL The seventh item has been included in\nthe list to provide information on the history of the entity, particularly if it is involved in a\nmerger and acquisition and/or other form of corporate action process. The final two items\nprovide a cross reference to the official business registry entry which provides the legal\nfoundation for the formation of the legal entity applying for an LEI (such as Companies\nHouse in the UK, for example). Such a reference will help to tie the global LEI system\ntogether as a registry of registries and provide a strong cross-referencing and data validation ‘\ntool. '\n28« Technical features of the legal entity identifier (LEL) “ FSB 7 March 2012,\n2 This is sometimes labeled the disposition of the LEL\n36\n","contentLength":2843,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.393Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"- Recommendation 10\nREVIEW OF SCOPE OF COVERAGE AND REFERENCE DATA The Regulatory\n, Oversight Committee should undertake regular reviews of the scope and extent of coverage of\nthe LEI to reflect emerging regulatory and market requirements for the LEI use according to\nan agreed schedule. The Regulatory Oversight Committee should undertake regular reviews\nof the LEI reference data according to a set schedule to monitor the required changes,\nadditions, retirements and modifications. .\nThe proposed ROC would monitor and review the scope and extent of coverage of the LEI )\n(for example by agreeing a timetable for periodic reviews which is likely to be more intetise\nin the early years of the LEI system). A particular issue for early review is for the ROC to\nconsider whether and if so how the global LEI can be leveraged to identify bodies such as\n: branches of international banks which are not legal entities, but which require separate\nidentification under some cross-border resolution schemes™,\nThe ROC would also regularly monitor and review the reference attached to the LEI\naccording to a pre-set schedule which again is likely to be more intense during the early\n' stages of the system.\nIn particular, the Expert Group identified a number of potential reference data items for future ‘\nconsideration: '\n. Organisation type — what is the corporate legal structure of the registered entity?\no Broader liability and other relationships — including elements such as control and '\nguarantees. _\no Problem indicators — such as reorganisation, etc.\n. Conglomerates flag — is the registered entity a part of a broader financial\nconglomerate? .\n) Corporate events flag — are there particular corporate actions or events affecting the\nfirm?\n) Industrial classification — what is the principal activity of the firm?\nIn putting forward these ideas for further review, the FSB is cognisant that there is an\nimportant trade off between expanding the scope of coverage and the set of reference data and\nthe burden on entities and registrars in reporting and keeping the information up to date. The\nROC will bear such cost-benefit considerations in mind as any proposals for broadening the\nscope of coverage or reference data are reviewed.\nRecommendation 11 ‘ '\nSTANDARDS FOR THE LEI SYSTEM The LEI system should meet, to the degree\npossible, evolving requirements of both the regulatory community and industry participants in\nterms of information content, scope, timeliness and availability. The ROC is responsible for\n3 One approach may be to build or bolt on a supplementary system on top of the LEL although a full range of options will\nbe assessed by the ROC.,\n_ ~ 37\n","contentLength":2669,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.393Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"the final determination for any standards for the LEI to be utilised in the global LEI system.\nWhen proposing areas for the development of new standards, the ROC should strongly\nconsider utilising existing standard setting organizations to develop such standards, provided\nthat such organizations incorporate the requirements for the standards as determined and\n- | communicated by the Regulatory Oversight Committee.\nThe set of reference data outlined the previous recommendation provides a minimum set of\ndata that should be available at the launch of the LEI (sometimes labeled Phase 1 data).\n_ In phase 2, it will be important to expand and add to this list, as additional reference\ninformation, for example, on corporate ownership and relationships (see recommendation\n' below) is essential in order to aggregate risks and prepare consolidated exposure statements.\nA key role of the ROC will be to review and monitor evolving needs and requirements of the\nregulatory community as well as proposals from private sector users in relation to the ,\nreference data to be included in the global LEI system. When new needs are identified by the .\n, ROC, the Committee should draw on the expertise of existing standard setting organisations\nin developing such standards, provided that such development fully incorporates the\nspecification and framework set out by the ROC: ‘\nBecause both risk aggregation across groups is important for regulators and indusiry, and\n- because relationship data may be important in defining the nature of an entity, this work has a\nvery high priority for both regulators and for private industry. )\nRecommendation 12 *\nLEI REFERENCE DATA ON OWNERSHIP The FSB LEI Implementation Group should\nas soon as possible develop proposals for additional reference data on the direct and ultimate\nparent(s) of legal entities and on relationship or ownership data more generally and prepare\nrecommendations by the end of 2012. The group should work closely with private sector\nexperts in developing the proposals. :\nAdding information on ownership and corporate hierarchies is essential to be able to\nundertake risk aggregation which is a key objective for the global LEI system. That should be\ntaken forward urgently by the proposed FSB LEI Implementation Group, with the aim of\n: developing practical proposals for such (phase 2) reference data by the end of 2012. '\nUltimately the aim is to have sufficient data to construct a map of the financial network and :\nthe complex groups of entities which participate in them. The task requires standardized,\n- machine readable information which underlies the network map. The more processes are :\nautomated, the more accurate the map will be. The more data rely on manual updating, the\nmore degraded the map will become. ,\nIdeal solutions to capture ownership relationships in the long run, such as parent and ultimate\nparent, would rely on information on the total share capital of all companies in the group, the\nshareholding of the parent entity, and LEIs for all the. companies in the group. If such\n\" information were available, it would be possible to construct shareholdings and voting control . |\nthrough the financial group. ' :\nSuch information is not available in the short term, however, and so other solutions must be\nfound. The FSB consequently recommends urgent further study of the options in order to\n38 . _\n","contentLength":3388,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.393Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"develop firm proposals in six months time on the best way forward. Interested parties within\nthe regulatory community would be invited to join the study — active advice from relevant\nprivate sector experts would be an important element of the process.\n, One additional and important challenge in addressing this issue is that some information on\n\n~ corporate ownership and hierarchies is protected by confidentiality and privacy restrictions in\nsome jurisdictions. That will colour where data can be stored, and what can be shared and\nexchanged. Ideally, legal and technical arrangements can be put in place to enable sharing of\n\n~ confidential information among the global regulatory community — that requires some\nadditional scrutiny by the proposed group over the next six months. Further examination -\nshould also be undertaken of the scope to provide non-confidential information on ownership\nrelationships to all users.\nRecommendation 13 :\nLEI OPERATIONAL AND HISTORICAL DATA The LEI system should maintain high\nquality records that retain relevant information on amendments (query, add, modify or delete\n\n‘ of any data element) to data items as well as additional data to facilitate the surveillance and o\ncontrol of the system by the COU where appropriate.\nThe LEI system, if successful, will receive a large amount of information on both registered\nentities and use of the system. Initial data will be entered for registered entities which may\nchange over time, either as changes occur to circumstances of the company and to the\nassociated reference data or as errors are detected. The system should also retain all relevant\ninformation on any changes made to data items for each entity, including a reference to the\ndata field changed, the date of the change, a classification of the reason for change, a\nclassification of the source of the change, and the value of the item before the change was\nmade. It is very important to maintain a full history of changes in LEI reference data, in order\nto maintain a strong audit trail in case of queries, and to enable users to be able to track the\ntime line of changes and to challenge the accuracy of information with a view to checking and\nto subsequent confirmation or amendment.\nUsers may perform various queries or downloads, they may ask for help, or they may\nchallenge the accuracy of data in the LEI System. Organizational and other operational data\nshould be collected to increase the efficiency, accuracy and utility of the System. :\nVL Pulling the LEI system together\nThe global LEI system should be implemented according to a globally federated model. Such\na structure will allow the accommodation of local jurisdictional differences such as language,\nlegal framework, etc, while also providing for the COU to perform the central functions of the\nglobal LEI system. '\nBoth the conceptual approach and technical features of the federated nature of the global LEI\nsystem have been addressed by the Industry Advisory Panel as well as LEI workshop '\nparticipants. '\n39\n","contentLength":3030,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.393Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"One of the comments highlighted that in order to achieve the global application of a standard,\n\n- it has to be able to accommodate the different rules, regulations, customs, languages,\npreferences and practices that apply in different sovereign states and jurisdictions. That would\nnaturally lead to the establishment of local registration facilities that are able to address these\nlocal characteristics in a meaningful way. Another argument put forward during the workshop-\nwas that a federated model can lead to lower costs and increased quality of service to end\nusers through competition.\n\nWhile the concept of “federation” can have different meanings, for the purpose of the LEI\nsystem a federated model implies, as a minimum:\n\n— A service is provided that appears to end users to be a single, global service — the\nsame data are available anywhere in the world, regardless of where they were\n\n' entered. :\n\n— Internally, the service is actually deployed as a network of multiple service\nproviders, who collaborate and use technology to provide the appearance to end users\nof a single seamless service.\n\n— Ifany LOU becomes isolated from the rest of the federation, the services provided by\n-that unit continue to function for the unit’s local end users, at least for the purpose of\ndomestic transactions.\n\nWhile this framework imposes requirements on the system architecture, it provides flexibility\nthat encourages jurisdictions to adopt the system. One workshop commenter noted that the\nkey element of the global LEI system operational model is not technological or of data\nreplication but governance. For example, the operator of the central registry could use a\nreplicated database that has elements hosted in data centres around the world. While this\napproach allows technological diversification in case of IT failure, it does not eliminate the\npolitical concern of one country registry denying services or access to another country. That is i\nwhy the federated architecture of the global LEI system employing I.OUs would address\nconcerns about national sovereignty. That architecture also allows for diversity in both\n~governance and services offered. For example, one country may have a strong preference for\na critical utility like the LEI registry to be operated as a governmental or quasi-governmental\nagency specified under national law. Another country may prefer a private competitive\nmarket, in which case there might be more than one LEI registry that offers services within\nthat jurisdiction, with the resulting competition serving to drive down prices and increase\nflexibility for end users.\nAlthough a federated model can be designed in a number of ways, the key consideration in the\nglobal LEI federated system is to be able to provide an LEI to any legal entity as defined in\nthe scope of coverage, regardless of country location or language used. Following this\nprinciple, a two level federated model can be described with the following components:\n1. Central Operating Unit (COU) in charge of central facilities, ensuring uniqueness of the\n“global LEI, global LEI administration and with responsibility for ensuring appropriate\nprotection of the key data. - ,\n2. Local Operating Unit (LLOU) that is in charge of local facilities, local information for the\njurisdiction (i.e. confidential information, former local identification number), and registry\n40\n","contentLength":3384,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.393Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"_ operations. It would also be in charge of processing LEI applications and verifying\ncompany authenticity. The key element here is that it should be able to accommodate local\nlanguages and local legal frameworks.\n\nExperts on the Industry Advisory Panel explained that there are a variety of ways how\nfederated distributed network architecture can be designed. One way is to have a single\n, searchable registry (COU) to which local operating units (LOUs) submit minimal reference\ndata sets about local registrants while holding locally additional, potentially non-standardized\ndata with pointers back to. the central regisiry. Alternatively, for example, the resolution\nsystem that ensures uniqueness of LEIs could hold the minimum set of data, the central\n: registry holding the extensive set of data and local units being exclusively processors of the\n\" submitted data. The latter model creates some validation and duplication challenges.\nHowever, it was emphasised that architecturally, the COU software does not need to be\nrestricted to a single central registry scenario. Multiple registries could be built to run in\nparallel to each other so that when a new entry or a change is made anywhere in one registry,\nit would be immediately reflected in other system components. In that case, each of those\nregistries could theoretically function.as a stand alone registry that lowers the risks of a\ncritical point of failure. Alternatively, each of the local registries could contain only a subset\nof all the registered data and technology would enable a query to any individual registry to be\nexecuted via a query of all linked registties. : :\nRecommendation 14\nCENTRAL OPERATING UNIT The mission and role of the Central Operating Unit should\nbe to ensure the application of uniform global operational standards and protocols that deliver\nglobal uniqueness of the LEI, seamless access to the global LEI and to high quality reference\n- | data for users with depth of access controlled by appropriate access rights, as well as\nprotocols and methods for how local systems can connect to the Central Operating Unit.\n- 41\n","contentLength":2118,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.395Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"fuse;s‘%hm’\nil e e\nD e R\nThe COU should be responsible for maintaining a central logical database of identifiers and\ncorresponding reference data to:\n\no Ensure quality and accuracy of data. '\n\n. Provide a set of services that facilitate expansion of the system, such as defined\nstandardised interfaces (software and services) that allow new jurisdictions to join\nthe system in a low-cost, open source manner and that provide educational and\ntraining materials that document the requirements, costs, and advantages for local\n\n' jurisdictions to join the system. '\n\n) Ensure that the system does not become technically obsolete over time by\nperforming ongoing evaluation and development of relevant standard and protocols\nfor the overall community (public and private sectors).\n\n) Ensure that the information within the system is secure and prevents fraudulent\n\n, activities. ‘ : _\nIn developing the rules and procedures for operations of the COU the ROC should consult the\nCPSS-IOSCO recommendations for Principles for Financial Market Infrastructure®.\nAmong other important tasks, the COU under the supervision of the ROC should identify the\nplausible sources of operational risk, both internal and external, and mitigate their impact\n3 Principles for Financial Market Infrastructure, April 2012,\n42\n","contentLength":1300,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.396Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"through the use of appropriate systems, policies, procedures, and controls. Systems should be\n“designed to ensure a high degree of security and operational reliability and should have\nadequate, scalable capacity. Business continuity management should aim for a continuous '\nsetvice and for timely recovery of operations in the event of a wide-scale or major :\ndisruption™.\nAt a minimum, the following three business continuity objectives should be meaningfully\naddressed in the development of the COU and its protocols and procedures:\n: e rapid recovery and timely resumption of critical operations following a wide-scale\ndisruption; _\n. rapid recovery and timely resumption of critical operations following the loss or\ninaccessibility of staff in at least one major location; and\n. a high level of confidence, through ongoing use or robust testing, that critical internal\nand external continuity arrangement are effective and compatible®. _\nRecommendation 15 '\nFORMATION OF THE CENTRAL OPERATING UNIT The LEI Implementation Group\nshould develop a detailed plan for the formation of the Central Operating Unit via the\nestablishment of a not-for-profit LEI foundation® by interested industry participants under\nthe oversight of the formed LEI Regulatory Oversight Cominittee. The foundation would rely\non industry participants, their expertise and knowledge to identify and develop the most\ntechnologically, financially and legally sound methods to implement the global LEI system in\nline with the standards and framework defined by the Regulatory Oversight Committee.\nRepresentatives from all geographic areas and industry sectors would be invited to participate '\nin the preparatory work underpinning the formation of the LEI foundation as the Central\n.| Operating Unit in a manner defined by the Implementation Group.\nThe LEI system should be designed and implemented as a truly global system in order to\n capture the full potential benefits. To achieve that, the COU must be set-up and operated ina\nclear and transparent manner where all stakeholders are meaningfully represented,\nencompassing wide geographic coverage and business sectors. A collaborative approach\nbased on industry consensus on technical and operational solutions should be the ultimate\nobjective of the COU structure and its design and governance should ensure that it can be\nachieved in the most effective way. The FSB considers that a legal form of foundation or\nbody of equivalent legal form would provide a catalyst for such international and cross-\nsectional cooperation and coordination, where the best ideas applicable for the global LEI\nsystem can be utilised, drawing on the experience of various experts from either finance or\nother sectors who have experience in the design and successful implementation of entity\n32 Principles of Financial Market Infrastructure, April 2012,\n3 Tnteragency paper on sound practices to strengthen the resilience of the U.S. Financial system, April 11, 2003, Federal :\nRegister Vol. 68, No.70. ) .\n3 Or body of equivalent legal form. '\n43\n","contentLength":3054,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.396Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"identification systems. Providing an open, transparent and broad access to such industry.\ncollaboration will ensure that the most technologically advanced and cost-efficient solutions\nare proposed and drawn on in the design and development of the federated global LEI system.\nThe broad participation” of various industry répresentatives in the LEI foundation will '\nreinforce open communication within the industry to address not only technological changes\n| but also structural, legal and policy considerations on both local and central levels. As one of :\nthe workshop participants noted, the design of the original system and the methodology for its\ndeployment will have a direct impact on how well the future system can copy with\nmodifications. To achieve a high degree of system adaptability in the future, the involvement ‘\nof a wide range of industry experts from different sectors should be an integral component of\nthe COU structure and should be a fundamental key element of its design.\nRecommendation 16 :\nBALANCED REPRESENTATION IN THE CENTRAL OPERATING UNIT The\nRegulatory Oversight Committee and LEI Implementation Group should ensure that the\nglobal LEI foundation takes account of the interests of financial and non-financial industry\nparticipants from different geographic areas and economic sectors. _\nThe global LEI Central Operating Unit should have a wide representation of experts from\ndifferent sectors of economy including financial and non-financial sectors industry\n' representatives. As emphasised during the LEI workshop in March, other industries have :\nmade enormous progress over recent years towards improving their identification systems. .\n\"~ Consequently, drawing extensively on the knowledge and experience of experts involved in\nsuch successful schemes will allow the financial sector regulators as well as industry to avoid\nobvious mistakes, as well as facilitating the choice of the best available solution in terms of\nimplementation time and cost. It was highlighted at the LEI workshop that organizations such\n. as Consumer Product Forum, GS1, Digital Object Identifier Foundation, Entertainment ID '\nRegistry, World Wide Web Consortium among others have a wide range of experience and\nknowledge in areas such as identification, the build-up of hierarchy relationships, and of\ndistributed network set-ups which are necessary for the successfil development of the global\nLEI system for financial counterparties. A global LEI foundation where not only interested :\nfinancial parties but also experts from other sectors have an active role and voice would be an\neffective way to start the rapid practical implementation of the initiative, building on best\npractices from all sectors. _ '\nLearning from experience of other industries suggests that there are benefits from enabling all\ninterested parties to contribute to the LEI foundation or body of equivalent legal form. That\nwould support the development of sound technical solutions and processes and raise the\nacceptability and adoption of the LEI system both in the short and in the long run. The FSB\nconsequently proposes that a global LEI foundation should be set-up to encourage wide-scale\nindustry participation. The proposed LEI Implementation Group would call for expressions of\ninterest in participating in the preparatory work, would guide the work and would develop all '\nnecessary legal documents, registrations, etc. to establish the global LEI foundation or body |\nof equivalent legal form. The global LEI foundation set-up would consequently be undertaken\nwith active engagement of the industry experts to expedite the process of the global LEI\nsystem launch.\n44 : :\n","contentLength":3674,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.396Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"with the ROC as described in Article 30, Board Members, includimg the Chair, shall be\n’ elected by a two-thirds majority vote of all Board Mcmbers,\n\nPrior to the appointment of a new board Member, the ROC may deliver recommniendations\n\nbased on the criteria mentioned in Article 12 above and certily that the candidates comply\n\nwith certain requirements laid out in By-laws.\n\nBoard Mecinbers, including the Chair, can be removed by a two-thirds majority vote of all\n\nBoard Members. Prior to the vote on his/her removal, the concerncd Board Maomber shall\n\nhave the opportunity to cxpress himself/herself to the Board.\n\nTrrespective of the above and at any time, the Founder has the right to appoint or remove a\n\nBoard Member. Prior to the appointment or removal, the Founder shall seek a\n\nrecommendation from the ROC,\n\nA concermmed Board Member shall abstain from voting on his/her removal, renewal or any\n\nother Board decision divectly and individually affecting him/her.\n\nArticle 16 Appointment of ex gfficio Board Members\n\nTwo or more representatives of the ROC shall be appointed as ex officic Board Members of\n\nthe Board with observer status and no voting rights. Ex officio Members do not have the lcgal\n\nstatus of Board Members and arc not entered into the register of commerce.\n\nFx officio Board Members are not subject to any fiduciary dulies applicable to Board\n\nMcmbers, including but not limited to the competences and functions of the Board\n\ncontemplated in Article 21 of the Statutes. Ex officio Members rights are limited (i) io attend\n\nthe meetings of the Board, (i) to provide the Board with information on ROC activities, (iii)\n\nto provide the ROC with information on GLEIL' activities, (1v) to request that a matter being\n\nconsidered by the Board be deferrcd so that the ex officio Members may take the matter to the\n\nROC to obtain the ROC position.\n\nArticle 17 Terms of office and term limits\n\nA Board Membher shall be eligible to hold officc for a three (3) ycar tcim, renewable (with\n\nconseni of the Board) for an additional term of threc (3) years. A Board Member's term may\n\nin the best interest of the Foundation exceptionally be extended at the discretion of the Board\n\nbeyond the two (2) three years terms referred to for an additional term of one (1) year up to\n\nmaximum three (3) years.\n\nIn the event that a Board membecr is unable to complete his or her term, the Board shall select\n\na replacement to serve until the end of the tern.\n\n10\n","contentLength":2468,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.396Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"_ ~ As it was noted above and discussed at the LEI workshop, the organizing principle of the\n: global LEI is a federated system with a “plug-in” architecture. This means that local\nprocedures are locally determined, subject to overall principles and content constraints set by\n- the centre when the local units plug in or join the system. To achieve that, LOUs would be -\nrequired to use the same “network card” to connect to the global LEI system. That is why to\nensure the successful launch and growth of the global LEI system it is important that potential\nLOUs are actively involved in the activities of the FSB LEI Implementation Group, in order\nto provide input to the design of the LEI implementation toolkit addressing data standards,\nmessaging standards, operational processes and software tools in a way to allow easy and\nefficient integration of local systems.\nRecommendation 17\nLOCAL OPERATING UNITS The LEI system should allow the local provision of all LEI\nfunctions which the Regulatory Oversight Committee determines do not need to be\n‘ centralised. The LEI system should enable the use of local languages, organisation types and\nrelationship structures as required. Procedures to integrate local systems into the global LEI\nsystem should be developed by the LEI Implementation Group in consultation with local\njurisdictions and potential Local Operating Units (when available) in a way and manner that :\nmeets the global LEI system High Level Principles. The Central Operating Unit of the LEL\nsystem should be able to provide support to Local Operating Unit operations when necessary\naccording to criteria and requirements established by the Regulatory Oversight Committee\nand administered by the Central Operating Unit.\nMembers of the Industry Advisory Panel noted that to achieve the widespread acceptance of\nthe LEI solution, a broad set of service providers (such as local registries and numbering\nagencies) that could become LOUs should be included in the COU and LOU integration\nmechanism development. Rapid take-up is best achieved by ensuring that as much\nfunctionality in relatiorn to integration is available in the central system as possible so that new\njurisdictions can ‘plug in’ without creating the need for a new “system build”, unless there are\nmajor constraints from local law and regulation. Early provision of the full functional\ndefinition of the user interface in local languages and of the full function test system for '\nregulatory and industry users are important to enisure rapid and relatively painless take-up.\nThe first local LOU is expected to be formed in the USA to commence the swap data\nreporting as required by the U.S. Commodity Futures Trading Commission (CFTC) final rule\n: on swap data recordkeeping and reporting requirements®. It should be noted that on 9 March\n2012 the CFTC requested submissions from industry participants who wish to be considered\nfor designation by the Commission as the source for the CFTC Interim Compliance Identifiers\nto be used for identification of swap counterparties in swap recordkeeping and swap data\nreporting under the jurisdiction of the Commission beginning in mid 2012. The Commission\nstated that the designation will have a limited term of two years, and be terminable on six\nmonths notice if a different central utility for the global LEI is chosen later through the FSB ,\n% CFTC swap data recordkeeping and reporting requirements, 13 January 2012\nhttp:/Avww.cfte.gov/iuem/groups/public/@lrfederalregister/documents/file/2011-33199a.pdf.\n45\n","contentLength":3541,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.396Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"process and becomes operational. The Commission also noted that it plans to adopt the\ngovernance principles and LEI reference data requirements endorsed by the FSB,\nRecommendation 18 : : -\nLEI DATA VALIDATION The LEI system should promote the provision of accurate LEI\n-reference data at the local level from LEI registrants. Responsibility for the accuracy of\n\n.| reference data should rest with the LEI registrant, but Local Operating Units have\nresponsibility to exercise due diligence in guarding against errors, as consistent with\nRegulatory Oversight Committee standards, and to encourage necessary updating. The\nCentral Operating Unit has responsibility to check registrations for global uniqueness and to\ncoordinate reconciliation by Local Operating Units where necessary. Accuracy should be\nensured at the local level by the registered entities. Self-registration should be encouraged as a\nbest practice for the global LEI system.\nThe key objective of the global LEI system is to provide accurate up to date reference data for\neach registered entity. That will require investment because as it was noted by the Industry '\nAdvisory Panel currently available information from public sources is of mixed quality and\ntimeliness. There are different short-term and long-term solutions to address the LEI data\nquality. One approach suggested by some workshop participants constitutes so-called\ncommercial third party data validation. Those services are focused on cross-checking\n\n- information from a range of sources by companies® staff in order to produce ‘cleaner’ data\nthat has been ‘scrubbed’ through such a process. Typically, such companies do not accept :\nliability or ultimate responsibility for data accuracy. - '\nIt wasnoted during the workshop that such third party validation services currently provide a\nuseful role in improving the quality of data. They do not, however, provide strong incentives\nto deliver fundamental improvements in data quality at source. To address the quality of the\ndata at the source, responsibility for the quality and accuracy of reference data must rest with\nthe LEI registrants, and so achieving permanent improvement should build on that\nresponsibility. That is best enabled at source at a local level where the initial registration is\nobtained; as such an approach draws on local expertise, legal frameworks and language, and\nalso addresses the issue of poor data quality at the base level. The FSB consequently\nrecommends that improvements in data accuracy should ultimately focus on providing\nresponsibility to the registrant for the quality and accuracy of data that would then be\nvalidated at source via the local registration facility. That may entail some upgrading of local\nregistration facilities, for example, to improve the timeliness of updating and reporting and the\n\n: quality of data validation. '\nTo support the process of improving data quality, the FSB recommends that the ROC directs\nthe set-up of standards for LEI validation and LEI data quality and that the Committee has the\npower to conduct independent assessments of the application of such standards. The process\nof independent validation and verification of data quality and standards should provide a\ncatalyst to deliver the necessary improvements.\n% CFTC Announces process to designate the provider of CFTC interim compliance identifier, 9 March 2012\nhttp://www.cfic.gov/PressRoom/PressReleases/pr6200-12, :\n46\n","contentLength":3438,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.396Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"The ultimate responsibility for the accuracy of the data should reside with the LEI receivers.\nFrom the practical stand-point the registered entity should have the best information about\nitself on a timely basis. The challenge for the data accuracy here is to create incentives or\n: compulsion for the entity to ensure the accuracy of its own data in the global LEI system.\nA relevant issue for LEI data validation is third party registration. Third party registration\nposes a set of challenges to align the incentives of the entity and third party register vs. cost of\nregistration vs. legal liability for data accuracy. At the workshop with private industry and\nduring the work of the Expert Group, it was noted by some participants that third party\n. registration would risk running counter to the objectives of uniqueness and data quality and\nhence should not be encouraged.\nSome members of the Industry Advisory Panel noted that such third-party registration\nfunction should be limited to the ability of legal entities to outsource the registration for an\nLEI to a third party. The responsibility for registration for an LEI and related maintenance and\ncertification of the accuracy of reference data would most sensibly rest with the\nrepresentatives of the entity itself.\nThe ROC should have the unfettered right to conduct independent validation and verification :\nof data standards, processes and quality. Such processes could leverage a third-party data\nvalidation as a temporary solution during the initial phase of the LEI system but the ROC\nshould develop a specific and timely transition plan to adjust from the transitional data :\nvalidation mechanisms to the permanent global data validation mechanisms.\nLegal enforcement for fraud in registration is the responsibility of local authorities, but local\nregistrars may act to invalidate entities associated with such fraud.\nRecommendation 19 '\nLEIISSUANCE WHEN NO LOCAL REGISTRAR AVAILABLE Whenever possible the\nLEI registration should take place with the relevant Local Operating Unit. When a Local\nOperating Unit is not available, the Regulatory Oversight Committee and a local jurisdiction\n(when willing to engage) should agree on approaches for local entities to obtain LEIs. The :\nImplementation Group should develop proposals for such mechanisms via: (1) establishing a\nmechanism of obtaining LEIs through other Local Operating Units; (2) establishing a\nmechanism of obtaining LEIs from a registration facility in the Central Operating Unit; and\n(3) any other mechanisms that are appropriate. :\nRecommendation 20\nSUSTAINABLE FUNDING The steady state funding of the global LEI system should be\nself-sustainable and reliable. The funding system should be based on an efficient non-profit\n' cost-recovery model. The system should have two components: a local discretionary charge;\n. | and a common fee based on the number of registrations in each LOU to pay for the centralised\noperations in the Central Operating Unit, alongside any costs of implementing.and sustaining\nthe governance framework. Fees should be sufficiently modest not to act as a barrier to\nacquiring an LEIL ' :\nThe funding system should have 2 components: a local discretionary charge; and a common\nfee for each registrant to pay for the centralised operations in the COU, alongside any costs of\n47 '\n","contentLength":3337,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.396Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"implementing and sustaining the governance framework. With respect to the ROC, the\nfunding mechanisms, procedures and responsibilities should be clearly outlined in the Charter\nand be accepted by jurisdictions and authorities joining the LEI system. The LEI ROC should\n' follow the established budgeting rules and other relevant cost related rules and ensure that the\noperations of the COU are undertaken on an efficient, non-for-profit, cost-recovery basis\n4 according to the cost-recovery criteria developed by the Implementation Group. The ROC\nshould review budget plans, accounts and audits on an annual basis to ensure that the funding\nmechanism adheres to the principles of cost-recovery, and does not present any monopoly\nprivileges, either directly or indirectly. Changes in payments to the COU from local systems\nshould be announced and introduced on a timely basis and approved by the ROC. The ROC\nshould ensure that the COU has financial resources not only to perform current functions but\nalso has sufficient resources for research and development, and system expansion and\nmodification as mandated by the ROC, while ensuring that the COU budget remains under\ntight control. Reflecting the federated nature of the LEI system, funding choices at the local\nlevel are flexible; a local operation may be viewed as being entirely a public good and be\nfunded by the public, or it may be seen as a good to be provided and funded in the\nmarketplace with a competitively determined price, or it may be seen as one of a variety of\nhybrids of the two. In all cases, it is in the interest of the ROC that local areas enforce rules to\n~ reduce the threat of monopoly privileges.\nVIL Governance and the rules of the game :\nProposals for the governance framework to protect the public interest are central to the\nmandate from the G-20 to the FSB. The approach adopted was first to identify the public\ninterests to be protected in relation to the introduction of a global LEI system and second to\nprovide recommendations for a governance framework best suited to protecting them.\nProtecting the public interest\n- As highlighted in earlier sections there is a need for a strong governance framework to protect\nthe public good of the global LEI system and to avoid creating positions where market powers\nand privileges can be exploited. A number of specific objectives have been identified:\n° Assuring open and free access to publicly available data. In particular:\n0 Data should be non-proprietary, with no ‘bundling of services®’,’ or\nrestrictions on access or redistribution; . ,\n0 All public data should be readily available on a continuous basis, free\nof charge; ‘\n0 Confidential data must be suitably protected;\n0 Data and operating processes should not be subject to any type of\n\" Intellectual Property restrictions, except those recognized as being '\nnecessary to promote free and open access.\n3 The LEI should be freely and openly available and should not be tied (or ‘bundled’) to the provision of other services.\n. 48\n","contentLength":3023,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.397Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"° Assuring open access to entities acquiring an LEI. Entities requited to, or\nwishing to, obtain an LEI should be able to acquire one under open, and non-\ndiscriminatory terms:\n\n' 0 Fees, where and when imposed, should be modest and based on a cost-\nrecovery basis>® that avoid monopoly rents and are subject to anti-trust\n. considerations. The operational model must be efficient and avoid\nexcessive costs. Budgeting rules should be clear and ¢onsistent.\n0 No restrictions should be placed on the use of the LEI by the registrant.\n\n° No competitive advantage should apply to any entities involved in the LEI _\nsystein.\n\n° Ensuring that the LEI system meets public sector requirements, including:\n\n) Ensuring uniqueness, accuracy, reliability, portability and persistence\nof the LEI code and reference data.\n\n0 Proposing new standards that serve the public interest. Modifying\nexisting standards as required. '\n\n0 Promoting the use and scope of the LEI to expand the collective benefit\nfrom widespread adoption. .\n\n: 0 Utilising local language and character sets, as well as ensuring access\n\nto the whole system in a common language.\n\n° The governance bodies should have the necessary powers to enforce\napplication of the governance principles, including:\n\n) To take any action deemed necessary to protect the public interest in\n. respect of the global LEI system;\n0 The ability to introduce oversight and governance processes, tailored to\nmeet local and central needs;\n) Ability to audit the parties involved and the process; and appoint\nindependent auditors;\n0 The ability to adjudicate disputes.\n_ The proposed governance framework has four main elements as set out in the Chart below:\ne High Level Principles and Charter for the Regulatory Oversight Committee which :\nsets out the principles and commitments that establish, specify and define the\n.governance of the global LEI system.\ne A ROC which is charged with protecting the public interests in the system.\n% 1t is possible that some jurisdictions could be willing to fund the LEI issuance from public sources and provide LEIs to its '\nlocal entities free of charge. . .\n) 49\n","contentLength":2136,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.397Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":". A Board of Directors of the COU which has responsibility for delivering the agreed\noperational standards.\n. Governance of the LOUs, which are the local implementers of the system.\nI e e s Roc Charter\nT Regulatory Ovérsight Committee (ROC} -\n|\n.\nCentral Optig f’lit {cou :\n| The proposed framework and specific recommendations with regard to the different elements\nare set out in the section below.\nRecommendation 21 - ‘\nGLOBAL REGULATORY OVERSIGHT COMMITTEE CHARTER The governance\nframework of the global LEI system should be developed at the international level in an open\nand transparent manner that supports collective governance of the global system. A global\n- | LEI Regulatory Oversight Committee Charter should set out the formation and operations of\nthe Regulatory Oversight Committee. The global LEI Regulatory Oversight Committee\nCharter should be prepared by the FSB LEI Implementation Group for endorsement by the G-\n20 at the Finance Ministers and Central Bank Governors meeting in November 2012 or by the\nFSB Plenary in October. ' _ |\nAs outlined earlier, the proposed global ROC Charter would define and frame the proposed\ninternational governance arrangements. The ROC would be established on endorsement of the\nCharter. :\n50\n","contentLength":1244,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.397Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"Recommendation 22\nREGULATORY OVERSIGHT COMMITTEE A Regulatory Oversight Committee, as\nspecified in the Charter, should have the responsibility of upholding the governance principles\nand oversight of the global LEI system functioning to serve the public interest. The\nRegulatory Oversight Committee should be a body representing regulators and other\n- | government or supranational entities engaged in regulating or monitoring the financial system\n' or markets. Membership and decision making processes would be established by the Charter.\nWherever possible, decisions would be reached by consensus.\n\n, The ROC will have responsibility to ensure that the governance and operation of the LEI\nsystem will protect the public interest. The proposed Charter will set out the high level\nprinciples governing the creation and operation of the ROC. Powers and participation\narrangements are set out in the following recommendations.\n\nRecommendation 23 - ' .\nPOWER AND AUTHORITY OF THE REGULATORY OVERSIGHT COMMITTEE\nThe Regulatory Oversight Committee has the ultimate power and authority over the global\nLEI system. Any power delegated to the Central Operating Unit, Local Operating Units and\nother entities can be reversed by the Regulatory Oversight Committee®. The Regulatory\nOversight Committee should establish a formal oversight plan to ensure that its directives to\nthe Central Operating Unit or other parts of the system are enforced and that the governance\nprinciples are upheld.\nThe ROC will be granted the ultimate power over the global LEI system in relation to\ndelivery of the public good and protection of the public interest. It .will take any action\n\n~ deemed necessary to protect the public interest in respect of the global LEI system. Specific\nresponsibilities assigned to the ROC include: .\n\n' ) Co-ordination of the global regulatory cb‘mmunity to oversee the implementation and\n\n' operations of the global LEI system in the public interest.\n\n. Development of plans, policies, and strategy for the global LEI system.\n\ne Approval of technical and operational standards for the global LEI system. -\nPromotion of the LEI as an industry standard.\n\ne Approval of business continuity standards for the global LEI system.\n\ne Approval of budgets and the setting of fees for the central operations and functions\nof the system, and overseeing local arrangements.\n\ne Requiring audits of the system (including appointment of external auditors) for\nfinancial controls, business practices, data quality standards or other matters\nnecessary to ensure the public interest. _\n\ne Ensuring balanced representation by geographic area and economic sector of the\nBOD of the COU. _\n\n3 Local authorities may also reserve rights to be engaged in decisions on local registration operations.\n51 )\n","contentLength":2786,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.397Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"‘ o Appointment of the initial BOD of the COU. -\n. Veto and removal of members of the BOD.\n: e . Appointment of independent members of the BOD, serving the public interest. '\ne Approval of policies for the recognition and termination of local registration agencies\nand LOUs.\ne Approval of material contracts with third parties to avoid ‘vendor dependence’ and to\nensure high quality in services that are subcontracted.\nThe ROC, when deemed appropriate, may delegate the fulfillment of selected responsibilities,\nas determined and agreed by the Plenary.\nRecommendation 24\nPARTICIPATION IN THE REGULATORY OVERSIGHT COMMITTEE To\nparticipate in the LEI Regulatory Oversight Committee, an authority should indicate support\n| for the global LEI High Level Principles and Charter for the Regulatory Oversight\nCommittee. Authorities may elect to be a full member of the Regulatory Oversight Committee\nor an observer. The rights and responsibilities of members and observer status participants\nshould be defined in the Charter. _\nParticipation in the ROC shall be open to all authorities and jurisdictions that agree to the core\nprinciples and purposes of the global LEI system and that are willing to subscribe to the\nobjectives and commitments specified in the high level Charter. Participation will be at the\nPlenary level which is the highest decision making body of the ROC.\nPlenary mémbership may be large. To help facilitate the work of the ROC, an Executive\nCommittee shall be appointed. The Executive Committee will take the day to day work\nforward. Membership of the Executive Committee shall be balanced jurisdictionally and\nregionally and also in terms of members’ functions (eg prudential regulators, market\nregulators, central banks, etc).\nWherever possible, decisions shall be taken by consensus. Where this is not available, a\nvoting system shall be applied, based on an allocation specified in the Charter.\nThe requirements, rights and responsibilities of Observer status shall be set out in the Charter.\nRecommendation 25 4\nLEVERAGING INFRASTRUCTURE OF AN INTERNATIONAL FINANCIAL\nORGANISATION In developing proposals to establish the Regulatory Oversight Committee\nfollowing agreement on the Charter, the Implementation Group should if possible and, subject\n\" | to agreement, leverage on the existing infrastructure of an international financial organisation\n: to initiate and stand-up the global LEI governance structure in a timely manner, utilising the\nexperience of the international organisation in executing international initiatives.\n\n_ The FSB sees considerable merit in drawing on the experience and infrastructure of an\ninternational financial organisation in helping to prepare and launch the international\ngovernance framework. Help and advice may be sought in a number of areas such as technical\ndevelopment and preparations; legal work; and meeting logistics.\n\n52\n","contentLength":2887,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.397Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":", Successful implementation of this option will require the acceptance and agreement of the\ninternational financial organisation to the proposal. ,\nRecommendation 26 : | : :\nGOVERNING DOCUMENTS FOR THE CENTRAL OPERATING UNIT Alongside the\ndevelopment of the global Charter, the Implementation Group should develop legal\n\n. documents governing the mandate provided by the Regulatory Oversight Committee to the\nCentral Operating Unit as well as other legal documents needed to specify the full governance\nframework for the global LEI system. ,\n\nA number of legal documents will need to be prepared alongside the Charter to set out and\nspecify the governance framework for the global LEI system. These potentially include the\nfollowing: .\n\n1. Regulatory Oversight Committee by-laws or similar document;\n2. ROC Plenary and Executive Committee governing documents;\n3. Foundation or body of equivalent legal form agreement for the Central Operating\nUnit; -\n4, Legal agreement between the ROC and the Central Operating Unit or similar\ndocument;\n5. IP and other related copyright/trademérk protection framework;\n6. Information sharing agreements or similar documents draft;\n7. Legal analysis of anti-trust laws to ensure adherence to competition and anti-trust\nprovisions. ' '\nThe proposed FSB LEI Implementation Group will be charged with responsibility for drafting\nthe legal documents alongside the high level Charter for the ROC.\nThe BOD of the COU will assent to and respect the terms of a legal agreement with the ROC,\nspecifying roles, responsibilities and rights of the respective parties for the governance and\noversight of the global LEI system. _\nRecommendation 27\nBOARD OF DIRECTORS OF THE CENTRAL OPERATING UNIT The Central\nOperating Unit shall have a Board of Directors. The Regulatory Oversight Committee has the\nright to veto membership of the BOD, as well as to remove members. The ROC has the right :\nto appoint independent members. |\nThe COU forms the operational arm of the global LEI system, charged with fulfilling the\nnecessary central functions to the overall standards set by the ROC. The BOD of the COU has\nresponsibility for the functioning of the COU, including the operational integrity and ,,\nimplementation and maintenance of standards specified by the ROC. The BOD\" should be\npopulated by stakeholders representing a wide range of interests, such as non-financial\n- companies as well as financial, experts with demonstrated experience of successfully\nintroducing and operating entity identification schemes in other industries, and independent\n53 ’\n","contentLength":2573,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.397Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf","content":"directors. It should be formed from membership of the proposed global LEI foundation or\nbody of equivalent legal form which will form the COU, together with independent members.\nThe initial Board shall be appointed by the ROC once the Committee has been established\nand the ROC has recognised the foundation as the system COU. Thereafter, the ROC will ‘\nveto/remove members of the Board proposed by the foundation and retains the right to\nappoint independent members®, )\nRecommendation 28 _\nFORMATION OF THE INITIAL BOARD OF DIRECTORS OF THE CENTRAL :\nOPERATING UNIT The Central Operating Unit’s initial Board of Directors should be\nappointed by the Regulatory Oversight Committee, taking into account the need for\ngeographic and sectoral diversity. The Implementation Group should develop the fitness\ncriteria, size, role etc for the BOD that should be reviewed in two years by the Regulatory | -\nOversight Committee.\nIt is important that the BOD of the COU has a balanced representation of stakeholder interests\n. charged with ensuring that the COU is run efficiently and effectively as the operational arm of\nthe global LEI in line with the standards set by the ROC.\nRecommendation 29\nPOWERS AND FUNCTIONS OF THE BOD OF THE CENTRAL OPERATING UNIT\nThe Board of Directors of the Central Operating Unit should be granted powers to direct the\nmanagement and operations of the Central Operating Unit in line with the overall standards\nset by the Regulatory Oversight Committee. :\nSpecific responsibilities may include:\no Appointing and dismissing management of the COU.\ne Entering into and enforcing contracts for services.\ne Auditing a local registration agency or LOU, or other service providers.\ne Dismiss or replace service providers as necessary.\n' . Invalidating an LEI, if appropriate standards are not met.\ne Determine a payment system for fees and services, in line with the decisions of the\nROC.\nRecommendation 30 ' ..\nCONTINGENCY ARRANGEMENTS The Regulatory Oversight Committee is responsible\nfor setting and overseeing the application of business continuity standards for the global LEL _\nsystem in line with best practices for key financial infrastructure. Rules and procedures should\nbe defined that the Central Operating Unit and Local Operating Units must follow in case of |\ninsolvency, bankruptcy, etc in order to ensure continuity of the global LEI system. A protocol\n40 In this context independent members mean non-industry representatives. :\n54\n","contentLength":2468,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:22:47.397Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/by-laws/gleif-by-laws-final-27-october-2016.pdf","content":"Enabling global identity\n: G LEI F > Protecting digital trust\nVersion 1.0\n2022-05-17\n","contentLength":85,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:23:11.982Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/by-laws/gleif-by-laws-final-27-october-2016.pdf","content":"Table of Contents\n| General ProViSIONS.....cccceeeeeireeceenierencrencrencrencerenceeneenscesnssensesssssensessssesnseens &\n1. BaSiS aNd PUIMPOSE ... ciiiieiieiiiiiiieie e ettt eesssrtveee s s s saiiraae e s s sraeeeessnnssseeassssssnnnnesesssnnnes B\n2. PUrpose Of the GLEIF .......cvviiiiiiiieiie ettt e ssraveee s s saiineee e s s snnnneseesnnnnns B\n3. Bodies Of the GLEIF........ueevieiiieiee ettt eececrrrrrrereeene e e e e e e e e en e ennnnn &\nI = o T [ o [ ] B 1T =T o1 o - USSR |\nK 1 o - | PR PPPRROUPRPR”\n3.3 EXLErnal AUITOrS .ueeei ittt ettt eerre e s esvrreesssssnreeesssnneeessnsvneeeesnnnens B\nILGLEIF BOQrd .....c.coveiiieiiiiniiieiiieniiiniieiiiaesieensiaiisesssasssassesssssssssssssssssssassssssses D\n1. COMPOSITION ettt s e e e e e e e e e eeeeste e be e bbb s e e e e e e anaaeeees D\n2. CONSEITULION e et eae e e re s D)\n3. Role, Duties and COMPETENCIES ......iiiiiiiiiiiieierriirie et e e s sierae e e s sinraeeeeenes D\nL - 1= = T OO P PP P PP PO UPPUPPPRPPIY.\nOFBANIZAtION ceeiiiiiee et ee e e e e e e s s st bete e e e e e e s e nanrnereaeaeees D\nSUPEIVISION Ltitiiieietie ettt te e e e e et re e e eees s st b aebeteeeeesaassasansbnabeaeaaeesanssasnsnnrseaeeeees D\nLo F= Y ol =] PR PPRPRRPPPRPRRPPPPRY o\nREEISTOIS ettt et e e et re e e ee e s se s st st bt teeeeeeessa s sanrnnaeeaeeeenseseassnrens ©\nACCOUNTING -ttt ettt ettt ee e e e e ettt te e eeeees s sabanbbeaeeteesassassassnssnnsesaeasessesssssnsssnseseees O\n(D1 13Yo] [T o] o PR PUPRPRRPUPRPRRPPPIRY o\n4. Role, Duties and Competencies of ex officio Board Members .........cccceevvvvieeeiiiineenn.. 6\n5. Election princCiples and ProCess .......ceeiveviuiieiiniiiiiieees st ee s sssiireeeeesssieseeeessssseseesssnns O\n6. Election of ex officio Board Members .........cccovviiiiiiiiiiiiieie e sveaeeee s 1\n7. Term Of OFfiCE et reraeeeeeeeaeaaeeaeenes\n8. RESIGNATION . et e e e e e e e e eeeeeneenesnnnnnnes ]\n9. BOArd MEELINGS ..uvviiieiiiiiiie ettt ee e s ae e e s sraae e e s sssbabeeeesssssssnaeeessnnnnneesesnns T\nO (=T o] [V o o 3T |\n3 IO O 18 o] U o PSP UPPRPRPPRRY )\n1 |V 1 0 101 =S PUUPPUPRNUPPUPRRRY\n13. Signatory powers of Board MembErS.......ccccviiiviiiiiieiie e ines O\nLI 3 - U -\n1. Duties and COMPETENCIES ...ccivvvvriieeiiiiiiie et sraae e e ssnreeeees D\nREPIESENTATION ..eeiiiiiiiieie et e e et te s ee e s e s asnnereaeseeeeanssesnnnnene D\n2 To T e Y =T o] o 1T USSP UUPPRPRPIRS -\n2T o T ISP PRRUUUPRPRPIRS -\nG By-laws Page 2 of 12\n@ gleif-by-laws-final-27-october-2016.docx Version 1.0\n2022-05-17\n","contentLength":2493,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:23:11.982Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/by-laws/gleif-by-laws-final-27-october-2016.pdf","content":"VI Regulations\n1. In General\n1 The Board may at any time adopt, modify, amend or cancel Regulations by a Board resolution.\nRegulations are based on the Statutes and on By-laws. They may also be called \"Policies\",\n\"Principles\", \"Procedures\", \"Guidelines\", \"Codes\", etc.\n2 The Board Members have to comply with such Regulations.\n3 Regulations do include provisions on their review.\n2. Conflict of Interests Policy\nThe Board adopts a Conflict of Interests Policy according to Article 18 Statutes.\n3. Travel and Expense Policy and Compensation Policy\nThe Board adopts a Travel and Expense Policy and a Compensation Policy.\n4. Procurement Policy\nThe Board adopts a Procurement Policy.\n5. Director's Code of Conduct\nThe Board adopts a Director's Code of Conduct.\nBy-laws Page 11 of 12\n@ gleif-by-laws-final-27-october-2016.docx Version 1.0\n2022-05-17\n","contentLength":845,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:23:11.982Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/by-laws/gleif-by-laws-final-27-october-2016.pdf","content":"VIl Other Provisions\n\n1. Confidentiality\n\n1 The Board Members including the ex officio Members as well as all other executive bodies and\nemployees (CEO, Executive Management, Secretary, etc.) keep confidential and withhold from\nthird parties any and all information, confidential communications, know-how etc., of\nwhatsoever nature and in any form whatsoever and that comes to their knowledge in the\nperformance of their duties.\n\n2 In particular, they are not allowed to share the agenda and/or documentation of the Board or\nBoard Committees with third parties.\n\n3 All attendees at Board meetings or Board Committee meetings are expected to keep the\ndialogue within the Board and the Board Committees and the distributed material strictly\nconfidential as agreed in the Inaugural meeting on 26 June 2014.\n\n4 Notwithstanding any of the above provisions, ex officio Board Members are allowed to provide\nthe ROC with information on GLEIF activities (Articles 16 Statutes). The confidentiality duties do\nnot prohibit that the ex officio Members may ask for information according to Article 31\nStatutes, in order to execute the tasks. The Communication and Notices procedure between the\nGLEIF and the ROC will be specified in a Memorandum of Understanding.\n\n2. Transparency\n\nThese By-laws will be made publicly available (Article 6 Statutes).\n\n3. Process amendment to the By-laws\n\n1 The Board shall after consultation with the ROC fix the details of organization of the Foundation\nin By-laws (Article 38 Statutes).\n\n2 After consultation of the ROC, these By-laws were approved by the Board of Directors on 27\nOctober 2016.\n\n3 These By-laws may be changed or amended from time to time by the Board with the approval of\nthe Supervision Authority. Prior to the submission of the By-laws or any modification thereof to\nthe Supervisory Authority, the ROC will deliver a recommendation (Article 38 Statutes).\n\nBasel, 30 November 2016\n\nChair of the Board Secretary of the Board\n\nGerard Hartsink Thomas Sprecher\n\nBy-laws Page 12 of 12\n@ gleif-by-laws-final-27-october-2016.docx Version 1.0\n2022-05-17\n","contentLength":2087,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:23:11.982Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/by-laws/gleif-by-laws-final-27-october-2016.pdf","content":"oYU Vo 1= USSP PRUPUPRPRPIRS -\n\nBOArd MEETINGS....vviiii ittt e st re e s e s sabeee s sssrreeeeanssrnnaessnnrnnaeees D\n\nBOArd reSOIULIONS ...ceiiiiiieieiiiiiiiie st stee et ee e se e e s s seee s e s sasneaeassnnnsesssnnseesssssnsees 10\n\nT} o] o s o= o T o FS ST UTPRRPRY: 0|\n\nF AN BT 1) £ 20T o o] o AP UPPPSPPRPRPS £ 0\n\nFUIthEr DULIES .. iviieie ettt et ee e sree e s s snee s e s saaneesassnnnnessssnsenasssnnnens 10\n\nVAT =T = - 1 U | 0\nV0 B =TT ] 1 o] LU | |\nI [T =T o 1= T | OO PPRPPPRRI i\n\n2. Conflict of INterests POlICY .....coovueiiiiiiiiiiiie et ssivieee s esssineneeeees 11\n\n3. Travel and Expense Policy and Compensation Policy.......cccccevvvveeeiininienieeennicciinennnn, 11\n\n4. Procurement POJICY .....uiiiiiiciiiiiie ittt siae e ee s sssivieee s s sssiiinaessssssnnneesssnnssneees L1\n\n5. Director's Code Of CONAUCT.......ccueiiiiiiiiiiiiie e e esseeeeenne 11\n\nVIl Other ProviSions.........ccceiiiiiiimieueiiiiiiiniennneiiiininenenssnesssssseneessss 12\nN 0o 1o o [T o} AT ] 1 AV OO PP OPPRPPRPR:\n\n2. TrANSPATENCY ceevrerueurunuiaieeeeeeereeeeeetetutresasaaaaasasaeaasaseeeseeesesesnsnsnnsnsnsnsssssseseeeseesessesnens 12\n\n3. Process amendment to the By-laWs .........ueeviiiiiiiiiiiiiiiiiie e essiviieeenn 12\nG By-laws Page 3 of 12\n@ gleif-by-laws-final-27-october-2016.docx Version 1.0\n2022-05-17\n","contentLength":1313,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:23:11.982Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/by-laws/gleif-by-laws-final-27-october-2016.pdf","content":"| General provisions\n1. Basis and Purpose\n1 These By-laws are issued by virtue of Articles 15, 22, 23, 24, 28, 32, 33 and 38 GLEIF Statutes.\n2 The By-laws establish the organization and administration of the GLEIF and define the respon\nsibilities and authorities of the respective corporate bodies.\n3 Where the By-laws and the Statutes conflict, the Statutes takes precedence over the By-laws.\n4 Details may be fixed in Regulations.\n2. Purpose of the GLEIF\nThe GLEIF's purpose is defined in Article 3 Statutes.\n3. Bodies of the GLEIF\n1 The corporate bodies of the GLEIF are the Board of Directors and the External Auditors (Article 12\nStatutes).\n2 The Chair, the CEQ, the ROC Observers (Articles 30—31 Statutes) and the Secretary have a specific\nrole.\n3 The Board can establish Board Committees.\n3.1 Board of Directors\nThe Board of Directors (composition, appointment, term, competencies, functions, etc.) is defined in\nArticles 13—22 Statutes.\n3.2 Chair\nThe appointment and term of the Chair are defined in Article 20 Statutes.\n3.3 External Auditors\nThe appointment and term of the External Auditors are defined in Articles 25 and 26 Statutes.\n3.4 CEO\n1 The appointment and the main duties of the CEO are defined in Article 29 Statutes.\n2 The particular duties and the relation between the Chair and the CEO shall be specified in\nRegulations.\nBy-laws Page 4 of 12\n@ gleif-by-laws-final-27-october-2016.docx Version 1.0\n2022-05-17\n","contentLength":1431,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:23:11.982Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/by-laws/gleif-by-laws-final-27-october-2016.pdf","content":"Il GLEIF Board\n1. Composition\nThe composition of the Board is defined in Article 13 Statutes.\n2. Constitution\nEach year, at its meeting after the approval of its Annual Report, but at the latest before June, the\nBoard shall constitute itself in accordance with Article 22 Statutes and these By-laws.\n3. Role, Duties and Competencies\n1. The main duties and competencies of the Board are defined in Article 22 Statutes.\n2. In particular, the Board, among its other non-delegable tasks, is responsible for the following non-\ndelegable tasks:\nStrategy\no tooversee the development and approach of the implementation of the vision and strategy of\nthe GLEIF, including the review and approval of business and resourcing plans;\n* tooversee the risk management;\nLOU\n© to specify the criteria and the process under which LOUs shall be recognised and derecognized\n(Article 33 Statutes);\nOrganization\no to appoint Board Members (Article 15 Statutes) and the Chair (Art. 20 Statutes);\n¢ to appoint and dissolve Board Committees (including the appointment and removal of their\nChairs);\ne to provide policies regarding the responsibilities that are delegated from the Board to the CEO;\nSupervision\n* toappoint and terminate the CEO and to approve the CEQ's remuneration.\n¢ The performance appraisal of the CEO is executed by the Chair who consults the Board for that\nmatter;\ne to provide overall supervision of the CEO as the head of the Management and the other\nmembers of the Executive Management;\no to conclude a written GLEIF Board membership Agreement with the GLEIF;\n* to provide a Conflict of Interests Policy;\nBy-laws Page 5 of 12\n@ gleif-by-laws-final-27-october-2016.docx Version 1.0\n2022-05-17\n","contentLength":1690,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:23:11.982Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/by-laws/gleif-by-laws-final-27-october-2016.pdf","content":"Financials\n\n¢ to approve the budget of the GLEIF;\n\no to adopt the Asset Management Policy (IPR and other assets);\n\n* tooversee the set up and approach to review procedures of the Asset Management;\n\n¢ toavoid over-indebtedness according to Article 84a Swiss Civil Code and to action in the event of\nover-indebtedness;\n\nRegisters\n\n¢ to apply to the Register of Commerce and the Trademark Register;\n\nAccounting\n\n¢ to approve the accounting standard recommended for use in the financial and the operational\naudits;\n\nDissolution\n\n* toapply to dissolve the GLEIF.\n\n3 The Board may assign the preparation and execution of its resolutions, other tasks and projects\nor the supervision of certain transactions and risks to one or more of its Members, except in case\nof untransferable tasks where delegation is not admissible. It may delegate the responsibility and\nauthority necessary or appropriate to carry out the day-to-day and operational activities of the\nGLEIF to the CEO.\n\n4. Role, Duties and Competencies of ex officio Board Members\n\nThe role, duties and competencies of ex officio Board Members are defined in Article 16 Statutes.\n\n5. Election principles and process\n\n1 The Board Members election principles and process are defined in Articles 13 and 15 Statutes.\n\n2 Board Members should master the English language at an appropriate level.\n\n3 The Board ensures the right balance as of excellence and diversity in the composition of the\nBoard as required in Article 13 Statutes.\n\n4 The Chair shall have in addition the following experiences and qualities:\n\no Extensive professional experience with significant executive leadership accomplishments in\nbusiness, government, philanthropy, or the non-profit sector;\n* Demonstrated success as a board chair or on a similar level;\no Track record of building credibility in the business community;\no A commitment to and understanding of GLEIF's mission preferably based on experience;\n* Sawvy diplomatic skills and a natural affinity for cultivating relationships and persuading,\nconvening, facilitating, and building consensus among diverse individuals;\no Personal qualities of integrity and credibility.\nBy-laws Page 6 of 12\n@ gleif-by-laws-final-27-october-2016.docx Version 1.0\n2022-05-17\n","contentLength":2236,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:23:11.982Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/by-laws/gleif-by-laws-final-27-october-2016.pdf","content":"6. Election of ex officio Board Members\n\nThe ex officio Board Members election principles are defined in Article 16 Statutes.\n\n7. Term of office\n\nThe Term of office is defined in Article 17 Statutes.\n\n8. Resignation\n\n1 The Resignation of Board Members is defined in Article 21 Statutes.\n\n2 The term of office shall also end if the Board Members are not re-elected, lose their capacity to\nact, or in the event of their death.\n\n9. Board meetings\n\n1 The Board meetings are defined in Article 24 Statutes.\n\n2 The Board shall be convened by the Chair whenever required by business, external events or\nregulatory matters, but at least four times a year in-person and four times by a call, with at least\none in-person meeting per year being focused to strategic matters.\n\n3 Board meetings can also be called by the Chair at the request of the CEQ. Board Members or the\nCEO requesting a meeting shall state the reasons.\n\n4 The meetings shall be held in at places that the Board may from time to time agree. At least one\nmeeting each year is planned to be in Basle, Switzerland (being the city where the GLEIF has its\nregistered domicile).\n\n5 Generally, the invitation to the meetings has to be sent 10 calendar days before. The agenda and\ndocuments for the meeting shall be distributed or made available at the latest a week prior to a\nscheduled meeting. In principle, proposals requiring a decision of the Board shall not be made\nwithout advance documentation.\n\n6 The Chair leads the Board meetings.\n\n7 With the permission of the Board, the CEO or one of the Executive Managers as well as third\nparties, may also be invited to attend Board meetings for specific points as guests (without\nvoting rights) from when it is necessary and appropriate for them to do so.\n\n10. Resolutions\n\nThe Board decision-making is defined in Articles 23 and 24 Statutes.\n\n11. Quorum\n\n1 The Quorum is defined in Articles 15, 20, 23 and 37 Statutes. The Board quorum shall be\nconstituted by the presence in person or by telephone or videoconference. Proxy voting is not\npermitted.\n\n2 The Board is expected to take decision by consensus. In case consensus is not possible, the Board\ncould decide to postpone the decision to the next Board meeting for further dialogue provided\nthe decision asked for is not an urgent decision.\n\n3 The following resolution shall require the assent of three-fourths of all Board Members:\n\no Request regarding the amendment of the Statutes (Article 37 Statutes).\nBy-laws Page 7 of 12\n@ gleif-by-laws-final-27-october-2016.docx Version 1.0\n2022-05-17\n","contentLength":2550,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:23:11.982Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/by-laws/gleif-by-laws-final-27-october-2016.pdf","content":"4 The following resolutions shall require the assent of two-thirds of all Board Members:\no Election of Board Members, including the Chair (Article 15 Statutes);\n¢ Removal of Board Members, including the Chair (Article 15 Statutes).\n\n12. Minutes\n\n1 The Minutes of the Board meetings are defined in Articles 24 Statutes. The Secretary takes care\nof the Minutes of the Board.\n\n2 All resolutions shall be recorded in writing. Minutes shall be approved by the Board and then\nsigned by the Chair and the Secretary.\n\n3 Minutes and circular resolutions shall be retained by the Secretary.\n\n13. Signatory powers of Board Members\n\n1 The Board Members have joint signatory power at two (Article 35 Statutes).\n\n2 The second signature will always be the signature of the Chair.\n\n3 Only the CEO and those members of the Executive Management of the GLEIF who have been\nregistered as signatories of the GLEIF in the Register of Commerce shall have the power to sign\non behalf of the GLEIF.\n\nBy-laws Page 8 of 12\n@ gleif-by-laws-final-27-october-2016.docx Version 1.0\n2022-05-17\n","contentLength":1062,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:23:11.982Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/by-laws/gleif-by-laws-final-27-october-2016.pdf","content":"Il Chair\n1. Duties and Competencies\n1 The Chair shall provide leadership of the Board and arrange for it to review and monitor the\naims, strategy, policy and directions of the GLEIF and the achievement of its objectives.\n2 The Chair shall facilitate the operations and deliberations of the Board and the satisfaction of the\nBoard’s functions and responsibilities under its mandate.\n3 The Chair shall have the following responsibilities:\nRepresentation\ne torepresent the GLEIF in the public (Article 34 Statutes);\no to speak on behalf of the GLEIF and the Board with regulatory and oversight agencies and groups\nand other third parties;\nBoard Members\n¢ to coordinate the Board Member nomination procedure (Article 15 Statutes);\n¢ to designate half of the initial Board with a term of three years (Article 17 Statutes);\nBoard\n¢ tolead the Board decision-making process (Article 23 Statutes);\n¢ to convene Board meetings (Article 24 Statutes);\nCEO\ne to propose a CEO (Article 29 Statutes);\nROC\no toreport to the ROC Chair and/or the ROC Executive Committee and/or the ROC Plenary on all\nmatters required in the Statutes in particular:\no to provide the ROC with GLEIF recommendations according to Article 5 Statutes;\ne toconsult the ROC according to Articles 13 and 15 Statutes;\no to ask the ROC for recommendation according to Articles 15, 23 and 31 and 38 the Statutes;\nFounder\no tokeep in touch with the Founder regarding Articles 15 and 37 Statutes.\n4 In addition to the responsibilities explicitly defined by the Statutes, the Chair shall have the\nfollowing responsibilities:\nBoard meetings\no to preside over the Board meetings;\nBy-laws Page 9 of 12\n@ gleif-by-laws-final-27-october-2016.docx Version 1.0\n2022-05-17\n","contentLength":1717,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:23:11.982Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/by-laws/gleif-by-laws-final-27-october-2016.pdf","content":"¢ toreview and sign the minutes of the Board meetings (together with the Secretary);\nBoard resolutions\no to supervise the compliance with and implementation of the resolutions of the Board;\nInformation\n¢ to handle information requests from Board Members;\n¢ torelay information as soon as possible to the Board of extraordinary events;\nAuditors Report\ne toaccept reports from the External Auditors and to ensure the transmission of same to the other\nBoard Members;\nFurther Duties\no all other matters reserved to the Chair by law, the Statutes, these By-laws or as set out in\nRegulations, Policies or Board resolutions.\nThe term, the responsibilities and the authority of the CEO are defined in Article 29 Statutes. The CEO\nshall be appointed to renewable terms of three years.\nV Secretary\n1 The Secretary shall be appointed to renewable terms of three years.\n2 The functions as well as the duties and competencies of the Secretary shall be specified in\nRegulations.\nBy-laws Page 10 of 12\n@ gleif-by-laws-final-27-october-2016.docx Version 1.0\n2022-05-17\n","contentLength":1053,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:23:11.982Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/policies/2017-03-01_board-code-of-conduct_v1.0-final-approved.pdf","content":"@> rotatun ol st\nCode of Conduct of the\nBoard of Directors\n","contentLength":59,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:23:31.724Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/policies/2017-03-01_board-code-of-conduct_v1.0-final-approved.pdf","content":"Subject Area: Corporate Governance Policy#: COR0O05 Level 1\nPolicy Title: Code of Conduct of the Board of Directors\nPolicy Owner: Board of Directors\nKey Policy User(s): Board of Directors\nChief Executive Officer\n\nGovernance Committee (GC) Review Date: 15/02/2017\nGC Recommendation: X (YES) O (NO) 15/02/2017\nBoard of Directors Approval Date: 22/02/2017\nEffective Date: 01/03/2017\n1 Application of the Code\nThis Code of Conduct (hereinafter “the Code”) applies upon acceptance of their mandate to the\nmembers of the Board of Directors (hereinafter “Member(s) of the Board of Directors”), and, where\nprovided, to the Chief Executive Officer, and to the professionals of the Global Legal Entity Identifier\nFoundation (hereinafter “GLEIF” or “the Foundation”). The Code sets out the rules applicable in\nmatters of professional ethics and behavior while embracing the core principles and values of the\nGLEIF as not-for-profit organization under Swiss law.\n2 Scope\nThe Code incorporates all applicable laws, regulations, the Foundation’s Statutes including its\nannexes and policies, the By-laws, the Organizational Regulations, the governance principles of the\nGlobal LEI System (the Global LEI System High Level Principles, the Financial Stability Board\nRecommendations and the Charter of the Regulatory Oversight Committee (hereinafter “ROC\")),\nprinciples and standards adopted by the ROC and generally accepted business principles.\n\nCode of Conduct of the Board of Directors Page 2 of 10\nGLEIF 2017-03-01_board-code-of-conduct_v1.0-final-approved Version 1.0\n\n1 March 2017\n","contentLength":1570,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:23:31.724Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/policies/2017-03-01_board-code-of-conduct_v1.0-final-approved.pdf","content":"3 Standard of Conduct\n\nMembers of the Board of Directors shall act with high ethical standards in the best interest of the\n\nFoundation. The Foundation’s ethical standards shall be based upon honesty, fairness, transparency,\n\nintegrity and trust. These should govern the interactions within the Foundation, and the\n\nFoundation’s relationships with the ROC, the LOUs and other business partners.\n\nMembers of the Board of Directors shall discharge their duties professionally with due diligence and\n\nefficiency and to the best of their abilities. Members of the Board of Directors shall, in particular,\n\nendeavor to:\n\n« comply with the Foundation’s applicable laws, regulations and policies;\n\ne prevent any situation which may give rise to a conflict of interest and declare any private interest\nrelative to their public duties and to take steps to resolve any conflicts arising in a way that\nprotects the broad public interest of the Foundation;\n\no respect the obligation of confidentiality relative to information received in the course of their\nduties;\n\no refrain from overstepping the powers conferred upon them;\n\n* make decisions fairly, impartially and promptly, considering all available information, legislation\nand policies and put interests of the Foundation above personal interests;\n\no exercise due care, diligence and skill assuming individual responsibility to contribute actively to\nall aspects of the Board of Director’s role;\n\no prepare for the discussion of business on the agenda of the Board of Directors meetings;\n\no apply best judgement in the light of the core objectives of the GLEIF understanding the strategic\nand other implications of decisions;\n\no exercise the oversight function as Member of the Board of Directors and respect issues that are\nof responsibility of Executive Management;\n\no respect the dignity and private lives of their colleagues, GLEIF professionals and anyone whom\nthey come in contact with during the discharge of their duties;\n\no treat colleagues with respect, courtesy, and fairness in all Board of Directors and Committee\nmeetings and when engaging with GLEIF professionals;\n\ne contribute to a harmonious and productive Board of Directors environment and culture through\nprofessional relationships;\n\no represent the interests of the Foundation in a positive and supportive manner at all times, and in\nline with its communication plan, where appropriate, while serving the development and\nmaintenance of the LEI as broad public good;\n\n¢ make use of the Foundation’s name and resources only in the interest of the Foundation.\n\nCode of Conduct of the Board of Directors Page 3 of 10\nGLEIF 2017-03-01_board-code-of-conduct_v1.0-final-approved Version 1.0\n1 March 2017\n","contentLength":2713,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:23:31.724Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/policies/2017-03-01_board-code-of-conduct_v1.0-final-approved.pdf","content":"4 Responsibilities to the Foundation\nIn performing their duties as Directors, Members of the Board of Directors shall be responsible only\nto the Foundation. Members of the Board of Directors shall ensure that their action remains within\nthe powers conferred upon them by or under the Statutes and otherwise comply with the provisions\nof the Statutes, the Bylaws and the Organizational Regulations of the Foundation.\n5 Principles\nIn accordance with Article 4 of the Statutes and in pursuing its purpose, the Foundation should\nensure that governance principles of the Global LEI System are upheld, under the regulatory\noversight of the ROC, in the broad public interest to the extent permitted under Swiss law.\nGLEIF is a not-for-profit organization. GLEIF shall uphold the highest legal, ethical and moral\nstandards. GLEIF’s reputation for integrity and excellence requires the careful observance of all\napplicable laws and regulations, including the principles of Swiss foundation law.\nMembers of the Board of Directors recognize the need to develop and maintain for the broad public\ngood a Global LEI System that is to be used: (a) by authorities of any jurisdiction or financial sector to,\nassess systemic risk and maintain financial stability, conduct market surveillance and enforcement,\nsupervise market participants, conduct resolution activities, prepare high quality financial data, and\nto undertake other official functions; and (b) by the private sector to support improved risk\nmanagement, increased operational efficiency, more accurate calculation of exposures, and other\nneeds.\nAll Members of the Board of Directors shall at all times seek to uphold the objectives of the GLEIF as\nset out in the Statutes and the approved GLEIF Strategy and to ensure the operation of the GLEIF in\nthe broad public interest in line with the High Level Principles and FSB recommendations, as\nendorsed by the Heads of State and Government of the G20 at the 2012 Los Cabos Summit, as well\nas any additional principles or Standards adopted by the ROC.\n6 Values\nMembers of the Board of Directors embrace the mission of the GLEIF to manage a network of\npartners to provide trusted services and open, reliable data for unique legal entity identification\nworldwide.\nMembers of the Board of Directors, and, where appropriate, the GLEIF’s professionals, should aspire\nto embrace the following core values:\n\nCode of Conduct of the Board of Directors Page 4 of 10\nGLEIF 2017-03-01_board-code-of-conduct_v1.0-final-approved Version 1.0\n\n1 March 2017\n","contentLength":2534,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:23:31.726Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/policies/2017-03-01_board-code-of-conduct_v1.0-final-approved.pdf","content":"¢ Sound Management and Performance\n\nMembers of the Board of Directors should oversee that the Foundation promotes effective and\n\nprudent management to ensure the best use of resources and sustainable funding. The Foundation\n\nand its professionals should meet high standards of performance reflecting the open, creative and\n\ninnovative nature of the GLEIF's operational excellence. Quality assurance and continuous\n\nimprovement through constant review shall be at the heart of the activities of the Foundation.\n\no Integrity\n\nMembers of the Board of Directors should not place themselves under any financial or other\n\nobligation to outside individuals or organizations that might influence them in the performance of\n\ntheir duties. Members of the Board of Directors should accept professional responsibility advocating\n\nfor the Foundation by engaging in activities that enhance its credibility and value in accordance with\n\nArticle 10 of the Statutes. GLEIF professionals should commit to providing expertise and reliability\n\nthroughout the organization and management of the Global LEI System.\n\n* Objectivity\n\nIn carrying out business, including making appointments, awarding contracts, or recommending\n\nindividuals for rewards and benefits, Members of the Board of Directors and GLEIF Executive\n\nManagement should make choices based on merit in connection to the Foundation’s core principles\n\nin terms of the public interest.\n\ne Transparency\n\nMembers of the Board of Directors shall uphold the principles of transparency in accordance with\n\nArticle 6 of the Statutes ensuring the Foundation’s application of uniform global operational\n\nstandards and protocols that deliver global uniqueness of the LEI, seamless access to the global LEI\n\nand to high quality reference data for users.\n\nThe Foundation should operate with a high degree of transparency and publish all relevant\n\ninformation in line with the governance principles of the Global LEI System and general policies as\n\napproved by the ROC.\n\n© Respect\n\nMembers of the Board of Directors and GLEIF professionals should treat customers, partners, and\n\npeers with the same respect that they wish to be treated with.\n\no Visibility\n\nThe GLEIF provides transparency and accessibility to legal entity identification and data services.\n\nMembers of the Board of Directors commit to contribute to the visibility of the GLEIF in the area of\n\nlegal entity identification and data services.\n\no Openness\n\nMembers of the Board of Directors and the Foundation supports the principles of the International\n\nOpen Data Charta including open global participation and engagement with the Global LEI System.\nCode of Conduct of the Board of Directors Page 5 of 10\n\nGLEIF 2017-03-01_board-code-of-conduct_v1.0-final-approved Version 1.0\n\n1 March 2017\n","contentLength":2785,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:23:31.726Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/policies/2017-03-01_board-code-of-conduct_v1.0-final-approved.pdf","content":"o Leadership\nMembers of the Board of Directors should promote and support these principles and values by\nleadership and example to add value to the Foundation and contributing to the ethical success of the\nFoundation.\n7 Governance and Compliance\nThe Board of Directors constitutes the supreme governing body of the Foundation. The Board\npossesses the highest and most extensive authority concerning decision-making and administration\nof the Foundation and shall exercise all other lawful powers required to carry out the purpose of the\nFoundation. Members of the Board of Director shall adhere to its governance documents and the\ngovernance principles of the Global LEI System.\nThe Foundation’s compliance framework shall be based on applicable laws, regulations, policies,\ncirculars, contracts, its Statutes and annexes, By-laws and Organizational Regulations and generally\naccepted business principles.\nThe GLEIF should at all times act in a legally compliant and ethically correct framework. This requires\nthe observance of law relevant for and of Swiss foundations, and business ethics as a matter of\ncourse and promoting voluntary practices to manage the Foundation in a responsible and effective\nmanner (Good Corporate Governance). Compliance is an integral part of Good Corporate\nGovernance. GLEIF shall promote lawful and ethical conduct in all business dealings and protect the\nFoundation’s assets, data and reputation.\n8 Conflicts of Interest\nMembers of the Board of Directors shall conduct themselves honestly and sensitively relative to the\nacceptance of certain functions or assignments which could conflict with the knowledge acquired by\nthem in the performance of their duties. All actual, perceived or potential conflicts of interest must\nbe disclosed to the Board of Directors as well as being managed, in particular, in compliance with the\nBoard Conflicts of Interest Policy of the Foundation as published on the GLEIF website and in\naccordance with Article 18 of the Statutes.\nConflicts of interest should also be avoided by all GLEIF professionals. When in doubt, GLEIF\nprofessionals are required to disclose all such cases to the Chief Compliance Office for review and\nresolution.\n9 Confidential information\n\nCode of Conduct of the Board of Directors Page 6 of 10\nGLEIF 2017-03-01_board-code-of-conduct_v1.0-final-approved Version 1.0\n\n1 March 2017\n","contentLength":2370,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:23:31.726Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/policies/2017-03-01_board-code-of-conduct_v1.0-final-approved.pdf","content":"Members of the Board of Directors and GLEIF professionals shall not divulge any confidential\ninformation or data which comes to their knowledge during the performance of their duties to third\nparties. They shall continue to be bound by this obligation after termination of their mandate or\nduties.\nMembers of the Board of Directors shall protect the integrity of the Foundation’s decision-making\nprocess. In particular, Members of the Board of Directors and GLEIF professionals and all other\nattendees of Board of Directors meetings or Board Committee meetings shall refrain from disclosing\ninformation and dialogue exchanged therein. They shall continue to be bound by this obligation after\ntermination of their mandate or duties.\n10 Action on an unpaid basis and expenses\nMembers of the Board of Directors shall act on an unpaid basis in accordance with Article 19 of the\nStatutes. They shall be entitled only to the reimbursement of their effective costs and travelling\nexpenses incurred by the Members in the execution of their duties for the Foundation as regulated in\nthe Board Travel and Expense Policy published on the GLEIF website. For activities exceeding the\nusual scope of the Foundation, each Member of the Board of Directors may receive appropriate\ncompensation according to the principle of \"usual in the market\". Principles of action on an unpaid\nbasis are governed by Article 19 of the Statutes.\n11 Assets and Intellectual Property\nIn accordance with Article 8 of the Statutes contributions of third parties, whether potential or\nactual, shall not convey any additional rights to the contributors.\nThe Foundation may own tangible or intangible assets, including intellectual property rights.\nIntellectual property rights should be held for the public benefit and consistent with the attainment\nof the purposes of the Foundation as well as the principles of the Global LEI System.\nThe Foundation shall have the exclusive ownership of all those intellectual property rights and the\nenjoyment and use of those intellectual property rights shall accrue to the benefit of the Foundation.\nThe Foundation shall observe all relevant existing patents, copyrights, designs and model rights and\ntrademark rights of which they are made aware.\n12 Corruption\nThe abuse of power by the position of Member of the Board of Directors or of GLEIF professionals is\nstrictly prohibited. It is expressly forbidden to apply for, receive or accept, any advantage, direct or\nindirect, of material or immaterial nature, which is or may appear in any way connected with a\nCode of Conduct of the Board of Directors Page 7 of 10\nGLEIF 2017-03-01_board-code-of-conduct_v1.0-final-approved Version 1.0\n1 March 2017\n","contentLength":2702,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:23:31.726Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/policies/2017-03-01_board-code-of-conduct_v1.0-final-approved.pdf","content":"mandate in the Foundation or make offers, or promises of benefits in terms of the allocation of\nmoney, goods or other services business benefits. Any form of bribery is prohibited.\n13 Gifts and donations\nGLEIF may accept gifts and donations that serve the purpose and fulfillment of the mission of the\nFoundation. Gifts and donations and the like may be in cash or in kind. They shall not be of a personal\nnature but serve any of the programs or services of the Foundation. The Board of Directors and the\nChief Executive Officer may solicit gifts, grants and donations from individuals, corporations, and\nfoundations and other organizations to secure the future growth of the Foundation. The Board of\nDirectors should strive for transparency with regard to the origin of its contributions committed to\nthe Foundation. Upon the receipt of larger contributions, the Foundation’s Board of Directors shall\nexamine the extent to which the origin of these assets conflicts with the purpose of the Foundation.\nThe Foundation shall keep a register of gifts and donations. A framework for the acceptance of\npersonal gifts and the duty to give notice on personal offers shall be defined for the review of the\nGovernance Committee of the Board of Directors.\nWhen in doubt as to the propriety of an offer, Members of the Board of Directors shall seek the\nadvice of the Secretary of the Board, GLEIF professionals shall seek the advice of the Chief\nCompliance Officer for all matters pertaining to the acceptance of gifts and donations that may have\npotential adverse legal, ethical, or policy consequences to the Foundation.\n14 Sustainable funding\nIn accordance with Article 9 of the Statutes the ongoing funding of the Global LEI System should be\nself-sustainable and reliable. The funding of the GLEIF should be based on a financial fee based on\nthe number of registrants. Any GLEIF funding sources in addition to the fee must be consistent with\npublic good principles and, as a consequence, must not inure to the benefit of the provider beyond\ncustomary commercially available provisions (cost recovery principle). In particular, data access shall\nremain free to users.\n15 Diversity, Equality and Non-Discrimination\nIt shall be ensured that the Board of Directors maintains a balance of excellence and diversity in the\ncomposition of the Board of Directors (Article 13 of the Statutes). Also, diversity shall be fostered\nacross the Foundation.\nGLEIF professionals shall have access to appropriate and effective services without discrimination on\nthe basis of geography, political, religious, or socio-economical characteristics of the state or region\nCode of Conduct of the Board of Directors Page 8 of 10\nGLEIF 2017-03-01_board-code-of-conduct_v1.0-final-approved Version 1.0\n1 March 2017\n","contentLength":2781,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:23:31.727Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/policies/2017-03-01_board-code-of-conduct_v1.0-final-approved.pdf","content":"represented, gender, sexual orientation, national origin, race, religion, age, political affiliation or\ndisability, in accordance with applicable legal and regulatory requirements.\nAny type of harassment (bullying) or discrimination at the work place shall not be tolerated.\n16 Communication\nMembers of the Board of Directors should channel its communication on internal Board business\nmatters through the Chair, its Secretariat and the Chief Executive Officer. Members of the Board of\nDirectors should not make any unauthorized public statements regarding the business of the\nFoundation. They should support, adhere to and not contradict the formal decisions of the Board of\nDirectors made in its meetings.\nMembers of the Board of Directors should act as ambassadors in the interest of the Foundation at all\ntimes thereby serving the development and maintenance of the LEI as broad public good. Public\nspeaking of any representative on behalf of GLEIF should be in line with the approved GLEIF\ncommunication plan and messaging tools, as appropriate. Usually, this refers to conveying publicly\navailable information as featured on the GLEIF website.\nMembers of the Board of Directors further adhere to the communication framework with the ROCin\naccordance with Article 31 of the Statutes and the Memorandum of Understanding.\nThe Foundation shall maintain active communication. It shall provide the general public with useful\ninformation in line with its communication plan. Communications should be easily understood by\ntheir intended recipient. In general, accuracy and integrity of information shall be ensured. Members\nof Board of Directors and GLEIF professionals should enter into fruitful exchanges with its partners as\nwell as other market protagonists building trustful relations.\nThe Foundation should participate in relevant public consultations under management of the Chief\nExecutive Officer.\n17 Self-Assessment\nBoard Members shall at all times be subject to fitness and properness criteria in accordance with\nArticle 13 of the Statutes. The Board of Directors undertakes a periodical review of its performance\nby a formal self-assessment.\n18 Observation of misconduct or grievances\nAny observed misconduct or grievances of whatsoever nature shall be notified, in the case of a\nMember of the Board of Directors, to the Secretary of the Board, and in the case of a GLEIF\nCode of Conduct of the Board of Directors Page 9 of 10\nGLEIF 2017-03-01_board-code-of-conduct_v1.0-final-approved Version 1.0\n1 March 2017\n","contentLength":2521,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:23:31.727Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/policies/2017-03-01_board-code-of-conduct_v1.0-final-approved.pdf","content":"professional, to the Chief Compliance Officer.\n19 Administration of the Code\nThe Chair of the Board of Directors shall supervise the application of the Code. The Governance\nCommittee, as specified in the Organizational Regulations, shall recommend changes to the Code of\nConduct, as appropriate, for the decision of the Board of Directors.\n\nCode of Conduct of the Board of Directors Page 10 of 10\nGLEIF 2017-03-01_board-code-of-conduct_v1.0-final-approved Version 1.0\n1 March 2017\n","contentLength":481,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:23:31.727Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/policies/2023-02-03_conflict_of_interest_policy_1.1final.pdf","content":"OGLEIF’ rotatun ol st\nBoard Conflict of Interest\nPolicy\n","contentLength":56,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:23:47.660Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/policies/2023-02-03_conflict_of_interest_policy_1.1final.pdf","content":"Table of Contents\nR O 1 [T o= U |\nO R U o o o 1O O TP PPPPPPRPPPPPPRY -\nA Yoo ] o 1= O O PP PPPPPPPPPPPPPRY -\n1.3 DefinitioNS .uuviiieei it e e s ssaareee s s s s sannnnesesennnnns B\n1.3.1 Conflict Of INTEIEST....ceiciiecciie ettt sctae e e e sraessreeesnee s snreeesnneeeens &\n1.3.2 Family IMEMDET ..evveiei i e s e e e e s naaraeees D\nPR o [T oy PR\n2.1 Examples of Conflicts of INterest........ccccevvviiiiiiiiiiiie i D\n2.1.1 Self-benefit/Benefit of Family Members..........ccooovveevvveeciieieeeee et eeennnn B\n2.1.2 INFlUENCE PEAAIING ..ccieieeeee et e et e e et e e e s sree s neesrsaeaneees D\n2.1.3 Other business relationships and dealings...........cccccceeiivvieiiiicviieee el 5\n2.1.4 Use of GLEIF property for personal advantage .......ccccceeceevvevieeecceeecsieccciee e 0\n2.1.5 Recording or reporting false information............cccceeviieecieiive e B\n2.1.6 Dealings With rantees .......ccciceciiiiiiiiieeee e estie e s sssrareee s ssraeee s sssrneeeesnnsens O\n2.2 Disclosure of Conflicts of INnterest .......ccccevvviieiiiiiiiiiiee e seeeee s ©\n2.3 Management of Conflicts of INterest.......cccvvveviiiiiiiei e esriiie e ©\n2.4 DisCiplinary ACTION.......uiiii ittt srare e e s saabeee s s s saannnaeeseenns T\n2.5 INterPretation. ... e e eeeeeeeeeennenenn\nP SR 1 (=T o o] o -SSP PTUPUPTPPPPRPPPPRRPY\n2.7 Supporting Policies and ProCedUIeS..........ccvvueveeeririiiieeeessiiiieeeeesssiieeeesessineneeessnns 7\n3 Implementation Responsibilities.....cccccccceereeiieeiiiencireiireeceincereecrenceeeennee 8\n4 Effective DAte .....cccccviiiiiineiiiieenniiiiineiiiiiieniieeiiieesssssesee 8\n@ Board Conflict of Interest Policy Page 2 of 8\nGLEIF GLEIF Public Version 1.1\n2023-02-03_Conflict of Interest Policy_1.1final 3 February 2023\n","contentLength":1739,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:23:47.660Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/policies/2023-02-03_conflict_of_interest_policy_1.1final.pdf","content":"_ Committee of Chairs\nAbout this policy\nThis document describes the Conflict of Interest Policy (the “Policy”). The Policy relates to\nencouragement of GLEIF Board Members to avoid or disclose unavoidable Conflicts of Interest.\nChange History\nThis section records the history of all changes to this document.\n2023-02-03 1.1 1.3 included civil partnership Sven Schumacher\n2014-06-20 1.0 Draft Thomas Sprecher\nWhere changes are made for clarity and reading ease only and no change is made to the meaning or\nintention of this document, the version number will be increased by 0.1.\nWhere significant changes are made to this document, the version number will be incremented by\n1.0.\nBoard Conflict of Interest Policy Page 3 of 8\nGLEIF GLEIF Public Version 1.1\n2023-02-03_Conflict of Interest Policy_1.1final 3 February 2023\n","contentLength":818,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:23:47.660Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/policies/2023-02-03_conflict_of_interest_policy_1.1final.pdf","content":"1 Overview\n\n1.1 Purpose\n\nThis Policy was adopted in accordance with Article 18 of the GLEIF statutes and Article VI.2 of the By-\n\nLaws. The purpose of this Policy is to protect the interests, integrity, and reputation of GLEIF and the\n\nBoard’s decision-making processes, by establishing procedures to identify, evaluate and address any\n\nactual, perceived or potential Conflicts of Interest that may arise. The Policy is intended to\n\nsupplement, and not replace, any relevant local laws regarding Conflicts of Interest.\n\n1.2 Scope\n\nThe Policy applies to persons in the following roles:\n\n¢ Board Members;\n\no Board Secretary;\n\n¢ Family members of the above-mentioned persons; and\n\ne CEO and members of management team to the extent that they are involved in Board decisions.\n\n1.3 Definitions\n\nTerms found in this Policy will have the same meaning as they do within the GLEIF’s statutes. Further,\n\nthe following definitions will apply:\n\n1.3.1 Conflict of Interest\n\nA Conflict of Interest arises where an outside or personal interest influences or has the potential to\n\ninfluence the ability of a person in scope (see Fehler! Verweisquelle konnte nicht gefunden\n\nwerden.)(a “Person”) to exercise impartial judgment in the best interests of GLEIF.\n\nA Person is considered to have a potential Conflict of Interest if one of the following conditions is\n\nmet:\n\ne The Person or any Family Member may receive a financial or other material benefit as a result of\nthe Person’s position on the Board or at GLEIF; or\n\n¢ The Person has the opportunity to influence GLEIF's material decisions in a manner that leads to\na personal gain or advantage to themselves, any Family Member, or an organization with which\nthey are affiliated; or\n\n¢ The Person has the opportunity to influence GLEIF's material decisions in a manner that creates\nthe perception that the Person is using his or her position in GLEIF for such organizational or\npersonal gain; or\n\ne The Person has an existing or potential financial or other personal interest which impairs or has\nthe appearance of impairing the Person’s independence in carrying out his or her responsibilities\nto GLEIF.\n\nBoard Conflict of Interest Policy Page 4 of 8\nGLEIF GLEIF Public Version 1.1\n2023-02-03_Conflict of Interest Policy_1.1final 3 February 2023\n","contentLength":2283,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:23:47.660Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/policies/2023-02-03_conflict_of_interest_policy_1.1final.pdf","content":"In addition, a Conflict of Interest can be direct or indirect, depending on if the Person benefits\ndirectly or indirectly from a decision, contract or policy.\n1.3.2 Family Member\nFamily Member means any spouse, partner or civil partner, parent, sibling, child, or any other\nrelative who resides in the same household, and any other familial or social relationships that could\ncreate the appearance of a Conflict of Interest.\n2 Policy\nConflicts of Interest of varying degrees of significance and nature are an unavoidable reality in the\nconduct of GLEIF’s operations. A Conflict of Interest may not be inherently unethical, but those\ninvolved in decision-making processes on behalf of GLEIF must take appropriate action to ensure\ndisclosure of any actual, perceived or potential Conflicts of Interest.\nAs a result, GLEIF will be able to properly manage Conflicts of Interest and thus mitigate the\noperational and reputational risks inherent in such conflicts. A culture of openness and accountability\nis essential in order to prevent such situations occurring and to address them when they occur.\n2.1 Examples of Conflicts of Interest\nThe following activities illustrate types of potential or actual Conflicts of Interest that should be\navoided and, if not capable of being avoided, disclosed, as applicable, in accordance with this Policy.\nThe list is not exhaustive and is intended to provide guidance.\n2.1.1 Self-benefit/Benefit of Family Members\nUsing your position or relationship within GLEIF to promote your own interests or those of your\nfamily, employer or company, including using confidential or privileged information gained in the\ncourse of serving as a Board Member of GLEIF for personal benefit or gain or for the personal gain or\nbenefit of Family Members.\n2.1.2 Influence peddling\nSoliciting benefits for yourself or a Family Member from an outside organization in exchange for\nusing your influence to advance the interests of that organization within GLEIF.\n2.1.3 Other business relationships and dealings\nApproving grants or contracts with organizations in which you or a Family Member have a material\nfinancial or other interest or relationship, particularly if you are: (i) in a position to influence major\ndecisions; (ii) responsible for review, negotiation and approval of the grants or contracts; or (iii)\notherwise direct GLEIF’s business dealings with that business or entity.\nBoard Conflict of Interest Policy Page 5 of 8\nGLEIF GLEIF Public Version 1.1\n2023-02-03_Conflict of Interest Policy_1.1final 3 February 2023\n","contentLength":2543,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:23:47.660Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/policies/2023-02-03_conflict_of_interest_policy_1.1final.pdf","content":"2.1.4 Use of GLEIF property for personal advantage\n\nUsing or misappropriating GLEIF resources, including facilities, equipment, personnel, and supplies,\n\nfor private use or other unauthorized non-foundation activities.\n\n2.1.5 Recording or reporting false information\n\nMisrepresenting, withholding, or falsifying information required to be reported to external parties or\n\nused internally for decision-making purposes, in order to derive personal benefits.\n\n2.1.6 Dealings with grantees\n\nPersonally accepting anything of value from organizations or individuals that either: (i) have grant\n\nproposals pending before GLEIF; or (ii) have previously received grants from GLEIF.\n\n2.2 Disclosure of Conflicts of Interest\n\nA Person must disclose immediately any real or perceived Conflict of Interest, including those that\n\nderive from Family Members, and the nature of such interest whenever the Person becomes aware\n\nthat a Conflict of Interest exists, could be perceived to exist, or is reasonably likely to occur.\n\nSuch Conflicts must be disclosed to the Chairman of the Board (the \"Chair\"). In case of unavailability\n\nof the Chair, or if the Conflict relates to the Chair, the Conflict of Interest shall be disclosed to the\n\nVice Chair or the Chair of the Governance Committee (the \"Committee”).\n\nIf a Conflict of Interest arises during the course of a Board meeting, a Committee meeting or\n\nworkshop, the Person must disclose it to the Chair of the meeting in advance of any discussion of the\n\nrelevant agenda item.\n\n2.3 Management of Conflicts of Interest\n\nConflicted Board Members shall abstain from voting on Board resolutions directly and individually\n\naffecting themselves (Article 15 Statutes). This also applies for Board Committee resolutions.\n\n* When a potential Conflict of Interest is disclosed, the Board or Committee will provide the Board\nMember concerned with an opportunity to disclose all the material facts.\n\n¢ The Board or Committee will review the relevant information and may decide to question the\nrelevant parties where that is deemed appropriate. If it transpires that a Conflict of Interest does\nnot exist, the inquiry will be documented but no further action will be required.\n\no Ifthe Board or Committee decides that a Conflict of Interest exists, it will take the appropriate\nand proportionate measures to address the Conflict. This could include, but is not limited to,\nprohibiting the Board Member from voting on any matter related to the Conflict of Interest. The\nBoard Member will be excused from all deliberations related to the resolution of the Conflict of\nInterest.\n\nBoard Conflict of Interest Policy Page 6 of 8\nGLEIF GLEIF Public Version 1.1\n2023-02-03_Conflict of Interest Policy_1.1final 3 February 2023\n","contentLength":2742,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:23:47.660Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/policies/2023-02-03_conflict_of_interest_policy_1.1final.pdf","content":"2.4 Disciplinary Action\nIf the Board or Committee reasonably believe that a Person has failed to disclose an existing or\npotential Conflict of Interest, it shall inform the Person of the basis of such belief and grant them an\nopportunity to explain the alleged failure to disclose the Conflict.\nHaving heard representations from the Person, and the testimony of other witnesses as appropriate,\nthe Board or Committee may take appropriate disciplinary action, including removal from their role\nas a Board Member.\n2.5 Interpretation\nThis Policy cannot describe all Conflicts of Interest situations that may arise involving GLEIF.\nTherefore, all Persons bound by this Policy according to Fehler! Verweisquelle konnte nicht\ngefunden werden. must use good judgment to avoid any appearance of impropriety. Appropriate\ncircumstances may also justify exceptions to the application of the Policy.\nThe “Recommendation of the Council on OECD Guidelines for Managing Conflict of Interest in the\nPublic Service”1 in their then valid version can be consulted in the decision-making process.\nIf you have any questions about this Policy or its application, please err on the side of caution and\ntransparency and seek advice from the Board Secretary or the Chief Compliance Officer prior to\nentering into such transaction.\n2.6 Reports\nAnnually, each Board Member and the Board Secretary will submit a statement regarding their actual\nor potential Conflicts of Interest to the Chair, to be distributed to the Board and to the Regulatory\nOversight Committee. Failure to sign the annual report does not nullify the Policy.\n2.7 Supporting Policies and Procedures\nSeparate policies, processes, procedures and guidelines designed to support, and achieve compliance\nwith this Policy shall be developed, as appropriate, by GLEIF. The following “Related Documents”\ntable will be maintained and updated accordingly.\nRelated Documents\nBoard of Directors’ Expense Report Form Form\nRecord Retention Period: 10 years or local legal requirements, whichever is longer.\nL https://legalinstruments.oecd.org/en/instruments/OECD-LEGAL-0316\nBoard Conflict of Interest Policy Page 7 of 8\nGLEIF GLEIF Public Version 1.1\n2023-02-03_Conflict of Interest Policy_1.1final 3 February 2023\n","contentLength":2244,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:23:47.660Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/policies/2023-02-03_conflict_of_interest_policy_1.1final.pdf","content":"3 Implementation Responsibilities\nThe Chair is responsible for the implementation of this Policy and related procedures as described.\n4 Effective Date\nThis Policy shall enter into force with its publication.\nBoard Conflict of Interest Policy Page 8 of 8\nGLEIF GLEIF Public Version 1.1\n2023-02-03_Conflict of Interest Policy_1.1final 3 February 2023\n","contentLength":349,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:23:47.660Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/policies/2020-02-05_bod_travelandexpense_policy_v2.0-final-approved.pdf","content":"@’ Protecting digtal st\nBoard Travel and Expense\nPolicy\n","contentLength":56,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:24:03.664Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/policies/2020-02-05_bod_travelandexpense_policy_v2.0-final-approved.pdf","content":"Table of Contents\n1 Overview 00000000 RRRRRRRRRRRRRRRRRERRNRRRORRRRNRRRORRRRRERRRRRRRRERRENRRRRRRRRRRRRRRRRRRRRORRRRRCRRTRTRTS 4\nO R ¥ o o o 1 OO TP PPPPPPRPPPPPPRY -\nA Yo ] o 1= OO TP PPPPPPPPPPPPPRY -\n2 Policy 0000000000 RNRNRRRRRRRRNRRRNRRRRRERRNRRRRRRNRNRRRORRRRNRRRRRRRRERRNNRRRRRRRNRRRRRRRRRRRRORRRRRPRORORRTORTOTS 4\nD R N1 - o TP UURUURRTTY. |\n2.2 Automobiles/Transportation .......c.ccccceeeciieiieieiieeeee e e e eveeaestae e srraesraaesnaeees D\n. T & o) 7= £ PP UPUURRPURRNS 1\nD Y 1T | T PPUUPUURRPRURRRY o\n2.5 Other Reimbursable EXPENSES .....cccuuviiiieiiiiiiieeieenssiitie e svvieeeessssiieeee s esssseeaeeeesnns O\n2.6 Non-reimbursable EXPENSES .....ccivviiiiiiieeiiiiieeeeesesitrie s srireeeessssiieeeessssssssaeessenns O\n2.7 Foreign Currency Exchange and Exchange Rates.......cccccvvvvivveeeeiniiieeeeeennsiineenennns 7\nTN 14 (o Lol =T o 11 =T 4\n4 Auditing of EXpense REPOItS .....cccceeeiireeireenciinncrennerrnnesennseesnssesensseeens 7\n5 Related documents 000000000000 RNRRRRRRRRRERRORRRRRRRRNRRRRRRNRR0RR0RRRRRERRRRRRRRRRRRORRRRRCRRCRRORTOTS 8\n6 Effective Date 00000000000 RRRRRRRRRRRERRRRRRRRRRNRRRRRRRRERRNRRRRRERRRRRRORRRRRRRRORRRORRCRORRTRTNTS 8\nBoard Travel and Expense Policy Page 2 of 8\n@ GLEIF Public Version 2.0\n2020-02-05_bod_travelandexpense_policy_v2.0-final-approved 5 February 2020\n","contentLength":1316,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:24:03.664Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/policies/2020-02-05_bod_travelandexpense_policy_v2.0-final-approved.pdf","content":"_ Committee of Chairs\nAbout this policy\nThis document describes the Travel and Expense Policy of the Board of Directors. The Policy relates\nto ensure a diligent system of reporting expenses for travel of Board Members in the Global Legal\nEntity Identifier Foundation (GLEIF).\nChange History\nThis section records the history of all changes to this document.\n2019-03-27 2.0 The version 2.0 replaces version 1.0 Committee of\nafter a periodical review of the Chairs\npolicy\n2015-06-24 1.0 Approval of the Travel and Expense Committee of\nPolicy at Board Level Chairs\nBoard Travel and Expense Policy Page 3 of 8\nGLEIF GLEIF Public Version 2.0\n2020-02-05_bod_travelandexpense_policy_v2.0-final-approved 5 February 2020\n","contentLength":711,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:24:03.664Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/policies/2020-02-05_bod_travelandexpense_policy_v2.0-final-approved.pdf","content":"1 Overview\n\n1.1 Purpose\n\nGLEIF Statutes Article 19 provides guidance on the reimbursement of costs and travel expenses of\n\nBoard Members. This policy will establish and communicate standards for the controlling and\n\nreporting of Board travel expenses in a manner consistent with GLEIF Statutes. The GLEIF Board\n\nrecognizes that travel may compromise personal time. It is GLEIF’s intent to reimburse Board\n\nMembers for all reasonable expenditures associated with the conduct of GLEIF business recognizing\n\nGLEIF’s obligation to minimize expense wherever possible.\n\n1.2 Scope\n\nThe intended use of this policy is for all GLEIF Board Members. The guidelines listed below are\n\ndesigned to address usual business travel, entertainment and other expenses. Unusual circumstances\n\nmay require unexpected or atypical expenses, which are unavoidable. GLEIF asks that good business\n\njudgment be exercised wherever possible so that the goal of cost savings is achieved.\n\n2 Policy\n\n2.1 Airfare\n\nBoard Members are free to book their airfare with their chosen carrier and travel service if desired.\n\nThe goal is to seek the lowest possible fare available for all travel from your local destination to\n\nmeetings and events. Airfare reimbursement is capped based on the average costs of comparable\n\nairfare tickets as calculated by the GLEIF staff.\n\nAny airfare greater than 4 hours in duration (point-to point, layovers are not considered) may be\n\nbooked in BUSINESS class however this should be the lowest applicable fare. It is suggested that non-\n\nrefundable fares are purchased whenever possible. GLEIF will reimburse in cases where the Board\n\nMember has obtained travel insurance. First class travel will not be reimbursed.\n\nTravel plans should be made as far in advance as possible to obtain the most favorable fares.\n\nTypically, this is at least twenty-one (21) days in advance when possible or immediately upon\n\nreceiving a meeting announcement. It is understood that it is not always possible to obtain the\n\nlowest fare due to timing and circumstances and GLEIF request that Board Members consider GLEIFs\n\ncost management principles when making their bookings.\n\nIf a Board Member wishes to combine business travel with personal business, this is permissible as\n\nlong as the airfare booked does not exceed the lowest applicable fare available at the time of\n\nbooking. Spouses/Significant Others may travel with the Board Member if the Board Member so\n\ndesires, however, all expenses relating to this will not be borne by GLEIF. This includes room\n\nupgrades, additional flights, transportation, meals and the like.\n\nIn general, open-ended (one-way) fares are not permitted unless there is a specific business reason\n\nto do so. If such a case needs consideration, the traveler should consider booking a round trip and\nBoard Travel and Expense Policy Page 4 of 8\n\nGLEIF GLEIF Public Version 2.0\n2020-02-05_bod_travelandexpense_policy_v2.0-final-approved 5 February 2020\n","contentLength":2958,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:24:03.664Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/policies/2020-02-05_bod_travelandexpense_policy_v2.0-final-approved.pdf","content":"making changes as soon as the actual return date is known. The penalty/change fee is usually less\nexpensive than the cost of the one-way ticket.\nIn the event that a Board Meeting is cancelled, GLEIF will reimburse Board Members for any non-\nrefundable incurred expenses as of the cancellation date.\nIn the event that a Board Member cancels attendance at a Board Meeting, GLEIF will consider\nreimbursement on a case-by-case basis.\nN.B: Directors may keep any travel related awards or club points (e.g. Frequent Flier miles, Hotel\npoints, etc.).\n2.2 Automobiles/Transportation\nAirport Taxis, Buses, Subways and the like should be used for local transportation where most\nconvenient and economical. Taxis should be used only when other local transportation is untimely or\nunavailable, or when heavy luggage is being transported. Reimbursement will be for actual expense,\nincluding tip but should not exceed 100- miles/161 km of total distance and based on the average\ncosts.\nWhen required for business purposes, GLEIF will reimburse Board Members for car rentals. We\nrecommend that the rental be for a mid-size vehicle unless the Board Members are sharing it with\nother Board members or staff. In those cases, a full-size car is appropriate.\nPersonal cars may also be used as required for business purposes. The use of a personal car and\nparking costs will be reimbursed at the standard rate established by GLEIF.\nTrain travel will be reimbursed based upon a round-trip, business class fare. Exceptions for night\nsleeper ticket shall be brought to the attention of the Board Chair or Vice Chair for review on a case-\nby-case basis.\n2.3 Hotels\nWhen required for meetings, Board Members may stay hotels that are reasonably priced and close\nand convenient to the place where the meeting will be held. Reimbursement will be made for actual\ncosts incurred for accommodations within policy.\nGLEIF expects that Board Members will stay at business-class hotels with a reasonable rate. Rather\nthan establish a set guideline value, given that the meeting locations are diverse, GLEIF requests that\nBoard Members use their best judgment when booking. Usually, GLEIF offers a choice of Hotels with\nnegotiated rates which should be used for Board travel. Exceptions to this shall be brought to the\nattention of the Board Chair or Vice Chair for review on a case-by-case basis. As previously stated,\nGLEIF has been charged with cost reduction wherever possible and this should be a consideration\nwhen reviewing options. It is expected that a reasonable accommodation would be a single-\nroom/private bath rate.\nAs previously noted, any expenses relating to non-Board Members traveling with a Board Member\nwill not be reimbursed.\nBoard Travel and Expense Policy Page 5 of 8\nGLEIF GLEIF Public Version 2.0\n2020-02-05_bod_travelandexpense_policy_v2.0-final-approved 5 February 2020\n","contentLength":2861,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:24:03.664Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/policies/2020-02-05_bod_travelandexpense_policy_v2.0-final-approved.pdf","content":"GLEIF suggests that hotel rooms be ,guaranteed’ for late arrival. Board Members are requested to\ncancel reservations within the time limits of the hotel so that no unnecessary charges are incurred.\nGLEIF may reimburse such charges on a case-by-case basis.\n2.4 Meals\nMeals are reimbursable while traveling on GLEIF-related business when not provided by the meeting\nhost or GLEIF. It is expected that Board Members will exercise good business judgment. In addition to\na receipt, the Board Member is asked to provide a list of all attendees and an explanation of the\nbusiness purpose of the meal. The cost of a Director’s meals should not exceed $75 per day.\n2.5 Other Reimbursable Expenses\nFitness Center Fee: Fees for the use of hotel fithess centers will be reimbursed up to $20 USD per\nday.\nGratuities: Gratuities to waiters and taxi drivers and the like should be included in the cost of meals\nand taxis, respectively. Other gratuities, such as tips to reported by a GLEIF ‘Missing Receipt\nDeclaration’ by the Board Member.\nTelephone/Cellphone Calls: Whenever possible, the Board Member is encouraged to use the GLEIF\nvideo and VOIP resources in place. Extensive long-distance conference calls should be avoided as\nfeasible. The GLEIF will reimburse Board Members for all reasonable and actual charges directly\nrelating to GLEIF business. Detailed receipts for the calls being expensed must be submitted.\nCharges for Baggage (Luggage): Reasonable baggage charges will be reimbursable. Excess baggage is\nnot reimbursable unless that baggage holds GLEIF related records or property.\nExpenses without receipt — will be reimbursed after approval and exceptional reimbursement needs\nto be requested, ideally with other supporting documents.\n2.6 Non-reimbursable Expenses\nListed below is a list of non-reimbursable expenses that are often incurred while traveling:\no Shoe shining, barber and similar items.\n* In-Room Movies and pay services.\no Excess cost of making circuitous or side trips for personal reasons.\no Fines for traffic violations, including parking fines.\no Loss of personal property - clothes jewellery, etc.\no Loss of personal funds or tickets.\no Purchase of clothing or toiletries and similar items for personal use.\no Late/delinquency charges on credit cards for untimely submission of expenses to GLEIF for\nprocessing.\nBoard Travel and Expense Policy Page 6 of 8\nGLEIF GLEIF Public Version 2.0\n2020-02-05_bod_travelandexpense_policy_v2.0-final-approved 5 February 2020\n","contentLength":2484,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:24:03.664Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/policies/2020-02-05_bod_travelandexpense_policy_v2.0-final-approved.pdf","content":"o Cost of members of a Board Member’s family traveling with him/her except in those instances\nwhere their presence serves a bona fide business purpose.\n\n* Maintenance and/or repair of personal property while traveling.\n\ne Memberships in social or athletic organizations.\n\no Purchase of luggage or attaché cases.\n\n* Entertainment of spouses/significant others.\n\n2.7 Foreign Currency Exchange and Exchange Rates\n\nAny currency exchange receipts may be submitted for reimbursement of service/commission\ncharges.\n\nAll conversion rates used must be clearly indicted on expense reports including the source of the rate\nused. It can be a published rate or the rate charged directly through a credit card transaction.\n\nAs a reminder, all expenses must be submitted for reimbursement within 90 days from the date of\nthe receipts. This policy is intended for to help control the impact of foreign exchange fluctuation.\n\n3 Procedures\n\nAccording to GLEIF’s Organizational Regulations, Compliance is overseen by the Governance\nCommittee (GC).\n\nThe role of the GC is to provide advice and counsel to the Chair of the Board to support the proper\ngovernance of the GLEIF, in particular with respect to its compliance with the Statutes and By-laws\nand with all applicable provisions of applicable law and regulation. In particular, the GC shall have the\nduties and competencies to serve as the compliance committee of the Board and in that capacity\nmonitor, compliance with any matters raised by a Board Member, the ROC, the Swiss Supervisory\nAuthority or any other regulatory or oversight bodies.\n\nThe GC reviews an annual report from the Compliance Officer which is an assessment of compliance\nrisk within GLEIF operations and the activities of the Compliance Officer in this context.\n\n4 Auditing of Expense Reports\n\nThe Audit and Finance Committee (AFC) annually requests that its external auditor reviews the travel\ncosts of the Board of Directors in a special engagement and reports any findings to the Board Chair\nand Audit and Finance Committee.\n\nIf non-compliant behavior is observed, the Chair of the AFC has the duty to inform the Chair of the\nBoard of Directors and the Chair of the Governance Committee.\n\nBoard Travel and Expense Policy Page 7 of 8\nGLEIF GLEIF Public Version 2.0\n2020-02-05_bod_travelandexpense_policy_v2.0-final-approved 5 February 2020\n","contentLength":2349,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:24:03.664Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/policies/2020-02-05_bod_travelandexpense_policy_v2.0-final-approved.pdf","content":"5 Related documents\n\nThe following RELATED DOCUMENTS table will be maintained and updated accordingly.\n\nRelated Documents\n\nBoard of Directors’ Expense Report Form Form\n\n6 Effective Date\n\nThis Policy shall enter into force with its publication.\nBoard Travel and Expense Policy Page 8 of 8\n\nGLEIF GLEIF Public Version 2.0\n2020-02-05_bod_travelandexpense_policy_v2.0-final-approved 5 February 2020\n","contentLength":395,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:24:03.664Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/policies/16-09-16_General_Accounting_FIN007_v.1_final.pdf","content":"OGLEIF, Protecting digtal rust\nTreasury Framework Policy\n","contentLength":57,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:24:11.123Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/policies/16-09-16_General_Accounting_FIN007_v.1_final.pdf","content":"Subject Area: General Accounting Policy#: FINOO7 Level 1\n\nPolicy Title: GLEIF Treasury Framework Policy\n\nFinal Approver: Chair, Board of Directors\n\nKey Policy User(s): Board of Directors\n\nChief Executive Officer\n\nAFC Committee Chair Review Date: 17/11/2015\n\nAFC Recommendation: X (YES) O (NO) 17/11/2015\n\nBoard Approval Date: 16/12/2015\n\nEffective Date: 16/12/2015\n\nPURPOSE:\n\nThe purpose of this policy is to provide an overall framework in which to organize and manage GLEIF\n\ntreasury activities.\n\nPOLICY:\n\nThis policy outlines the following overall scope of the GLEIF Treasury function:\n\n1. Cash and Liquidity management: The ongoing liquidity needs of GLEIF will be monitored\nregularly to ensure cash flow requirements are met on a day to- day, cyclical, and long-term\nbasis. Liquidity risk results from the Foundation’s potential inability to meet its financial\nliabilities, in particular the ongoing cash requirements of operating activities.\n\n2. Foreign exchange exposure management: The operating structure of GLEIF exposes the\nFoundation to foreign currency exchange rate risk in the ordinary course of business. The\nFoundation shall monitor and manage foreign exchange risk in order to mitigate the risk\nexposure to unpredicted and unwanted currency exchange fluctuations.\n\n3. Interest Rate risk management: The Foundation shall monitor and manage interest rate risk.\nInterest rate risk is the risk that the fair value or future cash flows of a financial instrument will\nfluctuate because of changes in market interest rates. This risk arises whenever interest terms of\nfinancial assets and liabilities are different.\n\n4. Investment management: The Foundation shall establish guidelines for investing/managing the\nfunds of GLEIF. A separate investment policy shall be developed by the Foundation.\n\nTreasury Framework Policy Page 2 of 3\nGLEIF 16-09-16_General_Accounting_FINOO7_v.1_final Version 1.1\n16 September 2016\n","contentLength":1926,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:24:11.123Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/policies/16-09-16_General_Accounting_FIN007_v.1_final.pdf","content":"5. Banking relationship management: The Foundation shall manage all banking relationship\nactivities, including, but not limited to:\ne Opening and closing of all GLEIF bank accounts\n¢ Maintaining authorized signatories for all GLEIF bank accounts\ne Compiling, issuing, and evaluating all Requests for Proposal with regards to any and all\nbanking services\no Serving as the first point of contact for any bank contact for GLEIF\nSUPPORTING POLICIES AND PROCEDURES:\nSeparate policies, procedures and guidelines designed to support, and achieve compliance with this\npolicy shall be developed, as appropriate, by GLEIF. The RELATED DOCUMENTS section below will be\nmaintained and updated accordingly.\nRESPONSIBILITIES AND ADMINISTRATION\nIt is the responsibility of the Board of Directors to approve and amend the Treasury Policy,\nand any exceptions to the Treasury Policy.\nIt is the responsibility of the CEO to:\no Implement the Treasury Policy and designate those who can act on behalf of the CEO including\noutside money management firms;\n¢ Monitor the existing portfolio for suitability, performance and conformity with this Treasury\nPolicy and report on same on a quarterly basis to the Board,;\n* Annually review and propose amendments, as appropriate, to the Treasury Policy\nRELATED DOCUMENTS\nN/A\nRecord Retention Period: 10 years or local legal requirements\nwhichever is greater\nTreasury Framework Policy Page 3 of 3\nGLEIF 16-09-16_General_Accounting_FINOO7_v.1_final Version 1.1\n16 September 2016\n","contentLength":1495,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:24:11.123Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/policies/16-09-16_IA_Charter_v.1_final.pdf","content":"O:GLEIF’ rotatun ol st\nInternal Audit Charter\n","contentLength":46,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:24:23.427Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/policies/16-09-16_IA_Charter_v.1_final.pdf","content":"Subject Area: Corporate Governance Policy#: GOV0O03 Level 1\nPolicy Title: GLEIF Internal Audit Charter\nFinal Approver: Chair, Board of Directors\nKey Policy User(s): Audit & Finance Committee\nBoard of Directors\nChief Executive Officer\n\nAFC Committee Chair Review Date: 11/09/2015\nAFC Recommendation: X (YES) O (NO) 17/11/2015\nBoard Approval Date: 16/12/2015\nEffective Date: 01/01/2016\nPURPOSE:\nThis policy establishes the policy, objectives and procedures of the Internal Audit (“IA”) function\nwithin the GLEIF.\nROLE:\nInternal Auditing is an independent and objective compliance, assurance and consulting activity\nthat is guided by a philosophy of adding value to improve the operations of the organization it\nserves. |A supports the organization in accomplishing its objectives by bringing a systematic,\ndisciplined approach to evaluating and improving the effectiveness of risk management,\ncontrol and governance processes.\nThe Head of Accreditation & Audit Services reports directly to the Chair of the Audit & Finance\nCommittee for audit related matters and administratively to the Chief Executive Officer for\nday-to-day operations.\n\nInternal Audit Charter Page 2 of 5\nGLEIF 16-09-16_IA/_Charter_v.1_final Version 1.1\n\n16 September 2016\n","contentLength":1240,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:24:23.428Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/policies/16-09-16_IA_Charter_v.1_final.pdf","content":"OBJECTIVES:\nIA’s mission is to provide GLEIF with value-added services by:\no Supporting the Chief Executive Officer and the Audit & Finance Committee of the Board in the\nexecution of its fiduciary and oversight responsibilities,\no Partnering with the GLEIF team to understand and evaluate their risks, internal control\nenvironments, and risk mitigation activities,\no Developing and executing a rolling schedule of audit projects that addresses these risks to be\napproved by the Board,\ne Promoting overall risk and controls awareness and\ne Evaluating existing controls and advising on effective and efficient control improvements.\nSCOPE:\nIA scope will include functions and topics within the GLEIF itself based upon the audit plan approved\nby the Audit & Finance Committee on an annual basis and/or special requests from the Audit &\nFinance Committee, the Chair of the Board or the Chief Executive Officer.\nThe scope of internal auditing encompasses, but is not limited to, the examination and evaluation of\nthe adequacy and effectiveness of the organization's governance, risk management, and internal\ncontrols as well as the quality of performance in carrying out assigned responsibilities to achieve the\norganization’s stated goals and objectives. This includes:\no Evaluating the reliability and integrity of financial and operational information and the means\nused to identify, measure, classify, and report such information.\ne Evaluating the systems established to ensure compliance with those policies, plans, procedures,\nlaws, and regulations which could have a significant impact on the organization.\no Evaluating the means of safeguarding assets and, as appropriate, verifying the existence\nof such assets.\no Evaluating the effectiveness and efficiency with which resources are employed.\no Evaluating operations or programs to ascertain whether results are consistent with established\nobjectives and goals and whether the operations or programs are being carried out as planned.\no Coordinating as necessary with external auditors as they assess the GLEIF internal\ncontrol environment.\n¢ Monitoring and evaluating governance processes and the effectiveness of the organization's\nrisk management processes.\no Reporting significant risk exposures and control issues, including fraud risks, governance issues,\nand other matters needed or requested by the Board.\nInternal Audit Charter Page 3 of 5\nGLEIF 16-09-16_IA/_Charter_v.1_final Version 1.1\n16 September 2016\n","contentLength":2468,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:24:23.428Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/policies/16-09-16_IA_Charter_v.1_final.pdf","content":"IA is also charged with conducting audits at LOU operations under certain circumstances. This type of\naudit activity is defined in the Master Agreement in Chapter 11 Subchapter D “Independent Audits at\nLOU Locations”. The execution of such projects will be consistent with the above scope statements.\nINTERNAL AUDIT PLANNING:\nAt least annually, the Head of Accreditation & Audit Services will submit to senior management and\nthe Board an internal audit plan for review and approval. The internal audit plan will consist of a\nwork schedule as well as budget and resource requirements for the next fiscal/calendar year. The\nHead of Accreditation & Audit Services will communicate the impact of resource limitations and\nsignificant interim plan changes to senior management and the Board as they occur.\nPROFESSIONALISM:\nIA will provide these services in a professional manner and will obtain competent advice and\nassistance from subject matter experts as needed to ensure appropriate due professional care.\nIA will govern itself by adherence to The Institute of Internal Auditors' mandatory guidance including\nthe Definition of Internal Auditing, the Code of Ethics, and the International Standards for the\nProfessional Practice of Internal Auditing. This mandatory guidance constitutes principles of the\nfundamental requirements for the professional practice of internal auditing and for evaluating the\neffectiveness of the internal audit activity’s performance.\nIA will also maintain their knowledge, skills, and other competencies through continuing professional\neducation to satisfy requirements related to the professional certifications they hold.\nAUDIT PRACTICES, REPORTING & MONITORING:\nAudit projects, as approved by the Audit & Finance Committee and/or the Chief Executive Officer,\nwill specify the work to be performed, the estimated timing of the project, and the estimated\nnumber of hours planned. A status report will be presented at all Audit & Finance Committee\nmeetings as to project status and planned activities as applicable.\nAll audit engagements will include a formal opening meeting at which audit scope is discussed,\na preliminary review and discussion of the draft audit report, a closing meeting at which all audit\nfindings are discussed and a final report that allows for Management to provide its own commentary\non findings noted.\nAll final audit reports will be copied to the Audit & Finance Committee Members, the Board Chair,\nthe Chief Executive Officer and the General Counsel. GLEIF’s external auditors will be granted access\nto the final reports of any audit upon requested with the approval of the Audit & Finance\nCommittee Chair.\nThe internal audit activity will be responsible for appropriate follow-up on engagement findings\nand recommendations. All significant findings will remain in an open issues file until cleared.\n\nInternal Audit Charter Page 4 of 5\nGLEIF 16-09-16_IA/_Charter_v.1_final Version 1.1\n\n16 September 2016\n","contentLength":2960,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:24:23.428Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/policies/16-09-16_IA_Charter_v.1_final.pdf","content":"ACCESS and AUTHORITY\nIn the execution of its duties, with strict accountability for confidentiality and safeguarding records\nand information, A is authorized by the Board and to have full, free, and unrestricted access to all\nGLEIF activities, operations, records, property, and personnel.\nIA will use its best professional judgment in the execution of audit projects in terms of determining\nrequired resources, scope of work and level of testing, and application of analytical techniques to\naccomplish audit objectives.\nIA is specifically not authorized to:\no Perform any operational duties for the GLEIF\no Initiate or approve accounting transactions,\no Direct the activities of any GLEIF employee outside of IA.\nACCOUNTABILITY, OBJECTIVITY & INDEPENDENCE:\nThe Head of Accreditation & Audit Services will periodically report to senior management and the\nBoard on the internal audit activity’s purpose, authority, and responsibility, as well as performance\nrelative to its plan. Reporting will also include significant risk exposures and control issues, including\nfraud risks, governance issues, and other matters needed or requested by senior management and\nthe Board.\nInternal auditors will exhibit the highest level of professional objectivity in gathering, evaluating, and\ncommunicating information about the activity or process being examined. Internal auditors will make\na balanced assessment of all the relevant circumstances and not be unduly influenced by their own\ninterests or by others in forming judgments.\nThe Head of Accreditation & Audit Services will confirm to the Board, at least annually, the\norganizational independence of the internal audit activity.\nThe Head of Accreditation & Audit Services may communicate directly in confidence to the Audit &\nFinance Chair, the Chair of the Board, or the GLEIF General Counsel at its discretion.\nInternal Audit Charter Page 5 of 5\nGLEIF 16-09-16_IA/_Charter_v.1_final Version 1.1\n16 September 2016\n","contentLength":1959,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:24:23.428Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/policies/2020-01-24_whistleblowingpolicy_v1.0-final-approved.pdf","content":"O:GLEIF, Protecting digta st\nWhistleblowing Policy\nGLEIF Public ‘ \\\nVersion 1.0\n\n2020-02-05\n","contentLength":92,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:24:38.139Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/policies/2020-01-24_whistleblowingpolicy_v1.0-final-approved.pdf","content":"Table of Contents\nA O 1 [T o= U |\nO R ¥ o o o 1 OO TP PPPPPPRPPPPPPRY -\nA Yo ] o 1= OO TP PPPPPPPPPPPPPRY -\n1.3 DefinitioNS .cuviiiiei i ssaareee s s s saannneeeeesnnnns B\nP A o [T o PR . |\n2.1 What is Whistleblowing? ........ccooiiiiiiiiiiiiieceee e nee e &\n2.2 What types of concerns can be raised by whistleblowers? .........ccccccceievviiieennn. 5\n2.3 CoNFIAENTIAlItY .eveeeeeeiiiieee e e D\n2.4 How toraise a concerninternally ......cccccoevviieiiiiiiiiiiie e sreae e e ens ©\nBt ) =T o Nt PO PP PP PP RNRUPPPPPPPPPPRPRY\nB A =] o 07 AN o1\nB e ) =T o I F O OO UP O PP P PP PP RNRUPPPPPPPPPPRORY\n2.5 How toraise a concern externally.......ccccoovviieiiiiiiiiiiiee e seeee e e ens ©\n2.6 What happens NEXTE......eiiiiiiiiiiieeeeciiee et ee e seee e e srareeeessssbabeeesessaasnsaeesssns O\n2.7 Support for WhistlebloOWErs.........covviiiiiiiiiiie et seeae e ees ©\n2.8 REPOITS ittt ettt e e ee e e e ee e rere et s eeeeeeeeeeeaeeessenennenn T\n2.9 Supporting Policies and ProCedUIES.........cccvueveeiiiniiiieeieeeiiiieeeeesssiiieeesessinnneeessnns 1\n3 Implementation Responsibilities.....ccccccceereeiiuniireiirenciencerencrencceenceenceeees 7\nT SN = i {=Tot V=T D T | Y J\n@ Whistleblowing Policy Page 2 of 7\nGLEIF GLEIF Public Version 1.0\n2020-01-24_whistleblowingpolicy_v1.0-final-approved 5 February 2020\n","contentLength":1308,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:24:38.139Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/policies/2020-01-24_whistleblowingpolicy_v1.0-final-approved.pdf","content":"_ Governance Committee (Level 1) and CEO (Level 2)\nAbout this policy\nThis document describes the Whistleblowing Policy. The Policy relates to the encouragement of the\nGLEIF Board Directors and Secretary of the Board to report suspect wrongdoing as soon as possible in\nthe knowledge that their concerns will be taken seriously and investigated as appropriate and their\nconfidentiality will be respected.\nChange History\nThis section records the history of all changes to this document.\n2020-02-05 1.0 Whistleblowing Policy GLEIF\nWhere changes are made for clarity and reading ease only and no change is made to the\nmeaning or intention of this document, the version number will be increased by 0.1.\nWhere significant changes are made to this document, the version number will be incremented\nby 1.0.\nWhistleblowing Policy Page 3 of 7\nGLEIF GLEIF Public Version 1.0\n2020-01-24_whistleblowingpolicy_v1.0-final-approved 5 February 2020\n","contentLength":930,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:24:38.139Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/policies/2020-01-24_whistleblowingpolicy_v1.0-final-approved.pdf","content":"1 Overview\n1.1 Purpose\nThis Policy describes the Whistleblowing process mentioned in GLEIF’s Compliance Policy in\ndetail.\n1.2 Scope\nThe Policy applies to everyone who carries out work for GLEIF, including:\n¢ Board Members\no Board Secretary\n« CEO\no All employees\n¢ Local Operating Units (LOUs)\no Registration Agents\ne Contractors\ne Consultants\no Secondees from third parties\no Trainees\n1.3 Definitions\nGLEIF is committed to conduct its business with honesty and integrity, and expects all staff to\nmaintain high standards in accordance with its policies and procedures. However, all organizations\nface the risk of things going wrong from time to time, or of unknowingly harbouring illegal or\nunethical conduct. A culture of openness and accountability is essential in order to prevent such\nsituations occurring or to address them when they occur.\n2 Policy\n2.1 What is whistleblowing?\nWhistleblowing is the disclosure of information which relates to suspected wrongdoing. If an\nemployee sees or find out about something and thinks it is wrong at GLEIF she or he should report it.\nThe employee should go first to its line-manager or any other senior person. If she or he cannot or do\nnot wish to do this for any reason this whistleblowing policy should be followed.\nRaising concerns about wrongdoing can be one of the most difficult and challenging things to doin a\nwork environment. Under this policy an employee may come forward with legitimate concerns\nwithout fear of being blamed or suffering any disadvantage for doing so.\nWhistleblowing Policy Page 4 of 7\nGLEIF GLEIF Public Version 1.0\n2020-01-24_whistleblowingpolicy_v1.0-final-approved 5 February 2020\n","contentLength":1659,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:24:38.139Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/policies/2020-01-24_whistleblowingpolicy_v1.0-final-approved.pdf","content":"2.2 What types of concerns can be raised by whistleblowers?\nThe law provides protection for employees who reasonably believe that they are acting in the public\ninterest and where the disclosure falls into one of more of the following categories:\no Acriminal offence that has, is being, or is likely to be committed\ne Unauthorised or inappropriate disclosure, misuse or loss of confidential, personal and / or\nsensitive information\ne A miscarriage of justice\no Risk or damage to the environment\no Adanger to the health and safety of employees or others\no Attempts to suppress or hide information relating to wrongdoing.\nThe concern can be about an incident that happened in the past, is happening now or that the\nemployee believes is likely in the future.\nIt is immaterial whether the information is confidential and whether the incident occurred, occurs or\nwould occur in Germany and whether the law applying to it is that of Germany or any other country\nor territory.\nAs long as the employee holds a reasonable belief that the information is true then she or he will be\ncovered by the protection set out in this policy regardless of whether she or he is mistaken or the\nmatter cannot be proved.\nWhistleblowing does not cover concerns where there is no public interest element such as a concern\nabout the own employment or related matters. Those concerns should be raised with the HR\nManager.\n2.3 Confidentiality\nIt is possible for an employee to raise its claim anonymously if she or he wishes to do so. However,\nthis may mean that it is difficult to investigate fully if the employee hasn’t provided GLEIF with\nenough information.\nGLEIF assures that it will not tolerate any harassment or victimisation of staff and would encourage\nthe employee to provide its name so GLEIF can fully investigate the matter. Employee may ask for\nconfidentiality when doing so and GLEIF will respect this.\nIf an employee asks for confidentiality GLEIF will make every effort to protect employee’s identity\nunless required to disclose it by law. If it becomes clear that GLEIF is unable to resolve the issue\nwithout revealing employee’s identity GLEIF will discuss this with the employee, taking into account\nemployee’s views and GLEIF’s wider legal obligations before deciding whether or not to proceed with\nthe investigation.\nWhistleblowing Policy Page 5 of 7\nGLEIF GLEIF Public Version 1.0\n2020-01-24_whistleblowingpolicy_v1.0-final-approved 5 February 2020\n","contentLength":2444,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:24:38.139Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/policies/2020-01-24_whistleblowingpolicy_v1.0-final-approved.pdf","content":"2.4 How to raise a concern internally\n241 Stepl\nWhere possible the employee should raise any matter of concern, serious or otherwise with its\nDepartment Head. This may be done either verbally or in writing.\n2.4.2 Step2\nIf the employee feels unable, for whatever reason, to raise the matter with its Department\nHead, she or he may go to the Chief Compliance Officer.\n243 Step3\nIf these steps have been followed and the employee still feel to have concerns, or that they\nhave not been addressed, or that she or he cannot discuss the matter with any of the above\nthen the CEOQ, the Chairman of the Board or the Chair of the Governance Committee should\nbe contacted.\nWhen raising the concern, it is helpful to provide an explanation with as much detail as\npossible including dates and times of incidents, any eye witness details and any supporting\ndocuments that the employee has.\n2.5 How to raise a concern externally\nWhere attempts to raise matters internally have been unsuccessful or, exceptionally, the employee\nfeel the concerns cannot be raised internally, she or he may consider raising the matter with the\nrelevant regulatory authority.\n2.6 What happens next\nThe person who the employee raised the concern to\no will listen to and consider the concern in full and determine whether any action is needed. This\nmay mean reporting it to a more senior member of staff or to the Governance Committee\no will try to keep the employee informed about the actions that were taken in relation to the\nconcern including a proposal how to deal with the matter, whether further assistance is needed\nfrom the employee, any action that is taken and the outcome of the investigation\no eventually may not be able to provide the employee with much detail where there’s a duty to\nkeep the confidence of other people.\n2.7 Support for whistleblowers\nWhistleblowing may be very difficult. GLEIF will take every step to ensure that whistleblowers are\nprotected and supported internally. However, GLEIF recognizes that people may feel more\ncomfortable seeking external support in this situation.\nIf so, GLEIF would encourage whistleblowers to contact Thomas Sprecher at NKF law office\nthomas.sprecher@nkf.ch or +41 58 800 80 00.\nWhistleblowing Policy Page 6 of 7\nGLEIF GLEIF Public Version 1.0\n2020-01-24_whistleblowingpolicy_v1.0-final-approved 5 February 2020\n","contentLength":2340,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:24:38.139Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about/governance/policies/2020-01-24_whistleblowingpolicy_v1.0-final-approved.pdf","content":"2.8 Reports\nThe Chief Compliance Officer will annually inform CEO, Board of Directors and the external auditors\nabout concerns raised under this Whistlebowing Policy and measures adopted to treat potential\nmisconducts.\n2.9 Supporting Policies and Procedures\nSeparate policies, processes, procedures and guidelines designed to support, and achieve compliance\nwith this policy shall be developed, as appropriate, by GLEIF. The following RELATED DOCUMENTS\ntable will be maintained and updated accordingly.\nWhistleblowing Policy Board Policy\nRecord Retention Period: 10 years or local legal requirements whichever is greater\n3 Implementation Responsibilities\nThe Governance Committee is responsible for the implementation of this policy and related\nprocedures as described.\n4 Effective Date\nThis Policy shall enter into force with its publication.\nWhistleblowing Policy Page 7 of 7\nGLEIF GLEIF Public Version 1.0\n2020-01-24_whistleblowingpolicy_v1.0-final-approved 5 February 2020\n","contentLength":977,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:24:38.139Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/get-an-lei-find-lei-issuing-organizations/how_to_identify_your_new_lou_after_the_termination_of_business_entity_data_b_v.pdf","content":"G LE I F Enabling global identity\nProtecting digital trust\nHow to identify your new LOU after the termination of Business Entity Data B.V.?\nTo identify your new LOU, please refer to the table below. Please note that LEls were transferred on a\njurisdictional basis. In case you are not 100% clear about the jurisdiction of your LEI(s), you can consult the Global\nLEIl Index, look for your LEI(s) and verify the jurisdiction of formation of the LEI(s).\nGlobal Legal Entity Identifier Foundation\nas of 2023-07-19T00:00:00Z\n- Events and Changes Show XML vLEls\nLEI Code 506700GE1G29325QX363 @ w\n(Primary) Legal Name Global Legal Entity Identifier Foundation\nOther Names Global Legal Entity Identifier Stiftung\nRegistered At UID-Register (Federal Statistical Office)\nIn French: Registre IDE; in German: UID-Register; in Italian: Registro IDI (In French: Office fédéral\nde la statistique; in German: Bundesamt fir Statistik; in Italian: Ufficio federale di statistica)\nLiechtenstein\nSwitzerland\nRAQO0548\nRegistered As CHE200595965\nGeneral Category GENERAL\nUnited States, Latin Bloomberg\nAmerica and the lei-support@bloomberg.net\nCaribbean 5493001KJTIIGC8Y1R12\nEQS\nCanada lei@egs.com\n529900F6BNUR3RJ2WH29\n© 2023 GLEIF and/or its affiliates. All rights reserved. GLEIF unrestricted. Page 1 of 2\n","contentLength":1286,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:24:43.970Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/get-an-lei-find-lei-issuing-organizations/how_to_identify_your_new_lou_after_the_termination_of_business_entity_data_b_v.pdf","content":": , Enabling global identity\nGLEIF Protecting digital trust\nCayman Islands & Bundesanzeiger Verlag '\n. - transfer@leireg.de\nBritish Virgin Islands 39150001kuLK7200U106\nLuxembourg, Sweden,\nDenmark, Norway,\no | NordLEl\nFinland, Faroe Islands support@nordlei.org\nand Iceland 5493000897ZC5H7CY412\nAll other European London Stock Exchange lei@lseg.com\n(st et s 213800WAVVOPS85N2205\nHong Kong and GS1 AISBL Hong Kong: lei@gs1lhk.org\nST 52990034RLKTOWSOAM90 Singapore:LEl_support@gsl.org.sg\nAll other Asian London Stock Exchange lei@lseg.com\n(st et s 213800WAVVOPS85N2205\nLondon Stock Exchange lei@lseg.com\nAll African jurisdictions\n213800WAVVOPS85N2205\nWM Datenservice lei-onboarding@wmdaten.com\nAustralia\n5299000J2N45DDNE4Y28\nAll other Oceanian London Stock Exchange lei@lseg.com\n(st et s 213800WAVVOPS85N2205\n© 2023 GLEIF and/or its affiliates. All rights reserved. GLEIF unrestricted. 2\n","contentLength":885,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:24:43.970Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/get-an-lei-find-lei-issuing-organizations/registration-agents/2023_03_28_registration-agents-governance-framework_1.0.pdf","content":"O:GLEIF’ Protecting dottal rust\n\nRegistration Agents Governance\nFramework 1.0\n\nVersion 1.0 ‘ \\\n","contentLength":95,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:24:58.514Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/get-an-lei-find-lei-issuing-organizations/registration-agents/2023_03_28_registration-agents-governance-framework_1.0.pdf","content":"1) Guidelines for Registration Agents\nIn 2018, GLEIF introduced the concept of ‘Registration Agent’ to help legal entities to access the\nnetwork of LEl issuing organizations responsible for performing LEl issuance and related services. Since\nthen, more than 100 Registration Agents have entered the Global LEI System helping legal entities to\nobtain and renew their LEls.\nTo ensure the Global LEI System’s integrity and seamless operations, GLEIF has established the\nfollowing set of guidelines for Registration Agents. LEIl Issuers in partnership with the operating\nRegistration Agents are to ensure that these best practices are followed. Non-compliance with below\nguidelines can lead to formal complaints by other LEIl Issuers or GLEIF and to the termination of\nRegistration Agents’ operations.\nGLEIF would like to remind that the good reputation and operational workflows of the Global LEI\nSystem depend on each and every member of the system. Moreover, Registration Agents shall endorse\ncollaboration among other Registration Agents and LEIl Issuers at all times.\nThe below guidelines are intended to address recent operational issues identified by GLEIF and provide\ndetailed guidance:\n\n1. Registration Agents shall make sufficiently clear on their website and in their promotional\nmaterials to their (potential) clients that a Registration Agent is not an LEI Issuer, but that a\nRegistration Agent performs certain tasks in the process of obtaining, renewing, or transferring\nof an LEI for an LEl Issuer or multiple LEI Issuers and that the issuing, transferring or renewing\nof the LEl is always done by the related LEI Issuer.\n\n2. Registration Agents shall identify themselves and their partner LEl Issuer via the respective LEI,\nthe LEI Issuer monitors that the Registration Agent’s LEl is in Registration Status ISSUED at all\ntimes.\n\n3. Registration Agents shall clearly display on their website pages the three different LEIl services:\n‘Issuance’, ‘Renewal’, and ‘Transfer’. Registration Agents shall specify whenever a renewal is\nrequested by a legal entity that is not managed by their partnering LEI Issuer, which will first\nrequire a transfer to a different LEl Issuer.\n\n4. Registration Agents shall not provide conflicting information regarding the two different\nservices of LElI renewal and LEI transfer. However, the combination of transfer and renewal\nmakes sense from a pricing, customer convenience and data validation point of view.\n\n5. Registration Agents shall ensure that comparisons of prices and/or of their services with the\nservices/prices of others are correct and up to date.\n\n6. Registration Agents shall ensure that no trademarks are registered or used by the Registration\nAgent where a risk of confusion with the GLEIF Trademark cannot be excluded.\n\n7. Registration Agents shall ensure compliance with local Trademark regulation, and it shall be\nprohibited to use other LEI Issuer’s logo, name or any other trademarks.\n\n8. Registrations Agents shall maintain a fluent and well-coordinated communication with their\npartnering LEI Issuer.\n\n9. Registration Agents shall clearly state on their website pages that they work as Registration\nAgents and indicate who is their partnering LEI Issuer, by clearly displaying their LElI and the\npatterning LEl Issuer with a hyperlink to the global LEl index record in all of their\n\n@ Registration Agents Governance Framework 1.0 Page 2 of 7\nGLEIF Version 1.0\n","contentLength":3429,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:24:58.514Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/get-an-lei-find-lei-issuing-organizations/registration-agents/2023_03_28_registration-agents-governance-framework_1.0.pdf","content":"communication materials to clients. Both the identity of the Registration Agent and the LEI\nissuer must be clearly communicated via the LEI.\n\n10. LEI Issuers shall conduct a thorough and regular (i.e., at least every 6 months) review of all\ntheir Registration Agents’ websites to ensure no misleading wordings or poor translations are\nprovided to the public.\n\n11. Registration Agents shall not contact legal entities with misleading information. Unclear\ncommunication may lead to false assumptions or may be considered deception.\n\n12. Registration Agents shall follow the steps highlighted in the transfer process and provide the\nrequested documentation without any exceptions, in particular the Transfer Request Form and\nthe Transfer Objection Form. Authorized signatories from the legal entity shall sign relevant\ndocuments via legally compliant formats in the respective jurisdiction. LEl Issuers and\nRegistration Agents shall comply with the signature legal frameworks in the jurisdictions where\nthey operate.\n\n13. LEl Issuers and Registration Agents that are not partnering with the managing LEI Issuer shall\nnot approach and offer LEI services to legal entities which are not under their management\nearlier than 6 weeks prior to their renewal date.\n\n14. Registration Agents shall ensure a transparent payment system that includes a reimbursement\nprocess for legal entities at the very least within the first 60 days of the contract.\n\n15. Registration Agents that offer LEI services to the public and call themselves Registration Agents\nshall be clearly listed on the GLEIF website.\n\n16. Registration Agents shall not overload legal entities with unsolicited offers across multiple\nchannels (emails, phone calls or mails) and must adhere to the marketing regulations of the\nclient’s jurisdiction.\n\n17. Registration Agents shall not incentivize legal entities to avoid reporting Level 2 data. For\ninstance, by offering discounted pricing to legal entities for not declaring parental information.\n\n18. Registration Agents shall not replicate tasks attributed to Validations Agents. Only Validation\nAgents shall be involved in identity verification and validation of data by leveraging their\nbusiness-as-usual client identification procedures in Know Your Customer (KYC), client\nonboarding or standard client refresh update processes.\n\n19. Registration Agents shall ensure that these guidelines are followed by their partners and third\nparty-vendors.\n\n@ Registration Agents Governance Framework 1.0 Page 3 of 7\nGLEIF Version 1.0\n","contentLength":2531,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:24:58.514Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/get-an-lei-find-lei-issuing-organizations/registration-agents/2023_03_28_registration-agents-governance-framework_1.0.pdf","content":"2) GLEIF Complaint Management Process\n\nStep Action\n\n1 LEl Issuer submits complaint.\n\n2 GLEIF Business Relations Manager confirms receipt of complaint. GLEIF analyses the\ncomplaint and additional evidence. In case the complaint is based on valid evidence,\nGLEIF Business Relations Manager contacts the Registration Agent’s partnering LEI\nIssuer to notify them about the complaint.\n\n3 The LEl Issuer analyses the complaint and additional evidence, if not otherwise granted,\nwithin 5 LEIl Issuer business days, the affected LEIl Issuer provides GLEIF with an\nexplanation, and a remediation plan.\n\nGLEIF will then assess the remediation plan provided and will evaluate its effectiveness\nto address the matter. The LEI Issuer may be requested to submit a revised plan, if\nnecessary. Once the remediation has been agreed between GLEIF and the LEI Issuer,\nthis shall be implemented within 1 month (possible extensions will be discussed\nbetween GLEIF and the partnering LEI Issuer as appropriate).\n\nShould a Licensing Agreement be in place with the Registration Agent, such agreement\nwill be terminated by GLEIF and the details of the Registration Agent will be removed\nfrom GLEIF’s website as well.\n\nShould the partnering LEl Issuer and sanctioned Registration Agent intend to sign a new\nLicensing Agreement and republish the Registration Agent’s details to the GLEIF\nwebsite, a new request may only be submitted after the successful implementation of\nthe remediation plan and the completion of a probationary period of 3 months,\nprovided that no further complaints have been received against the Registration Agent.\nIt should be noted that this first complaint sets precedent for further actions by GLEIF\nin case similar issues occur in the future.\n\n4 In case the Registration Agent does not implement the remediation plan within the\nagreed timeframe or in case GLEIF receives another valid complaint against the\nRegistration Agent within the next 3 months after the implementation of the\nremediation plan, GLEIF will request the partnering LEl Issuer to terminate its\nRegistration Agent Agreement with the Registration Agent with immediate effect, and\nthe Registration Agent will no longer be authorized to offer LEl services to Legal Entities\nfor a minimum period of 6 months. The LOU has two weeks to consult GLEIF to prevent\nthe termination.\n\nTo resume operations with the sanctioned Registration Agent under a new agreement\nupon completion of the 6-month sanction period, the partnering LEI Issuer should\nsubmit a revised remediation plan addressing the previous issues and guaranteeing full\ncompliance with Appendix 14 and the Registration Agents Governance Framework.\nRegistration Agents Governance Framework 1.0 Page 4 of 7\nGLEIF Version 1.0\n","contentLength":2744,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:24:58.514Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/get-an-lei-find-lei-issuing-organizations/registration-agents/2023_03_28_registration-agents-governance-framework_1.0.pdf","content":"In such case, GLEIF would review the remediation plan and request any supporting\n\nevidence within 2 months to notify of its final decision. The 6-month sanction period is\n\nequally imposed whether the Registration Agent is partnering with one or multiple LEI\n\nIssuers.\n\nShould the sanctioned Registration Agent be authorized to resume operations, any\n\nfurther breach of compliance will result in a permanent suspension of this Registration\n\nAgent by GLEIF.\n\nRegistration Agents Governance Framework 1.0 Page 5 of 7\nGLEIF Version 1.0\n","contentLength":532,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:24:58.514Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/get-an-lei-find-lei-issuing-organizations/registration-agents/2023_03_28_registration-agents-governance-framework_1.0.pdf","content":"3) Registration Agents Complaint Form\n\nLEIl Record\n\nLEIl Record\n\nName and last name:\n\nEmail:\n\nTelephone:\nNote: By providing these contact details you acknowledge that GLEIF could share this information with\nthe partnering LEl Issuer and the involved Registration Agent.\n\nRegistration Agents Governance Framework 1.0 Page 6 of 7\n\nGLEIF Version 1.0\n","contentLength":347,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:24:58.514Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/get-an-lei-find-lei-issuing-organizations/registration-agents/2023_03_28_registration-agents-governance-framework_1.0.pdf","content":"Actions that triggered the complaint:\ne Please indicate which of the following action(s) best describes the issue with the Registration\nAgent. If necessary, LEI Issuers can choose multiple options:\n1. Registration Agent does not make sufficiently clear on its website and in its\npromotional materials that it is not an LEIl Issuer, but that it performs certain tasks\nfor an LEI Issuer or multiple LEIl Issuers.\n2. Registration Agent provides conflicting information regarding LEI renewal and LElI\ntransfer.\n3. Registration Agent provides incorrect and outdated comparisons of prices and/or of\nits services with the services/ prices of others.\n4. Registration Agent uses trademarks where a risk of confusion with the GLEIF\nTrademark cannot be excluded.\n5. Other:\ne Any other additional comments or details relevant for GLEIF’s consideration.\ne Additional evidence:\nHave you attached any additional evidence such as?\nTransfer request: I:I\nEmail exchanges: |:|\nExtract from website: I:I\nPromotional material: l:l\nOther: |:|\nNote: all evidence shall be translated to English. By providing this evidence you acknowledge that GLEIF\ncould share this information with the partnering LEI Issuer of the involved Registration Agent. The\ncomplainer is expected to fill in all the above fields and to be as precise as possible. The complainer\nshall send the completed complaint form and any additional evidence to their Business Relations\nManager.\nRegistration Agents Governance Framework 1.0 Page 7 of 7\nGLEIF Version 1.0\n","contentLength":1510,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:24:58.514Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2020-06-01-ma-master-agreement-1.3-final.pdf","content":"GGLEIF, Protecing digtal tust\nMaster Agreement\n","contentLength":47,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:26:18.476Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2020-06-01-ma-master-agreement-1.3-final.pdf","content":"Master Agreement\n\nBetween\n\nGlobal Legal Entity Identifier Foundation \"GLEIF\"\n\nSt. Alban-Vorstadt 5, 4052 Basel/Switzerland\n\nand\n\n<*** Name of Local Operating Unit> \"LOU”\n\n<*** Address of Local Operating Unit>\n\neach also \"a Party\", together \"the Parties\"\n\nregarding Legal Entity Identifiers\n\nBasel, Place, Date\n\nBy: Stephan Wolf Sven Schumacher By:\n\nFunction(s): CEO General Counsel Function(s):\n\nmade in two originals, one for each Party\nGLEIS - Global LEI System Master Agreement Page 2 of 39\n\nGLEIF Master Copy Version 1.0\n2020-06-01_MA Master-Agreement-1.3-Final.docx Month 2000\n","contentLength":583,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:26:18.476Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2020-06-01-ma-master-agreement-1.3-final.pdf","content":"Independent Audit An audit report provided to the LOU by its internal or external\n\nReport auditors or comparable functions.\n\nLegal Entity as defined in I1ISO 17442, includes, but is not limited to, unique parties\nthat are legally or financially responsible for the performance of\nfinancial transactions or have the legal right in their jurisdiction to\nenter independently into legal contracts, regardless of whether they\nare incorporated or constituted in some other way (e.g. trust,\npartnership, contractual). It excludes natural persons, if not actingin a\nbusiness capacity, but includes governmental organizations and\nsupranationals\n\nLegal Entity Event an event initiated by a legal entity that affects the securities (equity or\ndebt) issued by that legal entity, and any other event that affects the\nLE-RD such as mergers, spinoffs, change of incorporation, domicile,\netc. Also sometimes referred to as corporate action\n\nLEI, LEls Legal Entity Identifier(s)\n\nLEl Issuance the process beginning with the request of a Legal Entity to assign to it\nan LEl, ending with upload of the LEI to the Global LEI Repository\n\nLEI Maintenance all steps taken to ensure that the LE-RD contains accurate and up-to-\ndate information, and that the LEl is regularly renewed and the LE-RD\nrevalidated\n\nLEI Owner the Legal Entity which has registered its LEl with a local operating unit\n\nLE-RD Legal Entity Reference Data (singular and plural), i.e. the data as\ndefined by the currently valid Common Data File Formats, describing\nbusiness card and relationship information related to corresponding\nROC policies\n\nlocal operating unit the general term for institutions having signed this Agreement, and\nseeking or already having obtained Accreditation. In the Preamble,\nthis is written as LOCAL OPERATING UNIT, to appropriately highlight\ntheir role within the GLEIS.\n\nLOU The contracting party to this Agreement\n\nNew LEI A New LEl is an LEl issued by the LOU which is the first and unique\ninstance of the LEl in the GLEIS, and which at the same time is the first\nand unique LEI associated with the Legal Entity\n\nOperational Date Date agreed between the LOU and GLEIF, following the issuance of\nthe Accreditation Certificate to the LOU, but not later than 2 months\nafter GLEIF issued the accreditation Certificate to the LOU\n\nOperational and the standards necessary for consistent implementation of the GLEIS in\n\nTechnical Standards a federated system or respecting specific schemas or transmission\nprotocols\n\nGLEIS - Global LEI System Master Agreement Page 11 of 39\nGLEIF Master Copy Version 1.0\n2020-06-01_MA Master-Agreement-1.3-Final.docx Month 2000\n","contentLength":2634,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:26:18.476Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2020-06-01-ma-master-agreement-1.3-final.pdf","content":"Personal Data all information relating to an identified or identifiable person, where\n\"person\" includes legal entities (i.e. as defined in the Swiss Data\nProtection Act, Article 3 (a) and (b))\n\npdf, pdf-document a document in the standard portable document format \"pdf\"- format\n\nROC Regulatory Oversight Committee, an organization of regulators from\nmultiple jurisdictions charged by the G-20 with oversight of the GLEIS;\nhttp://www.leiroc.org\n\nROC Charter the document available on\nhttp://www.leiroc.org/publications/gls/roc_20121105.pdf\n\nSLA Service Level Agreement (Appendix 06)\n\nSwiss law a set of rules, orders, regulation and court decisions which constitutes\nthe law in Switzerland. The source of Swiss law can be federal or\ncantonal. GLEIF will host a list of links where Swiss law can be found.\n\nThird Party Services Services provided by external parties, as further set out in Sections 8ss\nof this Agreement and in Appendix 14\n\nuUsD US Dollar\n\nIl Accreditation for the candidate LOU\n\nA. The Accreditation Process\n\n5 The accreditation process is detailed in the Accreditation Manual, Appendix 02.\n\n6 The Parties have negotiated, and agreed on, the Accreditation Plan, Appendix 03.\n\n7 For the avoidance of doubt, GLEIF shall be obliged to grant the Accreditation Certificate to the\nCandidate LOU if and when all components of the Accreditation Plan, and the review of the\nAccreditation Documentation (Appendix 04) have been completed in due time and all criteria\nfor successful Accreditation are met and at least one month after the Operational Date, the LOU\nmust manage several LEls.\n\nB. Use of Third Party Services\n\n8 If the LOU wishes to use Third Party Services, even where such engagement seems compliant\nwith Sections 9 through 11, any such use must comply with the FSB Recommendation No 6. The\nLOU understands and agrees that FSB Recommendation No. 6 is a fundamental pillar of the\nGLEIS, and that GLEIF is obliged and committed to strictly enforce it.\n\n9 The LOU may use Third Party Services running part of or its entire administrative and\noperational infrastructure.\n\nGLEIS - Global LEI System Master Agreement Page 12 of 39\nGLEIF Master Copy Version 1.0\n2020-06-01_MA Master-Agreement-1.3-Final.docx Month 2000\n","contentLength":2231,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:26:18.476Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2020-06-01-ma-master-agreement-1.3-final.pdf","content":"10 The LOU may use Third Party Services to assist the performance of its core duties as set out in\nChapter IV, provided it has a valid agreement with such third party which is compliant with\nAppendix 14 (Third Party Services).\n\n11 However, the LOU may not use Third Party Services to partly or fully perform its core duties as\nset out in Chapter IV (\"Core-Services\"), even if such third party should be another accredited\nlocal operating unit, unless the LOU is and stays in full control of the third party relative to Core-\nServices, as further set out in Appendix 14 (Third Party Services).\n\n12 The LOU may use the services of a qualified third party for assessment of its financial,\noperational and/or information technology practices and for independent audit purposes.\nReports from such third parties will be accepted for consideration by GLEIF as part of the\nAccreditation Plan / Accreditation Documentation processes, provided the report and pertaining\ndocumentation specifically addresses, and meets or exceeds the requirements of the\nAccreditation Checklist.\n\n13 Even when and to the extent which Third Party Services shall be permitted, the LOU remains\nfully and unrestrictedly responsible and liable for complying with, and acting in the spirit of, all\nof the requirements for Accreditation. This is true in particular regarding cost recovery which\nmust be equitable and fair even where Third Party Services are employed and agreed in the\nAccreditation Documentation (Appendix 04), as well as regarding going-concern issues, quality,\nsecurity and compliance as agreed in this Agreement.\n\n14 The Parties agree that the credibility and trust in the GLEIS is deeply anchored to the trust of the\npublic in any local operating unit as the issuer of LEls, and hence any violation of this Sub-\nChapter B shall be deemed to be a violation of an important contractual obligation.\n\nC. No Sublicensing of Accreditation\n\n15 The LOU is prohibited from sublicensing its Accreditation to any third party, even if and to the\nextent it controls such licensee, and even if and to the extent such sublicensee might be another\naccredited local operating unit. Likewise, the LOU is prohibited from otherwise making its\nAccreditation status available for use to any third party.\n\n16 If the LOU wishes to sublicense its Accreditation in part or as a whole, the LOU must undergo\nthe change process described in Sub-Chapter Il1.D.\n\n17 Regarding the use of Third Party Services, the credibility and trust in the GLEIS is deeply\nanchored to the trust of the public in any local operating unit as the true issuer of LEls issued by\nthat local operating unit, and hence any violation of this Sub-Chapter C by the LOU shall be\ndeemed to be a violation of an important contractual obligation.\n\nGLEIS - Global LEI System Master Agreement Page 13 of 39\nGLEIF Master Copy Version 1.0\n2020-06-01_MA Master-Agreement-1.3-Final.docx Month 2000\n","contentLength":2917,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:26:18.476Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2020-06-01-ma-master-agreement-1.3-final.pdf","content":"D. Change Process\n\n18 For the avoidance of doubt, the Accreditation Plan (Appendix 03) and the Accreditation\nDocumentation (Appendix 04) upon which the Accreditation is based, and which lead to the\nAccreditation Certificate, constitute a binding and enforceable agreement regarding any and all\ntechnical details agreed or mentioned therein, such as the validation and verification\nrequirements before issuing a New LEI.\n\n19 Throughout the Accreditation process, the Candidate LOU is obliged to inform GLEIF without\nundue delay about (i) any changed facts which form part of the filled-in Accreditation Checklist\n(part of Appendix 02), and/or of the Accreditation Plan (Appendix 03) and/or of the\nAccreditation Documentation (Appendix 04), in particular about events or developments which\nconcern its legal status such as form of incorporation, change of signatory power of its officers\nand the like, and/or about (ii) other facts or events or developments which actually or\npotentially significantly influence the Accreditation and/or the agreed time schedule.\n\n20 The same obligation to inform holds after successful Accreditation.\n\n20.1 If the Accredited LOU intends to change any part of what has been agreed in the\nAccreditation Plan, and/or submitted in the Accreditation Documentation (Appendix\n04), it must formally and in writing request GLEIF for a change in its Accreditation.\n\n20.2 The LOU must make every effort to notify GLEIF in advance of a change (or else notify\nGLEIF as soon as reasonably possible) and to supply to GLEIF all pertaining\ninformation and documents, and provide reasons for the change.\n\n20.3 GLEIF shall review the submission of the LOU and shall determine in its sole but\nreasonable discretion whether the LOU still meets all requirements for Accreditation.\n\n20.4 GLEIF shall either acknowledge the updates to the Accreditation Documentation\n(Appendix 04), and issue an amended Certification, which shall be duly published as\nrequired in the Accreditation Checklist referenced in the Accreditation Manual\n(Appendix 02), or shall refuse such amendment, giving summary reasons for its\nrefusal. In the event of refusal, the LOU can either accept this decision, or not accept\nand terminate this Agreement, or not accept and take recourse to the remedies\navailable to it under Chapter XVI (Appeals and Complaints), or ultimately request\nmediation and arbitration pursuant to Chapter XVII.\n\n20.5 Changes which consist merely of updates to the Contact Details (Appendix 12) need\nno prior approval of GLEIF. GLEIF shall publish, from time to time, guidance on similar\nadministrative changes or changes which are not relevant for Accreditation, which\nneed no prior notification to GLEIF.\n\n21 For the avoidance of doubt, any change of control at the LOU, be it a change in ownership,\nvoting power, or factual power of a third party over the LOU, is only one example of the\napplicability of the Change Process, and must be notified to GLEIF in advance, or if that is not\npossible as soon as reasonably possible.\n\nGLEIS - Global LEI System Master Agreement Page 14 of 39\nGLEIF Master Copy Version 1.0\n2020-06-01_MA Master-Agreement-1.3-Final.docx Month 2000\n","contentLength":3179,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:26:18.476Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2020-06-01-ma-master-agreement-1.3-final.pdf","content":"IV Core duties of the LOU\n\nA. Basic Guidance\n\n22 The GLEIS is designed to promote the provision of trustworthy LEls and accurate related LE-RD,\nand the LOU is aware and agrees that in alignment with ROC Recommendation No. 18 the\nissuance and maintenance and transfer of LEls and LE-RD, as set out in the Service Level\nAgreement (Appendix 06), is an all important part of the LOU's obligations under this\nAgreement, and that all pertaining parts of the Accreditation Documentation (Appendix 04) are\nof crucial importance, any change of them having to undergo the change process set out in Sub-\nChapter II.D, and their breach being a breach of an important provision of this Agreement.\n\n23 Whenever in doubt as to how a provision in this Agreement should be observed and performed,\nthe core duties, with guidance from the FSB Recommendations such as particularly No. 18, shall\ngovern its interpretation.\n\n24 As stated in FSB Recommendation No. 19, whenever possible the LEI registration and\nmanagement should take place with the LOU or another local operating unit, and GLEIF would\nissue or manage an LEI only if neither the LOU nor any other local operating unit is available to\ndo so. In the event that GLEIF issues or manages an LEl, it undertakes to observe the pertaining\nprovisions of the Service Level Agreement (Appendix 06).\n\nB. Records Management\n\n25 For the purposes of this Sub-Chapter B, records are defined as \"documents, internal procedures\nand practices documentation, and data, regardless of type and regardless of whether such items\nare in written (paper) form, in the form of electronic or optical data, or in any other non-\nhardcopy form, and other supporting evidence to satisfy GLEIF audit requirements\" (each of\nthem a \"LOU-Record\", in their entirety the \"LOU-Records\"), insofar as related to this Agreement\nand to its performance by the LOU, and as set out in Chapter XI. For the avoidance of doubt,\nessential hardcopy documents such as an incorporation certificate qualify as a LOU-Record and\nmust be kept as such.\n\n26 The LOU will make available to GLEIF LOU-Records which encompass for any specific LOU-\nRecord a period of at least 10 years after the most recent update to such LOU-Record, during\nthe entire term of the Agreement and for five years thereafter.\n\n26.1 It is the LOU's responsibility to ensure that LOU-Records can be viewed, printed and\ncopied, and that the required technical equipment is available.\n26.2 If the LOU employs the services of a third party, Sub-Chapter III.B including Appendix\n14 applies, and the LOU must provide evidence that the third party makes the LOU-\nRecords unconditionally (under reserve of Section 26.4) available to the LOU and to\nGLEIF and, in the event, to any third-party auditors appointed by the LOU or by GLEIF.\n26.3 If and to the extent this is technically and reasonably possible, the LOU shall enable\ninspection of the LOU-Records by GLEIF at GLEIF's premises or by remote access.\nGLEIS - Global LEI System Master Agreement Page 15 of 39\nGLEIF Master Copy Version 1.0\n2020-06-01_MA Master-Agreement-1.3-Final.docx Month 2000\n","contentLength":3103,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:26:18.476Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2020-06-01-ma-master-agreement-1.3-final.pdf","content":"26.4 Access to LOU-Records must be possible without undue expenditure of cost, time or\nother resources.\n\n27 The LOU is free in its choice of a data retention system for LOU-Records, provided that (i) the\nsystem is demonstrably reliable and secure, and (ii) the LOU has editorial access to the system,\n(iii) the system maintains and retains an audit trail about any changes including in particular\ncopies, discards, deletions and write-overs of data, and (iv) no information whatsoever\ncontained in or on the original LOU-Record is lost. Original LOU-Records need not be maintained\nor produced for an audit if the LOU's data retention system can prove that the stored data are\nan authentic, true and accurate copy of the original LOU-Records.\n\n28 If the LOU-Records are not retained as a hardcopy, but stored otherwise, particularly\nelectronically or optically, the LOU must (i) use highly reliable media, (ii) always keep a backup\ncopy, and (iii) check all media at least annually for accessibility, integrity and legibility.\n\nV Financials\n\nA. Contribution to GLEIF by the LOU\n\n29 GLEIF is a not-for-profit organization.\n\n30 GLEIF's purpose is to act as the operational arm of the GLEIS, and must therefore support on a\nnot-for-profit basis the implementation of the GLEIS. Under the Governance Principles of the\nGLEIS, GLEIF is requested to operate efficiently and to avoid excessive costs, so that fees to be\npaid by Legal Entities do not act as a barrier to be issued an LEI.\n\n31 GLEIF's activities and operations in its role of implementing the GLEIS and the Governance\nPrinciples of the GLEIS are primarily funded from a per-LEl charge (contribution fee) to be paid\nby the LOU in accordance with this Chapter V and Appendix 07 (Payments).\n\n32 The LOU understands, accepts and acknowledges\n\n32.1 that the contribution fee structure and the contribution fee amounts are determined\nby GLEIF in consultation with the ROC;\n\n32.2 that GLEIF is obliged as part of its yearly operating budget process to ensure the\ncontribution fees for issued and renewed LEls are sufficient to manage GLEIF’s general\nbusiness risk and to ensure sufficient operational reserves;\n\n323 that hence GLEIF annually approves its operating budget cost and the amount that\nGLEIF needs to recover for its annual operating expenditures and to support GLEIS\ngovernance for the relevant financial year;\n\n32.4 that the amount of the per LEI contribution fee is determined annually as part of this\nbudget process by GLEIF, in consultation with the ROC, where however changed fees\nshall not apply retroactively;\n\n32.5 that for these reasons the determination of contribution fee structure and\ncontribution fee schedules is, with regard to the LOU, in the sole but reasonable\n\nGLEIS - Global LEI System Master Agreement Page 16 of 39\nGLEIF Master Copy Version 1.0\n2020-06-01_MA Master-Agreement-1.3-Final.docx Month 2000\n","contentLength":2887,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:26:18.476Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2020-06-01-ma-master-agreement-1.3-final.pdf","content":"discretion of GLEIF, and that the provisions in the subsequent Sub-Chapters B and C\nmay be unilaterally changed by GLEIF.\n\n33 GLEIF shall inform the LOU about changes prior to implementation, and as soon as reasonably\npossible in advance, but no later than by end of November of each year, and in an appropriate\nmanner. No intra-year changes shall be made. GLEIF shall use its reasonable endeavors to give\nthe LOU as much notice as possible of all changes to fee structures and contribution fee\nschedules.\n\n34 The LOU may object to raised fees or unfavorable changes in the contribution fee structure or\ncontribution fee for GLEIF reconsideration by taking recourse to the remedies available to it\nunder Chapter XVI. After GLEIF has reached its final decision on the matter presented, the LOU\nmay accept the changed contribution fee structure or contribution fees, or terminate this\nAgreement, or take recourse to mediation and arbitration as set out in Chapter XVII.\n\nB. Contribution fee to be paid by the LOU per issued LEI\n\n35 The invoicing procedures between GLEIF and the LOU, including detail on the contribution fee\namount, when an invoice is received, the terms of payment, actions on default etc., are\ngoverned by Appendix 07 (Payments).\n\n36 GLEIF reserves the right to change Appendix 07 following the provisions of Section 125 if it\nbecomes impractical or inappropriate or does not reasonably reflect the needs of GLEIF to\nguarantee the functioning of the GLEIS and its Governance Principles.\n\nC. Cost Recovery Requirements for the LOU\n\n37 The LOU must ensure that its operations regarding LEls are sustainably financed in an efficient\nnot-for-profit cost-recovery manner avoiding excessive costs. The LOU takes note, acknowledges\nand accepts that no funds of any form whatsoever shall be contributed by GLEIF.\n\n38 The LOU takes note, acknowledges and accepts that the cost recovery requirements must\ncomply with the Governance Principles of the GLEIS, particularly ensuring that the LEls are freely\nand openly available, and non-proprietary, and are not tied (or \"bundled\") to the provision of\nother services by the LOU, which would force the user to pay directly or indirectly for the LEI, or\nwhich otherwise restrict access to or redistribution of the LEls.\n\n39 While the detailed business plan of the LOU - to the extent related to the rights and duties\nunder the GLEIS as set out in this Agreement - to ascertain sustainable financing shall be part of\nthe Accreditation Documentation (Appendix 04), a cost recovery verification shall occur\nannually during Accreditation Verification per the protocol specified in Appendix 10 (Annual\nAccreditation Verification Requirements).\n\n40 The LOU shall annually review its Direct Costs, its estimate of LEIl issuance and renewals (as\nagreed in Chapter Xl and in Appendix 10), and shall determine its fee schedule for LEl issuance\nand renewal. It shall annually submit to GLEIF its estimated fee schedule for LEl issuance and\nrenewals for the next year (in conjunction with requirements set out in Chapter Xl and in\nAppendix 10).\n\nGLEIS - Global LEI System Master Agreement Page 17 of 39\nGLEIF Master Copy Version 1.0\n2020-06-01_MA Master-Agreement-1.3-Final.docx Month 2000\n","contentLength":3230,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:26:18.476Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2020-06-01-ma-master-agreement-1.3-final.pdf","content":"41 For the avoidance of doubt, the LOU may reduce fees provided it maintains the cost recovery\nrequirements but is not obligated to refund issuance fees collected from the LEl owners as a\nresult of its annual review and determination of its fee schedule for LEl issuance and renewal.\nThis must be agreed in the contract between the LOU and the Legal Entity, as set out in\nAppendix 05 (LOU-contract Requirements).\n\n42 GLEIF reserves the right to audit the LOU's fee schedule based on its cost recovery model in the\ncourse of annual Accreditation Verification (see Appendix 10) and any independent audits\npursuant to Sub-Chapter XI.D. The LOU is obliged to follow the audit recommendations.\n\n43 While the LOU must operate in a financially sustainable way, it must not consider the issuance,\nmaintenance and transfer of LEIs driven by profit considerations. The overall goals, as set out by\nthe Governance Principles of the GLEIS, require that LEls become the main, widespread and\nuniversal means for identifying Legal Entities. This goal would be impaired by unreasonable\npricing relating to the issuance or renewal of an LEI.\n\n44 So as to meet and implement the Governance Principles of the GLEIS, the Parties acknowledge\nthat they have, in particular but explicitly without any limitation, certain ancillary duties.\n\n45 The ancillary duties of GLEIF and the LOU are set out in Appendix 08 (Ancillary Duties). Both\nParties are in agreement that further ancillary duties may become applicable, due to specific\nsituations or circumstances that require the Parties' attention in the context of the Governance\nPrinciples of the GLEIS.\n\n46 GLEIF provides services to the ROC, to the General Public as users of LEIs and LE-RD, and to the\nLOU.\n\n47 The LOU provides services to the Legal Entities, to the General Public as users of LEls and LE-RD,\nand to GLEIF.\n\n48 Services and service levels pursuant to this Agreement are governed by the Service Level\nAgreement, Appendix 06.\n\nGLEIS - Global LEI System Master Agreement Page 18 of 39\n\nGLEIF Master Copy Version 1.0\n\n2020-06-01_MA Master-Agreement-1.3-Final.docx Month 2000\n","contentLength":2117,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:26:18.476Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2020-06-01-ma-master-agreement-1.3-final.pdf","content":"VIll Languages and Documentation Format\n\nA. Language for Communicating\n\n49 The primary language to be used when GLEIF and the LOU communicate by whatever means\n(written, electronic, messaging, phone, conferences) shall be English.\n\n50 Nothing in this Agreement prevents the Parties to use a different language, chosen in mutual\nagreement, for day-to-day or informal communication (such as matters of day-to-day business\nor related inquiries and responses). But, for the avoidance of doubt, formal communication\nmust be in English.\n\nFor the purposes of this Sub-Chapter VIII.A, \"formal communication\" shall mean any\ncommunication which is relevant for the contractual relationship between GLEIF and the LOU,\nsuch as the entire Accreditation Documentation (Appendix 04), GLEIF requests related to annual\nAccreditation Verification and the LOU's responses (Appendix 10), change notifications which go\ninto Appendix 12 (Contact Details), change requests or intentions submitted by either Party\nleading to an amendment of the Accreditation Documentation (Appendix 04) and/or\nAccreditation Certificate, all matters regarding termination (Chapter Xll), the Agreement Change\nProcess (Chapter Xlll), Appeals and Complaints (Chapter XVI) and Mediation and Arbitration\n(Chapter XVII).\n\nB. Language of Documentation\n\n51 All documentation that is to be shared with GLEIF under this Agreement, in particular the\nAccreditation Documentation (Appendix 04), shall be in English language. Where documents are\nnot available in English, they must be accompanied by an English translation. Either Party may\nrequest a certified English translation. Translation and certification costs are borne by the LOU if\nthe documents are provided by the LOU and are borne by GLEIF if the documents are provided\nby GLEIF.\n\n52 Parts of documents, in particular information which cannot be translated to the English\nlanguage, or which can only be represented by a vocal assimilation substitute, shall be clearly\ncharacterized as such, and the graphic representation and/or meaning of any such parts of\ndocuments shall be identified and explained to the best extent reasonably possible.\n\n53 In the event of a contradiction between the foreign-language original and the English translation\nor representation, the foreign-language original shall always prevail if that original is a\ndocument issued by a governmental agency or authority, and the English translation or\nrepresentation shall prevail in all other cases. The Parties will undertake any reasonable effort to\navoid such contradictions. For the avoidance of doubt, it is the full and sole responsibility of the\nparty providing the English translation to provide true, complete and correct English\ntranslations.\n\n@ GLEIS - Global LEI System Master Agreement Page 19 of 39\nGLEIF Master Copy Version 1.0\n2020-06-01_MA Master-Agreement-1.3-Final.docx Month 2000\n","contentLength":2879,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:26:18.476Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2020-06-01-ma-master-agreement-1.3-final.pdf","content":"54 For the avoidance of doubt, the above Sections 51-53 apply only between GLEIF and the LOU.\nThey do not apply to documents exchanged between the LOU and a Legal Entity, as this is up to\nthe LOU to determine.\n\nIX Intellectual Property\n\nA. Intellectual Property Rights in LEls\n\n55 Both Parties take note and agree that the LEI as such, i.e. the code identifying a Legal Entity, is\nnot covered by intellectual property rights under the Revised Berne Convention.\n\n56 To protect the GLEIS against the possibility that, under the copyright legislation or any other\nlegislation applicable (whether now existing or later created), an LEI might enjoy intellectual\nproperty rights of whatever type, extent and legal nature, the LOU\n\n56.1 ascertains, in its contractual agreement with applicants for an LEl (Appendix 05, LOU-\ncontract Requirements), that any such rights are fully and irrevocably transferred (or,\nif not legally possible under applicable legislation, irrevocably licensed) to the LOU;\n\n56.2 herewith fully and irrevocably, and at no cost to GLEIF, transfers those rights (whether\nnow existing or later created) to GLEIF.\n\n57 The Terms of Use of GLEIF for the download and use of LEls are set out in Appendix 09a. They\nare also published on GLEIF's website.\n\n58 The LOU is obliged to use and publish materially identical Terms of Use for its operations, and to\nmake them available on its website, as set out in Appendix 09b. The LOU may add or amend\nprovisions to its Terms of Use, provided that no such added or amended provision may\ncontradict the provisions set out in Appendix 9b, and further provided any such added or\namended provision is covered by the Accreditation Documentation.\n\nB. Intellectual Property Rights in LE-RD\n\n59 Given that the LE-RD (as defined and agreed in this Agreement) are comprised of only publicly\navailable data, both Parties take note and agree that the LE-RD are not covered by copyrights\nunder the Revised Berne Convention, and neither by any other intellectual property rights.\nHowever, and for the avoidance of doubt, the Parties agree that the Legal Entity will have, as a\nrule, certain protective rights in its legal name which is included, for inevitable reference\npurposes, in the LE-RD as defined by the Common Data File Format.\n\n60 To protect the GLEIS against the possibility that, under the copyright legislation or any other\nlegislation applicable (whether now existing or later created), any part of the LERD might enjoy\ncopyrights, or any other intellectual property or protective rights of whatever type, extent and\nlegal nature, the LOU\n\nGLEIS - Global LEI System Master Agreement Page 20 of 39\nGLEIF Master Copy Version 1.0\n2020-06-01_MA Master-Agreement-1.3-Final.docx Month 2000\n","contentLength":2740,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:26:18.476Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2020-06-01-ma-master-agreement-1.3-final.pdf","content":"Index\nI Purpose and scope 000000000 RRRNRNRRRRRERRRRRRRRRRRNRRRNRRRRRERRORRRRRNNR0RRRRRRRRRRRRRRRRRRRRRRRRTRTS 8\nII Definitions 0000000 RN RRNRRRRRRRRRRRNNRRRRRRRRRRRRRRRRRRRRIRRRRRRRRRRRRRRRRRRENRRRRRRRRRRRRRRORRRRRRRRRRCRRTRTS 8\n. Accreditation for the candidate LOU .........cccovueeiiiireeniinniencsinnneeneniennen 12\nA. The Accreditation ProCESS......ccvvuviiiiiiiiiiiieee e ettt ee s cssiiieeee s siinee e e s s svaaeeessnnssneees 12\nB. Use Of Third Party SErVICES.......couvuiiiiiiiiiiiieeie s eiiiieeee s ssirie e e e s sveieee s ssssvnveeessssnns 12\nC. No Sublicensing of Accreditation ........cccceeeeiiiiiiie i eseeee s sieeeees 13\nD. Change PrOCESS ...ccccuveeieiiiiiiiiieeesestiieeeessssiiieee s sssiiiraeeessssnssaeeessnsssseeessssssnnsnesesssnns 1\nIV core duties Of the LOU ..........................................................................15\nA, BaSiC GUIANCE ...uuiiieiiiciiiecee ettt sttt srae e s s siiie e e e s s s saabaae e e s s sseaaeeessnnssseees LD\nB. Records ManagemeNnt .......cccvuvivuuiieeiiiiiiieeeesiiiieee s sssiiieeee s s s sieeaeeesssssaaeeeesnsnsseees 1D\nV Financials ..............................................................................................16\nA. Contribution to GLEIF by the LOU .......c.uovviiiiiiiiiiiecciiiccce i sveie e esienens 16\nB. Contribution fee to be paid by the LOU perissued LEl............ccceeeeeennnrnvnnennennnn. 17\nC. Cost Recovery Requirements for the LOU ........ccoevvvvieieiiiiiieeecinnniieieeenssiineennns 17\nVI ANCILLARY DUTIES ................................................................................18\nVII SERVICES...............................................................................................18\nVIII Languages and Documentation Format.........ccccieeiiieiieiiieiinnncceeinennne. 19\nA. Language for CommuNiCating ......ceeeeviiiiiiieeeeiiiiieeee e essiieeeeesssiieeeeessssseeseeeesnsssnnees 19\nB. Language of DOcUmMENtation.......ccceeeviiiiieie i crsieeee s sieee e eveeeeeeessnneees 19\nIX Intellectual Property .............................................................................20\nA. Intellectual Property Rights in LEIS........ccccceeviiiiieeeeiinniiiiieeessiieeee s essiiieeesesssennnns 20\nB. Intellectual Property RightsSin LE-RD .......ccccceviivniirieeeiiiiiiiieee e cniiieeee s ssienneeenennn 20\nC. Purpose regarding transfer or iCENSE......coovuvviiiiiiiiviiieie i siineenens 21\nD. GLEIF Trademark and LOBO .....ccovvuirieieriiiiieeeeeeiiiieeee s ssiirieeesssnvneeessnsvnnesessnsenns 21\nE. Further Trademarks and the \"Accredited by GLEIF\" LOGO.........cccvvvveeerinrreeeeeinnnnn 22\nF. Trademarks registered by the LOU ........ccccvvieviiiiiiieiie i siieeee e ennne 23\nX Liability .................................................................................................24\nA. Liability in GENEral ..cccocociiiiie e ssnnaeee s s ennens 2\nB. Liability for Damage caused by Willful Intent or Gross Negligence. ..................... 24\nC. Liability for Damage caused by Simple Negligence..........ccooceeeviviviivieeenniiiinennn. 25\nD. Obligation of the Parties to Keep each other Free from Harm ................ccceeveeeee. 25\nXI Verification and Audits..........................................................................26\nGLEIS - Global LEI System Master Agreement Page 3 of 39\nGLEIF Master Copy Version 1.0\n2020-06-01_MA Master-Agreement-1.3-Final.docx Month 2000\n","contentLength":3423,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:26:18.476Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2020-06-01-ma-master-agreement-1.3-final.pdf","content":"60.1 ascertains, in its contractual agreement with applicants for an LEI (Appendix 05, LOU-\ncontract Requirements), that any and all rights are fully and irrevocably transferred\n(or, if not legally possible under applicable legislation, irrevocably licensed) to the\nLOU, with the sole exception of the protective rights of the Legal Entity in its legal\nname;\n\n60.2 herewith fully and irrevocably, and at no cost to GLEIF, transfers those rights (whether\nnow existing or later created) to GLEIF.\n\nC. Purpose regarding transfer or license\n\n61 Itis understood and agreed that the purpose of the transfer, or license, of rights pursuant to\nSections 55 through 60 is only to eliminate any obstacle to the publication of LEls and LE-RD in\nthe GLEIS and/or to their use by anybody, including to eliminate (by way of example, but for the\navoidance of doubt without any limitation whatsoever) any obstacles to the free transfer of data\nfrom the LOU to the Global LEI Repository, to the publishing, and to the download and use of\nLEls and LE-RD and/or the Golden Copy by anybody for whatever purpose, whether commercial\nor not and whether alone or in combination with other data.\n\n62 This applies particularly in the event that data protection or other privacy rights might be\nclaimed, or any similar protection right (whether now existing or later created).\n\n63 The LOU is responsible and liable for any failure of obtaining where necessary and transferring\nto GLEIF any and all rights which confirm beyond any reasonable doubt that the LEl and LE-RD\nand the Golden Copy may be used as set out in Section 61 and in Appendix 09a (Terms of Use).\n\n64 GLEIF shall not make any inappropriate use of the rights transferred to it. The sole reason and\npurpose for the transfer to GLEIF is to ensure that LEIs and LE-RD may be freely and\nunrestrictedly transferred to the Global LEI Repository, made available for use by anybody, such\nas download from that source and use as described in Section 61 and in Appendix 09a (Terms of\nUse).\n\n65 The Parties explicitly agree that the provisions of this Chapter IX are critical and fundamental for\nthe proper functioning of the GLEIS. Any violation of the obligations designed to ensure the free\navailability of LEls and LE-RD is deemed to be a violation of an important provision of this\nAgreement.\n\nD. GLEIF Trademark and Logo\n\n66 The LOU acknowledges GLEIF's ownership of the GLEIF Trademark and Logo. GLEIF grants to the\nLOU, but only after Accreditation and only for the term of this Agreement, a non-exclusive, non-\ntransferable, non-sublicenceable, non-seizable royalty-free license as follows:\n\n66.1 The LOU may and must display the GLEIF Trademark and Logo on its website in an\nappropriate location, for no other purpose than indicating that the LOU is an\naccredited LOU within the GLEIS.\n\nGLEIS - Global LEI System Master Agreement Page 21 of 39\nGLEIF Master Copy Version 1.0\n2020-06-01_MA Master-Agreement-1.3-Final.docx Month 2000\n","contentLength":2967,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:26:18.477Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2020-06-01-ma-master-agreement-1.3-final.pdf","content":"66.2 In addition, the LOU may use the GLEIF Trademark and Logo only on condition that (i)\nit is used to denote its GLEIS-related services regarding LEIs and LE-RD as agreed in\nthis Agreement, and (ii) it is used exactly as registered, under explicit reserve of\nfurther directions of GLEIF at GLEIF's sole but reasonable discretion.\n\n66.3 The LOU is aware that as stated in Appendix 14 (Requirements for Third Party\nServices) or agreed on a case by case basis in the Accreditation Documentation, third\nparty service providers may be granted a licence, provided they comply with terms\nand conditions set by GLEIF in each individual case.\n\n66.4 GLEIF explicitly reserves the right to withdraw this licence at any time, and/or to\nimpose further other licence terms.\n\n66.5 The LOU takes note and agrees that strict observance of the quality requirements\nagreed in this Agreement are a pre-condition of above licenced use of the GLEIF\nTrademark and Logo.\n\n67 Any other use of the GLEIF Trademark and/or Logo is strictly prohibited. Even if the GLEIF\nTrademark and/or Logo is not (or not yet) protected in the LOU's country of organization,\ndomicile and/or operation, use of the GLEIF Trademark and/or Logo violating Section 66 shall be\nconsidered to constitute unfair competition, and shall be deemed to be a violation of an\nimportant provision of this Agreement.\n\n68 The LOU shall not undertake any activities that will disparage, bring into disrepute or damage\nthe goodwill and public image associate with the GLEIF Trademark and/or Logo, or will harm the\nreputation of GLEIF.\n\n69 The LOU may not apply for, register, purchase or use any trademarks or other signs identical or\nactually or potentially similar to the GLEIF Trademark and/or Logo nor any other trademark\nwhich might confuse the General Public about the status of the LOU or GLEIF within the GLEIS.\nIn the event of any such trademark being applied by, or registered for, the LOU, GLEIF may\nrequest assignment to it without any remuneration except reimbursement of public fees.\n\n70 The LOU agrees to promptly inform GLEIF about any use of the GLEIF Trademark and/or Logo by\nthird parties of which it becomes aware, and shall reasonably support GLEIF in enforcing GLEIF's\nrights against such use.\n\n71 Both Parties seek, on a best effort basis, to establish \"GLEIF\", \"GLEIS\" and the GLEIF Trademark\nand Logo as a worldwide brand, so as to widen public recognition of the LEI.\n\nE. Further Trademarks and the \"Accredited by GLEIF\" Logo\n\n72 The above provisions of Sub-Chapter IX.D will also hold regarding any further trademarks or\nlogos established by GLEIF which express the LOU holding Accreditation and being a part of the\nGLEIS.\n\n73 The above provisions of Sub-Chapter IX.D govern as well the use of GLEIF's \"Accredited by\nGLEIF\" logo.\n\nGLEIS - Global LEI System Master Agreement Page 22 of 39\nGLEIF Master Copy Version 1.0\n2020-06-01_MA Master-Agreement-1.3-Final.docx Month 2000\n","contentLength":2940,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:26:18.477Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2020-06-01-ma-master-agreement-1.3-final.pdf","content":"73.1 While the \"Accredited by GLEIF\" logo cannot be reasonably trademarked, any use\nagainst the substance of the provisions of Sub-Chapter IX.D would constitute a severe\nbreach of, inter alia, unfair competition law and similar legislation. In addition, the\nfollowing is agreed:\n\n73.2 The \"Accredited by GLEIF\" Logo must be displayed on the accredited LOU's website.\n\n73.3 The LOU is explicitly prohibited to permit any Third Party Service Providers of\nwhatever kind to use or display in whatever way the \"Accredited by GLEIF\" Logo.\n\nF. Trademarks registered by the LOU\n\n74 For the avoidance of doubt, the LOU may use the GLEIF Trademark and Logo as agreed in above\nSection 66.\n\n75 The LOU shall stop using its labeling for entity identifiers the LOU developed before this Master\nAgreement was signed by both parties. The LOU may apply for, register, purchase or use a\ntrademark containing the element \"LEI\", provided (i) such trademark is not confusingly similar to\nthe GLEIF Trademark and/or Logo, and (ii) contains as its main text component the LOU's nhame\nand/or acronym, and (iii) abstains from incorporating the GLEIF Logo. There shall be no\nexceptions to this rule and any violation shall be deemed to be a violation of an important\nprovision of this Agreement.\n\n76 In the event of any such trademark being confusingly similar to the GLEIF Trademark and/or\nLogo, regardless of whether simply used or applied for by registration or registered, GLEIF may\nrequest cessation of use and, in the event of a pending or successful registration in a trademark\nregister, request assignment to it without any remuneration except reimbursement of public\nfees.\n\n77 The LOU may apply for the registration of its own trademarks provided such trademarks respect\nSub-Chapters IX.D and IX.E. If in doubt about confusing similarity to the GLEIF Trademark and/or\nLogo, the LOU shall inform GLEIF before applying for, or registering, or purchasing, or using such\na trademark. For the avoidance of doubt, GLEIF reserves in either case to object and use any\nlegal remedies available to it.\n\n78 No co-branding of an LOU-owned trademark and the GLEIF Trademark and/or Logo shall be\npermitted without prior written approval of GLEIF in GLEIF's sole but reasonable discretion,\nexcept that the use of the GLEIF Trademark and/or Logo shall be permitted as specified in\nSection 66 and required as specified in Section 66.1.\n\nGLEIS - Global LEI System Master Agreement Page 23 of 39\nGLEIF Master Copy Version 1.0\n2020-06-01_MA Master-Agreement-1.3-Final.docx Month 2000\n","contentLength":2548,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:26:18.477Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2020-06-01-ma-master-agreement-1.3-final.pdf","content":"X Liability\n\nA. Liability in General\n\n79 Both Parties agree that in the interest of complying with the Governance Principles of the GLEIS\nthey have a duty of care in all aspects of performing this Agreement, and to operate in good\nfaith\n\n80 The LOU agrees that it has an essential and all-important duty of care regarding the services and\nservice levels set out in the Service Level Agreement, Appendix 06.\n\n81 Either Party is liable for acts and omissions of any auxiliary person such as (without any\nlimitation) employees and third party service providers like those acts or omissions were its\nown.\n\n82 Liability for trivial damages is waived by both Parties. The claiming party must demonstrate the\nexistence of a non-trivial damage.\n\n83 For the avoidance of doubt, liability as set out in this Chapter only governs the relationship\nbetween GLEIF and the LOU.\n\n84 Payment of damage claims, be they liquidated damages or not, does not relieve (i) the damaging\nParty of redressing the situation to comply with the Agreement, nor (ii) of further compliance\nwith the Agreement. A waiver or voluntary reduction of damage claim by the damaged Party, in\nthe event, and for whatever reason, does never constitute a waiver of compliance with the\nbreached provision.\n\n85 For the avoidance of doubt, the general principles of Swiss law regarding tort and contractual\nliability for damages do apply. In particular, the damaged Party is obliged to take any reasonable\nmitigation measures, and the burden of proof lies (under reserve of Section 87 ss) with the Party\nclaiming a damage.\n\nB. Liability for Damage caused by Willful Intent or Gross Negligence\n\n86 The Parties are aware that under mandatory Swiss law, damage caused by willful intent or gross\nnegligence can be neither waived nor capped.\n\n87 The Parties acknowledge and agree that it may be difficult for the damaged Party to quantify the\ndamage amount. Therefore, the Parties agree on an amount in USD as liquidated damages\nwhich is calculated according to Section 88. Notwithstanding this,\n\n87.1 the damaged Party is free to claim higher damages, but shall bear the burden of proof\nand associated costs in pursuing the entire claimed sum, and\n87.2 the violating Party is free to prove that actual damage was lower than the amount of\nliguidated damages, and\n87.3 both Parties are aware and acknowledge that pursuant to Swiss substantive law,\nliquidated damages which are excessively high compared with the actual damages\nshall be reduced by a deemed-competent judge (see Chapter XVIl on Mediation and\nGLEIS - Global LEI System Master Agreement Page 24 of 39\nGLEIF Master Copy Version 1.0\n2020-06-01_MA Master-Agreement-1.3-Final.docx Month 2000\n","contentLength":2697,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:26:18.477Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2020-06-01-ma-master-agreement-1.3-final.pdf","content":"Arbitration) at the judge's fair and just discretion, in particular upon evidence\nsubmitted by the liable Party showing that the actual damage is considerably lower\ncompared to the liquidated damages amount, or that even no or only trivial damage\nhas been caused, as set out in Article 163 para. 3 of the Swiss Code of Obligations.\n88 Liquidated damages are calculated as follows:\n88.1 If the Party in breach is the LOU: USD 1.00 (one USD) multiplied by the number of\nactive LEls as publicly reported in the latest annual report.\n88.2 If the Party in breach is GLEIF: 10% (ten percent) of the GLEIF's retained surplus\nmultiplied by the LOU-FACTOR; the LOU-FACTOR is \"the number of the damaged\nLOU's active LEls as publicly reported in the latest annual report, divided by the total\nactive LEls in the Golden Copy\".\nC. Liability for Damage caused by Simple Negligence\n89 For breaches of the Service Level Agreement (\"SLA\", Appendix 06) caused by simple negligence\nthe following governs:\nl. non-performance or bad performance of Service Obligations set out in Chapters 2\nand 3 of the SLA, and\nIl. underperformance of Service Levels set out in Chapter 4 of the SLA, and\nM. non-performance or bad performance of Service Reports set out in in Chapter 5 of\nthe SLA\ndo not cause liability claims, but are exclusively subject to the escalation management set out\nin Chapter 4 of the SLA.\n90 For all other violations of the Master Agreement caused by simple negligence, the Parties agree\non liquidated damages as set out in above Section 87 including Sub-Sections 87.1 through 87.3\nand calculated pursuant to Section 88.\nHowever, damage claims shall be capped as follows:\n90.1 90.1 If the Party in breach is the LOU: 150% (one hundred and fifty percent) of the\namount calculated pursuant to Section 88.1.\n90.2 90.2 If the Party in breach is GLEIF: 150% (one hundred and fifty percent) of the\namount calculated pursuant to Section 88.2.\nD. Obligation of the Parties to Keep each other Free from Harm\n91 Either Party shall keep the other free from harm and from any third party claims which result\nfrom any and all of its acts or omissions which are improper, unlawful, or a breach of this\nAgreement.\n92 Inthe event of a third party raising a claim against one of the Parties (for the purpose of this\nSub-Chapter \"the Prosecuted Party\") which may be attributable to the other Party (for the\nGLEIS - Global LEI System Master Agreement Page 25 of 39\nGLEIF Master Copy Version 1.0\n2020-06-01_MA Master-Agreement-1.3-Final.docx Month 2000\n","contentLength":2524,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:26:18.477Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2020-06-01-ma-master-agreement-1.3-final.pdf","content":"purpose of this Sub-Chapter \"the Liable Party\"), the Prosecuted Party shall immediately inform\nthe Liable Party in writing and provide all facts and documents to enable the Liable Party to\nassess the claim.\n\n93 The Prosecuted Party shall not acknowledge any allegations and shall not negotiate with the\nthird party on its own, but shall, in its sole but reasonable discretion, either leave the matter to\nthe Liable Party or deal with the matter on the Liable Party's instructions.\n\n94 Inthe event of litigation (civil, criminal or administrative) or government investigation, the\nParties shall cooperate, within the boundaries set by the applicable procedural rules of such\nlitigation or investigation, where guidelines shall be that due to the Liable Party's liability, the\nLiable Party should have the best possible influence on written submissions, hearings, evidence,\nsettlement talks, and negotiations.\n\nXl Verification and Audits\n\nA. Verification of LOU Internal Controls\n\n95 In order to maintain the LOU’s Accreditation, it is required to complete Accreditation\nVerification. The Accreditation Verification change policies, requirements and processes are\ngoverned by Appendix 10 (Annual Accreditation Verification Requirements).\n\n96 GLEIF may request extraordinary Accreditation Verification where exceptional circumstances\ngive GLEIF reason to believe that the Accreditation Documentation is no longer current or\nadhered to.\n\nB. Annual Verification of Cost Recovery and Setting of Future Fees\n\n97 Annually, the LOU must provide a written description of its current cost recovery methodology\nand a detailed quantitative analysis supporting its compliance results for the reporting year. The\nrequirements and expectations of such quantitative analysis are detailed in Appendix 10\n(Annual Accreditation Verification Requirements).\n\n98 In addition, the LOU must annually validate its cost recovery calculation reconciled to the\nexpected fee schedule. The requirements and expectations of such cost recovery calculation are\ndetailed in Appendix 10 (Annual Accreditation Verification Requirements).\n\nC. Oversight of Audit Activity at the LOU\n\n99 In order to execute its oversight responsibilities, GLEIF requires that any Independent Audit\nReports from any source received by the LOU that relate to LEI processing be provided to GLEIF\nfor information purposes at the latest within 30 Days after receipt thereof. Any exceptions of\nthis provision must explicitly be agreed in the Accreditation Documentation.\n\n100 GLEIF is entitled to have any Independent Audit Report submitted by the LOU as noted in above\nSub-Chapter A, reviewed by GLEIF’'s Compliance and Audit function and/or by a reputable\n\nGLEIS - Global LEI System Master Agreement Page 26 of 39\nGLEIF Master Copy Version 1.0\n2020-06-01_MA Master-Agreement-1.3-Final.docx Month 2000\n","contentLength":2841,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:26:18.477Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2020-06-01-ma-master-agreement-1.3-final.pdf","content":"auditing firm of its choice, and to request additional information or analysis from the LOU. The\ncost of provision of additional information or analysis shall be borne by the GLEIF.\n\n101 If such review or additional investigations result in GLEIF requiring remedial action(s) to be\nundertaken by the LOU to meet the relevant GLEIF Operational and Technical Standards, the\nLOU shall do so promptly and shall inform GLEIF about the progress and finalization of such\nmeasures.\n\nD. Independent Audits at LOU locations\n\n102 GLEIF may conduct financial, operational and/or information technology audits relating to LEI\noperations at LOU locations at GLEIF's sole but reasonable discretion. To provide for a\nreasonable scheduling opportunity, GLEIF will make every effort to provide at least four weeks\nnotice to the LOU. Should the LOU not be in a position or not willing to undergo an audit as\nrequested by GLEIF, GLEIF is explicitly entitled to have an audit performed by a qualified firm of\nits choice. Any violation of this ability shall be deemed to be a violation of an important\ncontractual obligation. The following provisions shall govern on-site audits:\n\n102.1 An audit shall take place during the LOU's normal business hours, and, to the extent\npracticable, shall be conducted with minimal disruption to the LOU's business.\n\n102.2 An audit shall not give rights to access any information other than that directly\nrelating to the provision of the services and service levels as set out in the Service\nLevel Agreement (Appendix 06) and/or to other contractual obligations of the LOU\nunder this Agreement, and the right of GLEIF to review the LOU shall be limited to the\nspecific access reasonably needed to perform the audit, and shall not include the right\nto install, add or execute software, or install, add or attach hardware, on the LOU's\nsystems.\n\n102.3 At all times while on site at the LOU's premises GLEIF's personnel (or GLEIF's\ndelegates, as the case may be) shall comply with the LOU's standard written security\npolicies and procedures applicable to its general visiting user population to the extent\nthat such policy has been notified in writing by the LOU to GLEIF or has been clearly\nverbally brought to the attention of GLEIF's personnel (or GLEIF's delegates) visiting\nthe LOU's premises at that time.\n\n102.4 The LOU reserves the right to deny GLEIF's personnel (or GLEIF's delegates) access to\nany part of the LOU's premises where such access may reasonably pose a risk to\ncompromise the proprietary nature of the LOU's systems or the confidentiality of it,\nor it customers' data or their confidentiality.\n\n103 The scope and timing of all such audits will be discussed in advance, observing above provisions,\nexcept in case of suspected fraudulent behavior.\n104 The costs of all such audits, excluding LOU preparation and participation in the audit, shall be\nborne by GLEIF.\n105 The resultant audit report shall be addressed to GLEIF and report distribution will be determined\nby GLEIF on a ‘need to know’ basis consistent with GLEIF’s transparency principles.\nGLEIS - Global LEI System Master Agreement Page 27 of 39\nGLEIF Master Copy Version 1.0\n2020-06-01_MA Master-Agreement-1.3-Final.docx Month 2000\n","contentLength":3228,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:26:18.477Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2020-06-01-ma-master-agreement-1.3-final.pdf","content":"Xl Term and Termination\n\nA. Accreditation Phase\n\n106 The Parties agree that in the event of the LOU not having satisfied the requirements for\nAccreditation within the time period agreed in the Accreditation Plan, although the Parties have\ntried in good faith and observing the principles set out in Chapter XVI (Appeals and Complaints),\nand particularly Sub-Chapters A and B, then upon GLEIF's sole but reasonable discretion:\n\n106.1 GLEIF may terminate with immediate effect this Agreement, or\n\n106.2 GLEIF may extend the deadline for obtaining Accreditation by no more than 3 months,\nparticularly if it seems reasonable that within such extended deadline the LOU shall\nsatisfy the requirements, or\n\n106.3 GLEIF may grant a provisional Accreditation for specific functions for a specified time\nperiod.\n\n107 In the event of GLEIF granting an extension of the deadline or of a provisional Accreditation,\nGLEIF shall notify the LOU about the outstanding requirements that must be satisfied within the\nspecified period of time. If the LOU does not satisfy those requirements, GLEIF shall be entitled\nto terminate this Agreement with immediate effect.\n\nOnly in rare situations, and entirely in GLEIF's sole but reasonable discretion, shall GLEIF once\nagain extend the deadline or the duration of a provisional Accreditation.\n\n108 For the avoidance of doubt, the LOU is not authorized to issue LEls while still being a Candidate\nLOU, i.e. before having obtained Accreditation.\n\nIn the event of a provisional Accreditation, GLEIF may authorize the Candidate LOU to issue LEls,\npotentially with some limitations, at GLEIF's sole but reasonable discretion.\n\nB. Initial Agreement Term\n\n109 Upon receipt of the Accreditation Certificate, this Agreement is entered into for an initial term\nuntil the end of a 36 months period after the Accreditation Certificate Date (the \"Initial Term\").\n\n110 110. After the Initial Term, this Agreement is automatically renewed by additional 36 months\nunless the Agreement is terminated by a Party by giving one year prior written termination\nnotice.\n\nC. Termination for Cause\n\n111 If either Party believes that the other Party is not fully compliant with important terms of this\nAgreement, such as in particular (but for the avoidance of doubt without limitation) Sections 14,\n17, 22, all provisions regarding the GLEIF Trademarks and Logos and 102, or that the other Party\ncontinually violates a specific obligation, the following rules shall apply:\n\nGLEIS - Global LEI System Master Agreement Page 28 of 39\nGLEIF Master Copy Version 1.0\n2020-06-01_MA Master-Agreement-1.3-Final.docx Month 2000\n","contentLength":2623,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:26:18.477Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2020-06-01-ma-master-agreement-1.3-final.pdf","content":"111.1 The aggrieved Party shall inform the other in writing, giving the full facts and exact\nreferences to the provisions of this Agreement which it believes have been violated,\nproviding reasons for its position, and shall give the other Party the opportunity to\npresent its reply within a reasonable term which shall in no event be longer than\nthirty Days from said notification.\n\n111.2 The accused party shall submit its reply, also giving the full facts and exact references\nto the provisions of this Agreement, either concurring with the aggrieved Party's\nviews, or providing reasons for its dissenting position.\n\n111.3 To the extent that the accused Party agrees with the aggrieved Party’s allegations, it\nshall set out in its response the steps it will take to rectify the issue, indicating a\nreasonable time frame for cure.\n\n111.4 To the extent that the accused Party does not agree with the allegations, the\naggrieved Party shall inform the accused Party about the continued areas of\ndisagreement providing the accused Party a further opportunity to remediate, which\nshall not exceed 15 Days from the communication above.\n\n111.5 If the accused Party does not cure the issues noted within the stated period(s), the\naggrieved Party may terminate this Agreement with immediate effect; it must do so in\nwriting and by registered letter / receipt confirmation requested.\n\n112 In the event of a violation of an important provision of this Agreement, whereupon the\naggrieved party cannot proceed without relief, and which in good faith prevents the aggrieved\nParty to continue in this Agreement, the following rules apply:\n\n112.1 The aggrieved Party may inform the accused Party of its allegations relating to\ncompliance with this Agreement as set out in Section 111.1, demanding a cure within\nfive Days.\n\n112.2 If the accused Party does not cure within that cure term, the aggrieved Party may\nterminate this Agreement with immediate effect; it must do so in writing and by\nregistered letter / receipt confirmation requested. If the aggrieved Party does not\nterminate the Agreement immediately after the five Days, it may still proceed as set\nout under Section 111.\n\n113 For the avoidance of doubt, any termination is subject to mediation and arbitration as set out in\nChapter XVII, and the Parties are particularly aware of the remedies available to them set out in\nChapter XVI (Appeals and Complaints), particularly observing the culture of communication.\n\n114 GLEIF reserves the right to proceed to less drastic measures if GLEIF believes, in its sole but\nreasonable discretion, that a termination is not (or not yet) necessary to preserve the GLEIF's\nrights and the principles of GLEIS. For the sole purpose of examples, GLEIF may determine that\nthe LOU can issue New LEls only under certain conditions (not unlike a provisional\nAccreditation), or that agreements with third parties must be suspended or amended, or that\ncertain protective measures for the GLEIF must be implemented.\n\nGLEIS - Global LEI System Master Agreement Page 29 of 39\nGLEIF Master Copy Version 1.0\n2020-06-01_MA Master-Agreement-1.3-Final.docx Month 2000\n","contentLength":3137,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:26:18.477Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2020-06-01-ma-master-agreement-1.3-final.pdf","content":"D. Termination for Loss of Authority of GLEIF\n\n115 The LOU takes note and accepts that the ROC reserves a right to terminate the designation of\nGLEIF as the central operating unit of the GLEIS at its sole discretion.\n\n116 The LOU takes note and accepts that in such event GLEIF shall have a right to terminate this\nAgreement at any time with effect one year after the ROC decision to terminate GLEIF's role. For\nthe avoidance of doubt, the LOU remains responsible for the performance of this Agreement\nuntil the effective termination date.\n\nE. Consequences of Termination\n\n117 The covenants and terms contained in this Agreement that contemplate their performance after\nthe expiration or termination of this Agreement shall be enforceable notwithstanding the\nexpiration or termination of this Agreement.\n\n118 Upon expiration of this Agreement, the LOU is no longer an accredited LOU, which means in\nparticular (but specifically without any limitation) that it is no longer a part of the GLEIS, and\nmay no longer use the GLEIF Trademark and Logo, and must transfer all LEls and LE-RD managed\nby it as instructed by GLEIF. For the avoidance of doubt, GLEIF will - where reasonably possible\nin mutual agreement with the LOU - set out appropriate steps and measures for the interim\nphase which may follow after the date of termination, in the interest of the GLEIS and in\naccordance with the Governance Principles of the GLEIS.\n\n119 The Parties are aware and acknowledge that an expiration or termination that is later held\ninvalid or unenforceable by a binding and final award of the arbitration court (see Chapter XVII)\nshall mean that this Agreement continued to be valid, effective and enforceable, and that this\nmay result in undesirable situations and/or entail claims such as damage claims.\n\n120 In order to avoid such situation,\n\n120.1 the terminating Party may request the other Party to commence mediation\nproceedings within two months after receipt of the termination letter, where failure\nto do so shall mean that the termination is valid; and/or\n\n120.2 the terminating Party may request the other Party to commence arbitration\nproceedings within two months after the mediation has ended, where failure to do so\nshall mean that the termination is valid; and/or\n\n120.3 the Parties may agree in writing, after one Party has issued a disputed termination\nletter, that they shall continue to follow this Agreement fully or in certain areas until\neither the termination is agreed by the Parties to be valid or invalid, or a final award is\nhanded down;\n\n120.4 where it is agreed and understood that by agreeing on terms under above Section\n120.3 there is no prejudice regarding the validity or invalidity of the termination\nletter.\n\nGLEIS - Global LEI System Master Agreement Page 30 of 39\nGLEIF Master Copy Version 1.0\n2020-06-01_MA Master-Agreement-1.3-Final.docx Month 2000\n","contentLength":2880,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:26:18.477Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2020-06-01-ma-master-agreement-1.3-final.pdf","content":"A. Verification of LOU Internal Controls.......ccccoeevvieieeiiiiiieeeesinniiiiecenssiiieee s esnineens 26\n\nB. Annual Verification of Cost Recovery and Setting of Future Fees........................ 26\n\nC. Oversight of Audit Activity at the LOU .......ccvviieiiiiiiiiiie e cssiiieee 26\n\nD. Independent Audits at LOU [0CatioNs .......cuveeeiiiiiiieeeeiiiniiiiieeeseiiieeeesssiieeee s annnnn 27\n\nXl Term and Termination ......ccccecieiiieeiiinniiinniinieeiinmnieree s 28\nA, ACCreditation Phase ....ccccuviiii ittt ee e snaneees 28\n\nB. Initial ABreement TEIM ..ot s e e naees 28\n\nC. Termination fOr CaUSE.....cii ittt irrae e e siraaeeeees 28\n\nD. Termination for Loss of Authority of GLEIF..........cccccevviiiiiieeee e eeriiieeeeeenn 30\n\nE. Consequences of Termination ........ccccccvvviiieeiniciiiiieeee e essiieeeeesssveeeeeseen 30\n\nXl AGREEMENT CHANGE PROCESS .....cccccitviiuirniiennniieniniiinecnnnsnssennennnens 31\nXIV Confidentiality .....cccuieeeeeeniiinnireiereniieecieeirencernceennsennceenssenneeencsnsesaseesnse 32\nA. Confidential INformation.......ccccuviiiiiiiiiiiiee e siaeees 32\n\nB. Confidentiality of this AGreement......ccccccvvieiiiiiiiiiiie e eee e sees 32\n\nXV Data Protection......c.ccccieieeiienieeiienrinieeereneesrenreesseecesssescssssascsascasssnscsnsees 33\nXVI Appeals and Complaints......ccccceeereeiiencrenierencrennerencrenneenceencesenesesccsssesenss 34\nS = - 1 ol o [ o Yol T L= PR PURPUPPPRRPC 7.\n\nB. Reconsideration of GLEIF decisions regarding Accreditation...........c.ccceccvvveeeennnn. 34\n\nC. Reconsideration and Complaints ......ccccceeeeiiiiiiieee i sssvnneeeees 34\n\nXVII Mediation and Arbitration ......cc.cccevveeiiiiiiinnniiiiinnciiiiineeeee. 35\nA PIINCIPIES ettt e et ae e e e s naraees 3D\n\n2 T V1Yo [ -1 1 o [OOSR UUPUPRPPRPITR: 1.\n\nO V4 o T 1 - { (o] o F TR PPPPPPRPPRRPPRPRC 1\n\nD. Maediation and Arbitration for Disputes amongst local operating units .............. 36\nXVIHIMISCellan@ous ......cceuueeeiiiiiiiiiineiiiiiiiiinriiisinninnrernssssssnssssssesssssseneeness 37\nAV oo I Tor=1 o] L3 IF: 1Y O PSP UPUTPRUPRPUPRRRR. ¥\n\nB. NO ABENCY ittt e e e e e ee e e ee e bbb s s s esee e e e e eeeeeeesesnennnnnsnnnnnnsaes DT\n\nC. SeVerability. oo ee e e s snaaeeeees 37\n\nD. ASSIBNMENT..cciiiiiiiiiir ettt s e e e e e e eeeeeeenbe e bbb e e eeaanaeees 3T\n\nE. Written Form, Entire ABreement ..... .. ccie it eeeeeeeeeee 38\n\nF. Contact Persons, Address, Phone, Website, Mail ........cccooovviviieiiiiiiiiiiineeiiiiiinnnn... 38\n\nLG 0 1) OO PP TUPPPUPPPPPTPPPRUPRRRRRRRRRNC 1o\n\nH. FOrmal NOtificatioNnS......coovviiiiiiieciiie ettt rie e ee s e saees 3O\n\nI NO WAIVET ettt s e e e e e e e e e e e e eeeeebeeressn e DO\n\nJ. FOPCE M@JEUIE ...ttt s e e e e e e e e e e eeeaeaeene e sn e e DO\n@ GLEIS - Global LEI System Master Agreement Page 4 of 39\nGLEIF Master Copy Version 1.0\n2020-06-01_MA Master-Agreement-1.3-Final.docx Month 2000\n","contentLength":2878,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:26:18.477Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2020-06-01-ma-master-agreement-1.3-final.pdf","content":"121 GLEIF may request the transfer of all LEIs managed by the LOU to one or several other local\noperating units. The details are set out in the Service Level Agreement, Appendix 06, and may\nbe further refined in an Implementation Manual or Note. The LOU shall submit, in the event of\nordinary termination of this Agreement by either Party pursuant to Section 110, a proposal and\nplan of the LOU regarding the transfer of the LEls managed by it, but under reserve of review by\nGLEIF, particularly under reserve of GLEIF issuing order as per this Section. For the avoidance of\ndoubt, any transfer will strictly follow the pertaining provisions of the Service Level Agreement\n(Appendix 06).\n\n122 Both Parties agree that the requirements for implementing the GLEIS and thus complying with\nthe standards of the GLEIS may change over time, and that with increasing experience in the\nperformance of this Agreement some of its provisions may require certain changes.\n\n123 For the avoidance of doubt, the following provisions regarding the Agreement change process\ndo not apply where this Agreement reserves GLEIF's right to change the Agreement, such as for\ninstance in Sub-Chapter V.A and there particularly in Section 32.\n\n124 To the extent that changes to this Agreement are of administrative nature, such as updates to\nthe Contact Details (Appendix 12), without deviating from the spirit of the original provision, the\nLOU takes note of, and accepts, that GLEIF may change provisions of this Agreement without\nprior consultation of the LOU and without needing the LOU's consent. The LOU may update the\ncontent of Appendix 12 without needing GLEIF consent, but must notify GLEIF of having done\nso.\n\n125 In the event of change requirements as outlined in below Section 125.1, the provisions set out in\nSections 125.2 through 125.4 apply.\n\n125.1 The LOU acknowledges and accepts that GLEIF may change provisions of this\nAgreement (for the avoidance of doubt: including any Appendices and\nImplementation Manuals and Notes) to reflect changes\n\ni being recommended by the ROC or resulting from amendments to the\nGovernance Principles of the GLEIS, or\nii. resulting from changes in applicable standards (regardless of whether being\nestablished by GLEIF or by a recognized third party such as ISO), or\niii. resulting from major changes in the market and particularly in the\nrequirements of the General Public, or\niv. resulting from technical developments, or\nV. resulting from changes in the legal framework or landscape, or\nVi. resulting from changes in the global financial system or the financial stability.\nGLEIS - Global LEI System Master Agreement Page 31 of 39\nGLEIF Master Copy Version 1.0\n2020-06-01_MA Master-Agreement-1.3-Final.docx Month 2000\n","contentLength":2743,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:26:18.477Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2020-06-01-ma-master-agreement-1.3-final.pdf","content":"125.2 Itis understood that GLEIF shall make most judicious use of the above. In addition,\nwhenever GLEIF decides that such changes are required, GLEIF commits to prior\nconsultation with the local operating unit community in general depending on the\nsubject matter, and shall grant the opportunity for the LOU's comment on the\nplanned changes and on the timeframe proposed by GLEIF for operational\nimplementation. The comment period will be a minimum of 30 Days.\n\n125.3 Following the close of the consultation, GLEIF shall provide a summary of the\ncomments and notify the LOU about its decision and the change(s) that shall be\nmade, and the timeframe for operational implementation. Those changes shall\nbecome effective within 30 Days after receipt of such change notice unless the LOU\nobjects to such changes in writing within 14 Days of being notified by GLEIF about its\ndecision and change(s).\n\n125.4 In the event of objection notification from the LOU, GLEIF may, in its sole but\nreasonable discretion, grant an extension of the deadline for implementing the\nchange. If the LOU cannot satisfy the change requirements, GLEIF or the LOU shall be\nentitled to terminate this Agreement with immediate effect.\n\n126 Where experience or developments require changes to this Agreement which GLEIF, in its sole\nbut reasonable discretion, would rather not establish and enforce on its own despite being\nentitled under Sections 123 through 125, GLEIF shall voluntarily call for a consultation of either\nspecifically the LOU, or with the LOU including some or all other local operating units in general,\nwhereupon GLEIF may proceed according to Sections 123 through 125. Alternatively, and again\nin GLEIF's sole but reasonable discretion, the Parties may in good faith and in the spirit of the\nGLEIS, negotiate and agree on amendments. For the avoidance of doubt, nothing in this Section\n126 shall limit the rights of GLEIF pursuant to Sections 123 through 125.\n\nXIV Confidentiality\n\nA. Confidential Information\n\n127 Each Party acknowledges that the other Party may provide confidential information to the other\nboth during Accreditation and later on.\n\n128 128. To protect confidential information, the Parties have signed a Non-Disclosure Agreement,\nAppendix 01.\n\nB. Confidentiality of this Agreement\n\n129 The Parties acknowledge the importance of the General Public’s trust in GLEIF and in the LOU,\nparticularly in the LOU's accreditation.\n\n130 For this reason, this Agreement (for the sole purpose of this Section 130: without the\nAppendices, which are dealt with in Section 131) shall be made publicly available both by GLEIF\nand by the LOU.\n\nGLEIS - Global LEI System Master Agreement Page 32 of 39\nGLEIF Master Copy Version 1.0\n2020-06-01_MA Master-Agreement-1.3-Final.docx Month 2000\n","contentLength":2783,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:26:18.477Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2020-06-01-ma-master-agreement-1.3-final.pdf","content":"131 Likewise, the Appendices shall be made publicly available by both Parties, with the exception of\nany documents, particularly in the Accreditation Documentation, which are marked\n\"CONFIDENTIAL\" pursuant to the Non-Disclosure Agreement in Appendix 01.\n\n132 In the event of a third party requesting access to a non-public document, the Party receiving\nsuch request shall duly inform the other Party, and the Parties shall assess such request in good\nfaith, taking into account the fair interests of both Parties, of the third party and the public\ngood. For the avoidance of doubt, regarding documents marked \"CONFIDENTIAL\", the Non-\nDisclosure Agreement in Appendix 01 shall always prevail.\n\nXV Data protection\n\n133 Both Parties agree to strictly observe data privacy rules as set out in the data protection\nlegislation applicable in their respective jurisdiction.\n\n134 For the purpose of this Agreement, the Parties primarily confirm that they respect and comply\nwith data protection legislation as applicable and in force.\n\n135 Where no such legislation is in force, and as a material minimum standard, both Parties shall\ncomply with the provisions of the Swiss Federal Data Protection Act except that Act's provisions\nregarding (i) data protection to be observed by the Federal Government, (ii) the competences of\nthe Federal Data Protection Commissioner, and (iii) the criminal sanctions. The hence applicable\nprovisions of the Swiss Federal Data Protection Act and of the pertaining Ordinance are\nreproduced in Appendix 11.\n\n136 For the avoidance of doubt, both Parties may use Personal Data for the purpose of performing\ntheir obligations and rights under this Agreement. However, both Parties are aware of the\nsubtlety of transferring Personal Data to a foreign country, and hence\n\n136.1 both Parties take great care in protection of such data from any misuse or\nmisappropriation;\n\n136.2 both Parties ensure that their employees are made aware of the potential transfer of\ntheir Personal Data to a foreign country and that they agree to such transfer within\nthe purposes as set out in this Agreement;\n\n136.3 both Parties ensure that their employees are informed about either (i) the material\napplicability of the provisions of the Swiss Federal Data Protection Act which are set\nout in Appendix 11 or (ii) about local data protection legislation applicable to the\nLOU, if such legislation is equivalent or more rigorous.\n\n137 Both Parties undertake to regularly review and ensure that the provisions of this Chapter XV are\nimplemented and enforced.\n\n138 Both Parties shall inform each other about actual or potential disclosure(s) of Personal Data and\npromptly take appropriate measures to address the situation and to limit the risk of such\ndisclosure(s) from reoccurrence.\n\nGLEIS - Global LEI System Master Agreement Page 33 of 39\nGLEIF Master Copy Version 1.0\n2020-06-01_MA Master-Agreement-1.3-Final.docx Month 2000\n","contentLength":2931,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:26:18.477Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2020-06-01-ma-master-agreement-1.3-final.pdf","content":"XVI Appeals and Complaints\n\nA. Basic Principle\n\n139 GLEIF's goal is to resolve issues between GLEIF and the LOU amicably.\n\n140 There shall be a \"culture of conversation\" (in German \"Gespr chskultur\", in French \"culture de\ncommunication\") which includes a culture of trust and cooperation, aiming at reducing\nconfrontation and formal steps.\n\nHence, before taking resort to steps like lodging an appeal or complaint or mediation or\narbitration, or steps towards termination, or before formally raising a claim for damages, the\naffected Party shall whenever possible take the issue up openly and in good faith with the other\nParty, giving a mutual opportunity to understand and to remove misunderstandings, to cure\namicably, and to resolve the issue in mutual trust and co-operation.\n\nThe Parties agree to engage in such \"culture of conversation\" broadly and for whatever issues\nmay arise during the term of this Agreement.\n\n141 GLEIF is in particular aware that during Accreditation, views of GLEIF and the Candidate LOU\nmight differ, and that taking recourse to mediation and arbitration as set out in Chapter XVII\nshould be confined as well as reasonably possible.\n\n142 Further, GLEIF wishes to establish a mechanism for both itself and for the LOU, as well as for\nthird parties to submit complaints of whatever nature relating to the LOU or GLEIF, respectively.\n\n143 The following Sub-Chapters set out the rules that shall govern.\n\nB. Reconsideration of GLEIF decisions regarding Accreditation\n\n144 The Accreditation Manual (Appendix 02) governs the process by which appeals may be\nsubmitted by the Applicant or Candidate LOU.\n\nC. Reconsideration and Complaints\n\n145 The LOU may submit to GLEIF a request for reconsideration, or complaints against GLEIF, or\ncomplaints against another local operating unit, as well as inform GLEIF about complaints it has\nreceived from another local operating unit or from third parties like e.g. an LEl owner or any\nLegal Entity. Further, GLEIF may also provide to the LOU complaints from outside parties\nsubmitted to GLEIF relative to the LOU.\n\n146 Either GLEIF or the LOU, as the case may be, shall respond to the Party submitting the case\nrelative to the reconsideration request or to the complaint within 30 Days of receipt.\n\n147 The Parties shall thereafter take up talks in the spirit of Sections 140 and 141 in order to find a\nsolution taking into consideration all relevant facts, and the mutual interests of GLEIF and the\nLOU (or other local operating units), and of the General Public.\n\nGLEIS - Global LEI System Master Agreement Page 34 of 39\nGLEIF Master Copy Version 1.0\n2020-06-01_MA Master-Agreement-1.3-Final.docx Month 2000\n","contentLength":2676,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:26:18.477Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2020-06-01-ma-master-agreement-1.3-final.pdf","content":"XVIlI Mediation and Arbitration\n\nA. Principles\n\n148 Both Parties agree that any disputes, controversies or claims arising out of, or in relation to, this\nAgreement, including (explicitly without limitation) the validity, invalidity, breach, or\ntermination thereof, should be solved whenever possible amicably.\n\n149 To that end, both Parties shall seek to proactively establish confidence in each other,\nparticularly (but explicitly without any limitation whatsoever) by using the remedies available to\nthem under Chapter XVI.\n\n150 A Party formally alleging that the other Party breaches this Agreement shall inform the other in\nwriting, by registered letter / return receipt requested, giving the full facts and exact references\nto the provisions of this Agreement which it believes to be in violation, providing reasons for its\nposition, including documentation and its arguments so as to enable the other Party to consider\nthe issue in all relevant aspects.\n\n151 If the issue cannot be resolved immediately or in the process set out in Sections 111 and 112,\nthe Parties shall first attempt to resolve the matter informally through discussions and/or\nmeetings attended by staff of an appropriate hierarchy level, seeking to settle diverging views in\nfair and positive-minded personal contacts.\n\n152 If the dispute cannot be resolved, or if the parties disagree about the validity of a termination\nnotified pursuant to the process set out in Sections 111 and 112, Parties may agree to seek\nmediation pursuant to the following Chapter B and/or arbitration pursuant to the following\nChapter C.\n\n153 While nothing in this Section XVII prevents either Party to seek relief at ordinary courts for\nurgent provisional measures such as provisional injunctions or the safeguarding of evidence, the\nParties are prevented from lodging ordinary court action at ordinary courts, i.e. they both\nsubmit bindingly to the exclusive jurisdiction of the arbitration court as agreed in Chapter C of\nthis Section.\n\n154 The Parties are aware and agree that cost of mediation and arbitration (including reasonable\ncost of legal representation), as determined by the mediator or the arbitration tribunal,\nrespectively, shall be borne by the Party losing the case, and that in the event of both winning to\nsome extent and losing to some extent cost shall be shared proportionally.\n\nB. Mediation\n\n155 If the Parties are unable to resolve the matter themselves within 60 Days after the formal\nnotification according to Section 150, either Party may submit the matter to mediation, by\nwritten notification to the other Party.\n\n156 GLEIF shall appoint a single independent mediator who seeks to reconcile the Parties, and who\nshall make a recommendation to the Parties.\n\n157 The language of the mediation proceedings shall be English.\n\nGLEIS - Global LEI System Master Agreement Page 35 of 39\nGLEIF Master Copy Version 1.0\n2020-06-01_MA Master-Agreement-1.3-Final.docx Month 2000\n","contentLength":2951,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:26:18.477Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2020-06-01-ma-master-agreement-1.3-final.pdf","content":"158 The place of the mediation shall be Basel/Switzerland, except if both Parties agree in a written\nand signed instrument on a different place.\n\n159 A mediation request and ongoing mediation prevent the Parties to commence arbitration\nproceedings, except if the other Party can show clear evidence that the mediation request was\nsubmitted in bad faith such as, for instance, for the sole reason of delaying the matter.\n\n160 If a mediation has not resulted, for whatever reasons, within two months after the mediation\nrequest, in a reconciliation, or if either Party is not prepared to accept the mediator's\nrecommendation, then either Party is free to initiate arbitration proceedings. Alternatively, both\nParties may agree in writing to extend mediation for a three-month period.\n\nC. Arbitration\n\n161 All disputes arising out of or in connection with this Agreement shall be exclusively and finally\nsettled under the Rules of Arbitration of the International Chamber of Commerce by three\narbitrators appointed in accordance with the said Rules, where, for the avoidance of doubt, the\nEmergency Arbitrator Provisions apply as well.\n\n162 The language of the arbitration proceedings shall be English.\n\n163 The place of arbitration shall be Basel/Switzerland, except if both Parties agree in a written and\nsigned instrument on a different place.\n\n164 The number of arbitrators shall be three, except if both Parties agree in advance and in a written\nand signed instrument on a sole arbitrator.\n\nD. Mediation and Arbitration for Disputes amongst local operating\n\nunits\n\n165 In the event of disputes between the LOU and any other Candidate or Accredited local operating\nunit, the LOU agrees to seek a solution and amicable agreement by negotiating the issue in good\nfaith with the other local operating unit in the spirit of Chapter XVI.\n\n166 In the event such negotiations fail, the LOU and the other local operating unit are obliged to first\nseek GLEIF's Good Offices to both of them, before applying for arbitration. GLEIF shall appoint a\nmediator of its own choice. The cost of the mediator is borne equally by both the LOU and the\nother local operating unit.\n\n167 In the event that the dispute cannot be resolved amicably, the LOU and the other local\noperating unit irrevocably and bindingly agree to submit their dispute to the International\nChamber of Commerce for Arbitration as set out in above Sub-Chapter XVII.C.\n\nGLEIS - Global LEI System Master Agreement Page 36 of 39\nGLEIF Master Copy Version 1.0\n2020-06-01_MA Master-Agreement-1.3-Final.docx Month 2000\n","contentLength":2565,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:26:18.477Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2020-06-01-ma-master-agreement-1.3-final.pdf","content":"XVIIl Miscellaneous\n\nA. Applicable Law\n\n168 This Agreement shall in all respects be governed by, and construed and interpreted in\naccordance with, the substantive laws of Switzerland, without regard to Switzerland's conflict of\nlaws rules. GLEIF maintains on its website a list with links to some online resources to\nSwitzerland's federal and cantonal law as well as federal court practice, which list for the\navoidance of doubt shall however not, on any account, be construed as limiting in whatever way\nthe scope of the applicable substantive laws of Switzerland.\n\n169 Notwithstanding the above choice of Law, both Parties acknowledge that certain areas and\nissues may be mandatorily governed by a different law, such as by the local law at the LOU's\ndomicile, and national trademark law regarding GLEIF's or the LOU's trademarks.\n\nB. No Agency\n\n170 The relationship between GLEIF and the LOU does not constitute a joint venture or partnership\nin the meaning of Art. 530 et seq. of the Swiss Code of Obligations or any similar form of\ncooperation under any other applicable laws.\n\nC. Severability\n\n171 The invalidity of individual parts of this Agreement shall have no impact on the validity of the\nAgreement as a whole. The Parties agree that if any provision or part of a provision of this\nAgreement shall, for whatever reason, be deemed invalid, inoperative or otherwise not\nenforceable, the Agreement as a whole shall remain valid and the invalid or inoperative\nprovision or part of a provision shall be considered replaced by the provision which the Parties\nwould have agreed on in good faith if they had been aware of the invalidity of the respective\nprovision.\n\nD. Assignment\n\n172 The LOU is not entitled to transfer this Agreement or any rights or obligations under this\nAgreement to any third party without GLEIF's prior written consent.\n\n173 GLEIF is entitled to delegate or sub-contract the exercise of its rights or obligations to another\nentity, provided that GLEIF remains responsible to the LOU for the performance and the\nobservance of this Agreement.\n\n174 If the functions of GLEIF are transferred to another entity, GLEIF is entitled to transfer its rights\nand obligations to such successor entity.\n\nGLEIS - Global LEI System Master Agreement Page 37 of 39\nGLEIF Master Copy Version 1.0\n2020-06-01_MA Master-Agreement-1.3-Final.docx Month 2000\n","contentLength":2364,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:26:18.478Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2020-06-01-ma-master-agreement-1.3-final.pdf","content":"E. Written Form, Entire Agreement\n\n175 This Agreement, including this clause, may only be amended, waived, rescinded or terminated in\nwriting.\n\n176 This Agreement contains the entire understanding of the Parties with respect to the subject\nmatter hereof and substitutes and merges any previous agreement, be it written or oral, among\nthe Parties hereto concerning the subject matter hereof.\n\nF. Contact Persons, Address, Phone, Website, Mail\n\n177 The primary contact persons of either Party, as well as specialized contact persons (such as\ntechnical staff) are listed in Appendix 12.\n\n178 Both Parties undertake to keep Appendix 12 up to date.\n\nG. Cost\n\n179 Subject to provisions herein containing agreements to the contrary, each Party bears its own\ncosts in relation to the drafting, conclusion, closing and performance of this Agreement.\n\nH. Formal Notifications\n\n180 Notifications to be made under this Agreement are only validly made by registered mail, return\nreceipt requested, or by e-mail followed by a duly dated and signed copy of that e-mail within 5\nDays (sent by registered mail, return receipt requested), or by telefax (explicitly confirmed by\nthe recipient), to the addresses listed in Appendix 12.\n\n181 Address changes have to be notified without delay to the other Party; as long as no such\nnotification of change of address is received, notifications hereunder are validly made to the last\nvalid address in accordance with Appendix 12. Time limits are deemed complied with if a\nnotification is (i) handed over for delivery to the recipient to an international courier service, or\n(ii) sent by telefax or e-mail no later than the last Day of the relevant time limit.\n\nI. No Waiver\n\n182 No act, delay or omission on a Party's part in exercising any right or remedy shall operate as a\nwaiver of such or any other right or remedy. No single or partial waiver by a Party of any\nprovision of this Agreement, or of any breach or default by the other Party, or of any right or\nremedy, shall operate as a waiver of any other provision, breach, default, right or remedy or of\nsuch provision, breach, default, right or remedy on a future occasion.\n\nJ. Force Majeure\n\n183 In the event of force majeure, such as floods, tsunamis, earthquakes, fires, storms such as\nhurricanes or typhoons, war, strikes, riots, volcanic eruptions, or any other similar extraordinary\nsituation, event or circumstance beyond the control of either Party, the obligations of the\n\nGLEIS - Global LEI System Master Agreement Page 38 of 39\nGLEIF Master Copy Version 1.0\n2020-06-01_MA Master-Agreement-1.3-Final.docx Month 2000\n","contentLength":2609,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:26:18.478Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2020-06-01-ma-master-agreement-1.3-final.pdf","content":"Parties are suspended to the extent force majeure prevents their reasonable performance, and\nno damage claims shall arise for that reason.\n184 Once the force majeure ceases, the Parties shall seek in good faith to resume orderly business.\n185 If the force majeure persists for more than three months, the Parties shall convene to find an\nacceptable intermediate agreement.\nkK sk\nGLEIS - Global LEI System Master Agreement Page 39 of 39\nGLEIF Master Copy Version 1.0\n2020-06-01_MA Master-Agreement-1.3-Final.docx Month 2000\n","contentLength":523,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:26:18.478Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2020-06-01-ma-master-agreement-1.3-final.pdf","content":"List of Appendices\nApp. 01 Non-Disclosure Agreement\nApp. 02 Accreditation Manual and Accreditation Checklist\nApp. 03 Accreditation Plan\nApp. 04 Accreditation Documentation\nApp. 05 LOU-contract Requirements\nApp. 06 Service Level Agreement\nApp. 07 Payments\nApp. 08 Ancillary Duties\nApp.09a Terms of Use of GLEIF\nApp. 09b Template for the Terms of Use of the LOU\nApp. 10 Annual Accreditation Verification Requirements\nApp. 11 Applicable provisions of the Swiss Data Protection Act\nApp. 12 Contact details of the Parties\nApp. 13 Individual deviations from the Master Agreement\nApp. 14 Requirements for Third Party Services\n@ GLEIS - Global LEI System Master Agreement Page 5 of 39\nGLEIF Master Copy Version 1.0\n2020-06-01_MA Master-Agreement-1.3-Final.docx Month 2000\n","contentLength":765,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:26:18.478Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2020-06-01-ma-master-agreement-1.3-final.pdf","content":"Preamble\n\nA. Recognizing the need to develop and maintain globally unique identifiers for all legal entities\nbeing parties to financial transactions across the globe (a Legal Entity Identifier, \"LEI\", with\npertaining Legal Entity Reference Data, \"LE-RD\"), to be used by authorities and by the private\nsector to support improved risk management, increased operational efficiency and other needs,\nthe Group of Twenty (\"G-20\") leaders and the Financial Stability Board® (\"FSB\") initiated in the\ninterest and for the benefit of the public the Global Legal Entity Identifier System (\"GLEIS\").\n\nB. The GLEIS is based on three tiers, namely\n\n1. the Regulatory Oversight Committee (\"ROC\"), an organization of regulators from\nmultiple jurisdictions charged by the G-20 with oversight of the GLEIS?;\n\n2. the Global Legal Entity Identifier Foundation (\"GLEIF\"), a non-profit foundation\nincorporated by the Financial Stability Board (\"FSB\") under the laws of Switzerland\non June 26, 2014, dedicated to serve the interests of the public;\n\n3. the accredited LOCAL OPERATING UNITS, federated through GLEIF by worldwide\nuniform standards and protocols.\n\nC. The ROC- established in January 2013 on the basis of a Charter endorsed by the Finance\nMinisters and Central Bank Governors of the G-20 and being composed by representatives from\npublic authorities across the globe — has the mission to uphold the governance principles of, and\nto oversee, the GLEIS in the broad public interest. The ROC is represented as observer on GLEIF's\nBoard. The ROC sets policy standards for the GLEIS and may take appropriate action to protect\nthe public interest through regulatory oversight of GLEIF and the GLEIS.\n\nD. Within the GLEIS, for the purposes of this Agreement, GLEIF is — operating under the oversight\nof the ROC - responsible for\n1. developing, in consultation with the ROC and other relevant stakeholders, worldwide\n\nuniform operational and technical standards and protocols for LEls and LE-RD in accordance\nwith the governance principles of the Global LEI System and the existing and future policy\nstandards defined by the ROC (\"Rulemaking Function\");\n\n2. maintaining a central database of LEIs and corresponding LE-RD in order to ensure a high\nlevel of data quality, and making available — along with LOCAL OPERATING UNITS — LEIs and\nLE-RD in the public domain in accordance with the Governance Principles of the GLEIS as set\nout by the FSB in June 20123 and as implemented and agreed in this Master Agreement\n(\"Operational Function\");\n\n1 http://www.financialstabilityboard.org/\n\n2 http://www.leiroc.org/index.htm\n\n3 http://www.financialstabilityboard.org/2012/06/fsb-report-global-legal-entity-identifier-for-financial-markets\n\nGLEIS - Global LEI System Master Agreement Page 6 of 39\nGLEIF Master Copy Version 1.0\n2020-06-01_MA Master-Agreement-1.3-Final.docx Month 2000\n","contentLength":2856,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:26:18.478Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2020-06-01-ma-master-agreement-1.3-final.pdf","content":"3. monitoring of compliance of Accredited LOCAL OPERATING UNITS with the terms of this\nMaster Agreement which implements the Governance Principles of the GLEIS, and with the\noperational and technical standards issued by GLEIF (\"Monitoring Function\");\n\n4. ensuring that the GLEIS is and remains first and foremost dedicated to the interest and\nbenefit of the public;\n\n5. and committing to equal treatment of all LOCAL OPERATING UNITS.\n\nE. Within the GLEIS, the LOCAL OPERATING UNITS are responsible for creation and issuance of New\nLEls, collection of corresponding LE-RD, maintaining and renewing such data, and — along with\nGLEIF — making available LEls and LE-RD data as defined hereinafter (\"Level-I\") in the public\ndomain, all of the foregoing in accordance with the Governance Principles of the GLEIS and in\nadherence to the standards, protocols and terms set out and agreed in this Master Agreement.\n\nF. The next policy step (\"Level-1I\") is the implementation of additional LE-RD. l.e. information on\norganizational relationship structures, particularly hierarchical structures as an important aspect\nof the GLEIS (\"Level-ll\"). The ROC established in December 2014 a task force to develop a\nproposal. A public consultation is expected to be held in the course of 2015, and phased\nimplementation to begin around the end of 2015*.\n\nG. Asrequired in Recommendation 6 issued by the FSB in June 2012, the GLEIS is committed to the\nprinciples of competition and anti-trust at global and local levels and encourages competition\nand innovation, while however making no compromises in strict and uniform requirements\nrelative to data quality.\n\nH. This Master Agreement being signed by each individual LOCAL OPERATING UNIT with GLEIF sets\nout the mutual agreements, rights and obligations between GLEIF and each signing LOCAL\nOPERATING UNIT.\n\nI. Any institution signing this Master Agreement thereby seeks Accreditation as set out and agreed\nin the terms of this Master Agreement including its Appendices, thereby recognizing that the\nsuccess of the GLEIS is based on all LOCAL OPERATING UNITS maintaining compliance with the\nGovernance Principles of the GLEIS, with globally uniform standards and protocols, and by\nensuring delivery of data which is of the highest quality, up-todate and compliant with the\ncurrently valid common data formats.\n\nNow, therefore, the Parties agree as follows:\n\n4 http://www.leiroc.org/publications/gls/roc_20150128-2.pdf\n\nGLEIS - Global LEI System Master Agreement Page 7 of 39\nGLEIF Master Copy Version 1.0\n2020-06-01_MA Master-Agreement-1.3-Final.docx Month 2000\n","contentLength":2594,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:26:18.478Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2020-06-01-ma-master-agreement-1.3-final.pdf","content":"I Purpose and scope\n\n1 The Master Agreement (\"this Agreement\", which for the avoidance of doubt and as defined\nincludes its Appendices) sets out the rights and obligations of GLEIF and of the LOU regarding\nthe LOU's participation in the GLEIS, including in particular (but for the avoidance of doubt\nwithout limitation) the Accreditation of the LOU, the issuance of New LEls and maintenance of\nLEls, cost contributions, services by GLEIF and by the LOU, the public availability of LEIs and LE-\nRD, intellectual property on LEls and LERD, data protection matters, ensuring competition and\nanti-trust at global and local levels, and the binding rules regarding dispute resolution and court\ncompetence.\n\n2 With this Agreement, the Parties establish rights and duties with the overall aim of furthering\nthe implementation of the GLEIS by issuing and maintaining LEls, where GLEIF has a rulemaking,\nan operational and a monitoring role in the implementation of the GLEIS, and where the LOU is\none of many local operating units throughout the world.\n\n3 The foregoing Sections 1 and 2 are a broad and summary description of the contents and scope\nof this Agreement. Nothing in Sections 1 and 2 limits the binding force and applicability of this\nAgreement or of any of its provisions.\n\n4 Inthe event of a contradiction between this Agreement and any of its Appendices, that\nAppendix shall prevail, provided that in such Appendix (i) this preference appears clear and\nunambiguous, and (ii) except where stipulated otherwise. More recent Appendices shall prevail,\nin the event of contradictions with older Appendices.\n\nIl Definitions\n\nAccreditation the formal evaluation process performed by GLEIF to ensure that the\nCandidate LOU meets GLEIS/GLEIF requirements\nAccreditation Certificate a formal certificate issued by GLEIF confirming successful\nAccreditation\nAccreditation Checklist the document, referenced in the Accreditation Manual (Appendix 02),\nwhich details the control and process requirements for Accreditation\nAccreditation the documentation to be provided by the Candidate LOU to GLEIF for\nDocumentation evaluation for Accreditation, as agreed in the Accreditation Plan,\nwhere the final documentation becomes binding upon successful\nAccreditation and is integrated into this Agreement as Appendix 04\nAccreditation Manual the Manual (Appendix 02), and the Accreditation Checklist, describing\nthe requirements and steps towards Accreditation\nAccreditation Plan an initial set of documents reflecting, in general terms, the Applicant\nLOU’s plan for achieving Accreditation\nGLEIS - Global LEI System Master Agreement Page 8 of 39\nGLEIF Master Copy Version 1.0\n2020-06-01_MA Master-Agreement-1.3-Final.docx Month 2000\n","contentLength":2720,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:26:18.478Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2020-06-01-ma-master-agreement-1.3-final.pdf","content":"Accreditation the process detailed in the Accreditation Manual (Appendix 02), and\n\nVerification the Annual Accreditation Verification Requirements (Appendix 10),\nassessing that the LOU still meets all criteria for Accreditation in\nsubsequent years of operation\n\nAgreement this Master Agreement as signed by both Parties, where for the\navoidance of doubt any reference to \"Agreement\" includes all\nAppendices\n\nApplicant LOU an institution which wishes to become a Candidate LOU and\nparticipate in the Accreditation process and negotiates an\nAccreditation Plan with GLEIF with the intent of entering into this\nAgreement, but not yet having signed this Agreement\n\nCandidate LOU the contracting party to this Agreement, that has signed this\nAgreement but not yet received Accreditation\n\nCommon Data File the mandatory requirements for the structure and content of LE-RD\n\nFormat as set out in the currently valid versions of the “LEI Data File Formats”\n\nDay a business day, provided that a given day only counts as such if itis a\nbusiness day both at GLEIF's domicile in Basel/Switzerland and at the\nLOU's domicile.\n\nDirect Cost a cost borne by the LOU that can be specifically allocated to a\nparticular business activity, and that can be accurately and clearly\ntraced, with little effort, to said business activity, including inter-\ncompany transfer fees based on “arm’s lengths” terms and fees paid\nto third party service providers assisting the performance of Services\nagreed in the Service Level Agreement (Appendix 06).\n\nEffective Date the later of the dates of signing shown on the first page of this\nAgreement\n\nfor example, e.g., such \"for example\", \"e.g.\", \"such as\", \"including\", \"in particular\" and similar\n\nas, including, in expressions consistently denote that the following are examples,\n\nparticular without any limitation and/or without limiting the generality of\nrequirements, given for illustrative or highlighting purposes, except\nwhere explicitly stated otherwise\n\nFSB Financial Stability Board, http://www.financialstabilityboard.org\n\nFSB Recommendations the recommendations contained in Annex 2 in the 8 June 2012 FSB\nreport \"A Global Legal Entity Identifier for Financial Markets\"\ndownloadable from the URL in footnote 3, endorsed by the Leaders of\nthe G-20 at Los Cabos, Mexico, on 19 June 2012\n\nGeneral Public includes the public sector, financial institutions, investment vehicles,\ncorporations (big and SME), private individuals and researchers and\nany other users of LEls and LE-RD.\n\nGLEIF Global Legal Entity Identifier Foundation http://www.gleif.org/\n\nGLEIS - Global LEI System Master Agreement Page 9 of 39\nGLEIF Master Copy Version 1.0\n2020-06-01_MA Master-Agreement-1.3-Final.docx Month 2000\n","contentLength":2718,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:26:18.480Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2020-06-01-ma-master-agreement-1.3-final.pdf","content":"GLEIF Logo the logo (graphical design) of the GLEIF Trademark\nGLEIF Statutes the document available on\nhttp://www.gleif.org/en/about/governance/ statutes and valid on the\ndate of signature of this Agreement\nGLEIF Trademark the trademark owned by GLEIF (\"LEl/design\"), the basic registration\nbeing Swiss Trademark Reg-No 775’471 (which may be found by\nsearching on https://www.swissreg.ch), and any and all national\ntrademarks based on it or being substantially identical\nEnabling global identity\nGLEI F Protecting digital trust\nGLEIF Website http://www.gleif.org\nGLEIS Global Legal Entity Identifier System\nGlobal LEI Repository a database managed by GLEIF containing all current and historical LEls\nand LE-RD and other (if any) LEIl related current and historical data\nitems as provided by the LOUs and by GLEIF in case GLEIF issues an LEI\nGolden Copy database file generated by GLEIF containing all current LEls and\nrelated reference data (LE-RD)\nGovernance Principles the Global LEI System High Level Principles as set out in Annex 3 of the\nof the GLEIS FSB report \"A Global Legal Entity Identifier for Financial Markets\" of 8\nJune 2012 downloadable from the URL in footnote 3, endorsed by the\nLeaders of the G-20 at Los Cabos, Mexico, on 19 June 2012, the\nrecommendations in Annex 2 of the same report, the ROC Charter\nendorsed by the G-20 on 5 November 2012, as well as any\namendments thereof; and any additional principles or standards\nadopted by the ROC\nImplementation a manual or note, describing how GLEIF implements existing\nManual / Note provisions of this Agreement, as e.g. typically Operational and\nTechnical Standards associated with services of the LOU, or describing\nGLEIF processes already identified in this Agreement which have an\nimpact on the LOU, or describing internal GLEIF processes for\ninformational purposes\nISO 17442 the I1SO Standard relating to the LEI format and structure as set out in\nthe currently valid version of the code\nIT Information Technology, encompassing application software,\ncomputer and network systems and suitable equipment for the\nimplementation and support of such systems\nGLEIS - Global LEI System Master Agreement Page 10 of 39\nGLEIF Master Copy Version 1.0\n2020-06-01_MA Master-Agreement-1.3-Final.docx Month 2000\n","contentLength":2268,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:26:18.480Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2017-09-01-ma-appendix-01-non-disclosure-agreement_final.pdf","content":"O:GLEIF} Protecing digtal tust\nNon-Disclosure Agreement\nAppendix 01\n","contentLength":68,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:26:30.555Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2017-09-01-ma-appendix-01-non-disclosure-agreement_final.pdf","content":"Non-Disclosure Agreement\nBetween\nGlobal Legal Entity Identifier Foundation “GLEIF”\nSt. Alban-Vorstadt 5, 4052 Basel, Switzerland\nAnd\nuLOUn\nEach also \"a Party\", together \"the Parties\"\nRegarding Confidential Information\nBasel,\nBy: Stephan Wolf Sven Schumacher By:\nFunction(s): CEO General Counsel Function(s):\nMade in two originals, one for each Party\nGLEIS - Global LEI System Master Agreement Page 2 of 5\nGLEIF Appendix 01 — Master Copy Version 1.2\n2017-09-01-MA-Appendix-01-non-disclosure-agreement-Final.docx 1 September 2017\n","contentLength":528,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:26:30.555Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2017-09-01-ma-appendix-01-non-disclosure-agreement_final.pdf","content":"Whereas\n\nA. The Parties plan to enter into the Master Agreement regarding Legal Entity Identifiers, without\nan obligation of either Party, by mere signature and performance of this Non-Disclosure\nAgreement, to do so.\n\nB. Definitions set out in the Master Agreement are valid for this Non-Disclosure Agreement as well,\nand both Parties confirm to be aware of those.\n\nC. Already before, but as well in the course of, performance of their respective rights and\nobligations under the Master Agreement, the Parties will disclose to each other and, in the event,\nto their respective affiliates, employees, advisors and representatives certain confidential\ninformation, and will contact employees of those.\n\nD. Both Parties are interested in strict confidence with regard to certain disclosed information.\n\nNow, therefore, the Parties agree as follows:\n\nl. Confidentiality Undertaking\n\nA. Disclosure of Information\n\n1. The Parties will disclose certain information to each other, and for each occurrence of such\ndisclosure, the Party disclosing the information is herein referred to as the Disclosing Party,\nwhereas the Party receiving the information is referred to as the Receiving Party.\n\n2. Forthe avoidance of doubt, a reference to a Disclosing or a Receiving Party, respectively, shall\ninclude its respective affiliates, employees, auxiliary persons such as freelancers, advisors and\nrepresentatives.\n\nThe LOU is aware that GLEIF eventually has to disclose certain information on request. Hence,\nregarding GLEIF a reference to the Receiving Party shall further include (i) the Chairperson and\n(i) the Vice-Chairperson of ROC, and (iii) the Supervisor (member of ROC) if such Supervisor has\nbeen formally designated.\n\nB. Confidential Information\n\n3. \"Confidential Information\" shall mean all information furnished to the Receiving Party by the\nDisclosing Party, whether furnished before the signing, or Effective Date, of the Master\nAgreement in the context of negotiations or during the term of the Master Agreement,\n\ni. if transmitted in text form, namely in hardcopy such as a letter or an agreement, or\nelectronically such as a pdf- or Word-document, or by e-mail, and the like,\nii. and if clearly marked as \"CONFIDENTIAL\".\nGLEIS - Global LEI System Master Agreement Page 3 of 5\nGLEIF Appendix 01 — Master Copy Version 1.2\n2017-09-01-MA-Appendix-01-non-disclosure-agreement-Final.docx 1 September 2017\n","contentLength":2404,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:26:30.555Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2017-09-01-ma-appendix-01-non-disclosure-agreement_final.pdf","content":"4. Confidential Information does not include, however, information which\ni. is already publicly known or becomes publicly known other than as a result of either Party's\nbreach of the confidentiality undertaking;\n\nii. was or will be disclosed to the Receiving Party without confidentiality reservation prior to\ndisclosure to the Receiving Party, provided that such disclosure did not constitute a breach of\na Non-Disclosure-Agreement of the Disclosing Party with either GLEIF or any local operating\nunit (including Applicant and Candidate local operating units) or was obtained by the\nDisclosing Party in breach of laws;\n\niii. the Receiving Party is required to disclose due to applicable laws, a judgement or an order of\na competent authority. In such case, the Receiving Party will notify the Disclosing Party\nwithout delay of such disclosure obligation (except if prohibited by law, judgement or order)\nin order to enable the Disclosing Party to seek an appropriate protective order or other\nappropriate remedy. In any case, the Receiving Party will limit such disclosure to the legally\nrequired minimum.\n\n5. The Disclosing Party shall not unduly mark information provided as \"Confidential\". The Receiving\nParty may inquire, from time to time, whether some specific information is still confidential.\n\n6. The Receiving Party is aware and acknowledges for each occurrence of disclosure of Confidential\nInformation that the Disclosing Party has a significant interest that all its Confidential Information\nbe kept confidential, in particular because such Confidential Information may contain know-how\nand business secrets of the Disclosing Party, or may be subject to banking secrecy or similar\nmandatory restrictions.\n\n7. The Receiving Party agrees\n7.1. to keep all Confidential Information confidential and not to disclose, or allow access to, any\n\nConfidential Information to any person other than its affiliates, employees, advisors and\nrepresentatives who are actively and directly participating in the performance of the Master\nAgreement, or who otherwise need to know the Confidential Information;\n\n7.2. to procure that any such affiliates, employees, advisors and representatives will observe the\nterms of this Non-Disclosure Agreement as if such persons were a party hereto, which\nincludes for the avoidance of doubt the ROC-members mentioned in Section 2 2\" para;\n\n7.3. to assume responsibility and to be held liable for any disclosure or use of the Confidential\nInformation other than expressly permitted in this Non-Disclosure Agreement, pursuant to\nthe Master Agreement's provisions regarding warranty and liability.\n\n8. The Receiving Party undertakes to use best efforts to protect and maintain the confidentiality of\nthe Confidential Information and to prevent access of unauthorized persons to the Confidential\nInformation.\n\n9. Upon the termination of the Master Agreement, each Party shall upon request return to the\nother Party, or destroy, all copies and other records of Confidential Information, except if and to\nthe extent mandatory provisions of law or of professional codes of conduct may require the\nkeeping of records, which requirements shall be communicated to the other Party.\n\nGLEIS - Global LEI System Master Agreement Page 4 of 5\nGLEIF Appendix 01 — Master Copy Version 1.2\n2017-09-01-MA-Appendix-01-non-disclosure-agreement-Final.docx 1 September 2017\n","contentLength":3385,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:26:30.555Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2017-09-01-ma-appendix-01-non-disclosure-agreement_final.pdf","content":"10. This Non-Disclosure Agreement remains valid and binding upon both Parties for an indefinite\nperiod also after termination of the Master Agreement.\nIl. Applicable Law and Jurisdiction\n11. This Non-Disclosure Agreement is subject to the law and the jurisdiction agreed in the Master\nAgreement. Both Parties explicitly confirm to having had access to the Master Agreement before\nsigning this Non-Disclosure Agreement.\nIll. Miscellaneous\n12. For the avoidance of doubt, the following provisions of the Master Agreement apply to this Non-\nDisclosure Agreement as well:\nXII. Agreement Change Process\nXIV. Confidentiality\nXV. Data Protection\nXVI. Appeals and Complaints\nXVIl. Mediation and Arbitration\nXVIIl. Miscellaneous\n%k k%\nGLEIS - Global LEI System Master Agreement Page 5 of 5\nGLEIF Appendix 01 — Master Copy Version 1.2\n2017-09-01-MA-Appendix-01-non-disclosure-agreement-Final.docx 1 September 2017\n","contentLength":908,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:26:30.555Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2021-05-31-ma-appendix-02-accreditation-checklist_final.pdf","content":"Accreditation\nDocumentation\nChecklist\n","contentLength":38,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:27:02.643Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2021-05-31-ma-appendix-02-accreditation-checklist_final.pdf","content":"Contents 2\nAContactDetdils .........ciiiiiiiiiiniiiieninnenarentonssassssaeseesd\nBENtity Structure .........ciiitiiiiiiiiintiinernnennneeneennnnnnnaaa.lt\nC Organization Structure .. ..........ciiiiiiiiiiinnnnneeeessneneesas . 8\nD Financial Data, Audits & General Governance . . . ................9\nE Cost Recovery Requirements . .. ........c.coiiiiineeennnssenness..10\nFLOU SEIviCes . ...ivviiitiinneenerenessnsssssssssssnssssnssnsssasssll\nG Required Website ltems . ............... .. ittt 15\nHRecords Management .. ..........ciiiiiiiiiiiiiinrennnnnneneeas. 16\n| Software Development .. ......... .ottt 17\nJ Networks & Infrastructure . . ........ ...ttt 17\nKIT Security & Compliance . . ...ttt nnnnnnnnss.. 18\nLData Quality Management .. .. ......c.iiiiiiiinnrtronnnnnneeeaas 19\nChecklist Instructions\nSections A, B, and C (Questions 1-3) must be completed and submitted\nas part of the Accreditation Plan. Sections D through L and the remaining\nguestions from Section C are to be completed and submitted after the\nAccreditation Plan has been agreed with GLEIF and the Master\nAgreement has been fully executed.\nPlease note:\nThis version of the Accreditation Checklist should be used by all Applicants\nand Candidates after 31 May 2021 for Accreditation and Annual\nAccreditation Verification when instructed.\nAny prior versions of the Accreditation Checklist will no longer be utilized nor\naccepted by GLEIF. This document is posted to the GLEIF website for public\nuse and downloading.\nAll questions as applicable consider and address both Level 1 and Level 2\ndata requirements. The Applicants/Candidates need to ensure this factor\nis incorporated into all responses.\n Please provide Informatlon felated to Parent/Owner andlor LEI Operations asnoted\n\nGLEIF 2021/01\n","contentLength":1763,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:27:02.643Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2021-05-31-ma-appendix-02-accreditation-checklist_final.pdf","content":"General Information for Accreditation Documentation Submission 1\n> Required Documentation to be Submitted with Checklist Responses\nF LOU Services\nLegal Name of Candidate LOU\nLOU Services\nType of Document Xrefto Docs Provided Yes No N/A Additional Documentation Requested\nPlease cite document Please check one\nand page #\n1. Issuenew LEls\n11 Will you execute a formal contract either physically or Please provide a template and a brief narrative including\nelectronically with a Legal Entity for every LEl issued? all points\n1.2 Does your legal entity contract template include all\nrequirements as defined in the Master Agreement Appendix 5?\n1.3 Do you have astandard process for receiving payment from Please provide a brief narrative\na legal entity for which an LEI was provided?\n1.4 Upon receipt of an application do you have procedures Please provide a brief narrative on all points\ninplace for:\n1.41 Verifying against an authoritative source the\naccuracy of the LE-RD provided by the LE?\n1.4.2 Verifying existence and eligibility of the entity\napplying for the LEI?\n1.4.3 Verifying that the individual signing the application\nis duly empowered?\n1.4.4 Ensuring an up-to-date list of applicable accounting\nstandards and authoritative sources is used for verifying\nthat the reported relationship information exists?\n1.4.5 Verifying the existence and eligibility of the relationship\ninformation reported?\n1.4.6 Informing the Legal Entity that either its application shall\nrequire amendment, shall be refused, or the LEI has been\nissued and incorporated into the Global LEI repository?\n1.4.7 Reporting the correct relationship information of\nthe Legal Entity?\n1.4.8 Uploading new LEI and LE-RD as well as relationship\nrecords to GLEIF?\n1.4.9 Accepting without delay and processing applications\nfor an LEI?\nGLEIF 2021|01\n","contentLength":1817,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:27:02.643Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2021-05-31-ma-appendix-02-accreditation-checklist_final.pdf","content":"General Information for Accreditation Documentation Submission 12\n> Required Documentation to be Submitted with Checklist Responses\nF LOU Services\nLegal Name of Candidate LOU\nLOU Services\nType of Document Xrefto Docs Provided Yes No N/A Additional Documentation Requested\nPlease cite document Please check one\nand page #\n2. Enter Legal Entity Events\n2.1 Do you have a formal process in place which includes: Please provide a template and a brief narrative including\nall points\n211 Providing aninterface or mechanism for the\nLegal Entity to update LE-RD\n21.2 Maintaining procedures for verifying the change\nis duly empowered to do so by:\n- Reverifying the authority of the requestor of the change?\n- Reconfirming the authorized person’s contact details\nincluding email address?\n- Reconfirming the requestor email address is not generic?\n21.3 Checking,if an update to the relationship information\nis also required?\n214 Verifying via an authoritative source the accuracy\nof the Legal Entity Event change?\n215 Informing the Legal Entity of changed LE-RD\nand uploading the changed LE-RD to GLEIF?\n3. Manage Challenges\n31 Do you have aformal challenge process in place which includes: Please provide a template and a brief narrative including\nall points\n311 Reviewing and responding to LEl and LE-RD\nchallenges transmitted to the LOU by GLEIF?\n31.2 Ensuring that the relationship information is\nalso reviewed and changed, where applicable?\n31.3 Informing the Legal Entity of validated challenges\nand uploading the changed LE-RD to GLEIF\nas applicable?\n4. Transfer of LEls and LE-RD\n4.1 Do youhave aprocess in place for a Legal Entity to request Please provide a template and a brief narrative including\ntransfer of a LEI? all points\n4.2 Does your process ensure that:\n4.21 The defined and established transfer rules in the GLEIS\nare followed?\n4.2.2 Procedures for verifying the individual requesting the\nLEI transfer is duly empowered to do so are in place?\n4.2.3 The associated relationship information is\ntransferred as well?\n4.2.4 LE-RDis verified via an authoritative source?\n4.2.5 Relationship information is correctly transferred as well?\n4.2.6 The Legal Entity is informed (as applicable)?\n4.2.7 The LElI and its changed LE-RD are uploaded to GLEIF?\nGLEIF 2021|01\n","contentLength":2265,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:27:02.643Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2021-05-31-ma-appendix-02-accreditation-checklist_final.pdf","content":"General Information for Accreditation Documentation Submission 13\n> Required Documentation to be Submitted with Checklist Responses\nF LOU Services\nLegal Name of Candidate LOU\nLOU Services\nType of Document Xrefto Docs Provided Yes No N/A Additional Documentation Requested\nPlease cite document Please check one\nand page #\n5. Renewals of LEls\n51 Are there procedures in place for: Please provide a template and a brief narrative including\nall points\n511 Notifying Legal Entity of upcoming renewal requirements?\n51.2 Providing aninterface or mechanism for the Legal Entity\ntorenew?\n5.1.3 Maintaining procedures for verifying the individual\nrequesting the LEI renewal is duly empowered to do so?\n514 Uploading the relationship information as well?\n51.5 Verifying via an authoritative source the accuracy\nof the LE-RD?\n51.6 Informing the Legal Entity about any missing or\nincorrect entries?\n5.1.7 Receiving secure payments for the renewal?\n51.8 Adjusting the LEl and relationship status as applicable\nto recognize renewal or non-renewal?\n519 Informing the Legal Entity of renewal or non-renewal status?\n5110 Uploading the changed LE-RD and the updated\nrelationship information to GLEIF?\n5.2 If you are planning to use multiple-year renewal contracts, Please provide a brief narrative including all points\ncanyou please confirm that there are procedures in place for\nensuring that the following will be performed on annual basis\nwithin the contract period:\n5.21 Informing the Legal Entity about any missing\norincorrect entries?\n5.2.2 Adjusting the LEl and relationship status as\napplicable to recognize renewal or non-renewal\n5.2.3 Informing the Legal Entity of renewal or non-renewal status?\n5.2.4 Uploading the changed LE-RD and the updated\nrelationship information to GLEIF?\n6. Check for Duplicates\n6.1 Are there procedures in place for checking against GLEIF's Check\nfor Duplicates facility and process as defined? Please explain.\n6.2 Are there procedures in place to avoid any types\nof duplicates in the system? Please explain.\nGLEIF 2021|01\n","contentLength":2041,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:27:02.643Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2021-05-31-ma-appendix-02-accreditation-checklist_final.pdf","content":"General Information for Accreditation Documentation Submission 14\n> Required Documentation to be Submitted with Checklist Responses\nF LOU Services\nLegal Name of Candidate LOU\nLOU Services\nType of Document Xref to Docs Provided Yes No N/A Additional Documentation Requested\nPlease cite document Please check one\nand page #\n7. Code Lists\n71 Are there procedures in place to ensure the implementation\nof the code lists updates within the defined timeframe?\nPlease explain.\n8. Code Lists\n8.1 Are there procedures in place for checking against GLEIF's\nData Governance Pre-Check API as defined? Please explain.\n8.2 Are there procedures in place to avoid any data quality\nfailures in the system? Please explain.\n9. MetricData Collection\n91 Do youregularly check your SLA performance in the SLA\ndashboard to ensure the timely remediation of any detected\nfailure to prevent a service level breach and in case of a service\nlevel breach to immediately remediate it?\n10. Third Party Resources /Registration Agents\n10.1 Do you currently utilize third party services such as\nregistration agents?\n\n10.11 Does your organization have a formal vetting process for Please provide a description of how you develop, issue,\nevaluating the reliability of a third party service provider monitor and update procedures carried out by the third party\nor registration agents? If so, does it consider: service provider\n\n10.2 Do you have a formal vetting process for evaluating the Please provide a brief narrative including all points\nreliability of a third party service provider or registration agents?\nIf so, does it consider:\n\n10.2.1 Financial stability\n\n10.2.2 Market reputation\n\n10.2.3 Abilities to meet LOU and GLEIF control requirements?\n\n10.2.4 Evaluating the potential risks of utilizing the services provided\n\nGLEIF 2021|01\n","contentLength":1809,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:27:02.643Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2021-05-31-ma-appendix-02-accreditation-checklist_final.pdf","content":"General Information for Accreditation Documentation Submission 15\n> Required Documentation to be Submitted with Checklist Responses\nG Required Website Items\nLegal Name of Candidate LOU\nRequired Website Items\nType of Document Xrefto Docs Provided Yes No N/A Additional Documentation Requested\nPlease cite document Please check one\nand page #\n1. After Accreditation, will your website: These items will be reviewed and documented during\nthe live walk through of the LEI system.\n11 Provide a transparent means for Legal Entities to submit\nand update registration information?\n1.2 Provide a transparent means for Legal Entities to understand\nthe process of requesting an LEI or LEI transfer?\n1.3 Incorporate all terms and requirements of GLEIF's Terms of\nUse as defined in Appendix 9b of the Master Agreement?\n1.4 Display your accreditation certificate on your LOU homepage?\n1.5 Display the GLEIF logo?\nGLEIF 2021|01\n","contentLength":913,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:27:02.643Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2021-05-31-ma-appendix-02-accreditation-checklist_final.pdf","content":"General Information for Accreditation Documentation Submission 16\n> Required Documentation to be Submitted with Checklist Responses\nH Records Management\nLegal Name of Candidate LOU\nRecords Management\nType of Document Xrefto Docs Provided Yes No N/A Additional Documentation Requested\nPlease cite document Please check one\nand page #\n1. Do you maintain a complete audit trail in compliance with Please provide a brief narrative and copies of all relevant policies\n1SO 17442 data attributions and other Common Data File\nformat elements (Level 1business card data and Level 2\nrelationship data) for all actions affecting the content\nor status of LEl records?\n2. Isaparticular function responsible for all aspects of Please provide a brief narrative and copies of all relevant policies\nrecord retention as per your established internal policies?\nWhat is your testing process and periodicity?\n3. Do you process paper records? If yes, are there specific Please provide a brief narrative and copies of all relevant policies\nretention policies regarding this?\n4. Is periodic training provided to all relevant personnel Please provide a brief narrative and copies of all relevant policies\n(including employees, contractors and temporary staff) to\nmake them aware of your Records Management procedures?\n5. Do youcreate and maintain an internal list/index of relevant Please provide a brief narrative and copies of all relevant policies\nrecords and/or storage archives which includes information\nrelating to Retention Periods and is it periodically updated?\n6. Do you ensure indexing, scanning, retrieval, storage and Please provide a brief narrative and copies of all relevant policies\ndestruction processes are documented, communicated,\nand tested at least annually?\n7. Do your historical records include:\n71 Al LEl data elements (Level 1business card data and Please provide a brief narrative and copies of all relevant policies\nLevel 2 relationship data) for the current LEI and all of\nits associated changes?\n711 If yes,dothe recordsinclude: Please provide a brief narrative and copies of all relevant policies\n- Effective date of any change(s)\n- The entity responsible for the change(s)\n- The reason for each change(s)\n- Who performed the change(s)\n- Who authorized the change(s)\n7.2 ldentification of Data Sources for each issuance/change? Please provide a brief narrative and copies of all relevant policies\n8. Do you ensure access to relevantrecords is restricted to only Please provide a brief narrative and copies of all relevant policies\nthose employees who are appropriately authorized and need\naccess to perform their duties?\n9. Do you ensure control procedures relating to the physical Please provide a brief narrative and copies of all relevant policies\nand environmental protection of relevant records, including\narchived datais in place and functioning properly?\n10. Do you ensure relevant records are only destroyed in Please provide a brief narrative and copies of all relevant policies\ncompliance with your procedures and any local or\nlegal requirements?\nGLEIF 2021|01\n","contentLength":3079,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:27:02.643Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2021-05-31-ma-appendix-02-accreditation-checklist_final.pdf","content":"General Information for Accreditation Documentation Submission 17\n> Required Documentation to be Submitted with Checklist Responses\n| Software Development | J Networks & Infrastructure\nLegal Name of Candidate LOU\nSoftware Development\nType of Document Xrefto Docs Provided Yes No N/A Additional Documentation Requested\nPlease cite document Please check one\nand page #\n1. Do youhave a document which describes the software Relevant process documents\ndevelopment tools and environment in place for the\nLEl operation?\n2. Do youhave aformal process for developing and approving Relevant process documents\nnew software?\n3. Do youhave any outsourced software development Relevant process documents\narrangements relating LE| operations?\n4. Do youhave a process in place for identifying, Relevant process documents\ntracking and correcting software errors / bugs?\n5. Doyouhave standard IT service management processes in place? Relevant process documents\nPlease provide evidence that these are followed and\nmaintained as needed. This would include a patching process\nand upgrade/ update policies and procedures.\nNetworks & Infrastructure\nType of Document Xrefto Docs Provided Yes No N/A Additional Documentation Requested\nPlease cite document Please check one\nand page #\n1. Please provide anetwork diagram showing network Relevant process documents and technical diagrams\nentry points, firewalls, servers etc..\n2. Please describe the current server/hosting environment? Relevant process documents and technical diagrams\nIs it hosted, in-house, via a third party, etc.?\nDescribe the use of any cloud-based resources such\nas Amazon Web Services or Microsoft Azure.\n3. Do you perform any monitoring over the LEl-related Relevant process documents and technical diagrams\nITinfrastructure?\n4. Are there any redundancies built into the hosting platform Relevant process documents and technical diagrams\nand hardware?\n5. Hasthere been any unscheduled network or system Relevant process documents and technical diagrams\ndowntime in the past twelve months?\n6. Do youhave acurrent disaster recovery and/or business Relevant process documents, results of last testing\ncontinuity plan in place? How often is it tested? cycle and summary of any incidents\nHas the plan been invoked during the past 3 operating years?\n7. Do youhave structured backup policies and practices? Relevant process documents\nGLEIF 2021|01\n","contentLength":2390,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:27:02.643Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2021-05-31-ma-appendix-02-accreditation-checklist_final.pdf","content":"General Information for Accreditation Documentation Submission 18\n> Required Documentation to be Submitted with Checklist Responses\nK IT Security & Compliance\nLegal Name of Candidate LOU\nSecurity & Compliance\nType of Document Xrefto Docs Provided Yes No N/A Additional Documentation Requested\nPlease cite document Please check one\nand page #\n1. Haveyou performed or engaged a third party to test Relevant process documents and most current reports\nsystem vulnerability, intrusion detection or perform\npenetration testing? Please list all vendors as applicable.\n2. Do you maintain firewall(s)? Relevant process documents and technical diagrams;\nplease describe its purpose and your monitoring procedures.\n3. Isaccesstosource code and other critical resources Relevant process documents and technical diagrams\n(documents, contracts etc.) monitored and tracked?\n4. Are there any users that are not subject to the standard Relevant process documents and list of exceptions\nsecurity policies of the Company/Business Unit/Department?\n5. Are there non-employees who have access to critical Relevant process documents and list of exceptions\ncompany information (source code, documentation etc.)?\n6. Are terminated employees/contractors removed from Relevant process documents and technical diagrams\naccess to LOU systems/resources in a timely manner?\n7. Do youhave password policies for the networks and systems, Relevant process documents, technical diagrams\nincluding length and complexity, and any expiration policies? and most current reports\n8. Do you have procedures in place to identify, Relevant process documents, technical diagrams\nreport and remediate any security breaches? and most current reports\n9. Do you have any physical access restrictions to Relevant process documents, technical diagrams\ncritical company assets such as servers and data? and most current reports\n10. Have you had any IT operational or security audits Relevant process documents and results of last testing cycle\n(i. e. SSAE 16, SAS70) performed in the past three years?\n1. Have you had any LEl-related security breaches Relevant process documents, technical diagrams\ninthe past five years? and most current reports\n12. Do you have your compliance activities in place to ensure Relevant process documents. Please specify which data privacy\ncompliance with respect to all applicable Data Privacy Laws? laws you are enforcing and confirm that you are meeting the\nrequirements documented in Appendix 11 of the\nMaster Agreement.\nGLEIF 2021|01\n","contentLength":2518,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:27:02.643Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2021-05-31-ma-appendix-02-accreditation-checklist_final.pdf","content":"General Information for Accreditation Documentation Submission 19\n> Required Documentation to be Submitted with Checklist Responses\nL Data Quality Management\nLegal Name of Candidate LOU\nData Quality Management\nType of Document Xrefto Docs Provided Yes No N/A Additional Documentation Requested\nPlease cite document Please check one\nand page #\n1. General and Participation in Continuous Improvement\n11 Does your organization have a governance framework\nthat enables it to adhere to GLEIS standards? If yes, please\nexplain how this governance framework is structured.\n1.2 Does your organization have a continuous improvement process\nfor data quality in place? If yes, please explain what the process\nstepsare.\n1.3 Does your organization have a continuous improvement process\nfor adapting to procedural changes as required for adjustments\nto ROC or GLEIF standard and operating principles?\nPlease explain.\n1.4 Does your organization have a defined implementation period\nexpectation for different types of adjustments? Please explain.\n2. DataValidation\n21 Do you have an established data library that defines Please provide a brief narrative\nproper values for fields entered in a LEl request?\n2.2 Do you prevent unlikely or incorrect data in submissions Please provide a brief narrative\nof LEl requests?\n2.3 Do you maintain procedures for :\n2.31 Verifying the LE-RD based on the Legal Entity Please provide a brief narrative\njurisdiction, entity category and legal form?\n2.3.2 Ensuring an up-to-date list of authoritative sources used Please provide a brief narrative including all points\nfor verification is maintained, accessible and usable at all\ntimes with no restriction for all below services?\na. Issue new LEI\nb. Enter Legal Entity Events\nc. Manage Challenges\nd. Transfer of LEls and LE-RD\ne. Renewals of LEIs (incl. multiple-year renewal contracts)\n2.3.3 Do you have sufficient proficiency for understanding or Please list all languages\ninterpreting authoritative sources?\n2.3.4 Do you use other sources not listed in the GLEIF\nRegistration Authorities list for verification/validation?\nIf yes, please specify.\n2.4 Do you have sufficient language proficiency in the jurisdictions\nyou are applying for understanding and interpreting the\nfollowing? If yes, please list all languages.\n2.41 The information you receive fromthe legal entity?\n2.4.2 Theinformation provided in the corresponding\nauthoritative source for validation?\nGLEIF 2021|01\n","contentLength":2443,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:27:02.643Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2021-05-31-ma-appendix-02-accreditation-checklist_final.pdf","content":"General Information for Accreditation Documentation Submission 20\n> Required Documentation to be Submitted with Checklist Responses\nL Data Quality Management\nLegal Name of Candidate LOU\nData Quality Management\nType of Document Xrefto Docs Provided Yes No N/A Additional Documentation Requested\nPlease cite document Please check one\nand page #\n2.5 Do you have validation procedures in place for Please provide a brief narrative including all points\n2.51 Verifying that a Legal Entity is eligible for an LEI code?\n2.5.2 Provision of corresponding language tags for the\nset of specified fields?\n2.5.3 Incorporating Transliteration data for all below services?\na. Issue new LEI\nb. Enter Legal Entity Events\nc. Manage Challenges\nd. Transfer of LEls and LE-RD\ne. Renewals of LEIs (incl. multiple-year renewal contracts)\n2.5.4 Ensuring that LEls are only issued when\nvalidation process is successfully completed?\n2.5.5 Verifying the LEI Record Set is compliant\nwith the Common Data File (CDF) format\n(as published per www.gleif.org)\n2.5.6 Ensuring a LEI complies with GLEIF Operational\nand Technical Standards (Data Quality Rule Setting)\nduring all below services:\na. Issue new LEI\nb. Enter Legal Entity Events\nc. Manage Challenges\nd. Transfer of LEls and LE-RD\ne. Renewals of LEIs (incl. multiple-year renewal contracts)\n2.5.7 Researching the content of the challenge and verifying\nthe challenge via an authoritative data source?\nPlease explain.\n2.6 Do you comply with ISO 17442? Please provide a brief narrative.\nGLEIF 2021|01\n","contentLength":1522,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:27:02.643Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2021-05-31-ma-appendix-02-accreditation-checklist_final.pdf","content":"General Information for Accreditation Documentation Submission 3\n> Required Documentation to be Submitted with Accreditation Plan\nA Contact Details\nLegal Name of Applicant LOU | Note:\nThis name must match your LEIl reference Data VAT No. if applicable\nURL of Applicant LOU Submission Date (YYYY-MM-DD)\nParent/Grandparent/Owner/Governing Organization if applicable Accreditation Plan Checklist\nLEI of Parent/Grandparent/Governing Organization if applicable First Submission Revised Submission\nInternal Project Manager Authorized Representative\nName Name\nTitle Title\nEmail Email\nPhone Phone\nKey Contact Operations Key Contact Finance\nName Name\nTitle Title\nEmail Email\nPhone Phone\nPlease ensure you have: Yes No In Progress\n¢ Provided your LEl below\n¢ Provided a Notarized Copy of the Authorized Representative’s Signature\nIn submitting this document, | confirm that, to the best of my knowledge, my organization is in compliance with or is able\nto become compliant with the requirements of GLEIF reflected in the Master Agreement and its appendices, Accreditation\nManual and Checklist and Service Level Agreement as of the date of this document unless otherwise noted.\nAuthorizing Representative Signature* Date (YYYY-MM-DD)\nE-Signature\nName\nTitle\nEmail LEI (20 Alphanumeric Characters)\nPhone\n\n* Please note: the Authorized Representative may sign this form physically or electronically\n\nGLEIF 2021/01\n","contentLength":1400,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:27:02.643Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2021-05-31-ma-appendix-02-accreditation-checklist_final.pdf","content":"General Information for Accreditation Documentation Submission 21\n> Required Documentation to be Submitted with Checklist Responses\nL Data Quality Management\nLegal Name of Candidate LOU\nData Quality Management\nType of Document Xrefto Docs Provided Yes No N/A Additional Documentation Requested\nPlease cite document Please check one\nand page #\n3. Check for Duplicates Please provide a brief narrative including all points\nDo you have procedures in place for handling\neach of the following\n31 Checking that the LEI code does not exist already in\nthe Global LEI Index?\n3.2 Checking, that the legal entity does not have an\nassigned LEI code already?\n3.3 Checking that no duplicate relationships exists?\n3.4 Identifying Exclusivity Violations by using automated routines?\n3.5 Checking the received feedback from GLEIF's Check\nfor Duplicates facility?\n3.6 Ensuring that all newly issued LEls are processed\nby GLEIF's Check for Duplicates facility?\n4. Data Governance\n4.1 Have you integrated the Data Governance Pre-Check API Please provide a brief narrative.\ninto your processes? If yes, please describe briefly.\n4.2 Do you process the received feedback from GLEIF's Data\nGovernance Pre-Check APl and take actions based on this\nfeedback? Please explain briefly.\n4.3 Do you ensure that all newly issued and updated LEls are\nprocessed by GLEIF’'s Data Governance API to fulfil the\nCompleteness Service Level Target? Please explain briefly.\n5. Uploading of LEIs and LE-RD Please provide a brief narrative including all points\nDo you have procedures in place to ensure: and your relevant procedures documentation.\n51 Timely response to any GLEIF communication concerning doubts,\ninconsistencies, or data quality issues of the uploaded data?\n5.2 Uploading LEl records at least daily?\n5.3 Confirmation to GLEIF via the GLEIF interface/ If yes, please explain the process control with respect\ncommunications protocol indicating a daily “live signal” to monitoring this condition.\ngiven no LEl activity occurs?\nGLEIF 2021|01\n","contentLength":2011,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:27:02.643Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2021-05-31-ma-appendix-02-accreditation-checklist_final.pdf","content":"G LE I F Enabling global identity\nProtecting digital trust\nGlobal Legal Entity Identifier Foundation (GLEIF)\nSt. Alban-Vorstadt 12, PO Box\n4002 Basel\nSwitzerland\naccreditation@gleif.org\ngleif.org\nChairman of the Board: Teresa Glasser\nChief Executive Officer: Stephan Wolf\n© 2022 All rights reserved\nGLEIF 2021/01\n","contentLength":313,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:27:02.643Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2021-05-31-ma-appendix-02-accreditation-checklist_final.pdf","content":"General Information for Accreditation Documentation Submission 4\n> Required Documentation to be Submitted with Accreditation Plan\nB Entity Structure\nLegal Name of Applicant LOU\nOrganization Structure\nParent/Governing Organization Applicant LOU\nGovernment Government\nPrivate - For Profit Private - For Profit\nPrivate - NonProfit Private - NonProfit\nPublic-Listed Public-Listed\nPublic-Non-Listed Public-Non-Listed\nNot Applicable - there is no parent/owner Other\nOther\nAccounting Framework Check as many as applicable Internal Controls Framework Check as many as applicable\nUS GAAP COSO\nIFRS COBIT\nTransitioning to IFRS 1SO*\nOther - Please specify* Other - Please specify**\nUnknown/Not Applicable Unknown/Not Applicable\n+Comments (if any) * Please note the applicable standard and provide the certificate if you have been certified\n*Comments (if any)\nFISCAL YEAR (Please provide your business calendar) Payment Currency Please choose one\nusD\n- EUR\nDate (YYYY-MM-DD) Date (YYYY-MM-DD)\nCHF\n(@Pisssaprovidalrformationiralotad toParstiONanandlos LE| Opatotions ssnated )\nGLEIF 2021|01\n","contentLength":1078,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:27:02.643Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2021-05-31-ma-appendix-02-accreditation-checklist_final.pdf","content":"General Information for Accreditation Documentation Submission 5\n> Required Documentation to be Submitted with Accreditation Plan\nB Entity Structure\nLegal Name of Applicant LOU\n\nJurisdiction - Self-Registration\n\nPlease complete the Registry Inventory Spreadsheet Form and include it in your Accreditation Plan submission. The form is on our website.\n\nStatement of Beneficial Ownership\n\nPlease list all Entities which have > 20 % Entity LEI# %\n\nownership stake in your organization\n\nPotential Taxation Requirements\n\nPlease detail your taxation strategy as it relates to your operations and LOU services\n\nGLEIF 2021|01\n","contentLength":617,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:27:02.643Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2021-05-31-ma-appendix-02-accreditation-checklist_final.pdf","content":"General Information for Accreditation Documentation Submission 6\n> Required Documentation to be Submitted with Accreditation Plan\nB Entity Structure\nLegal Name of Applicant LOU\nExternal Audit Firm (if applicable) Comments (if any)\nFirst Name\nYes No Not Applicable\n\nAre annual financial statements issued?\n\nParent Level\n\nLOU Level\nIs an annual management letter/report issued which relate to LEl services?\nAre your financial statements public record?\n\nParent Level?\n\nLOU Level?\nGovernmental/Regulatory Auditors (if applicable) Comments (if any)\nOrganization\n\nYes No Not Applicable\n\nAre annual financial statements issued?\n\nParent Level\n\nLOU Level\nAre periodic management letters/reportsissued which could relate to LEI services?\n\nParent Level\n\nLOU Level\nAre these reports public record?\n\nGLEIF 2021|01\n","contentLength":801,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:27:02.643Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2021-05-31-ma-appendix-02-accreditation-checklist_final.pdf","content":"General Information for Accreditation Documentation Submission 7\n> Required Documentation to be Submitted with Accreditation Plan\nB Entity Structure\nInternal Audit Group (if applicable) Comments (if any)\nDepartment\nYes No Not Applicable\nAre financial/operational/IT scope audits performed?\nParent Level\nLOU Level\nAre periodic management letters/reportsissued which could relate to LEI services?\nAre these reports public record?\nExternal Consultants (if applicable) Comments (if any)\nYes No Not Applicable\nHave you engaged a third party to evaluate your business and/or IT Parent Lou Both\noperations/controls?\nAre any of these reports SSAE16 SOC Type 1 or equivalent? Parent Lou Both\nAre any of these reports SSAE16 SOC Type 2 or equivalent? Parent Lou Both\nAre any of these reports ISAE3402 or equivalent? Parent Lou Both\nAre any of these reports public record? Parent Lou Both\nPlease specify the provider of service(s):\nComments (if any)\nPlease note:\nFor any third party reports submitted for Accreditation\nconsideration, please indicate which specific LEl operations and\nquestionnaire sections/ items it addresses. In these cases, the LOU\ndoes not need to provide additional supporting documentation\nunless requested by GLEIF.\nGLEIF 2021|01\n","contentLength":1243,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:27:02.643Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2021-05-31-ma-appendix-02-accreditation-checklist_final.pdf","content":"General Information for Accreditation Documentation Submission 8\n> Required Documentation to be Submitted with Accreditation Plan\nC Organization Structure\nLegal Name of Applicant LOU\nGovern- Private - Private- Public- Public\nOrganization Structure ment For Profit NonProfit Listed Non-Listed\nType of Document Applicability Applicant LOU Response\nIncluded Not Not Not\nincluded included applicable\ncannot be\nprovided\ndue to con-\nfidentiality\n1. Prior Year Financial Statements (Parent/Owner) N Y Y Y Y\n2. Auditor/Regulator Letter(s)/Report(s) Y N N Y Y\n(Parent/Owner & LEI Ops)\n3. Most Recent Annual Report N Y Y Y Y\n4. Current Organization Chart for all LElI Operations and Y Y Y Y Y\ncomplete list of all relevant third party service providers.\n5. Relevant Operational Procedures (LEI Ops only) Y Y Y Y Y\n6. Relevant Technical Procedures (LEI Ops only) Y Y Y Y Y\n7. Relevant Compliance Procedures (LEI Ops only) Y Y Y Y Y\n8. Records Retention Policy (Parent/Owner & LEI Ops) Y Y Y Y Y\n9. Relevant third party and Vendor Agreements (LEI Ops only) Y Y Y Y Y\nComments\nPlease note:\nDocuments 1-3 should be provided as part of the Accreditation\nPlan submission. The remaining examples will support your responses\nin other sections of the Checklist and you should gather current\nversions as applicable and provide to GLEIF after the signing of\nthe Master Agreement.\nGLEIF 2021/01\n","contentLength":1374,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:27:02.644Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2021-05-31-ma-appendix-02-accreditation-checklist_final.pdf","content":"General Information for Accreditation Documentation Submission 9\n> Required Information to be Submitted with Checklist Responses\nD Financial Dataq, Audits & General Governance\nLegal Name of Candidate LOU\nFinancial Data, Audits & General Governance\nType of Document Xrefto Docs Provided Yes No N/A Additional Documentation Requested\nPlease cite document Please check one\nand page #\n1. General Questions - Going Concern - Parent and LOU\n11 Hasanindependent audit of your financial statements Audited financial statements (income statement, balance sheet,\nbeen performed for your last completed fiscal year? cash flows statement) for prior year\nIf your organization does not have audited statements, please\nprovide your prior and current financials as maintained. Please\nexplain how these statements are validated and reported.\n1.2 Has your audit firm/government regulatory agencies issued any Final Management Letters with management responses\nmanagement letters relating to LEI operations over the past as applicable.\nthree years? - This would include commentary relating to internal\ncontrols, accounting controls and methods of procedures.\n1.3 Do you have aninternal audit function?\n1.3.1 Have they performed any audits within your organization Relevant issued internal audit reports which relate to LEI\nrelating to LEI operations? operations in the past 2 years\nPlease include management responses.\n1.4 Have you been subject to any regulatory audits/reviews Relevant comment letters, audit reports (qualified and\ninyour current year’s operations? unqualified opinions) and management responses as applicable\n1.5 Do you have aformal LEI Operations Budget for this year Please provide budgets as per GLEIF instructions and\nand next year's operations? explain financial assumptions, volume estimations, operating\nbudget, expenses etc. - soft copies should be submitted\nwherever possible.\n2. General Questions - Going Concern - Parent and LOU\n21 Are third party services (e. g. augmented staff, cloud services, Summary of vendor contracts and detailed description of\ndata centers) utilized in order to provide LEl services? services provided; copies of contracts may be requested\n2.2 Doyou have intellectual property and/or proprietary methods/ Provide a description of the asset and its use with respect\nsystems which are employed in the delivery of LEI services? to LEl services\n2.3 Are you currently involved with any litigation matters Provide a summary of all relevant litigation, arbitration,\nwhich could effect LEI services? claims and proceedings\n2.4 Are you subject to regulatory compliance Please list all relevant governmental regulatory agencies\nrequirementswhich could effect LEI operations? and the applicable regulations with respect of LEI activities\nGLEIF 2021|01\n","contentLength":2778,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:27:02.644Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2021-05-31-ma-appendix-02-accreditation-checklist_final.pdf","content":"General Information for Accreditation Documentation Submission 10\n> Required Documentation to be Submitted with Checklist Responses\nE Cost Recovery Requirements\nLegal Name of Candidate LOU\nCost Recovery Requirements\nType of Document Xrefto Docs Provided Yes No N/A Additional Documentation Requested\nPlease cite document Please check one\nand page #\n1. Do youclearly understand the technical requirements Please summarize any actual or contemplated changes\nof the Cost Recovery Principle? to the GLEIF-approved Plan since the date of Master\nAgreement signing.\n2. Do you confirmthat the LOU business operations will comply Please summarize any actual or contemplated changes\nwith the Cost Recovery Principle at and after accreditation? to the GLEIF-approved Plan since the date of Master\nAgreement signing.\n3. Do you confirmthat the LOU business operations will comply Please summarize any actual or contemplated changes\nwith the Cost Recovery Principle at and after to the GLEIF-approved Plan since the date of Master\nAgreement signing.\n4. Do you clearly understand the requirements of the annual Please summarize any actual or contemplated changes\nverification process and the independent cost recovery audit? to the GLEIF-approved Plan since the date of Master\nAgreement signing.\n5. Please confirm that your budget information as submitted\nconforms to the following definitions:\nDirect Cost: Specifially allocable to a particular business\nthat can be accurately and clearly traced, with little\neffort, to said business activity, including intercompany\ntransfer fees based on “arm’s lengths” terms and fees\npaid to third party service providers assisting the\nperformance of Services agreed in the Service Level\nAgreement (Appendix 06). Only the services mentioned\nin the above definition should be considered to be the\ncost objects for the purpose of calculating direct costs.\nTypes of Direct Cost:\nDedicated LOU Personnel costs: e.g. salary overtime,\nrecruitment costs, Travel, Training\nDedicated LOU Resources: e.g. IT hardware/software/\nsupplies, telephone/internet, stationary & postage.\nDedicated LOU Support: e.g. Marketing, monitoring,\nlegal, audit costs, GLEIF fees.\nA Candidate LOU must submit three-years operating budget information Please note the following:\nin Excel format for Cost Recovery review by GLEIF. A specific definition of\neach cost category and its relevance to LEl operations must be included. @ Do not include any indirect/overhead costs as part of LEI direct\ncosts. This includes costs such as general administrative functions\nPlease provide detailed (line by line) disclosure of DIRECT COSTS and management time. The overarching 100 % uplift factoris\n(defined above) that can be specifically allocated to the Services applied to compensation for these costs.\noutlined in Section F of this document.\n@ For costsrelating to intercompany transfer fees and fees paid\nIt needs to be clearly demonstrated that these costs are direct to third party service providers, please provide detailed cost\ncosts as defined. information by service and provider separately from the Direct\nCost data. Do not include these costs in the LEI direct costs data.\n@ Alldata provided is subject to inquiry and/or audit at\nGLEIF’s discretion.\nGLEIF 2021|01\n","contentLength":3259,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:27:02.644Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-6-30-ma-appendix-02-accreditation-manual.pdf","content":"GLEIF | oo cioial st\nA ditati\nSupplemental user guide in support\nof the accreditation process.\nGLEIF\nACCREDITED\n","contentLength":112,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:28:07.635Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-6-30-ma-appendix-02-accreditation-manual.pdf","content":"The Accreditation Manual is provided to\nApplicant LOUs and Candidate LOUs as\na supplemental user guide in support of\nthe accreditation process.\n\nThe contents of this document do not\nsupersede interpret or change in any\nway the terms of the Master Agreement.\nIn all cases, the Master Agreement is the\nprevailing document in the event of any\ncontradictions contained in this Manual.\nIn using this document, the reader accepts\nand understands these conditions.\n","contentLength":458,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:28:07.635Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-6-30-ma-appendix-02-accreditation-manual.pdf","content":"Ll\n\nChapter 3:\nAccreditation Process\n3.1 Overview\nThe Accreditation Process is in place to ensure that all Applicant/Candidate LOUs meet the\nminimum financial and operational control requirements of the GLEIF and that a local accredited\noperating unit’s control environment is reasonable to protect the integrity of LElI operations.\nThroughout the Accreditation Process, the Applicant/Candidate LOU is obliged to inform GLEIF\nwithout undue delay about any events or developments which affect the accuracy of information\nprovided to GLEIF such as changes in legal status e.g. form of incorporation, change of signatory\npower of its officers and the like. Such changes could impact the Accreditation Process and/or\nany agreed time schedule.\nApplicant and Candidate LOUs will be submitting all accreditation materials via GLEIF's customer\nportal and LOU Communications Portal. Details for accessing both tools the portal will be provided\nduring process orientation after a non-disclosure agreement has been signed. All documents\nreceived will be date stamped and a receipt sent to the submitter. Applicant/Candidate LOUs\nmay not submit documents via email directly to GLEIF, unless requested, so that a complete audit\ntrail for all documents can be maintained. They will be able to submit documents throughout\nthe accreditation process, however, once documents are designated as ‘FINAL, the LOU\nCommunications Portal will be restricted to read-only for users and any proposed changes\nwill need to be discussed with and approved by GLEIF before taking any action.\nThe Accreditation Process is comprised of six steps. During the first three steps, the Applicant\nLOU is referred to as an Applicant. At this point, no formal contract has been signed and the\nApplicant LOU is gaining an understanding of the GLEIF control requirements and reviewing its\nown operations to determine the feasibility of becoming a LOU. Once the Master Agreement\nhas been signed, the Applicant LOU becomes a Candidate LOU. The Candidate LOU is focused\non successfully completing the Accreditation Process and obtaining an Accreditation Certificate.\nPlease note that for many questions, the Applicant/Candidate LOU is required to submit\nsupporting documentation as part of their response. The Applicant/Candidate LOU should only\nsubmit documentation relevant to the question being asked. This may include full documentation\nor excerpts from manuals, policy statements and the like. All such documents (full or excerpt)\nmust be translated into English for submission.\n\nThe Accreditation Process is focused only on LEI-related operations and processes\n\nwithin the Applicant/Candidate LOU'’s organization. It is critical that Checklist\n\nresponses and the corresponding documentation presented address this specific\n\noperational area.\n\n©GLEIF2019 1911 VO1\n","contentLength":2822,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:28:07.635Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-6-30-ma-appendix-02-accreditation-manual.pdf","content":"Chapter 3: Accreditation Process 12\n3.2 Flowchart\nThe following is the standard Accreditation Process flow represented as a swim lane chart\nwith associated roles.\nAccreditation Process Flow\nStart\nAccreditation\nDevelop\nAccreditation Plan\n>\n[e]\n-\n-\n(=\no\n.\no\no A\n<\nAgree on\nAccreditation Plan\n\"EI' Sign Master\nfp' Agreement\nAssess Accreditation\nDocumentation\nImplement\nAccreditation\nRequirements\n>\n[e]\n-\n[\n-\n[\n3\nel\n[=\nO\no\n©GLEIF2019 1911VO1\n","contentLength":439,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:28:07.635Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-6-30-ma-appendix-02-accreditation-manual.pdf","content":"Chapter 3: Accreditation Process 13\n3.3 Process Flow Steps\nRole Step Description\nApplicant 1 Start Accreditation\nGLEIF's requirements are explained in the following key\ndocuments and the Applicant LOU should review each in\ndetail to understand service and control expectations.\nIn order to begin this process, the Applicant LOU\nmust provide a non-disclosure agreement signed by\nan authorized representative of the organization. The\n‘Authorized Representative’ is defined as an individual\nwith sufficient authority to enter into contracts, such as\nthe Non-Disclosure Agreement or Master Agreement, with\nGLEIF. This individual’s authority to represent the Applicant\nmust be verifiable via available public sources. GLEIF will\npermit the Authorized Representative role to be delegated\nto an appropriate person in an Applicant/Candidate’s\norganization upon receipt of a letter from an Officer of\nthat organization making such a request and identifying\na single individual for this designation. The non-disclosure\nform can be found on the GLEIF website.\n\no Master Agreement - This is the contract that sets\nout the rights and obligations of GLEIF and the LOU.\nIt is executed between the Applicant LOU and GLEIF\nafter joint agreement on the Accreditation Plan.\n\no Accreditation Manual - This is an Appendix to the\nMaster Agreement which explains the Accreditation\nprocess, procedures and requirements.\n\no Accreditation Checklist - This is an Appendix to the\nMaster Agreement and is used by the Applicant LOU\nto assess its operational status regarding GLEIF's\nrequirements and decide if it wishes to pursue\nbecoming a local operating unit.\n\nIt is also the key tool for the Candidate LOU\ncompleting the Accreditation Documentation. The\nChecklist documents the minimum levels of internal\ncontrols expected to be in place and functioning\neffectively within an accredited local operating unit.\n\no Service Level Agreement (SLA) - This document\ndetails services to be delivered and performance\nmetrics which an Accredited LOU must meet to\nachieve and maintain its accreditation.\n\nThese materials in addition to others are located on GLEIF\nwebsite: www.gleif.org\n©GLEIF2019 1911 VO1\n","contentLength":2169,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:28:07.635Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-6-30-ma-appendix-02-accreditation-manual.pdf","content":"Chapter 3: Accreditation Process 14\n3.3 Process Flow Steps\nRole Step Description\nApplicant LOU 2 Develop Accreditation Plan\n\nOnce the Applicant LOU has reviewed and considered\nGLEIF's requirements, and decided to move forward, an\nAccreditation Plan is developed. This is the key document\nprepared by the Applicant LOU for initial assessment.\nThe Plan is a free-text format and the Applicant LOU\ndetermines the appropriate level of detail. The Applicant\nLOU must address six key points:\n\no Who - Describe the nature of organization applying\n- what are its key services/customers, market\nposition, size/revenue, competition.\n\no Why - Describe the reason(s) supporting the\norganization’s desire to be a LEl-issuer — what are\nkey business drivers, strategic objectives and plans,\neconomic model, business plan?\n\n© What - Describe how you envision your LOU in\noperation. What countries do you support? Do\nyou plan to use third party services or registration\nagents? How do you plan to grow the business?\nWhere do you see your LOU in 5 years? How do\nyou see your LOU operations fitting in with GLEIF's\nstrategy and vision? Do you have a strategic\nplan? What marketing resources/plans have you\ndeveloped to support your vision?\n\no Where - Identification of all jurisdictions in which the\nlocal operating unit plans to serve and the reference\nsources which will be used to validate LEls.\n\no How - During the planning process, the Applicant\nLOU will have reviewed the details of the\nAccreditation Checklist and needs to analyze\nhow well it presently complies with the expected\ncontrols and how remediation of control gaps will\nbe addressed.\n\no Timeframe - Based upon an understanding of the\nrequirements, what is the preparation timeframe\nfor completion and submission to GLEIF of the\nAccreditation Documentation?\n\nApplicant LOUs must submit the “Applicant Plan Checklist”\nwith the Plan submission. This additional checklist catalogs\nall the required components of the Plan. All components\nare required in order for GLEIF to consider a Plan complete\nand ready for review. This form can be found on our\nwebsite. The Applicant is responsible for advising GLEIF\nthat their materials are ready for review.\n©GLEIF2019 1911 VO1\n","contentLength":2213,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:28:07.635Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-6-30-ma-appendix-02-accreditation-manual.pdf","content":"Chapter 3: Accreditation Process 15\n3.3 Process Flow Steps\nRole Step Description\nGLEIF 3 Agree on Accreditation Plan\n\nApplicant LOU GLEIF will review the Accreditation Plan and any supporting\nmaterials submitted in order to evaluate the readiness of\nthe Applicant LOU to move forward with the Accreditation\nProcess. As part of this evaluation, the Applicant LOU may\nschedule a review session to discuss its submission. This\nreview session will be planned for one hour’s duration and\nminimal extra time will be allotted at the discretion\nof GLEIF. This is to ensure fairness to all Applicant LOUs.\nGLEIF will complete its evaluation process within forty-five\n(45) business days of receipt of the final Plan. In order to\ncomplete this, GLEIF may request a review session with the\nApplicant which will be scheduled at a mutually agreeable\ndate and time.\nIf, after this discussion, it is agreed that an on-site visit\nis required, the requesting party will bear the costs.\nOnce it is agreed that the Accreditation Plan is acceptable\nand meets all review criteria, e.g., synergy with GLEIF\nstrategy, going concern, compliance with all GLEIF internal\ncontrol requirements including also the cost recovery\nprinciple, etc., a recommendation is presented to the\nGLEIF CEO and Board. Once approved, the Applicant LOU\nmoves on to Step 4.\n\nGLEIF L Sign Master Agreement\n\nApplicant LOU If the Applicant LOU wishes to continue the process,\nthe Master Agreement must be executed.\nOnce the Master Agreement has been countersigned,\nthe Applicant LOU then becomes a ‘Candidate LOU’,\nit is then considered a “Candidate”. GLEIF publishes a\nlist of all Candidate LOUs on GLEIF's website for full\ndisclosure purposes.\n\n©GLEIF2019 1911 VO1\n","contentLength":1716,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:28:07.635Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-6-30-ma-appendix-02-accreditation-manual.pdf","content":"Chapter 3: Accreditation Process 16\n3.3 Process Flow Steps\nRole Step Description\nCandidate LOU 5 Implement Accreditation Requirements\nThe Candidate LOU will now focus on the information\ngathering process utilizing the Accreditation Checklist.\nThe Accreditation Checklist is the key tool for completing\nthe Accreditation Documentation. It is designed to reflect\nthe requirements of the MA. The Checklist is included in\nthe Master Agreement. It is divided into twelve (12)\nseparate sections all of which need to be completed.\nThroughout the Checklist, additional supporting\ndocumentation is requested in order to validate and/or\nsupport the Candidate LOU’s responses. These requests\nare noted under the “Additional Documentation Requested”\ncolumn and, in some cases, a suggested example is noted.\nThese are provided for illustrative purposes only and the\nCandidate LOU is free to provide whatever documentation\nit believes to be appropriate and relevant.\nThe Candidate LOU must complete its analysis and\nassessment of compliance with GLEIF requirements\nand submit its Accreditation Documentation within\nsix (6) months (180 calendar days) of the Effective\nDate of its MA.\nThe Candidate LOU must clearly reference how\nsupporting documents address specific questions\nin the Accreditation Checklist.\nIn case where certain questions of the accreditation\nChecklist document can be skipped, as per the Appendix\n02-Certificate List, the Candidate LOU must clearly\nreference the certificate name in the “Additional\nDocumentation Requested” column space.\nThroughout the development of its Accreditation\nDocumentation, the Candidate LOU is obliged to\ninform GLEIF, without undue delay, about any events\nor developments covered by, or having potential\nimpact on, the agreed Accreditation Plan.\nThe Candidate is responsible for advising GLEIF that\ntheir materials are ready for review. Any Accreditation\nDocumentation submitted must be properly authorized\nby the Candidate LOU'’s Authorized Representative(s)\nas identified as part of Step 1.\n©GLEIF2019 1911 VO1\n","contentLength":2047,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:28:07.635Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-6-30-ma-appendix-02-accreditation-manual.pdf","content":"Chapter 3: Accreditation Process 17\n3.3 Process Flow Steps\nRole Step Description\nGLEIF 6a Assess Accreditation Documentation\nGLEIF has a maximum of ninety (90) calendar days to\nreview the Accreditation Documentation once a complete,\nauthorized submission is received.\nUpon receipt, GLEIF is responsible for reviewing\nthe completeness of Accreditation Documentation.\nThis includes the Checklist and all supporting materials\npresented by the Candidate LOU.\nUpon initial review, if all required materials have been\nsubmitted, the Documentation will be moved forward\nfor detailed assessment. If not, it may be returned to\nthe Candidate LOU with a full explanation so that it can\nbe resubmitted if the Candidate LOU chooses to do so.\nExcept if agreed in advance in writing, the Candidate LOU\nmay not submit documents separately; it is expected the\nAccreditation Documentation will be submitted as a single\nsubmission to GLEIF.\nIf the Candidate LOU repeatedly submits incomplete\nAccreditation Documentation, GLEIF may terminate\nwith immediate effect the Master Agreement.\n©GLEIF2019 1911 VO1\n","contentLength":1086,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:28:07.635Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-6-30-ma-appendix-02-accreditation-manual.pdf","content":"Chapter 3: Accreditation Process 18\n3.3 Process Flow Steps\nRole Step Description\n\nGLEIF 6b As part of the Accreditation Process, GLEIF will be\nperforming data quality checks and reviewing the\nresults of test cases provided to the Candidate LOU.\nCandidate LOUs will be required to execute the GLEIF-\ndeveloped test cases using their current LEI system and\nprovide the results to GLEIF. Candidate LOUs will also\nbe required to test and verify technical capabilities\nto connect and upload data to the GLEIF network.\nGeneral comments relating to test results will be\nshared with the Candidate LOU.\nThe level and type of data quality testing will vary\nbased upon the stage of maturity of the Candidate LOU.\nApplicants should carefully consider the scope of\njurisdictional locations as well as the scope of entities\n(non-fund entities, fund entities) for which they desire\nto offer LEl services.\nDepending on the jurisdictions and the type of entities\nselected to serve in each jurisdiction, GLEIF will prepare\nand provide test cases. On a case-by-case basis, GLEIF will\nassess how many test cases Candidates shall receive but\nas a minimum requirement, Candidates need to successfully\ncomplete one test case for each jurisdiction indicated in\ntheir application form.\nOnce the accreditation program is successfully completed,\nAccredited LEl Issuers (LOUs) may offer LEI services for\neither non-fund entities only or for both non-fund and\nfund entities in the respective jurisdiction(s). The\nAccreditation Certificate will specify all jurisdictions as\nwell as the type of entities per jurisdiction which have\nbeen accredited by GLEIF.\nAfter accreditation, if a LOU wishes to add new\njurisdictions to its portfolio or to add LEl services for fund\nentities in a given jurisdiction, the LOU must make a formal\nrequest to GLEIF listing the jurisdictions to be added, the\nrespective registry sources to be used as well as the entity\ntypes to be served per jurisdiction. GLEIF will review the\nrequest and provide test cases for processing. As in the\ninitial accreditation process, the LOU must successfully\ncomplete the test case(s) before (fund or non-fund) LEls\nmay be issued or maintained for these jurisdictions.\n\n©GLEIF2019 1911 VO1\n","contentLength":2224,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:28:07.635Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-6-30-ma-appendix-02-accreditation-manual.pdf","content":"Chapter 3: Accreditation Process 19\n3.3 Process Flow Steps\nRole Step Description\nGLEIF 6c Upon successful completion of the activities in 6a and 6b,\nGLEIF will work with the Candidate to ensure that they are\nprepared to provide LEl services in concert with GLEIF's\ninfrastructure and protocols. This activity is referred to\nas “onboarding”. These activities focus on the integration\nof LOU operations with GLEIF required services, registry\nand jurisdictional verification and conformity with Master\nAgreement specifications. The Candidate is also required\nto facilitate a real-time, live demonstration of their LEI\nproduction system based upon a set of scripted activities\nwhich will be provided by GLEIF.\n©GLEIF2019 1911 VO1\n","contentLength":726,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:28:07.635Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-6-30-ma-appendix-02-accreditation-manual.pdf","content":"Chapter 3: Accreditation Process 20\n3.3 Process Flow Steps\nRole Step Description\n6d GLEIF Accreditation, in consultation with other GLEIF\nteam specialists, will prepare an assessment report which\nis reviewed and approved by the GLEIF CEQO. A notification\nwill be shared with the GLEIF Board and the ROC to inform\nabout the result of the accreditation application. The\nBoard'’s decision will be made without undue delay and\n@ minuted. decision will be minuted. GLEIF will then advise\noo the Candidate LOU of the outcome of the assessment\nin writing.\nCertificate of Accreditation ° If Pass - Accreditation Certificate, the Candidate\nLOU will be granted its Accreditation Certificate and\nP the designation of accredited local operating unit.\n* If Fail - does not meet standards, the Candidate LOU\nmm will receive a summary of the assessment report for\noD clarification and the MA will be terminated; it can\nAccreditation Subject / Title reapply again at a date of its choosing. Alternatively,\nW - GLEIF, at its option, may reject the submission\n= and grant the Candidate LOU more time to\nAW K prepare its documentation.\nM“m M«M « If granted Pass - Provisional, GLEIF will provide a\nfull explanation as to what authority the LOU has\nbeen granted, what needs to be remediated for full\naccreditation, and the allocated timeframe. GLEIF\nis required to reassess all changes made by the\nCandidate LOU in order to render a decision with\nrespect to final status; if not completed in a timely\nmanner, the Candidate LOU's status will be changed\nto ‘not approved’ and the Master Agreement\nwill be terminated.\nAny dispute arising out of the recognition or de-recognition\nof a LOU shall be reviewed with the goal of resolution -\nsee Appeals and Complaints in the Master Agreement.\n©GLEIF2019 1911 VO1\n","contentLength":1785,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:28:07.635Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-6-30-ma-appendix-02-accreditation-manual.pdf","content":"Contents 3\nAboutthisManUAL.......ccoiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii ittt ieiiieaetetisasstesosssnsssssssassssosssasnsssssnsslh\n- eLel =T [ e L ToT o T e Yo -3\nYool f=Te [1 e T ATeT oY BT all 4 1= o o3\n(000 11 e Loy ol 0T o 1 -3 -\nChapter 1: Accreditation ReqUIremMENtS.....cciiiiiiiiiiiiiii it iieetieiereneteanesenesennessncsenncesneeas®\nTTAccreditation Elgibility .. ..ooooi el O\nT2 FUNAAMENEAIS . oo el O\n12 CertifICAt LISt e el O\nT3 COSt RE OV Y .. e e ]\n1.4 0rganizational REPULATION . ... e\n[ Y @] o) e el =Y =3 Y\n1.6 AccreditationInternal Control Standards. ..o i i 8\n1.7 ACCreditatioN Ol . .. e e et 8\nLRI @l al Lo STl W] L 0 PPN -\n1.9 Accreditation Appeals and Complaints .. ...ttt et B\n1.10 Continuous Improvement of Accreditation.........coooiiiiiiiii 9\n11MUseof Third Party Reportsin Accreditation...... ... il 9\n112 Use of Third Party Service Providersin Accreditation...........cooiiiiiiiii i ciiiie a9\nL = =T o) N1 U T o | o Ve\nChapter 2: Roles and Responsibilities........ccoiiiiiiiiiiiiiiiiiiiiiiiiiii it icireieeeenneeenennnnesennnnes. 10\n2 APPICANtLOU . .o T10\n2.2Candidate LOU .. e 10\n2.3Accredited LOU . .. e e 10\n8] C I = | =T | o P [0\nChapter3: Accreditation ProCeSS.....uvieiiiiiiieieieieneereneeeeeneerensesenncesensessnsessnnsessnsassnsaaesll\nG0 O =T = PP I |\nB2 OW Ot . o el 12\nB B PrOCESS FlOW S DS . vttt ettt e e 13\nB RACT NI e 21\nB S ACCreditatioON SUP PO T . e e e 22\n3.6 ACCreditation CertifiCate . .. oot e 22\n3.7 Agreement Change PrOCESS ... ittt et ettt et e e 22\nChapter 4: Guide | General Information for Accreditation Documentation Submission.....................23\n41 AContactDetails | BENtity Structure .. ..o e 23\n4.2 C0rganization STrUCTUIE . . ...ttt et e e el 20\n4.3 D Financial Data, Audits and General Governance . .........oviiii i i .. 25\n44 E Cost Recovery ReEQUINEMENES . .. .ttt e ittt e e 25\nL el I T Y = Vo321 o\n4.6 GRequiredWebsite TemS . ... o e e 26\n47 HRecords ManagemMent . ... o el 26\n4.8 1 Software DeVelOPmMENt . ... e 2T\n4.9 JNetworks & INfrastrUCtUre . .. ..o e e 2T\nLI0KIT Security & ComMPlIaNCE . ..ot e e e e e e 2T\n411LDataQuality Management . . ... e 2T\nAppendix 02 - Certificate List.....coiiiiiiiiiiiiiiiietiiieeiieteeneeseeeeresnnnseeesesncnssesessssnnsnscasenens 28\n©GLEIF2019 1911 VO1\n","contentLength":2259,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:28:07.635Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-6-30-ma-appendix-02-accreditation-manual.pdf","content":"Chapter 3: Accreditation Process 21\n3.4 RACI Chart\nObligation Role Description\nResponsible Responsible to perform the assigned task\nAccountable Accountable to make certain work is assigned and performed\nConsulted Consulted about how to perform the task appropriately\nInformed Informed about key events regarding the task\nTask Applicant LOU GLEIF Candidate LOU\n1. Start Accreditation Responsible\nAccountable\n2. Develop Accreditation Plan Responsible Consulted\nAccountable\n\n3. Agree on Accreditation Plan Responsible Responsible\n\nAccountable\n4. Sign Master Agreement Responsible Responsible\n\nAccountable\n5. Implement Accreditation Plan Informed Responsible\n\nAccountable\n\n6. Assess Accreditation Documentation Responsible Informed\n\nAccountable\n\n©GLEIF2019 1911 VO1\n","contentLength":762,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:28:07.635Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-6-30-ma-appendix-02-accreditation-manual.pdf","content":"Chapter 3: Accreditation Process 22\n3.5 Accreditation Support\nIn order to provide for fairness to all Applicant and Candidate LOUs, GLEIF will not provide\nad hoc advice to Applicant/Candidate LOUs regarding their application responses and/or\ndocuments. GLEIF provides sufficient definitions and information on its website for this purpose.\nHowever, the Applicant/Candidate LOU may, upon request, schedule up to three (3) review\nconference calls or video conferences with GLEIF during the Accreditation Process - Each call\nwill be planned for one hour’s duration and minimal extra time will be allotted at the discretion\nof GLEIF. This is to ensure fairness to all Applicant and Candidate LOUs.\nFor these calls, the Applicant/Candidate LOU may be asked to submit a preliminary Accreditation\nPlan/Documentation materials and/or supporting documentation relating to the controls/ topics\nat issue and provide a specific list of questions depending on the nature of the request. Questions\nand answers may be published on the GLEIF website for reference by all Applicant/ Candidate LOUs\n- this information will not be attributable to any specific Applicant/Candidate LOU.\nThis support is completely optional to the Applicant/Candidate LOU which can submit\nits Accreditation Plan and Documentation with or without it.\nGLEIF reserves the right to request and schedule review meetings for its own purposes of\nclarification and will follow the same procedure of providing the Applicant/Candidate LOU\na list of questions in advance depending on the subject and circumstances and setting a\nmutually agreeable schedule.\n3.6 Accreditation Certificate\nUpon successful completion of the Accreditation Process, GLEIF sends the Candidate LOU\nan Accreditation Certificate, granting the right to issue LEIs. GLEIF will explicitly and clearly\nenumerate in which countries the new local operating unit is accredited to issue LEIs and\nas well as an accreditation date.\nGLEIF also publishes all successful Accreditations on its website.\n3.7 Agreement Change Process\nPost-accreditation, the LOU may desire to modify its internal operating procedures due to\nchanges in the business or operating environment. In those cases, the LOU must follow the\nestablished Change Process as documented in the Master Agreement, Sub-Chapter lll. D\nGLEIF\nThe GLEIF ACCREDITED logo must be displayed in an\nappropriate location on the accredited LOU’s website.\nACCREDITED\n©GLEIF2019 1911 VO1\n","contentLength":2448,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:28:07.635Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-6-30-ma-appendix-02-accreditation-manual.pdf","content":"23\nGuide | General Information for\nAccreditation Documentation Submission\n\nSection Title 4.1 A Contact Details | B Entity Structure\n\nGeneral Purpose Providing a business and technical overview of the organization\napplying for Accreditation.\n\nDescription A Contact Details (page 3)\nThis section requires specific information regarding the organization’s\nmanagement contacts for this process. This includes the preparer and\napprover of the documents and key reference resources (Operations\nand Finance) who may need to be contacted for additional information\nand clarification. It most importantly requests information about the\n‘sponsor’ of this application initiative - this is the signatory at the bottom\nof the page who will be designated as the “Authorized Representative”\nfor the Applicant and is responsible to certify that the application is correct\nand complete. This individual needs to be sufficiently authorized by the\napplying organization to represent the organization as well as serve as\nthe key senior management sponsor throughout the Accreditation process.\nB Entity Structure (page 4)\nThis section requires specific information regarding the organization structure\nof the Applicant/Candidate LOU. The Applicant/Candidate LOU may be a\nstand-alone organization or part of a larger organization. GLEIF will require\nbasic information about parent-child relationships, in general, if applicable\nbackground information however, the main focus will be on the Applicant/\nCandidate LOU organization.\nFor purposes of clarity, “Government” refers to an Applicant/Candidate LOU\nwhich is, or is part of, an administrative agency, nation state or state-owned\ncompany; “Private” is a privately controlled legal entity which is not listed\non a stock exchange; “Public-listed” is an entity which is listed on a stock\nexchange and has shareholders - “Public-Non-Listed” is an entity which\nis funded from public sources, but does not have stockholders.\n“Accounting Framework” and “Internal Controls Framework” refer to\ncommonly recognized business models in use globally. This is helpful\nbut not essential information.\nFiscal Year - please specify when the Applicant/Candidate LOU's fiscal or\naccounting year starts and ends. This is helpful background information\nfor billing planning.\nB Entity Structure (page 5)\nThe Applicant LOU is asked to identify any beneficiary ownership associated\nwith their organization and its intended tax strategy in relation to the delivery\nof LEI services. The Applicant LOU is also required to disclose its registry/\nsources of data and current or expected jurisdictions on a separate form.\n\n© GLEIF 2019 1911 VO1\n","contentLength":2645,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:28:07.636Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-6-30-ma-appendix-02-accreditation-manual.pdf","content":"Chapter 4: Guide | General Information for Accreditation Documentation Submission 24\nDescription B Entity Structure (page 6)\nThis section asks the Applicant LOU to describe its current audit activities\nfrom a variety of sources. This may aid the Applicant LOU in identifying any\ncurrent third party report that could be used to confirm the adequacy of\ninternal controls independent of the organization. These reports may be\naccepted by GLEIF in lieu of other documentation if current and relating\nto LEl services.\nAccess Groups Checklist Template - Public - included on www.gleif.org\nCompleted Data - Confidential as per the NDA\nUpdate Frequency Asrequired subject in the Master Agreement.\nSection Title 4.2 C Organization Structure (page 7)\nGeneral Purpose Providing guidance on the documentation requirement which will\nassist the Applicant LOU to complete the Accreditation Process.\nDescription The purpose of this page is to advise the Applicant LOU as to the types\nof information/reports which will either be required or may be helpful\nduring the Accreditation Process.\nA key point to note is that distinctions are made as to what reports\nwould generally be expected to be in place for certain types of organization.\nSee the “Applicability” columns.\nAccess Groups Public - included on www.gleif.org\nCompleted Data - Confidential as per the NDA\nUpdate Frequency Asrequired in the Master Agreement.\n©GLEIF2019 1911 VO1\n","contentLength":1421,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:28:07.636Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-6-30-ma-appendix-02-accreditation-manual.pdf","content":"Chapter 4: Guide | General Information for Accreditation Documentation Submission 25\n\nSection Title 4.3 D Financial Data, Audits and General Governance (page 8)\n\nGeneral Purpose Describing of the basic financial position of the Candidate LOU and\ngeneral questions regarding governance and organizational structure.\n\nDescription The purpose of this section is to provide GLEIF with an overview\nof certain financial and operational aspects of the Candidate LOU.\n\nA key point to note is that the Candidate LOU must clearly explain how its\noperations are structured within an organization. For example, it could be a\nstand-alone entity with no other affiliations. It could also be a department/\nfunction within another organization.\n\nThis section applies to the Candidate LOU in the context of its parent/owner/\ncontrolling entity, if applicable. All relevant entities need to be represented in\nthe Candidate LOU’s answers.\n\nAccess Groups Public - included on www.gleif.org\nCompleted Data - Confidential as per the NDA\n\nUpdate Frequency Asrequired in the Master Agreement.\n\nSection Title 4.4 E Cost Recovery Requirements (page 9)\n\nGeneral Purpose Understanding how the Candidate LOU intends to comply with GLEIF's Cost\nRecovery Requirements.\n\nDescription A critical principle of GLEIF is that a local operating unit must operate its LEI\nactivities on a not-for-proft basis. Cost Recovery requirements are a specific set\nof quantitative measures based upon direct costs incurred by a local operating\nunit in the production and support of the LEI operations. This section asks\nquestions about the Candidate LOU’s awareness of and agreed compliance\nwith this principle.\n\nAccess Groups Public - included on www.gleif.org\nCompleted Data - Confidential as per the NDA\n\nUpdate Frequency Asrequired subject to GLEIF review and discussion process and as set out in the\nMaster Agreement.\n\n©GLEIF2019 1911 VO1\n","contentLength":1895,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:28:07.636Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-6-30-ma-appendix-02-accreditation-manual.pdf","content":"Chapter 4: Guide | General Information for Accreditation Documentation Submission 26\n\nSection Title 4.5 F LOU Services (page 10-13)\n\nGeneral Purpose Explaining the Candidate LOUs internal operations regarding\nservice requirements for LOU services as per the Master Agreement\n\nDescription This set of questions parallels and reflects the services detailed in\nthe Service Level Agreement.\n\nAccess Groups Public - included on www.gleif.org\nCompleted Data - Confidential as per the NDA\n\nUpdate Frequency Asrequired in the Master Agreement.\n\nSection Title 4.6 G Required Website Items (page 14)\n\nGeneral Purpose Informing and confirming with the Candidate LOU the minimum requirements\nfor its LEI website.\n\nDescription Self-explanatory.\n\nAccess Groups Public - included on www.gleif.org\nCompleted Data - Confidential as per the NDA\n\nUpdate Frequency Asrequired in the Master Agreement.\n\nSection Title 4.7 H Records Management (page 15)\n\nGeneral Purpose Informing and confirming the Candidate LOU'’s obligations regarding\nhistorical LEI information.\n\nDescription Record retention and management is critical to the effectiveness of LEI\noperations and the GLEIS. The Candidate LOU must understand GLEIF\nrequirements in this area. Available/retrievable historical data will\nbecome increasingly critical as the LEl population expands.\n\nAccess Groups Checklist Template - Public - included on www.gleif.org\nCompleted Data - Confidential as per the NDA\n\nUpdate Frequency Asrequired in the Master Agreement.\n\n©GLEIF2019 1911 VO1\n","contentLength":1516,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:28:07.636Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-6-30-ma-appendix-02-accreditation-manual.pdf","content":"Chapter 4: Guide | General Information for Accreditation Documentation Submission 27\n\nSection Title 4.8 | Software Development (page 16)\n\n4.9 J Networks & Infrastructure (page 16)\n410 KIT Security & Compliance (page 17)\n\nGeneral Purpose Explaining the information technology general controls in place.\n\nDescription The purpose of these sections is to provide GLEIF with an understanding of\ncertain IT operational practices at the Candidate LOU’s data center whether\nit is in-house or outsourced.\n\nIf a Candidate LOU has a current third party controls assessment report\n(e.g. SAS70, SSAE16 SOC2) it can be submitted as supporting documentation.\nGLEIF requests the Candidate LOU to cross-reference the report(s) to the\nChecklist items to provide a clear record of understanding.\n\nAccess Groups Checklist Template - Public - included on www.gleif.org\nCompleted Data - Confidential as per the NDA\n\nUpdate Frequency Asrequired in the Master Agreement.\n\nSection Title 411 L Data Quality Management (page 18 - 20)\n\nGeneral Purpose Understanding the Candidate LOU's internal procedures regarding\nthe maintenance and measurement of LEI-related data quality.\n\nDescription Data Quality is a critical characteristic, which must be maintained in order\nto preserve the integrity of LEl data. The Candidate LOU'’s internal procedures\nprovides information about how it maintains and measures the quality of\nits data and complies with ISO 17442:2019. This section also asks about the\nCandidate LOU’s procedures with respect to identifying and handling\npotential duplicate LEls. Lastly, questions are asked regarding LEI\npublishing and upload procedures.\n\nAll of these principles are reflected in the SLA which is available on\nGLEIF's website.\n\nAccess Groups Checklist Template - Public - included on www.gleif.org\nCompleted Data - Confidential as per the NDA\n\nUpdate Frequency Asrequired in the Master Agreement.\n\n©GLEIF2019 1911 VO1\n","contentLength":1917,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:28:07.636Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-6-30-ma-appendix-02-accreditation-manual.pdf","content":"28\n[ ] [ ]\nCertificate List\nThe step is not addressed by the standard at the\ntop, so would need to be asked/observed.\nThe step is addressed by the standard at the top,\nso it may be skipped.\nChecklist Checklist Question Question Text elDAS ETSI WEB- Web- ISO ISO\nSection Topic Number ETSIEN X-Ref TRUST* trust 200071** 27007**\n319 401 X-ref\nD 11 Has an independent audit of your financial Yes Principle\nstatements been performed for your last 1\ncompleted fiscal year?\nD 1.2 Has your audit firm/government regulatory Yes Principle\nagencies issued any management letters 1\nrelating to LEl operations over the past three\nyears? - This would include commentary\nGoing relating to internal controls, accounting\nConcern - controls and methods of procedures.\nD Parentand 1.3 Do you have an internal audit function?\nLOU\nD 1.3.1 Have they performed any audits within your\norganization relating to LEl operations?\nD 1.4 Have you been subject to any regulatory\naudits/reviews in your current year's operations?\nD 1.5 Do you have a formal LEI Operations Budget\nfor this year and next year's operations?\nD 21 Are third party services (e. g. augmented\nstaff, cloud services, data centers) utilized in\norder to provide LEl services?\nD 2.2 Do you have intellectual property and/or\nLEI proprietary methods/ systems which are\ni i ices?\ne employed in the delivery of LEl services?\nD 2.3 Are you currently involved with any litigation\nmatters which could effect LEl services?\nD 2.4 Are you subject to regulatory compliance Yes 711113 Yes Principle\nrequirements which could effect LE| operations? 3\nE 1 Do you clearly understand the technical\nrequirements of the Cost Recovery Principle?\nE 2 Do you confirm that the LOU business\noperations will comply with the Cost Recovery\nPrinciple at and after accreditation?\nE Cost 3 Does your agreed business plan include\nRecovery transparent financial information and\nRequire- assumptions regarding the LOU services\nments described in Section F?\nE 4 Do you clearly understand the requirements\nof the annual verification process and the\nindependent cost recovery audit?\nE 5 Please confirm that your budget information as\nsubmitted conforms to the following definitions:\n© GLEIF2019 1911 VO1\n","contentLength":2211,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:28:07.636Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-6-30-ma-appendix-02-accreditation-manual.pdf","content":"Appendix 02 - Certificate List 29\nThe step is not addressed by the standard at the\ntop, so would need to be asked/observed.\n\nThe step is addressed by the standard at the top,\nso it may be skipped.\nChecklist Checklist Question Question Text elDAS ETSI WEB- Web- ISO 1ISO\nSection Topic Number ETSIEN X-Ref TRUST* trust 20001** 27001**\n319 401 X-ref\nF 11 Will you execute a formal contract either\nphysically or electronically with a Legal\nEntity for every LEl issued?\nF 1.2 Does your legal entity contract template\ninclude all requirements as defined in the\nMaster Agreement Appendix 5?\nF 1.3 Do you have a standard process for receiving\npayment from a legal entity for which an LEI\nwas provided?\nF 1.4 Verifying against an authoritative source the Yes Principle\naccuracy of the LE-RD provided by the LE? 2\nF 1.4.2 Verifying existence and eligibility of the Yes Principle\nentity applying for the LEI? 2\nF 1.4.3 Verifying that the individual signing Yes Principle\nthe application is duly empowered? 2\nIssue New\nF LEls 1.4.4 Ensuring an up-to-date list of applicable Yes Principle\naccounting standards and authoritative 2\nsources is used for verifying that the\nreported relationship exists?\nF 1.4.5 Verifying the existence and eligibility Yes Principle\nof the relationship information reported? 2\nF 1.4.6 Informing the Legal Entity that either its Yes Principle\napplication shall require amendment, shall 2\nbe refused, or the LEI has been issued and\nincorporated into the Global LE| repository?\nF 1.4.7 Reporting the correct relationship\ninformation of the Legal Entity?\nF 1.4.8 Uploading new LEI and LE-RD as well as\nrelationship records to GLEIF?\nF 1.4.9 Accepting without delay and\nprocessing applications for an LEI?\n© GLEIF 2019 1911VO1\n","contentLength":1742,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:28:07.636Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-6-30-ma-appendix-02-accreditation-manual.pdf","content":"Appendix 02 - Certificate List 30\nThe step is not addressed by the standard at the\ntop, so would need to be asked/observed.\n\nThe step is addressed by the standard at the top,\nso it may be skipped.\nChecklist Checklist Question Question Text elDAS ETSI WEB- Web- ISO ISO\nSection Topic Number ETSIEN X-Ref TRUST* trust 20007** 27007**\n319 401 X-ref\nF 211 Providing an interface or mechanism\nfor the Legal Entity to update LE-RD\nF 21.2 Maintaining procedures for verifying the\nchange is duly empowered to do so by:\n¢ Reverifying the authority of the\nrequestor of the change?\n¢ Reconfirming the authorized person’s\nEnter contact details including email address?\nLegalEntity ¢ Reconfirming the requestor email\nEvents . .\naddress is not generic?\nF 213 Checking, if an update to the relationship\ninformation is also required?\nF 214 Verifying via an authoritative source the\naccuracy of the Legal Entity Event change?\nF 21.5 Informing the Legal Entity of changed LE-RD\nand uploading the changed LE-RD to GLEIF?\nF 311 Reviewing and responding to LEl and LE-RD\nchallenges transmitted to the LOU by GLEIF?\nF 312 Ensuring that the relationship information is\nManage also reviewed and changed, where applicable?\nChallenges\nF 313 Informing the Legal Entity of validated\nchallenges and uploading the changed\nLE-RD to GLEIF as applicable?\n©GLEIF2019 1911 VO1\n","contentLength":1346,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:28:07.636Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-6-30-ma-appendix-02-accreditation-manual.pdf","content":"About this Manual / Accreditation Tools / Contact Details 4\nAbout this Manual\nThe purpose of this document is to provide an overview of the Accreditation Process, which\nis required for all Applicant LOUs and Candidate LOUs seeking to become an accredited local\noperating unit (LOU). In order to support the integrity of the GLEIS, local operating units must\nincorporate the vision and internal control requirements of GLEIF within its operations.\nThe Accreditation Process has two distinct phases: Application (also referred to as the Plan Phase)\nand Candidacy (also referred to as the Documentation Phase). Each will be explained in detail\nin this Manual. Applicant/Candidate LOUs are responsible for reviewing the materials posted\nby GLEIF on its website and determining if they wish to proceed and be evaluated for\naccredited status.\nAt a summary level, the Applicant LOU creates an Accreditation Plan that is a strategic\ndocument outlining the goals, objectives and capabilities of the Applicant LOU and how\nit envisions complying with GLEIF operational and control environment as well as fitting in\nwith the GLEIF strategy. After progressing to Candidate LOU status, the Candidate LOU\nprepares the detailed Accreditation Documentation materials after signing the Master\nAgreement which progresses GLEIF's evaluation process.\nAccreditation Tools\nApplicant LOUs can start the Accreditation Process by sending an E-mail to\naccreditationrequest@gleif.org attaching a signed NDA which can be obtained at www.gleif.org.\nAll materials required for the first stage of Accreditation are listed in the Accreditation\nPlan Checklist which is provided as a guide for Applicants in the Plan stage.\nGLEIF will grant the Applicant LOU access to GLEIF's customer portal to identified individuals\nprovided by the Applicant LOU. Authorized users are also provided access to a virtual LOU\nCommunications portal for the uploading of application documentation. All materials must\nbe loaded into this space for GLEIF consideration. Additionally, all further Applicant/Candidate\nLOU communication must be managed through the customer portal (OTRS). No external\ncommunications will be accepted in order to maintain a proper audit trail.\n\n©GLEIF2019 1911 VO1\n","contentLength":2238,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:28:07.636Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-6-30-ma-appendix-02-accreditation-manual.pdf","content":"Appendix 02 - Certificate List 31\nThe step is not addressed by the standard at the\ntop, so would need to be asked/observed.\n\nThe step is addressed by the standard at the top,\nso it may be skipped.\nChecklist Checklist Question Question Text elDAS ETSI WEB- Web- ISO ISO\nSection Topic Number ETSIEN X-Ref TRUST* trust 200071** 27001**\n319 401 X-ref\nF 4.1 Do you have a process in place for a\nLegal Entity to request transfer of a LEI?\nF 4.2 Does your process ensure that:\nF 421 The defined and established transfer rules\nin the GLEIS are followed?\nF 422 Procedures for verifying the individual\nrequesting the LEI transfer is duly\nempowered to do so are in place?\nTransfer\nF PR 4.2.3 The associated relationship information\nLE-RD is transferred as well?\nF 4.2.4 LE-RD is verified via an authoritative source?\nF 4.2.5 Relationship information is correctly\ntransferred as well?\nF 4.2.6 The Legal Entity is informed (as applicable)?\nF 427 The LEl and its changed LE-RD are uploaded\nto GLEIF?\n© GLEIF2019 1911 VO1\n","contentLength":1011,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:28:07.636Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-6-30-ma-appendix-02-accreditation-manual.pdf","content":"Appendix 02 - Certificate List 32\nThe step is not addressed by the standard at the\ntop, so would need to be asked/observed.\n\nThe step is addressed by the standard at the top,\nso it may be skipped.\nChecklist Checklist Question Question Text elDAS ETSI WEB- Web- ISO ISO\nSection Topic Number ETSIEN X-Ref TRUST* trust 20007** 27007**\n319 401 X-ref\nF 5.1 Are there procedures in place for: Yes Principle\n2\nF 511 Notifying Legal Entity of upcoming Yes Principle\nrenewal requirements? 2\nF 512 Providing an interface or mechanism for Yes Principle\nthe Legal Entity to renew? 2\nF 513 Maintaining procedures for verifying the\nindividual requesting the LEl renewal is duly\nempowered to do so?\nF 514 Uploading the relationship information Yes Principle\nas well? 2\nF 515 Verifying via an authoritative source the\naccuracy of the LE-RD?\nF 5.1.6 Informing the Legal Entity about any missing Yes Principle\nor incorrect entries? 2\nF 517 Checking for duplicates including Yes Principle\nrelationship information? 2\nF 518 Receiving secure payments for the renewal?\nF 519 Adjusting the LEI and relationship status Yes Principle\nRenewals as applicable to recognize renewal or 2\nof LEIS non-renewal?\nF 5.1.10 Informing the Legal Entity of renewal or Yes Principle\nnon-renewal status? 2\nF 51M Uploading the changed LE-RD and the Yes Principle\nupdated relationship information to GLEIF? 2\nF 5.2 If you are planning to use multiple-year\nrenewal contracts, can you please confirm\nthat there are procedures in place for\nensuring that the following will be performed\non annual basis within the contract period:\nF 5.21 Informing the Legal Entity about any missing\nor incorrect entries?\nF 522 Checking for duplicates including\nrelationship information?\nF 523 Adjusting the LEI and relationship status\nas applicable to recognize renewal or\nnon-renewal?\nF 524 Informing the Legal Entity of renewal or\nnon-renewal status?\nF 525 Uploading the changed LE-RD and the\nupdated relationship information to GLEIF?\n© GLEIF 2019 1911 VO1\n","contentLength":2001,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:28:07.636Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-6-30-ma-appendix-02-accreditation-manual.pdf","content":"Appendix 02 - Certificate List 33\nThe step is not addressed by the standard at the\ntop, so would need to be asked/observed.\n\nThe step is addressed by the standard at the top,\nso it may be skipped.\nChecklist Checklist Question Question Text elDAS ETSI WEB- Web- ISO ISO\nSection Topic Number ETSIEN X-Ref TRUST* trust 200071** 270071**\n319 401 X-ref\nF 6.1 Are there procedures in place for checking\nagainst GLEIF's Check for Duplicates facility\nand process as defined? Please explain.\nCheck for\nF Duplicates ] Are there procedures in place to avoid\nany types of duplicates in the system?\nPlease explain.\nF 71 Are there procedures in place to ensure the Yes\nCode Lists implementation of the code lists updates\nwithin the defined timeframe? Please explain.\nF 8.1 Are there procedures in place for checking\nagainst GLEIF's Data Governance Pre-Check\nAPl as defned? Please explain.\nData\nF Governance B Are there procedures in place to avoid\nany data quality failures in the system?\nPlease explain.\nF Metric Data IR Do you measure the Service Levels as defined\nCollection in the Service Level Agreement?\nF 10.1 Do you currently utilize third party services\nsuch as registration agents?\nF 10.11 Does your organization have a formal vetting\nprocess for evaluating the reliability of a\nthird-party service provider or registration\nagents? If so, does it consider:\nF 10.2 Do you have a formal vetting process for\nevaluating the reliability of a third-party\nThird Party service provider or. registration agents?\nResources/ If so, does it consider:\nRegistration\nF Agents 10.21 Financial stability\nF 10.2.2 Market reputation\nF 10.2.3 Abilities to meet LOU and GLEIF\ncontrol requirements?\nF 10.2.4 Evaluating the potential risks of utilizing\nthe services provided\n© GLEIF2019 1911 VO1\n","contentLength":1773,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:28:07.636Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-6-30-ma-appendix-02-accreditation-manual.pdf","content":"Appendix 02 - Certificate List 34\nThe step is not addressed by the standard at the\ntop, so would need to be asked/observed.\n\nThe step is addressed by the standard at the top,\nso it may be skipped.\nChecklist Checklist Question Question Text elDAS ETSI WEB- Web- ISO ISO\nSection Topic Number ETSIEN X-Ref TRUST* trust 200071** 270071**\n319 401 X-ref\nG 11 Provide a transparent means for Legal\nEntities to understand the process of\nrequesting an LEl or LEI transfer?\nG 1.2 Provide a transparent means for Legal\nEntities to understand the process of\nrequesting an LEl or LEI transfer?\nRequired\nG Website 13 Incorporate all terms and requirements of\nItems GLEIF's Terms of Use as defined in Appendix\n9b of the Master Agreement?\nG 1.4 Display your accreditation certificate\non your LOU homepage?\nG 1.5 Display the GLEIF logo?\nH 1 Do you maintain a complete audit trail\nin compliance with ISO 17442:2012 data\nattributions and other Common Data File\nformat elements (Level 1business card data\nand Level 2 relationship data) for all actions\naffecting the content or status of LEI records?\nH 2 Is a particular function responsible for all Yes 71.2/ Yes Principle Yes Yes\naspects of record retention as per your 710 3\nestablished internal policies? What is\nyour testing process and periodicity?\nH 3 Is periodic training provided to all relevant Yes 71.2/ Yes Principle Yes Yes\npersonnel (including employees, contractors 710 3\nand temporary staff) to make them aware\nof your Records Management procedures?\nPlease provide a brief narrative and copies\nRecords of all relevant policies\nManagement\nH 4 Do you process paper records? If yes,\nare there specific retention policies\nregarding this?\nH 5 Do you create and maintain an internal list/ Yes 71.21 Yes Principle Yes\nindex of relevant records and/or storage 710 3\narchives which includes information relating\nto Retention Periods and is it periodically\nupdated? Please provide a brief narrative\nand copies of all relevant policies\nH 6 Do you ensure indexing, scanning, retrieval, Yes 7.3.2/ Yes Principle Yes\nstorage and destruction processes are 710 3\ndocumented, communicated, and tested\nat least annually? Please provide a brief\nnarrative and copies of all relevant policies\n© GLEIF2019 1911 VO1\n","contentLength":2242,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:28:07.636Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-6-30-ma-appendix-02-accreditation-manual.pdf","content":"Appendix 02 - Certificate List 35\nThe step is not addressed by the standard at the\ntop, so would need to be asked/observed.\n\nThe step is addressed by the standard at the top,\nso it may be skipped.\nChecklist Checklist Question Question Text elDAS ETSI WEB- Web- ISO ISO\nSection Topic Number ETSIEN X-Ref TRUST* trust 200071** 270071**\n319 401 X-ref\nH 71 All LEI data elements (Level 1business card\ndata and Level 2 relationship data) for the\ncurrent LElI and all of its associated changes?\nPlease provide a brief narrative and copies\nof all relevant policies\nH 711 If yes, do the records include:\nH effective date of any change(s)\nH the entity responsible for the change(s)\nH the reason for each change(s)\nH who performed the change(s)\nRecords\nH Management who authorized the change(s)\nH 72 Identification of Data Sources Yes 7.3.2/ Yes Principle Yes\nfor each issuance/change? 710 3\nH 8 Do you ensure access to relevant records is Yes 7.3.2/ Yes Principle Yes\nrestricted to only those employees who are 710 3\nappropriately authorized and need access\nto perform their duties?\nH 9 Do you ensure control procedures relating to Yes 7.3.2/ Yes Principle Yes Yes\nthe physical and environmental protection of 7.6 3\nrelevant records, including archived datais in\nplace and functioning properly?\nH 10 Do you ensure relevant records are only Yes 7.3.2/ Yes Principle Yes\ndestroyed in compliance with your procedures 710 3\nand any local or legal requirements?\n© GLEIF2019 1911 VO1\n","contentLength":1473,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:28:07.636Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-6-30-ma-appendix-02-accreditation-manual.pdf","content":"Appendix 02 - Certificate List 36\nThe step is not addressed by the standard at the\ntop, so would need to be asked/observed.\n\nThe step is addressed by the standard at the top,\nso it may be skipped.\nChecklist Checklist Question Question Text elDAS ETSI WEB- Web- ISO ISO\nSection Topic Number ETSIEN X-Ref TRUST* trust 200071** 270071**\n319 401 X-ref\n11J 1 Do you have a document which describes the Yes 741771 Yes Principle Yes\nsoftware development tools and environment 7.8 3\nin place for the LEI operation?\n11J 2 Do you have a formal process for developing Yes 741771 Yes Principle Yes\nand approving new software? 7.8 3\n11J 3 Do you have any outsourced software\ndevelopment arrangements relating\nLEl operations?\n11J 4 Do you have a process in place for identifying, Yes 741771 Yes Principle Yes\ntracking and correcting software errors/bugs? 7.8 3\n11J 5 Do you have standard IT service management Yes 741771 Yes Principle Yes Yes\nprocesses in place? Please provide evidence 7.8 3\nthat these are followed and maintained as\nneeded. This would include a patching process\nSoftware and upgrade/update policies and procedures.\nDevelope-\n11) ment/ 2 Please describe the current server/hosting Yes 741771 Yes Principle Yes\nN environment? Is it hosted, in-house, via a 7.8 3\nand third party, etc.? Describe the use of any\nInfrastructurel cloud-based resources such as Amazon\nWeb Services or Microsoft Azure.\n11) 3 Do you perform any monitoring over Yes 741771 Yes Principle Yes Yes\nthe LEl related IT infrastructure? 7.8 3\n11) 4 Are there any redundancies built into Yes 741771 Yes Principle Yes\nthe hosting platform and hardware? 7.8 3\n11J 5 Has there been any unscheduled network or\nsystem downtime in the past twelve months?\n11J 6 Do you have a current disaster recovery and/ Yes n Yes Principle Yes Yes\nor business continuity plan in place? How 3\noftenis it tested? Has the plan been invoked\nduring the past 3 operating years?\n11J 7 Do you have structured backup policies Yes n Yes Principle Yes Yes\nand practices? 2\n© GLEIF2019 1911 VO1\n","contentLength":2038,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:28:07.636Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-6-30-ma-appendix-02-accreditation-manual.pdf","content":"Appendix 02 - Certificate List 37\nThe step is not addressed by the standard at the\ntop, so would need to be asked/observed.\n\nThe step is addressed by the standard at the top,\nso it may be skipped.\nChecklist Checklist Question Question Text elDAS ETSI WEB- Web- ISO ISO\nSection Topic Number ETSIEN X-Ref TRUST* trust 200071** 270071**\n319 401 X-ref\nK 1 Have you performed or engaged a third\nparty to test system vulnerability, intrusion\ndetection or perform penetration testing?\nPlease list all vendors as applicable. Relevant\nprocess documents and most current reports\nK 2 Do you maintain firewall(s)? Relevant Yes 7.3179 Yes Principle Yes\nprocess documents and technical diagrams; 3\nplease describe its purpose and your\nmonitoring procedures.\nK 3 Is access to source code and other critical Yes 72 Yes Principle Yes\nresources (documents, contracts etc.) 3\n. monitored and tracked? Relevant process\nIT Security documents and technical diagrams\nand\nK Compliance Are there any users that are not subject to the Yes 7.2 Yes Principle Yes\nstandard security policies of the Company/ 3\nBusiness Unit/Department? Relevant process\ndocuments and list of exceptions\nK 5 Are there non-employees who have Yes 72 Yes Principle Yes\naccess to critical company information 3\n(source code, documentation etc.)? Relevant\nprocess documents and list of exceptions\nK 6 Are terminated employees/contractors Yes 72 Yes Principle Yes\nremoved from access to LOU systems/ 3\nresources in a timely manner? Relevant\nprocess documents and technical diagrams\n© GLEIF2019 1911 VO1\n","contentLength":1553,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:28:07.636Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-6-30-ma-appendix-02-accreditation-manual.pdf","content":"Appendix 02 - Certificate List 38\nThe step is not addressed by the standard at the\ntop, so would need to be asked/observed.\n\nThe step is addressed by the standard at the top,\nso it may be skipped.\nChecklist Checklist Question Question Text elDAS ETSI WEB- Web- ISO ISO\nSection Topic Number ETSIEN X-Ref TRUST* trust 200071** 270071**\n319 401 X-ref\nK 7 Do you have password policies for the Yes 7.2 Yes Principle Yes\nnetworks and systems, including length 3\nand Complexity, and any expiration policies?\nRelevant process documents, technical\ndiagrams and most current reports\nK 8 Do you have procedures in place to identify, Yes 7.3/ Yes Principle Yes\nreport and remediate any security breaches? 79 2\nK 9 Do you have any physical access restrictions Yes 7.3/ Yes Principle Yes\nto critical company assets such as servers 7.6 2\nand data? Relevant process documents,\nIT Security technical diagrams and most current reports\nand\nK Compliance 10 Have you had any IT operational or security\naudits (i. e. SSAE 16, SAS70) performed in\nthe past three years? Relevant process\ndocuments and results of last testing cycle\nK n Have you had any LEl-related security\nbreaches in the past five years? Relevant\nprocess documents, technical diagrams\nand most current reports\nK 12 Do you have your compliance activities in Yes 73 Yes Principle Yes\nplace to ensure compliance with respect 3\nto all applicable Data Privacy Laws?\n© GLEIF2019 1911 VO1\n","contentLength":1431,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:28:07.636Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-6-30-ma-appendix-02-accreditation-manual.pdf","content":"Appendix 02 - Certificate List 39\nThe step is not addressed by the standard at the\ntop, so would need to be asked/observed.\n\nThe step is addressed by the standard at the top,\nso it may be skipped.\nChecklist Checklist Question Question Text elDAS ETSI WEB- Web- ISO ISO\nSection Topic Number ETSIEN X-Ref TRUST* trust 200071** 270071**\n319 401 X-ref\nL 11 Does your organization have a governance Yes 79 Yes Principle Yes Yes\nframework that enables it to adhere to GLEIS 3\nstandards? If yes, please explain how this\ngovernance framework is structured.\nL 1.2 Does your organization have a continuous Yes Yes\nimprovement process for data quality in\nplace? If yes, please explain what the\nprocess steps are.\nL 1.3 Does your organization have a continuous Yes\nimprovement process for adapting to\nprocedural changes as required for\nadjustments to ROC or GLEIF standard\nand operating principles? Please explain.\nL 1.4 Does your organization have a defined\nimplementation period expectation\nfor different types of adjustments?\nPlease explain.\nL 21 Do you have an established data library that\ndefines proper values for fields entered in a\nLEl request?\nL Data Quality 2.2 Do you prevent unlikely or incorrect data\nManagement in submissions of LEl requests?\nL 2.3 Do you maintain procedures for:\nL 2.31 Do you maintain procedures for: Verifying the\nLE-RD based on the Legal Entity jurisdiction,\nentity category and legal form?\nL 2.32 Do you maintain procedures for: Ensuring an\nup-to-date list of authoritative sources used\nfor verification is maintained, accessible and\nusable at all times with no restriction for all\nbelow services?\nL 2.32A Issue new Lei\nL 2.328B Enter Legal Entity Events\nL 2.32C Manage Challenges\nL 232D Transfer of LEls and LE-RD\nL 2.32E Renewal of LEls\n(Inlc.multiple-year renewal contract)\n© GLEIF2019 1911 VO1\n","contentLength":1827,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:28:07.636Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-6-30-ma-appendix-02-accreditation-manual.pdf","content":"Appendix 02 - Certificate List 40\nThe step is not addressed by the standard at the\ntop, so would need to be asked/observed.\n\nThe step is addressed by the standard at the top,\nso it may be skipped.\nChecklist Checklist Question Question Text elDAS ETSI WEB- Web- ISO ISO\nSection Topic Number ETSIEN X-Ref TRUST* trust 200071** 270071**\n319 401 X-ref\nL 233 Do you have sufficient proficiency for\nunderstanding or interpreting\nauthoritative sources?\nL 2.34 Do you use other sources not listed in the\nGLEIF Registration Authorities list for\nverification/validation? If yes, please specify.\nL 2.4 Do you have sufficient language proficiency\nin the jurisdictions you are applying for\nunderstanding and interpreting the following?\nIf yes, please list all languages.\nL 2.41 The information you receive from the\nlegal entity?\nL 2.4.2 The information provided in the\ncorresponding authoritative source\nfor validation?\nL 2.5 Do you have validation procedures in\nplace for:\nL 2.51 Verifying that a Legal Entity is eligible for\nan LEl code?\nData Quality\nL Management B ¥3p] Provision of corresponding language tags\nfor the set of specified fields?\nL 253 Incorporating Transliteration data for all\nbelow services?\nL 253A Issue new LEI\nL 253B Enter Legal Entity Events\nL 253C Manage Challenges\nL 253D Transfer of LEls and LE-RD\nL 253E Renewal of LEls\n(Inlc.multiple-year renewal contract)\nL 254 Ensuring that LEls are only issued when\nvalidation process is successfully completed?\nL 255 Verifying the LEI Record Set is compliant\nwith the Common Data File (CDF) format\n(as published per www.gleif.org)\n© GLEIF2019 1911 VO1\n","contentLength":1610,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:28:07.638Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-6-30-ma-appendix-02-accreditation-manual.pdf","content":"About this Manual / Accreditation Tools / Contact Details 5\n[ ] [ ]\n\nAccreditation Documents\n\nApplicant LOUs will need to refer to the documents listed below to initiate and complete their\n\naccreditation application to GLEIF:\n\nAccreditation Stage Topic Document Location\n\nOverall Accreditation Program Master Agreement https://www.gleif.org/en/about-lei/\n\n. the-lifecycle-of-a-lei-issuer/gleif-\n(all Appendlces) accreditation-of-lei-issuers/required-\ndocuments#\n\nOverall Accreditation Program Accreditation Manual https://www.gleif.org/en/about-lei/\nthe-lifecycle-of-a-lei-issuer/gleif-\n\nApp.02 S T T S\n( PP ) accreditation-of-lei-issuers/required-\ndocuments#\n\nOverall Accreditation Program Accreditation Checklist https://www.gleif.org/en/about-lei/\nthe-lifecycle-of-a-lei-issuer/gleif-\n\nApp.02 e e\n( PP ) accreditation-of-lei-issuers/required-\ndocuments#\n\nPlan Phase - Applicant LOU Non-Disclosure Agreement https://www.gleif.org/en/about-lei/\nthe-lifecycle-of-a-lei-issuer/gleif-\naccreditation-of-lei-issuers/required-\ndocuments#\n\nPlan Phase - Applicant LOU Plan Accreditation Checklist https://www.gleif.org/en/about-lei/\nthe-lifecycle-of-a-lei-issuer/gleif-\naccreditation-of-lei-issuers/required-\ndocuments#\n\nPlan Phase - Applicant LOU Registry Inventory https://www.gleif.org/en/about-lei/\n\nSpreodsheet Form the-life:cyc!e-of-o-I(.-:‘i.-issuer/gleif-.\naccreditation-of-lei-issuers/required-\ndocuments#\n\nPlan Phase - Applicant LOU Funds Questionnaire https://www.gleif.org/en/about-lei/\nthe-lifecycle-of-a-lei-issuer/gleif-\naccreditation-of-lei-issuers/required-\ndocuments#\n\nPlan Phase - Applicant LOU Estimated LEI Volume Analysis https://www.gleif.org/en/about-lei/\nthe-lifecycle-of-a-lei-issuer/gleif-\naccreditation-of-lei-issuers/required-\ndocuments#\n\nGLEIF Contact\n\nAccreditation Requests accreditationrequest@gleif.org\n\nGeneral Accreditation Information accreditation@gleif.org\n\nGeneral Information info@gleif.org\n\n©GLEIF2019 1911VO1\n","contentLength":1950,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:28:07.640Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-6-30-ma-appendix-02-accreditation-manual.pdf","content":"Appendix 02 - Certificate List 41\nThe step is not addressed by the standard at the\ntop, so would need to be asked/observed.\n\nThe step is addressed by the standard at the top,\nso it may be skipped.\nChecklist Checklist Question Question Text elDAS ETSI WEB- Web- ISO ISO\nSection Topic Number ETSIEN X-Ref TRUST* trust 200071** 270071**\n319 401 X-ref\nL 2.5.6 Ensuring a LEI complies with GLEIF\nOperational and Technical Standards (Data\nQuality Rule Setting) during all below services:\nL 256A Issue new LEI\nL 2568B Enter Legal Entity Events\nL 256C Manage Challenges\nL 256D Transfer of LEls and LE-RD\nL 256E Renewal of LEls\n(Inlc.multiple-year renewal contract)\nL 257 Researching the content of the challenge and\nverifying the challenge via an authoritative\ndata source? Please explain.\nL 2.6 Do you comply with ISO 174427\nL 3.1 Do you have procedures in place for handling\nData Quality each of the following: Checking that the\nManagement LEI code does not exist already in the\nGlobal LEI Index?\nL 3.2 Do you have procedures in place for handling\neach of the following: Checking, that the\nlegal entity does not have an assigned LEI\ncode already?\nL 3.3 Do you have procedures in place for handling\neach of the following: Checking that no\nduplicate relationships exist?\nL 3.4 Do you have procedures in place for handling\neach of the following: I[dentifying Exclusivity\nViolations by using automated routines?\nL 3.5 Do you have procedures in place for\nhandling each of the following: Checking\nthe received feedback from GLEIF's Check\nfor Duplicates facility?\nL 3.6 Do you have procedures in place for handling\neach of the following: Ensuring that all newly\nissued LEls are processed by GLEIF's Check for\nDuplicates facility?\n© GLEIF2019 1911 VO1\n","contentLength":1742,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:28:07.640Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-6-30-ma-appendix-02-accreditation-manual.pdf","content":"Appendix 02 - Certificate List 42\nThe step is not addressed by the standard at the\ntop, so would need to be asked/observed.\n\nThe step is addressed by the standard at the top,\nso it may be skipped.\nChecklist Checklist Question Question Text elDAS ETSI WEB- Web- ISO ISO\nSection Topic Number ETSIEN X-Ref TRUST* trust 200071** 270071**\n319 401 X-ref\nL 4.1 Have you integrated the Data Governance Yes Yes\nPre-Check APl into your processes? If yes,\nplease describe briefly.\nL 4.2 Do you process the received feedback from Yes\nGLEIF's Data Governance Pre-Check\nL 4.3 Do you ensure that all newly issued and\nupdated LEls are processed by GLEIF's Data\nGovernance API to fulfil the Completeness\nService Level Target? Please explain briefly.\nData Quality\nL Management ISl Do you have procedures to ensure: Timely\nresponse to any GLEIF communication\nconcerning doubts, inconsistencies, or\ndata quality issues of the uploaded data?\nL 5.2 Do you have procedures in place to ensure:\nUploading LEl records at least daily?\nL 5.3 Do you have procedures in place to ensure:\nConfirmation to GLEIF via the GLEIF interface/\ncommunications protocol indicating a daily\n“live signal” given no LEI activity occurs?\n* Applicant would need to ** Subject to limitations\nconfirm that the same control noted in report scope\napplied to certificates would be (e. g. locations)\napplied to LEls. Principles apply\nspecifically to certificates only.\n© GLEIF2019 1911 VO1\n","contentLength":1440,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:28:07.640Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-6-30-ma-appendix-02-accreditation-manual.pdf","content":"G LE I F Enabling global identity\nProtecting digital trust\nGlobal Legal Entity Identifier Foundation (GLEIF)\nSt. Alban-Vorstadt 12, PO Box\n4002 Basel\nSwitzerland\naccreditation@gleif.org\ngleif.org\nChairman of the Board: Teresa Glasser\nChief Executive Officer: Stephan Wolf\n© 2019 All rights reserved\n©GLEIF2019 1911 VO1\n","contentLength":319,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:28:07.640Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-6-30-ma-appendix-02-accreditation-manual.pdf","content":"6\n\nAccreditation Requirements\n1.1 Accreditation Eligibility\nAny organization in any geographic location may apply to become a local operating unit with\nthe exception of a sole proprietorship or “natural person”.\nAn organization which does not successfully complete the Accreditation Process due to timing\ndeadlines or a decision of GLEIF may re-apply for Accreditation at a future date of its choosing.\n1.2 Fundamentals\nEvery Applicant/Candidate LOU is required to successfully complete the Accreditation Process\nin order to achieve accredited local operating unit status. The Accreditation Process evaluates\nan Applicant/Candidate LOU's financial, operational and information technology controls\nusing GLEIF's internal control questionnaire which is referred to as the Accreditation Checklist.\nThe specific areas of review are documented in this Manual.\nFor the avoidance of doubt, GLEIF is obliged to accredit a Candidate LOU if and when its\nAccreditation Plan has been fulfilled and all criteria for Accreditation Documentation have\nbeen met.\nGLEIF believes, as part of its founding principles, that every Applicant/Candidate LOU shall be\ntreated in a fully transparent manner with consistent processes and evaluation criteria. GLEIF\nacknowledges, however, that every Applicant/Candidate LOU will have its own unique profile\nand requirements as it considers entering into Accreditation.\nThe same set of questions and documentation requirements will be presented to all Applicant/\nCandidate LOUs. There are three (3) key documents that comprise GLEIF's Accreditation\nDocumentation. They are the Master Agreement (MA and its appendices), the Accreditation\nManual (this document), and the Accreditation Checklist. Basic definitions of each document\ncan be found at Step 1 of the Accreditation Process section of this Manual.\nIn addition to these materials, the Accreditation Process includes data quality test procedures\nutilizing test scenarios and sample data. These requirements are described in the Process Flow\nStep 3.3 Step 6b.\nAs an Applicant/Candidate LOU reviews the Accreditation Checklist, the Applicant/Candidate LOU\nmay believe that some questions are not applicable to its particular circumstances or operational\nmodel and should adapt its responses accordingly.\n1.2.1 Certifications\nOrganizations that hold any of the certificates included in the Appendix 02-Certificate List,\nat the end of this document, may be subject to a simplified Accreditation Process, through\nskipping certain sections of the Accreditation Checklist document, where applicable.\nThe decision to allow Candidate LOUs to skip sections of the Accreditation checklist\nis at the sole discretion of GLEIF.\n\n© GLEIF 2019 1911 VO1\n","contentLength":2712,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:28:07.640Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-6-30-ma-appendix-02-accreditation-manual.pdf","content":"Chapter 1: Accreditation Requirements 7\n1.3 Cost Recovery\nAccredited LOUs in the GLEIS must operate in a financially sustainable way. The Master Agreement\ndescribes in full the cost recovery principle and annual verification requirements. Accredited\nLocal operating units must not consider the issuance and maintenance of LEls as driven by profit\nconsiderations. The Applicant LOU must acknowledge with the submission of its Accreditation\nPlan that it intends to operate on a cost recovery basis. The Accreditation Checklist requires that\ncertain questions be answered and documentation provided to further validate this point during\nthe Documentation Phase.\n1.4 Organizational Reputation\nAn Applicant LOU must have a good reputation in its marketplace as it is representative of\nthe values and mission of the GLEIS. A business can achieve its objectives more easily if it has\na good reputation amongst its stakeholders, especially the public, regulators and authorities,\nlarge customers, opinion leaders in the business community, and suppliers.\nApplicants should be aware that this aspect of its organization may be considered in the\nAccreditation Process as well as concerns or comments brought to GLEIF's attention. While\nthe Accreditation Process is non-public, once an Applicant LOU executes the Master Agreement\nwith GLEIF and is designated as Candidate LOU, this fact is published on GLEIF's website as\na matter of public record. However, their detailed status within in the accreditation process\nwill not be published.\nContinued good reputation is a standard that all are required to uphold.\n1.5 Conflicts of Interest\nGLEIF defines a Conflict of Interest (COl) as:\n\n“A set of circumstances that creates a risk that professional judgment\n\nor actions regarding a primary interest will be unduly influenced by\n\na secondary interest. Primary interest refers to the principal goals of\n\nthe profession or activity, such as the protection of clients or duties\n\nof public office. Secondary interest includes not only financial gain but\n\nalso such motives as the desire for professional advancement and the\n\nwish to do favors for family and friends.”\nGiven the value and sensitivity of the services the local operating units provide, GLEIF will not\naccept any degree of COI given the irredeemable reputational harm it could cause. The Applicant/\nCandidate LOU is requested to report any potential COI situations to GLEIF's Head of Accreditation\n& Audit Services explaining the circumstances, actions, and remediation implemented to address\nthe COIl.\n\n©GLEIF2019 1911 VO1\n","contentLength":2571,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:28:07.640Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-6-30-ma-appendix-02-accreditation-manual.pdf","content":"Chapter 1: Accreditation Requirements 8\n1.6 Accreditation Internal Control Standards\nGLEIF has not adopted any single internal control standard as a requirement for LOU Accreditation.\nHowever, it has identified key control topics it considers critical to the overall integrity of LOU\noperations. These are reflected in the Accreditation Checklist. This is not a prescriptive model\n-the LOU is free to implement its own internal control structures based upon its own business\nrequirements as long as they meet spirit and substance of the GLEIF standards.\nWhen developing the Accreditation Checklist, GLEIF considered and incorporated control standards\nreferring to generally accepted models such as ISO, COSO, and CoBIT. It also reflects the principles\nof the CPSS-10SCO and ICC standards.\n1.7 Accreditation Processing Order\nAccreditation processing order is based on a FIFO (First In First Out) principle depending on the\ntimeliness and completeness of the Applicant/Candidate LOU’s submissions. Applications which\nare incomplete and/ or require additional documentation may be impacted with significantly\ndelayed processing times which can effect the precedence of their application.\n1.8 Confidentidlity\nConfidentiality is set out in the non-disclosure agreement.\n1.9 Accreditation Appeals and Complaints\nAppeals and Complaints by the Applicant/Candidate Regarding Accreditation\nGLEIF's goal is to amicably resolve any complaints or appeals. The Applicant LOU or Candidate LOU\nhas the right to petition GLEIF for an appeal and/or reconsideration of a decision. The Applicant or\nCandidate LOU must inform GLEIF by delivering to GLEIF's Head of Accreditation & Audit Services,\nin writing, the full facts and exact references to GLEIF's decision and the reason(s) why the Applicant\nLOU or Candidate LOU disagrees with the decision. This communication must be received within\nthirty (30) days of the date GLEIF communicated a decision to the Applicant LOU or Candidate LOU.\nCandidate LOUs also have the right to enter into independent Mediation or Arbitration\n(as documented in the Master Agreement) if they it believe that a satisfactory resolution\nhas not been, or cannot be achieved.\nComplaints about an Applicant/Candidate Received by GLEIF\nGLEIF may advise an Applicant LOU or Candidate LOU of complaints received from outside parties.\nAll such complaints must be received in writing with specific detail to be evaluated by GLEIF. The\nreceipt of a complaint will be acknowledged to the complainant within fourteen (14) days. GLEIF will\nreview all such complaints with the Applicant/Candidate LOU, as appropriate within thirty (30) days\nof the receipt of the complaint.\n\nFor the avoidance of doubt, when an Applicant/Candidate LOU submits a third\n\nparty report as part of the Accreditation Documentation, the Applicant/Candidate\n\nLOU must indicate which sections are applicable to which questions/sections of the\n\nAccreditation Checklist. In these cases, the Applicant/Candidate LOU\n\nunless requested by GLEIF.\n©GLEIF2019 1911 VO1\n","contentLength":3032,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:28:07.640Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-6-30-ma-appendix-02-accreditation-manual.pdf","content":"Chapter 1: Accreditation Requirements 9\n1.10 Continuous Improvement of Accreditation\nGLEIF regularly evaluates its accreditation criteria and process for best practices to ensure its\nrelevance. Any material changes to this Manual or the Accreditation Checklist will be managed\nper the terms of the Master Agreement “Agreement Change Process.”\n1.11 Use of Third Party Assessment Reports in Accreditation\nThe Applicant/Candidate LOUs may integrate the control assessment and reporting requirements\nfor becoming an accredited LOU with any independent auditing activity that is carried out with\nrespect to its organization(s). If an Applicant/Candidate LOU has a current third party opinion/\nreport from independent, qualified internal auditors, external auditors or, regulatory auditors or\nindependent consultants with respect to the subjects included in the Accreditation Checklist, these\nreports may be submitted as evidence as to the adequacy and effectiveness of internal controls.\nThe Applicant/Candidate LOU must cross-reference such reporting to the appropriate Checklist\nitem and provide direct responses to questions about areas not included in these reports.\n1.12 Use of Third Party Service Providers in Accreditation\nThe Applicant/Candidate LOU may utilize third party service providers for certain functions\nin the issuance and maintenance of LEls. The terms and conditions for this are detailed in\nthe Master Agreement. Appendix 14.\n1.13 Letters of Assurance\nIt is critical that an accredited LOU maintain its financial viability both in practical terms\nas well as with respect to the reputation of the GLEIS as a whole. When performing its financial\nassessment, GLEIF evaluates both independent information, such as audit reports as well\na unverified information from the Applicant/Candidate, such as operating budgets. GLEIF,\nat its sole discretion, may require an Applicant/Candidate LOU to provide a letter of assurance,\nguarantee or confirmation of financial sources and/or support from an Applicant/Candidate LOU'’s\nparent organization(s) indicating its ultimate responsibility for the Applicant/Candidate LOU'’s\nfinancial soundness. If such a document is not provided upon request, GLEIF, at its sole discretion\nmay terminate any contractual obligations with the Applicant/Candidate LOU as per the\nprocess agreed in the Master Agreement.\n\n©GLEIF2019 1911 VO1\n","contentLength":2376,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:28:07.640Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-6-30-ma-appendix-02-accreditation-manual.pdf","content":"(0]\nRoles and Responsibilities\n2.1 Applicant LOU\n* Issues accreditation request\n* Prepares the Accreditation Plan\n* Submits the Accreditation Plan\n* Signs the Master Agreement\n2.2 Candidate LOU\n* Provides all required documentation\n» Completes Accreditation requirements\n* Submits Accreditation documentation\n2.3 Accredited LOU\n° Complies with GLEIF requirements as defined in the Master Agreement including\nthe Cost Recovery Principle and the Annual Accreditation Verification process.\n* Publishes Accreditation Certificate on its website\n2.4 GLEIF\n* Processes all Accreditation Applications\n» Reviews and evaluates Accreditation Plan\n» Assesses feasibility and impacts on marketplace and GLEIS of Accreditation Plan\n» Signs the Master Agreement\n° Reviews and evaluates Accreditation Documentation\n° Communicates Accreditation decisions\n» Publishes newly accredited LOUs on GLEIF website\n» Monitors Accredited LOU activities and performance\n2.5 GLEIF CEO\n* Reviews and approves all Applicant and Candidate accreditations\n2.6 GLEIF Board\n* Monitors all Applicant and Candidate accreditations\n2.7 ROC\n* Oversees Accreditation activities of GLEIF\n» Endorses GLEIF process of Accreditation\n» Supervises the GLEIS\n© GLEIF2019 1911 VO1\n","contentLength":1231,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:28:07.640Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2018-02-08_ma-appendix-05-lou-contract-requirements.pdf","content":"GGLEIF, Brotectng digieal srust.\nLOU-Contract\nRequirements\nAppendix 05\n","contentLength":71,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:28:17.612Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2018-02-08_ma-appendix-05-lou-contract-requirements.pdf","content":"I. LOU-Contract Requirements\n\nEach contract between the LOU and a Legal Entity shall comprise provisions at\n\nleast regarding\n\n1. duration, which shall last, notwithstanding termination, as long as the Legal Entity exists and as\nlong as the LOU exists, whichever is shorter;\n\n2. termination, which shall be possible in the event of (i) a transfer of the Legal Entity's LEl to a\ndifferent local operating unit or to GLEIF, (ii) the Legal Entity abandoning its status as Legal\nEntity with an LEI, (iii) a deprivation of the LEI due to non-compliance of the Legal Entity with\nrequirements in the course of re-validation;\n\n3. termination with immediate effect for cause in the event of severe or repeated violation of\ncontractual duties, for which no cure is possible, or cure has been refused despite a reasonable\ncure period;\n\n4. termination with immediate effect by the LOU, and without any liability of the LOU for any\ndamages caused by such termination, in the event that the Master Agreement of the LOU with\nGLEIF is terminated;\n\n5. contractual language to be observed for any formal notices;\n\n6. applicability of the LOU's fee schedule, which shall mandatorily include the policy and terms\napplicable in the event of a transfer of the LEI;\n\n7. the provision that the LOU may annually review its fee schedule, and unilaterally determine new\nfees;\n\n8. obligation of the Legal Entity to supply true, full and authentic information;\n\n9. awareness of the Legal Entity that only one single LEI may be requested for a Legal Entity, i.e.\nprohibition to request a second LEI at either the same LOU or any other local operating unit;\n\n10. obligation of the Legal Entity to review the LE-RD at least once annually, to verify its accuracy;\n\n11. obligation of the Legal Entity to promptly submit any changes regarding any aspect having an\nactual or potential influence on the LElI and/or LE-RD;\n\n12. reference to the LOU's communication policy regarding challenges of the LEl and/or the LE-RD;\n\n13. awareness of the Legal Entity that it is obliged to make annual payment for the revalidation and\nrenewal of the LEI;\n\n14. awareness of the Legal Entity that the LOU may be required by mandatory law or per internal\nLOU controls to change LE-RD;\n\n15. awareness of the Legal Entity that the issuance of an LEl, and its yearly renewal, is subject to\nrequirements established by GLEIF;\n\n16. awareness of the Legal Entity that GLEIF reserves the right to request the transfer of the LEl to\nanother local operating unit;\n\nGLEIS - Global LEI System Master Agreement Page 2 of 4\nGLEIF Appendix 05 — Master Copy Version 1.2\n2018-02-08-MA-Appendix-05-LOU-Contract-Requirements.docx 8 February 2018\n","contentLength":2675,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:28:17.612Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2018-02-08_ma-appendix-05-lou-contract-requirements.pdf","content":"17. awareness of the Legal Entity that it may request the transfer of its LEl to another local\noperating unit (to be specifically designated by the Legal Entity), and/or to allow another local\noperating unit to request such transfer on the Legal Entity's behalf, and that no fees will be\nassessed;\n\n18. the transfer of rights (see Chapter IX of the Master Agreement) from the Legal Entity, its signing\nindividuals and any other persons, relating to any data becoming part of the LERD, to the LOU;\n\n19. the general requirement that any information provided, and applications and requests lodged,\nto the LOU must be submitted by the Legal Entity's authorized signatories, and duly dated and\nsigned;\n\n20. attestation of the authorities of the individual signing the contract on behalf of the Legal Entity.\n\n21. exclusive place of jurisdiction (only under exceptional circumstances being somewhere else than\nthe legal residence of the LOU);\n\n22. exclusive court competence either of the ordinary courts at the place of jurisdiction or an\nacknowledged and trusted arbitration court.\n\nThe LOU is explicitly prohibited to include in its contract with the Legal Entity that the LOU reserves\n\nthe right to transfer on its own initiative the LEIl to any other local operating unit.\n\nIl.\n\nVoluntarily, a LOU can opt to use the following LOU-Contract Requirements for\n\nGovernmental Entities in addition to the LOU-Contract Requirements above.\n\nLOU-Contract Requirements for Governmental Entities\n\nGovernment Entity (in the following “Legal Entity”) means any national, regional, provincial, state,\n\nlocal, municipal or other governmental body, tribunal, commission, court or regulatory or other\n\nagency, including any of its political or administrative subdivisions, as applicable and as determined\nby relevant law. The burden of proof that a Legal Entity is to be considered as Government Entity\nstays either with the particular Legal Entity or with its competent supervisory agency.\n\nEach contract between the LOU and a Legal Entity shall comprise provisions at least regarding\n\n1. duration, which shall last three calendar years;\n\n2. termination, which shall be possible in the event of a transfer of the Legal Entity's LEl to a\ndifferent local operating unit or to GLEIF;\n\n3. termination with immediate effect by the LOU, and without any liability of the LOU for any\ndamages caused by such termination, in the event that the Master Agreement of the LOU with\nGLEIF is terminated;\n\nGLEIS - Global LEI System Master Agreement Page 3 of 4\nGLEIF Appendix 05 — Master Copy Version 1.2\n2018-02-08-MA-Appendix-05-LOU-Contract-Requirements.docx 8 February 2018\n","contentLength":2644,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:28:17.612Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2018-02-08_ma-appendix-05-lou-contract-requirements.pdf","content":"4. contractual language to be observed for any formal notices;\n\n5. applicability of the LOU's fee schedule, which shall mandatorily include the policy and terms\napplicable in the event of a transfer of the LEI;\n\n6. the provision that the LOU may not unilaterally change current fees or determine new fees\nduring the contractual relationship with the Legal Entity;\n\n7. obligation of the Legal Entity to supply true, full and authentic information;\n\n8. awareness of the Legal Entity that only one single LEI may be requested for a Legal Entity, i.e.\nprohibition to request a second LEI at either the same LOU or any other local operating unit;\n\n9. obligation of the Legal Entity to review the LE-RD at least once annually, to verify its accuracy;\n\n10. obligation of the Legal Entity to promptly submit any changes regarding any aspect having an\nactual or potential influence on the LElI and/or LE-RD;\n\n11. reference to the LOU's communication policy regarding challenges of the LEl and/or the LE-RD;\n\n12. awareness of the Legal Entity that the LOU may be required by mandatory law or per internal\nLOU controls to change LE-RD;\n\n13. awareness of the Legal Entity that the issuance of an LEI, and any renewal, is subject to\nrequirements established by GLEIF;\n\n14. awareness of the Legal Entity that GLEIF reserves the right to request the transfer of the LEI to\nanother local operating unit;\n\n15. awareness of the Legal Entity that it may request the transfer of its LEI to another local\noperating unit (to be specifically designated by the Legal Entity), and/or to allow another local\noperating unit to request such transfer on the Legal Entity's behalf, and that no fees will be\nassessed;\n\n16. the transfer of rights (see Chapter IX of the Master Agreement) from the Legal Entity, its signing\nindividuals and any other persons, relating to any data becoming part of the LERD, to the LOU;\n\n17. the general requirement that any information provided, and applications and requests lodged,\nto the LOU must be submitted by the Legal Entity's authorized signatories, and duly dated and\nsigned;\n\n18. attestation of the authorities of the individual signing the contract on behalf of the Legal Entity.\n\n19. exclusive place of jurisdiction (only under exceptional circumstances being somewhere else than\nthe legal residence of the LOU);\n\n20. exclusive court competence either of the ordinary courts at the place of jurisdiction or an\nacknowledged and trusted arbitration court.\n\nThe LOU is explicitly prohibited to include in its contract with the Legal Entity that the LOU reserves\n\nthe right to transfer on its own initiative the LEl to any other local operating unit.\n\nGLEIS - Global LEI System Master Agreement Page 4 of 4\nGLEIF Appendix 05 — Master Copy Version 1.2\n2018-02-08-MA-Appendix-05-LOU-Contract-Requirements.docx 8 February 2018\n","contentLength":2833,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:28:17.612Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-03-31-ma-appendix-06-sla_2.1.pdf","content":"@, Protecting digtal st\nService Level Agreement\n(SLA)\n","contentLength":54,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:31.970Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-03-31-ma-appendix-06-sla_2.1.pdf","content":"Table of Contents\n1 Service Level Agreement GlOSSary.....ccccceeecerreirieenierenecrrencreencsranseeennsees 3\n2 GLEIF Services - Service Descriptions ......cccccceveieeeceenereeencrenreecseecenscencennees 7\nD R O 10 I Yool o =T [ =1 o] o PP RUPRURTRRY\n2.2 LOU Annual Accreditation Verification .......ccccccceeeeeiiiiiiiieiieeieeeeee e 9\n2.3 Upload LEI & LE-RD Fil€S .....uuuivieeieciiiieeeeccciiieeeeeeeciteeeeeeecvvneeeeesesnnneeeeeeesnneneeeees 11\n2.4 Check fOr DUPIICAtES ...ueiiiiririeiieeiesiiee et stee e e e srareeee s sasbeeesesssasnnneeeses 12\n2.5 Trigger LEl management transfer......ccccovviiviiiieiiiiiiecie s seivieee s esiiieeeee e 13\n2.6 LOU Communications Portal........cccccoiievieeeiieiie e cccvinvieeeeeeee e e e e e e e e ennns 14\nD A o o [ I T 4 PRPUPUURPPRURRR: o\n2.8 Data Governance Pre-Check ......cccciuiiueieeeeeeiieeie e cccccciievieeieeeeeeeeeeeeeeeenseennnens 17\n3 The LOU Services — Service Descriptions.....ccccccceeeeecerencrencernecrennrenneeenee. 18\n3.1 1SSUE NEW LED .ot sse v s s eevnsnsnssesnennnes 20\n3.2 Maintain Legal Entity EVENTS.....cciiiiiiiiiiiiiiciiiece e snnne e ssnnneeee s 24\n3.3 Challenge LEI Data........cuiieviiiiiieeee ettt sire e ee s ssanveeee s s savsnaeeessinnaeeeees 27\n3.4 Transfer of LEISANd LE-RD .......ccoooeoieceteeieeeeee e esevnnnrneeneeeeeneeeeeeeeees 29\n3.5 ReNEWAIS OF LEIS....uuiuiiiiieiieieeie ettt ee e ecvrrnesneseseeeeeeeeeeeeees 31\n4 Monitoring and Service Level Breaches.......c.cccceeereeniirreeccreeiceenncereenen. 35\n4.1 Service Level calculation and monitoring.........ccccceevevviieeeeiiisiiie e esiiieee e essiieens 35\n4.2 Maintenance windows at GLEIF...........c.cccooiiiiiiiiiiie e eeccccccrrerreeeeee e ee el 38\n4.3 Service LeVel BreaChEs .....uuuuiiiiieiie ettt ee e e e e et raesaeeeeeeeeeeeees 38\n4.4 Escalation Management.....ccccciriiieiiiniiiie e eriieee s esiiieeee s siinsee e e s snaneeeesnnnnneees 39\n45 Termination. ..o e e srri s seseaai s s s saesennesssessennnneees B0\n/N I S or-1F- [ o] o I O] o - [ o1 £SO PPSPRRRRRY” 10\n5 Incident Management.........cccoireeiieniiinniieeiiineiiinnieninnecsennesesesnesssseeee 41\n5.1 MajJor INCIAENT...ciiiiiiiiiieee ettt srre e s sssrareeee s s sansneesessnnneneeeees D2\n6 complaints............................................................................................43\n7 GLEIF Code of Conduct in case of a disaster.......cccceeeerrrunncirrrrnnnicrrennnenn. . 44\n8 SLA Reports...........................................................................................46\n9 Change of Service Levels .......cceeeucirreeiiieeiiienciienineencnrenesenncesnnsenennneensd 7\nService Level Agreement (SLA) Page 2 of 47\n@ Public Version 2.1\n2022-03-31_MA-Appendix-06-SLA_v2.1.docx 2022-03-31\n","contentLength":2732,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:31.970Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-03-31-ma-appendix-06-sla_2.1.pdf","content":"2.3 Upload LEI & LE-RD Files\nName Upload LEI & LE-RD Files\nTag Line Interface for local operating units to upload LEI & LE-RD.\nDescription Via an interface the LOUs are required to upload the LElI & LE-RD\nfiles to the Global LEI Repository daily.\nData is represented in the Common Data File Formats. Details will be\nclarified in Implementation Notes.\nThe interface provides quality gates for testing of the data. Files or\nrecords not passing the quality tests will be rejected.\nEssential Tasks o Provide upload interface\n¢ Contact the LOU in case of rejections\no Provide and process quality checks\no Incorporate the LEl and LE-RD, uploaded by the LOU, after\npassing the quality tests, into the Global LEI Repository\no Ensure that the LEl and LE-RD uploaded by the LOU and\nincorporated into the GLEIF Concatenated File is a true and\nauthentic copy of the LEl as issued and of the LE-RD as provided\nby the LOU !\nAccess Group(s) Accredited local operating units\nThe LOU Tasks o Send data in Common Data File Format\nAvailability 99,9 % (Monday — Sunday 00:00 — 24:00)\nProcessing Time Within 1 hour upon arrival\nWorkload Limit 30 concurrent (i.e. within 1 minute) file uploads with an average file\nsize up to 20 megabytes (zipped)\nException In case the Continuity process is invoked (ref. chapter 7)\n1 The LOU takes note, understands and accepts that incorporation of the LEl and LE-RD as issued and provided\nrespectively by the LOU into the Global LEI Repository, and publishing those, entails no responsibility or liability\nwhatsoever of GLEIF for the LEl and the LE-RD as such, i.e. regarding their validity, completeness, accurateness,\nuniqueness and authenticity.\nService Level Agreement (SLA) Page 11 of 47\n@ Public Version 2.1\n2022-03-31_MA-Appendix-06-SLA_v2.1.docx 2022-03-31\n","contentLength":1780,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:31.970Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-03-31-ma-appendix-06-sla_2.1.pdf","content":"2.4 Check for Duplicates\nName Check for Duplicates\nTag Line Technical interface to allow GLEIF and the LOU to check for\nduplicate LEl and LE-RD data prior to finally issuing a New LEL.\nDescription In order to support the local operating units, GLEIF provides the\nappropriate and mandatory processes and a technical interface for\nlocal operating units to check the LEl and LE-RD data for duplicate\nentries. The LOU follows the required steps prior to assigning a valid\nLEI code to a Legal Entity. Details will be clarified in an\nImplementation Note.\nEssential Tasks o Provide technical interface to check for Duplicates\n¢ Automatically inform about check result\nAccess Group(s) Accredited local operating units\nThe LOU Tasks o Perform check for Duplicates\no Evaluate check result\nAvailability 99,9 % (Monday — Sunday 00:00 — 24:00)\nProcessing Time <1 minute\nWorkload Limit 500 requests in total within the same minute\nException In case the Continuity process is invoked (ref. chapter 7)\nService Level Agreement (SLA) Page 12 of 47\n@ Public Version 2.1\n2022-03-31_MA-Appendix-06-SLA_v2.1.docx 2022-03-31\n","contentLength":1102,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:31.970Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-03-31-ma-appendix-06-sla_2.1.pdf","content":"2.5 Trigger LEl management transfer\n\nName Trigger LEI management transfer\n\nTag Line Trigger the porting of all LEI & LE-RD from one local operating unit to\nanother local operating unit or GLEIF in certain cases.\n\nDescription GLEIF triggers a transfer of the management authority for one or\nmore LEls from the LOU when the LOU is either unable or\nunauthorized to provide service, or at the expiry of the Master\nAgreement. Details will be clarified in an Implementation Note.\n\nIn the case that a Legal Entity triggers the transfer of its own LEls,\nGLEIF and this service are not involved.\n\nEssential Tasks o Trigger LEl management transfer\n* Monitor open transfer instances\n\nAccess Group(s) Accredited local operating units\n\nThe LOU Tasks o Cooperate in transfer management\n\nCompleteness No LEls are left without any operating managing LOU for more than\n48 hours during GLEIF business days.\n\nIn case of force majeure, GLEIF shall trigger this process within 48\nhours during GLEIF business days, given the impacted LOU stops LEI\nfile daily upload and does not provide business as usual\nconfirmation.\n\nWorkload Limit 4 concurrent LOUs\n\nException In case the Continuity process is invoked (ref. chapter 7)\n\nService Level Agreement (SLA) Page 13 of 47\n@ Public Version 2.1\n2022-03-31_MA-Appendix-06-SLA_v2.1.docx 2022-03-31\n","contentLength":1318,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:31.970Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-03-31-ma-appendix-06-sla_2.1.pdf","content":"2.6 LOU Communications Portal\n\nName LOU Communications Portal\n\nTag Line A central web-based communication portal for all communications\nbetween GLEIF and LOU.\n\nDescription This service provides a central location for accessing LOU-Only\ninformation where LOUs can share information and experience\namong themselves regarding LEI Services. It also provides the master\nsource for all the information related to the LOUs.\n\nThe functionalities provided within this service are a shared calendar\nfor all LOUs, a repository of information, a common platform to raise\nquestions / request feedback, and a web interface for Service Level\nAgreement (SLA) reporting.\nEssential Tasks Register an account for the Communication Portal:\ne Provide registration to Portal\no Verify registration authority\n* Manage registration information\n* Provide possibility to change password / get new password\n¢ Send access information\no Verify email addresses\no Archive registration information until deregistration\nProvide Calendar & Events:\no Collect internal GLEIF, local operating unit and GLEIS events\no Edit and update the calendar\n* Provide and maintain local operating unit calendar & events\n* Manage subscriptions to provide local operating unit calendar\nupdates\n¢ Provide numbered messages\n¢ Provide a platform for LOUs to communicate among themselves\n¢ Provide a means for receipt of feedback and discussion on\ndifferent topics\nProvide a repository for LOU related information, in order to:\n¢ Share documentations related to LOU Accreditation and LOU\nAnnual Accreditation Verification between an LOU (applicant,\ncandidate or accredited) and GLEIF\no Collect LOUs information in the portal\no Share GLEIF contact information with LOUs\n¢ Exchange certain information among LOUs\nService Level Agreement (SLA) Page 14 of 47\nGLEIF Public Version 2.1\n@ 2022-03-31_MA-Appendix-06-SLA_v2.1.docx 2022-03-31\n","contentLength":1877,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:31.970Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-03-31-ma-appendix-06-sla_2.1.pdf","content":"For the accredited LOUs additional functionalities are available such\nas:\no Access to electronic Invoices (see Appendix 07, Payments)\no Access to SLA reports\no SLA web interface to incorporate defined service level data\nAccess Group(s) o Accredited local operating units\no Candidate local operating units\nThe LOU Tasks o Enter valid registration information\no Periodically review list of Authenticated users for the LOU and\nconfirm the Authenticated users' access and access roles\no Deliver upcoming events to GLEIF\no Subscribe to local operating unit calendar updates\no Unsubscribe in case local operating unit calendar updates are not\nneeded anymore\no Subscribe to numbered messages\no Unsubscribe to numbered messages\no Collate LOU service level data and submit it for SLA Report.\n¢ Review uploaded SLA report and provide feedback if applicable\no Check electronic LOU invoices provided\nAvailability 97,7 % (Monday — Sunday 00:00 — 24:00)\nProcessing Time o To register an account within one GLEIF business day\nWorkload Limit 20 queries per GLEIF business day\nException In case the Continuity process is invoked (ref. chapter 7)\nService Level Agreement (SLA) Page 15 of 47\n@ Public Version 2.1\n2022-03-31_MA-Appendix-06-SLA_v2.1.docx 2022-03-31\n","contentLength":1245,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:31.970Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-03-31-ma-appendix-06-sla_2.1.pdf","content":"2.7 Code Lists\nName Code Lists\nTag Line Maintain code lists referenced in Common Data File Formats\nDescription This service provides a standard process for identifying and\nincorporating updates to code lists in the Common Data File (CDF)\nformats.\nExamples of code lists include the Registration Authority list\nreferenced for the Registration Authority and Validation Authority\nfields of LEI CDF file format and the Entity Legal Form code list (ISO\nStandard 20275) referenced for the Legal Form field of LEI CDF file\nformat. It also includes the Corroboration Compliance List code list,\nthat provides information about the minimum expected\ncorroboration level of an LEl corresponding to the declared ELF code\nas a legal form. Breach is defined, when an LEI declares a lower\ncorroboration level than expected.\nEssential Tasks GLEIF o Collect feedback from stakeholders on code lists (if applicable)\no Decide if the change is appropriate (if applicable)\n© Assess data quality program to ensure changes to code lists are\nincorporated\no Update GLEIF databases for correct representation of current\nand past code lists\n* Update website and other GLEIF communications with changes\nin code lists\no Provide code lists in on-line master datasource\nAccess Group(s) Accredited local operating units and Public\nThe LOU Tasks o Appropriate use of the code lists in the relevant CDF fields (e.g.\nincluding reserved codes ‘8888’ and ‘RA888888’, to be used only\nafter a request for addition has been sent to GLEIF)\no Propose updates to the code lists\nAvailability GLEIF Website 99,9 % (Monday — Sunday 00:00 — 24:00)\nWorkload Limit 100 concurrent (i.e. within 1 minute) codelist downloads with an\naverage file size up to 1 megabyte\nException In case the Continuity process is invoked (ref. chapter 7)\nService Level Agreement (SLA) Page 16 of 47\n@ Public Version 2.1\n2022-03-31_MA-Appendix-06-SLA_v2.1.docx 2022-03-31\n","contentLength":1900,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:31.970Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-03-31-ma-appendix-06-sla_2.1.pdf","content":"2.8 Data Governance Pre-Check\n\nName Data Governance Pre-Check\n\nTag Line A facility to allow the LEl issuers to perform data quality checks on\nLEI Record Sets prior to publication of newly issued or updated LEls\ninto the Global LEI System.\n\nDescription In order to improve the overall data quality in the Global LEI System,\nGLEIF provides the LEl issuers a facility to evaluate the data quality\non LEI Record Sets prior to publication into the Global LEI\nRepository.\n\nThe facility provides the result of the assessment and delivers the\nexact reason for the failures. This enables the LEl issuers to\nremediate potential issues in a timely and efficient manner.\n\nIn scope are new and to be updated LEI Record Sets. The LEl issuers\ncan use the facility unlimited times for the same LEI Record Set.\nBoth an API and a user-friendly graphical user interface (GUI), which\nenables the manual usage of the Pre-Check facility, are provided.\n\nEssential Tasks o Provide API to Data Governance Pre-Check\n¢ Provide user-friendly GUI for easy usage of the Data Governance\n\nPre-Check\n* Automatically inform about check results and failure reasons\n\nAccess Group(s) e APl and GUI in production: accredited LOUs\no Test APl and GUI: accredited and candidate LOUs\n\nThe LOU Tasks ¢ Send new or changed LEI Record Set to the facility prior to\n\npublication\n¢ Remediate check failures\n\nAvailability API: 99,9 % (Monday — Sunday 00:00 — 24:00)\nGUI: 97,7 % (Monday — Sunday 00:00 — 24:00)\n\nProcessing Time < 3 seconds per request\n\nWorkload Limit 1000 requests in total within the same minute\n\nException In case the Continuity process is invoked (ref. chapter 7)\n\nService Level Agreement (SLA) Page 17 of 47\n@ Public Version 2.1\n2022-03-31_MA-Appendix-06-SLA_v2.1.docx 2022-03-31\n","contentLength":1751,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:31.970Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-03-31-ma-appendix-06-sla_2.1.pdf","content":"3 The LOU Services — Service Descriptions\nThe services of the LOU set out in this Service Level Agreement are all related to the issuance of New\nLEls and maintenance of LEls and related LE-RD, and transmission of all LEI and LE-RD to GLEIF. The\ncredibility and trust of the public in the GLEIS is deeply anchored to the credibility and trust in the\nLEls and LE-RD and the transmission of this information to GLEIF.\nAs agreed in Section 22 of the Master Agreement, LEls and related LE-RD must be correct, complete,\naccurate, unique and true LEls and LE-RD not only when they are issued, but throughout the life of\nthe LEI (e.g. in the course of updating Legal Entity Events and managing challenges, transfers, and\nrenewals).\nThe LEI and the related LE-RD collected about, or collected from, the Legal Entity, or created by the\nLOU in the course of issuance, transfer, and maintenance of the LEIl, must be uploaded to GLEIF\naccurately and reliably, and by performing the LOU Services set out in this chapter.\nTo ensure compliance with its Core Duties, the LOU shall provide means and processes for improving\noperational quality and performance. The LOU is responsible that the third party has such processes\nas well.\nThe following table shows the service levels that are applicable for all LOU services.\nData Governance 100% of all new and updated LEI Record Sets shall be evaluated via\nPre-Check Completeness Data Governance Pre-Check. The assessment must be performed in\nno more than 4 calendar days (i.e. in no more than 96 hours) before\nthe upload to GLEIF.\nData Quality Failure Age Failed Data Quality Checks must be remediated within 60 calendar\ndays\nJurisdiction Compliance There shall be no LEls in status ISSUED outside accredited\njurisdictions\nLOU Annual Accreditation LOUs must complete any required remediation action based upon\nVerification - Remediation | the LOU Annual Accreditation Verification follow up schedule, as\nof Findings listed in the LOU Annual Accreditation Verification report.\nNumber of New Duplicates =0\nRequired Quality Rate = 100% each calendar day — up to 7 calendar days granted per\ncalendar month\nExpected Quality Rate > 99% each calendar day — up to 7 calendar days granted per\ncalendar month\nService Level Agreement (SLA) Page 18 of 47\n@ Public Version 2.1\n2022-03-31_MA-Appendix-06-SLA_v2.1.docx 2022-03-31\n","contentLength":2344,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:31.970Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-03-31-ma-appendix-06-sla_2.1.pdf","content":"Excellent Quality Rate > 98% each calendar day — up to 7 calendar days granted per\ncalendar month\nUpload Failure Rate =0%\nThe LOU performs the following services to comply with its Core Duties.\nService Level Agreement (SLA) Page 19 of 47\n@ Public Version 2.1\n2022-03-31_MA-Appendix-06-SLA_v2.1.docx 2022-03-31\n","contentLength":310,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:31.970Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-03-31-ma-appendix-06-sla_2.1.pdf","content":"3.1 Issue New LEI\ne\nDescription The LOU provides the means for a Legal Entity to request an LEI.\nR\nEssential Tasks o Verify the Legal Entity is from a Country the LOU has been\naccredited for (jurisdiction check).\no Provide and execute a contract with the Legal Entity applying\nfor and holding the LEI. This contract must comply with the\nrequirements of Appendix 05.\n¢ Publish to its website information helping a Legal Entity apply\nfor an LEI (see Website Requirements in the Accreditation\nChecklist referenced in the Accreditation Manual, Appendix\n02).\n¢ Provide an interface or mechanism for the Legal Entity to apply\nfor an LEI\ne Maintain procedures for verifying via an authoritative source\nthe accuracy of the LE-RD supplied by the Legal Entity\ne Maintain procedures for verifying the existence and eligibility\nof the entity applying for the LEI\no Verify the individual signing the application and any pertaining\ndocuments is duly empowered to submit such application in\nthe name and on behalf of the Legal Entity\no Ensure an up-to-date list of authoritative sources used for\nVerification is maintained, accessible and usable at all times\nwith no restrictions\no Verify the existence of the entity applying for the LEI\no Validate the LE-RD\no Verify via the applicable authoritative source, as submitted in\nthe Accreditation Documentation (Appendix 04), the accuracy\nof the LE-RD supplied in the LEl request; Transliterate in roman\ncharacters (as applicable)\no Perform automated data checks or data edits of specific fields\nper the Common Data File Formats\n¢ Inform the Legal Entity about any missing or wrong entries\no Check for Duplicates\no Make use of Service 2.4, and if Duplicate is reported\no Contact another local operating unit\no Contact the applicant for the LEl or Legal Entity\nService Level Agreement (SLA) Page 20 of 47\nGLEIF Public Version 2.1\n@ 2022-03-31_MA-Appendix-06-SLA_v2.1.docx 2022-03-31\n","contentLength":1913,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:31.970Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-03-31-ma-appendix-06-sla_2.1.pdf","content":"1 Service Level Agreement Glossary\nNote: All definitions of terms in the Master Agreement are valid also for the Service Level Agreement\nand prevail\n\nAccess Groups Allowed customers of the service.\n\nApplication Programming | The Application Programming Interface (API) is a computing interface\n\nInterface (API) which defines interactions among software intermediaries.\n\nAttended Service Time of reachability of GLEIF support on business days.\n\nOperating Time\n\nAuthenticated Local operating units that have subscribed to the restricted GLEIF\nsection on gleif.org and have a login name and a password.\n\nAvailability Ability of a service to perform its agreed function when required.\n\nCalendar days Calendar days means every day on the calendar, including weekends\nand public holidays.\n\nComplaint A written, formal expression of dissatisfaction from LOU’s Relations\nManager/authorized signatory related to GLEIF services and relevant\nrequirements.\n\nCustomer Portal Portal for LOUs to perform defined processes.\n\nData Quality Campaign Complete, planned course of actions formulated to achieve defined\ndata quality objectives.\n\nData Quality Checks The definition of (series of) rules, usually in a form of if-then-else\nconditions, that a data record must fulfill in order to achieve certain\ndata quality criteria and maturity levels.\n\nData Quality Failure A pair of a LEI Record Set and a Data Quality Check, where the LEI\nRecord Set does not fulfill the described rules.\n\nData Quality Rule Setting | A set of defined Data Quality Checks to establish a transparent and\nobjective benchmark to assess the level of data quality within the\nGlobal LEI System. Please refer to the GLEIF website for the current\nversion of the Rule Setting.\n\nDescription Detailed description that also identifies the service interface and its\noutcomes.\n\nDisaster Extraordinary situation where widespread human, material, economic\n\nService Level Agreement (SLA) Page 3 of 47\n@ Public Version 2.1\n2022-03-31_MA-Appendix-06-SLA_v2.1.docx 2022-03-31\n","contentLength":2017,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:31.970Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-03-31-ma-appendix-06-sla_2.1.pdf","content":"e Contact GLEIF\no Issue the LElI in compliance with ISO 17442 along with the\npertaining LE-RD, and in accordance with the current Data\nQuiality Rule Setting.\no Process or receive payment for the New LEI\n¢ Inform the LEl applicant of the application result\no Upload to GLEIF the New LEl and all LE-RD collected from the\nLegal Entity or created by the LOU before bulk transmission or\npublication to another third party, where however transmission\nto the Legal Entity and normal publication to the LOU website\n(as agreed in in the Accreditation Documentation Appendix 04)\nare permitted\no Accept and without undue delay process applications for an LEI\n¢ The related facility shall be kept available to the public at least\n99.9% of the time each month\nExamples of Third Party Registration o Publish to its website information helping a\nAssistance Agent Legal Entity apply for an LEI with the LOU\no Collect and transmit to the LOU the information\nrequired to verify the existence of the entity\napplying for the LEI\no Contact the applicant for the LEIl or the Legal\nEntity requesting it explain why there is a\nDuplicate (if applicable)\no Process or receive secure payment for the New\nLEI\n¢ Inform the Legal Entity of application status\nValidation * Provide and execute a contract with the Legal\nAgent Entity applying for and holding the LEI. This\ncontract must comply with the requirements of\nAppendix 05 (e.g. by referencing the LOU’s\nterms & conditions for the issuance of LEls).\n¢ Maintain procedures for verifying via an\nauthoritative source the accuracy of the LE-RD\nsupplied by the Legal Entity\no Ensure an up-to-date list of authoritative\nsources used for Verification is maintained,\naccessible and usable at all times with no\nrestrictions\n¢ Maintain procedures for verifying the existence\nand eligibility of the entity applying for the LEI\no Maintain procedures for verifying the individual\nService Level Agreement (SLA) Page 21 of 47\n@ Public Version 2.1\nG 2022-03-31_MA-Appendix-06-SLA_v2.1.docx 2022-03-31\n","contentLength":2010,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:31.970Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-03-31-ma-appendix-06-sla_2.1.pdf","content":"signing the LEI application is duly empowered\ntodo so\no Verify the individual signing the application and\nany pertaining documents is duly empowered\nto submit such application in the name and on\nbehalf of the Legal Entity\n« Verify the existence of the entity applying for\nthe LEI\n¢ Validate the LE-RD\no Verify via an applicable authoritative source,\nthe accuracy of the LE-RD supplied in the LEI\nrequest\n¢ Inform the Legal Entity about any missing or\nwrong entries\no Inform the Legal Entity on the application result\nOthers ¢ Provide an interface or mechanism for the\nLegal Entity to apply including automated data\nchecks or data edits in the collection of Legal\nEntity application information\n* Provide data collection or aggregation services\nfrom the authoritative sources agreed upon\nwith the LOU\no Transliterate in roman characters (as\napplicable)\no Make use of Service 2.4, and if Duplicate is\nreported\no Contact another local operating unit\no Contact the applicant for the LEI, Validation\nAgent or Legal Entity\no Contact GLEIF\n¢ Upload the New LEIl and associated LE-RD to\nGLEIF\nEssential Tasks excluded o Editorial access to all LEls and LE-RD with the LOU prefix at all\nfrom Third Party Services times\n¢ Maintain a procedure for monitoring and updating a list of\nreliable sources to validate LE-RD, as submitted in the\nAccreditation Documentation (Appendix 04), and approved by\nGLEIF\nService Level Agreement (SLA) Page 22 of 47\nGLEIF Public Version 2.1\n@ 2022-03-31_MA-Appendix-06-SLA_v2.1.docx 2022-03-31\n","contentLength":1514,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:31.970Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-03-31-ma-appendix-06-sla_2.1.pdf","content":"Completeness Duplicates - Levell before being uploaded to GLEIF\nService Level Agreement (SLA) Page 23 of 47\n@ Public Version 2.1\n2022-03-31_MA-Appendix-06-SLA_v2.1.docx 2022-03-31\n","contentLength":180,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:31.970Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-03-31-ma-appendix-06-sla_2.1.pdf","content":"3.2 Maintain Legal Entity Events\n\nName Maintain Legal Entity Events\n\nTag Line The LOU maintains the LEI data for Legal Entity Events reported by\n\nthe Legal Entity.\n\nDescription The LOU provides an interface or a mechanism for Legal Entities to\n\nupdate their LE-RD managed by the LOU. The LOU verifies all Legal\nEntity Events updates requested by the Legal Entity via an\nauthoritative source. For those changes verified by the LOU, the\nLOU ensures the changes are promptly incorporated into the LE-\nRD. The LOU uploads the updated LEI record to GLEIF by using\nService 2.3.\n\nEssential Tasks o Provide an interface or mechanism for the Legal Entity to\nupdate LE-RD including means for automated data checks or\ndata edits\n\ne Maintain procedures for verifying the individual requesting the\nchange is duly empowered to do so\n\no Verify the individual requesting the change is duly empowered\nto do so on behalf of the Legal Entity\n\ne Maintain procedures for verifying via an authoritative source\nthe accuracy of the reported Legal Entity Events\n\no Ensure an up-to-date list of authoritative sources used for\nVerification is maintained, accessible and usable at all times\nwith no restrictions\n\n* Validate the LE-RD\n\no VERIFY via the applicable authoritative source, as submitted in\nthe Accreditation Documentation (Appendix 04), the accuracy\nof the Legal Entity Events change; Transliterate in roman\ncharacters (as applicable)\n\n¢ Inform the Legal Entity of the updated LE-RD\n\no Upload to GLEIF, using Service 2.3, the updated LE-RD collected\nfrom the Legal Entity or created by the LOU before bulk\ntransmission or publication to another third party excluding the\nLegal Entity and normal publication to the LOU website as\ninformed in in the Accreditation Documentation (Appendix 04)\n\no Accept and without undue delay initiate the process to\nimplement updates provided by a Legal Entity regarding its LEI\nmanaged by the LOU\n\n¢ The related facility shall be kept available to the public at least\n\nService Level Agreement (SLA) Page 24 of 47\n@ Public Version 2.1\n2022-03-31_MA-Appendix-06-SLA_v2.1.docx 2022-03-31\n","contentLength":2101,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:31.970Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-03-31-ma-appendix-06-sla_2.1.pdf","content":"99.9% of the time each month\nExamples of Third Party Registration Agent * None\nAssistance\nValidation Agent ¢ Provide an opportunity for the Legal\nEntity to update LE-RD\n\ne Maintain procedures for verifying the\nindividual requesting the change is duly\nempowered to do so\n\no Verify the individual requesting the\nchange is duly empowered to do so on\nbehalf of the Legal Entity\n\ne Maintain procedures for verifying via an\nauthoritative source the accuracy of the\nreported Legal Entity Events\n\n* Validate the LE-RD\n\no Verify via the applicable authoritative\nsource the accuracy of the Legal Entity\nEvents change\n\n¢ Inform the Legal Entity of the updated\nLE-RD\n\no Accept and without undue delay initiate\nthe process to implement updates\nprovided by a Legal Entity regarding its\nLEI\n\n¢ Inform the Legal Entity of updated LE-RD\n\nOthers o Transliterate in roman characters (as\napplicable)\n\n* Provide data collection or aggregation\nservices from the authoritative sources\nagreed upon with the LOU\n\no Upload the changed LE-RD to GLEIF\n\nEssential Tasks excluded o Editorial access to all LEls and LE-RD with the LOU prefix at all\nfrom Third Party Services times\ne Maintain a procedure for monitoring and updating a list of\nreliable sources to validate LE-RD, as submitted in the\nAccreditation Documentation (Appendix 04), and approved by\nGLEIF\n¢ Ensure an up-to-date list of authoritative sources used for\nService Level Agreement (SLA) Page 25 of 47\n@ Public Version 2.1\n2022-03-31_MA-Appendix-06-SLA_v2.1.docx 2022-03-31\n","contentLength":1510,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:31.970Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-03-31-ma-appendix-06-sla_2.1.pdf","content":"Verification is maintained, accessible and usable at all times\nwith no restrictions\nAccess Group(s) Legal Entities via the LOU Terms & Conditions\nService Level Agreement (SLA) Page 26 of 47\n@ Public Version 2.1\n2022-03-31_MA-Appendix-06-SLA_v2.1.docx 2022-03-31\n","contentLength":262,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:31.970Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-03-31-ma-appendix-06-sla_2.1.pdf","content":"3.3 Challenge LEI Data\n\nName Challenge LEI Data\n\nTag Line Challenge the data of any LEI and legal entity reference data (LE-\nRD) of the Global LEI repository on the GLEIF website.\n\nDescription GLEIF provides a mechanism for any third party to challenge the\ndata of any LEl and LE-RD of the Global LEI repository. A data\nchallenge that is submitted for a specific LEI (or LE-RD) will be\nforwarded to the corresponding managing LEl issuer. The actual\nresolution of data challenges is a service provided by the LEl issuer.\nDifferent challenges can be submitted, which the challenging user\nmust specify alongside evidence and an optional comment. The\navailable types are:\n\n- Legal Entity business card details\n- Legal Entity relationship details\n- LEl code\nEssential Tasks o Review and respond to LEI or LE-RD challenges transmitted by\nGLEIF\n\n¢ Research the content of the challenge and verify the challenge\nvia the applicable authoritative source, as submitted in the\nAccreditation Documentation (Appendix 04); Transliterate in\nroman characters (as applicable)\n\no Ensure an up-to-date list of authoritative sources used for\nVerification is maintained, accessible and usable at all times\nwith no restrictions\n\n¢ Inform the Legal Entity of verified challenges and of challenges\nwhich have failed Verification\n\n¢ Upload to GLEIF the updated LE-RD collected from the Legal\nEntity or created by the LOU (if applicable) before bulk\ntransmission or publication to another third party excluding the\nLegal Entity and normal publication to the LOU website as\ninformed in in the Accreditation Documentation (Appendix 04)\nor inform GLEIF that no change is to be made\n\nExamples of Third Party Registration * None\n\nAssistance Agent\n\nService Level Agreement (SLA) Page 27 of 47\n@ Public Version 2.1\n2022-03-31_MA-Appendix-06-SLA_v2.1.docx 2022-03-31\n","contentLength":1832,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:31.970Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-03-31-ma-appendix-06-sla_2.1.pdf","content":"Validation Agent | Inform the Legal Entity of verified challenges\nand of challenges which have failed\nVerification\nResearch the content of the challenge and\nverify the challenge via an authoritative data\nsource (if applicable)\n¢ Ensure an up-to-date list of authoritative\nsources used for Verification is maintained,\naccessible and usable at all times with no\nrestrictions\nOthers * Provide data collection or aggregation\nservices from the agreed upon\nauthoritative sources\n¢ Upload the adjusted LEI record to GLEIF (if\napplicable)\no Transliterate in roman characters (as\napplicable)\nEssential Tasks excluded o Editorial access to all LEls and LE-RD with the LOU prefix at all\nfrom Third Party Services times\no Review and respond to GLEIF relative to LEI or LE-RD challenges\ne Maintain a procedure for monitoring and updating a list of\nreliable sources to validate LE-RD, as submitted in the\nAccreditation Documentation (Appendix 04), and approved by\nGLEIF\nAccess Group(s) o GLEIF\nProcessing Time 15 calendar days\nService Level Agreement (SLA) Page 28 of 47\n@ Public Version 2.1\n2022-03-31_MA-Appendix-06-SLA_v2.1.docx 2022-03-31\n","contentLength":1129,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:31.970Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-03-31-ma-appendix-06-sla_2.1.pdf","content":"3.4 Transfer of LEls and LE-RD\n\nName Transfer of LEIs and LE-RD\n\nTag Line The LOU participates in and enables transfers of LEls and LE-RD\nfrom or to another local operating unit.\n\nDescription The LOU on behalf of a Legal Entity can notify another local\noperating unit of a request to transfer LEl management. Both local\noperating units follow the required steps to complete the transfer.\n\nEssential Tasks o Provide and execute a contract with the Legal Entity for holding\n\nthe LEI. This contract must comply with the requirements of\nAppendix 05.\ne Maintain procedures for verifying the individual requesting the\nLEI transfer is duly empowered to do so\no Verify the individual requesting transfer is duly empowered to\ndo so on behalf of the Legal Entity\n* Validate the LE-RD\no Verify via the applicable authoritative source, as submitted in\nthe Accreditation Documentation (Appendix 04), the accuracy\nof the LE-RD; Transliterate in roman characters (as applicable)\no Ensure an up-to-date list of authoritative sources used for\nVerification is maintained, accessible and usable at all times\nwith no restrictions\no Keep the Legal Entity informed (as applicable)\no Upload to GLEIF, using Service 2.3, the LEl and its changed LE-\nRD collected from the Legal Entity or created by the LOU before\nbulk transmission or publication to another third party\nexcluding the legal entity and normal publication to the LOU\nwebsite as informed in in the Accreditation Documentation\n(Appendix 04)\n¢ Participate in and enable transfers of one or several LEI(s) and\nLE-RD from or to another local operating unit on request of the\nLegal Entity, a local operating unit on behalf of a Legal Entity, or\nthe GLEIF\no The transfer of an LEl and related LE-RD as Sending LOU shall\nbe performed in 4 LOU business days\no The transfer the LEIl and related LE-RD as Receiving LOU shall be\nService Level Agreement (SLA) Page 29 of 47\n@ Public Version 2.1\n2022-03-31_MA-Appendix-06-SLA_v2.1.docx 2022-03-31\n","contentLength":1972,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:31.970Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-03-31-ma-appendix-06-sla_2.1.pdf","content":"performed in 3 LOU business days\n¢ Once transferred, the LOU shall unpublish the LEIl and related\nLE-RD within 1 LOU business day from when the transferred LEI\nis displayed as “ISSUED” on GLEIF search facility\nExamples of Third Party Registration * None\nAssistance Agent\nValidation o Keep the Legal Entity informed\nAgent .\n\ng ¢ In case of termination of validation agent\ncontract with the LOU or client consent with\nthe Legal Entity, initiate the transfer to the LOU\n\nOthers o Verify the individual requesting transfer is duly\nempowered to do so on behalf of the Legal\nEntity\no Provide data collection or aggregation services\nfrom the agreed upon authoritative sources\n* Validate the LE-RD\n« Verify via an authoritative source the accuracy\nof the LE-RD; Transliterate in roman characters\n(as applicable)\n¢ Upload the adjusted LEI record to GLEIF (if\napplicable)\nEssential Tasks excluded o Editorial access to all LEI and LE-RD with the LOU prefix at all\nfrom Third Party Services times\ne Maintain procedures for verifying the individual requesting the\nLEI transfer is duly empowered to do so\ne Maintain a procedure for monitoring and updating a list of\nreliable sources to validate LE-RD, as submitted in the\nAccreditation Documentation (Appendix 04), and approved by\nGLEIF\n¢ Ensure an up-to-date list of authoritative sources used for\nVerification is maintained, accessible and usable at all times\nwith no restrictions\nAccess Group(s) o Legal Entities to LOU which manages their LEI\no Validation Agents to the LOU which manages the LEI\no Accredited local operating units\nService Level Agreement (SLA) Page 30 of 47\n@ Public Version 2.1\n2022-03-31_MA-Appendix-06-SLA_v2.1.docx 2022-03-31\n","contentLength":1688,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:31.970Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-03-31-ma-appendix-06-sla_2.1.pdf","content":"or environmental losses have occurred which exceeded GLEIF’s ability\nto respond and recover using its own resources.\n\nDuplicate Either one LEI code exists more than once, or one Legal Entity has\nmore than one LEI.\n\nDuplicate Rate Shows how many Duplicates exist at the end of a month based on the\nGlobal LEI Repository.\n\nEssential Tasks Essential Tasks that are required to be performed by the service\nprovider to deliver the agreed service.\n\nEssential tasks excluded Essential tasks that must not be delegated to a Third Party Service\n\nfrom Third Party Services | provider, unless otherwise agreed in Appendix 13.\n\nExamples of Third Party The LOU may use Third Party Services to assist with its Essential Tasks\n\nAssistance but remains unrestrictedly responsible and liable for the execution of\nEssential Tasks. Subject to GLEIF’s approval which is set out in\nAppendix 14.\n\nExcellent Quality Rate The rate of LEI records that fulfill the excellent quality checks =\nmaturity level 3 checks as defined in the Data Quality Rule Setting.\n\nException Extraordinary situations, that will not be considered for the\ncalculation of a service level.\n\nExpected Quality Rate The rate of LEI records that fulfill the expected quality checks =\nmaturity level 2 checks as defined in the Data Quality Rule Setting.\n\nGLEIF business day Business day in Frankfurt am Main, Germany (Monday — Friday).\n\nGLEIF Concatenated File File generated daily by GLEIF which aggregates all files from all LOUs.\nIt contains all LEIl issues to legal entities and related LEI reference\ndata.\n\nGraphical User Interface The Graphical User Interface (GUI) is a form of user interface that\n\n(GUI) allows users to interact with applications and electronic devices.\n\nLegal Entity Event An event initiated by a Legal Entity that affects the securities (equity\nor debt) issued by that Legal Entity, and/or any other event that\naffects the LE-RD such as mergers, spinoffs, change of incorporation,\ndomicile, etc. It was previously referred to as Corporate Action.\n\nLEl Record Set An XML data record in CDF format describing one Legal Entity,\nincluding its related relationship information.\n\nLOU Local Operating Unit, also referred as LEl issuer.\n\nService Level Agreement (SLA) Page 4 of 47\n@ Public Version 2.1\n2022-03-31_MA-Appendix-06-SLA_v2.1.docx 2022-03-31\n","contentLength":2316,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:31.970Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-03-31-ma-appendix-06-sla_2.1.pdf","content":"3.5 Renewals of LEls\nName Renewals of LEls\nTag Line The LOU facilitates, at least annually, the renewal of the LEl and a\nreconfirmation of its LE-RD by the Legal Entity.\nDescription The LOU provides an interface or a mechanism for the Legal Entity\nto renew at least annually. The Legal Entity must formally apply for\nrenewal. The LOU ensures notification to the Legal Entity at least 6\nweeks prior to the renewal.\nGiven the Legal Entity has not successfully completed the renewal\nprocess at the renewal date, the LOU ensures the status of the LEI\nis adjusted to indicate the LEl is lapsed (as defined in the Common\nData File Format) on the next calendar day.\nThe LOU requires the Legal Entity to confirm that any and all data\nprovided in the preceding year are still valid or to supply changed\ndata.\nEssential Tasks o Ascertain the contract with the Legal Entity holding the LEI. This\ncontract must comply with the requirements of Appendix 05\n(e.g. by referencing the LOU’s terms & conditions for the\nissuance of LEIs).\n¢ Notify Legal Entity of upcoming renewal requirements\no Provide an interface or mechanism for the Legal Entity to\nrenew\ne Maintain procedures for verifying the individual requesting the\nLEl renewal is duly empowered to do so\no Verify the individual requesting renewal is duly empowered to\ndo so on behalf of the Legal Entity\n* Validate the LE-RD\no Verify via the applicable authoritative source, as submitted in\nthe Accreditation Documentation (Appendix 04), the accuracy\nof the LE-RD; Transliterate in roman characters (as applicable)\no Ensure an up-to-date list of authoritative sources used for\nVerification is maintained, accessible and usable at all times\nwith no restrictions\ne Maintain procedures for verifying via an authoritative source\nthe LE-RD supplied by the Legal Entity\nService Level Agreement (SLA) Page 31 of 47\n@ Public Version 2.1\n2022-03-31_MA-Appendix-06-SLA_v2.1.docx 2022-03-31\n","contentLength":1922,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:31.971Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-03-31-ma-appendix-06-sla_2.1.pdf","content":"o Perform automated data checks or data edits of specific fields\n¢ Inform the Legal Entity about any missing or wrong entries\no Make use of Service 2.4, and if Duplicate is reported\no Contact another local operating unit\no Contact the Legal Entity\no Contact GLEIF\no Upload the changed LE-RD to GLEIF\ne Process or receive payment for the renewal\no Adjust the LEI status as applicable to recognize renewal or non-\nrenewal\n¢ Inform the Legal Entity of renewal or non-renewal status\n¢ Upload to GLEIF the changed LE-RD collected from the Legal\nEntity or created by the LOU before bulk transmission or\npublication to another third party excluding the legal entity and\nnormal publication to the LOU website as informed in in the\nAccreditation Documentation (Appendix 04)\n¢ Collect and maintain metrics of data quality demonstrating the\nLOU notifies the Legal Entity of pending renewal requirements\nand accepts and without undue delay processes the renewal\n¢ The related facility shall be kept available to the public at least\n99.9% of the time each month\nExamples of Third Party Registration » None\nAssistance Agent\nValidation ¢ Notify the Legal Entity of upcoming renewal\nAgent requirements\no Ascertain the contract with the Legal Entity\nholding the LEI. This contract must comply\nwith the requirements of Appendix 05 (if\napplicable).\no Provide a procedure to renew the LEI for the\nLegal Entity\no Verify the individual requesting renewal is\nduly empowered to do so on behalf of the\nLegal Entity\nService Level Agreement (SLA) Page 32 of 47\n@ Public Version 2.1\n2022-03-31_MA-Appendix-06-SLA_v2.1.docx 2022-03-31\n","contentLength":1606,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:31.971Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-03-31-ma-appendix-06-sla_2.1.pdf","content":"» Validate the LE-RD\no Verify via the applicable authoritative\nsource the accuracy of the LE-RD\ne Maintain procedures for verifying the\nindividual requesting the LEI renewal is duly\nempowered to do so\ne Maintain procedures for verifying via an\nauthoritative source the LE-RD\n¢ Inform the Legal Entity about any missing or\nwrong entries\n¢ Inform the Legal Entity of renewal or non-\nrenewal status\n¢ Ensure an up-to-date list of authoritative\nsources used for Verification is maintained,\naccessible and usable at all times with no\nrestrictions\nOthers ¢ Provide an interface or mechanism for the\nLegal Entity to renew including automated\ndata checks or data edits in the collection of\nupdated Legal Entity information\n* Provide data collection or aggregation\nservices from authoritative sources\n¢ Transliterate in roman characters (as\napplicable)\no Make use of Service 2.4, and if Duplicate is\nreported\no Contact another local operating unit\no Contact the applicant for the LEI,\nValidation Agent or Legal Entity\no Contact GLEIF\no Upload the changed LE-RD to GLEIF\no Process or receive payment for the renewal\no Upload the changed LE-RD to GLEIF\no Collect and maintain metrics of data quality\ndemonstrating the LOU notifies the Legal\nService Level Agreement (SLA) Page 33 of 47\n@ Public Version 2.1\n2022-03-31_MA-Appendix-06-SLA_v2.1.docx 2022-03-31\n","contentLength":1346,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:31.971Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-03-31-ma-appendix-06-sla_2.1.pdf","content":"Entity of pending renewal requirements and\naccepts and without undue delay processes\nthe renewal\nEssential Tasks excluded o Editorial access to all LEI and LE-RD with the LOU prefix at all\nfrom Third Party Services times\no Adjust the LEI status as applicable to recognize renewal or non-\nrenewal\nAccess Group(s) o Legal Entities to the Validation Agent or the LOU which\nmanages their LEI\nService Level Agreement (SLA) Page 34 of 47\n@ Public Version 2.1\n2022-03-31_MA-Appendix-06-SLA_v2.1.docx 2022-03-31\n","contentLength":504,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:31.971Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-03-31-ma-appendix-06-sla_2.1.pdf","content":"e e e\n4 Monitoring and Service Level Breaches\nThe Service Levels ensure the required high quality of the GLEIS. It is therefore essential to closely\nmonitor the achievement of the agreed Service Levels. Dependent on the service, the LOU and GLEIF\nhave to monitor and report the Service Level metrics.\n4.1 Service Level calculation and monitoring\nThe following tables show the formulas on how to calculate the service levels committed by GLEIF\nand LOU services respectively.\nGLEIF Service Level calculations:\nAvailability Tmonth @ — T non availability® 100 GLEIF Webserver\nL —— x\nTmonth®\n(1) Minutes in the month\n(2) Minutes in the month when the service was not available (excluding planned maintenances)\nThe difference is calculated considering calendar days\nProcessing Time for Z(EndResponse(l) _ StartRequest™) GLEIF Data Gg\\{ernance\n“Data Governance Pre- ] x100 Pre-Check facility\nCheck” Z(Requests)(3)\n(1) Time stamp when reply has been provided\n(2) Time stamp when request has been submitted\nThe difference is calculated considering calendar days\n(3) Number of requests received in the month\nProcessing Time for o © GLEIF Check for\n“Check for Duplicates” Z(E”dR“p\"”se ~ StartRequest ) x100 Duplicates facility\nZ (Requests)(3)\n(1) Time stamp when reply has been provided\n(2) Time stamp when request has been submitted\nThe difference is calculated considering calendar days\n(3) Number of requests received in the month\nProcessing Time for\n“ & Z(EndResponseBD(l) - StartRequestBD(z))\nLOU Annual ~« ‘) x100\nAccreditation Z(Requests)(3)\n. .\nVerification (1) Time stamp when reply has been provided\n(2) Time stamp when request has been submitted\nThe difference is calculated considering GLEIF business days\n(3) Number of requests received in the month\nFrgcessmg 'I\"me for Z(EndResponse(l) _ StartRequest®) GLEIF Customer Portal\nincidents priority 1 ———————\"]x100\nchosed incidents priority 1\n(1) Time stamp when reply has been provided\n(2) Time stamp when request has been submitted\nThe difference is calculated considering calendar days during GLEIF business days\n(3) Number of requests received in the month\nPrgcessmg 'I\"me for Z(EndResponseBD(l) _ StartRequestBp™) GLEIF Customer Portal\nincidents priority 2 — ] x100\nchosed incidents priority 2\n(1) Time stamp when reply has been provided\nService Level Agreement (SLA) Page 35 of 47\nGLEIF Public Version 2.1\n2022-03-31_MA-Appendix-06-SLA_v2.1.docx 2022-03-31\n","contentLength":2411,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:31.971Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-03-31-ma-appendix-06-sla_2.1.pdf","content":"(2) Time stamp when request has been submitted\nThe difference is calculated considering GLEIF business days\n(3) Number of requests received in the month\nFrgcessmg 'I\"me for Z(EndResponseBD(l) _ tartkequestsn®) GLEIF Customer Portal\nincidents priority 3 — ] x100\nchosed incidents priority 3\n(1) Time stamp when reply has been provided\n(2) Time stamp when request has been submitted\nThe difference is calculated considering GLEIF business days\n(3) Number of requests received in the month\nfrocessmg T|'me'for Z(EndResponseBD(l) _ StartRequestBp®™) GLEIF Customer Portal\nLOU Accreditation — ——————x100\nApplicant Z(RequestS)(3)\nH H \"\ndocumentation review (1) Time stamp when reply has been provided\n(2) Time stamp when request has been submitted\nThe difference is calculated considering GLEIF business days\n(3) Number of closed applicant documentation reviews in the month\nfrocessmg T|'me'for Z(EndResponse(l) _ Startrequest®) GLEIF Customer Portal\nLOU Accreditation — =—————x100\nCandidate Z (Requests)®\nH H ”\ndocumentation review (1) Time stamp when reply has been provided\n(2) Time stamp when request has been submitted\nThe difference is calculated considering calendar days\n(3) Number of closed candidate accreditation documentations in the month\nfrocessmg Tlmg fo'r Z(EndResponseBD(l) _ StartRequestBp®) GLEIF Communications\nLOU Communications ————|x100 Portal\nPortal” - Register an Z(RequestS)“)\naccount (1) Time stamp when reply has been provided\n(2) Time stamp when request has been submitted\nThe difference is calculated considering GLEIF business days\n(3) Number of closed requests in the month\nPro'cessmg Time for Z (EndResponse® — StartRequest®) GLEIF Customer Portal\n”Trlgger LEI —_—\nManagement Transfer” ZTmnSfers @\n(1) Time stamp when the activity ended\n(2) Time stamp when the activity started\nThe difference is calculated considering GLEIF business days\n(3) Number of transfers requests received in the month\nfrocessmg Time for Z(EndResponse(l) _ StartRequest™) GLEIF Upload Facility\nUpload LEI & LE-RD ————\"—\"—]x100\nFiles” ZUploads ®\n(1) Time stamp when reply has been provided\n(2) Time stamp when request has been submitted\nThe difference is calculated considering calendar days\n(3) Number of upload requests received in the month\nService Level Agreement (SLA) Page 36 of 47\nGLEIF Public Version 2.1\n2022-03-31_MA-Appendix-06-SLA_v2.1.docx 2022-03-31\n","contentLength":2365,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:31.971Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-03-31-ma-appendix-06-sla_2.1.pdf","content":"LOU Service Level calculations:\nCheck for Duplicates , GLEIF Concatenated File\nZ (New issued LEIs verifed via Check for Duplicates)\nCompleteness - — —|x100\nX\nZ(New issued LEIs)\nData Governance Pre- Z(New or updated prechecked LEIs ) GLEIF Data Gg\\{ernance\nCheck Completeness =—————\"—\"—1x100 Pre-Check facility\nZ(New or updated LEIS)(Z) &\n(1) Number of LEIs in scope that have an entry with the same fingerprint (\") in the Pre-Check logs GLEIF Concatenated File\nas in the LEl uploaded to GLEIF, and having been uploaded to GLEIF within the requested number\nof calendar days since the execution of the Pre-Check.\n(2) Number of LEIs uploaded to GLEIF with a different fingerprint than last date. These are the\nLEls in scope for the metric.\n(*) Please refer at the end of this table\nData Quality Failure o GLEIF Concatenated File\nA ZData Quality Failures existing consecutively for more than 60 calendar days\nge\n(1) No LEI should fail the same check consecutively for more than the requested number of\ncalendar days\nExcellent Quality Rate Z(LEI records fulfilling excellent quality) GLEIF Concatenated File\n] x100\nZ(LEI Records within the LOU)\nThe rate is calculated daily\nService level = Number of calendar days the Quality Rate achieved the\ntarget\nExpected Quality Rate GLEIF Concatenated File\nZ (LEI record fulfilling expected quality)\n] x100\nZ(LEI Records within the LOU)\nThe rate is calculated daily\nService level = Number of calendar days the Quality Rate achieved the\ntarget\nJurisdiction Compliance o GLEIF Concatenated File\nZLEI(S) outside accredited jurisdictions\n(1) Only LEIs having Registration Status equal to ISSUED will be taken into account.\nFor each LEI:\n- If the “General Category” (CDF field Entity.EntityCategory) = FUND and the LEI has been issued\nor renewed after 01/04/2022, then the LEl jurisdiction (as in CDF field Entity.Legallurisdiction)\nshould be part of the accredited “FUND” jurisdictions.\n- In case the General Category = BRANCH, the country listed in the legal address (CDF field\nEntity.LegalAddress.Country) will be compared with the accredited “non FUNDs” jurisdictions.\n- For all the other LEIs, the LEI Issuer should be accredited for that jurisdiction (reference, list of\naccredited “non-FUND” jurisdictions).\nNumber of New o GLEIF Concatenated File\nDuplicates ZDuplicates\n(1) Number of introduced duplicates in the referring month. Of the LEls involved in a duplication,\nthe breach is ascribed to the newly issued LEI if the duplication occurred within 150 calendar\ndays from the upload date of the newer issued LEl and the Check for Duplicates listed possible\nduplicates for the LEI.\nLOU Annual GLEIF Customer Portal\nAccreditation Number of expired finding remediations\nVerification —\nRemediation of\nFindings\nService Level Agreement (SLA) Page 37 of 47\nGLEIF Public Version 2.1\n2022-03-31_MA-Appendix-06-SLA_v2.1.docx 2022-03-31\n","contentLength":2866,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:31.972Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-03-31-ma-appendix-06-sla_2.1.pdf","content":"Processing Time for 3 EndResponsend” startrequesisn®) GLEIF Customer Portal\n“Challenge LEI Data” —————]x100\nZ (Closed challenges)(3)\n(1) Time stamp when reply has been provided\n(2) Time stamp when request has been submitted\nThe difference is calculated considering calendar days\n(3) Number of closed challenges LEls in the month\nRequired Quality Rate . Wt records fulfitling required quaity) GLEIF Concatenated File\n= |x100\nZ(LEI Records within the LOU)\nThe rate is calculated daily\nService level = Number of calendar days the Quality Rate achieved the\ntarget\nUpload Failure Rate Z(Dayswithcomplete setoffilessucessfullyuploaded) GLEIF Upload FaCIIIty\n(CDF format (W) x100\nalendar days in the mont\ncompliance) 4\n(*) A fingerprint (type of hashsum) is generated for each LEI Record Set. Fingerprints will not take\ninto account the fields LastUpdateDate, InitialRegistrationDate, LegalEntityEventRecordedDate\n(when applicable) and all extensions. Also, the header information for RecordCount, ContentDate,\nFileContent, NextVersion and all extensions will be excluded. Lapsing LEls, i.e. records that are\nupdated in only in RegistrationStatus from ISSUED/PUBLISHED to LAPSED, will be excluded from the\nscope for the Data Governance Pre-check Completeness service level target.\n4.2 Maintenance windows at GLEIF\nGLEIF’s website and Global LEI Repository operate 24/7/365 without regular maintenance windows.\nIn case of exceptional maintenance windows GLEIF will announce them, whenever possible and on a\nbest effort’s basis, two weeks ahead via email and/or via LOU Communications Portal.\n4.3 Service Level Breaches\nIn case of Service Level breaches, the timely finding of a sustainable remediation is of predominant\nimportance for GLEIF and the LOU.\nBased on the results of the monthly SLA Reports, which are created and distributed by GLEIF, when\nService Level breaches occur the steps as for “4.2.1 Escalation Management” must be followed.\nService Level Agreement (SLA) Page 38 of 47\n@ Public Version 2.1\n2022-03-31_MA-Appendix-06-SLA_v2.1.docx 2022-03-31\n","contentLength":2055,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:31.972Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-03-31-ma-appendix-06-sla_2.1.pdf","content":"4.4 Escalation Management\nS == <=~ k»\\/ e —\n\nEscalation Level 1\n\nWhenever a breach is detected, an escalation is opened and the GLEIF Business Relations Manager\n\ncontacts the relevant Escalation Level 1 counterpart to notify them about the occurred Service Level\n\nbreach(es).\n\nThe LOU analyses the ascribed Service Level Breach(es) and, if not otherwise granted, within three\n\nLOU business days provides GLEIF with the breach root cause and an effective remediation plan.\n\nThe LOU must demonstrate the remediation latest by the second available SLA report after the\n\nescalation notification.\n\nIf both, the target SLA report and the following one, show that the remediation was successful, the\n\nEscalation Level 1 is closed.\n\nEscalation Level 2 will be triggered:\n\n¢ In case the LOU has not provided GLEIF with the breach root cause and an effective remediation\nplan within 3 LOU business days.\n\no If the Escalation Level 1 has been not remediated as required.\n\n* When a breach, that has been already managed via an Escalation Level 2 or higher, occurs again\nwithin the following 2 months after the escalation closure. In this case the escalation is opened\ndirectly as level 2, and the LOU must demonstrate the remediation by the next available SLA\nreport after the escalation notification. If the occurred breach cannot be remediated to get a\nclean report in the same month (e.g. the service level is breached already), remediation is\nexpected for the next month. GLEIF can exceptionally extend the remediation time in its sole but\nreasonable discretion upon request, and having received a complete and thorough explanation.\n\nEscalation Level 2\n\nWhenever an Escalation Level 2 is triggered, GLEIF’s Escalation Level 2 contact (or deputy) notifies\n\nthe Escalation Level 2 counterpart that Escalation Level 2 has been triggered.\n\nIn case the Escalation Level 2 is triggered from an exhausted level 1 (i.e. not because of a recurrent\n\nbreach), the LOU must demonstrate the remediation by the next available SLA report after the\n\nescalation notification. GLEIF can exceptionally extend the remediation time in its sole but\nreasonable discretion upon request, and having received a complete and thorough explanation.\nService Level Agreement (SLA) Page 39 of 47\n@ Public Version 2.1\n2022-03-31_MA-Appendix-06-SLA_v2.1.docx 2022-03-31\n","contentLength":2328,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:31.972Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-03-31-ma-appendix-06-sla_2.1.pdf","content":"If both the target SLA report and the following one show that the remediation was successful,\nEscalation Level 2 is closed.\nEscalation Level 3 will be triggered in case Escalation Level 2 is not remediated as required.\nEscalation Level 3\nWhenever an Escalation Level 3 is triggered, GLEIF’s Escalation Level 3 contact notifies the Escalation\nLevel 3 counterpart requesting the breach root cause is understood and a final effective remediation\nplan.\nThe counterpart implements a sustainable remediation and GLEIF’s Escalation Level 3 contact (or\ndeputy) closes the Escalation when both the target SLA report and the following one show that the\nremediation was successful.\nIf the remediation has not occurred within the expected timeframe and stability, or an effective\nremediation plan is not submitted, GLEIF may verify the LOU Internal Controls pursuant Master\nAgreement — chapter XI (on-site audit). GLEIF will make every possible effort to provide at least four\nweeks’ notice to the LOU.\nAs a result of the on-site audit, GLEIF provides the LOU with a list of findings that must be\nremediated in the agreed timeframe and, in any case, within no more than 90 calendar days. GLEIF\nreserves the right to proceed with a further audit in order to verify the effective remediation of the\nlisted findings.\nIn case the LOU failed to remediate the ascribed audit findings by the requested timeframe, or the\nsame breach occurs in the next two reports from the audit conclusion, GLEIF in its sole but\nreasonable discretion reserves the right to suspend the LOU’s accreditation as a whole or in parts,\nthat might imply the LOU not to be able to issue new LEls in any or all accredited jurisdictions until\nfurther notice. It is the LOU’s obligation to provide immediately a notice to their customer on their\nwebsite on the suspended rights to issue LEls. Also, a further on-site audit or the trigger of section\n4.5 “Termination” can be initiated by GLEIF. Whenever an on-site audit is triggered, LOU bears the\nrelated costs.\n4.5 Termination\nIf the audit findings are not effectively remediated in the requested timeframe, GLEIF may terminate\nthe Agreement pursuant to Chapter Xll. C of the Master Agreement.\n4.6 Escalation Contacts\nThe escalation contacts are listed in the relevant section of the LOU Communications Portal. It is\nexpected the Escalation Level 2 contacts to be at managerial level, and the Escalation Level 3\ncontacts at “C” level or equivalent (e.g. President, General Director). Each escalation contact should\nmention an assigned deputy. Each LOU has the responsibility to keep their escalation contacts up-to-\ndate.\nService Level Agreement (SLA) Page 40 of 47\n@ Public Version 2.1\n2022-03-31_MA-Appendix-06-SLA_v2.1.docx 2022-03-31\n","contentLength":2742,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:31.972Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-03-31-ma-appendix-06-sla_2.1.pdf","content":"LOU Annual Accreditation | The activities GLEIF undertakes to ensure that remediation actions\nVerification Remediation | have been taken by the LOU to successfully address the findings\nof Findings reported in the AAV report. The nature of the remediation and the\ntimeframe depend on the findings and are defined on a case-by-case\nbasis by the GLEIF Accreditation Analyst.\nLOU business day Business day according to local LOU business calendar.\nLOU Tasks Activities of the LOU in a GLEIF service to assure service delivery.\nName Name of the service, using verbs to indicate actionable items.\nMaturity Level The Maturity Levels define the evolution of improvements in\nprocesses associated with what is measured. Each Data Quality Check\nis associated to a Maturity Level and the link between Maturity Level\nand Quality Rate in the SLA is the following:\no Level 1, in the SLA is corresponding to ‘Required Quality’\no Level 2, in the SLA is corresponding to ‘Expected Quality’\no Level 3, in the SLA is corresponding to ‘Excellent Quality’\nOther Service Providers This is an example of a Third Party Service Provider. Please see\nAppendix 14.\nProcessing Time Time of all involved parties (if not stated otherwise) to fulfill a service\nrequest.\nRecovery Time Objective | The maximum amount of time allowed to resume an activity, recover\n(RTO) resources, or provide products and services after a disaster has\noccurred.\nRegistration Agent This is an example of a Third Party Service provider. Please see\nAppendix 14.\nRequired Quality Rate The rate of LEI records that fulfill all required quality checks = maturity\nlevel 1 checks as defined in the Data Quality Rule Setting.\nResponse Time Defines the maximum time to respond to a service request.\nService Continuity The process responsible for recovery of GLEIF vital business functions\nProcess in the event of a disaster.\nService Level Commitment based on Service Level requirements. Ensures that the\nservice is able to meet the GLEIS objectives.\nService Transfer Point The definition of the system where the service is delivered to measure\nthe accordant Service Level.\nTag Line A short description that summarizes the service.\nService Level Agreement (SLA) Page 5 of 47\n@ Public Version 2.1\n2022-03-31_MA-Appendix-06-SLA_v2.1.docx 2022-03-31\n","contentLength":2284,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:31.972Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-03-31-ma-appendix-06-sla_2.1.pdf","content":"5 Incident Management\nGLEIF has implemented the incident management process based on ISO 20000 standard to be able to\nrestore disrupted services back to normal operations to meet service levels.\nThe disrupted service is required to be back to normal operation as quickly as possible with minimal\nimpact on business operations.\nIn the event that an incident on any GLEIF service occurs, the incidents are processed by GLEIF’s\nservice desk, and specialists are assigned to restore agreed services. When the service is fully\nrecovered, the incident is closed.\nIncidents are to be reported via an email to servicedesk@gleif.org by LOUs.\nIncidents are prioritized based on the Impact-Urgency Matrix_depending on the service affected.\nProcessing time is targeted as service level for the following priorities:\no Priority 1: 24 hours (during GLEIF business days)\no Priority 2: 2 GLEIF business days\no Priority 3: 3 GLEIF business days\nAttended service operating time is Mo-Fr: 09.00 — 17.00 CET GLEIF business days.\nImpact-Urgency Matrix\nThe Impact-Urgency Matrix shows which services are treated with which Priority.\nImpact — measures the effect of an incident based on the functionality of the service.\nUrgency - measures the criticality, which indicates the speed of resolving an incident.\nPriority - is derived from Impact and Urgency.\nUrgency\n3 - Low 2 — Medium 1-High\nSupporting Services Enhancing Services Core Services\no g Specific functionality\n= | unavailable\n5 5\ne ~ 35 | Partial Service\n£ < | unavailable\n®\n' £ | Full Service unavailable\nService Level Agreement (SLA) Page 41 of 47\n@ Public Version 2.1\n2022-03-31_MA-Appendix-06-SLA_v2.1.docx 2022-03-31\n","contentLength":1660,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:31.972Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-03-31-ma-appendix-06-sla_2.1.pdf","content":"Urgency classification\nL LOU Annual Accreditation L\nLOU Accreditation o Application: Customer Portal\nVerification\nChallenge LEI Data Check for Duplicates\nCode Lists LOU Communications Portal\n. Trigger LEI Management\nUpload LEI & LE-RD Files\nTransfer\nData Governance Pre-check\nPriority Level Definition\nThe following table shows the priority level definition for an incident. A resolution target is set for\neach Priority.\n1 Hich Core Services are inaccessible, interrupted, or 24 hours (during GLEIF\ni\n8 unusable. business days)\n2 Medium Enhancing Services are unusable or hard to use. | 2 GLEIF business days\n3 Low Support Services are unusable or hard to use. 3 GLEIF business days\n5.1 Major Incident\nA “Major Incident” is a type of incident, that occurs when all or major parts of the core services are\naffected by disruption.\nThe resolution time in case of a major incident is 1 hour during GLEIF business days.\nService Level Agreement (SLA) Page 42 of 47\n@ Public Version 2.1\n2022-03-31_MA-Appendix-06-SLA_v2.1.docx 2022-03-31\n","contentLength":1031,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:31.972Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-03-31-ma-appendix-06-sla_2.1.pdf","content":"6 Complaints\nComplaints are handled via the defined process “LOU feedback”.\nLOUs can submit their complaints via Customer Portal or by communicating with their Business\nRelations Manager.\nService Level Agreement (SLA) Page 43 of 47\n@ Public Version 2.1\n2022-03-31_MA-Appendix-06-SLA_v2.1.docx 2022-03-31\n","contentLength":304,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:31.972Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-03-31-ma-appendix-06-sla_2.1.pdf","content":"7 GLEIF Code of Conduct in case of a disaster\n\nIn the extraordinary circumstances GLEIF is affected by a disaster:\n\n1. GLEIF informs the LOUs in the shortest possible time via LOU Communication Portal (if available,\nor by using any other possible means e.g. email or telephone) and invokes the Service Continuity\nProcess\n\n2. Insuch a situation and until full recovery occurred, the following RTOs and targets are effective:\n\nCheck for Duplicates <2 GLEIF Availability: 97.5 %\nbusiness days Processing time < 1 min\nCode Lists < 1 calendar Availability: 95 % (GLEIF Website)\nmonth\nData Governance Pre-Check | <2 GLEIF API:\nbusiness days Availability: 97.5 %\nProcessing time £ 3 sec\nGUI:\nAvailability: 95 %\nProcessing time £ 1 min\nLOU Accreditation < 1 calendar Availability: 95 % (GLEIF Website)\nmonth Availability: 95 % (Customer Portal)\nProcessing Time to review applicants’\ndocumentation: 60 days\nProcessing Time to review candidates’\ndocumentation: 4 months\nLOU Annual Accreditation < 1 calendar Availability: 95 % (Customer Portal)\nverification month Processing Time to review LOU submitted\ndocumentation: 60 days\nLOU Communications Portal | <2 GLEIF Availability: 95 %\nbusiness days Processing Time to register an account: 3 days\nTrigger LEl management <2 GLEIF No LEls are left without any operating\ntransfer business days managing LOU for more than 4 business days\nIn case of force majeure, GLEIF shall trigger\nthis process within 4 business days given the\nimpacted LOU stops LEI file daily upload and\nService Level Agreement (SLA) Page 44 of 47\n@ Public Version 2.1\n2022-03-31_MA-Appendix-06-SLA_v2.1.docx 2022-03-31\n","contentLength":1624,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:31.972Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-03-31-ma-appendix-06-sla_2.1.pdf","content":"does not provide business as usual\nconfirmation\nUpload LEI & LE-RD Files <2 GLEIF Availability: 97.5 %\nbusiness days Processing time: Within 1 hour upon arrival\nSame workload limits as during business as usual apply.\nService Level Agreement (SLA) Page 45 of 47\n@ Public Version 2.1\n2022-03-31_MA-Appendix-06-SLA_v2.1.docx 2022-03-31\n","contentLength":333,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:31.972Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-03-31-ma-appendix-06-sla_2.1.pdf","content":"8 SLA Reports\nGLEIF provides monthly SLA Reports to the LOU by the 10\" GLEIF business day of the following\nmonth.\nIn case of Service Level breaches GLEIF initiates escalation management.\nService Reports Definition\nContents Report parameters according to SLA\nReporting period Monthly\nReporting Reports are made available through LOU Communications Portal\nObligation According to SLA\nLanguage English\nFiling 10 years\nService Level Agreement (SLA) Page 46 of 47\n@ Public Version 2.1\n2022-03-31_MA-Appendix-06-SLA_v2.1.docx 2022-03-31\n","contentLength":531,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:31.972Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-03-31-ma-appendix-06-sla_2.1.pdf","content":"9 Change of Service Levels\nChapter XllII of the Master Agreement applies.\nService Level Agreement (SLA) Page 47 of 47\n@ Public Version 2.1\n2022-03-31_MA-Appendix-06-SLA_v2.1.docx 2022-03-31\n","contentLength":190,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:31.972Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-03-31-ma-appendix-06-sla_2.1.pdf","content":"Update Frequency How often a request for service will occur in a given period of time.\n\nUpload Failure Rate The rate of LEI records that could not be successfully uploaded (due to\nfalse formats etc.).\n\nValidation Ensures complete, reasonable, sensible data within acceptable\nboundaries. To check data that is being entered.\n\nValidation Agent The Validation Agent is an organization that obtains and maintains\nLegal Entity Identifiers (LEls) for its clients in cooperation with\naccredited LEl issuers by leveraging their business as usual client\nidentification procedures in Know Your Customer (KYC) and client\nonboarding processes.\n\nVerification Entered data matches exactly the validation source.\n\nWorkload Limit A measure of the volume of work that the GLEIF services apply to.\n\nService Level Agreement (SLA) Page 6 of 47\n@ Public Version 2.1\n2022-03-31_MA-Appendix-06-SLA_v2.1.docx 2022-03-31\n","contentLength":896,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:31.972Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-03-31-ma-appendix-06-sla_2.1.pdf","content":"2 GLEIF Services - Service Descriptions\n\nThe following services listed below are delivered by GLEIF, applying GLEIF’s Information Security\nPolicy.\n\nFor all of them, the attended service operating time will be from Monday to Friday between\n\n09.00 — 17.00 GLEIF business days. Also, the response time to service requests issued by Customers\ngenerally is within one GLEIF business day upon submission.\n\n2.1 LOU Accreditation\n\nName LOU Accreditation\n\nTag Line Entities desiring to become local operating units must seek\nAccreditation by GLEIF.\n\nDescription In order to support the integrity of the GLEIS, an extensive vetting\nprocess is in place to ensure that local operating units reflect and\nincorporate the vision and internal control requirements of GLEIF\nwithin their operations.\n\nThe Accreditation Manual and Accreditation Checklist (Appendix 02)\ncan be downloaded from GLEIF’'s website.\n\nEssential Tasks e Provide Accreditation Manual and Accreditation Checklist and\n\nother supporting materials and forms\n\no Evaluate readiness of Applicant LOU based on the Accreditation\nPlan\n\no Set up of Non-Disclosure Agreement / Master Agreement\ncontract\n\n* Provide up to support calls per phase\n\n© Assess Accreditation Documentation from Candidates for\ncompliance with expected standards\n\no Provide transactional LEI test cases to the Candidate LOU and\nassess performance\n\no Assess use of authoritative sources\n\n¢ Ensure integrity and availability of historical LEI information\n\no Issue Accreditation Certificate\n\no Publish Accreditation Certificate on GLEIF website\n\n¢ Provide and maintain on GLEIF website the list of all LOUs\ncurrently accredited\n\nAccess Group(s) o Applicant LOU\n\nService Level Agreement (SLA) Page 7 of 47\n@ Public Version 2.1\n2022-03-31_MA-Appendix-06-SLA_v2.1.docx 2022-03-31\n","contentLength":1791,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:31.972Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-03-31-ma-appendix-06-sla_2.1.pdf","content":"¢ Candidate LOU\nThe Applicant/Candidate © Read Accreditation Manual\nLOU Tasks Develop Accreditation Plan and other required documentation\nand forms\n» Sign Non-Disclosure Agreement / Master Agreement\no Complete Accreditation Checklist with supporting documents\no Participate in support calls with GLEIF\no Deliver Accreditation Documentation and data testing results\no Remediate areas of non-compliance as required\no Publish Accreditation Certificate on own website\no Candidate to provide the requested material in no more than 6\nmonths from the date of the Master Agreement signature\nAvailability 99.9 % (Monday — Sunday 00:00 — 24:00) for GLEIF Website\n97,7 % (Monday — Sunday 00:00 — 24:00) for Customer Portal\nProcessing Time Applicant documentation review:\nReview Accreditation Plan submission within 45 GLEIF business days\nof receipt of full set of materials\nCandidate documentation review:\nReview Candidate submission within 3 months of receipt of\ncomplete set of materials\nWorkload Limit 15 concurrent instances\nException In case the Continuity process is invoked (ref. chapter 7)\nService Level Agreement (SLA) Page 8 of 47\n@ Public Version 2.1\n2022-03-31_MA-Appendix-06-SLA_v2.1.docx 2022-03-31\n","contentLength":1203,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:31.972Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-03-31-ma-appendix-06-sla_2.1.pdf","content":"2.2 LOU Annual Accreditation Verification\n\nName LOU Annual Accreditation Verification\n\nTag Line GLEIF’s process of re-verification of the LOU compliance with\nexpected internal controls within its LEI operations.\n\nDescription GLEIF will request from the LOUs certain documentation and\nevidence of compliance with expected internal controls which need\nto be in place for an accredited LOU to be operational. This exercise\nis based upon the current status of internal controls that were\nverified as part of the LOU’s initial Accreditation and as amended in\nthe event under the Accreditation Change Process.\n\nThe LOU Annual Accreditation Verification process is executed on or\nafter the anniversary date of the LOU’s date of accreditation as\ndocumented on their accreditation certificate. See Appendix 10.\nUsing a template provided by GLEIF, the LOU verifies the status of\neach processing area as mentioned in the Accreditation Checklist.\nFor areas where significant changes have occurred, the LOU\ndocuments the nature and extent of the changes and how it/they\neffected LEI processing. Supporting documentation must be\nprovided as additional information regarding the change(s).\n\nGLEIF reviews this information and assesses the overall impact of\nany changes noted in the internal controls. GLEIF determines if the\nchanged internal controls still meet the required control standard\nand advises the LOU as to whether any remediation action is\nrequired.\n\nEssential Tasks o Provide LOU Annual Accreditation Verification questionnaire and\n\nother review materials\n¢ Review and evaluate LOU self-assessment\n¢ Confirm adequate levels of compliance with expected controls\nexists and/or document required remediation activities\n© Ensure that any remediation activities are completed in a timely\nand complete manner\ne Maintain on GLEIF website the list of all LOUs currently\naccredited\n* Yearly by the following 3 months after the anniversary date of\nLOU accreditation, GLEIF will trigger an LOU Annual Accreditation\nVerification. The scope of the LOU Annual Accreditation\nService Level Agreement (SLA) Page 9 of 47\n@ Public Version 2.1\n2022-03-31_MA-Appendix-06-SLA_v2.1.docx 2022-03-31\n","contentLength":2173,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:31.973Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-03-31-ma-appendix-06-sla_2.1.pdf","content":"Verification will be always the last operational year from the\nanniversary date.\nAccess Group(s) Accredited local operating units\nThe LOU Tasks ¢ Download the designated annual verification materials from\ngleif.org when instructed\no Provide completed Accreditation Verification questionnaire (self-\nassessment) noting all changes in its internal controls within its\nLEl operations\n¢ Provide supporting documentation for any process changes\nnoted\no Review GLEIF evaluation results with GLEIF\no Complete any required remediation activities based upon a\nmutually agreed schedule\n¢ The LOUs having performed at least the LOU Annual\nAccreditation Verification once and having 9 clean SLA reports\n(no breaches) in the last operating year, could be requested to\nperform the LOU Annual Accreditation Verification with a\nreduced scope. The decision is at the sole discretion of GLEIF\nAvailability 97,7 % (Monday — Sunday 00:00 — 24:00) for Customer Portal\nProcessing Time GLEIF shall review the LOU submitted documentation within 30\nGLEIF business days of receipt of the complete set of documents\nWorkload Limit 20 concurrent instances\nException In case the Continuity process is invoked (ref. chapter 7)\nService Level Agreement (SLA) Page 10 of 47\n@ Public Version 2.1\n2022-03-31_MA-Appendix-06-SLA_v2.1.docx 2022-03-31\n","contentLength":1312,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:31.973Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2021-11-30_ma-appendix-07-payments_v1.4-final.pdf","content":"@’ Protacting diital rust\nPayments\n\nAppendix 07\n\nGLEIF\n\nVersion 1.4 ‘\n\n2021-11-30 \\\n","contentLength":84,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:47.791Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2021-11-30_ma-appendix-07-payments_v1.4-final.pdf","content":"1. Contribution Fee\nThe LOU's contribution fee covers all GLEIF Services as described in the Service Level Agreement\n(Appendix 06). It is established as a per LEI net amount. \"Net\" means that the LOU shall adjust the\namount in a way that GLEIF receives the contribution fee amount net of any charges, banking\ncharges, taxes, levies and any other deductions.\nThe annual per LEI contribution fee is USD 11.00, invoiced by GLEIF to the LOU in quarterly\ninstallments in accordance with below Section 3. This LEI contribution fee applies to LEls issued or\nrenewed on or after 1 January 2019. For LEls issued or renewed prior to 1 January 2019, the LEI\ncontribution fee remains USD 17.00.\nIf the LEl was issued and is still part of a Validation Agent relationship recognized by GLEIF, the\nfollowing fee structure applies for these LEls:\nNumber of LEIs from relationship Amount in USD each per quarter\nbetween the LOU and a Validation\nAgent by each quarter-end\n0-10,000 1.25\n10,001 - 50,000 0.75\n50,001 - 100,000 0.5\n100,001 - 500,000 0.375\n500,001 - 1,000,000 0.25\n> 1,000,001 0.125\nIf the number of LEls at the end of the quarter exceeds or falls below the threshold for the next fee\nlevel, the amount of this fee level applies to all LEls of the LOU that are serviced together with a\nValidation Agent.\n2. Taxes\nThe competent Tax Authorities of the Canton of Basel-Stadt have formally granted the tax exemption\nstatus to GLEIF regarding income tax and capital tax.\nThe LOU is responsible to consult local counsel regarding any potential tax issues and document the\nresults in its Accreditation Documentation. The LOU should in particular pay attention to services\nprovided by GLEIF (as a foreign entity from the LOU perspective), which could (i) either trigger a\npotential VAT liability for GLEIF in the LOU's country or (ii) be taxed at the LOU's level under a reverse\ncharge or similar mechanism pursuant to the local laws of the LOU’s domicile, and/or which might be\ngoverned by a Double Taxation Treaty.\nPayments Page 2 of 8\n@ GLEIF Version 1.4\n2021-11-30_MA Appendix 07 Payments_v1.4final.docx 2021-11-30\n","contentLength":2105,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:47.791Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2021-11-30_ma-appendix-07-payments_v1.4-final.pdf","content":"3. Invoicing\n\nThe per LEI contribution fee is to be paid quarterly by the LOU managing the LEl at the quarter-end\ndate. The quarterly payment is determined by multiplying the active number of LEIl records managed\nby the LOU as of the quarter end date (23.59 Central European Time) by USD 2.75. LEIs that are part\nof the Validation Agent relationships recognized by GLEIF are invoiced separately. The quarterly\npayment for these LEls is determined by multiplying the active number of LEl records managed by\nthe Validation Agent and LOU as of the quarter end date (23.59 Central European Time) by the\napplicable fee structure (see Table 1 above).\n\nIf the LEI had lapsed or retired as of a previous quarter-end date, but is reported by the LOU as active\nat a subsequent quarter-end date, the quarterly payment for such LEl is USD 2.75 multiplied by «1\nplus the count of all previous quarter-end dates where the LEl was reported as lapsed or retired»,\nwhere however that latter factor is capped at twelve quarters, i.e. three years.\n\nGLEIF will issue electronic LOU invoices within 10 Days following receipt of the LOU's quarter-end\nusage attestation (see Section 4). The invoice will state the GLEIF bank account number, the period\ncovered, and the amount to be paid; invoices shall be paid by the last day of the month in which the\ninvoice was dated.\n\nAny LOU queries regarding invoiced charges must be received by GLEIF within 10 Days of the date of\nthe invoice. Payment of an invoice by the LOU acknowledges that the in-voiced amounts were\ncorrect and complete.\n\nPayment reminders will be issued after non-receipt of full payment by the due date. GLEIF reserves\nthe right to apply either or both of the following measures in case of late or partial payment:\n\n(i) Interest Charges: Any overdue amount may be subject to a monthly interest\ncharge based on the one year London Interbank Offered Rate (LIBOR) in the\nbilling currency (derived from such source as GLEIF may select) plus 2.5%,\nwhere for the avoidance of doubt interest charged to the LOU will never be\nlower than 2.5%.\n\n(ii) Suspension: If the LOU has not paid-in-full, excluding disputed amounts (see\nSection 9), after three months from the date of the invoice, it may have its\nrights sus-pended and GLEIF retains the right to take other appropriate steps,\nincluding to terminate with immediate effect the Agreement, pursuant to all\nremedies available to it under the Master Agreement.\n\n4. LOUs Usage Attestation\nThe LOU is required to provide GLEIF with a usage attestation of the LEIs managed by the LOU and\nthe number of LEIs per Validation Agent of the LOU (if applicable and attested by each applicable\nValidation Agent) as of the relevant quarter-end date. The LOU usage at-testation must be received\nby the fifth Day following the quarter-end date. GLEIF shall pro-vide a template for this attestation.\nThis usage attestation report shall identify the population of LEIs per the LEI Registration Status as of\nthe relevant quarter-end date (see Common Data File Format field Registration-Status for further\ndetail). The LEI Registration Status is used to determine if a fee is due for the LEI.\nPayments Page 3 of 8\n@ GLEIF Version 1.4\n2021-11-30_MA Appendix 07 Payments_v1.4final.docx 2021-11-30\n","contentLength":3262,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:47.791Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2021-11-30_ma-appendix-07-payments_v1.4-final.pdf","content":"PENDINGVALIDATION An application for an LEI that has been submitted and | No\nwhich is being processed and validated.\nNOTE: LE| registrations in the PENDING state are not\nintended for public release, but could be used\ninternally between the LOU and other local operating\nunits.\nISSUED An LEI Registration that has been validated and issued, | Yes\nand which identifies an entity that was an operating\nlegal entity as of the last update.\nDUPLICATE An LEI Registration that has been determined to be a No\nduplicate registration of the same legal entity as\nanother LEI Registration; the DUPLICATE status is\nassigned to the non-surviving registration (i.e., the LEI\nthat should no longer be used). Only one of the\npotential multiple identifiers will survive; for all other\nduplicate registrations:\n1. The RegistrationStatus is set to DUPLICATE,\n2. The LEI of the surviving LEI Registration is set in\nthe SuccessorLEl data element of (each) duplicate\nLEI registration;\n3. The LastUpdateDate is set to reflect the date of\nthis update, and\n4. No further updates of the DUPLICATE registration\nrecord will occur.\nLAPSED An LEI registration that has not been renewed and has | No —see\nexceeded any allowed grace period for renewal. section 3 for\nAfter being issued an LEl, an entity must regularly do further detail\nthe following:\no Periodically verify the continued accuracy of its\nregistration reference data that is recorded in the\nlocal operating unit that is responsible for\nmanaging the LEI registration of the entity,\nupdating any aspect of the registration reference\ndata that has changed;\nPayments Page 4 of 8\nGLEIF GLEIF Version 1.4\n@ 2021-11-30_MA Appendix 07 Payments_v1.4final.docx 2021-11-30\n","contentLength":1694,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:47.791Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2021-11-30_ma-appendix-07-payments_v1.4-final.pdf","content":"o Periodically renew its LEI registration agreement\nwith the managing local operating unit, paying the\nrenewal fee.\n\n(Although both of the above actions are typically\n\nperformed at the same time, it is certainly possible\nthat the frequency of each action could be different.)\n\nIf, after being issued an LElI,\n\no Alegal entity fails to renew and re-certify its LEI\nregistration with the managing local operating\nunit by the leiNextRenewalDate, and\n\no The legal entity fails to do so for a pre-determined\n(as yet unspecified) period of time, and\n\no The legal entity is not known by public sources to\nhave ceased operation\n\nThen\n\n1. The leiRegistrationStatus is set to LAPSED,\n\n2. Updates to the LEl registration are permitted,\nnotably to reinstate the registration to the ISSUED\nstatus.\n\nMERGED A LEI registration for an entity that has been merged No\ninto another legal entity, such that this legal entity no\nlonger exists as an operating entity.\n\nIf\n\no After being issued an LEl, the entity is acquired by,\nor merged with, another legal entity;\n\no Per agreements among the parties to the\ntransaction, the LEI of the acquired or merged\nentity will not be used to identify the surviving\nentity (or if a new entity is created that is issued a\nnew LEI)\n\nThen\n\n1. The leiRegistrationStatus is set to “MERGED”,\n\n2. The LEI of the surviving/new legal entity is set in\nthe successorLEl data element of (each) LEI\nregistration that is no longer to be used;\n\n3. The leiRecordLastUpdate is set to reflect the date\nof this update,\n\nPayments Page 5 of 8\n@ GLEIF Version 1.4\n2021-11-30_MA Appendix 07 Payments_v1.4final.docx 2021-11-30\n","contentLength":1622,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:47.791Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2021-11-30_ma-appendix-07-payments_v1.4-final.pdf","content":"4. The EntityExpirationDate is also set to the date of\nthis update,\nThe EntityExpirationReason is set to\n“CORPORATEACTION”,\n\n5. The EntityStatus is set to “INACTIVE”; and\n\n6. No further updates of the MERGED registration\nrecord(s) will occur.\nRETIRED An LEI registration for an entity that has ceased No - see\noperation, without having been merged into another section 3 for\nentity. further detail\nIf\no After being issued an LEI, the entity ceases to\noperate (goes out of business and/or dissolves its\nlegal standing)\n\n¢ The entity informs the managing local operating\nunit of the cessation of business, OR, the\nmanaging local operating unit determines by\npublic sources that the legal entity has been\ndissolved or ceased to operate (and the local\noperating unit seeks to confirm this status through\nall available channels with the entity)\n\nThen\n\n1. The leiRegistrationStatus is set to “RETIRED”;\n\n2. The leiRecordLastUpdate is set to reflect the date\nof this update;\n\n3. The EntityExpirationDate is also set to the date of\nthis update;\n\n4. The EntityExpirationReason is set to “DISSOLVED”;\n\n5. The EntityStatus is set to “INACTIVE”; and\n\n6. No further updates of the RETIRED registration\nrecord will occur.\n\nANNULLED An LEl registration that was marked as erroneous or No\ninvalid after it was issued.\n\nCANCELLED An LEI registration that was abandoned prior to No\nissuance of an LEI. A record in this state is not\npublished, but may be exchanged among local\noperating units.\n\nPayments Page 6 of 8\n@ GLEIF Version 1.4\nG 2021-11-30_MA Appendix 07 Payments_v1.4final.docx 2021-11-30\n","contentLength":1580,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:47.791Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2021-11-30_ma-appendix-07-payments_v1.4-final.pdf","content":"TRANSFERRED An LEI registration that has been transferred to a No\ndifferent local operating unit as the managing local\noperating unit. A record in this state is not published,\nbut may be used internally by the prior local operating\nunit for audit trail purposes.\nPENDINGTRANSFER An LEl registration that has been requested to be Yes\ntransferred to another local operating unit. The\nrequest is being processed at the sending local\noperating unit. When the receiving local operating\nunit is ready, the status will be changed to\nPENDINGARCHIVAL by the sending local operating unit\nprior to completion of the transfer.\nPENDINGARCHIVAL An LEI registration is about to be transferred to a No\ndifferent local operating unit, after which its\nregistration status will revert to a non-pending status.\nThe PENDINGARCHIVAL status serves to inform\nrecipients of data files provided by the local operating\nunit that an LEI record will be removed from that local\noperating unit’s published file after the transfer is\ncomplete.\n5. Currency\nGLEIF shall invoice the LOU in USD but shall provide the LOU the option of making payment in USD,\nEUR, or CHF. For EUR and CHF currency payments, GLEIF will apply the applicable exchange rate\npublished on the invoice date by the European Central Bank Euro Foreign Exchange Reference\nRates .\n6. Costs of Transferring/Exchanging Funds\nThe LOU shall bear all costs of transferring/exchanging funds.\n7. Reimbursement of Erroneous Payments,\nor Payments Received in Error\nIf the LOU makes a payment that is obviously made in error, GLEIF shall notify the LOU and refund\nthe full payment. GLEIF shall undertake to refund within 14 Days. No interest shall be paid.\n1 See http://www.ecb.europa.eu/stats/exchange/eurofxref/html/eurofxref-graph-usd.en.html\nPayments Page 7 of 8\nGLEIF GLEIF Version 1.4\n@ 2021-11-30_MA Appendix 07 Payments_v1.4final.docx 2021-11-30\n","contentLength":1878,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:47.791Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2021-11-30_ma-appendix-07-payments_v1.4-final.pdf","content":"If the LOU makes, in GLEIF's view, payment of an erroneous amount, GLEIF shall notify the LOU, and\nthe Parties shall in good faith locate the error and agree on the appropriate resolution.\n8. Offset\nGLEIF reserves the right in its sole discretion to offset any valid outstanding balance or amount due\nfrom the LOU to GLEIF against any valid outstanding balance or amount payable by GLEIF to the LOU.\n9. Disputed Amounts\nIf the LOU believes that an invoice of GLEIF is wrong for any reason, it shall (i) notify GLEIF without\nany delay, including (ii) the exact amount which is disputed, and (iii) the reason for the disagreement\nincluding documentary evidence, and shall (iv) pay the undisputed amount within the due date.\nThe Parties shall in good faith and without undue delay seek to clear up misunderstandings, and to\nestablish agreed facts underlying the invoice. If agreement has been reached, GLEIF shall either\nconfirm the invoice, or issue a new invoice, or issue a credit note.\nIn the event of protracted disagreement about an invoice, the Parties may resort to the remedies\navailable under Chapter XVI (Appeals and Complaints) or ultimately under Chapter XVII (Mediation\nand Arbitration) of the Master Agreement.\nGLEIF reserves the right to request the LOU to pay the disputed amount to GLEIF, on the\nunderstanding that such payment is no acknowledgement of an obligation to pay that disputed\namount, and GLEIF shall earmark that payment as \"disputed\". Refusal or delay of the LOU to\npromptly pay the disputed amount after being requested to do so by GLEIF shall qualify as late\npayment and shall have the consequences set out in above Section 3.\nPayments Page 8 of 8\n@ GLEIF Version 1.4\n2021-11-30_MA Appendix 07 Payments_v1.4final.docx 2021-11-30\n","contentLength":1759,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:47.791Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2016-02-01-ma-appendix-08-ancillary-duties_final.pdf","content":"O:GLEIF’ Protecing digtal tust\nAncillary Duties\nAppendix 08\n\nGLEIF ‘\n\nRevision Version 1.1\n\n2016-02-01 \\\n","contentLength":105,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:58.030Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2016-02-01-ma-appendix-08-ancillary-duties_final.pdf","content":"Ancillary Duties\n\nA.Ancillary Duties of GLEIF\n\nGLEIF\n\no functions as an anchor and link for any queries or issues the local operating units might have\nregarding the ROC;\n\no ensures that the FSB Recommendations are observed, including without limitation that the\nGovernance Principles of the GLEIS are upheld;\n\ne points out to the local operating units actual or potential issues of a factual, technical or legal\nkind which have come to GLEIF's attention and which might jeopardize the continuing\nimplementation of the GLEIS Governance Principles;\n\n¢ develops and maintains for its Global LEI Repository and any preceding LEI file storage facility,\nsupport for business continuity/disaster recovery backup for LEls and LE-RD, encompassing\nseamless public access to global LEI data;\n\no operates a website for such public access to global LEI data;\n\no supports the local operating units in the event of difficulties (on a best effort basis);\n\no provides relationship management for the local operating units for day to day issues;\n\n* provides updated information of matters relevant to the Master Agreement and/or to the local\noperating units;\n\ne organises and leads conferences, puts topics on the agenda upon request of the local operating\nunits;\n\no oversees and fosters competition and cooperation issues between the various parts of the GLEIS;\n\no follows developments regarding intellectual property rights of and in LEI data;\n\ne provides services in the area of developing and maintaining international GLEIS legal, operational\nand technical standards;\n\no registers the GLEIF Trademark and other trademarks globally, in its reasonable discretion;\n\no establishes a branding strategy regarding GLEIF, the GLEIF Trademark and Logo and the GLEIS;\n\no will help to ensure compliance of all local operating units with the rules set forth in the Master\nAgreement;\n\ne promotes, in its reasonable discretion, the LEl, particularly in countries where no local operating\nunit is yet established.\n\nGLEIS - Global LEI System Master Agreement Page 2 of 4\nGLEIF Appendix 08 — Master Copy Version 1.1\n2016-02-01-MA-Appendix-08-Ancillary-Duties-Final.docx 1 February 2016\n","contentLength":2156,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:58.030Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2016-02-01-ma-appendix-08-ancillary-duties_final.pdf","content":"B. Ancillary Duties of the LOU\n\nThe LOU\n\n¢ shall promptly and without any undue delay respond to communications from GLEIF or from\nanother local operating unit, regardless of the nature and issue;\n\no shall not unreasonably withhold its consent to permit GLEIF access to the LOU's facilities upon\nadvance notice, where however GLEIF shall comply with security and house-order requirements\nof the LOU;\n\n¢ informs GLEIF, on a best efforts basis, of difficulties or issues or suggestions of whatever\nAgreement related kind;\n\ne points out to GLEIF actual or potential issues of a factual, technical or legal kind which have come\nto the LOU's attention and which might jeopardize the continuing implementation of the\nGovernance Principles of the GLEIS or compliance with the Master Agreement;\n\n* maintains its website, adjusting to customer needs;\n\n» has reasonable maintenance agreements as well as business continuity / disaster recovery\nprograms in place to ensure excellent availability of IT infrastructure and website for the LEI\nsystem;\n\ne can be reached by GLEIF and other local operating units during local office hours over a phone\nnumber published on its website;\n\n* maintains an e-mail address each for GLEIF and for customers, ensuring replies without undue\ndelay;\n\no keeps staff knowledgeable about (i) LEl registration, (ii) administrative matters and (iii)\ninfrastructure (including IT).\n\nGLEIS - Global LEI System Master Agreement Page 3 of 4\nGLEIF Appendix 08 — Master Copy Version 1.1\n2016-02-01-MA-Appendix-08-Ancillary-Duties-Final.docx 1 February 2016\n","contentLength":1568,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:58.030Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2016-02-01-ma-appendix-08-ancillary-duties_final.pdf","content":"[ ] [ ] e \\ e\n\nC. Ancillary Duties of the LOU vis-a-vis GLEIF and\n\nall other local operating units\n\nThe LOU\n\no supports GLEIF in implementing GLEIF's branding strategy, coordinating with other local\noperating units;\n\ne cooperates with GLEIF in the event of another local operating unit ceasing its operations or\nexperiencing a major or serious break in regular operation;\n\no cooperates with all other local operating units and with GLEIF to resolve any problems with the\nmaintenance of LEls (examples: invalid LEls, duplicate LEls, LEls with serious flaws in their LE-RD,\ndata quality challenges);\n\no cooperates with all other local operating units and with GLEIF in the event that a transfer of LEls\nis necessary which have been attributed (i.e. maintained so far) by a different local operating unit\nto ensure that these LEIs have continued maintenance;\n\no shall actively attend conferences organised by GLEIF on a best effort basis;\n\no shall actively promote the LEI.\n\nD. Compliance with Applicable Competition\n\nRules, Observance of FSB Recommendation No 6,\n\nand Furtherance of Competition\n\nGLEIF and the LOU\n\no agree to be compliant with whatever competition legislation might apply, in particular but\nwithout any limitation to such legislation in Switzerland (GLEIF's residence) and in the LOU's\ncountry (including rules of international law);\n\no agree to strictly observe the FSB Recommendation No 6 requesting that the GLEIS in particular\n(but without limitation) \"is not 'locked-in' with a particular service provider for any key system\nfunctions or processes\".\n\no shall review from time to time potential compliance issues and shall seek solutions in good faith;\n\n¢ shall amend the Master Agreement including any Appendices, upon becoming aware that there\nmight be non-compliance issues.\n\nkK sk\nGLEIS - Global LEI System Master Agreement Page 4 of 4\nGLEIF Appendix 08 — Master Copy Version 1.1\n2016-02-01-MA-Appendix-08-Ancillary-Duties-Final.docx 1 February 2016\n","contentLength":1973,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:29:58.031Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2017-09-01-ma-appendix-09a-terms-of-use-gleif_final.pdf","content":"GGLEIF’ Protecting digtl st\n\nTerms of use GLEIF\nAppendix 09A\n\nGLEIF \\\nRevision Version 1.2 (\n\n2017-09-01\n","contentLength":105,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:30:09.244Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2017-09-01-ma-appendix-09a-terms-of-use-gleif_final.pdf","content":"Terms of Use\n\nof the:\n\nGlobal Legal Entity Identifier Foundation (GLEIF),\n\nSt. Alban-Vorstadt 5, 4052 Basel, Switzerland\n\nregarding the look-up and download of LEIs and LE-RD from this website by anyone\n\nIntroduction\n\nA. GLEIF is a not-for-profit foundation incorporated by the Financial Stability Board under the laws\nof Switzerland.\n\nB. GLEIF and its partnering Local Operating Units (\"LOUs\") operate a system of worldwide unique\nLegal Entity Identifiers (\"LEI\", \"LEIs\"), and GLEIF operates a Global LEI repository with certain\nadditional information about the relevant legal entities (\"Legal Entity Reference Data\", \"LE-RD\").\n\nC. The website \"http(s)://www.gleif.org\" allows users to access LEls and related LEI Reference Data.\nAny such access might use file downloads, access via Web Interfaces/APIs or by any other\ntechnical means, as provided in GLEIF's discretion. Any LEI data and LERD access from\nhttp(s)://www.gleif.org is subject to the terms of use as set out here below (the \"Terms of Use\").\n\nI. Definitions\n\n\"Access Service\" shall mean the facility provided by GLEIF under these Terms of Use and further\n\ndescribed below, provided on this website (http(s)://www.gleif.org).\n\n\"Global LEI Repository\" shall mean the global resource of databases and file servers operated by\n\nGLEIF containing and providing all LEls and LE-RD.\n\n\"GLEIF Trademark and Logo\" shall mean the trademark and logo of GLEIF as shown on\n\nhttp(s)://www.gleif.org.\n\n\"GLEIS\" shall mean the Global Legal Entity Identifier System operated by GLEIF and the LOUs.\n\n\"LEIs\" shall mean one or many Legal Entity Identifiers issued by GLEIF and the LOUs.\n\n\"LEl Reference Data\" and \"LE-RD\" (singular and plural) shall mean the information available in the\n\nGlobal LEI Repository in relation to an LEI. The categories of data currently included in the LE-RD are\n\nlisted on http(s)://www.gleif.org/***.\n\nGLEIS - Global LEI System Master Agreement Page 2 of 5\nGLEIF Appendix 09a — Master Copy Version 1.2\n2017-09-01-MA-Appendix-09a-Terms-of-Use-GLEIF-Final.docx 1 September 2017\n","contentLength":2047,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:30:09.244Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2017-09-01-ma-appendix-09a-terms-of-use-gleif_final.pdf","content":"\"LOU\" or \"LOUs\" shall mean the Local Operating Units who have entered into a Master\n\nAgreement with GLEIF and who are accredited by GLEIF to accept applications by legal entities for\n\nLEIs and to issue LEls. A list of the accredited LOUs can be found on http(s)://www.gleif.org/***\n\n\"We\", \"us\", \"our\" or equivalent terms shall refer to GLEIF.\n\n\"User\", \"You\", \"your\" or equivalent terms refer to any user of the Access Service.\n\nIl. Access Service\n\n1. The Access Service enables Users to look-up and/or download individual LEIs and/or related LE-\nRD and/or the entire set or a subset of LEls and/or pertaining LE-RD from the Global LEI\nRepository.\n\n2. The Access Service on the website http(s)://www.gleif.org is provided for free.\n\n3. The data available through the Access Service are provided under the CCO licence, see\nhttps://creativecommons.org/publicdomain/zero/1.0/.\n\n4. Inorder to protect the GLEIS and the fundamental principles underlying it as set out in the\nGovernance Principles of the GLEIS, in particular in the event of any use of the Access Service\nwhich is contrary to, or threatens to undermine, those fundamental principles or the public\nbenefit for which LEIs and LE-RD are provided, we do have to reserve the right to suspend or\nmodify the Access Service or any of the Terms of Use.\n\n5. The technical requirements you have to observe in order to be able to use the Access Service are\ndescribed on http(s)://www.gleif.org/***.\n\nIll. Service Level\n\nWe do not guarantee that the website http(s)://www.gleif.org and the Access Service will function\n\nand be available without interruptions or errors. In particular, their operation may be interrupted\n\ndue to maintenance, updates or system or network failures. Unplanned interruptions will be dealt\nwith on a best effort basis. Service windows are — whenever possible —announced in due time on\nhttp(s)://www.gleif.org/***.\nGLEIS - Global LEI System Master Agreement Page 3 of 5\nGLEIF Appendix 09a — Master Copy Version 1.2\n2017-09-01-MA-Appendix-09a-Terms-of-Use-GLEIF-Final.docx 1 September 2017\n","contentLength":2063,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:30:09.244Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2017-09-01-ma-appendix-09a-terms-of-use-gleif_final.pdf","content":"IV. Conditions of Use\n\n1. By using our Access Service, you agree with the following terms:\n\na. You acknowledge that you do not have, and will not acquire, any intellectual property or\nother proprietary rights in the LEls and LE-RD as provided by the Access Service, and that you\ndo not, and will not, claim such rights.\n\nb. You agree that you access LEls and/or LE-RD on http(s)://www.gleif.org only by way of using\nthe Access Service, and that you refrain from trying to obtain access to our Global LEI\nRepository or any other of our files or databases other than through using the Access Service\nas offered by us and, in particular, that you refrain from trying to circumvent\n\nc. If you wish to use the GLEIF Trademark and Logo, which is a registered trademark, please\ncontact GLEIF at the address indicated on http(s)://www.gleif.org.\n\n2. You agree that you shall refrain from creating, in whatever way, the impression that data and/or\nservices, except the original LEl and LE-RD downloaded by you through the Access Service, are\nprovided or supported or authorized or granted or otherwise associated by or with GLEIF.\n\n3. You further agree to refrain from any actions or statements which may mislead the public and/or\nyour customers to believe that any products or services provided by you, even if LEls and LE-RD\nmay be a part of such product or service, are services or products of GLEIF or any LOU, or that\nyou are part of, or in a special relationship to, GLEIF and/or the GLEIS and/or any LOU.\n\n4. You agree that GLEIF may take any appropriate steps, including but not limited to court action\nand to preliminary injunctions, if you do not comply with these Terms of Use, and that you are\nliable to a payment of liquidated damages\n\nGLEIS - Global LEI System Master Agreement Page 4 of 5\nGLEIF Appendix 09a — Master Copy Version 1.2\n2017-09-01-MA-Appendix-09a-Terms-of-Use-GLEIF-Final.docx 1 September 2017\n","contentLength":1914,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:30:09.244Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2017-09-01-ma-appendix-09a-terms-of-use-gleif_final.pdf","content":"V. Disclaimer of Warranties and Waiver of\n\nLiability\n\n1. The LEIs and the le-rd made available to you through the access service are provided on an \"as is\"\nand \"as available\" basis. We make no representations or warranties of any kind, express or\nimplied, thereto. You expressly agree that any use thereof is at your sole risk.\n\n2. To the fullest extent permitted by applicable law, we disclaim regarding leis and le-rd all\nwarranties, express or implied, and liability, including, but not limited to, implied warranties of\nmerchantability and fitness for a particular purpose. We will not be liable for any damages of any\nkind (including, but not limited to direct, indirect, incidental, punitive and consequential\ndamages) arising from the use of the access service or the leis and le-rd.\n\n3. In particular, without limitation, you recognize that the issuance of LEls and collection of le-rd is\nbased on applications and information provided by third parties. We cannot and do not\nrepresent or warrant that such information is accurate, correct, up-to-date or that a certain lei is\nthe only lei issued for a certain legal entity.\n\n4. In particular, without limitation, we disclaim all liability for damages caused by any interruptions\nor errors in the functioning of the access service or the website http(s)://www.gleif.org.\nFurthermore, we disclaim all liability for any malfunctioning, impossibility of access, or poor use\nconditions of the services or the website due to inappropriate equipment, disturbances related\nto internet service providers, to the saturation of the internet network, and for any other reason.\nFurthermore, we do not warrant that the services, information and contents included on or\notherwise made available to you through the services or the website http(s)://www.gleif.org are\nfree of viruses or other harmful components.\n\n5. The reservations of the licence (see section iv) apply.\n\nVI. Applicable Law and Jurisdiction\n\n1. These Terms of Use, and your use of the Access Service, shall in all respects be governed by, and\n\nconstrued and interpreted in accordance with, the substantive laws of Switzerland without\nregard to Switzerland's conflict of law rules.\n\n2. The Parties submit to the exclusive jurisdiction of the competent courts in Basel, Switzerland, for\n\nall disputes arising out of, or in connection with, these Terms of Use.\nGLEIS - Global LEI System Master Agreement Page 5 of 5\nGLEIF Appendix 09a — Master Copy Version 1.2\n2017-09-01-MA-Appendix-09a-Terms-of-Use-GLEIF-Final.docx 1 September 2017\n","contentLength":2542,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:30:09.244Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-05-11_ma-appendix-10-accreditation-verification_1.4final.pdf","content":"OGLEIF> rotactng digtor st\n\nAnnual Accreditation\nVerification Requirements\nAppendix 10\n","contentLength":87,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:30:19.148Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-05-11_ma-appendix-10-accreditation-verification_1.4final.pdf","content":"Annual Accreditation Verification Requirements\n\nAnnually, the LOU must confirm the continued compliance with GLEIF requirements regarding\n\ncurrent status of certain internal controls within its LEl operations as set out and agreed in the\n\nAccreditation Documentation (Appendix 04), and as amended in the event under the Accreditation\n\nChange Process. The confirmation can be done with reports of any source received by the LOU that\n\nshows its continued compliance e.g. (Independent) Audit Report.\n\nAnnual Verification will comprise, as a rule, the following steps.\n\nThe following reporting is required for submission on or before the date of the issuance of the\n\nLOU’s Accreditation Certificate annually:\n\n1. Reconfirmation of the accuracy and completeness of the Accreditation Documentation\nThe LOU must formally annually reconfirm that its internal controls for the previous twelve\nmonths based upon the accreditation certificate anniversary continues to conform to the\nAccreditation Documentation (Appendix 04), as amended.\n\n2. Confirmation of reporting year cost recovery compliance\nAs established in the Master Agreement and Accreditation Documentation (Appendix 04), the\nLOU will be required annually to confirm and demonstrate its compliance with the cost recovery\nmodel.\n\nDuring Annual Accreditation Verification (AAV) i.e. one year after the Accreditation Certificate\nAnniversary Date, the LOU has to confirm and demonstrate its compliance with the cost recovery\nmodel by providing the data mentioned in 2.1 to 2.3 that is independently validated.\nGLEIF will accept either one of the following time frames as reporting year for the verification of\ncost recovery compliance:\no The LOU’s last operating year, i.e., previous 12 months of operations based on the\nLOU’s accreditation certificate anniversary date. Example_ If the LOU became\naccredited on 20 July 2021, for its first AAV, the LOU will need to report compliance\nwith cost recovery from 20 July 2021 to 19 July 2022, for its second AAV from 20 July\n2022 to 19 July 2023, etc.\no The LOU’s last audited financial year. Example: If the LOU became accredited on 20\nJuly 2021 and its financial year is from January to December, for its first AAV, the\nLOU will need to report compliance with cost recovery for the most recent audited\nfinancial year, which in this case would be the year ending to 2021, i.e., from August\n2021 to December 2021.\no Last calendar year. Example: If the LOU became accredited on 20 July 2021, for its\nfirst AAV, the LOU will need to report cost recovery for the calendar year ending to\n2021, i.e., from August to December 2021.\nGLEIS - Global LEI System Master Agreement Page 2 of 4\nGLEIF Appendix 10 — Master Copy Version 1.4\n2022-05-11_MA-Appendix-10-Accreditation-Verification_1.4final 11 May 2022\n","contentLength":2791,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:30:19.148Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-05-11_ma-appendix-10-accreditation-verification_1.4final.pdf","content":"The LOU will be required to report consistently cost recovery compliance; switching reporting\n\ntimeframes from one Annual Accreditation Verification to the other Annual Accreditation\n\nVerification shall be avoided and has to be mutually agreed between GLEIF and the LOU.\n\n2.1 Total previous year LEI fee revenues\n\n2.2 Total previous year annual Direct Cost (as defined in the Master Agreement) associated with\nits core duties as set out in Chapter IV such as salaries and cost of IT and as documented by\n\nthe LOU in its Accreditation Documentation (Appendix 04);\n\n2.3 LOU adds to the Direct Cost calculated as per above Section 2.2 amounts to cover overhead\nand determines its annual total costs estimate as follows:\n\ni. The LOU determines the components of its Direct Cost calculated as per above Section 2.2\n\nthat are either (a) inter-company transfer fees with margin or (b) third-party service fees\n\nii. The LOU subtracts from annual Direct Cost (a) and (b) as defined in 2.3(i) and adds 100%\n\niii. The LOU adds 25% to (a) and (b) as defined in 2.3(i)\n\niv. The LOU determines its annual total costs estimate by adding 2.3(ii) and 2.3(iii)\nConfirmation of the previous reporting year cost recovery compliance must be reviewed and\nconfirmed in writing by the LOU’s independent auditors or by some other third party as agreed\nin the Accreditation Documentation (Appendix 04).\n\nGLEIS - Global LEI System Master Agreement Page 3 of 4\nGLEIF Appendix 10 — Master Copy Version 1.4\n2022-05-11_MA-Appendix-10-Accreditation-Verification_1.4final 11 May 2022\n","contentLength":1551,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:30:19.148Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-05-11_ma-appendix-10-accreditation-verification_1.4final.pdf","content":"3. Next Year’s Expected Fee Schedule:\nThe LOU will be required annually to forecast its cost recovery model estimations and its\nexpected LEI fee schedule for the next reporting year (1 January to 31 December) as follows:\n3.1 the LOU’s generates its forward-looking 3-year estimate of annual average Direct Cost\nassociated with its core duties as set out in Chapter Xl such as salaries and cost of IT, as\ndocumented in the Accreditation Documentation (Appendix 04);\n3.2 LOU adds to the Direct Cost calculated as per above Section 3.1 amounts to cover overhead\nand determines its annual total costs estimate as follows\ni. The LOU determines the components of its annual average Direct Cost calculated as per\nabove Section 3.1 that are either (a) inter-company transfer fees with margin or (b) third-\nparty service fees\n\nii. The LOU subtracts from annual average Direct Cost (a) and (b) as defined in 3.2.(i) and\nadds 100%\n\niii. The LOU adds 25% to (a) and (b) as defined in 3.2.(i)\n\niv. The LOU determines its annual average annual total costs estimate by adding 3.2.(ii) and\n3.2.(iii).\n\n3.3 the LOU estimates how many LEls it likely will issue plus renewals for the upcoming year;\n\n3.4 the average fee schedule requested for the issuance or renewal of an LEI by the LOU cannot\nexceed the result of 3.2.(iv) divided by the estimated number of LEIs ((3.1 + 3.2) / 3.3)\n\nMaterially overestimated fees collected, as identified in the LOU annual quantitative analysis\nrequired pursuant to Chapter V of the Master Agreement, shall be included the above\ncalculation, so that on a rolling average over three years the maximum fee limit requirements\nare met, as agreed in the Accreditation Documentation (Appendix 04).\nGLEIS - Global LEI System Master Agreement Page 4 of 4\nGLEIF Appendix 10 — Master Copy Version 1.4\n2022-05-11_MA-Appendix-10-Accreditation-Verification_1.4final 11 May 2022\n","contentLength":1882,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:30:19.148Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2016-02-01-ma-appendix-11-swiss-data-protection-act_final.pdf","content":"GGLEIF’ rotattng ol st\nSwiss Data Protection Act\nAppendix 11\n","contentLength":61,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:30:38.198Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2016-02-01-ma-appendix-11-swiss-data-protection-act_final.pdf","content":"Applicable Provisions of the Swiss Data\nProtection Act (DPA) including the pertaining\nOrdinance (DPO)\nNote: The following is an excerpt of the Swiss Federal Act on Data Protection of 19 June 1992 (\"DPA\",\nStatus as of 1 January 2014 and of the pertaining Ordinance (\"DPQ\", Status as of 14 June 2010)\nSwiss Federal Act on Data Protection (DPA)\nChapter 1: Aim, Scope and Definitions\nArt. 1 Aim\nThis Act aims to protect the privacy and the fundamental rights of persons when their data is\nprocessed.\nArt. 2 Scope\n1. This Act applies to the processing of data pertaining to natural persons and legal persons by:\na. private persons; note: this includes private legal entities\nb. federal bodies.\n2. It does not apply to: [note: not relevant in the context of GLEIF-LOU]\nArt. 3 Definitions\nThe following definitions apply:\n\na. personal data (data): all information relating to an identified or identifiable person;\n\nb. data subjects: natural or legal persons whose data is processed;\n\nc. sensitive personal data: data on:\n\n1. religious, ideological, political or trade union-related views or activities,\n2. health, the intimate sphere or the racial origin,\n\n3. social security measures,\n\n4. administrative or criminal proceedings and sanctions;\n\nd. personality profile: a collection of data that permits an assessment of essential\ncharacteristics of the personality of a natural person;\n\ne. processing: any operation with personal data, irrespective of the means applied and the\nprocedure, and in particular the collection, storage, use, revision, disclosure, archiving or\ndestruction of data;\n\nGLEIS - Global LEI System Master Agreement Page 2 of 11\nGLEIF Appendix 11 — Master Copy Version 1.1\n2016-02-01-MA-Appendix-11-Swiss-Data-Protection-Act-Final.docx 1 February 2016\n","contentLength":1766,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:30:38.198Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2016-02-01-ma-appendix-11-swiss-data-protection-act_final.pdf","content":"Art. 10 Records\n\n1. The controller of the data file shall maintain a record of the automated processing of sensitive\npersonal data or personality profiles if preventive measures cannot ensure data protection.\nRecords are necessary in particular if it would not otherwise be possible to determine\nsubsequently whether data has been processed for the purposes for which it was collected or\ndisclosed. [note: remainder of para.1 not relevant in the context of GLEIF-LOU]\n\n2. The records must be stored for one year in a state suitable for auditing. They are accessible only\nto those bodies or private persons whose duty it is to supervise compliance with the data\nprotection regulations, and may be used only for this purpose.\n\nArt. 11 Processing policy\n\n1. The controller of an automated data file subject to registration (Art. 11a para. 3 DPA) that is not\nexempted from the registration requirement in terms of Article 11a paragraph 5 letters b—d DPA\nshall issue a processing policy that describes in particular the internal organisation and the data\nprocessing and control procedures and contain documents on the planning, realisation and\noperation of the data file and the information technology used.\n\n2. The controller of the data file shall update the processing policy regularly. He shall make it\navailable to the Commissioner or the data protection officer under Article 11a paragraph 5 letter\ne DPA on request in a form that is comprehensible to them.\n\nArt. 12 Disclosure of data\n\nThe controller of the data file shall notify the data recipient as to how up-to-date and reliable the\n\npersonal data that he has disclosed is, unless this information is evident from the data itself or from\n\nthe circumstances.\n\n[note: the remainder of the Ordinance (Articles 13-38) is not relevant in the context of GLEIF-LOU]\n\nGLEIS - Global LEI System Master Agreement Page 11 of 11\nGLEIF Appendix 11 — Master Copy Version 1.1\n2016-02-01-MA-Appendix-11-Swiss-Data-Protection-Act-Final.docx 1 February 2016\n","contentLength":1997,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:30:38.198Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2016-02-01-ma-appendix-11-swiss-data-protection-act_final.pdf","content":"f. disclosure: making personal data accessible, for example by permitting access, transmission\nor publication;\n\ng. datafile: any set of personal data that is structured in such a way that the data is accessible\nby data subject;\n\nh. federal bodies: [note: not relevant in the context of GLEIF-LOU]\n\ni. controller of the data file: private persons or federal bodies that decide on the purpose and\ncontent of a data file;\n\nj- formal enactment: [note: not relevant in the context of GLEIF-LOU]\n\nChapter 2: General Data Protection Provisions\n\nArt. 4 Principles\n\n1. Personal data may only be processed lawfully.\n\n2. Its processing must be carried out in good faith and must be proportionate.\n\n3. Personal data may only be processed for the purpose indicated at the time of collection, that is\nevident from the circumstances, or that is provided for by law.\n\n4. The collection of personal data and in particular the purpose of its processing must be evident to\nthe data subject.\n\n5. If the consent of the data subject is required for the processing of personal data, such consent is\nvalid only if given voluntarily on the provision of adequate information. Additionally, consent\nmust be given expressly in the case of processing of sensitive personal data or personality\nprofiles.\n\nArt. 5 Correctness of the data\n\n1. Anyone who processes personal data must make certain that it is correct. He must take all\nreasonable measures to ensure that data that is incorrect or incomplete in view of the purpose\nof its collection is either corrected or destroyed.\n\n2. Any data subject may request that incorrect data be corrected.\n\nArt. 6 Cross-border disclosure\n\n1. Personal data may not be disclosed abroad if the privacy of the data subjects would be seriously\n\nendangered thereby, in particular due to the absence of legislation that guarantees adequate\nprotection.\n\n2. Inthe absence of legislation that guarantees adequate protection, personal data may be\n\ndisclosed abroad only if:\na. sufficient safeguards, in particular contractual clauses, ensure an adequate level of\nprotection abroad;\nb. the data subject has consented in the specific case;\nc. the processing is directly connected with the conclusion or the performance of a contract\nand the personal data is that of a contractual party;\n@ GLEIS - Global LEI System Master Agreement Page 3 of 11\nGLEIF Appendix 11 — Master Copy Version 1.1\n2016-02-01-MA-Appendix-11-Swiss-Data-Protection-Act-Final.docx 1 February 2016\n","contentLength":2466,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:30:38.198Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2016-02-01-ma-appendix-11-swiss-data-protection-act_final.pdf","content":"d. disclosure is essential in the specific case in order either to safeguard an overriding public\ninterest or for the establishment, exercise or enforcement of legal claims before the courts;\n\ne. disclosure is required in the specific case in order to protect the life or the physical integrity\nof the data subject;\n\nf. the data subject has made the data generally accessible and has not expressly prohibited its\nprocessing;\n\ng. disclosure is made within the same legal person or company or between legal persons or\ncompanies that are under the same management, provided those involved are subject to\ndata protection rules that ensure an adequate level of protection.\n\n3. [note: not relevant in the context of GLEIF-LOU]\n\nArt. 7 Data security\n\n1. Personal data must be protected against unauthorised processing through adequate technical\nand organisational measures.\n\n2. The Federal Council issues detailed provisions on the minimum standards for data security.\n\nArt. 8 Right to information\n\n1. Any person may request information from the controller of a data file as to whether data\nconcerning them is being processed.\n\n2. The controller of a data file must notify the data subject:\n\na. of all available data concerning the subject in the data file, including the available\ninformation on the source of the data;\n\nb. the purpose of and if applicable the legal basis for the processing as well as the categories of\nthe personal data processed, the other parties involved with the file and the data recipient.\n\n3. The controller of a data file may arrange for data on the health of the data subject to be\ncommunicated by a doctor designated by the subject.\n\n4. If the controller of a data file has personal data processed by a third party, the controller remains\nunder an obligation to provide information. The third party is under an obligation to provide\ninformation if he does not disclose the identity of the controller or if the controller is not\ndomiciled in Switzerland.\n\n5. The information must normally be provided in writing, in the form of a printout or a photocopy,\nand is free of charge. The Federal Council regulates\n\n6. No one may waive the right to information in advance.\n\n@ GLEIS - Global LEI System Master Agreement Page 4 of 11\n\nGLEIF Appendix 11 — Master Copy Version 1.1\n\n2016-02-01-MA-Appendix-11-Swiss-Data-Protection-Act-Final.docx 1 February 2016\n","contentLength":2372,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:30:38.198Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2016-02-01-ma-appendix-11-swiss-data-protection-act_final.pdf","content":"Art. 9 Limitation of the duty to provide information\n\n1. The controller of a data file may refuse, restrict or defer the provision of information where:\na. aformal enactment so provides;\n\nb. thisis required to protect the overriding interests of third parties.\n\n2. [note: not relevant in the context of GLEIF-LOU]\n\n3. Assoon as the reason for refusing, restricting or deferring the provision of information ceases to\napply, the federal body must provide the information unless this is impossible or only possible\nwith disproportionate inconvenience or expense.\n\n4. The private controller of a data file may further refuse, restrict or defer the provision of\ninformation where his own overriding interests so require and he does not disclose the personal\ndata to third parties.\n\n5. The controller of a data file must indicate the reason why he has refused, restricted or deferred\naccess to information.\n\nArt. 10 [note: not relevant in the context of GLEIF-LOU]\n\nArt. 10a Data processing by third parties\n\n1. The processing of personal data may be assigned to third parties by agreement or by law if:\n\na. the datais processed only in the manner permitted for the instructing party itself; and\nb. itis not prohibited by a statutory or contractual duty of confidentiality.\n\n2. The instructing party must in particular ensure that the third party guarantees data security.\n\n3. Third parties may claim the same justification as the instructing party.\n\nArt. 11 [note: not relevant in the context of GLEIF-LOU]\n\nArt. 11a [note: not relevant in the context of GLEIF-LOU]\n\n@ GLEIS - Global LEI System Master Agreement Page 5 of 11\nGLEIF Appendix 11 — Master Copy Version 1.1\n2016-02-01-MA-Appendix-11-Swiss-Data-Protection-Act-Final.docx 1 February 2016\n","contentLength":1744,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:30:38.198Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2016-02-01-ma-appendix-11-swiss-data-protection-act_final.pdf","content":"Chapter 3: Processing of Personal Data by Private Persons\n\nArt. 12 Breaches of privacy\n\n1. Anyone who processes personal data must not unlawfully breach the privacy of the data subjects\nin doing so.\n\n2. In particular, he must not:\n\na. process personal data in contravention of the principles of Articles 4, 5 paragraph 1 and 7\nparagraph 1;\n\nb. process data pertaining to a person against that person’s express wish without justification;\n\nc. disclose sensitive personal data or personality profiles to third parties without justification.\n\n3. Normally there is no breach of privacy if the data subject has made the data generally accessible\nand has not expressly prohibited its processing.\n\nArt. 13 Justification\n\n1. Abreach of privacy is unlawful unless it is justified by the consent of the injured party, by an\noverriding private or public interest or by law.\n\n2. Anoverriding interest of the person processing the data shall in particular be considered if that\nperson:\n\na. processes personal data in direct connection with the conclusion or the performance of a\ncontract and the personal data is that of a contractual party;\n\nb. is orintends to be in commercial competition with another and for this purpose processes\npersonal data without disclosing the data to third parties;\n\nc. process data that is neither sensitive personal data nor a personality profile in order to verify\nthe creditworthiness of another, and discloses such data to third parties only if the data is\nrequired for the conclusion or the performance of a contract with the data subject;\n\nd. processes personal data on a professional basis exclusively for publication in the edited\nsection of a periodically published medium;\n\ne. processes personal data for purposes not relating to a specific person, in particular for the\npurposes of research, planning and statistics and publishes the results in such a manner that\nthe data subjects may not be identified;\n\nf. collects data on a person of public interest, provided the data relates to the public activities\nof that person.\n\n@ GLEIS - Global LEI System Master Agreement Page 6 of 11\nGLEIF Appendix 11 — Master Copy Version 1.1\n2016-02-01-MA-Appendix-11-Swiss-Data-Protection-Act-Final.docx 1 February 2016\n","contentLength":2232,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:30:38.198Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2016-02-01-ma-appendix-11-swiss-data-protection-act_final.pdf","content":"Art. 14 Duty to provide information on the collection of sensitive personal data and\npersonality profiles\n1. The controller of the data file is obliged to inform the data subject of the collection of sensitive\npersonal data or personality profiles; this duty to provide information also applies where the\ndata is collected from third parties.\n2. The data subject must be notified as a minimum of the following:\na. the controller of the data file;\nb. the purpose of the processing;\nc. the categories of data recipients if a disclosure of data is planned.\n3. Ifthe datais not collected from the data subject, the data subject must be informed at the latest\nwhen the data is stored or if the data is not stored, on its first disclosure to a third party.\n4. The duty of the controller of the data file to provide information ceases to apply if the data\nsubject has already been informed or, in cases under paragraph 3, if:\na. the storage or the disclosure of the data is expressly provided for by law; or\nb. the provision of information is not possible or possible only with disproportionate\ninconvenience or expense.\n5. The controller of the data file may refuse, restrict or defer the provision of information subject to\nthe requirements of Article 9 paragraphs 1 and 4.\n[note: the remainder of the Act (Articles 15-39) is not relevant in the context of GLEIF-LOU]\n@ GLEIS - Global LEI System Master Agreement Page 7 of 11\nGLEIF Appendix 11 — Master Copy Version 1.1\n2016-02-01-MA-Appendix-11-Swiss-Data-Protection-Act-Final.docx 1 February 2016\n","contentLength":1544,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:30:38.198Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2016-02-01-ma-appendix-11-swiss-data-protection-act_final.pdf","content":"Ordinance to the Federal Act on Data Protection\n\nChapter 1: Processing of Personal Data by Private Persons\n\nSection 1: Right of Access\n\nArt. 1 Modalities\n\n1. Anyone who requests information from the controller of a data file on whether data concerning\nthem is being processed (Art. 8 DPA) must normally request the information in writing and\nprovide proof of their identity.\n\n2. Requests for information as well as the provision of information may also be made online if the\ncontroller of the data file expressly arranges for this and takes appropriate measures to:\n\na. guarantee the identification of the data subject; and\nb. protect the personal data of the data subject when providing information against\nunauthorised access by third parties.\n\n3. With the agreement of the controller of the data file or at his suggestion, the data subject may\ninspect their data in situ. The information may also be provided verbally if the data subject has\nconsented and has been identified by the controller.\n\n4. The information or the substantiated decision on the restriction of the right of access (Art. 9 and\n10 DPA) is provided within 30 days of receipt of the request for information. If the information\ncannot be provided within 30 days, the controller of the data file must notify the applicant of this\nand of the date by which the information will be provided.\n\n5. If one or more data files are jointly held by two or more controllers, the right of access may be\nasserted against each controller, unless one of them is responsible for processing all requests for\ninformation. If the controller of the data file is not authorised to provide information, he shall\npass the request on to the person responsible.\n\n6. If the request for information relates to data that is being processed by a third party on behalf of\nthe controller of the data file, the controller shall pass the request on to the third party for\nprocessing if the controller is not able to provide the information himself.\n\n7. Ifinformation is requested on data relating to deceased persons, it must be provided if the\napplicant proves an interest in the information that is not countered by the overriding interests\nof relatives of the deceased or third parties. Close relatives and persons who have been married\nto the deceased have a justified interest.\n\nArt. 2 Exceptions to the exemption from costs\n\n1. The payment of an appropriate share of the costs may by way of exception be requested if:\n\na. the applicant has already been provided with the requested information in the twelve\nmonths prior to the application and no legitimate interest in the further provision of\nGLEIS - Global LEI System Master Agreement Page 8 of 11\nGLEIF Appendix 11 — Master Copy Version 1.1\n2016-02-01-MA-Appendix-11-Swiss-Data-Protection-Act-Final.docx 1 February 2016\n","contentLength":2816,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:30:38.198Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2016-02-01-ma-appendix-11-swiss-data-protection-act_final.pdf","content":"information can be proven. A legitimate interest is constituted in particular if the personal\ndata has been modified without notice being given to the data subject;\nb. the provision of information entails an exceptionally large amount of work.\n\n2. The share of the costs amounts to a maximum of 300 francs. The applicant must be notified of\nthe amount of the share before the information is provided and may withdraw his request within\nten days.\n\nSection 2: [note: not relevant in the context of GLEIF-LOU]\n\nSection 3: Transborder Disclosure\n\nArt. 5 Publication in electronic form\n\nIf personal data is made generally accessible by means of automated information and\n\ncommunications services for the purpose of providing information to the general public?, this\n\nis not deemed to be transborder disclosure.\n\nArt. 6 Duty to provide information\n\n1. [note: not relevant in the context of GLEIF-LOU]\n\n2. [note: not relevant in the context of GLEIF-LOU]\n\n3. The duty to provide information is [...] regarded as fulfilled if data is transmitted on the basis of\nmodel contracts or standard contract clauses that have been drawn up or approved by the\nCommissioner, and the Commissioner has been informed about the use of these model contracts\nor standard contract clauses by the controller of the data file. The Commissioner shall publish a\nlist of the model contracts and standard contract clauses that he has drawn up or approved.\n[note: the Model Clauses of the European Union are approved].\n\n4. The controller of the data file shall take appropriate measures to ensure that the recipient\ncomplies with the safeguards and the data protection rules.\n\n5. [note: not relevant in the context of GLEIF-LOU]\n\nArt. 7 [note: not relevant in the context of GLEIF-LOU]\n\nSection 4: Technical and organisational measures\n\nArt. 8 General measures\n\n1. Anyone who as private individual processes personal data or provides a data communication\nnetwork shall ensure the confidentiality, availability and the integrity of the data in order to\n\n1For the avoidance of doubt, \"general public\" in Art. 5 DPO is the English translation of the term in the three\n\nnational languages of Switzerland, i.e. of the German \"die Offentlichkeit\", of the equivalent French \"le public\"\n\nand of the equivalent Italian \"il pubblico\", respectively. This term, as used in the DPO, is (legally, contractually)\nunrelated to the definition of \"General Public\" in the Master Agreement.\nGLEIS - Global LEI System Master Agreement Page 9 of 11\nGLEIF Appendix 11 — Master Copy Version 1.1\n2016-02-01-MA-Appendix-11-Swiss-Data-Protection-Act-Final.docx 1 February 2016\n","contentLength":2617,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:30:38.198Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2016-02-01-ma-appendix-11-swiss-data-protection-act_final.pdf","content":"ensure an appropriate level of data protection. In particular, he shall protect the systems against\n\nthe following risks:\n\na. unauthorised or accidental destruction;\n\nb. accidental loss;\n\nc. technical faults;\n\nd. forgery, theft or unlawful use;\n\ne. unauthorised alteration, copying, access or other unauthorised processing.\n\n2. The technical and organisational measures must be adequate. In particular, they must take\naccount of the following criteria:\n\na. the purpose of the data processing;\n\nb. the nature and extent of the data processing;\n\nc. anassessment of the possible risks to the data subjects;\n\nd. the current state of the art.\n\n3. These measures must be reviewed periodically.\n\nArt. 9 Special measures\n\n1. The controller of the data file shall, in particular for the automated processing of personal data,\ntake the technical and organisational measures that are suitable for achieving the following goals\nin particular:\n\na. entrance control: unauthorised persons must be denied the access to facilities in which\npersonal data is being processed;\n\nb. personal data carrier control: unauthorised persons must be prevented from reading,\ncopying, altering or removing data carriers;\n\nc. transport control: on the disclosure of personal data as well as during the transport of data\ncarriers, the unauthorised reading, copying, alteration or deletion of data must be\nprevented;\n\nd. disclosure control: data recipients to whom personal data is disclosed by means of devices\nfor data transmission must be identifiable;\n\ne. storage control: unauthorised storage in the memory as well as the unauthorised knowledge,\nalteration or deletion of stored personal data must be prevented;\n\nf. usage control: the use by unauthorised persons of automated data processing systems by\nmeans of devices for data transmission must be prevented;\n\ng. access control: the access by authorised persons must be limited to the personal data that\nthey required to fulfilment their task;\n\nh. input control: in automated systems, it must be possible to carry out a retrospective\nexamination of what personal data was entered at what time and by which person.\n\n2. The data files must be structured so that the data subjects are able to assert their right of access\nand their right to have data corrected.\n@ GLEIS - Global LEI System Master Agreement Page 10 of 11\nGLEIF Appendix 11 — Master Copy Version 1.1\n2016-02-01-MA-Appendix-11-Swiss-Data-Protection-Act-Final.docx 1 February 2016\n","contentLength":2464,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:30:38.198Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2016-02-01-ma-appendix-13-individual-deviations-from-the-ma_final.pdf","content":"O:GLEIF, rotaceny digptortnuss\n\nIndividual Deviations from\nthe Master Agreement\nAppendix 13\n","contentLength":92,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:30:45.957Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2016-02-01-ma-appendix-13-individual-deviations-from-the-ma_final.pdf","content":"Individual Deviations from the Master\nAgreement\nFor the avoidance of doubt, the LOU must comply with the Master Agreement and its Appendices\nupon Accreditation. Where and to the extent the LOU can show to GLEIF's reasonable satisfaction\nthat this will not be possible in certain areas despite all reasonable efforts having been made, it\nbindingly commits to comply as per the below schedule.\nNote: the remainder of this standard Appendix 13 is a template; it will be replaced at the time of\nAccreditation by an Appendix 13 with the agreed commitments.\nAppendix 13 as agreed at the time of Accreditation will likely include references to the\nfollowing:\ne Pre-LOU’s permission to continue issuing LEls under the endorsement of the ROC, i.e. without\nAccreditation\n* Documentation regarding\no the current contracts between the pre-LOU and the Legal Entities, including earliest\no termination/update possible\no the current services and service levels\no the current terms of use for (pre-)LEls\no the current rules in place for the pre-LOU regarding data protection\ne LOU-Records (Sub-Chapter IV.B of the Agreement)\no Applicability of\nAppendix 05, LOU-contract requirements, i.e. a new\ncontract with all existing Legal Entities to which a pre- as of\nLEl has been issued, with retroactive effect except\nperformed obligations and effected payments:\nAppendix 06, Service Levels: as of\nAppendix 07, Payments: as of date of certification\nAppendix 09, Terms of Use: as of date of certification or earlier\nAppendix 11, Data Protection: as of date of certification or earlier\nGLEIS - Global LEI System Master Agreement Page 2 of 3\nGLEIF Appendix 13 — Master Copy Version 1.1\n2016-02-01 MA-Appendix-13-Individual-Deviations-from-the-MA-Final.docx 1 February 2016\n","contentLength":1747,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:30:45.957Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2016-02-01-ma-appendix-13-individual-deviations-from-the-ma_final.pdf","content":"o Detailed transition plans\ne in general, how to migrate from pre-LOU status to Accredited LOU status\no specifically, how to ensure that pre-LEls including pre-LE-RD are compliant with GLEIF's\nrequirements under the MA, including particularly (without any limitation) validation\nprocedures and sources, and quality and quality assurance\no specifically, how to transfer all of the LEIs / LE-RD issued by the pre-LOU to GLEIF's\nCentral LEI Repository\n° etc\nGLEIS - Global LEI System Master Agreement Page 3 of 3\nGLEIF Appendix 13 — Master Copy Version 1.1\n2016-02-01 MA-Appendix-13-Individual-Deviations-from-the-MA-Final.docx 1 February 2016\n","contentLength":641,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:30:45.957Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2023-03-28-ma-appendix-14-third-party-services-v1.3.pdf","content":"OGLEIF’ Protecting digtal rust\nRequirements for Third\nParty Services\n\nAppendix 14\n","contentLength":82,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:30:55.147Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2023-03-28-ma-appendix-14-third-party-services-v1.3.pdf","content":"Requirements for Third Party Services\n\n1. Any third party used by the LOU must operate under a confidentiality and data protection\nagreement which is materially equivalent to the respective provisions of the Master Agreement.\n\n2. Inthe light of Sections 13 and 14 of the Master Agreement, GLEIF reserves to assess any and all\nuses of Third Party Services. The following provisions are rules, but do not constitute general\nclearance.\n\n3. Forany use of Third Party Services under Sub-Chapter Ill.B of the Master Agreement, the LOU\nmust provide (i) a complete overview, and (ii) complete contracts (excepting administrative\ncontracts), in its Accreditation Documentation.\n\n4. The services of third parties running part of or the entire administrative infrastructure of the LOU\nshall as a rule be accepted. They may not make any reference to GLEIF or the GLEIS, and they are\nexplicitly not authorized to use, or make reference to, the GLEIF Trademark and Logo.\n\n5. Third Party Services used for assistance in the performance of the Services agreed in the Service\nLevel Agreement (Appendix 06; hereinafter for the purposes of this Appendix \"SLA-Services\")\ninclude third parties like typically registration agents, which help Legal Entities to access the\nnetwork of LOUs (e.g. facilitate and handle communication with, and payments of, the Legal\nEntity). Such third parties will, as a rule, be granted by GLEIF a licence as set out in Sub-Chapter\nIX.F of the Master Agreement, provided they agree in writing to the terms and conditions of such\nlicense, and further provided they agree that GLEIF may at any time cancel the licence if its terms\nand conditions are not meticulously observed.\n\n6. Third parties used by the LOU to partly or fully perform the SLA-Services are admitted only if the\nLOU is and stays in full control of the third party relative to the SLA-Services, which includes:\n\na. The LOU has at all times unrestricted access to the work results of the SLA-Services;\n\nb. Such access to SLA-Services work results is granted unconditionally, and without\nunreasonable cost, or need for resources in terms of time or staff, and anytime during\nbusiness hours, in particular without regard to any issue the LOU and the third party might\nhave over their agreement;\n\nc. The LOU has the right to inspect - upon reasonable prior notice - and to audit (or have\naudited) the third party regarding the SLA-Services;\n\nd. The LOU has and keeps the right to issue directives, general or specific, to the third party,\nand the third party submits unconditionally (excepting breaches of mandatory applicable\nlaw) to follow them to the letter;\n\ne. The third party subscribes in writing, vis-a-vis the LOU, to all provisions of the Master\nAgreement (including for the avoidance of doubt the Appendices) which have or may have\nan impact on the SLA-Services;\n\nf. The LOU regularly monitors the behaviour of the registration agent towards Legal Entities,\ncompetitors of the registration agent, the LOU and other LOUs and the registration agent’s\ncompliance with the currently valid version of the “Registration Agent Governance\n\nGLEIS - Global LEI System Master Agreement Page 2 of 3\nGLEIF Appendix 14 — Master Copy Version 1.2\n2023-03-28-MA-Appendix-14-Third-Party-Services-v1.3 28 March 2023\n","contentLength":3278,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:30:55.148Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2023-03-28-ma-appendix-14-third-party-services-v1.3.pdf","content":"Framework”. When GLEIF or the LOU are not satisfied with the behaviour of the registration\nagent, GLEIF or LOU will take necessary steps to correct that behaviour, with the ultimate\npossibility as described in sections g and h;\n\ng. The LOU has and keeps the right to terminate its agreement with the third party\nimmediately, whereupon the third party shall without any undue delay hand over (physically\nor electronically or by any reasonable means) any and all work results of the SLA-Services to\nthe LOU;\n\nh. GLEIF has the right to request the LOU to terminate the LOU’s agreement with the third party\nimmediately.\n\n7. GLEIF shall determine in its reasonable discretion,\n\na. if and how the third party may use in conjunction with the GLEIF Trademark and Logo the\nLOU's trademarks and logos, the LOU's company name, and similar characteristics or signs\nused by the LOU;\n\nb. if and how the third party may present itself to the General Public as performing SLA-Duties\nto the LOU;\n\nc. ifand how the third party shall be granted by GLEIF a licence as set out in Sub-Chapter IX.F of\nthe Master Agreement, provided the third party agrees in writing to the terms and\nconditions of such license, and further provided it agrees that GLEIF may at any time cancel\nthe licence if its terms and conditions are not meticulously observed.\n\n8. GLEIF shall pay special attention to the way the third party presents itself and its SLA-Services to\nthe General Public, in particular to Legal Entities seeking an LEI from the LOU, so as to avoid any\nconfusion of the General Public and Legal Entities that the LOU (and not the third party) is fully\nresponsible and liable for the SLA-Services.\n\n9. GLEIF reserves to require the right that the LOU provide proper contractual provisions in its\ncontract with Legal Entities (supplementing the requirements set out in Appendix 05) to clarify\nmatters of SLA-Services, of responsibility and liability, and of data protection.\n\n10. Qualified third parties for the assessment of the LOU's financial, operational and/or information\ntechnology practices and for independent audit purposes shall as a rule be accepted by GLEIF,\nprovided satisfactory evidence for their qualification is in the Accreditation Documentation.\n\n11. For the avoidance of doubt, with reference to Section 81 of the Master Agreement, the LOU shall\nbe liable for all acts or omissions regarding the Master Agreement's performance like those acts\nor omissions were its own.\n\nGLEIS - Global LEI System Master Agreement Page 3 of 3\nGLEIF Appendix 14 — Master Copy Version 1.2\n2023-03-28-MA-Appendix-14-Third-Party-Services-v1.3 28 March 2023\n","contentLength":2632,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:30:55.148Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/2022-02-22_cdf_questions_and_answers_v2.4.pdf","content":"@’ rotattng ol st\n\nCommon Data File Formats\n— Questions and Answers\nFINAL\n","contentLength":74,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:31:48.032Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/2022-02-22_cdf_questions_and_answers_v2.4.pdf","content":"Table of Contents\n) C =T 1Y - I o] 11 o1 PRPPPRPORRPRR.\n1.1 What are the GLEIF data formats? .....ccccccvvieeriiiiiiiiie et csiieeee e siane D\n1.2 How are the GLEIF data formats applied? .......cccoveeiiiiiiiiiieieniiieece e D\n1.3 How are the GLEIF data formats updated?........cccccceeiviviiiiieniiiiiieece e, 6\n1.4 How can my organization store and manage CDF data locally? .........ccccceviiinnnnnn. 6\n1.5 Whatis a CDF-formatted data file?.......cccouveeiiiiiiiiiii e, ©\n1.6 Whatis a CDF-formatted data file?........cccvuveeriiiiiiiiii i, ©\n1.7 How does GLEIF process the CDF data it receives?.......cccccveevvvcivieeeeisinineeneensncnns 7\n1.8 How do the CDF formats handle international languages and scripts?........c........ 7\n1.9 Which special characters, string lengths and character encoding can be expected\nwhen working with LEI-CDF formatted data? ........ccccceeeiiiiiieeeriiiniie i 8\n2 LEI-CDF TOPICS cetuueruneeneranrennrenrennsenceossascrnssassensesnssnsssnssnsssassesssassesssascennens O\n2.1 Whatisan LEI data file? ...ccovuiiieiiieiiieie et ee e sinnne e D\n2.2 What information is found in the LEIl data file header?.........cccccevviveeiinniiieennnn. 9\n2.3 What are LEI data reCOords? ......civiiiiiieeiiiiieeie e essiiie e es s sniveeeesssnneeee s e s snnnneessenes 9\n2.4 Whatis the structure of the LEI-CDF?......ccccviiiiiiiiiiieece e sineneee s 9\n2.4.1 LEIHEAUEITYPE. ceiiiiciiieeeeieciieee s eestteeeesestrieeesssstreeesssstreeesssssssesssssssseesssssssneessnssseeessnans L0\n2.4.2 LEIRECOIASTYPE wieiiervieeeiieitieeeeeeitieeeseettteesseetteeessseeeaessnsnseessnsnsesssssnssensssssssenasssnens L1\n2.4.3 LEIRECOIATYPE cuiiiiiciiieeeiieitieee s sectieeessettteessestteaesssveeaesssnsaeeessnnseeasssnssenessssnsenasssnnns L1\nW Ny W) AV Y oSO OO OO PP PP PP PPPP P RPRPPPPPPRPR .\n2.5 Whatisa valid LEI COU@? .......uiiiiiiiiiiiiie e ciiiieeee e cssitie e e svvveeeessssinneeesessssnnneesees 19\n2.6 Whatisthe LEl code prefiX?..... et siiieeeessssiieeee s esssineneeeees 19\n2.7 How isthe LEI code generated?........ccccceeevviiieeiiiiiniiiiiece s siiieeeeesssiieeeesessineneeenss 19\n2.8 How are the LEI code’s check digits calculated and checked?............................. 19\n2.9 What information about a legal entity is required by the LEI-CDF?..................... 20\n2.10 What additional information can be provided in LEIl data records? .................... 20\n2.11 Which status fields are used in an LEl data record?........cccccccevevvinieeeennnicineeennn. 20\n2.12 Which other codes and standards are included in the LEI-CDF? ...........cccccuee..... 21\n2.13 How do LEl Issuers deal with changes, corrections and updates to the LEI-CDF\ndata they deliver t0 GLEIF? .......oiiviiiiiie e ssieeee s e sinnaeeeees 22\n3 RR-CDF TOPICS ceuteuirerenerenrennrenrennsencransencrnssessensssnssasssnssssssassesssssssnssancensss 3\n3.1 What are RR-CDF Fil@S?...cciiiiiiiiiiie ettt seete e srae e e s ssvveeee s s s siiinneees 23\n3.2 Whatis the structure of the RR-CDF? ......ccccoviiiiiiiiiiiiieeeeeciiieee s eniieeee s sineeens 23\n3.2.1 RelationshipDataTyPe ...ccccvieei ittt eerre e errae e e s srae e e s sree e e e eeee 23\n3.2.2 RRHEAUEITYPE . ceiiiiciiiiiecitieie s eestteeeesestrieeessstteee s setreeessssssseesssnssseessnssssneessnssseeeesnnns 200\n3.2.3 RelationshipRECOIASTYPE ..uuiieiieciiiieeccriieeecctrie e eeree e e eeevee e ssreae e e s sree s e s ssneeaaeseeee 2D\nG Common Data File Formats — Questions and Answers Page 2 of 35\n@ Public Version 2.4\n2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22\n","contentLength":3535,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:31:48.032Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/2022-02-22_cdf_questions_and_answers_v2.4.pdf","content":"2.4.2 LEIRecordsType\nLEIRecord lei:LEIRecordType {0,unbounded} Contains all LEI reference data including details of the LEl's registration\nwith the ManagingLOU.\nExtension lei:ExtensionType {0,1} This lei:Extension element\n2.4.3 LEIRecordType\n) The ISO 17442 compatible identifier for the legal entity described in the Entity\nLEI lei:LEIType {1,1} .\nsection.\n) L The Entity container element contains the legal entity's reference data,\nEntity lei:EntityType {1,1} L e .\nenabling identification.\n) ) ) ) ) The Registration container element contains all information on the legal entity's\nRegistration lei:RegistrationType {1,1} ) . . .\nLEI registration with the ManagingLOU.\nCommon Data File Formats — Questions and Answers Page 11 of 35\n@ Public Version 2.4\n2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22\n","contentLength":815,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:31:48.032Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/2022-02-22_cdf_questions_and_answers_v2.4.pdf","content":"A structure for adding further elements in to the LEI Data Record in anticipation\nof a new version, by nesting a series of XML elements with this content model\nNextVersion lei:LEIRecordNextVersionType {0,1} within the NextVersion element, one for each new minor version of the\nschema, postpending a serial number (1,2,3...) to the element name upon each\niteration.\n) ) ) This lei:Extension element may contain any additional elements required to\nExtension lei:ExtensionType {0,1}\nextend the LEIRecord.\n2.4.4 EntityType\nLegalName lei:NameType {1,1} The legal name of the entity.\nOtherEntityNames lei:OtherEntityNamesType {0,1} An optional list of other names (excluding\ntransliterations) for the legal entity.\nTransliteratedOtherEntityNames lei:TransliteratedOtherEntityNamesType {0,1} An optional list of ASClI-transliterated (i.e.,\nLatin- or Romanized) representations of names\nfor the legal entity.\nCommon Data File Formats — Questions and Answers Page 12 of 35\n@ Public Version 2.4\n2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22\n","contentLength":1043,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:31:48.032Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/2022-02-22_cdf_questions_and_answers_v2.4.pdf","content":"LegalAddress lei:AddressType {1,1} The address of the entity as recorded in the\nregistration of the entity in its legal jurisdiction.\n\nHeadquartersAddress lei:AddressType {1,1} The address of the headquarters of the Entity.\n\nOtherAddresses lei:OtherAddressesType {0,1} An optional list of other addresses for the legal\nentity, excluding transliterations.\n\nTransliteratedOtherAddresses lei:TransliteratedOtherAddressesType {0,1} An optional list of transliterated addresses for\nthe legal entity.\n\nRegistrationAuthority lei:RegistrationAuthorityType {0,1} An identifier for the legal entity in a business\nregistry in the jurisdiction of legal registration,\nor in the appropriate registration authority.\n\nLegallurisdiction lei:JurisdictionCodeType {0,1} The jurisdiction of legal formation and\nregistration of the entity (and upon which the\nLegalForm data element is also dependent).\nPlease note that the XML schema validates the\nformat of Legallurisdiction codes but not the\nspecific codes conforming to the ISO standards\nit requires.\n\nCommon Data File Formats — Questions and Answers Page 13 of 35\n@ Public Version 2.4\n2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22\n","contentLength":1176,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:31:48.032Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/2022-02-22_cdf_questions_and_answers_v2.4.pdf","content":"EntityCategory lei:EntityCategoryTypeEnum {0,1} Indicates (where applicable) the category of\nentity identified by this LEI data record, as a\nmore specific category within the broad\ndefinition given in ISO 17442. These categories\nare based on use cases specified in LEI-ROC\npolicies, found at\nhttp://www.leiroc.org/list/leiroc_gls/index.htm\n\nEntitySubCategory lei:EntitySubCategoryTypeEnum {0,1} Indicates and specifies further (where\napplicable) the sub-category (sub-sector) of\nLegal Entity identified by this LEI Record and\nalready categorized by the EntityCategory.\n\nLegalForm lei:LegalFormType {0,1} The legal form of the entity, taken from the ISO\nEntity Legal Form (ELF) code list maintained by\nGLEIF. Please note that the XML schema\nvalidates the format of LegalForm codes but\nnot the specific codes conforming to the ISO\nstandard it requires.\n\nCommon Data File Formats — Questions and Answers Page 14 of 35\nGLEIF Public Version 2.4\n@ 2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22\n","contentLength":1000,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:31:48.032Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/2022-02-22_cdf_questions_and_answers_v2.4.pdf","content":"AssociatedEntity lei:AssociatedEntityType {0,1} Another entity associated with this entity if\nneeded to fully identify this entity or to place it\nin an appropriate context.\n\nNote: This is a deprecated field and is\nmaintained for technical backward\ncompatibility.\n\nEntityStatus lei:EntityStatusEnum {1,1} The operational and/or legal registration status\nof the entity (may be ACTIVE, INACTIVE, or\nNULL).\n\nEntityCreationDate lei:LEIDateTimeProfileGeYear0001 {0,1} The date on which the legal entity was first\nestablished as defined in ISO 17442.\n\nEntityExpirationDate lei:LEIDateTimeProfile {0,1} The date that the legal entity ceased to\noperate, whether due to dissolution, merger or\nacquisition.\n\nNote: This is a deprecated field and is\nmaintained for technical backward\ncompatibility.\n\nEntityExpirationReason lei:EntityExpirationReasonEnum {0,1} The reason that a legal entity ceased to exist\nand/or operate.\n\nCommon Data File Formats — Questions and Answers Page 15 of 35\nGLEIF Public Version 2.4\n@ 2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22\n","contentLength":1059,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:31:48.032Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/2022-02-22_cdf_questions_and_answers_v2.4.pdf","content":"Note: This is a deprecated field and is\nmaintained for technical backward\ncompatibility.\nSuccessorEntity lei:SuccessorEntityType {0,unbounded} The surviving/new legal entity which\ncontinues/replaces this registration.\nLegalEntityEvents lei:LegalEntityEventsType {0,1} Container for a finite number of events\nspecified by the LEI ROC in the life of a legal\nentity that would impact the Reference Data in\nthe Global LEI System.\nNextVersion lei:EntityNextVersionType {0,1} A structure for adding further elements into\nthe Entity section of the LEl data record in\nanticipation of a new version, by nesting a\nseries of XML elements with this content model\nwithin the NextVersion element, one for each\nnew minor version of the schema, postpending\na serial number (1,2,3...) to the element name\nupon each iteration.\nCommon Data File Formats — Questions and Answers Page 16 of 35\nGLEIF Public Version 2.4\n@ 2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22\n","contentLength":957,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:31:48.032Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/2022-02-22_cdf_questions_and_answers_v2.4.pdf","content":"InitialRegistrationDate lei:LEIDateTimeProfile {1,1} Date/time the LEI record was created.\nLastUpdateDate lei:LEIDateTimeProfile {1,1} Date/time the LEI record was most recently updated.\nRegistrationStatus lei:RegistrationStatusEnum {1,1} The status of the legal entity's LEI registration with the\nManagingLOU.\nNextRenewalDate lei:LEIDateTimeProfile {1,1} The next date by which the LEI registration should be\nrenewed and re-certified by the legal entity.\nManagingLOU lei:LEIType {1,1} The LEI of the LOU that is responsible for administering\nthis LEI registration.\nValidationSources lei:ValidationSourcesEnum {0,1} The level of validation of the reference data provided by\nthe registrant.\nValidationAuthority lei:ValidationAuthorityType {0,1} The (primary) registration authority used by the LOU to\nvalidate the entity data.\nOtherValidationAuthorities lei:OtherValidationAuthoritiesType {0,1} An optional list of additional registration authorities used\nby the LEl Issuer to validate the entity data.\nCommon Data File Formats — Questions and Answers Page 17 of 35\n@ Public Version 2.4\n2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22\n","contentLength":1144,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:31:48.032Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/2022-02-22_cdf_questions_and_answers_v2.4.pdf","content":"NextVersion lei:RegistrationNextVersionType {0,1} A structure for adding further elements into the\nRegistration section of the LEI Data Record in anticipation\nof a new version, by nesting a series of XML elements with\nthis content model within the NextVersion element, one\nfor each new minor version of the schema, postpending a\nserial number\n\nCommon Data File Formats — Questions and Answers Page 18 of 35\nGLEIF Public Version 2.4\n@ 2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22\n","contentLength":492,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:31:48.032Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/2022-02-22_cdf_questions_and_answers_v2.4.pdf","content":"2.5 What is a valid LEI code?\n\nAll LEI codes must contain only combinations of the digits 0 to 9 and the upper-case letters A to Z.\nLower case letters are not allowed. The final 2 digits (the check digits) must be numeric only.\n\nThis is required by the LEI standard, 1ISO 17442, and the LEIl code character set is enforced by the\nCommon Data File formats.\n\nA valid LEI code must also have correct check digits.\n\n2.6 What is the LEI code prefix?\n\nThe first 4 digits of an LEI (its “prefix”) are reserved to an LEl Issuer to ensure that LEl codes are\nunique at the point of issuance; this is an additional operational principle which is not explicitly\nrequired by ISO 17442. This is not checked automatically by the CDF XML schemas.\n\nPlease note that the prefix of any LEI code is added at the initial registration of a legal entity, solely to\nprevent duplication of codes across two or more LEl Issuers. It has no intrinsic meaning and no other\nuse.\n\nSome LEI codes were issued before the LEI ROC's operational standards came into effect. These\ncodes may have prefixes that do not match any LEl Issuer.\n\n2.7 How is the LEI code generated?\n\nCharacters 5-18 of the LEI code are the entity-specific section, generated and assigned by LOUs\naccording to transparent, sound and robust allocation policies. As required by ISO 17442, it contains\nno embedded intelligence.\n\n2.8 How are the LEI code’s check digits calculated and checked?\n\nThe 2 check digits of an LEI are calculated from the first 18 characters of the LEI, according to the I1SO\nStandard 17442, which itself refers to ISO Standard 7064. Both standards are available from\nWWW.iso.org at a cost.\n\nPlease note that the check digits are only a technical, statistical protection against manual\ntranscription errors (e.g., character transposition during data entry or automated character\nrecognition).\n\nIncorrect check digits indicate the probable presence of an error in the other 18 characters. Correct\ndigits indicate the absence of such errors. The check digits are no indication of any other type of\ndefect beyond this probability, and they do not relate in any way to the LEI reference data.\n","contentLength":2149,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:31:48.032Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/2022-02-22_cdf_questions_and_answers_v2.4.pdf","content":"2.9 What information about a legal entity is required by the LEI-\nCDF?\nThe minimum reference data for an LEl data record as defined by ISO 17442 and enforced by the LEI-\nCDF is as follows:\n¢ The official name of the legal entity as recorded in the business registry, or with the fund\nmanager for collective investment vehicles, or otherwise in the entity’s constituting documents.\n* Where applicable:\no The name of the business registry in which the entity was formed.\n¢ The identifier of the entity in the business registry.\no The address of the headquarters of the legal entity or the address of the fund manager.\n¢ The address and the country of legal formation as represented in ISO 3166.\n¢ The date of the first LEl assignment; the date on which the legal entity first established.\n¢ The date of last update of the LEIl set of information.\n¢ The date of expiry, where applicable.\no The reason for expiry, if applicable.\no For entities with a date of expiry, where applicable, the LEI of the entity or entities that acquired\nthe expired entity.\nIn addition to LEI-CDF information, a legal entity must report its relationship information, per current\nLEI-ROC policy, to keep its LEIl in good standing (issued). This is reported to GLEIF by the LEl Issuer,\nusing the RR-CDF format (and the Reporting Exceptions format, where applicable).\n2.10 What additional information can be provided in LEI data\nrecords?\no The legal form of the entity.\ne Other names or representations of names for the legal entity.\no Alegal or headquarters address in different languages.\nCustom fields may (optionally) also be added; please see below.\n2.11 Which status fields are used in an LEI data record?\nThe Legal Entity Reference Data (LE-RD) provided with each LEI code, contains two status fields:\ne EntityStatus - The status of the legal entity (active, inactive, or null).\ne RegistrationStatus -The status of the LEl registration with the LEI Issuer.\nG Common Data File Formats — Questions and Answers Page 20 of 35\n@ Public Version 2.4\n2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22\n","contentLength":2081,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:31:48.032Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/2022-02-22_cdf_questions_and_answers_v2.4.pdf","content":"3.2.4 RelationshipRECOIATYPE. . .uuiiiiieciiiiie ittt ceie e eerre e esrrae e e s sree e e e sreeaaeeeeee 2D\n\n3.2.5 RelationshipContainerTYPe ..ccccccieeeiieciiieee it cetiee e sssrrre e sssrrreeesssreeeesssssseeeesenns 20\n\n3.2.6 NOUETYPE cooiiiieeit ettt ettt ee s eestte e ee st reesse st be e e ssstbeeeesssereeesssateessnnsaeeessnnssseessnns 28\n\n3.2.7 RelationshipPeriodsTyPe . .uueiiiccieeee ittt esrreeesessrrreee s ssraeeesssrreeeesnees 28\n\n3.2.8 RelationshipPeriodTYPe ...cveeeiecciiiiiiieiiieie ettt e s sssrare e s ssraeeeessraeeeeseees 28\n\n3.2.9 RelationshipQUAlIfIErSTYPE .....uvevciiiecieecce et sree e e sree e ssneeeneeeeeees 29\n3.2.10RelationshipQUAlIfIErTYPE ..cccvvveeeeie et e sree e esneesneeeeeees 29\n3.2.11RelationshipQuUantifiersTYPe .....ccccveeceeiisiee et ceesrcree e e ste e eseee e seeeesseaeeseeeeenes 30\n3.2.12RelationshipQuUantifierTyPe......ccccueecciiesececeee e esecreeeceeeste e eseee e sreeessseaeseneeeenes 30\n3.2.13RegistrationCoNtaiNerTYPe. .. ..uuuiriiiiieieeieeirciieeiete e e ee e s siererreeeeseessessssnnneeseneess 31\n\n3.3 What information is found in the relationship data file header? ........................ 33\n\n3.4 What are relationship records? ........cccviieiiiiiiiin e eeeees 33\n\n3.5 Do relationship records have a unique ID? ........cccccvviiiieeiiiiiiieeee s esrieeee e essieeees 33\n\n3.6 What information about a relationship is required by the RR-CDF? ................... 33\n\n3.7 What if relationship information is not available for a legal entity?.................... 33\n\n3.8 What are the status fields used in a relationship record? .........ccceccvvvvvvviiinnnee... 34\n\n4 Where can | find further information?.......cc.cccevvviiiiiiinciiiiiinncciniieeennnn. 35\n4.1 GLEIF FIlES oottt ettt e e e eeeeeeee e e e e e es s s nnsanssesaesaesseeaaanaaees 3D\n\n4.2 LELISSUET fIllES coiuiiiiieiei ittt sttt e e s saanae s e s s svaae e e s snnnnnees 3D\n\n4.3 Whom should | contact for further questions?.........cccccceevevvvciieeinvcciieeeeeiiineen. 35\nG Common Data File Formats — Questions and Answers Page 3 of 35\n@ Public Version 2.4\n2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22\n","contentLength":2148,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:31:48.032Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/2022-02-22_cdf_questions_and_answers_v2.4.pdf","content":"For afull list of EntityStatus and RegistrationStatus values, including descriptions,\nplease see the detailed specification of the LEl Common Data File format XML Schema Definitions.\n2.12 Which other codes and standards are included in the LEI-CDF?\nThe following code lists are managed by GLEIF:\nLegalForm Entity Legal Form (ELF) Code; Resolves variant names for\nISO Standard 20275 each valid legal form within a\njurisdiction to a single code\nper legal form, per\njurisdiction.\nRegistrationAuthority Registration Authority List (RAL) Identifies a business registry\nin the jurisdiction of legal\nregistration, or appropriate\nregistration authority (e.g.,\none of the varieties of funds\nregistered instead with\nfinancial regulators).\nOther codes managed by third parties included in the LEI-CDF are used to ensure data quality:\nCountry The 2-character I1SO 3166-1 country code of the country.\nRegion The 4- to 6-character ISO 3166-2 region code of the region.\nLegal Jurisdiction Either an ISO 3166-1 country code or an ISO 3166-2 region code.\nxml:lang An IETF Language Code conforming to RFC 4646.\nCommon Data File Formats — Questions and Answers Page 21 of 35\n@ Public Version 2.4\n2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22\n","contentLength":1235,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:31:48.032Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/2022-02-22_cdf_questions_and_answers_v2.4.pdf","content":"ContentDate, DeltaStart, A subset of the ISO 8601-compliant XML Schema dateTime format\nEntityExpirationDate,\nEntityCreationDate,\nInitialRegistrationDate,\nLastUpdateDate,\nNextRenewalDate\nIETF standards can be found on the World Wide Web for free. ISO standards can be obtained from\nWWW.iso.org at a cost.\n2.13 How do LEI Issuers deal with changes, corrections and updates\nto the LEI-CDF data they deliver to GLEIF?\nLEI Issuers are responsible for the contents of their LEI data records. GLEIF simply passes on the LEI\ndata records we receive from the LEl Issuer, without changes.\nPlease address any specific queries about the LEI Issuers' data to the LEI Issuers themselves. GLEIF\nprovides contact details for all LEI Issuers at www.gleif.org.\nAn LEI data record may also be challenged directly:\ne Gotothe page for your LEl using the URL pattern below.\nhttps://www.gleif.org/lei/\nExample:\nhttps://www.gleif.org/lei/549300Q82NZ9NYNMZT63\no Click the “Challenge” button at the foot of the page to send a proposed update directly to the LEI\nIssuer through GLEIF’s central Challenge Service.\nCommon Data File Formats — Questions and Answers Page 22 of 35\n@ Public Version 2.4\n2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22\n","contentLength":1238,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:31:48.032Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/2022-02-22_cdf_questions_and_answers_v2.4.pdf","content":"3 RR-CDF Topics\n\n3.1 What are RR-CDF Files?\n\nThe XML format defines a container that holds a file header and a series of relationship data records.\n\n3.2 What is the structure of the RR-CDF?\n\nPlease see the tables below for an overview of the RR-CDF elements.\n\nSome “Type” column values refer to later tables; these refer to data elements that are contained within the referring element.\n\nFurther details can be found in the technical specification document PDF and corresponding XML Schema Definition (XSD), available at www.gleif.org.\n\n3.2.1 RelationshipDataType\nHeader rr:RRHeaderType {11} Contains the file upload information for this RelationshipData file.\nRelationshipRecords rr:RelationshipRecordsType {1,1} Container for all of the RelationshipRecord container elements\n\nsubmitted with this file.\n","contentLength":806,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:31:48.032Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/2022-02-22_cdf_questions_and_answers_v2.4.pdf","content":"3.2.2 RRHeaderType\n\nContentDate rr:LEIDateTimeProfile {1,1} The date and time as of which the data contained in the file is valid.\n\nOriginator rr:LEIType {0,1} The LEI of the entity that created the content of this file.\n\nFileContent rr:FileContentEnum {1,1} A code describing the content of this relationship record file.\n\nDeltaStart rr:LEIDateTimeProfile {0,1} The date and time of the baseline relative to which this file contains new\nor changed Relationship Records.\n\nRecordCount xs:nonNegativelnteger {1,1} The number of relationship records in the file.\n\nNextVersion rr:HeaderNextVersionType {0,1} A structure for adding further elements into the LEI data file header in\nanticipation of a new version, by nesting a series of XML elements with\nthis content model within the NextVersion element, one for each new\nminor version of the schema, postpending a serial number (1,2,3...) to the\nelement name upon each iteration.\n\nExtension rr:ExtensionType {0,1} This Extension element may contain any additional elements required to\nextend the Header container element.\n\nCommon Data File Formats — Questions and Answers Page 24 of 35\n@ Public Version 2.4\n2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22\n","contentLength":1211,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:31:48.032Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/2022-02-22_cdf_questions_and_answers_v2.4.pdf","content":"3.2.3 RelationshipRecordsType\nRelationshipRecord rr:RelationshipRecordType {0,unbounded} Contains all relationship information including identifiers referring to\nthe related entities, the specific type and other attributes of the\nrelationship itself, and details of the relationship's registration with\nthe ManagingLOU.\n3.2.4 RelationshipRecordType\nRelationship rr:RelationshipContainerType {1,1} The Relationship container element contains the identifiers of the\ntwo entities related by the reported relationship, as well as the\ntype of relationship, dates related to the relationship and other\nrelationship quantifiers and qualifiers.\nRegistration rr:RegistrationContainerType {1,1} The Registration container element contains information\nspecifying the LOU's administration of the relationship report.\nCommon Data File Formats — Questions and Answers Page 25 of 35\n@ Public Version 2.4\n2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22\n","contentLength":948,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:31:48.032Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/2022-02-22_cdf_questions_and_answers_v2.4.pdf","content":"NextVersion rr:RelationshipRecordNextVersionType {0,1} A structure for adding further elements into the Registration\nsection of the Relationship Record in anticipation of a new\nversion, by nesting a series of XML elements with this content\nmodel within the NextVersion element, one for each new minor\nversion of the schema, postpending a serial number (1,2,3...) to\nthe element name upon each iteration.\n\nExtension rr:ExtensionType {0,1} This Extension element may contain any additional elements\nrequired to extend the RelationshipRecord.\n\n3.2.5 RelationshipContainerType\nStartNode rr:NodeType {1,1} An LEl or ISO 17442-compatible ID for the entity at the \"start\" of\na directional relationship.\nEndNode rr:NodeType {1,1} An LEl or ISO 17442-compatible ID for the entity at the \"end\" of\na directional relationship.\nRelationshipType rr:RelationshipTypeEnum {1,1} A unique code designating the specific category of a directional\nrelationship between two legal entities.\nCommon Data File Formats — Questions and Answers Page 26 of 35\n@ Public Version 2.4\n2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22\n","contentLength":1110,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:31:48.032Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/2022-02-22_cdf_questions_and_answers_v2.4.pdf","content":"RelationshipPeriods rr:RelationshipPeriodsType {0,1} A collection of paired beginning and end dates relating to: the\nrelationship itself, periods (e.g. accounting cycles) covered by\ndocuments demonstrating the relationship, or the filing date(s)\nof those documents.\n\nRelationshipStatus rr:RelationshipStatusEnum {1,1} The status of the legal entities' relationship itself: ACTIVE,\nINACTIVE, or NULL.\n\nRelationshipQualifiers rr:RelationshipQualifiersType {O,unbounded} Any additional qualitative attributes that help to categorize the\nrelationship.\n\nRelationshipQuantifiers rr:RelationshipQuantifiersType {0,unbounded} Any additional quantitative attributes that help to categorize the\nrelationship.\n\nNextVersion rr:RelationshipNextVersionType {0,1} A structure for adding further elements in to the Registration\nsection of the Relationship Record in anticipation of a new\nversion, by nesting a series of XML elements with this content\nmodel within the NextVersion element, one for each new minor\nversion of the schema, postpending a serial number (1,2,3...) to\nthe element name upon each iteration.\n\nExtension rr:ExtensionType {0,1} This Extension element may contain any additional elements\nrequired to extend the Relationship container element.\n\nCommon Data File Formats — Questions and Answers Page 27 of 35\n@ Public Version 2.4\n2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22\n","contentLength":1392,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:31:48.032Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/2022-02-22_cdf_questions_and_answers_v2.4.pdf","content":"3.2.6 NodeType\nNodelD rr:LEIType {1,1} The identifier for the entity designated by this node.\nNodelDType rr:NodelDTypeEnum {1,1} The type of identifier used to designate this node's entity.\n3.2.7 RelationshipPeriodsType\nRelationshipPeriod rr:RelationshipPeriodType {1,unbounded} Contains one set of start and end dates for a particular type of\nperiod, for example, the duration of the relationship itself, the\nfiling or validity period of any documents demonstrating the\nrelationship, or the accounting period they refer to.\n3.2.8 RelationshipPeriodType\nStartDate rr:LEIDateTimeProfile {0,1} The start date for a particular period relevant to the relationship.\nEndDate rr:LEIDateTimeProfile {0,1} The end date for a particular period relevant to the relationship.\nCommon Data File Formats — Questions and Answers Page 28 of 35\n@ Public Version 2.4\n2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22\n","contentLength":906,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:31:48.032Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/2022-02-22_cdf_questions_and_answers_v2.4.pdf","content":"PeriodType rr:PeriodTypeEnum {1,1} The particular type of period, for example, the duration of the relationship itself, the\nfiling or validity period of any documents demonstrating the relationship, or the\naccounting period they refer to.\n\n3.2.9 RelationshipQualifiersType\nRelationshipQualifier rr:RelationshipQualifierType {0,unbounded} Container for all sets of relationship qualifier information.\n3.2.10 RelationshipQualifierType\n\nQualifierDimension rr:QualifierDimensionEnum {1,1} Designates the optional list of additional qualitative attributes\n\nthat help to categorize the relationship.\n\nQualifierCategory rr:QualifierCategoryTypeEnum {0,1} Specifies the additional qualitative attributes that help to\n\ncategorize the relationship.\n\nRelationshipQuantifier rr:RelationshipQuantifierType {0,unbounded} Specifies one additional quantitative attribute of the\n\nrelationship, according to a particular measurement method.\nCommon Data File Formats — Questions and Answers Page 29 of 35\n@ Public Version 2.4\n2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22\n","contentLength":1067,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:31:48.032Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/2022-02-22_cdf_questions_and_answers_v2.4.pdf","content":"3.2.11 RelationshipQuantifiersType\nRelationshipQuantifier rr:RelationshipQuantifierType {0,unbounded} Specifies one additional quantitative attribute of the\nrelationship, according to a particular measurement method.\n3.2.12 RelationshipQuantifierType\n\nMeasurementMethod rr:MeasurementMethodTypeEnum {1,1} Specifies the method of measurement (or set of rules) used to\nguantitatively categorize the relationship.\n\nQuantifierAmount xs:decimal {1,1} Specifies the quantity measured as a decimal (positive or\nnegative) number, using a ‘.” as the decimal point, with no spaces,\nand without thousand delimiters (e.g. ,).\n\nQuantifierUnits rr:QuantifierUnitsTypeEnum {0,1} Specifies the units, where applicable, of a measurement made on\na relationship.\n\nCommon Data File Formats — Questions and Answers Page 30 of 35\n@ Public Version 2.4\n2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22\n","contentLength":887,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:31:48.032Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/2022-02-22_cdf_questions_and_answers_v2.4.pdf","content":"_ GLEIF Head of IT Operations & Development\nAbout this Document\nThis document provides answers to common questions on the Common Data File formats developed\nby the Legal Entity Identifier Regulatory Oversight Committee (LEI ROC) and further developed and\nmaintained by GLEIF.\nChange History\nThis section records the history of all changes to this document.\n2022-02-22 Final, 2.4 Updated the document to reflect the | GLEIF\nlatest version of LEI- CDF V3.1, RR-\nCDF V2.1, and Reporting Exceptions\nformat v2.1\n2017-11-06 WORK, 2.3 Minor updates, alignment with GLEIF\nGolden Copy\n2017-05-04 FINAL, 2.2 New Level 2 version, major updates: GLEIF\nLEI-CDF V2.1, RR-CDF\n2016-11-11 FINAL, 1.0 Final version GLEIF\nCommon Data File Formats — Questions and Answers Page 4 of 35\n@ Public Version 2.4\n2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22\n","contentLength":844,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:31:48.032Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/2022-02-22_cdf_questions_and_answers_v2.4.pdf","content":"3.2.13 RegistrationContainerType\nInitialRegistrationDate rr:LEIDateTimeProfile {1,1} The date at which the relationship information was first\ncollected by the ManagingLOU.\nLastUpdateDate rr:LEIDateTimeProfile {1,1} The date at which the information was most recently updated by\nthe ManagingLOU.\nRegistrationStatus rr:RegistrationStatusEnum {1,1} The status of the legal entity's relationship record registration\nwith the ManagingLOU.\nNextRenewalDate rr:LEIDateTimeProfile {0,1} The next date by which the relationship information must be\nrenewed and re-certified by the legal entity.\nManagingLOU rr:LEIType {1,1} The LEI of the LOU that is responsible for administering this\nrelationship record.\nValidationSources rr:ValidationSourcesTypeEnum {1,1} Level of relationship validation.\nValidationDocuments rr:ValidationDocumentsTypeEnum {1,1} Type of source document(s) used for validating the relationship.\nValidationReference rr:Tokenized500Type {0,1} A reference to a specific document or other source used as the\nbasis of relationship validation for this relationship record.\nCommon Data File Formats — Questions and Answers Page 31 of 35\n@ Public Version 2.4\n2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22\n","contentLength":1221,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:31:48.032Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/2022-02-22_cdf_questions_and_answers_v2.4.pdf","content":"NextVersion rr:RegistrationNextVersionType {0,1} A structure for adding further elements into the Registration\nsection of the Relationship Record in anticipation of a new\nversion, by nesting a series of XML elements with this content\nmodel within the NextVersion element, one for each new minor\nversion of the schema, postpending a serial number (1,2,3...) to\nthe element name upon each iteration.\n\nExtension rr:ExtensionType {0,1} This Extension element may contain any additional elements\nrequired to extend the Registration container element.\n\nCommon Data File Formats — Questions and Answers Page 32 of 35\nGLEIF Public Version 2.4\n@ 2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22\n","contentLength":695,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:31:48.032Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/2022-02-22_cdf_questions_and_answers_v2.4.pdf","content":"3.3 What information is found in the relationship data file header?\n\nThe header contains the file upload information for a relationship data file.\n\n3.4 What are relationship records?\n\nA relationship record contains all mandatory and additional information on one relationship between\n\ntwo legal entities.\n\n3.5 Do relationship records have a unique ID?\n\nRelationship records themselves do not have an ID code, as, although they are reported in a\n\ntechnically separate way from LEI-CDF files, they function as part of the LEl reference data and\n\nalways contain at least one LEl. Some types of relationship, such as ultimate accounting\n\nconsolidation, may be unique, while others may be repeatable for a given legal entity.\n\n3.6 What information about a relationship is required by the RR-\n\nCDF?\n\nAll mandatory relationship types must be reported by entities with an LEI. Each relationship type has\n\nits own set of requirements for valid reporting.\n\nOther optional relationship types may be reported, but the LEI Issuer is not obliged to provide them.\n\nFurther, some data fields pertaining to specific relationship types may be optional, supplemental\n\ninformation.\n\nPlease see the State Transition Rules and Validation Rules v2.5 document for further details,\n\navailable at www.gleif.org.\n\n3.7 What if relationship information is not available for a legal\n\nentity?\n\nTo receive and keep an LEl in good standing, legal entities must provide and update all the\n\nrelationship information required by LEI-ROC policy. The latest LEI-ROC requirements can be found at\n\nwww.leiroc.org.\n\nAny acceptable reasons, per LEI-ROC policy, for non-reporting of relationship information are\n\nsupplied to GLEIF using the Reporting Exceptions format. These might include, for example:\n\n¢ Non-consolidating, whenever the accounting consolidation definition for parent relationship does\nnot apply. This category includes cases where the entity is controlled by a natural person(s)\nwithout any intermediate legal entity (“Natural Person(s)”); the entity is controlled by legal\nentities not subject to consolidation (“Non-Consolidating”); and where there is no known\nperson(s) controlling the entity (“No Known Person” e.g., the entity is controlled by diverse\nshareholders).\n","contentLength":2248,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:31:48.032Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/2022-02-22_cdf_questions_and_answers_v2.4.pdf","content":"¢ Non-Public, whenever the relationship information is non-public and therefore creates obstacles\nto releasing this information. This category includes cases where there are obstacles in the laws\nor regulations of a jurisdiction restricting the reporting (“Binding Legal Constraint”); the existence\nof other legal constraints such as articles governing the legal entity or a contract (“Legal\nObstacles”); where disclosure of the information would be detrimental to the legal entity or the\nrelevant parent (“Disclosure Detrimental” and “Detriment Not Excluded”); and where the\nconsent to disclose the parent LEI was not obtained (“Consent Not Obtained”) An entity is not\nrequired to provide non-public relationship information in order to register or renew an LEI.\n¢ No LEl, when the parent does not consent to obtain an LEI or to authorize its “child entity” to\nobtain an LEI on its behalf.\nDetails of the Reporting Exceptions format can be found at www.gleif.org, although the reported\ndata in these formats is shared only with the LEI-ROC for evaluation purposes.\n3.8 What are the status fields used in a relationship record?\nThe relationship data provided in a relationship record contains two status fields:\nRelationshipStatus - The status of the relationship itself (active or\ninactive).\nRegistrationStatus - The status of the relationship reporting data record maintained by the LEI\nIssuer.\nFor a full list of RelationshipStatus and RegistrationStatus values, including descriptions,\nplease see the detailed specification of the Relationship Record Common Data File format, found at\nwww.gleif.org.\nCommon Data File Formats — Questions and Answers Page 34 of 35\n@ Public Version 2.4\n2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22\n","contentLength":1746,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:31:48.032Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/2022-02-22_cdf_questions_and_answers_v2.4.pdf","content":"4 Where can | find further information?\n4.1 GLEIF Files\nFor a description of the GLEIF Concatenated Files and instructions on how to obtain and use them,\nplease see the GLEIF Concatenated Files (and, separately, the Golden Copy Files) Specification and\nUser Manual documents, available from www.gleif.org.\n4.2 LEl Issuer files\nIf you have any questions regarding the original source files, please contact the respective LEI Issuer\nvia its website.\nContact details for all LEl Issuers can be found at www.gleif.org.\n4.3 Whom should I contact for further questions?\nPlease address any further questions or feedback on the LEI-CDF and RR-CDF formats to\ninfo@gleif.org.\nCommon Data File Formats — Questions and Answers Page 35 of 35\n@ Public Version 2.4\n2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22\n","contentLength":808,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:31:48.032Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/2022-02-22_cdf_questions_and_answers_v2.4.pdf","content":"1 General topics\n1.1 What are the GLEIF data formats?\nThe GLEIF data formats include\no LEI-CDF\no RR-CDF\no Reporting Exceptions\nThey are technical specifications supporting the 1ISO 17442 Legal Entity Identifier (LEI) standard.\nThe GLEIF standards are proposed and developed by the Legal Entity Identifier Regulatory Oversight\nCommittee (LEI-ROC), and further developed and maintained by GLEIF as the operational arm of the\nGlobal LEI System, always under LEI-ROC oversight.\n1.2 How are the GLEIF data formats applied?\nThe LEI-CDF, RR-CDF, Reporting Exceptions format, and code lists such as the RAL, specify data\nelements and values that can be checked (“validated”) automatically. GLEIF applies this validation to\nall the LEl and relationship data that LEI Issuers submit to GLEIF, so that a basic level of data quality is\nenforced across all the data.\nAlthough this validation is automated, GLEIF monitors the LEI Issuers’ data uploads and data quality\nreports on a daily basis. In addition, the data formats are flexible enough for LEI Issuers to include\nadditional value-added information in a reliable way, and changes or corrections to the data\nstructures can be proposed to GLEIF at any time.\nThe primary access point to the Global LEI Index, the full set of GLEIF Concatenated Files, is in XML\nformat and is also CDF schema compliant.\nPlease address any further questions or feedback on the LEI- and RR-CDF formats to\ninfo@gleif.org.\nPlease note that XML schema validation enforces a minimum data quality and\nstandards conformance. Data files in CDF XML format are not accepted if they\ndo not validate against the XML schema found in the CDF format specification,\nbut other business rules and data quality checks applied by GLEIF also\nencourages stricter conformance in live implementations.\nCommon Data File Formats — Questions and Answers Page 5 of 35\n@ Public Version 2.4\n2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22\n","contentLength":1941,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:31:48.032Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/2022-02-22_cdf_questions_and_answers_v2.4.pdf","content":"1.3 How are the GLEIF data formats updated?\nAny update requiring significant changes will be accompanied by an appropriate transition plan.\nAll updates are notified via the website, www.gleif.org.\n1.4 How can my organization store and manage CDF data locally?\nMany CDF data file users might wish to use the Golden Copy and Golden Copy\nDelta Files as the basis of their local LEl and relationships database, as they are\noptimized for this use case. Updates to specific LEI Records can be quickly\nobtained via the GLEIF API.\nThe GLEIF Concatenated Files are also maintained to provide a permanent audit trail of all original\ndata as received from LEI Issuers. A local database can also be populated from these files but this\nmay require extra effort to process the data.\nA secure, scheduled transfer can be set up using HTTPS, as described in the following documents\navailable at www.gleif.org:\n¢ GLEIF Golden Copy and Delta Files Specification and User Manual\no GLEIF Concatenated File Specification and User Manual\nAnother option is to download a complete or partial set of records in Excel, CSV or JSON format from\nthe LEI Search tool.\n1.5 What is a CDF-formatted data file?\nThe GLEIF CDF file downloads are not a database and so there is no documentation detailing tables,\nrelationships between tables or database validation rules.\nThe GLEIF CDF file downloads and the LEI CDF formats are also not intended as database design\nguidance, though they could be used to inform such a process\n1.6 What is a CDF-formatted data file?\nLEl and RR data files, such as those produced by the LEI Issuers, or the GLEIF Concatenated Files, are\ntext files containing LEI data and relationship records, structured using XML.\nThey cannot be directly opened with a spreadsheet or database application, e.g., Excel or Access,\nalthough data in these formats is available through GLEIF’s LEI Search tool, available at\nwww.gleif.org.\nCommon Data File Formats — Questions and Answers Page 6 of 35\n@ Public Version 2.4\n2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22\n","contentLength":2054,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:31:48.032Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/2022-02-22_cdf_questions_and_answers_v2.4.pdf","content":"The XML files can be viewed with any simple text editor, but for large numbers\nof LEI records this is impractical, and a specialized tool is needed. GLEIF does\nnot provide tool support; instead, we recommend consulting your IT team for\nany complex tasks.\n\nThe XML format defines a container that holds a file header and a series of data records.\n\n1.7 How does GLEIF process the CDF data it receives?\n\nGLEIF receives one daily data file per format, per LEI Issuer (also known as a Local Operating Unit or\n\nLOU), directly from the LEI Issuer.\n\nIf an invalid LEl Issuer file is found, i.e., one that does not meet technical validation criteria against\n\nthe relevant Common Data File (CDF) format, then the most recent valid data file from that LEI Issuer\n\nis substituted for it in that day's Concatenated File.\n\nHowever, information about the original LEI Issuer file will still be available, even if the file is not CDF\n\nvalid.\n\n1.8 How do the CDF formats handle international languages and\n\nscripts?\n\nAn LEI data record can contain:\n\ne Other names or representations of names for the legal entity.\n\no Alegal or headquarters address in different languages.\n\nThe OtherEntityName and OtherAddress fields, may have xml:lang language codes:\n\no FEach OtherEntityName elementincludes an optional language code, permitting\nOtherEntityName to be repeated as many times as necessary to express the same name\ntype in multiple languages.\n\n* When the type attribute’s value begins with\nPREFERRED ASCIT TRANSLITERATED LEGAL or\nAUTO ASCII TRANSLITERATED LEGAL, thelanguage codeinits xml:lang attribute\nspecifies the language of the name prior to transliteration.\n\nFor transliterated name and address elements, the value of the free text fields must consist only of\n\nnon-control characters drawn from the “invariant subset” of ISO 646 (ASCII).\n\nRelationship records can also contain some free-text fields which are handled in a similar way.\n\nCommon Data File Formats — Questions and Answers Page 7 of 35\n@ Public Version 2.4\n2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22\n","contentLength":2067,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:31:48.032Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/2022-02-22_cdf_questions_and_answers_v2.4.pdf","content":"1.9 Which special characters, string lengths and character encoding\ncan be expected when working with LEI-CDF formatted data?\nAny UTF-8 character can be found in an LEI data file.\nMost free-text fields are limited to a maximum of 500 characters.\nFor full technical details please refer to the LEI-CDF XML schema available at www.gleif.org.\nCommon Data File Formats — Questions and Answers Page 8 of 35\n@ Public Version 2.4\n2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22\n","contentLength":481,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:31:48.032Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/2022-02-22_cdf_questions_and_answers_v2.4.pdf","content":"2 LEI-CDF Topics\n2.1 What is an LEIl data file?\nLEI data files are compliant with the latest LEI-CDF format.\nThey normally contain a full set of LEI records; either\no All LEIs managed by one LEl Issuer, or\no All LEIs globally, as compiled by GLEIF from the LEI Issuer files.\nEach LEI data file contains a mandatory header with file information, and zero or more LEl records as\nfollows.\n2.2 What information is found in the LEI data file header?\nThe header contains the file upload information for an LEI data file. The GLEIF Concatenated File\nheader contains additional Extension fields supplying information on the LEI Issuers that\nsupplied the LEI data records the file contains.\n2.3 What are LEI data records?\nAn LEI data record contains all LEI reference data for one legal entity including the essential minimum\nreference data needed to tell one legal entity apart from another, supplemental information, and\ndetails of the LEI's registration with the LEI Issuer who manages the legal entity’s LEI registration.\nThrough the LEI code, they can be referred to relationships between legal entities, reported using the\nRR-CDF format.\n2.4 What is the structure of the LEI-CDF?\nPlease see the tables below for an overview of the LEI-CDF elements.\nSome “Type” column values refer to later tables; these refer to data elements that are contained\nwithin the referring element.\nFurther details can be found in the LEIl Common Data File Format specification PDF document and\ncorresponding XML Schema Definition (XSD) available at www.gleif.org.\nCommon Data File Formats — Questions and Answers Page 9 of 35\n@ Public Version 2.4\n2022-02-22_cdf_questions_and_answers_v2.4.docx 2022-02-22\n","contentLength":1680,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:31:48.032Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/2022-02-22_cdf_questions_and_answers_v2.4.pdf","content":"2.4.1 LEIHeaderType\n\nContentDate lei:LEIDateTimeProfile {1,1} The date and time as of which the data contained in the file is valid.\n\nOriginator lei:LEIType {0,1} The LEI of the entity that created the content of this file.\n\nFileContent lei:FileContentEnum {1,1} A code describing the content of this LEI data file.\n\nDeltaStart lei:LEIDateTimeProfile {0,1} The date and time of the baseline relative to which this file contains new or\nchanged LEI data records.\n\nRecordCount xs:nonNegativelnteger {1,1} The number of LEI data records in the file. Can be a positive whole (integer)\nnumber, or zero (0).\n\nNextVersion lei:HeaderNextVersionType {0,1} A structure for adding further elements into the LEI data file header in\nanticipation of a new version, by nesting a series of XML elements with this\ncontent model within the NextVersion element, one for each new minor version\nof the schema, postpending a serial number (1,2,3...) to the element name upon\neach iteration.\n\nExtension lei:ExtensionType {0,1} This lei:Extension element may contain any additional elements required to\nextend the LEIHeader.\n","contentLength":1100,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:31:48.034Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"@’ Protect dletto) st\n\nState Transition and\nValidation Rules for\nCommon Data File formats\n","contentLength":90,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.098Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Table of Contents\nY Yo 101 R 4 o TR 0 T YL U] 44 =T 4 Y\nAN | 1o o 1V T ' o TP | ||\n1.1 Terms and Definitions......ccccceeeviiiiiieie it csiieeee s sneee e s s sneeeeessnnnene 10\n1.2 Terminology and Typographical Conventions .........ccccecevveeeeivinineeeeinnnieeneeensiennn 12\n2 Lifecycle and General CoNCePtS.....cccerrueerenirrnecrenrrennceenceenncrnncesnecseneseneeee 14\n2.1 LEIRecord Set Reference Data ......ccccceeeeeiiiieeeeiiiiiicie s csssieeee s ssineeee s sssvvveeeesnnnenn 14\n2.1.1 Legal Entity data (Level 1 data — ‘“Who is WhO') ....cccovevvivicccieeeceecee e, 14\n2.1.2 Legal Entity relationship information (Level 2 data — “Who owns whom’)............ 14\n2.2 Corroboration of LEI Record Set .......ccccvivviiiiiiiiiiiiiieeee e ssieie e s ssiineeeeennn 21\n2.2.1 LEIREGISTIatioN ..ccceeiieeiiiiieie ettt e re e e e e e s s erneeneneeeaneanenes 21\n2.2.2 Validation c...uueeii et ee s srae e s snaees 22\n2.2.3 Application of GLEIF Registration Authorities List ........cccccccevevvieeccciesceeiiieeennn. 25\n2.3 LIf@ CYCIE coeeeee e s e sraae e e s s snnneaeeennn 27\n2.3.1 Registration Status COES .....ccuieiiiiiiiiei ittt ssrreee s seraees 28\n2.3.2 Changes in Registration Status due to Legal Entity Events .......c.cccveeviecviieeeriennen. 30\n2.3.3 Changes in Registration Status when a registration error is resolved.................... 31\n2.4 Registration Status Codes for Transient PUrpOSES......cccccevvvveeeeeriniinieensesiiinieeeennnn 31\n2.5 RENEWAI ciiiiciiiieiee e e s e ae e e snareeesenes 32\n2.6 1SO 3166 Conformance of Address and Jurisdiction Fields.............ccccceeeinnnennnnn. 32\n2.7 AdAress REPOITING ..uuviiiiiiiiiiiieee ettt eee s re e e sraae e ee s s sssaeeee s essaasaaaeesesens 33\n2.8 Entity Legal FOrm RePOItiNg ....cccvvcuuiiiiiiiiiiiieiieciiiiece s esssieeee s sveeeee s ssssvveeeeannnens 34\n2.9 Language, translation and transliteration ..........ccccceceeeiiivi s 35\n3 General State Transition and Validation Rules...........cccccccceeerrreennnnnnne.... 36\n3.1 Header Section (applicable to all files) .....cccceevveeeiieeiiiiieeceecee e 37\n3.2 CONTENT DAt e e e e e s DO\nR I O [ g 7= {1 o -1 (o] TP P TR PUPPPUPPPPPPRPPPOPOPRRRRRC 1o\nK I 1 L= @o | 1= | SO PSP PPPRUPPPPURPRPRPPNC 1 |\n3.5 Delta Start..cccccciiiee e sraeeee s sssnnneesesnsssnnnaeeen e 40\n3.6 ReCOrd COUNL .uviiiieiiiiiiiie sttt esie e e siieeee s s s snnneeessnsnnneesssssssnnnneeen s 40\n3.7 Extension (applicable to multiple Header Sections and data sections) ................41\n3.8 LEIRECOIT ettt s s sttte s sarre e e s ssvive e ae s s s sasbnaesesssnnnanesessnnnnnnenessnes B2\n3.9 LEI Code (context: LEI-CDF)......ccccieieiiiieeiiiiieciiieeessiieessevee e sieeeessvnessssnneessnnneee s 42\n3.10 Legal NAME c.iiiiiie ittt ee s ee s e s sra e e eesssvaneeessssasnnnnessssnnsneeeess B3\n3.11 Other ENntity NAmMES c.uuuiiiiiiiiiieiee ettt svrae e s sssvnneee s s s sainnae e s s snnneeee s 43\nG State Transition and Validation Rules for Common Data File formats Page 2 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":3087,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.100Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Common Data Files Format | The mandatory requirements for the structure and content of Legal\n\n(CDF) Entity Reference Data.\n\nELF code / ELF code list Abbreviation for the ISO 20275: Entity Legal Forms (ELF) code and\ncode list.\n\nExclusivity Violation Registration error where a Legal Entity has more than one LEI.\n\nGeneral Government Consists of institutional units that, in addition to fulfilling their\n\nSector political responsibilities and their role of economic regulation,\nproduce services (and possibly goods) for individual or collective\nconsumption mainly on a non-market basis and redistribute income\nand wealth.\n\nInstitutional Unit An institutional unit is an economic entity that is capable, in its own\nright, of owning assets, incurring liabilities and engaging in economic\nactivities and in transactions with other entities.\n\nInternational Organizations | Non-resident units created by international agreements or other\narrangements for the provision of non-market services or financial\nintermediation at the international level.\n\nLegal Entity Legal person or structure that is organized under the laws of any\njurisdiction (as defined in ISO 17442).\n\nLEl issuer, LOU An entity issuing and managing LEI Records; also referred to as\nManagingLOU, Managing LOU or just LOU (Local Operating Unit).\n\nLEI Record An XML data record in LEI-CDF format detailing one LEl record as\nreported by a Legal Entity to its LOU, and by the LOU to GLEIF.\n\nLEI Record Set An XML data record in CDF format describing one Legal Entity,\nincluding its related relationship information.\n\nRA code / RA list Abbreviation for the GLEIF Registration Authorities (RA) code and\nlist.\n\nReference Data The entity description and registration information recorded in the\nLEI Record Set.\n\nRelationship Record (RR) An XML data record in RR-CDF format detailing one relationship type\nbetween two Legal Entities, as reported by a Legal Entity to its LOU,\nand by the LOU to GLEIF.\n\nState Transition and Validation Rules for Common Data File formats Page 11 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2135,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.100Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"¢ The StartNode of a fund relationship SHALL be a fund entity, categorized by using the correct\nEntityCategory value FUND.\no If the RelationshipType is:\ne IS _SUBFUND_OF, then the EndNode of the relationship SHALL be a fund entity, categorized\nby using the correct EntityCategory value FUND (see\no Figure 8, relationship LEI A -> LEI D).\ne IS_FUND-MANAGED_BY, then the EndNode of the relationship SHALL be:\no afund entity, categorized by using the correct EntityCategory value FUND (see\no Figure 8, relationship LEI F -> LEI F).\ne aregular entity, categorized by using the correct EntityCategory value GENERAL (see\no Figure 8, relationship LEI A -> LEI G).\n* asole proprietor entity, categorized by using the correct EntityCategory value\nSOLE_PROPRIETOR.\ne IS _FEEDER_TO, then the EndNode of the relationship SHALL be a fund entity, categorized by\nusing the correct EntityCategory value FUND (see\no Figure 8, relationship LEI A -> LEI E).\n¢ For fund entities, if the requirement for financial consolidation requirement persists, direct and\nultimate parent entities SHALL be reported (see\no Figure 8, relationships LEI D -> LEI B and LEI C); In general for fund entities apply the same rules\nas described in chapter 2.1.2.\n¢ Fund entities MAY provide exact one Relationship Record of a type IS_SUBFUND_OF and\nIS_FEEDER_TO.\n¢ Reported ACTIVE fund relationships SHALL at least provide one RelationshipPeriod with\nPeriodeType RELATIONSHIP_PERIOD with a StartDate but no EndDate. Additional\nRelationshipPeriods MAY be included, if applicable (see 3.51).\n¢ Independent of what role in a relationship a fund entity plays (e.g., sub-fund, umbrella fund), the\nLegalName of the entity SHALL be its standalone LegalName and SHALL NOT include\nconcatenation of any related entities; in cases where an ‘Umbrella Structure’ relationship is\npresent, GLEIF will represent the names of the both the fund and the umbrella entities on LEI\nSearch as has been specified in the LEI-ROC policy.\n4.4 Issue New LEI - Fund in formation\nIn some jurisdictions or financial markets, fund entities require an LEl in order to register the fund or\nset up clearing accounts, before they become active from a legal perspective. In such cases, LEI\nState Transition and Validation Rules for Common Data File formats Page 101 of 170\nGLEIF Public Version 2.7.1 Final\n2022-04-01_State-Transition-Validation-Rules_v2.6_final.docx 2023-03-07\n","contentLength":2400,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.100Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"issuers SHALL follow these guidelines for setting up and maintaining the LEI Record for a not yet\n\nactive FUND:\n\ne The LEl issuer SHALL take due diligence to verify that the fund meets or will shortly meet the\nrequirements for entering the process requiring the LEI.\n\no The LEl issuer SHALL create and validate an LEI Record for the fund, as described above, including\nall relevant relationships and based on the available information and with the following special\nrules:\n\no EntityStatus SHALL be temporary set to NULL.\no EntityCreationDate SHALL NOT be populated.\no If afund relationship is introduced:\no RelationshipStatus SHALL be temporary set to NULL.\no RegistrationStatus of the relationship record SHALL be PUBLISHED.\ne StartDate of the RelationshipPeriod with PeriodType RELATIONSHIP_PERIOD SHALL NOT be\npopulated.\n\no During the setup of the fund, the LEl issuer SHALL work with the Legal Entity to keep the LEI\nRecord up to date with any Reference Data changes (e.g., a change in the name of the fund) and\nupdates the LEI Record Set accordingly. The LEl issuer SHALL be especially alert to the situation\nwhen the fund becomes a legally active entity, or the fund registration process is cancelled or\nwithdrawn.\n\n¢ If the fund becomes legally active, the LEl issuer SHALL update the LEI Record:\n\no EntityStatus SHALL be ACTIVE.\n\no EntityCreationDate SHALL be the date the legal status was achieved.\n\no If applicable, StartDate of the RelationshipPeriod with PeriodType RELATIONSHIP_PERIOD\nSHALL be the date the date the legal status was achieved.\n\no If the fund registration process is cancelled or withdrawn, the LEl issuer SHALL update the LEI\nRecord:\n\no RegistrationStatus of the LEI Record Set SHALL be ANNULLED.\n\no LElissuers SHALL monitor LEI Records for funds in formation closely and SHALL NOT keep them\nfor much longer in an uncertain state as it usually takes to register a fund in that jurisdiction.\n\nState Transition and Validation Rules for Common Data File formats Page 102 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2109,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.100Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o After the official registration of the fund entity is completed, the LEI Record Set SHALL be\nupdated accordingly.\n\n4.5 Issue New LEI - Sole proprietor\n\nWhen a new LEl is requested for a Sole Proprietor, in addition to or differing from section 4.1, the LEI\n\nissuer:\n\no SHALL ensure that the Legal Entity is registered in a Registration Authority\n\no SHALL validate and publish at least the following:\n\no RegistrationAuthorityID different from 'RA999999' and RegistrationAuthorityEntity|D SHALL\nbe included.\n\no EntityCategory SHALL be SOLE_PROPRIETOR.\n\no EntitySubCategory SHALL NOT be provided.\n\no LegalForm SHALL be a legal form applicable to Sole Proprietors in that jurisdiction.\n\no ValidationSources SHALL NOT be ENTITY_SUPPLIED_ONLY.\n\n4.6 Issue New LElI — Government entity\n\nWhen a new LEl is requested for a Government Entity as defined in chapters 3.22 and 3.23, in\naddition to or differing from section 4.1, the LEl issuer:\n\no SHALL validate and publish at least the following:\n\n+ EntityCategory SHALL be RESIDENT_GOVERNMENT_ENTITY.\n\no EntitySubCategory SHALL be CENTRAL GOVERNMENT, STATE GOVERNMENT, LOCAL\nGOVERNMENT or SOCIAL SECURITY, as applicable. If none of these sub-categories applies,\nEntitySubCategory SHALL NOT be provided.\n\n¢ If the Government Entity is registered in a registry or other authoritative source listed in the\nRA Code list in that country or jurisdiction, RegistrationAuthority SHALL be included\nrespectively and ValidationSources SHALL NOT be ENTITY_SUPPLIED_ONLY (unless the\nreserved code RA888888 is used to identify the authoritative source).\n\no If the Government Entity is not registered, but referred to in laws, regulations or decrees\nmade public by competent authorities, these public legal documents SHALL be used for\nvalidation and ValidationSources SHALL be either FULLY_CORROBORATED or\nPARTIALLY_CORROBORATED, depending on the extend of data elements validated against\nthat source. In this case RegistrationAuthoritylD RA999999 and ValidationAuthoritylD\nRA777777 SHALL be used and the document reference SHALL be added in the field\nOtherValidationAuthorityID.\n\nState Transition and Validation Rules for Common Data File formats Page 103 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2293,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.100Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o LegalAddress SHALL be the address recorded in the register or other authoritative source, if\nthe Government Entity is registered, or the official seat of the Government Entity as defined\nin their jurisdiction.\n\no HeadquartersAddress SHALL be the address of the Government Entity or the address of the\nauthorized entity managing the LEI registration on behalf of the Government Entity. The\naddress MAY be the same as LegalAddress. If another entity manages the registration,\nHeadquartersAddress SHALL include a ‘care-of’ part including the name of the entity\nmanaging the LEl registration.\n\no If the Government Entity has a dedicated legal form in the local jurisdiction according to the\nELF Code list, EntityLegalForm SHALL be included. If not, the appropriate reserved code (8888\nor 9999) SHALL be used together with a fitting descriptive term in the OtherLegalEntityForm\nfield.\n\n* If the Government Entity is declaring a direct and/or ultimate parent, the accounting\nstandard SHALL be GOVERNMENT_ACCOUNTING_STANDARD and the parent entity SHALL be\ncategorized as RESIDENT_GOVERNMENT_ENTITY as well. If no direct and/or ultimate parent\nis declared, a Reporting Exception with ExceptionReason NO_KNOWN_PERSON SHALL be\nincluded.\n\no If the Government Entity has a direct and/or ultimate parent that does not have an LEl, a\nReporting Exception with ExceptionReason NO_LEI SHALL be included.\n\nIf an LEI has been issued to a Government Entity prior to the implementation of LEI-CDF 3.1, the LEI\nissuer SHALL adapt the record in accordance with above rules during the next renewal at the latest.\nNote: Legal entities related to the European Union or related bodies SHALL NOT be categorized as\nGENERAL or RESIDENT_GOVERNMENT_ENTITY but rather as INTERNATIONAL_ORGANIZATION.\n4.7 Issue New LEI — International organization\n\nWhen a new LEl is requested for an International Organization as defined in chapter 3.22, which is\nnot organized in the specific legal form of a jurisdiction, in addition to or differing from section 4.1,\nthe LEl issuer:\n\no SHALL validate and publish at least the following:\n\no EntityCategory SHALL be INTERNATIONAL ORGANIZATION.\n\no EntitySubCategory SHALL NOT be provided.\n\n¢ HeadquartersAddress SHALL be the main base of operations or, in case most employees work\nin distributed field operations, the location of a secretariat or similar administrative central\nfunction.\n\n¢ The concept of LegalAddress as defined in the GLEIS does not apply to International\nOrganizations. LegalAddress SHALL be the same as HeadquartersAddress.\n\nState Transition and Validation Rules for Common Data File formats Page 104 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2731,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.100Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o If the RA Code list includes an authoritative source for International Organizations that can\nbe used to validate the data, that RA Code SHALL be included as RegistrationAuthority and\nValidationAuthority. In case the entity is not registered in any public registry, RA999999\nSHALL be used for RegistrationAuthoritylD. If there are also no Public Legal Documents\navailable that can be used to validate the data, RA999999 SHALL also be used as\nValidationAuthoritylD.\n\no ValidationAuthoritylD SHALL be RA777777 in case there is no information available in any\nregular registration authority and Public Legal Documents are used instead.\n\no AsInternational Organizations are established by treaties or other specific multinational\nagreements governed by international law, the concept of legal jurisdiction does not apply as\nfor other entities established under a national law. Legallurisdiction SHALL be the one of the\nfollowing:\n\no UN, if the entity is the United Nations, one of their specialized agencies or other\naffiliated organizations.\n\no EU, if the entity is established by a treaty signed by all members of the European Union\nand no other countries.\n\no XX, in all other cases.\n\no LegalForm SHALL be 9999, the reserved code for jurisdictions not on the ELF code list.\nOtherlLegalForm SHALL include the name of the treaty establishing the entity. If a series of\ntreaties or updates of treaties were signed to form or change the International Organization,\nonly the latest one establishing it in its current form SHALL be included.\n\no If the International Organization is declaring a direct and/or ultimate parent the parent entity\nSHALL be categorized as INTERNATIONAL_ORGANIZATION as well. If no direct and/or\nultimate parent is declared, a Reporting Exception with ExceptionReason\nNO_KNOWN_PERSON SHALL be included.\n\nIf an LEI has been issued to an International Organization prior to the implementation of LEI-CDF 3.1,\nthe LEl issuer SHALL adapt the record in accordance with above rules during the next renewal at the\nlatest.\n4.8 LEI Record Renewal\nIf a Legal Entity renews its LEI Record (see 2.5 Renewal above), the LEl issuer:\no SHALL validate that the Legal Entity is operational.\no SHALL validate the LEI Reference Data including all updates provided by the Legal Entity.\nState Transition and Validation Rules for Common Data File formats Page 105 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2470,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.100Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o SHALL validate that all reported ACTIVE relationships are still current and update the dates in\nperiods with PeriodType ACCOUNTING_PERIOD and DOCUMENT _FILING_PERIOD accordingly, if\npresent; if one or more relationships are no longer current, the Use Case 4.13.22 applies.\n\ne For a Fund entity, SHALL validate that all reported ACTIVE fund relationships (RelationshipType\nIS_ FUND-MANAGED_BY, IS SUBFUND_OF and IS_FEEDER_TO) are still current and update the\ndates in periods with PeriodType ACCOUNTING_PERIOD and DOCUMENT_FILING_PERIOD\naccordingly, if present; if one or more relationships are no longer current, the Use Case 4.13.22\napplies.\n\no SHALL check, if a parent without LEI (Exception reason NO_LEl) can be replaced by an LEI\nrelationship (see Use Case 4.9).\n\no SHALL check with the Legal Entity, if a reported exception due to legal obstacles still applies and\nreplace with a new Relationship Record if it is no longer valid.\n\ne SHALL set a new NextRenewalDate not more than 12 months after the current NextRenewalDate\nor the date of last Validation of the record, whichever is later; this applies to the Entity Data as\nwell as all ACTIVE Relationship Records.\n\ne For a Branch entity, SHALL ensure that the LEI Record of the (head office) Legal Entity has\nRegistrationStatus ISSUED; the Branch LElI Record SHALL NOT be renewed, if the\nRegistrationStatus of its head office LAPSED.\n\n4.9 LEI Record update — Parent Legal Entity without an LEIl requests\n\nan LEI\n\nThis Use Case applies where a parent without an LEI requests an LEI. As soon as the child Legal Entity\n\nis aware of this information, it needs to inform its LEIl issuer. The LEl issuer of the child entity:\n\no SHALL create the applicable Relationship Records(s) according to Use Cases 4.1.1.\n\no SHALL remove the NO_LEI Reporting exception record(s) from publication.\n\n4.10 LEI Record update — Relationship Record changes to Reporting\n\nException\n\nThis Use Case applies where the child Legal Entity reports a Reporting Exception after initially\n\ndeclaring a relationship. The LEl issuer:\n\ne SHALL annul the Relationship Record in case it was entered erroneously in the system.\n\no SHALL retire the Relationship Record in case the relationship for instance expired.\n\nState Transition and Validation Rules for Common Data File formats Page 106 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2418,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.100Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o In either case, the LOU SHALL continue publishing the ANNULLED/RETIRED Relationship\nRecord(s).\n\no SHALL create a new Reporting Exception and publish it.\n\n4.11 Lack of renewal — Legal Entity\n\nIf a Legal Entity does not renew its LElI Record (see Use Case 4.8), with reaching the\n\nNextRenewalDate, the LEl issuer:\n\no SHALL check with the registration and/or Validation Authority for the given Legal Entity (if\navailable), whether the entity is still active. If the Legal Entity stopped operations, then the rules\nfor retiring an LEIl apply here, or if applicable, the details of a corresponding Legal Entity Event.\n\nThe fact that an International Branch’s LEI Record is LAPSED SHALL NOT allow for the issuance of a\n\nsecond LEI Record for a Branch in the same host jurisdiction.\n\n4.12 Lack of renewal — Related Legal Entity including head offices,\n\nfund managers, umbrella and master funds\n\nIf the LEl Record of a related Legal Entity (the EndNode of an active relationship) is not renewed, all\n\nactive accounting consolidating, Fund Management Entities, Umbrella Structures and Master-Feeder\n\nRelationship Records having this entity’s LEl as EndNodelD SHALL NOT be updated, if the lack of\n\nrenewal of the parent Legal Entity is the only change.\n\nIf the parent Legal Entity is the head office of a Branch entity, the LEl issuer of the Branch SHALL set\n\nthe Branch’s LEI Record, including the Relationship Records, to LAPSED (see section 4.6). This SHALL\n\nbe ensured by the Branch LEI Record having the same NextRenewalDate as the head office LElI\n\nRecord, whether or not both records are managed by the same or by different LEIl issuers and\n\nregardless of any renewal request submitted by the Branch entity but not by the head office.\n\n4.13 Update of LEI Reference Data due to Legal Entity Events\n\nThe Reference Data of an LEI Record may change due to Legal Entity Events. The LEl issuer is\n\nresponsible to verify changed Reference Data. If the LEl issuer is ultimately unable to verify the\n\nchanged Reference Data, the Validation Sources SHALL change to PARTIALLY CORROBORATED or\n\nENTITY_SUPPLIED_ONLY.\n\nWhenever an element of the Reference Data is updated, the respective LastUpdateDate (LEI Record\n\nor Relationship Records) SHALL be updated with the current date and time as well.\n\nIf LEI Reference Data is updated to just correct an error or add missing data to an element associated\n\nwith Legal Entity Events (e.g., LegalName, LegalAddress, EntityLegalForm), but the Legal Entity itself\n\ndid not change, no Legal Entity Event SHALL be recorded together with the reference data update.\n\nState Transition and Validation Rules for Common Data File formats Page 107 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2774,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.100Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Legal Entity Events can occur as\n\n¢ Single Standalone events (e.g., an address change)\n\n¢ Sequence of Standalone events (e.g., a change in legal name after a merger or demerger)\n\n¢ Standalone Events that occur simultaneously (e.g., a change in legal name in the course of an\nabsorption)\n\ne Grouped events that happen at the same time (e.g., a change in legal form that also changes the\nlegal name)\n\ne Grouped events in a logical succession (e.g., reverse take-over).\n\n4.13.1 Legal Entity Event — Event timeline and status\n\nSome events MAY be able to be confirmed officially before the event becomes legally effective. For\n\nother events, becoming legally effective will be the only binding confirmation for the event. There\n\nMAY be cases where a Legal Entity Event has been confirmed officially but later will be withdrawn or\n\ncancelled before becoming legally effective.\n\nTo capture different timelines and statuses, each Legal Entity Event has an attribute defining the\n\nstatus of the event (see section 3.29):\n\no @event_status SHALL be IN_PROGRESS, if the Legal Entity Event is confirmed by an official\nsource (which could be the Legal Entity itself) but has not become legally effective yet. Not all\nevents MAY be able to be confirmed and recorded in the Global LEI System before the\nLegalEntityEventEffectiveDate.\n\no LegalEntityEventEffectiveDate SHALL be a future date (if the effective date is known) or\nSHALL be omitted (if the date is unknown).\n\no All provided AffectedFields SHALL include the values of the LEI Reference Data as expected to\nchange as a result of a completed Legal Entity Event.\n\n¢ The values provided in the attribute @field_xpath of the AffectedFields element SHALL be as\nlisted in section 3.36.\n\no @event_status SHALL be COMPLETED, if the Legal Entity Event is confirmed and legally effective.\no LegalEntityEventEffectiveDate SHALL be present and earlier or equal to\n\nLegalEntityEventRecordedDate.\n\n@event_status SHALL be WITHDRAWN_CANCELLED, if an event has been reported with\n\n@event_status IN_PROGRESS but has been determined to not be completed due to withdrawal or\n\ncancellation. This status SHALL be used only when it is confirmed that the event will not happen —a\n\ndelay past an expected effective date SHALL NOT result in a cancellation. Figure 9 gives further\n\ndetails on the application of event timelines.\nState Transition and Validation Rules for Common Data File formats Page 108 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2529,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.100Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"@event_status WITHDRAWN_CANCELLED SHALL also be used to cancel events that have been\npublished in the LEI Record by mistake. In this case the event with @event_status\nWITHDRAWN_CANCELLED SHALL have the exact same reference data as the erroneously introduced\nevent with @event_status COMPLETED with the exception of the LegalEntityEventRecordedDate.\nLegalEntityEvent:\no @entity_status:\nWITHDRAWN_CANCELLED\no LegalEntityEventRecordedDate:\ne 2020-06-01T00:00:00+02:00\n@event_status: IN_PROGRESS\n@event_status: WITHDRAWN_CANCELLED\nLegalEntityEvent:\no @entity_status: IN_PROGRESS\nLegalEntityEventEffectiveDate:\n: & y @event_status: COMPLETED\no 2020-11-20T00:00:00+02:00\no LegalEntityEventRecordedDate: LegalEntityEvent:\no 2020-04-20T00:00:00+02:00\no @entity_status: COMPLETED\n¢ LegalEntityEventEffectiveDate: 2020-11-\nAffectedFields: 20T00:00:00+02:00\no Expected attribute values that will o LegalEntityEventRecordedDate: 2020-\nbe effective on November 20, 2020. 12-05T00:00:00+02:00\nFigure 9: Application of event timeline and event status\n4.13.2 Legal Entity Event — Legal Name changes\nThis Use Case only applies where the legal name changes and the Legal Entity remains an operating\nentity. This event applies to all entity categories. For cases where the LegalName changed due to a\nchange of LegalForm, see Use Case 4.13.5.\nThe LEl issuer:\ne SHALL update LegalName accordingly, as recorded by an official Registration Authority.\no SHALL create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be omitted.\nState Transition and Validation Rules for Common Data File formats Page 109 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1797,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.100Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be CHANGE_LEGAL NAME.\no LegalEntityEventEffectiveDate SHALL be the date the change in LegalName becomes effective\nin the Legal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no If @event_statusis IN_PROGRESS, the LEl issuer SHALL provide information regarding the\nAffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide lei:LegalName\ne SHALL provide lei:OtherEntityNames\no MAY provide lei:TransliteratedOtherEntityNames\no MAY provide lei:SuccessorEntity\ne SHALL include a new OtherEntityName with OtherEntityNameType PREVIOUS_LEGAL_NAME.\no SHALL update OtherEntityName with OtherEntityNameType\nALTERNATIVE_LANGUAGE_LEGAL_NAME, if necessary.\no SHALL update TransliteratedOtherEntityNames, if necessary.\nIf the change of the Legal Entity name is due to the formation of a new Legal Entity, then a new LEI\nSHALL be issued for the new Legal Entity (see sections 4.1 and 4.3) and the SuccessorEntity /\nSuccessorlLEl field of the old LEI Record SHALL be updated with the new LEI (see sections 4.13.22).\nState Transition and Validation Rules for Common Data File formats Page 110 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1355,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.100Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Reporting Exception An XML data record in REPEX-CDF format detailing the reported\nRecord (Repex) exception for not reporting a relationship type in a relationship\nrecord, as reported by a Legal Entity to its LOU, and by the LOU to\nGLEIF.\nSystem of National The System of National Accounts (SNA) is the internationally agreed\nAccounts (SNA) standard set of recommendations on how to compile measures of\neconomic activity. The SNA defines resident Government Entities as\nnon-market producers, part of the central, state or local\ngovernment, social security funds or non-profit institutions (NPI)\ncontrolled by government units.\n(https://unstats.un.org/unsd/nationalaccount/sna.asp)\nSubsidiary A Legal Entity controlled by a holding company.\nTransition Rule A rule stipulating what LOUs, GLEIF and Legal Entities must do when\nan LEI Record Set changes from one allowed state to another.\nUse Case A specific operation scenario which applies one or more Business\nRules.\nValidation Ensures complete, reasonable, sensible data within acceptable\nboundaries by checking the data that is being entered.\nVerification Entered data matches exactly the Validation source.\n1.2 Terminology and Typographical Conventions\nWithin this document, the terms, as will be SHALL and MAY, are to be interpreted as specified in\nAnnex G of the ISO/IEC Directives, Part 2, 2001, 4th edition:\nSHALL (NOT) Requirement\nMAY Permission / Possibility\nWhen used in this way, these terms will always be shown in ALL CAPS; when these words appear in\nordinary typeface, they are intended to have their ordinary English meaning. All sections of this\nState Transition and Validation Rules for Common Data File formats Page 12 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1793,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.100Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"O LegalName changes O\n—>\nLEI A LEI A\nPre Event Post Event\nLEI A LEIA\nEntity: Entity:\no LegalName: ,Former LegalName“ o LegalName: ,New LegalName“\no OtherEntityName: “Former LegalName”\nRegistration: o OtherEntityNameType:\no lei:RegistrationStatus: ISSUED PREVIOUS_LEGAL_NAME\no LastUpdateDate: 2019-07-01T11:13:00+01:00\nRegistration:\no RegistrationStatus: ISSUED\no LastUpdateDate:\no 2020-04-16T17:43:00+02:00\nLegalEntityEvent:\no @group_type: STANDALONE\no @event_status: COMPLETED\no LegalEntityEventType: CHANGE_LEGAL_NAME\no LegalEntityEventEffectiveDate:\ne 2020-04-13T00:00:00.000Z\no LegalEntityEventRecordedDate:\ne 2020-04-16T00:00:00.000Z\no ValidationDocuments:\nSUPPORTING_DOCUMENTS\no ValidationReference:\nhttp://pub_registry.gov/new_entity_docs.pdf\nExample 1: The Legal Entity “Former LegalName” with an LEI A changed its name to “New LegalName” with effective\ndate April 13, 2020. The LEl issuer updated the record and published it in the Global LEI System on April 16, 2020. The\nchange of the name can be validated in the business registry where the Legal Entity is registered.\nState Transition and Validation Rules for Common Data File formats Page 111 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1269,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.100Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.13.3 Legal Entity Event — Business or trading name changes\nThis Use Case only applies where a business or trading name changes, the LegalName does not\nchange and the Legal Entity remains an operating entity. This event applies to all entity categories\nexcept for Government entities.\nThe LEl issuer:\no SHALL update OtherEntityName with OtherEntityNameType TRADING_OR_OPERATING_NAME\naccordingly.\no SHALL create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be CHANGE_OTHER_NAMES.\no LegalEntityEventEffectiveDate SHALL be the date the change in OtherEntityName becomes\neffective in the Legal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no If @event_statusis IN_PROGRESS, the LEl issuer SHALL provide information regarding the\nAffectedFields: For @field_xpath the LEl issuer usually\ne SHALL provide lei:OtherEntityNames\no MAY provide lei:TransliteratedOtherEntityNames\no MAY provide lei:SuccessorEntity\nIf the change of the Legal Entity’s business or trading name is due to the formation of a new Legal\nEntity, then a new LEI SHALL be issued for the new Legal Entity (see Use Cases 4.1 and 4.3) and the\nSuccessorEntity / SuccessorLEl field of the old LEI Record SHALL be updated with the new LEI (see\nUse Case 4.13.22).\nState Transition and Validation Rules for Common Data File formats Page 112 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1685,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.100Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"O Business or trading name changes O\nN — S\nLEI A LEI A\nPre Event Post Event\nLEI A LEI A\nEntity: Entity:\no LegalName: “Good company name” o LegalName: “Good company name”\no OtherEntityName: “GoodCo”\nRegistration: o OtherEntityNameType:\no lei:RegistrationStatus: LAPSED TRADING_OR_OPERATING_NAME\no LastUpdateDate: 2019-07-01T11:13:00+01:00\no NextRenewalDate: 2020-01- Registration:\n01T00:00:00+01:00 o lei:RegistrationStatus: ISSUED\no LastUpdateDate: 2020-01-23T10:42:00+02:00\no NextRenewalDate: 2021-01-\n01T00:00:00+01:00\nLegalEntityEvent:\no @group_type: STANDALONE\no @event_status: COMPLETED\no LegalEntityEventType:\nCHANGE_OTHER_NAMES\no LegalEntityEventEffectiveDate:\ne 2020-01-15T00:00:00.000Z\no LegalEntityEventRecordedDate:\ne 2020-01-23T00:00:00.000Z\no ValidationDocuments: CONTRACTS\no ValidationReference: Notarized documents\nExample 2: The Legal Entity ,,Good company name“ uses “GoodCo” as a new trading name as of January 15, 2020. The\nLegal Entity Event was recorded in the Global LEI System on January 23, 2020 in the course of renewal, after initially the\nLEI lapsed.\nState Transition and Validation Rules for Common Data File formats Page 113 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1266,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.100Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.13.4 Legal Entity Event — Address information changes\nThis Use Case only applies where the LegalAddress or HeadquartersAddress changes and the Legal\nEntity remains an operating entity. This event applies to all entity categories.\nThe LEl issuer:\no SHALL update LegalAddress and/or HeadquartersAddress accordingly.\no SHALL create a new LegalEntityEvent for each address changed with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be CHANGE_LEGAL_ADDRESS or CHANGE_HQ_ADDRESS,\nrespectively.\no LegalEntityEventEffectiveDate SHALL be the date the change in address becomes effective in\nthe Legal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no If @event_statusis IN_PROGRESS, the LEl issuer SHALL provide information regarding the\nAffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide lei:LegalAddress/* and/or lei:HeadquartersAddress/*\no MAY provide lei:OtherAddresses/*\n* MAY provide lei:TransliteratedOtherAddresses/*\no MAY provide lei:SuccessorEntity\ne Forall above mentioned address containers (LegalAddress, HeadquartersAddress,\nOtherAddresses and TransliteratedOtherAddresses) the concrete data elements SHALL be\nprovided.\no SHALL update OtherAddresses with type ALTERNATIVE_LANGUAGE_LEGAL_ADDRESS and/or\nALTERNATIVE_LANGUAGE_HEADQUARTERS_ADDRESS, if necessary.\no SHALL update TransliteratedOtherAddresses, if necessary.\no SHALL check, if also the Registration Information changed (see Use Case 4.15).\nIf the change of the legal address is due to the formation of a new Legal Entity, then a new LEI SHALL\nbe issued (see Use Cases 4.1 and 4.3) and the SuccessorEntity / SuccessorLEl field of the old LEI\nrecord SHALL be updated with the new LEI (see Use Case 4.13.22). Example 3 provides a specific use\ncase for changing address information.\nState Transition and Validation Rules for Common Data File formats Page 114 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2199,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.100Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"O Address information changes O\n———>\nLEI A LEI A\nIn-progress Event Post Event\nLEI A LEI A\nEntity: Entity:\no FirstAddressLine: “Streetname former legal o FirstAddressLine: “Streetname new legal\naddress 1” address 5”\no AddressNumber: 1 o AddressNumber: 5\nRegistration: Registration:\no RegistrationStatus: ISSUED o RegistrationStatus: ISSUED\no LastUpdateDate: 2019-07-01T11:13:00+01:00 o LastUpdateDate: 2020-01-23T710:42:00+02:00\nLegalEntityEvent: LegalEntityEvent:\no @group_type: STANDALONE o @group_type: STANDALONE\no @event_status: IN_PROGRESS o @event_status: IN_PROGRESS\no LegalEntityEventType: o LegalEntityEventType:\nCHANGE_LEGAL_ADDRESS CHANGE_LEGAL_ADDRESS\no LegalEntityEventEffectiveDate: o LegalEntityEventEffectiveDate:\ne 2020-01-15T00:00:00.000Z e 2020-01-15T00:00:00.000Z\no LegalEntityEventRecordedDate: o LegalEntityEventRecordedDate:\ne 2019-07-07T00:00:00+01:00 e 2019-07-07T00:00:00+01:00\no ValidationDocuments: ¢ ValidationDocuments:\nSUPPORTING_DOCUMENTS SUPPORTING_DOCUMENTS\no ValidationReference: o ValidationReference:\nhttp://pub_registry.gov/new_entity_docs.pdf http://pub_registry.gov/new_entity_docs.pdf\nAffectedFields: LegalEntityEvent:\no Entity/LegalAddress/FirstAddressLine: o @group_type: STANDALONE\no @event_status: COMPLETED\no LegalEntityEventType:\nCHANGE_LEGAL_ADDRESS\no LegalEntityEventEffectiveDate:\nExample 3: The Legal Entity makes available the information about a change in the legal address that will become\neffective on January 15, 2020. In the example only the street and address number change. The change of the legal\naddress was recorded in the Global LEI System on July 7, 2019 as in-progress event. The completion of the Legal Entity\nEvent was validated in the local registry and recorded in the Global LEI System on January 23, 2020.\nState Transition and Validation Rules for Common Data File formats Page 115 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1973,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.100Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.13.5 Legal Entity Event — Legal form changes\nA change of the legal form potentially has different degrees of impact on the Legal Entity. The\nfollowing three Use Cases describe the most common variants. They apply to all entity categories.\nFor cases where an ELF code is supplied for the first time, see section 2.8 instead.\nThe first Use Case (Example 4) applies when only the legal form changes and the Legal Entity remains\nan operating entity. An example could be that the legal forms used in the Legal Entity’s jurisdiction\nare transformed into other legal forms while preserving the legal status of the Legal Entities.\nIn this case, the LEl issuer:\ne SHALL update LegalForm accordingly, following the general rules for Entity Legal Form Reporting\n(see section 2.8).\no SHALL create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be CHANGE_LEGAL_FORM.\no LegalEntityEventEffectiveDate SHALL be the date the change in the legal form becomes\neffective in the Legal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no If @event_statusis IN_PROGRESS, the LEl issuer SHALL provide information regarding the\nAffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide lei:EntityLegalFormCode and lei:OtherLegalForm, if necessary\no MAY provide lei:Legallurisdiction\no MAY provide lei:SuccessorEntity\no SHALL check, if also Registration Information has changed (see Use Case 4.15).\nState Transition and Validation Rules for Common Data File formats Page 116 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1848,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.100Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"O LegalForm changes O\n———’\nLEI A LEI A\nIn-progress Event Post Event\nLEI A LEI A\n\nEntity: Entity:\n\no EntityLegalFormCode: 059 o EntitylegalFormCode: Y1Q4\n\nRegistration: Registration\n\no RegistrationStatus: ISSUED o RegistrationStatus: ISSUED\n\no LlastUpdateDate: 2019-07-01711:13:00+01:00 o LastUpdateDate: 2020-01-23T710:42:00+02:00\n\nLegalEntityEvent: LegalEntityEvent:\n\no @group_type: STANDALONE o @group_type: STANDALONE\n\no @event_status: IN_PROGRESS o @event_status: IN_PROGRESS\n\no LegalEntityEventType: o LegalEntityEventType:\n\nCHANGE_LEGAL_FORM CHANGE_LEGAL_FORM\n\no LegalEntityEventEffectiveDate: o LegalEntityEventEffectiveDate:\n\ne 2020-01-15T00:00:00.000Z e 2020-01-15T00:00:00.000Z\n\no LegalEntityEventRecordedDate: o LegalEntityEventRecordedDate:\n\ne 2019-07-01T00:00:00+01:00 e 2019-07-01T00:00:00+01:00\n\no ValidationDocuments: ¢ ValidationDocuments:\nSUPPORTING_DOCUMENTS SUPPORTING_DOCUMENTS\n\no ValidationReference: o ValidationReference:\nhttp://registry.gov/evidence.pdf http://registry.gov/evidence.pdf\n\nAffectedFields: AffectedFields:\n\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:E o /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:E\nntity/lei:LegalForm/lei:EntityLegalFormCode: ntity/lei:LegalForm/lei:EntityLegalFormCode:\nY1Q4 Y1Q4\n\nLegalEntityEvent:\no @group_type: STANDALONE\no @event_status: COMPLETED\no LegalEntityEventType:\nCHANGE_LEGAL_FORM\no LegalEntityEventEffectiveDate:\ne 2020-01-15T00:00:00.000Z\no LegalEntityEventRecordedDate:\ne 2020-01-23T00:00:00.000Z\n¢ ValidationDocuments:\nSUPPORTING_DOCUMENTS\no ValidationReference:\nhttp://registry.gov/evidence.pdf\nExample 4: The Legal Entity changes its legal form from ELF O59C to ELF Y1Q4 with effective date January 15, 2020. The\nLEl issuer has published this change on July 1, 2019 prior to the effective date. The completion of the Legal Entity Event\nwas recorded in the Global LEI System on January 23, 2020.\nState Transition and Validation Rules for Common Data File formats Page 117 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2074,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.100Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"The second Use Case (Example 5) applies when also the legal name changes due to the legal form\nchange and the Legal Entity remains an operating entity.\nIn this case, the LEl issuer:\no SHALL update LegalForm accordingly, following the general rules for Entity Legal Form Reporting\n(see section 2.8).\no SHALL create a new LegalEntityEvent for the legal form change with:\no @group_type SHALL be CHANGE_LEGAL_FORM_AND_NAME.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be a unique identifier (e.g., a hash value calculated from the combination\nof the LEl, EventType and EffectiveDate).\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be CHANGE_LEGAL_FORM.\no LegalEntityEventEffectiveDate SHALL be the date the change in the legal form becomes\neffective in the Legal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no If @event_status is IN_PROGRESS, the LEl issuer SHALL provide information regarding the\nAffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide lei:EntityLegalFormCode and lei:OtherLegalForm, if necessary\no MAY provide lei:Legallurisdiction\no MAY provide lei:SuccessorEntity\no SHALL create a new LegalEntityEvent for the legal name change with (see Use Case 4.13.2):\no @group_type SHALL be CHANGE_LEGAL FORM_AND_NAME.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be the same unique identifier used for the previous event.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be CHANGE_LEGAL NAME.\no LegalEntityEventEffectiveDate SHALL be the date the change in the legal form becomes\neffective in the Legal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\nState Transition and Validation Rules for Common Data File formats Page 118 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2070,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.100Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o If @event_statusis IN_PROGRESS, the LEl issuer SHALL provide information regarding the\n\nAffectedFields: For @field_xpath the LEl issuer usually\n\no SHALL provide lei:LegalName\n\ne SHALL provide lei:OtherEntityNames\n\no MAY provide lei:TransliteratedOtherEntityNames\n\no MAY provide lei:SuccessorEntity\n\no SHALL check, if also Registration Information has changed (see section 4.15).\nState Transition and Validation Rules for Common Data File formats Page 119 of 170\n@ Public Version 2.7.1 Final\n\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":566,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.100Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"LegalForm and LegalName change\n-\nPre Event Post Event\nLEI A LEI A\nEntity: Entity:\no EntityLegalFormCode: FGVH o EntityLegalFormCode: O85W\no LegalName: “Company Name Inc” o LegalName: “Company Name LLC”\nRegistration: Registration:\no lei:RegistrationStatus: ISSUED o lei:RegistrationStatus: ISSUED\no lastUpdateDate: 2019-07-01711:13:00+01:00 o LastUpdateDate: 2020-01-23T10:42:00+02:00\nLegalEntityEvent:\no @group_type:\nCHANGE_LEGAL_FORM_AND_NAME\no @group_id: dfecd444f23463443a98n12a\no @event_status: COMPLETED\no LegalEntityEventType:\nCHANGE_LEGAL_FORM\no LegalEntityEventEffectiveDate:\ne 2020-01-15T00:00:00.000Z\no LegalEntityEventRecordedDate:\ne 2020-01-23T00:00:00.000Z\no ValidationDocuments:\nSUPPORTING_DOCUMENTS\ne ValidationReference:\nhttp://pub_registry.gov/new_entity_docs.pdf\nLegalEntityEvent:\no @group_type:\nCHANGE_LEGAL_FORM_AND_NAME\no @group_id: dfecd444f23463443a98n12a\no @event_status: COMPLETED\no LegalEntityEventType:\nCHANGE_LEGAL_NAME\no ValidationDocuments:\nSUPPORTING_DOCUMENTS\no LegalEntityEventEffectiveDate:\ne 2020-01-15T00:00:00.000Z\no LegalEntityEventRecordedDate:\ne 2020-01-23T00:00:00.000Z\no ValidationDocuments:\nSUPPORTING_DOCUMENTS\ne ValidationReference:\nhttp://pub_registry.gov/new_entity_docs.pdf\nExample 5: The Legal Entity changes its legal form from ELF FGVH to ELF O85W with effective date January 15, 2020 and\nadditionally changes its legal name. The completion of the Legal Entity Event was recorded in the Global LEI System on\nJanuary 23, 2020.\nState Transition and Validation Rules for Common Data File formats Page 120 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1667,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.100Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"document, with the exception of the Introduction, are normative, except where explicitly noted as\nnon-normative. The following typographical conventions are used throughout the document:\no ALL CAPS type is used for the special terms enumerated above and when in the text is referred to\na data field value from an enumerated list.\no CamelCase type is used to refer to the data elements as declared in the CDF XML Schema\nDefinition (xsd).\nState Transition and Validation Rules for Common Data File formats Page 13 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":620,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.100Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"The third Use Case (Example 6) applies when the legal form change creates a new Legal Entity while\nthe previous Legal Entity ceases to exist.\n\nIn this case, the LEl issuer:\n\no SHALL retire the LEI Record Set of the previous Legal Entity:\n\no Set RegistrationStatus to RETIRED.\n\no Set RegistrationStatus of all current Relationship Records to RETIRED with RelationshipStatus\nINACTIVE; set EndDate of RelationshipPeriod with PeriodType RELATIONSHIP_PERIOD as\nLegalEntityEventEffectiveDate of the event (see below).\n\no Setthe new Legal Entity (see below) as SuccessorEntity.\n\ne Create a new LegalEntityEvent for the LEI Record Set of the previous Legal Entity with:\n\no @group_type SHALL be COMPLEX_CHANGE_LEGAL_FORM.\n\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\n\no @group_id SHALL be omitted.\n\no @group_sequence_no SHALL be omitted.\n\no LegalEntityEventType SHALL be CHANGE_LEGAL_FORM.\n\no LegalEntityEventEffectiveDate SHALL be date the change in the legal form becomes effective\nin the Legal Jurisdiction of the Legal Entity.\n\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\n\no If @event_statusis IN_PROGRESS, the LEl issuer SHALL provide information regarding the\nAffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide lei:EntityLegalFormCode and lei:OtherLegalForm, if necessary\no MAY provide lei:Legallurisdiction\no MAY provide lei:LegalName\no MAY provide lei:OtherEntityNames\no MAY provide lei:TransliteratedOtherEntityNames\no MAY provide lei:SuccessorEntity\n\no If @event_status is COMPLETED and there is at least one SuccessorEntity entry added to the LEI\n\nRecord Set, the LEl issuer SHALL provide information regarding the AffectedFields: For\n\n@field_xpath the LEl issuer usually\n\no SHALL provide lei:SuccessorEntity\n\no Issue a new LEI Record (see Use Cases 4.1 and 4.3), including all appropriate relationships.\nState Transition and Validation Rules for Common Data File formats Page 121 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2099,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.100Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o For the newly issued LEI Record, create a new LegalEntityEvent with:\no @group_type SHALL be COMPLEX_CHANGE_LEGAL_FORM.\no @event_status SHALL be COMPLETED.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be CHANGE_LEGAL_FORM.\no LegalEntityEventEffectiveDate SHALL be the date when the change in the legal form becomes\neffective in the Legal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no AffectedFields SHALL be omitted.\nState Transition and Validation Rules for Common Data File formats Page 122 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":749,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.101Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"LegalForm changes and LEI A retires\n_————’\nPost Event Post Event\nLEIA LEI B (Create new LEI Record Set)\nEntity: Entity:\no EntityLegalFormCode: FGVH o EntityLegalFormCode: O85W\no LegalName: Company inc o LegalName: Company LLC\no SuccessorlLEl: B o EntityCreationDate:\ne 2020-01-15T00:00:00.000Z\nRegistration:\no lei:RegistrationStatus: RETIRED Registration:\no lei:LastUpdateDate: o lei:RegistrationStatus: ISSUED\no 2020-01-23T10:42:00+02:00 o lei:LastUpdateDate:\no 2020-01-23T10:42:00+02:00\nRelationship:\no rr:RegistrationStatus: RETIRED LegalEntityEvent:\no rr:RelationshipStatus: INACTIVE o @group_type:\no rr:LastUpdateDate: COMPLEX_CHANGE_LEGAL_FORM\no 2020-01-23T10:42:00+02:00 e @event_status: COMPLETED\no LegalEntityEventType:\nLegalEntityEvent: CHANGE_LEGAL_FORM\n° (@group_type: o LegalEntityEventEffectiveDate:\nCOMPLEX_CHANGE_LEGAL_FORM e 2020-01-15T00:00:00.000Z\no @event_status: COMPLETED o LegalEntityEventRecordedDate:\no LegalEntityEventType: e 2020-01-23T00:00:00.000Z\nCHANGE_LEGAL_FORM ¢ ValidationDocuments:\no LegalEntityEventEffectiveDate: SUPPORTING_DOCUMENTS\ne 2020-01-15T00:00:00.000Z o ValidationReference:\no LegalEntityEventRecordedDate: http://pub_registry.gov/new_entity_docs.pdf\no 2020-01-23T00:00:00+01:00\no ValidationDocuments:\nSUPPORTING_DOCUMENTS\no ValidationReference:\nhttp://pub_registry.gov/new_entity docs.pdf\nAffectedFields:\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:E\nntity/lei:SuccessorEntity/lei:SuccessorLEl:\nLEI B\nExample 6: Legal Entity LEI A changes its legal form from ELF O59C to ELF NSNT with effective date January 15, 2020. As a\nconsequence, LEI A retires, and an LEI Record Set for LEI B is created. The completion of the Legal Entity Event was\nrecorded in the Global LEI System on January 23, 2020.\nState Transition and Validation Rules for Common Data File formats Page 123 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1938,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.101Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"A legal form change could result in one of the three above described scenarios. The LEl issuer SHALL\nassess and evaluate the documents at hand and decide which of the three scenarios apply in the\nparticular case.\n4.13.6 Legal Entity Event — Acquisition\nLegal Entity A (general Legal Entity or Fund, but not Branch, Government Entity or International\nOrganization), either independent/stand-alone or Subsidiary/sub-fund/compartment, is acquired by\nanother Legal Entity B but remains a separate/segregated Legal Entity.\nThe LEl issuer managing the record of entity A SHALL:\no Retire any current Relationship Records and/or stop publishing Reporting Exception Records for\nA.\no Create new relationships/exceptions with parent Legal Entity B (including Fund relationships, if\napplicable).\no Create a new LegalEntityEvent (single, combined or group, as applicable) with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be MERGERS_AND_ACQUISITIONS.\no LegalEntityEventEffectiveDate SHALL be the date the acquisition becomes effective in the\nLegal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no If @event_statusis IN_PROGRESS, the LEl issuer SHALL provide information regarding the\nAffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide rr:EndNode/rr:NodelD\no SHALL provide rr:EndNode/rr:NodeType\no SHALL provide rr:RelationshipType\n* MAY provide repex:ExceptionCategory\no MAY provide repex:ExceptionReason\nState Transition and Validation Rules for Common Data File formats Page 124 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1849,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.101Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"O Acquired by O\n- >\nLEIA LEIB\nPost Event\nLEI A\nRelationship:\no rr:RegistrationStatus: RETIRED\no rr:LastUpdateDate: 2020-04-16T17:43:00.000Z\no Create new RelationshipRecords, if applicable\no Stop publishing ReportingExceptions, if applicable\nLegalEntityEvent:\no @group_type: STANDALONE\no @event_status: COMPLETED\no LegalEntityEventType: MERGERS_AND_ACQUISITIONS\no LegalEntityEventEffectiveDate: 2020-03-02T00:00:00.000Z\no LegalEntityEventRecordedDate: 2020-04-16T00:00:00.000Z\no ValidationDocuments: SUPPORTING_DOCUMENTS\no ValidationReference: http://registry.gov/evidence.pdf\nExample 7: The Legal Entity with LEI A is acquired by Legal Entity with LEI B with effective date on March 2, 2020 and\nrecorded in the Global LEI System on April 16, 2020.\n4.13.7 Legal Entity Event — Absorption\nLegal Entity A (general Legal Entity or Fund, but not Branch, Government Entity or International\nOrganization), either independent/stand-alone or Subsidiary/sub-fund/compartment, is acquired by\nanother Legal Entity B (may or may not be in a parent relationship with A). All assets/shares of Legal\nEntity A are absorbed by Legal Entity B and A ceases to exist as an active Legal Entity.\nNote: The addition of Absorption to the list of Legal Entity Events covered by the policy is under\nreview with the LEI-ROC.\nThe LEl issuer managing the record of Legal Entity A SHALL:\no Retire LEI Record Set of absorbed Legal Entity A:\no Set RegistrationStatus RETIRED.\ne Set current relationships to RETIRED, if applicable.\no Set Legal Entity B as SuccessorEntity.\nState Transition and Validation Rules for Common Data File formats Page 125 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1726,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.101Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be ABSORPTION.\no LegalEntityEventEffectiveDate SHALL be the date the Absorption becomes effective in the\nLegal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no If @event_status is IN_PROGRESS or COMPLETED, the LEl issuer SHALL provide information\nregarding the AffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide lei:SuccessorEntity\nThe LEl issuer managing the record of entity B SHALL:\no Record the absorption of Legal Entity A by creating a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be ABSORPTION.\no LegalEntityEventEffectiveDate SHALL be the date the Absorption becomes effective in the\nLegal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\n© AffectedFields SHALL be omitted.\nNote: LEI Records for A and B MAY be managed by different LEl issuers. Nevertheless, there SHALL be\nconsistency for the LegalEntityEventEffectiveDate and ValidationReference of the event; Recorded\nDate MAY be different.\nState Transition and Validation Rules for Common Data File formats Page 126 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1645,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.103Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"O Absorbed by O\nR\nLEI A LEIB\nPost Event Post Event\nLEI A LEI B\nEntity: LegalEntityEvent:\no SuccessorEntity: LEI B o @group_type: STANDALONE\no @event_status: COMPLETED\nRegistration: o LegalEntityEventType: ABSORPTION\no RegistrationStatus: RETIRED o LegalEntityEventEffectiveDate:\no LastUpdateDate: 2020-01-23T10:42:00+02:00 e 2020-01-20T00:00:00.000Z\no LegalEntityEventRecordedDate:\nRelationship: e 2020-01-23T00:00:00.000Z\no Stop publishing ReportingExceptions » ValidationDocuments:\nSUPPORTING_DOCUMENTS\nRelationship Registraion: « ValidationReference:\no RegistrationStatus: RETIRED http://registry.gov/evidence.pdf\no LastUpdateDate: 2020-01-23T10:42:00+02:00\nLegalEntityEvent:\no @group_type: STANDALONE\no @event_status: COMPLETED\no LegalEntityEventType: ABSORPTION\no LegalEntityEventEffectiveDate:\ne 2020-01-20T00:00:00.000Z\no LegalEntityEventRecordedDate:\ne 2020-01-23T00:00:00.000Z\no ValidationDocuments:\nSUPPORTING_DOCUMENTS\no ValidationReference:\nhttp://registry.gov/evidence.pdf\nAffectedFields:\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:E\nntity/lei:SuccessorEntity/lei:SuccessorLEl:\nLEI B\nExample 8: The Legal Entity with LEI A is absorbed by a Legal Entity with an LEI B with effective date January 20, 2020 and\nboth records have been updated on the same date January 23, 2020.\nState Transition and Validation Rules for Common Data File formats Page 127 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1480,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.104Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.13.8 Legal Entity Event — Merger\nA common example how a Merger is processed and its outcome:\nLegal Entity A (not a Branch) and Legal Entity B (not a Branch either and usually of a similar category\nas A) combine their shares/assets and together form a new Legal Entity C (general Legal Entity or\nFund, but not Branch). A and B cease to exist as Legal Entities after the Merger.\nThe LEl issuer(s) managing the LEI Record Sets of entities A and B SHALL:\no Retire records of entity A and entity B once @event_status is COMPLETED:\no Set RegistrationStatus RETIRED.\no Set EntityStatus INACTIVE.\ne Set current relationships to RETIRED, if applicable.\no Set Legal Entity C as SuccessorEntity.\no Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be MERGERS_AND_ACQUISITIONS.\no LegalEntityEventEffectiveDate SHALL be the date the Merger becomes effective in the Legal\nJurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no If @event_status is IN_PROGRESS or COMPLETED, the LEl issuer SHALL provide information\nregarding the AffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide lei:SuccessorEntity\nThe LEl issuer creating the new LEI Record for Legal Entity C SHALL:\n¢ Issue a new LEI Record (see Use Case Issue new LEI), including all appropriate relationships.\no Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be omitted.\nG State Transition and Validation Rules for Common Data File formats Page 128 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1912,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.104Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be MERGERS_AND_ACQUISITIONS.\no LegalEntityEventEffectiveDate SHALL be the date the Merger becomes effective in the Legal\nJurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no AffectedFields SHALL be omitted.\nLEIB\nMerge O\nLEIC\nLEI A\nPre Event Post Event\nState Transition and Validation Rules for Common Data File formats Page 129 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":590,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.105Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Pre & Post Event Post Event\nLEI A; LEIB LEI C (Create new LEI Record Set)\nEntity: Entity:\no EntityStatus: INACTIVE (Post Event) o LegalName: “New Firm LLC”\no SuccessorEntity: LEI C (Post Event) o EntityStatus: ACTIVE\no CreationDate:\nRegistration LE| A: 2020-04-19T00:00:00+02:00\no RegistrationStatus: RETIRED (Post Event)\no LastUpdateDate (Post Event): Registration:\no LEI A: 2020-04-20T13:43:25+02:00 o RegistrationStatus: ISSUED\no LEIB: 2020-05-20T13:43:25+02:00 ¢ InitialRegistrationDate:\n2020-04-20T00:00:00+02:00\nRelationship (Post Event):\n« Stop publishing ReportingExceptions LegalEntityEvent:\no @group_type: STANDALONE\nRelationship Registration (Post Event): o @event_status: COMPLETED\no RegistrationStatus: RETIRED o LegalEntityEventType:\nMERGERS_AND_ACQUISITIONS\nLegalEntityEvent (Pre & Post Event): o LegalEntityEventEffectiveDate:\no @group_type: STANDALONE o 2020-04-19T00:00:00+02:00\no @entity_status: IN_PROGRESS o LegalEntityEventRecordedDate:\no LegalEntityEventType: MERGERS_AND_ACQUISITIONS o 2020-04-20T00:00:00+02:00\no LegalEntityEventEffectiveDate: o ValidationDocuments: CONTRACTS\ne 2020-04-19T00:00:00+02:00 o ValidationReference: Notarized documents\no LegalEntityEventRecordedDate:\no LEI A: 2020-03-11T00:00:00+02:00\ne LEIB: 2020-03-13T00:00:00+02:00\no ValidationDocuments: SUPPORTING_DOCUMENTS\no ValidationReference: http://registry.gov/evidence.pdf .\nExample 9: LEI A and LEI B merge into LEI C (new Legal\n. Entity). LEI A and LEI B cease to exist on April 19, 2020.\nAffectedFields: The LEl issuer of LEI A was made aware of the\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei: incoming merger on 11 March 2020, while the LEI\nSuccessorEntity/lei:SuccessorLEl: LEI C issuer of LEI B was made aware of the incoming\nmerger on 13 March 2020. Both LOUs were given the\nLegalEntityEvent (Post Event): information that the legal name of LEI C will be “New\n« @group_type: STANDALONE Firn:l LLC” and that the merger will be complete.d on 19\n« @entity_status: COMPLETED April 2020. The recorded dates.of the Legal Entity\n- Events MAY vary between the involved records, as\no LegalEntityEventType: MERGERS_AND_ACQUISITIONS these may be managed by different LEI issuers.\no LegalEntityEventEffectiveDate:\no 2020-04-19T00:00:00+02:00\no LegalEntityEventRecordedDate:\ne LEI A: 2020-04-20T00:00:00+02:00\ne LEI B: 2020-05-20T00:00:00+02:00\no ValidationDocuments: SUPPORTING_DOCUMENTS\no ValidationReference: http://registry.gov/evidence.pdf\nAffectedFields:\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:\nSuccessorEntity/lei:SuccessorLEl: LEI C\nState Transition and Validation Rules for Common Data File formats Page 130 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2768,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.105Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"2 Lifecycle and General Concepts\n\n2.1 LEI Record Set Reference Data\n\nThe LEI Record Set consists of a set of one LEI record and its corresponding Relationship Records (RR),\n\nand Reporting Exception Records (Repex) that give the full Level 1 and Level 2 Reference Data for\n\nthat LEL.\n\nLEI records, Relationship Records and Reporting Exception Records each consist of a pre-defined set\n\nof mandatory and optional data elements. The following types of elements are used within the LEI\n\nRecord Set:\n\no Fixed list of allowed values (enumerations): only values defined in the respective xsd file are\nallowed. Example element: RegistrationStatus.\n\no Codes from a code list: only values from the current version of the referenced code list are\nallowed. Example element: LegalFormCode.\n\no Fixed format: only values with a specific format pattern are allowed. Example element: LEI.\n\no Free text: any content allowed. The xsd MAY have some restrictions defined (length, character\nset, no leading/trailing spaces). The content of a free text element SHALL NOT be “N/A” or similar\nplaceholder. Example element: LegalName.\n\n2.1.1 Legal Entity data (Level 1 data — ‘Who is who’)\n\nThe Legal Entity Identifier (LEl) connects to key Reference Data that provides the information on a\n\nLegal Entity identifiable with an LEI. The ISO 17442 standard developed by the International\n\nOrganization for Standardization defines a set of attributes that comprises the most essential\n\nelements of identification. The standard specifies the minimum Reference Data, which must be\n\nsupplied for each LEIl and further requirements for the LEI code and provided Reference Data. For the\ncomplete scope and content of the standard, please refer to the International Organization for\n\nStandardization®.\n\nWith the inclusion of Legal Entity Events and the related update of the Common Data File format to\n\nversion 3.1, the Legal Entity data will be enriched with Legal Entity Event information that impacts\n\nthe Legal Entity and changes their reference data.\n\n2.1.2 Legal Entity relationship information (Level 2 data — ‘Who owns whom’)\n\nLegal Entity relationship information describe the relationship between two Legal Entities. All\n\nrelationships have a specific type describing the kind of the relationship and two end points defining\n\nL https://www.iso.org/standard/75998.html\n\nState Transition and Validation Rules for Common Data File formats Page 14 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2526,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.105Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.13.9 Legal Entity Event — Transformation of a Subsidiary to an International Branch\nLegal Entity A (a general Legal Entity) in country X, a Subsidiary of parent Legal Entity B in country Y,\nis absorbed by Legal Entity B and turned into an International Branch. All shares/assets and liabilities\nof Legal Entity A are absorbed by Legal Entity B. This Legal Entity Event can only be recorded if Legal\nEntity A fulfills all the requirements for International Branches within the Global LEI System (see\nsection 4.2); otherwise, a different Legal Entity Event could apply. In case Legal Entity A is in the\nhome jurisdiction of Legal Entity B and it has been transformed to a Branch entity, the LEI of Legal\nEntity A SHALL be set to RETIRED since an International Branch LEI cannot be assigned in the home\njurisdiction. In that scenario the Legal Entity Event of type ABSORPTION MAY apply.\nFor the transformation of a subsidiary to an international branch, the LEl issuer managing the LEI\nRecord Set of Legal Entity A SHALL:\ne Update LEI Record Set of Legal Entity A to Branch:\no Set current relationships with Legal Entity B to RETIRED.\no Create a new relationship with Legal Entity B with RelationshipType\nIS_INTERNATIONAL BRANCH_OF; StartDate of the RelationshipPeriod with PeriodType\nRELATIONSHIP_PERIOD SHALL be the LegalEntityEventEffectiveDate of the Legal Entity Event\n(see below).\no Set EntityCategory to BRANCH.\ne Set the LegalForm and the ELF code to the LegalForm and the ELF code of the (head office)\nLegal Entity B.\no Set the Legal Jurisdiction to the Legal Jurisdiction of the (head office) Legal Entity B.\no Setthe RegistrationStatus (lei and rr) to either ISSUED or LAPSED, depending on the\nRegistrationStatus of the (head office) Legal Entity B.\no Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be TRANSFORMATION_SUBSIDIARY_TO_BRANCH\no LegalEntityEventEffectiveDate SHALL be the date the transformation becomes effective\nin the Legal Jurisdiction of the Legal Entity\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the\nGlobal LEI System.\nState Transition and Validation Rules for Common Data File formats Page 131 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2465,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.105Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o If @event_status is IN_PROGRESS, the LEl issuer SHALL provide information regarding\nthe AffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide rr:EndNode/rr:NodelD\no SHALL provide rr:EndNode/rr:NodeType\no SHALL provide rr:RelationshipType\no SHALL provide lei:EntityCategory\ne SHALL provide lei:SuccessorEntity, if applicable\no If @event_status is COMPLETED, the LEl issuer SHALL provide information regarding the\nAffectedFields: For @field_xpath the LEl issuer usually\ne SHALL provide lei:SuccessorEntity, if applicable\nState Transition and Validation Rules for Common Data File formats Page 132 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":723,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.105Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Switzerland O Transformed into O Belgium\nLET A International branch of LEI B\nPost Event Post Event\nLEI B\nLEI A\nEntity:\nEntity: o EntityLegalformCode: N5NT\ne EntityCategory: BRANCH o Legallurisdiction: BE\no EntityLegalformCode: N5NT\no Legallurisdiction: BE Registration:\no RegistrationStatus: ISSUED\nRegistration:\no RegistrationStatus: ISSUED Relationship Registration:\no RegistrationStatus: PUBLISHED\nRelationship: © LastUpdateDate:\no RegistrationStatus of previous relationships with LEI s 2020-04-20T13:43:25+02:00\nB: RETIRED\no Create new RelationshipRecord with LEI B with\nRelationship/RelationshipType\nIS INTERNATIONAL BRANCH OF Example 10: The Legal Entity with LEI A,\n* RelationshipPeriodStartDate: r:::\\csi;cnlrisez ?rl:tb:adr:ai:\\‘{c::nl-aili:;\\:l branch\n° 2020-04-18T00:00:00+02:00 of Legal Entity B with effective date April\n18, 2020. Both records have been\nRelationship Registration: updated on the same date April 20, 2020.\no RegistrationStatus: PUBLISHED\no LastUpdateDate: 2020-04-20T13:43:25+02:00\nLegalEntityEvent:\no @group_type: STANDALONE\no @entity_status: COMPLETED\no LegalEntityEventType:\nTRANSFORMATION_SUBSIDIARY_TO_BRANCH\no LegalEntityEventEffectiveDate:\no 2020-04-18T00:00:00+02:00\no LegalEntityEventRecordedDate:\no 2020-04-20T00:00:00+02:00\no ValidationDocuments: CONTRACTS\no ValidationReference: Notarized documents\nIf applicable, LegalEntityEvent:\no @group_type: STANDALONE\no @entity_status: COMPLETED\no LegalEntityEventType: CHANGE_LEGAL_FORM\no LegalEntityEventEffectiveDate:\no 2020-04-18T00:00:00+02:00\no LegalEntityEventRecordedDate:\no 2020-04-20T00:00:00+02:00\no ValidationDocuments: CONTRACTS\no ValidationReference: Notarized documents\nState Transition and Validation Rules for Common Data File formats Page 133 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1860,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.105Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.13.10 Legal Entity Event — Acquisition of an International Branch\nA common example how Acquisition of an International Branch is processed and its outcome:\nInternational Branch A of (head office) Legal Entity B, is acquired by Legal Entity C and henceforth\noperates as Branch for (head office) Legal Entity C. The assets and liabilities related to the Branch are\nfully or partially transferred from Legal Entity B to Legal Entity C. Legal Entity B will have International\nBranch A deleted from the official registry (RA source). Legal Entity C will register a new International\nBranch D in the official registry. This Legal Entity Event can only be recorded if Legal Entity D fulfills all\nthe requirements for International Branches within the Global LEI System (see section 4.2).\nThe LEl issuer managing the LEI Record Set of International Branch A SHALL:\no Set the RegistrationStatus (lei and rr) to RETIRED\no Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be ACQUISITION_BRANCH.\no LegalEntityEventEffectiveDate SHALL be the date the acquisition of the Branch becomes\neffective in the Legal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no If @event_statusis IN_PROGRESS or COMPLETED, the LEl issuer SHALL provide information\nregarding the AffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide lei:SuccessorEntity\no Set the new International Branch (see below) as SuccessorEntity.\nThe LEl issuer managing the LEI Record Set of Branch entity D SHALL:\no Create a new LEI Record for a Branch, if the conditions for issuing an LEI Record for a Branch are\nmet (see Use Case 4.2).\no Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be COMPLETED.\no @group_id SHALL be omitted.\nState Transition and Validation Rules for Common Data File formats Page 134 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2206,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.105Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be ACQUISITION_BRANCH.\no LegalEntityEventEffectiveDate SHALL be the date the acquisition of the Branch becomes\neffective in the Legal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no AffectedFields SHALL be omitted.\no The EntityCreationDate SHALL be the LegalEntiyEventEffectiveDate of entity A’s event with\nLegalEntityEventType ACQUISITION_BRANCH.\n¢ The LegalEntityEventEffectiveDate SHALL be the date the Acquisition becomes effective in the\nLegal Jurisdiction of Branch entity A.\ne Set the LegalForm and the ELF code to the LegalForm and the ELF code of the (head office) Legal\nEntity C.\no Set the Legal Jurisdiction to the Legal Jurisdiction of the (head office) Legal Entity C.\n¢ Create a Relationship Record with the head office C and RelationshipType\nIS_INTERNATIONAL _BRANCH_OF; the StartDate of the RelationshipPeriod with PeriodType\nRELATIONSHIP_PERIOD SHALL be the EntityCreationDate.\no Legal Entity D can acquire an LEl only in case it is not in the home jurisdiction of Legal Entity C.\nState Transition and Validation Rules for Common Data File formats Page 135 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1341,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.105Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"LEI C\nEntity:\no EntityLegalFormCode: N5NT\no Legallurisdiction: BE\nO Transfers assets & liabilities O\n—>\nLEIB LEIC\nFormer INTERNATIONAL_BRANCH_OF\nIS_INTERNATIONAL_BRANCH_OF\nchd\\‘edw\nLEIA LEI D (Create new LEI Record Set)\nEntity: Entity:\ne SuccessorEntity: LEI D o EntitiyCreationDate:\ne 2020-04-19T00:00:00+02:00\nRegistration: o EntityLegalFormCode: N5NT\no RegistrationStatus: RETIRED o Legallurisidiction: BE\no LastUpdateDate: 2020-04-20T13:43:25+02:00\nRelationship:\nRelationship: ° RelationshipType:\no Stop publishing ReportingExceptions IS_INTERNATIONAL_BRANCH_OF\no RelationshipPeriodType:\nRelationship Registration: RELATIONSHIP_PERIOD\no RegistrationStatus: RETIRED * RelationshipPeriodStartDate:\ne 2020-04-19T00:00:00+02:00\nLegalEntityEvent: o LastUpdateDate: 2020-04-20T13:43:25+02:00\no @group_type: STANDALONE\no @entity_status: COMPLETED LegalEntityEvent:\no LegalEntityEventType: ACQUISITION_BRANCH o @group_type: STANDALONE\no LegalEntityEventEffectiveDate: o @entity_status: COMPLETED\n¢ 2020-04-19T00:00:00+02:00 o LegalEntityEventType: ACQUISITION_BRANCH\no LegalEntityEventRecordedDate: o LegalEntityEventEffectiveDate:\ne 2020-04-20T00:00:00+02:00 e 2020-04-19T00:00:00+02:00\ne ValidationDocuments: REGULATORY_FILING o LegalEntityEventRecordedDate:\ne 2020-04-20T00:00:00+02:00c\nAffectedFields: + ValidationDocuments: REGULATORY_FILING\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:E\nntity/lei:SuccessorEntity/lei:SuccessorLEl:\nLEID\nExample 11: The Legal Entity with LEI A, which is an International Branch of B, is acquired by Legal Entity with an LEI C\nwith effective date April 19, 2020. The Legal Entity with LEI A ceases to exist and a new Legal Entity with LEI D is issued as\ninternational Branch of Legal Entity with LEI C. The LElI Record Sets of LEI A and LEI D have been updated on the same\ndate April 20, 2020.\nState Transition and Validation Rules for Common Data File formats Page 136 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2022,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.105Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.13.11 Legal Entity Event — Break-up\nLegal Entity A (general Legal Entity or Government Entity) completely separates into two or more\nindependent Legal Entities B and C (plus D, E, ...). Entity A will cease to exist as an independent Legal\nEntity.\nA common example how Break-up is processed and its outcome if entity A ceases to exists:\nThe LEl issuer managing the LEl Record Set of entity A SHALL:\ne Retire the LEI Record Set of Legal Entity A:\no Set RegistrationStatus RETIRED.\ne Set current relationships to RETIRED, if applicable.\ne SHALL include SuccessorEntity for every newly created entity after the separation.\no Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be BREAKUP.\no LegalEntityEventEffectiveDate SHALL be the date the Break-up becomes effective in the Legal\nJurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no If @event_statusis IN_PROGRESS or COMPLETED, the LEl issuer SHALL provide information\nregarding the AffectedFields: For @field_xpath the LEl issuer usually\ne SHALL provide lei:SuccessorEntity for all independent Legal Entities created\nThe LEl issuer(s) managing the records of entities B, C, ... SHALL:\no Create new LEI Records for the new Legal Entity(ies) (see Use Case 4.1).\no Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be COMPLETED.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\nG State Transition and Validation Rules for Common Data File formats Page 137 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1852,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.105Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o LegalEntityEventType SHALL be BREAKUP.\no LegalEntityEventEffectiveDate SHALL be the date the Break-up becomes effective in the Legal\nJurisdiction of the new Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no AffectedFields SHALL be omitted.\nState Transition and Validation Rules for Common Data File formats Page 138 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":495,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.105Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"LEIB LEIC LEID(E, F,..)\nv\nBreak-up\nLEI A\nLEI A LEIB, C, (D, E,F,..)\nEntity: o Create new LEI Record Sets\no SuccessorEntity: LEI B\no SuccessorEntity: LEI C LegalEntityEvent:\nRegistration: o @group_type: STANDALONE\no RegistrationStatus: RETIRED o @event_status: COMPLETED\no LegalEntityEventType: BREAKUP\nRelationship: + LegalEntityEventEffectiveDate:\n© Stop publishing ReportingExceptions © 2020-04-12T00:00:00+02:00\no LegalEntityEventRecordedDate:\nRelationship Registration + 2020-04-20T00:00:00+02:00\n© RegistrationStatus: RETIRED + ValidationDocuments:\n_ SUPPORTING_DOCUMENTS\nLegalEntityEvent: » ValidationReference:\n© @group_type: STANDALONE http://registry.gov/evidence.pdf\no @event_status: COMPLETED\no LegalEntityEventType: BREAKUP\no LegalEntityEventEffectiveDate:\no 2020-04-12T00:00:00+02:00\no LegalEntityEventRecordedDate:\no 2020-04-20T00:00:00+02:00\no ValidationDocuments:\nSUPPORTING_DOCUMENTS\no ValidationReference:\nhttp://registry.gov/evidence.pdf\nAffectedFields:\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Ent\nity/lei:SuccessorEntity/lei:SuccessorLEl: LEI B\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Ent\nity/lei:SuccessorEntity/lei:SuccessorLEl: LEI C\nExample 12: The Legal Entity with LEI A is separated into LEI B and LEI C with effective date April 12, 2020. The Legal\nEntity with LEI A ceases to exist. Theoretically, it is possible that LEI A is split into additional Legal Entities (LEID, E, F, ...).\nThe LEI Record Sets of LEI A and LEI D have been updated on the same date April 20, 2020.\nState Transition and Validation Rules for Common Data File formats Page 139 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1712,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.105Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.13.12 Legal Entity Event — Demerger\n\nA part or division of Legal Entity A (general Legal Entity or Government Entity) is separated into a new\n\nseparate entity, Subsidiary Legal Entity B. Part of Legal Entity A’s shares/assets and liabilities are\n\ntransferred to B.\n\nThe LEl issuer managing the LEI Record Set of Legal Entity A SHALL:\n\no Create a new LegalEntityEvent with:\n\no @group_type SHALL be STANDALONE.\n\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\n\no @group_id SHALL be omitted.\n\no @group_sequence_no SHALL be omitted.\n\no LegalEntityEventType SHALL be DEMERGER.\n\no LegalEntityEventEffectiveDate SHALL be the date the Demerger becomes effective in the\nLegal Jurisdiction of the Legal Entity.\n\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\n\no If @event_statusis IN_PROGRESS or COMPLETED, the LEl issuer SHALL provide information\nregarding the AffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide lei:SuccessorEntity\n\no Set LEI B as SuccessorEntity.\n\nThe LEl issuer managing the LEI Record Set of entity B SHALL:\n\n¢ Create a new LEI Record Set for the new Legal Entity B (see Use Case 4.1).\n\n* Create accounting consolidation relationship(s) with Legal Entity A, as applicable; StartDate of\nthe RelationshipPeriod with PeriodType RELATIONSHIP_PERIOD SHALL be the effective date that\nthe Legal Entity event became effective in the Legal Jurisdiction of the new Legal Entity (see\nbelow).\n\no Create a new LegalEntityEvent with:\n\no @group_type SHALL be STANDALONE.\n\no @event_status SHALL be COMPLETED.\n\no @group_id SHALL be omitted.\n\no @group_sequence_no SHALL be omitted.\n\no LegalEntityEventType SHALL be DEMERGER.\nState Transition and Validation Rules for Common Data File formats Page 140 of 170\n\n@ Public Version 2.7.1 Final\n\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1910,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.105Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"the Legal Entities linked by the relationship. Currently, relationship information for accounting\nconsolidation parents, for branches and for funds are defined within the Global LEI System.\nAccounting consolidating parent relationship\nAccounting consolidating parent relationship information is based on existing accounting definitions\nimplemented in the International Financial Reporting Standard (IFRS) or the United States Generally\nAccepted Accounting Principles (US GAAP), but other accounting standards are also accepted.\nThe direct accounting consolidating parent of Legal Entity X would be defined as the lowest level\nLegal Entity that prepares consolidated financial statements that consolidate entity X, based on the\naccounting definition of consolidation applying to this parent.\nThe ultimate accounting consolidating parent of entity X would be the highest level Legal Entity\npreparing consolidated financial statements that consolidate entity X, based on the accounting\ndefinition of consolidation applying to this parent. The ultimate accounting consolidating parent\nSHALL NOT have accounting consolidating parent relationships of its own.\nAccording to the definitions of direct and ultimate parents, a Legal Entity cannot declare a\nconsolidation relationship for one parent and a non-consolidating exception for the other. If the\ndirect accounting consolidation parent is controlled, but not consolidated, by another entity, it is also\nconsidered to be the ultimate parent within the Global LEI System (see Figure 1). Likewise, if the child\nLegal Entity is controlled, but not consolidated, by an entity that itself is controlled by an entity\nconsolidating the child Legal Entity, the consolidating entity would be both direct and ultimate parent\n(see Figure 2, example b).\nBy the same definition, only entities with two non-consolidating exceptions can be viable candidates\nfor being declared as an ultimate parent of another entity. GLEIF created a set of data quality checks\nto ensure compliance with this requirement, assigning errors to both the LEl issuer of the child Legal\nEntity record and of the ultimate parent record when inconsistent parent relationships are detected.\nIt is expected that LEl issuers, as part of the Validation and Verification of Level 2 data, check if the\nultimate parent identified by an LEI has consistent parent information. LEl issuer SHALL use LEI\nSearch 2.0, Level 2 XML files (relationship and exception files) and/or Golden Copy files to identify\ninformation regarding the ultimate parent's relationships (if any).\nState Transition and Validation Rules for Common Data File formats Page 15 of 170\n@ Public Version 2.7.1 Final\nG 2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2755,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.105Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o LegalEntityEventEffectiveDate SHALL be the date the Demerger becomes effective in the\nLegal Jurisdiction of the new Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no AffectedFields SHALL be omitted.\nO Demerger O\n—>\nLEI A LEIB\nLEIA LEI B (Create new LEI Record Set)\nEntity: Entity:\no SuccessorEntity: LEI B o EntityCreationDate:\no 2020-04-12T00:00:00+02:00\nLegalEntityEvent:\no @group_type: STANDALONE Relationship:\no @event_status: COMPLETED o Create accounting consolidation\n+ LegalEntityEventType: DEMERGER relationship(s)\no LegalEntityEventEffectiveDate: o RelationshipPeriodStartDate:\no 2020-04-12T00:00:00+02:00 o 2020-04-12T00:00:00+02:00\n+ LegalEntityEventRecordedDate: © RelationshipPeriodType:\n+ 2020-04-20T00:00:00+02:00 RELATIONSHIP_PERIOD\n° ValidationDocuments: L LaStUpdateDate: 2020-04-20T13:43:25+02:00\nSUPPORTING_DOCUMENTS\n« ValidationReference: LegalEntityEvent:\nhttp://registry.gov/evidence.pdf © @group_type: STANDALONE\no @event_status: COMPLETED\nAffectedFields: o LegalEntityEventType: DEMERGER\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/I ¢ LegalEntityEventEffectiveDate:\nei:Entity/lei:SuccessorEntity/lei:Successor e 2020-04-12T00:00:00+02:00\nLEI: LEI B o LegalEntityEventRecordedDate:\no 2020-04-20T00:00:00+02:00\no ValidationDocuments:\nSUPPORTING_DOCUMENTS\no ValidationReference:\nhttp://registry.gov/evidence.pdf\nExample 13: The Legal Entity with LEI A is separated into LEI B with effective date April 12, 2020. The Legal Entity with LEI\nA continues to exist. The LEI Record Sets of LEI A and LEI D have been updated on the same date April 20, 2020.\nState Transition and Validation Rules for Common Data File formats Page 141 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1838,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.108Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.13.13 Legal Entity Event — Spin-off\nA part, division or Subsidiary of Legal Entity A (general Legal Entity) is separated into Legal Entity B,\nwhich could be a new or existing Legal Entity. In case of an existing Legal Entity B, Legal Entity B will\nno longer remain as a Subsidiary of Legal Entity A after completion of the Spin-off. Part of Legal Entity\nA’s shares/assets and liabilities are transferred to Legal Entity B; shareholders of Legal Entity A are\ncompensated for the asset value or loss by either receiving shares from Legal Entity B or via dividend.\nThe LEl issuer managing the LEI Record Set of Legal Entity A SHALL:\no Provide a SuccessorEntity.\no Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be SPINOFF.\no LegalEntityEventEffectiveDate SHALL be the date the Spin-off becomes effective in the Legal\nJurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no If @event_status is IN_PROGRESS or COMPLETED, the LEl issuer SHALL provide information\nregarding the AffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide lei:SuccessorEntity\nThe LEl issuer managing the LEI Record Set of Legal Entity B SHALL:\no Create a new LEI Record for the new Legal Entity B (see Use Case 4.1), if applicable.\no Retire any excisting relationships between Legal Entity B and Legal Entity A, if Legal Entity B\nalready exists,\no Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be COMPLETED, in case a new Legal Entity is created.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED, in case\nLegal Entity B already existed before the Spin-off.\no @group_id SHALL be omitted.\nState Transition and Validation Rules for Common Data File formats Page 142 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2110,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.108Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be SPINOFF.\no LegalEntityEventEffectiveDate SHALL be the date the Spin-off becomes effective in the\nLegalljurisdiction of the new Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no AffectedFields SHALL be omitted.\nO Spin-off O\n—>\nLEI A LEIB\nLEIA LEI B (existing entity, prev. subsidiary)\nEntity: Relationship:\no SuccessorEntity: LEI B o RelationshipStatus: RETIRED\no RelationshipPeriodEndDate:\nLegalEntityEvent: e 2020-04-18T00:00:00+02:00\n© @group_type: STANDALONE o RelationshipPeriodType:\no @event_status: COMPLETED RELATIONSHIP_PERIOD\n© LegalEntityEventType: SPINOFF o LastUpdateDate: 2020-04-20T13:43:25+02:00\no LegalEntityEventEffectiveDate:\no 2020-04-18T00:00:00+02:00 LegalEntityEvent:\no LegalEntityEventRecordedDate: o @group_type: STANDALONE\no 2020-04-20T00:00:00+02:00 o @event_status: COMPLETED\no ValidationDocuments: o LegalEntityEventType: SPINOFF\nSUPPORTING_DOCUMENTS o LegalEntityEventEffectiveDate:\no ValidationReference: e 2020-04-18T00:00:00+02:00\nhttp://registry.gov/evidence.pdf o LegalEntityEventRecordedDate:\no 2020-04-20T00:00:00+02:00\nAffectedFields: o ValidationDocuments:\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/| SUPPORTING_DOCUMENTS\nei:Entity/lei:SuccessorEntity/lei:Successor o ValidationReference:\nLEI: LEIB http://registry.gov/evidence.pdf\nExample 14: The Legal Entity with LEI A is separated into LEI B with effective date April 18, 2020. The Legal Entity with LEI\nA continues to exist. The former relationship record between LEI B and LEI A is set to RegistrationStatus RETIRED. The LEI\nRecord Sets of LEI A and LEI B have been updated on the same date April 20, 2020.\nState Transition and Validation Rules for Common Data File formats Page 143 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1934,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.108Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"O Spin-off O\n—>\nLEIA LEIB\nLEI A\nEntity: LEl B (new entity, prev. division of A)\ne SuccessorEntity: LEI B\nEntity:\nLegalEntityEvent: o EntityCreationDate:\n« @group_type: STANDALONE + 2020-04-18T00:00:00+02:00\no @event_status: COMPLETED\no LegalEntityEventType: SPINOFF LegalEntityEvent:\no LegalEntityEventEffectiveDate: © @group_type: STANDALONE\no 2020-04-18T00:00:00+02:00 ¢ @event_status: COMPLETED\no LegalEntityEventRecordedDate: o LegalEntityEventType: SPINOFF\ne 2020-04-20T00:00:00+02:00 o LegalEntityEventEffectiveDate:\no ValidationDocuments: e 2020-04-18T00:00:00+02:00\nSUPPORTING_DOCUMENTS o LegalEntityEventRecordedDate:\ne ValidationReference: e 2020-04-20T00:00:00+02:00\nhttp://registry.gov/evidence.pdf o ValidationDocuments:\nSUPPORTING_DOCUMENTS\nAffectedFields: o ValidationReference:\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/I http://registry.gov/evidence.pdf\nei:Entity/lei:SuccessorEntity/lei:Successor\nLEI: LEI B\nExample 15: The Legal Entity with LEI A is separated into LEI B with effective date April 18, 2020. The Legal Entity with LEI\nA continues to exist. The entity for LEI Record Set B has been created as a result of the Spin Off on April 20, 2020.\n4.13.14 Legal Entity Event — Transformation of an International Branch to a\nSubsidiary\nInternational Branch A of (head office) Legal Entity B, is separated from Legal Entity B and becomes a\nnew Legal Entity C, a Subsidiary of Legal Entity B; part of Legal Entity B’s shares/assets and liabilities\nare transferred to new Legal Entity C.\nThe LEl issuer managing the LEI Record of Legal Entity A SHALL:\ne Retire the LEI Record Set of Legal Entity A:\n\no Set RegistrationStatus to RETIRED.\n\no Set RegistrationStatus of all current Relationship Records to RETIRED with RelationshipStatus\nINACTIVE; set EndDate of RelationshipPeriod with PeriodType RELATIONSHIP_PERIOD as\nEffective Date of the LegalEntityEvent (see below).\n\no Set Legal Entity C as SuccessorEntity.\n\no Create a new LegalEntityEvent with:\nState Transition and Validation Rules for Common Data File formats Page 144 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2162,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.108Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o @group_type SHALL be STANDALONE.\n\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\n\no @group_id SHALL be omitted.\n\no @group_sequence_no SHALL be omitted.\n\n+ LegalEntityEventType SHALL be TRANSFORMATION_BRANCH_TO_SUBSIDIARY.\n\no LegalEntityEventEffectiveDate SHALL be the date the transformation becomes effective in\nthe Legal Jurisdiction of the Legal Entity.\n\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\n\no If @event_status is IN_PROGRESS, or COMPLETED, the LEl issuer SHALL provide information\nregarding the AffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide lei:SuccessorEntity\n\ne The LEl issuer managing the LEI Record of the new Legal Entity C SHALL:\n\no Create new LEI Records for the new Legal Entity(ies) (see section 4.1)\n\no Create a new accounting consolidation relationship(s) with Legal Entity B, as applicable;\nStartDate of the RelationshipPeriod with PeriodType RELATIONSHIP_PERIOD SHALL be the\nLegalEntityEventEffectiveDate that the Legal Entity event became effective in the Legal\nJurisdiction of the new Legal Entity (see below).\n\no Create a new LegalEntityEvent with:\n\no @group_type SHALL be STANDALONE.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no @event_Status SHALL be COMPLETED\n+ LegalEntityEventType SHALL be TRANSFORMATION_BRANCH_TO_SUBSIDIARY.\no LegalEntityEventEffectiveDate SHALL be the date the transformation becomes effective in\nthe Legal Jurisdiction of the new Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no AffectedFields SHALL be omitted.\nState Transition and Validation Rules for Common Data File formats Page 145 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1862,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.108Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"0\nFormer NTERNAW s\\mw&mwcomm DATED_BY\nSucceeded by\n—>\nS %\no LEIA LEI C (Create new LEI Record Set)\nEntity: Entity:\no SuccessorEntity: LEI C o EntityCreationDate:\ne 2020-04-17T00:00:00+02:00\nRegistration:\no RegistrationStatus: RETIRED Relationship:\no LastUpdateDate: 2020-04-20T13:43:25+02:00 o Create accounting consolidation\nrelationship(s)\nRelationship: o RelationshipPeriodStartDate:\no RelationshipPeriodEndDate: e 2020-04-17T00:00:00+02:00\ne 2020-04-17T00:00:00+02:00 o RelationshipPeriodType:\no RelationshipPeriodType: RELATIONSHIP_PERIOD\nRELATIONSHIP_PERIOD o LastUpdateDate: 2020-04-20T13:43:25+02:00\nRelationship Registration: LegalEntityEvent:\no RegistrationStatus: RETIRED o @group_type: STANDALONE\no @event_status: COMPLETED\nLegalEntityEvent: + LegalEntityEventType:\n° (@group_type: STANDALONE TRANSFORMATION_BRANCH_TO_SUBSIDIARY\n¢ @event_status: COMPLETED o LegalEntityEventEffectiveDate:\n¢ LegalEntityEventType: e 2020-04-17T00:00:00+02:00\nTRANSFORMATION_BRANCH_TO_SUBSIDIARY + LegalEntityEventRecordedDate:\no LegalEntityEventEffectiveDate: o 2020-04-20T00:00:00+02:00\n° 2020-04-17T00:00:00+02:00 o ValidationDocuments:\no LegalEntityEventRecordedDate: SUPPORTING_DOCUMENTS\no 2020-04-20T00:00:00+02:00 o ValidationReference:\n¢ ValidationDocuments: http://registry.gov/evidence.pdf\nSUPPORTING_DOCUMENTS\no ValidationReference:\nhttp://registry.gov/evidence.pdf\nAffectedFields:\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:E\nntity/lei:SuccessorEntity/lei:SuccessorLEl: LEI\nC\nExample 16: The Legal Entity with LEI A, which is an International Branch of LEI B, is transformed into a Subsidiary of LEI B\nwith effective date April 17, 2020. The Legal Entity with LEI B is now the direct and/or ultimate parent of LEI C. The Legal\nentity with LEI A ceases to exist and a new Legal Entity with LEI C is created as successor of LEI A. The LEI Record Sets of\nLEI A and LEI C have been updated on the same date April 20, 2020.\nState Transition and Validation Rules for Common Data File formats Page 146 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2120,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.108Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.13.15 Legal Entity Event — Bankruptcy\nLegal Entity A (general Legal Entity or Government Entity) declares Bankruptcy based on the laws of\nits jurisdiction. During the process, the Legal Entity could no longer be operational, and could still\nexist as Legal Entity. Once the process is completed, all or part of the Legal Entity could survive, and\nthe LEI remains ISSUED or the Legal Entity could become inactive and the LEIl is RETIRED. Bankruptcy\nevents are often followed by Liquidation, Insolvency or Dissolution events which will determine the\nfinal status of the Legal Entity and its LEI.\nWhile the Bankruptcy is in progress, the LEl issuer managing the LEI Record Set of Legal Entity A\nSHALL:\no Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status MAY be IN_PROGRESS.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be BANKRUPTCY.\no LegalEntityEventEffectiveDate SHALL be the date the Bankruptcy becomes effective in the\nLegal Jurisdiction of Legal Entity A.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no If @event_status is IN_PROGRESS or COMPLETED, the LEl issuer SHALL provide information\nregarding the AffectedFields: For @field_xpath the LEl issuer usually\no MAY provide lei:SuccessorEntity\no Keep the LEI Record Set of Legal Entity A as it is, but check if a change in legal name and/or in\nlegal form applies; create the respective Legal Entity Events, including all other LEI Record Set\nupdates, if necessary. Depending on the laws and regulations in the Legal Entity’s jurisdiction, the\nchange in legal form and/or legal name MAY already be effective, in which case the\n@event_status of these events SHALL be COMPLETED rather than IN_PROGRESS.\nOnce the Bankruptcy event is completed the LEl issuer managing the LEI Record Set of entity A\nSHALL:\no Create a new LegalEntityEvent with:\no @event_status SHALL be COMPLETED.\no LegalEntityEventEffectiveDate SHALL be the date the Bankruptcy becomes effective in the\nLegal Jurisdiction of Legal Entity A.\nState Transition and Validation Rules for Common Data File formats Page 147 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2291,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.108Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no AffectedFields SHALL be omitted.\nState Transition and Validation Rules for Common Data File formats Page 148 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":322,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.108Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Bankruptcy\n- O O o Oy >\nS S\nIn-progress Event Post Event\nLEI A LEI A\nLegalEntityEvent: Registration:\no @group_type: STANDALONE o RegistrationStatus: RETIRED\no @event_status: IN_PROGRESS\no LegalEntityEventType: BANKRUPTCY Relationship:\no LegalEntityEventEffectiveDate: o Create accounting consolidation relationship(s)\no 2020-09-08T00:00:00+02:00 o RelationshipPeriodEndDate:\no LegalEntityEventRecordedDate: e 2020-04-19T00:00:00+02:00\ne 2020-02-09T00:00:00+02:00 o RelationshipPeriodType: RELATIONSHIP_PERIOD\no ValidationDocuments: o LastUpdateDate:\nSUPPORTING_DOCUMENTS e 2020-04-20713:43:25+02:00\ne ValidationReference:\nhttp://registry.gov/evidence.pdf LegalEntityEvent:\no @group_type: STANDALONE\no @event_status: IN_PROGRESS\no LegalEntityEventType: BANKRUPTCY\nExample 17: The Legal Entity LEI A goes ¢ LegalEntityEventEffectiveDate:\nbankrupt. The process of Bankruptcy was e 2020-09-08T00:00:00+02:00\nscheduled to end on September 8, 2020 and o LegalEntityEventRecordedDate:\nwas recorded in the Global LEI System on s 2020-02-09T00:00:00+02:00\nFebruary 9, 2020. In this example, no « ValidationDocuments: SUPPORTING_DOCUMENTS\nrelevant information describing the Legal s -\nEntity is changed and therefore no ‘ Valldatlon'Reference: .\nAffectedFields are included. The Bankruptcy http://registry.gov/evidence.pdf\nwas completed on October 19, 2020 behind\nschedule. The completion of the Legal Entity LegalEntityEvent:\nEvent was recorded in the Global LEI System o @group_type: STANDALONE\non November 20, 2020. As a consequence of s @event_status: COMPLETED\nthe bankruptcy, the Legal Entity has ceased o LegalEntityEventType: BANKRUPTCY\nto exist due toa dissomtio.n even.t on o LegalEntityEventEffectiveDate:\nDecember 19, 2020. The dissolution was\nrecorded in the Global LEI System on ¢ 2020-10-19T00:00:00+02:00\nDecember 20, 2020. o LegalEntityEventRecordedDate:\ne 2020-11-20T00:00:00+02:00\nLegalEntityEvent:\no @group_type: STANDALONE\no @event_status: COMPLETED\no LegalEntityEventType: DISSOLUTION\no LegalEntityEventEffectiveDate:\ne 2020-12-19T00:00:00+02:00\no LegalEntityEventRecordedDate:\ne 2020-12-20T00:00:00+02:00\ne ValidationDocuments: SUPPORTING_DOCUMENTS\ne ValidationReference:\nhttp://registry.gov/evidence.pdf\nState Transition and Validation Rules for Common Data File formats Page 149 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2413,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.108Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.13.16 Legal Entity Event — Insolvency\n\nLegal Entity A (general Legal Entity or Government Entity) declares itself insolvent based on the laws\nof its jurisdiction. This Legal Entity Event is handled like a Bankruptcy, except for the different\nLegalEntityEventType recorded.\n\nIn contrast to Bankruptcy, the LEl issuer managing the LegalEntityEvent of Legal Entity A SHALL:\n\no Use INSOLVENCY as LegalEntityEventType.\n\n4.13.17 Legal Entity Event — Liquidation\n\nLegal Entity A (general Legal Entity or Government Entity) closes all business activities due to\nLiguidation. This Legal Entity Event always leads to the retirement of the LEl and the Legal Entity\nbecoming INACTIVE when the Legal Entity Event reached @event_status COMPLETED. Liquidation\ncan be the result of a Bankruptcy or of an Insolvency.\n\nThe LEl issuer managing the LEI Record Set of Legal Entity A SHALL:\n\no Retire the LEI Record Set of Legal Entity A, if @event_status is COMPLETED:\n\no Set RegistrationStatus to RETIRED.\n\no Set EntityStatus to INACTIVE.\n\no Set RegistrationStatus of all current Relationship Records to RETIRED with RelationshipStatus\nINACTIVE; set EndDate of RelationshipPeriod with PeriodType RELATIONSHIP_PERIOD as\nEffective Date of the LegalEntityEvent (see below).\n\no Create a new LegalEntityEvent with:\n\no @group_type SHALL be STANDALONE.\n\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\n\no @group_id SHALL be omitted.\n\no @group_sequence_no SHALL be omitted.\n\no LegalEntityEventType SHALL be LIQUIDATION.\n\no LegalEntityEventEffectiveDate SHALL be the date the LIQUIDATION becomes effective in the\nLegal Jurisdiction of Legal Entity A.\n\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\n\no If @event_statusis IN_PROGRESS or COMPLETED, the LEl issuer SHALL provide information\nregarding the AffectedFields: For @field_xpath the LEl issuer usually\no MAY provide lei:SuccessorEntity\n\nState Transition and Validation Rules for Common Data File formats Page 150 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2131,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.108Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Non-consolidating Non-consolidating\nException Exception\n%}T PARENT\\/ULTIMATE/PA\\RENT\n@\\?\nDIRECT PARENT\n@ EJ‘LTIMI/\\TE PARE;\\]T\n\\I: \\\"\\ ULTIMATE PARENT\nA ! ULTIMATE PARENT\nULTIMATE PARENT /\nDIRECT PARENT\nFigure 1: General view on one complete network chain and the representation of the Relationship Records to the\nultimate parent LEI.\nChild reporting (bottom-up) principle\nInitially only child entities may report level 2 data (the relationship information to their parent\nentities) to minimize difficulties arising from complex Business Rules dependent on the reporting\nentity and de-duplication. This also covers a parent entity instructing its child entity or entities to\nreport parent information, and also delegated reporting by a parent entity on behalf of any child\nentities.\nGiven this rule, reporting of child entities without an LEl is NOT possible under any circumstance.\nState Transition and Validation Rules for Common Data File formats Page 16 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1067,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.108Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.13.18 Legal Entity Event — Dissolution\nLegal Entity A (general Legal Entity of Government Entity) voluntarily closes all business activities.\nThis Legal Entity Event always leads to the retirement of the LElI and the Legal Entity becoming\nINACTIVE when the Legal Entity Event reached @event_status COMPLETED. This Legal Entity Event is\nhandled like Liquidation, except for the different Legal EntityEventType and the different expected\n@field_xpath.\nIn contrast to Liquidation, the LEl issuer managing the LEI Record Set of Legal Entity A SHALL create a\nnew LegalEntityEvent with:\no LegalEntityEventType SHALL be DISSOLUTION.\no If @event_status is IN_PROGRESS or COMPLETED, the LEl issuer SHALL provide information\nregarding the AffectedFields: For @field_xpath the LEl issuer usually\no MAY provide lei:SuccessorEntity\n4.13.19 Legal Entity Event — Voluntary Arrangement\nA company Voluntary Arrangement (CVA) allows a Legal Entity A (general Legal Entity or Government\nEntity) to negotiate with its creditors the settlement of any debts by paying only a portion of the\namounts owed or by some other arrangement to pay the debt. This Legal Entity Event does not lead\nto retirement of the LEL.\nThe LEl issuer managing the LEI Record Set of Legal Entity A SHALL:\no Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be VOLUNTARY_ARRANGEMENT\no @event_status SHALL be IN_PROGRESS.\no LegalEntityEventEffectiveDate SHALL be the date the CVA becomes effective in the Legal\nJurisdiction of Legal Entity A.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no AffectedFields SHALL be omitted.\nOnce the CVA is completed, the LEl issuer managing the LEI Record Set of entity A SHALL:\nState Transition and Validation Rules for Common Data File formats Page 151 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2068,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.108Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be COMPLETED\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be VOLUNTARY_ARRANGEMENT.\no LegalEntityEventEffectiveDate SHALL be the date the CVA becomes effective in the Legal\nJurisdiction of Legal Entity A.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no AffectedFields SHALL be omitted.\nState Transition and Validation Rules for Common Data File formats Page 152 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":675,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.109Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"O Voluntary Arrangement O\n_————’\nLEI A LEI A\nPre Event Post Event\nLEI A LEI A\nLegalEntityEvent: LegalEntityEvent:\no @group_type: STANDALONE o @group_type: STANDALONE\no @event_status: IN_PROGRESS o @event_status: IN_PROGRESS\no LegalEntityEventType: o LegalEntityEventType:\nVOLUNTARY_ARRANGEMENT_IN_PROGRESS VOLUNTARY_ARRANGEMENT_IN_PROGRESS\no LegalEntityEventEffectiveDate: [ ] o LegalEntityEventEffectiveDate: [ ]\no LegalEntityEventRecordedDate: o LegalEntityEventRecordedDate:\ne 2020-03-05T09:00:00+02:00 e 2020-03-05T09:00:00+02:00\no ValidationDocuments: CONTRACTS o ValidationDocuments: CONTRACTS\nLegalEntityEvent:\no @group_type: STANDALONE\no @event_status: COMPLETED\no LegalEntityEventType:\nVOLUNTARY_ARRANGEMENT\no LegalEntityEventEffectiveDate:\no 2020-04-19T00:00:00+02:00\no LegalEntityEventRecordedDate:\no 2020-04-20T09:00:00+02:00\no ValidationDocuments: CONTRACTS\nExample 18: Legal Entity LEI A engages in a company Voluntary Arrangement without any knowledge regarding the\nexpected effective date. The process of the Voluntary Arrangement was recorded in the Global LEI System on March 5,\n2020. The Voluntary Arrangement was completed on April 19, 2020. The completion of the Legal Entity Event was\nrecorded in the Global LEI System on April 20, 2020.\nState Transition and Validation Rules for Common Data File formats Page 153 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1452,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.109Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.13.20 Legal Entity Event — Reverse Takeover\nA Reverse Takeover describes the following scenario:\n1. Entity Bis acquired by entity A\n2. Entity Ais absorbed by B\n3. Entity B changes its LegalName to A\nThe result has a surviving entity with the original LegalName of entity A and the LEI of entity B. The\nLEI Record of entity A will be RETIRED and point to the LEI of entity B as SuccessorEntity.\nTo record this Legal Entity Event, the LEl issuer of entity A SHALL update the LEI Record as following:\no Set RegistrationStatus RETIRED.\no Set Legal Entity B as SuccessorEntity.\ne Set current relationships to RETIRED, if applicable.\no Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED, based on\nthe status of the event (see section 4.13.1).\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be MERGERS_AND_ACQUISITIONS.\n¢ LegalEntityEventEffectiveDate SHALL be the date the Reverse Takeover becomes effective in\nthe Legal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\n¢ ValidationDocument and the optional ValidationReference SHALL indicate the sources used\nfor validating the Legal Entity Event.\no If @event_statusis IN_PROGRESS or COMPLETED, the LEl issuer SHALL provide information\nregarding the AffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide lei:SuccessorEntity\nThe LEl issuer of entity B SHALL record the Reverse Takeover event as a group of three events, linked\ntogether and set in the correct sequence order:\n¢ Create a new LegalEntityEvent with:\no @group_type SHALL be REVERSE_TAKEOVER.\nState Transition and Validation Rules for Common Data File formats Page 154 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1935,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.109Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be a unique identifier (e.g., a hash value calculated from the combination\nof the LEl, EventType and EffectiveDate).\no @group_sequence_no SHALL be 1 (one).\no LegalEntityEventType SHALL be MERGERS_AND_ACQUISITIONS.\n¢ LegalEntityEventEffectiveDate SHALL be the date the Reverse Takeover becomes effective in\nthe Legal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\n¢ ValidationDocument and the optional ValidationReference SHALL indicate the sources used\nfor validating the Legal Entity Event.\no AffectedFields SHALL be omitted.\ne Create a new LegalEntityEvent with:\no @group_type SHALL be REVERSE_TAKEOVER.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be the same unique identifier used for the previous event.\no @group_sequence_no SHALL be 2 (two).\no LegalEntityEventType SHALL be ABSORPTION.\no LegalEntityEventEffectiveDate SHALL be the same date as for the previous event.\no LegalEntityEventRecordedDate SHALL be the same date as for the previous event.\n¢ ValidationDocument and the optional ValidationReference SHALL indicate the sources used\nfor validating the Legal Entity Event.\no AffectedFields SHALL be omitted.\no Create a new LegalEntityEvent with:\no @group_type SHALL be REVERSE_TAKEOVER.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be the same unique identifier used for the previous event.\no @group_sequence_no SHALL be 3 (three).\no LegalEntityEventType SHALL be CHANGE_LEGAL_NAME.\nG State Transition and Validation Rules for Common Data File formats Page 155 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1855,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.109Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o LegalEntityEventEffectiveDate SHALL be the same date as for the previous event.\no LegalEntityEventRecordedDate SHALL be the same date as for the previous event.\n¢ ValidationDocument and the optional ValidationReference SHALL indicate the sources used\nfor validating the Legal Entity Event.\no If @event_statusis IN_PROGRESS, the LEl issuer SHALL provide information regarding the\nAffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide lei:LegalName\no MAY provide lei:OtherEntityNames\no MAY provide lei:TransliteratedOtherEntityNames\n¢ The LegalName of LEI B SHALL change to LegalName of LEI A.\nState Transition and Validation Rules for Common Data File formats Page 156 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":796,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.109Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"1 Acquired by\nA/Z/-\\bs;edby\\\n_—mmm\nS S\nLEI A LEI B\nEntity: Entity:\no “SuccessorEntity: LEI B” o LegalName: “Company B.V.“\no LegalName: Company B.V.\nLegalEntityEvent:\nRegistration: o @group_type: REVERSE_TAKEOVER\no RegistrationStatus: RETIRED o @event_status: COMPLETED\no @group_id: dfecd444f23463443a98n12a\nRelationship: o @group_sequence_no: 1\n* Remove ReportingExceptions o LegalEntityEventType:\no lastUpdateDate: 2020-04-20T13:43:25+02:00 MERGERS_AND_ACQUISITIONS\no LegalEntityEventEffectiveDate:\nRelationship Registration: © 2020-04-19T00:00:00+02:00\n* RegistrationStatus: RETIRED o LegalEntityEventRecordedDate:\no 2020-04-20T00:00:00+02:00\nLegalEntityEvent: « ValidationDocuments: ACCOUNTS_FILING\no @group_type: STANDALONE\no @event_status: COMPLETED LegalEntityEvent:\n© LegalEntityEventType: o @group_type: REVERSE_TAKEOVER\nMERGERS_AND_ACQUISITIONS s @event_status: COMPLETED\n© LegalEntityEventEffectiveDate: + @group_id: dfecd444f23463443a98n12a\n© 2020-04-19T00:00:00+02:00 « @group_sequence_no: 2\n© LegalEntityEventRecordedDate: + LegalEntityEventType: ABSORPTION\n¢ 2020-04-20T11:30:00+02:00 » LegalEntityEventEffectiveDate:\no ValidationDocuments: ACCOUNTS_FILING s 2020-04-19T00:00:00+02:00\no ValidationReference: Consolidated financial + LegalEntityEventRecordedDate:\nstatement o 2020-04-20T11:30:00+02:00\no ValidationDocuments: ACCOUNTS_FILING\nAffectedFields:\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:E LegalEntityEvent:\nntity/lei:SuccessorEntity/lei:SuccessorLEl: « @group_type: REVERSE_TAKEOVER\nLEI B + @event_status: COMPLETED\no @group_id: dfecd444f23463443a98n12a\no (@group_sequence_no: 3\no LegalEntityEventType: CHANGE_LEGAL_NAME\no LegalEntityEventEffectiveDate:\no 2020-04-19T00:00:00+02:00\no LegalEntityEventRecordedDate:\ne 2020-04-20T11:30:00+02:00\no ValidationDocuments: ACCOUNTS_FILING\nExample 19: Reverse Takeover\nState Transition and Validation Rules for Common Data File formats Page 157 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2050,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.109Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.13.21 Legal Entity Event — Transformation of an Umbrella Fund to a Stand-Alone\nFund\nWhen an umbrella fund A is converted into a stand-alone fund, all sub-funds/compartments of\numbrella fund A (fund entities with a IS_SUBFUND_OF relationship with umbrella fund A) are either\nmerged into umbrella fund A or need to be separated from umbrella fund A with a different Legal\nEntity Event recorded for the sub-fund(s). This Use Case assumes, that all (remaining) sub-funds are\nmerged into the umbrella fund prior to the conversion.\nThe LEl issuer managing the LEI Record Sets of any sub-fund of umbrella fund A SHALL:\ne Set the sub-fund relationship to RETIRED.\no Set the RegistrationStatus of each sub-fund to RETIRED.\no Set the umbrella fund as SuccessorEntity.\nThe LEl issuer managing the LEl Record Sets of umbrella fund entity A SHALL:\no Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED, based on\nthe status of the event (see section 4.13.1).\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be TRANSFORMATION_UMBRELLA_TO_STANDALONE.\no LegalEntityEventEffectiveDate SHALL be the date the transformation becomes effective in\nthe Legal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no If @event_statusis IN_PROGRESS or COMPLETED, the LEl issuer SHALL provide information\nregarding the AffectedFields: For @field_xpath the LEl issuer usually\no MAY provide lei:SuccessorEntity\n4.13.22 Legal Entity Event — Effects on parent and child relationships\nA Legal Entity Event applied to a Legal Entity can also affect all relationships where the entity is the\nEndNode (parent). Several cases have already been described above. In addition, there is need to\nlook at cases if the parent Legal Entity is RETIRED and hence no longer active or if a Legal Entity that\nwas an ultimate parent has been acquired and now has parent relationships.\nState Transition and Validation Rules for Common Data File formats Page 158 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2246,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.109Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"As soon as the LEl issuer of any child Legal Entity is aware of the retirement of the parent, the LEI\n\nissuer SHALL:\n\no Update all affected relationships to RETIRED.\n\no Create new Relationship Records or reporting exceptions, as applicable.\n\ne The LEl issuer of the child entity works with the child Legal Entity to record the new direct or\nultimate parent Legal Entity relationship.\n\nThe LEl issuer of the child Legal Entity can be informed about the change in the parent’s\n\nRegistrationStatus either\n\no by the child Legal Entity at the time of renewal,\n\n* viathe challenge process\n\ne orduring the course of normal business operations\n\nGiven the LEl issuer of the parent Legal Entity becomes aware of this change to the parent Legal\n\nEntity via the challenge process or during the course of normal business, the LEl issuer should notify\n\nthe LEl issuer of the child Legal Entity and request the LEl issuer of the child Legal Entity to provide\n\nupdated information on the direct or ultimate parent Legal Entity.\n\no If the child Legal Entity has active Relationship Records with rr:RegistrationStatus PUBLISHED or\n\nLAPSED reported, these are updated as follows:\n\no RelationshipStatus SHALL be INACTIVE.\n\no rr:RegistrationStatus SHALL be RETIRED.\n\no RelationshipPeriods with PeriodType RELATIONSHIP_PERIOD SHALL have EndDate populated\nwith the date the parent Legal Entity ceased to exist (same as the\nLegalEntityEventEffectiveDate that retired the parent Legal Entity).\n\no Relationship Records that are already RETIRED, DUPLICATE or ANNULLED are not updated.\n\no The LEl issuer of the child Legal Entity creates a new set of relationship data for the direct and/or\n\nultimate parent Legal Entity based on the updated information.\n\nFor an International Branch relationship, if the (head office) Legal Entity it belongs to merges or\n\nretires and is no longer active, the LEI Record Set of a Branch needs to be updated as well. Either the\n\n(head office) Legal Entity or the International Branch notifies their LEIl issuer at the time of renewal,\n\nthe LEl issuer is made aware via the challenge process, or the LEl issuer becomes aware of the (head\nState Transition and Validation Rules for Common Data File formats Page 159 of 170\n\n@ Public Version 2.7.1 Final\n\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2328,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.109Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"office) Legal Entity retiring during the course of normal business. The LEl issuer of the International\nBranch SHALL change the Branch entity’s LElI Record Set to the RegistrationStatus of RETIRED to have\nthe same status as the (head office) Legal Entity (see above Use Cases 4.8.1 or 4.8.2 respectively).\n4.13.23 Legal Entity Event — Erroneously introduced Legal Entity Event\nIf a Legal Entity Event has been falsely introduced to the LEI Repository, the LEl issuer SHALL:\ne Continue uploading the erroneously introduced Legal Entity Event\no Create an additional Legal Entity Event with:\no @event_status WITHDRAWN_CANCELLED\no LegalEntityEventRecordedDate representing the date the event was cancelled\no All remaining reference data shall be identical to the erroneously introduced legal entity\nevent\nState Transition and Validation Rules for Common Data File formats Page 160 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":986,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.109Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"With the exception of branches, all Legal Entities SHALL report relationship data for both direct and\nultimate accounting consolidating parent. Each relationship SHALL be reported by either a\nRelationship Record or a Reporting Exception Record. See Figure 1 for possible combinations.\nOnly one parent Legal Entity per child may be reported per unique relationship type with published\nregistration status. Direct and ultimate parent can be the same Legal Entity, still the child reports one\nrelationship of each type. The parent entity can be represented by:\ne an LEl for those parent Legal Entities with an LEI;\no an exception with exception reason NO_LEl in case the parent Legal Entity does not have an LEI.\nDIRECT PARENT\\/ULHMATE PARENT DIRECT Pw PARENT\na) b)\nDIRECT PARENTVULTIMATE PARENT DIRECT PARENT\\/ ULTIMATE PARENT\nc) .H d) ‘a\nState Transition and Validation Rules for Common Data File formats Page 17 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1020,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.109Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"O Remediation of an incorrectly reported event O\nIntroduction of incorrect event Resolved incorrect event\nLEI A LEI A\nRegistration: Registration:\no RegistrationStatus: RETIRED o RegistrationStatus: ISSUED\no LastUpdateDate: 2020-01-23T08:41:00+02:00 o LastUpdateDate: 2020-01-25T10:42:00+02:00\nLegalEntityEvent: LegalEntityEvent:\no @group_type: STANDALONE o @group_type: STANDALONE\no @event_status: COMPLETED o @event_status: COMPLETED\no LegalEntityEventType: DISSOLUTION o LegalEntityEventType: DISSOLUTION\no LegalEntityEventEffectiveDate: o LegalEntityEventEffectiveDate:\ne 2020-01-20T00:00:00.000Z e 2020-01-20T00:00:00.000Z\no LegalEntityEventRecordedDate: o LegalEntityEventRecordedDate:\no 2020-01-23T08:41:00+02:00 o 2020-01-23T08:41:00+02:00\no ValidationDocuments: o ValidationDocuments:\nSUPPORTING_DOCUMENTS SUPPORTING_DOCUMENTS\no ValidationReference: o ValidationReference:\nhttp://registry.gov/evidence.pdf http://registry.gov/evidence.pdf\nLegalEntityEvent:\no @group_type: STANDALONE\no @event_status: WITHDRAWN_CANCELLED\no LegalEntityEventType: DISSOLUTION\no LegalEntityEventEffectiveDate:\ne 2020-01-20T00:00:00.000Z\no LegalEntityEventRecordedDate:\ne 2020-01-25T10:42:00+02:00\no ValidationDocuments:\nSUPPORTING_DOCUMENTS\no ValidationReference:\nhttp://registry.gov/evidence.pdf\nExample 20: LEI A was erroneously set to RETIRED on 23 January 2020 and a Legal Entity Event with LegalEntityEventType\nDISSOLUTION was introduced. The LEl issuer acknowledged the incorrect Legal Entity Event on 25 January 2020 and\ncreated an additional Legal Entity Event with @event_status WITHDRAWN_CANCELLED to indicate that the previously\nrecorded Legal Entity Event was incorrect. The RegistrationStatus of the LEI Record returns to ISSUED.\nState Transition and Validation Rules for Common Data File formats Page 161 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1920,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.109Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.14 Update of LEI Reference Data other than due to Legal Entity\nEvents\nThe Reference Data of an LEI Record Set may change without the occurrence of specific Legal Entity\nEvents, for instance due to data updated by the Legal Entity or challenged data. The LEl issuer is\nresponsible to verify changed or challenged Reference Data. If the LEl issuer is ultimately unable to\nfully corroborate Reference Data updated or confirmed by the Legal Entity, the Validation Sources\nmust change to PARTIALLY CORROBORATED or ENTITY_SUPPLIED_ONLY.\nWhenever an element of the Reference Data is updated, the respective LastUpdateDate (LEI Record\nor Relationship Records) SHALL be updated with the current date and time as well.\n4.15 LEI Record update — Registration information changes\nThis Use Case only applies where the registration information changes, and the Legal Entity remains\nan operating entity. Usually, this would happen as part of a Legal Entity Event (e.g.: legal form\nchange), but the registration information change does not trigger a Legal Entity Event itself.\nThe LEl issuer:\no SHALL update lei:RegistrationAuthority accordingly, following the general rules for Registration\nAuthority Reporting (see section 2.2.3).\no SHALL check, if an update to lei:ValidationAuthority, lei:ValidationOtherAuthorities and/or\nlei:ValidationSources is required.\nThis also includes cases where a non-reserved Registration Authority code is supplied for the first\ntime (see section 2.2.3 for the Transition Rules after an RA list update).\n4.16 LEI Record update — Reporting Exception changes to\nRelationship Records\nThis Use Case applies where the child Legal Entity reports a parent Legal Entity after initial opt-out\nreporting.\nThe LEl issuer:\no SHALL create the applicable Relationship Record(s) according to Use Cases 4.1.1 and/or 4.1.2.\ne SHALL remove the superseded reporting exception record(s) from publication.\nIf the ExceptionReason was NO_LEI, Use Case 4.11 applies instead.\nState Transition and Validation Rules for Common Data File formats Page 162 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2153,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.109Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.17 LEI Record Set update — Entity or Relationship Data changes\n\nThis Use Case applies where any data element in the entity data or the Relationship data or a\n\nreporting exception changes that is not the result of one of the other Use Cases (usually, this is only\n\nnecessary to amend registration or validation errors).\n\nThe LEl issuer:\n\ne SHALL update the respective data element(s) accordingly.\n\ne SHALL not make any additional changes, except for updating LastUpdateDate.\n\n4.18 LEI Record Set update — Change of fund manager\n\nThis Use Case applies when the management of a fund entity changes from fund manager with LEI A\n\nto fund manager with LEI B and the fund entity itself is still active.\n\nThe LEl issuer:\n\ne SHALL set the rr:RegistrationStatus of the fund relationship record with EndNodelD LEI A to\nRETIRED. The EndDate of the RelationshipPeriod with PeriodType RELATIONSHIP_PERIOD SHALL\nbe the date of the change.\n\ne SHALL introduce a new fund relationship record with rr:RegistrationStatus PUBLISHED with\nEndNodelD LEI B. The StartDate of the RelationshipPeriod with PeriodType\nRELATIONSHIP_PERIOD SHALL be the date of the change.\n\n4.19 LEI Record Set update — Transfer\n\nA Legal Entity's LEI Record can be transferred from one LEl issuer to another. All Relationship Records\n\n(active and inactive) are also transferred. The following sections describe the updates to the LEI\n\nRecord Set only. For details on timelines and responsibility, refer to the Supporting Documentation\n\nfor Transfers.\n\nIn general, only LEI Record Sets representing operational Legal Entities can be transferred\n\n(RegistrationStatus ISSUED or LAPSED). In rare cases, LEI Record Sets representing inactive Legal\n\nEntities (RegistrationStatus RETIRED) and even invalid records (RegistrationStatus DUPLICATE or\n\nANNULLED) will transfer from one LEl issuer to another. In such cases the Receiving LOU should\n\nprovide an explanation to the Sending LOU (e.g.: the closure of one LEl issuer).\n\nA transfer is initiated after the request from the Legal Entity by the Receiving LOU. The Receiving LOU\n\ninforms the Sending LOU about the transfer request, providing evidence for the authorization of the\n\nrequestor. The Sending LOU confirms the transfer with their contact to the Legal Entity. If no\nresponse from the Legal Entity can be received within the timeframe defined in supporting transfer\nprotocol documentation, the Sending LOU SHALL accept the transfer request.\nState Transition and Validation Rules for Common Data File formats Page 163 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2632,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.109Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Sending LOU Perspective:\n\nWhen the Sending LOU receives the transfer request, the LEI Record Set is updated as follows:\n\no lei:RegistrationStatus SHALL be PENDING_TRANSFER.\n\no rr:RegistrationStatus SHALL be PENDING_TRANSFER for all Relationship Records.\n\nWhen the Sending LOU confirms the transfer request and verifies that the updated\n\nRegistrationStatus is displayed in the Golden Copy, the LEI Record Set is updated as follows:\n\no lei:RegistrationStatus SHALL be PENDING_ARCHIVAL that was PENDING_TRANSFER before.\n\no rr:RegistrationStatus SHALL be PENDING_ARCHIVAL for all Relationship Records that were\nPENDING_TRANSFER before.\n\nThe Sending LOU verifies in the Golden Copy Files, generated by GLEIF, that its own LEI Record Set is\n\ndisplayed as PENDING_ARCHIVAL. After the Receiving LOU’s LEI Record Set is published in the Golden\n\nCopy, the Sending LOU updates their LElI Record Set as follows:\n\no lei:RegistrationStatus SHALL be TRANSFERRED that was PENDING_ARCHIVAL before and\nremoved from files uploaded to GLEIF.\n\no rr:RegistrationStatus SHALL be TRANSFERRED for all Relationship Records that were\nPENDING_ARCHIVAL before and removed from files uploaded to GLEIF.\n\ne All remaining Relationship Records and all Reporting Exception Records are removed from files\nuploaded to GLEIF.\n\nReceiving LOU Perspective:\n\nThe Receiving LOU validates all LEI Reference Data during transfer and once the Sending LOU\n\npublishes the LEI Record with RegistrationStatus PENDING_ARCHIVAL, the Receiving LOU SHALL\n\npublish a complete set of entity and relationship data, including historical and/or internal\nrelationships:\n\no lei:RegistrationStatus SHALL be ISSUED, unless, in very rare cases, the LEI Record was RETIRED,\nDUPLICATE or ANNULLED prior to the transfer request, in which case, the original\nRegistrationStatus is retained; the Receiving LOU SHALL NOT publish the LElI Record with\nRegistrationStatus LAPSED after the transfer is completed, even if that was the recorded status\npublished by the Sending LOU. All LAPSED LEIs SHALL be renewed during transfer.\n\nState Transition and Validation Rules for Common Data File formats Page 164 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2241,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.109Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o rr:RegistrationStatus SHALL be PUBLISHED for all ACTIVE Relationship Records; INACTIVE\nRelationship Records that were ANNULLED by the Sending LOU are retained with the\nRegistrationStatus they had prior to the transfer; the Receiving LOU SHALL keep historical\nRelationship Records unchanged except for amending data quality issues (e.g.: due to missing\nRelationshipPeriods).\n\no InitialRegistrationDate for all LEI Record Sets SHALL NOT be updated but retained as it was\nbefore the transfer (adapting to a different time zone is accepted but not required).\n\nFigure 10 further clarifies the transfer protocol. Each row represents a time unit, e.g., one business\n\nday.\n\nState Transition and Validation Rules for Common Data File formats Page 165 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":852,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.109Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Receiving LOU Sending LOU\nInitiation of Transfer\nThe Legal Entity informs its new\nmanaging LOU (Receiving LOU)\nrequesting a transfer. The LOU O\ncontacts the current managing LOU [RSUET, LACRED]\n(Sending LOU) and triggers a LEIA\ntransfer.\nO\\ PENDING_\nLEIA TRANSFER\nThe Sending LOU sends confirmation of the\nLEI Transfer request back to the Receiving\nLOU. The Sending LOU notifies the Legal\nEntity that the transfer will occur after 3\nbusiness days, if no objection is received.\nThe Transfer Objection Form is attached to\nthe notification.\nO\\ PENDING_\nLEIA ARCHIVAL\nThe Sending LOU receives\nconfirmation from the Legal Entity or\nthe Legal Entity has not responded\nwithin 3 business days.\nLEIA\nO\\ PENDING _\nThe Receiving LOU validates the LEIA ARCHIVAL\nmost recent data of the LEI Record\nSet and publishes the record.\nThe Sending LOU stops publishing\nthe LEI Record Set after the LEI\nO— Record Set appears in the Golden\nLEIA Copy Files generated by GLEIF with\nManagingLOU = Receiving LOU.\nTransfer Completed\nFigure 10: Exemplary timeline of an LEI transfer\nState Transition and Validation Rules for Common Data File formats Page 166 of 170\nGLEIF) Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1243,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.109Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.20 Registration errors — Exclusivity Violation (duplication)\nIf a Legal Entity has more than one LEI, the Legal Entity SHALL choose which LEI Record Set survives.\nIf the contact point for both LEls is non-responsive, then the earliest LEI survives. The DUPLICATE\nstatus is assigned to the non-surviving registration (i.e. the LEI that should no longer be used).\no lei:RegistrationStatus SHALL be DUPLICATE\ne SuccessorLElI SHALL be the LEI of the surviving registration\no for Branch entities, the survivor SHALL be another Branch entity in the same host jurisdiction; if\nthe Branch entity was registered in the same jurisdiction as the head office, lei:RegistrationStatus\nSHALL be ANNULLED instead (see Use Case 4.17 Registration error — Eligibility violation)\no rr:RegistrationStatus SHALL be ANNULLED for all relationships\nIf a parent Legal Entity (i.e.: the entity represented by the EndNodelD of a Relationship Record) is a\nduplicate, the LEl issuer of the child Legal Entity adjusts all not ANNULLED Relationship Records with\nthis parent Legal Entity as EndNote as follows:\no rr:RegistrationStatus of existing Relationship Records SHALL be ANNULLED\n¢ new Relationship Records SHALL be created with the surviving parent Legal Entity’s LEIl as\nEndNodelD\n4.21 Registration error — Relationship Record or reporting exception\nis a duplicate\nA child LEI record SHALL have only a maximum of one relationship data set of each type at a time. If\nthere is more than one published at the same time, duplicate Relationship Records exist. There are\nthree ways, duplicate Relationship Records can be introduced:\n* More than one ACTIVE Relationship Record with the exact same StartNode, same\nRelationshipType but different EndNodes are published, or\n* More than one Relationship Record with the exact same StartNode, same RelationshipType,\nsame EndNode and same StartDate for PeriodType RELATIONSHIP_PERIOD is published.\ne One ACTIVE accounting consolidation parent relationship is published together with a\ncorresponding reporting exception for the same parent (direct/ultimate).\nState Transition and Validation Rules for Common Data File formats Page 167 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2256,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.110Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"For the first case, the LEl issuer SHALL determine which Relationship Record is correct currently; all\nother duplicate records need to be set either to INACTIVE, if they represent no longer current\nrelationships, or to ANNULLED, if they were created erroneously.\n\n4.22 Registration error — Eligibility violation (invalid LEl issuance)\n\nIf an LEI registration is identified as erroneous or invalid after it is issued, the LEl issuer SHALL set the\n\nrecord to an ANNULLED state but keep it as published records in the Global LEI System to support the\n\nhistorical record and to provide resolution to any external query of the LEI. If the record represented\n\na parent Legal Entity (i.e.: is the EndNode in a Relationship Records), the LEl issuer of the child Legal\n\nEntity SHALL update all affected relationships as if the parent were a duplicate (see section 4.20).\n\n4.23 Issue New LEI for an US company incorporated in one state but\n\noperating in another\n\nIn the US, the state where a company is incorporated may not necessarily be the state where the\n\ncompany has its main base of operations. When a Legal Entity incorporated in the US is requesting a\n\nnew LEI code, in addition to or differing from section 4.1, the LEl issuer:\n\nSHALL validate and publish at least the following:\n\no RegistrationAuthority SHALL be the register where the entity is incorporated.\n\no Legallurisdiction SHALL match with the state of incorporation.\n\no EntityLegalFormCode SHALL match with Legallurisdiction.\n\no LegalAddress SHALL be the address displayed in the RegistrationAuthority.\n\ne HeadquartersAddress SHALL be the main location of business operations.\n\no If the entity is registered with a business name or as a foreign company in the state where the\nheadquarters are located, this registration SHALL be included in the ValidationAuthority or in\nOtherValidationAuthorities.\n\n¢ ValidationSources SHALL be FULLY_CORROBORATED, if all relevant elements can be\ncorroborated via the provided ValidationAuthority and OtherValidationAuthorities; it SHALL be\nPARTIALLY_CORROBORATED if not all relevant elements can be corroborated.\n\nState Transition and Validation Rules for Common Data File formats Page 168 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2292,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.110Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.24 Issue New LEI - Financial institution in the US\n\nBanks, credit unions, and other financial institutions in the US can be chartered on a state level or on\n\na federal level and are subject to regulations and supervision from multiple governmental\n\nauthorities. When a new LEl is requested for financial institution in the US (e.g., National Banks and\n\nFederal Savings Associations, State Banks, Credit Unions, Bank Holding Companies, Edge Act\n\nCorporations), in addition to or differing from section 4.1, the LEl issuer:\n\no SHALL consult the FDIC’s “BankFind Suit”, the FFIEC’s NIC institution search, the OOC's list of\nfinancial institutions, or the NCUA’s “Research a Credit Union Tool” and determine if the LEI\napplicant is a National Bank, Federal Savings Association, Federal Credit Union, or a state-\nchartered institution.\n\nIf the LEl applicant is chartered on a federal level, following rules apply:\n\no Legallurisdiction SHALL be US.\n\no EntityLegalForm SHALL be an ELF code assigned on federal (US) level representing the respective\ntype of financial institution (e.g., “62VJ” for National Bank).\n\no The LEl issuer SHALL determine under which authority the entity is chartered and populate the\nrespective RA code as RegistrationAuthoritylD\n\no RegistrationAuthorityEntitylD SHALL be the local identifier representing the entity; it SHALL be\nthe ‘native’ identifier assigned by that authority (e.g., the OCC’s charter license number) as some\nalso provide identifiers assigned by other authorities (e.g., FDIC certificate number).\n\n¢ ValidationAuthoritylD SHALL be one of the authorities consulted to determine that the entity is\nfederally chartered (FDIC, OCC, FFIEC, or NCUA). Having a different authority than in\nRegistrationAuthoritylD MAY support the identification of potential duplicates.\nValidationAuthorityEntity|D SHALL be the ‘native’ entity identifier assigned by that authority.\n\no OtherValidationAuthorities MAY be included to refer to further authorities (e.g., local business\nregister) used for the corroboration of the reference data.\n\nIf the LEIl applicant is chartered on a state level, the following rules apply:\n\no Legallurisdiction SHALL be the state where the state-chartered institution is chartered.\n\no EntityLegalForm SHALL be the Legal Form code that best describes the nature of the financial\ninstitution using the relevant ELF codes for that state.\n\no The LEl issuer SHALL determine under which authority the entity is chartered and populate the\nrespective RA code as RegistrationAuthoritylD\n\no RegistrationAuthorityEntitylD SHALL be the local identifier representing the entity; it SHALL be\nthe ‘native’ identifier assigned by that authority.\n\nState Transition and Validation Rules for Common Data File formats Page 169 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2866,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.110Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"¢ ValidationAuthoritylD SHALL be one of the authorities consulted to determine that the entity is\nstate-chartered (FDIC, OCC, FFIEC, or NCUA). ValidationAuthorityEntitylD SHALL be the ‘native’\nentity identifier assigned by that authority.\ne OtherValidationAuthorities MAY be included to refer to further authorities (e.g., local business\nregister) used for the corroboration of the reference data.\nState Transition and Validation Rules for Common Data File formats Page 170 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":582,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.110Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Figure 2: Examples for level 2 declaration within an LEI Record Set - a) describes the expected Use Case of an LEI A\ndeclaring two different LEls as direct and ultimate parent; b) LEI A declares same LEI B as direct and ultimate parent by\nproviding two separated Relationship Records; c) LEI A declares an LEI B as direct parent and an exception (e.g., NO_LEI)\nfor its ultimate parent relationship; d) LEI A declares two exceptions.\nA child Legal Entity SHALL never have an accounting consolidation parent or branch relationship with\nitself; the LEI identifying the parent must be different from the LEI identifying the child entity.\nReporting accounting consolidating direct and ultimate parent is mandatory for all Legal Entities with\nthe exception of branches (see below). In cases where the Legal Entity has declined to provide the\nmandatory reporting of a specified type of relationship information (direct or ultimate parent), the\nreason is explicitly declared in relationship Reporting Exception Record. This information is reported\nat the time of LEl Issuance, LEI Renewal, or LEl Transfer, whichever happens first.\nExceptions are reported as provided by the Legal Entity. The LOU creates a reporting exception\ninstead of a Relationship Records. The LOU SHALL remove the exception record given:\no the child subsequently reports the respective direct or the ultimate parent.\n¢ the child entity subsequently ends (LEI RegistrationStatus of RETIRED, ANNULLED, or DUPLICATE).\no after a transfer to another LOU has been completed.\nException reason reporting\nIn the case that a Legal Entity is aware that it has a relationship of the relevant type but withholds\nthe details due to legal concerns, the Legal Entity SHALL provide an opt out reason NON_PUBLIC.\nReasons are recorded in a manner specified by the LEI-ROC and reported in the Reporting Exception\nRecords file. No relationship information SHALL be recorded by the LEl issuer. The opt out reason is\ncollected as part of the LEl Record of the reporting entity. As noted by the LEI-ROC, it would be the\nprerogative of any competent regulator requiring this information to determine whether the opt out\nwas justified.\nNon-consolidating exceptions have one of the following reasons: NATURAL_PERSONS,\nNON_CONSOLIDATING or NO_KNOWN_PERSON. This group of exceptions can only be assigned to\nboth parents or to neither of them and never in combination with an active relationship or another\nexception reason indicating that an unreported accounting consolidation relationship exists.\nNo parent according to the definition used\nIf the Legal Entity reports that it has no accounting consolidating parent relationships, this\ninformation is collected and reported in the Reporting Exception Records file.\nParent without LEI\nIn the case that one or both Relationship Records include a parent without an LEl, this information is\nalso reported in the Reporting Exception Records file for publication.\nState Transition and Validation Rules for Common Data File formats Page 18 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":3128,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.110Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Resolving parentage conflicts\n\nParentage conflicts describe situations where the reported relationship information for direct and\n\nultimate parent is not consistent with the definition of parent relationships based on accounting\n\nconsolidation or if the declared ultimate parent is not a viable candidate for being an ultimate\nparent.\n\nCommon reasons for inconsistent information:\n\no Declared ultimate parent has parents: the ultimate parent has public parent relationships.\n\no Declared ultimate parent has incorrect exceptions: the ultimate parent SHALL have exactly 2\nexceptions — one for its direct and one for its ultimate parent — with proper exception reasons\n(NATURAL_PERSONS, NON_CONSOLIDATING, NO_KNOWN_PERSON). Reporting Exception\nRecords with other reasons are inconsistent to being declared as an ultimate parent.\n\no Declared ultimate parent has at least one public Reporting Exception Record with reason NO_LEI.\n\no Declared ultimate parent is inactive, or LEl record is invalid: the RegistrationStatus of the\nultimate parent's LEl record is RETIRED, MERGED , DUPLICATE or ANNULLED.\n\no Declared ultimate parent is an International Branch: the ultimate parent can never be defined as\na BRANCH.\n\nIn case of inconsistent information, the LEl issuer SHALL confirm the relationship information of the\n\nLEI record managed by them (can be the child Legal Entity, the declared ultimate parent or both).\n\nThis also can involve contacting the involved Legal Entities but the most up to date consolidated\n\nfinancial statements remain the primary source for validating Level 2 data. If the current information\n\nis found to be incorrect, the LEl issuer SHALL update the relationship information accordingly. If the\ncurrent information is confirmed as correct, the LEl issuer SHALL approach the other LEl issuer(s)\ninvolved by raising a challenge and providing evidence of how the data should be corrected. At this\nstage, the LEl issuer MAY publish the record even if the parentage conflict has not been resolved.\n\nChallenges MAY be raised using GLEIF's Challenge Facility integrated in LEI Search on GLEIF website?.\n\nThe other LEl issuer then re-validates their record(s) and responds to the challenge accordingly. If the\n\nchallenge is not accepted, both LEl issuers need to discuss this matter further with all involved\n\nparties.\n\nBranch relationships\n\nBranches are part of the same legal person as their head office, and can be described as different\n\nestablishments, or locations, of the same corporate entity, whereas a Subsidiary is a legal person\n\ndistinct from its parent. However, International Branches may have independent requirements for\nregulatory reporting and are therefore eligible for their own LEls. A Branch relationship describes the\nrelationship between an International Branch and its head office. The Branch LEI MAY represent\n\n2 https://search.gleif.org/\n\nState Transition and Validation Rules for Common Data File formats Page 19 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":3061,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.110Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"multiple offices or locations of a Legal Entity in a host country jurisdiction. The Legal Entity SHALL\n\nprovide the address information and additional Reference Data of the Branch. A Branch SHALL NOT\n\ndeclare a direct or ultimate accounting consolidating parent relationship or report exceptions.\n\nFund relationships\n\nFor Fund entities the following three relationship types are available (see section 3.50):\n\n¢ Fund Management Entity: A Legal Entity that is considered as the main management entity of a\nfund when it is legally responsible for the constitution and operation of the fund. Such\nresponsibility will include the day-to-day management of a fund's investments and management\nof a fund’s risks, or the appointment of others for that purpose. In the latter case, the entity to\nwhich these functions may have been delegated is not considered to be a Fund Management\nEntity. The Fund Management Entity can be the fund itself, if the fund is self-managed. In this\ncase there MAY be a relationship for which StartNode and EndNode are populated with the LEI of\nthe fund.\n\no Umbrella Structures: An Umbrella Structure is a Legal Entity with one or more than one sub-\nfunds/compartments where each sub-fund/compartment has its own investment objectives,\nseparate investment policies and strategies, segregation of assets, separate investors and which\nhas segregated liability between sub-funds/compartments. U.S. Series Funds and Japanese “non-\ninvestment management funds” are to be identified as Umbrella Structures in the Global LEI\nSystem.\n\no Master-Feeder: A relationship, where a Feeder Fund is exclusively, or almost exclusively, invested\nin a single other fund (e.g., U.S, EU UCITS), or several funds that have identical investment\nstrategies (for the latter, provided this situation is qualified as a Master-Feeder Relationship\nunder the applicable laws and regulations, e.g., some alternative investment funds in the EU)\nreferred to as a Master Fund (or Master Funds). It is clarified that this covers only cases where\nthis relationship is organized in the legal documentation of the feeder fund and does not cover\nrelationships where a fund’s assets are invested in multiple other funds (fund of fund structure).\n\nThe collection of new fund relationships in the Global LEI System SHALL be mandatory:\n\na) If the relationship is mandated to be reported and publicly available in the relevant\njurisdiction AND if the LEl is mandatory for the related entity in the relevant jurisdiction\n\nb) For the relationship between an Umbrella Structure and a sub-fund or compartment or other\nsub-structure.\n\nIn all cases where a fund relationship is reported, StartNode and EndNode of the relationship SHALL\n\nbe LEI codes.\n\nState Transition and Validation Rules for Common Data File formats Page 20 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2906,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.110Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.12 Transliterated Other Entity Names.....cccccevvvviiieiiinniiiiiieeccciiiece e ssssiieeeeen 44\n3.13 Legal AQAIESS ...vvuieeeiiiieeeeereiiitte e srte e etrrr e e s e ssrire e ee s s s saibeaae e s s sananeeessnsnnneeaesenes 4D\n3.14 Headquarters AdAreSS ......ccuvuviieeiiiiiiiieeeesiiiieee e esssiieeeessssiiesesessssnnseesssssssnseeessnns 40\n3.15 Other AdAreSSES ..ceeivviieeee ittt eeesie e e e s esssireeee s sasieeae e s s snnaneeessnsnsnseeessnsn BT\n3.16 Transliterated Other Addresses.......cvviviviiiiiviiee e essiieee e seveeeessssnnneee e 47\n3.17 Registration AULNOIILY ..ccciiiiiiiiieiiiiciiiececie e ssnnneee e 48\n3.18 Registration AUthOrIty ID ...cccvveiiiiiiiiiieeie e e s ssnnneee e 49\n3.19 Other Registration AUthOrity ID.......cccceeeviiiiiiiee s ssieneee 0. 49\n3.20 Registration Authority Entity ID......cccccveiiiiiiiiiiie i ceciieeee s esiiieeeessssiiieeeeeen. D0\n3.21 Legal JUriSAICTiON ...cicciiieeie ettt s ee s eee e s s sraae e essssnnneeesenes DL\n3.22 ENTitY Cat@OrY ettt ettt e e e e e e e e eeereaesne e s D2\n3.23 ENtitySUDCAtEEOIY .uuiiiiiii ittt ettt ee s e ae e s s state e eessnaaeeeeenes DD\n3.24 Legal FOIM ciiiiiiiiee ettt ette e e rrae e e s e srabe e ae s s s sasbaaeeesssannanesessnnnsssenessnes DT\n3.25 ENtItY STAtUS .cuieiiiie ettt te e e s aaaeeeeenes DO\n3.26 Entity Creation Date ...ttt DO\n3.27 SUCCESSOr ENTItY oot e s e eeeeeeeeeeeesnen OO\n3.28 Legal ENtity EVENTS ..cccvveiiii ittt sttt e esiieeee s siiieeae e s s snaneeesssnnnneaesanns O\n3.29 Legal ENtity EVENT oottt ee s siie e s srane e e s ssnaaeee e enes O2\n3.30 Legal ENtity EVENT TYPE .ciiiiiiiiiiiieieeciiieeeecriiieee s es e ee e s srae e e e s sssnneeeessssssnnaeaen e O4\n3.31 Legal Entity Event Effective Date.......cccceevevivieee it ssiiaeee 0000, 06\n3.32 Legal Entity Event Recorded Date........ccccoeviiieeeiiiiiieeie s ensiieeie s sevieeesssinieee e 07\n3.33 Validation Documents (context: LEI-CDF).......ccccceevviieeeiiieeeceeeessiieesvee e siieeeennn 67\n3.34 Validation Reference (context: LEI-CDF)......ccccccveiiviieeiiiiieeecieee e e esiee e eeiieeennn. 68\n3.35 Affected FIEldS ..uuiiii ittt ssrreeee a0 D8\n3.36 Affected Field. ... e s s naeeee e enes 0O\n3.37 Initial Registration Date (context: LEI-CDF) ........cccovvveeeiviieeecieeeeesivieesceeeesiieenennn 71\n3.38 Last Update Date (context: LEI-CDF)......cccccveeeieeeriiieeeiiiieeeciieeessiiesessveeesveeeesnnnn 71\n3.39 Registration Status (context: LEI-CDF) ..c.covvveeiiieeiiiieecciee e sevieee s 72\n3.40 Next Renewal Date (context: LEI-CDF)....ccccuueeeieeeiiiieeciiiieeciieee e e esvee e svvveeeennnn 72\n3.41 Managing LOU (context: LEI-CDF)....ccccviiiiiiie e ccieeesstee s eeeee s svieeessvaee e 73\n3.42 Validation Sources (context: LEI-CDF)......ccccueveiiiieeciieeeciieeesiiee e eeeeeesieessssineeennn 73\n3.43 Validation AULNOIItY......ceiiiiiiiiiec e ee s seanneee e 1\n3.44 Validation AUthOFItY ID ....ccooveiiiieiiiciiiiecce e erae e ssvreeee s snvnnneeenn 1\n3.45 Other Validation AUthOrity ID.....ccooviiiiiiiiiiiiece et ssivveee e e 1D\n3.46 Validation Authority Entity ID.....ccooviiiiiiiiiiiiiece et seeve e sieaeee a0 10\n3.47 Other Validation AUthOIItIES.......coviviiiiiiiiiiiieee et ssiaaeee e 10\n348 STArt NOGE....eieiieie et srire e ee s s s saaieae s e s s sanaaeeessnnsnneaessnes 1T\nG State Transition and Validation Rules for Common Data File formats Page 3 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":3461,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.110Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"The reporting of the Umbrella Structure MAY be triggered by the umbrella entity as well as by its\ncompartments or sub-funds. However, the relationships are then technically recorded following the\nexisting approach of bottom-up declaration (see section 3.50).\nParent reporting for Government Entities\nGeneral Government Entities are related to each other in the sense that all of them belong to the\nGovernment sector. However, there is no “control” of one Government Entity over another in the\nmeaning attributed to “control” in the IFRS or US GAAP. The consolidation procedures may be quite\ndifferent among government entities and the standards used to identify parent relationships\nbetween general entities would not apply. Government entities that are controlled by another\nGovernment Entity SHALL declare parent relationships according to the usual Global LEI System rules\nbut are likely to use specific accounting standards — GOVERNMENT_ACCOUNTING_STANDARD.\nIn the cases that the parent is unknown, the existing relationship exception for\n“NO_KNOWN_PERSON“is to be used.\n2.2 Corroboration of LElI Record Set\n2.2.1 LEI Registration\ne The process by which Legal Entities are issued LEls and the corresponding Reference Data is\nadded and published in the Global LEI System after successful Validation.\no Asageneral rule, only active Legal Entities can request an LEI.\n° When the LEl is initially issued, the RegistrationStatus SHALL be ISSUED and EntityStatus SHALL\nbe ACTIVE.\n¢ Inrare cases, a regulatory framework may require that inactive entities that do not have an LEI\nneed to be identified with an LEI. Then the LEIl record MAY be issued initially with\nRegistrationStatus RETIRED and EntityStatus INACTIVE.\no If a Legal Entity has (a) parent(s) according to the definitions described above, (a) Relationship\nRecord(s) SHALL be published.\n¢ Only relationships that are active by the time of the registration SHALL be recorded.\nRelationships that ended prior to the initial registration SHALL be excluded.\n* When a Legal Entity cannot provide information on its direct and/or ultimate parents, a\nReporting Exception Record SHALL be published instead.\no The Reporting Exception Record includes the applicable reason for not providing (a) Relationship\nRecord(s). If the reason changes over time, the Reporting Exception Record SHALL be updated.\nState Transition and Validation Rules for Common Data File formats Page 21 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2534,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.110Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"2.2.2 Validation\n\nThe LEI Reference Data includes all elements of an LEI Record that describe the Legal Entity itself and\n\nall of its relationships. The LEI Registration details that describe the state of the LEI Record itself are\n\nnot part of the LEI Reference Data.\n\nThe Legal Entity is responsible to supply its Reference Data when a new LEl is requested. The LOU\n\nverifies the existence of the Legal Entity and the Reference Data based on reliable public sources,\n\nprimarily the sources as mentioned on the RA list. If the data is not available from public sources,\nthen the data MAY be provided by the Legal Entity. Available information from the authoritative\nsource used for Validation SHALL be entered in ValidationAuthority. If more than one authoritative\nsource was used, OtherValidationAuthorities SHALL be populated with information from additional\nsources.\n\ne The LElissuer is responsible for validating and verifying the Reference Data of the LEIl Record,\nusing public (RA) sources where available and relying on entity supplied documents, if no public\nsource can be consulted.\n\no The LEl issuer also is responsible to validate any changes and updates to LEI Records.\n\no The LEl issuer SHALL note the level of Validation in the Reference Data via the element\nValidationSources.\n\no If public sources from the RA list were used to validate the LEI Reference Data, ValidationSources\nSHALL be either FULLY_CORROBORATED, if all LEI Reference Data can be verified, or\nPARTIALLY_CORROBORATED, if only some of the LEI Reference Data can be verified.\n\no If public sources from the RA list were used to validate the LEI Reference Data and all data apart\nfrom the postal code and region can be verified using the public sources, the LEl issuer SHALL add\nthe postal code and region information and ValidationSources SHALL be FULLY_CORROBRATED,\nas the postal code and region are a derivative of the verified address.\n\no If the Validation relies on sources provided by the Legal Entity or other sources not included in\nthe RA list, ValidationSources SHALL be ENTITY_SUPPLIED_ONLY.\n\n* Insome jurisdiction, Government entities are not registered by any Registration Authority.\nHowever, the Government Entity is established by a public legislation or statute, that can be\nreferred to for corroboration. If such public legal document is the source used for corroboration,\nValidationSources SHALL be FULLY _CORROBORATED, if all data elements could be corroborated\nfrom the document, or PARTIALLY_CORROBORATED, if some data elements could be\ncorroborated. Using such documents for validation of unregistered Government entities SHALL\nbe the preferred validation process compared to relying only on entity supplied information.\n\no If ValidationSources is PENDING, the LEI Record SHALL NOT be published and is for the LEI\nissuer's internal use only.\n\no The same authoritative source SHALL NOT appear more than once in ValidationAuthority and/or\nOtherValidationAuthorities but one of the sources MAY be the same as RegistrationAuthority.\n\nState Transition and Validation Rules for Common Data File formats Page 22 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":3213,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.112Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o OtherValidationAuthorities SHALL NOT include RA999999 (see chapter 2.2.3) as\nValidationAuthorityID.\n\no OtherValidationAuthorities MAY contain additional information about an authorititative source\nand local identifiers, in order to enrich the LEI Record Set and support verification by a third\nparty, the public or just to enhance and enable a mapping exercise.\n\no If the Legal Entity has declared relationships, the LEl issuer is responsible to validate that the\nrelationship between the two Legal Entities exists.\n\no The LElissuer is responsible for validating that the LEl presented in an EndNode of a relationship\nindeed represents the Legal Entity declared in the documents used for validating the\nrelationship.\n\ne The LElissuer is not responsible for validating Reporting Exception reasons reported.\n\ne The LElissuer is not responsible for validating a Legal Entity’s statement that there is no parent\naccording to the accounting consolidating definition used but SHALL respond to any challenges to\nthat status.\n\no The LElissuer is not expected to validate the Reference Data associated with the LEI presented as\nEndNode unless the LEl issuer is also the LEl issuer of the EndNode’s LEI Record Set.\n\ne The LElissuer is responsible for ensuring that a relationship is made to an active entity. This\nmeans the parent LEI should not have a RegistrationStatus of DUPLICATE, RETIRED, MERGED , or\nANNULLED at the time of the initial Relationship Records issuance. Rare cases, where an LEl is\nissued initially to an inactive entity are exempted from this rule.\n\no The LEl issuer SHALL accept or deny a Relationship Record based on the result of its Validation.\n\no The LEl issuer SHALL revalidate the complete LEI Reference Data at each renewal. When LEI\nReference Data is updated (e.g.: by the Legal Entity or due to a challenge), the updated data\nSHALL also be validated.\n\nPrimary sources are required for the Validation of accounting consolidating parent relationships.\n\nThese include only the following documents:\n\n1. Consolidated financial statements are a key source to validate parent relationships. Such reports\nmay be prepared and submitted to the relevant authority quarterly or annually or attested to by\na third-party auditor and not submitted to an authority.\n\n2. Regulatory filings (i.e., reports to a securities regulator or a bank supervisor) are another\nimportant source. When validating using a regulatory filing, the filing name must be provided (as\nwell as the path if available). Best practice would be to include the Digital Object Identifier (DOI)\nof the document.\n\n3. Other types of allowable sources include other documents supporting the preparation of\nconsolidated financial statements, contracts, and other official documents.\n\nState Transition and Validation Rules for Common Data File formats Page 23 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2939,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.114Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Proprietary products containing secondary data derived from a variety of sources are not considered\nas valid sources for Validation of relationship data. Only an original source of the above-mentioned\nquality is acceptable. The level of corroboration depends on the sources used for Validation:\n\n¢ The ValidationSources of a Relationship Records is FULLY _CORROBORATED if\no (i) there are consolidated financial statements, other documents supporting the preparation\n\nof consolidated financial statements coming from or otherwise confirmed by the external\nauditor, or regulatory filings\n\ne AND (ii) these documents establish the consolidation relationship and mention the name of\nboth related entities.\n\no The ValidationSources of a Relationship Record is PARTIALLY_CORROBORATED, if\no (i) the definition of parent used in regulatory filings differs from the accounting consolidation\n\ndefinition, but filings assist in corroborating the information provided by the child Legal\nEntity that the conditions of consolidation are met. Only accounting consolidation\nrelationships are expected to be reported and the LEl issuer is not expected to conduct an\nanalysis of differences between the regulatory sources and the accounting standard.\nGenerally, the type of source, or the fact that the source does not refer to accounting\nstandards will inform the LEl issuer that this category should be used;\n\no OR (ii) Official documents such as regulatory filings or contracts make it likely that the\nconditions of accounting consolidation are met, or have ceased to be met, when\nconsolidated accounts reflecting the new situation have not been established yet.\n\n¢ The ValidationSources of a Relationship Records is ENTITY_SUPPLIED_ONLY if\ne (i) the conditions for FULLY_CORROBORATED or PARTIALLY_CORROBORATED would have\n\nbeen met, except that the documents used for Validation are usually not publicly available in\nthe legal jurisdiction(s) of the child and parent Legal Entities;\n\ne AND (ii) the child Legal Entity provided official documents for the purpose of validating the\nrelationship.\n\nFund entities can have fund relationships in addition to the above described accounting consolidating\n\nparent relationships. A fund prospectus would be a good source for validating the different Fund\n\nrelationships:\n\ne Providing prospectus certified by a regulatory authority from GLEIF RA list SHALL be set to\nFULLY_CORROBORATED and the corresponding RA code SHALL be documented in the Validation\nAuthority container.\n\ne Providing prospectus not vetted by any authority SHALL be reported as ENTITY_SUPPLIED _ONLY.\n\nState Transition and Validation Rules for Common Data File formats Page 24 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2779,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.116Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"The Validation Authority of a fund entity SHALL be the financial regulator registering the fund.\n\n2.2.3 Application of GLEIF Registration Authorities List\n\nLEl issuers SHALL ensure the cross reference to the local authoritative source is standardized and\n\nincluded in an LEI record. GLEIF maintains and publishes a list with Registration Authority (RA) Codes®\n\nthat SHALL be used to populate RegistrationAuthoritylD and ValidationAuthorityID. This list includes\nspecific and unique codes for all authoritative sources accepted by GLEIF as well as three reserved RA\ncodes (RA777777, RA888888 and RA999999).\n\nSpecific RA code (not RA777777, RA888888 or RA999999):\n\n» If a specific RA code is available, it SHALL be used in RegistrationAuthoritylD and/or\nValidationAuthorityID.\n\no If RegistrationAuthoritylID is populated with a specific RA code, OtherRegistrationAuthoritylD\nSHALL NOT be provided; the same applies to ValidationAuthorityID and\nOtherValidationAuthorityID.\n\n¢ If ValidationAuthorityID is populated with a specific RA code, ValidationSources SHALL NOT be\nENTITY_SUPPLIED_ONLY.\n\no If a specific code is removed from the RA list, the LEl issuer SHALL update all affected records,\nwith a correct new code within the specified implementation time. The new code SHALL NOT be\nRA888888 with the name of the just removed registration authority as OtherAuthorityID.\n\nReserved RA code RA777777:\n\no The RA code RA777777 is used for General Government Entities and International Organizations\nonly in case there is no information available in any regular registration authority and Public\nLegal Documents are used for validation instead.\n\no If ValidationAuthoritylID is populated with RA777777, OtherValidationAuthoritylD SHALL be\npopulated with the name of the source as free text or if available with the link to the documents\nused for validation.\n\no RegistrationAuthoritylD and OtherRegistrationAuthoritylD SHALL NOT be populated with\nRA777777.\n\no If ValidationAuthorityID is RA777777, the RegistrationAuthoritylD SHALL be RA888888 or\nRA999999 only (please consult Figure 3)\n\n3 https://www.gleif.org/en/about-lei/code-lists/gleif-registration-authorities-list#\n\nState Transition and Validation Rules for Common Data File formats Page 25 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2348,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.116Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o If ValidationAuthorityID is RA777777, ValidationSources SHALL shall be\nPARTIALLY_CORROBORATED or FULLY_CORROBORATED.\n\nReserved RA code RA888888:\n\no The RA code RA888888 is used as an interim code. This indicates that a Registration/Validation\nAuthority is not available on the RA list, but the addition of a relevant source, which could be\nused for the LEl in question, has been requested to GLEIF.\n\no This code SHALL be used only after a request to add a new RA source has been sent by email to\nralist@gleif.org with further description of the source.\n\no All requests for new RA codes (or modifications) are collected over time and processed in time\nfor the periodical publication of a new version of the RA list. The approximate date(s) for the\npublication of a new version are communicated well in advance.\n\n* In cases, where the suggested source has NOT been accepted as authoritative source, the LEI\nissuer needs to provide a new suggestion for a source in order to ensure proper corroboration\nwithin a month, if no other implementation time is defined. If no other source could be identified\nfor Validation and Verification of the Legal Entity and its Reference Data, the correspondent\nfields SHALL be changed to RA999999.\n\n* In cases, where the suggested source has been accepted as an authoritative source, the LEl issuer\nSHALL replace the reserved code with the new code and adjust the corroboration level\naccordingly within the time frame communicated for the implementation of the new version of\nthe RA list.\n\n¢ The reserved code RA888888 SHALL NOT be used for longer than a month after publication of\nthe new version of the RA list which includes the new valid RA code, unless a different\nimplementation time has been defined.\n\no If RegistrationAuthorityID is populated with RA888888, OtherRegistrationAuthoritylD SHALL be\npopulated with the name of the source as free text; the same applies to ValidationAuthoritylD\nand OtherValidationAuthorityID.\n\n¢ The name provided as free text SHALL be the same as used in the request sent to GLEIF to add\nthe source to the RA list.\n\no If RegistrationAuthorityID or ValidationAuthorityID is RA888888, ValidationSources SHALL only be\nset to the lowest corroboration level, namely ENTITY_SUPPLIED_ONLY.\n\nReserved RA code RA999999:\n\ne The RA code RA999999 refers to situations when no Registration Authority can be defined for a\nLegal Entity. The LEl issuers are obliged to use their full efforts and local expertise to ensure that\nthe applicant is an existing Legal Entity and is eligible to obtain an LEl and also document this\ninformation accordingly.\n\nState Transition and Validation Rules for Common Data File formats Page 26 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2789,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.116Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o If RA999999 is used as identifier for the source, the respective EntitylD SHALL NOT be populated.\nPlaceholders like “N/A”, “None”, etc. SHALL NOT be used.\n¢ If ValidationAuthorityID is RA999999, ValidationSources SHALL be ENTITY_SUPPLIED_ONLY.\ne RA999999 SHALL NOT be used in OtherValidationAuthorityID or for records with EntityCategory\nBRANCH.\nFigure 3 below shows the allowed combinations of reserved RA codes for RegistrationAuthoritylD\nand ValidationAuthority ID.\nValidationAuthoritylD\nSpecifc\nRA777777 RA888888 RA999999 ValidationAuthoritylD\nRegistrationAuthoritylD\nSpecific Not ok Not ok Not ok Ok\nRegistrationAuthoritylD ot okay ot okay ot okay ay\nFigure 3: Overview of allowed combinations of reserved and specific RA codes for RegistrationAuthoritylD and\nValidationAuthoritylD\n2.3 Life cycle\nFigure 4 highlights the existing general STVR in the registration status of an LEIl, from its creation in\nthe internal LEl issuer systems until reaching a so-called end state. In addition, the life cycle includes\nand describes the process of transferring an LElI Record Set from one LEl issuer to another.\nThe life cycle is divided into “Internal” states, that are managed by the LEl issuer but not shared with\nthe public, and “Published” states, that are included in the Global LEI Repository. For instance,\nPENDING_VALIDATION is Internal with respect to publication because LEI registrations are expected\nto be fully validated prior to the LEI being assigned, issued, and published. An expected part of the\nlife cycle of an LEl registration is the timely update and periodic Validation of its Reference Data. This\nperiodic Validation needs to be performed at least once a year. If a record is not validated again\nwithin this timeframe, the registration status code will be set to LAPSED, meaning the Validation is\noverdue.\nState Transition and Validation Rules for Common Data File formats Page 27 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2012,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.116Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"1\nPUBLISHED\n- /‘///J>77777\\7\\\nINTERNAL H\nREGISTRATION LIFE CYCLE\n: .\nSTART ISSUING PROCESS TRANSIENT\n\\/ |\n\\ END STATES |\nTRANsFERED]<—1\n\nFigure 4: High-level general representation of the life cycle of an LEI\n\n2.3.1 Registration Status Codes\n\nThe RegistrationStatus operational data element indicates the state that an LEI Record can have over\n\nits life cycle.\n\nThe defined status codes fall into four broad categories:\n\n1. Registration life cycle: These are codes applied in the normal life cycle of an LEl registration from\nsubmission through issuance through the termination of the registration when the entity\nbecomes inactive.\n\n2. Registration Errors: These are codes that are needed to correct errors that may occur in LEI\nregistration process.\n\n3. Transient conditions: These are codes that support certain transient conditions describing the\ntransfer of an LEl registration from one LEIl issuer to another.\n\n4. Deprecated statuses: Values that have been accepted in the past, and due to changes in\nunderlying standards, policies and/or rules, have be amended as invalid or no longer in use.\n\nEach RegistrationStatus code holds information regarding the publication of the LEI Record Set as\n\nshown in below table:\n\ne Published: The LEI Record Set is included in the public files published by the LEl issuer and GLEIF.\n\nState Transition and Validation Rules for Common Data File formats Page 28 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1509,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.116Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"¢ Transient: The LEI Record Set is included in the public file published by the LEl issuer, but only\nduring a record transfer from one LEl issuer to another. It may not be included in files published\nby GLEIF, if the same LEl is already published by another LEl issuer.\n\ne Archived: The LEI Record Set is not included in the public file published by the LEl issuer or by\nGLEIF but is retained by the LEl issuer as part of its archival records.\n\n¢ Internal: The LEI Record Set is not included in the public file published by the LEl issuer or by\nGLEIF but may be exchanged between LEI issuers and/or GLEIF as part of the Validation process\nprior to issuance.\n\no Deprecated: The RegistrationStatus has been deprecated and SHALL NOT be used anymore. LEI\nRecords with this RegistrationStatus MAY appear in historical LEI Record files but have been\nupdated to a different status in current data files.\n\nThe following table categorizes the RegistrationStatusEnum codes:\n\nPENDING_VALIDATION Registration life cycle Internal\n\nISSUED Registration life cycle Published\n\nPUBLISHED Registration life cycle Published\n\nDUPLICATE Registration Errors Published\n\nLAPSED Registration life cycle Published\n\nMERGED Deprecated Deprecated\n\nRETIRED Registration life cycle Published\n\nANNULLED Registration Errors Published\n\nCANCELLED Registration Errors Archived\n\nTRANSFERRED Transient condition Archived\n\nPENDING_TRANSFER Transient condition Transient\n\nPENDING_ARCHIVAL Transient condition Transient\n\nThe value MERGED in the RegistrationStatus field is deprecated with the LEI-CDF 3.1 being effective.\nState Transition and Validation Rules for Common Data File formats Page 29 of 170\n@ Public Version 2.7.1 Final\n\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1764,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.116Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"2.3.2 Changes in Registration Status due to Legal Entity Events\nWhile the RegistrationStatus has information about the LEI Record itself and not necessarily\ndescribes the state of the Legal Entity, some Legal Entity Events also trigger a transition in\nRegistrationStatus. Each of the following events documented with its exact effective date SHALL\nchange the RegistrationStatus of the LEI Record to RETIRED according to the existing rules:\no Liquidation (@event_status COMPLETED)\n¢ Insolvency (@event_status COMPLETED)\no Dissolution of a Legal Entity, including International Branches and Subsidiaries (@event_status\nCOMPLETED)\ne Mergers and Acquisitions (for the Legal Entity which ceases operation as a result of a merger)\nRETIRED is an end state of an LEl Record Set, and an update that assigns this RegistrationStatus code\nto the LEI Record Set is the last regular update that is made to that record. Therefore, the\nEntityStatus and the RelationshipStatus are set to INACTIVE once this end state has been reached. In\norder to satisfy the 1ISO 17442 persistence criteria of the LEI (i.e., the ability to properly interpret\nexisting and historical records and reports that refer to LEls in this state), these LEI Records are still\npart of the published LEI records. The LEI Record Set MAY still be updated to comply with the\nimplementation of new code lists or to amend data quality issues caused by the record. In such cases\nGLEIF needs to be informed about the data updates.\nThe following Legal Entity Events SHALL be documented together with the EffectiveDate of the event\nand SHALL remain in their current RegistrationStatus (expected to be either ISSUED or LAPSED):\n¢ Changeinlegal name (@group_type STANDALONE)\ne Change in trade or doing business name\no Change in legal address\no Change in headquarters address\n¢ Change of legal form\no Demergers and Spinoffs (for the entity that has been demerged or spin off)\ne Absorption\no Voluntary Arrangement\no Acquisition of an international branch (for the branch entity)\no Transformation of an international branch into a Subsidiary (for the entity that has been\ntransformed into a Subsidiary)\ne Transformation of a Subsidiary to an international branch (for the entity that has been\ntransformed into an international branch)\nState Transition and Validation Rules for Common Data File formats Page 30 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2459,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.116Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"349 ENA NOUE ettt ettt e e s s saabn e s e s s snaae e e e s snnnneeesenes 1O\n3.50 RelationShip TYPE cooiiiiiiiei et ae e sraae e s ssnaneeeeenes 1O\n3.51 Relationship PEriods .....ccciiiiiiiiiiiiiiiiiiieeee sttt srne e s sssnieeee s seinneeeeees S0\n3.52 Relationship StAtUS ...uvviiiiiiiiiie e 82\n3.53 Relationship QUAlIfIErS.......ooviuiieiiiiriiiee e ee e e 82\n3.54 Relationship QUaNLIfIErs ......c.uivviiiiiiiiiee e ieee e S\n3.55 |Initial Registration Date (context: RR-CDF).......ccccceeverivriieecicieee e 84\n3.56 Last Update Date (context: RR-CDF) .......ccccveeeiiieiiiiieecriiee e s e sieeee 0000 85\n3.57 Registration Status (context: RR-CDF) .....ccccceeeiieiiiiiieciiiee e 85\n3.58 Next Renewal Date (context: RR-CDF)....ccccveeeuiiieiiieeeiiiee e e seiieeee00. 80\n3.59 Managing LOU (context: RR-CDF) ......cccceeiiiieeiiieeeciies e sstve e e sive e 8 7\n3.60 Validation Sources (context: RR-CDF) .....ccccueeeiieiiiiiieeisiiee e esiie e siveee e 8 7\n3.61 Validation Documents (context: RR-CDF) .......cccceviviiieeiiiiee e s, 88\n3.62 Validation Reference (context: RR-CDF) .......ccccvveeiivieeeiiiiie e ssiee e siieeeen00n 89\n3.63 LEI (context: REPEX-CDF)..ccccciiiecieeeiiieeesitiie e ceeeeesiie e essvee s saee e e s savaesssnee s snnveeesnnee 89\n3.64 EXCePtion CateBOrY ....cooiiiiiiiiiiiiiceee ettt ee e OO\n3.65 EXCePtion REASON....ccoiiiiiiiiiiieeieitie e e e e e s e s e eeeesneenenesnens D0\n3.66 EXCEPLiON RETEIENCE ...uuiiiii ittt srae e ssaaaeee e enes D2\n3.67 Associated Entity — DEPRECATED .......cuvviviiiiiiiieeeeiiiieece s essiieeeeesssneneeesssnnneeeeenns 92\n3.68 Entity Expiration Date — DEPRECATED ......ccoocutiiiiiiiiiiieee s ciiiiieee s essiinneeee e ssnneeee . 93\n3.69 Entity Expiration Reason — DEPRECATED.........ccccvivmiiiiiiiiiieieeeeeeeeeeeeeeeeeeeieiiennnnn. 93\nL ¥ LY - 1 R |-\n4.1 Issue New LEI that is not branch, fund, sole proprietor, government entity or\n\ninternational Organization ........cccvueeeiiiinieeie e 9D\n4.1.1 Relationship with a parent Legal Entity with an LEl.........ccccovvviiiiviiiieiiiniieeeennn.. 96\n4.1.2 Relationship with a parent Legal Entity without an LEl .........cccccceeviviiiiiiinieennnn... 96\n4.1.3 No accounting consolidation parent relationship........cccoccevieviieeiiiiviiniiesieeen e 97\n\n4.1.4 Accounting consolidation parent relationship not reported due to legal obstacles\n(o] 2o 10 1 | TS TS USURORSSPRP < ¥\n4.2 Issue NeW LEI = Branch .......coooviuiiiiiiiiiiiiiee e cssiieie e svveeeee s ssvnneeesssssinnnne s 97\n4.3 Issue NeW LEI = FUNd .....oviiiiiiiiiiiecceciiieece e esieee e svane e e e s ssnnneee s snssannenees 99\n4.4 Issue New LEI —Fund in formation ........cccccevvviiiiiiinniiiienscciieeeesssiiieee e esnnnnnn. 101\n4.5 Issue New LEI —Sole proprietor.....ccccoccvveeeeiiiiieeeeiiisiieeeeesssieeeeeesscveneesssnsnnneees 103\n4.6 Issue New LElI —Government entity........cccceviimimiiiiiiiiiiin e eececccveeeeeeeeen... 103\n4.7 Issue New LEI —International organization .........ccccceeeviveeeiiiiiieeeeeinniiiee e 104\n4.8 LEIRecOrd RENEWAl ..cuvvviiiiiiiiiiiieieeciiiecce et essiieie e sieeeeessssnnseeessnssennnns 10D\n4.9 LEl Record update — Parent Legal Entity without an LEI requests an LEl............106\n4.10 LEI Record update — Relationship Record changes to Reporting Exception .......106\nG State Transition and Validation Rules for Common Data File formats Page 4 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":3466,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.118Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"¢ Umbrella fund changes its structure to a stand-alone fund (for the new stand-alone fund)\n\no Bankruptcy (@event_status IN_PROGRESS)\n\n¢ Liquidation (@event_status IN_PROGRESS)\n\no Insolvency (@event_status IN_PROGRESS)\n\no Dissolution of an entity, including international branches and subsidiaries (@event_status\nIN_PROGRESS)\n\no Break ups (for any part of the original Legal Entity that remains in operation and for any new\nLegal Entities that are formed as part of the terms of the breakup)\n\n2.3.3 Changes in Registration Status when a registration error is resolved\n\nThere are three registration status codes that apply to situations in which a registration assignment\n\nerror has been made: DUPLICATE, ANNULLED, and CANCELLED.\n\no The DUPLICATE code refers to the non-surviving record under an Exclusivity Violation.\n\no The ANNULLED code applied to any other type of assignment error detected after an LEI\nregistration has been publicly issued.\n\no The CANCELLED code refers to any type of assignment error detected before publication.\n\nThese error states are terminal: no further updates to Entity sections of registration records in these\n\nstates SHALL occur. Records in the DUPLICATE or ANNULLED states SHALL be retained as published\n\nrecords in the Global LEI System to support the historical record and to provide resolution to any\nexternal query of the LEI. The LEI Record Set MAY still be updated to comply with the\nimplementation of new code lists or to amend data quality issues caused by the record. In such cases\n\nGLEIF needs to be informed about the data updates. Records with the state CANCELLED SHALL be\n\nretained internally by an LEl issuer to support auditing.\n\n2.4 Registration Status Codes for Transient Purposes\n\nThree registration status codes exist to accommodate the transfer of the management of an LElI\n\nregistration from one LEl issuer to another: PENDING_TRANSFER, PENDING_ARCHIVAL,\n\nTRANSFERRED.\n\no PENDING_TRANSFER and PENDING_ARCHIVAL are used in the transitional period between the\nreceipt of a porting request by a Sending LOU and the final confirmation of the transfer.\n\no The TRANSFERRED code is used in the archival records of a Sending LOU after having successfully\ncompleted the transfer of that responsibility to another (Receiving) LOU. A record in this state is\nnot published but kept internally by the prior LOU for audit trail purposes.\n\nFor a short period of time a given record may appear more than once in a published concatenated\n\nfile. This case occurs at the end of the transfer process, when the Sending LOU publishes their file\n\nState Transition and Validation Rules for Common Data File formats Page 31 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2760,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.120Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"with RegistrationStatus PENDING_ARCHIVAL and the Receiving LOU publishes their file with the\nregistration status ISSUED. The time window for these transient states is limited by a transfer\nprotocol shared between GLEIF and the LEl issuers (see Use Case 4.19). On average, transfers SHALL\nbe completed within five to ten business days.\n2.5 Renewal\nRenewal is the process that triggers the periodic Validation of an LEI Record Set. Renewal is required\none year after the initial registration and every year thereafter. The Next Renewal Date in the\nrecord’s registration section indicates the date when the next renewal is due. If a record is not\nrenewed in due time, the LEl issuer shall validate that the entity is still operating. Given the entity is\nstill operating, the Registration Status SHALL be set to LAPSED and the Next Renewal Date SHALL NOT\nbe updated.\nThe renewal of an LEI Record is initiated by the Legal Entity. The LEIl issuer SHALL inform the Legal\nEntity at least six weeks prior to the next renewal date and remind the Legal Entity to renew the LEI\nRecord Set. Any changes to the LEI Reference Data SHALL be updated by the Legal Entity and\nvalidated by the LEl issuer. After this is completed, the Registration Status remains ISSUED and one\nyear is added to the Next Renewal Date. A LAPSED record MAY be renewed as well and return to an\nISSUED state at any point of time.\n2.6 1SO 3166 Conformance of Address and Jurisdiction Fields\nThe following LEI-CDF data fields must contain current, valid ISO 3166 country (or region, where\napplicable) codes taken from the ISO 3166 code lists. The XML schema for the LEI-CDF validates only\nthe format (pattern) of these fields, not the specific codes used.\no CountryCode in all addresses\no RegionCode in all addresses\no Legallurisdiction\nThe RegionCode SHALL be an ISO 3166-2 subdivision code assigned under the CountryCode.\nDepending on the jurisdiction, either a country code or a region code or either of both SHALL be used\nin Legallurisdiction. Details on this are defined in the GLEIF Accepted Legal Jurisdictions Code List*.\n4 GLEIF Accepted Legal Jurisdictions Code List: https://www.gleif.org/en/about-lei/code-lists/gleif-accepted-\nlegal-jurisdictions-code-list\nState Transition and Validation Rules for Common Data File formats Page 32 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2411,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.121Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"2.7 Address Reporting\n\nAn LEI Record SHALL have at least a LegalAddress (where the entity is legally registered) and a\n\nHeadquartersAddress (where the main center of control of the entity resides). LegalAddress and\n\nHeadquartersAddress MAY be the same. Both addresses MAY also be in different countries and/or in\n\ncountries different from Legallurisdiction. If the Legal Entity has only one address recorded in an\n\nofficial Registration Authority, LegalAddress and HeadquartersAddress SHALL be the same address,\nexcept for entities categorized as FUND or BRANCH which have special rules for\n\nHeadquartersAddress (see 3.13 and 3.14 below). If the registry has partial address information, for\n\ninstance a seat of the company recorded only with the city name and a second field with a complete\n\naddress, the latter SHALL be used for LegalAddress and HeadquartersAddress, even if the address is\nin a different city than the city of the seat. In case of doubts, the LEl issuer SHALL contact the\nauthoritative source for further clarification and validation of the data.\n\nIf the address recorded in the registry is not complete, the LEl issuer SHALL collect the missing\n\nelements from the Legal Entity and set ValidationSources to PARTIALLY_CORROBORATED, except\n\nwhen only postal code and/or region is added by the LOU. In this case, the record can be still\n\nFULLY_CORROBORATED (see chapter 2.2.2). In case the HeadquartersAddress could be validated in\n\nan autoritative source different from the primary one, this could be added in the container\n\nOtherValidationAutorities and the corroboration status MAY be set FULLY_CORROBORATED.\n\nAll addresses reported SHALL be complete and include the following mandatory elements:\n\no FirstAddressLine SHALL include the first line describing the address. Up to three additional lines\nMAY be included.\n\no City SHALL be the name of the city in local language and alphabet.\n\no PostalCode SHALL be the postal code in the format specified by the local postal service. For\ncountries that do not use postal codes in addresses, this optional element SHALL NOT be\nprovided.\n\no Region SHALL be the 1ISO 3166-2 region code of the address. For countries that do not have\nregion codes, this optional element SHALL NOT be provided.\n\ne Country SHALL be the ISO 3166-1 country code of the address.\n\nAddresses MAY include optional elements for additional relevant parts of an address to be recorded\n\nin a structured way:\n\n¢ MailRouting MAY contain explicit routing information or “care of” address.\n\no AddressNumber MAY contain the building number.\n\n¢ AddressNumberWithinBuilding MAY contain an internal location within a building, for example to\nidentify the floor, suite or an apartment.\n\nState Transition and Validation Rules for Common Data File formats Page 33 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2892,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.123Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"The information in these optional fields SHALL also be included in FirstAddressLine or\nAdditionalAddressLines. The content of the mandatory elements SHALL NOT be repeated in any\nother field (e.g., the postal code SHALL NOT be included in the designated City field).\n\n2.8 Entity Legal Form Reporting\n\nLEl issuers SHALL ensure that cross reference to the entity legal form is standardized and included in\n\nan LEl record. GLEIF maintains the ISO 20275 standard and publishes the Entity Legal Forms (ELF)\n\nCode List. Codes from that list SHALL be used to populate EntityLegalFormCode. This list includes\n\nspecific and unique codes for all legal forms identified per jurisdiction and two reserved ELF codes\n\n(8888 and 9999) that are valid across jurisdictions.\n\nSpecific ELF code (not 8888 or 9999):\n\no If a specific ELF code is available for an entity's legal form in the entity's legal jurisdiction, it\nSHALL be used in EntityLegalFormCode.\n\no If EntityLegalFormCode is populated with a specific ELF code, OtherLegalForm SHALL NOT be\nprovided.\n\no If a specific code is removed from the ELF code list, the LEl issuer SHALL update all affected\nrecords representing an ACTIVE Legal Entity with a correct new code. The new ELF code SHALL\nNOT be 8888 or 9999 with the name of the just removed legal form as OtherLegalForm.\n\nReserved ELF codes 8888 and 9999:\n\ne Reserved ELF code 8888 is to be used when a new ELF code (for a legal form not yet on the list) is\nrequested by an LEl issuer from GLEIF for a jurisdiction which is on the ELF code list.\n\no Reserved ELF code 9999 is to be used for LEIs from a jurisdiction which is not on the ELF code list\nyet.\n\n¢ The reserved code 8888 SHALL be used only after a request email to elf@gleif.org with further\ndescription of the legal form has been sent.\n\no All requests for new ELF codes (and modifications) are collected over time and processed in time\nfor the periodical publication of a new version of the ELF code list. The approximate date(s) for\nthe publication of a new version SHALL be published well in advance.\n\n¢ In cases, where the suggested legal form has NOT been accepted, based on the reason for the\nrejection, the LEl issuer SHALL select one of the following options:\n\no Use a different existing ELF code assigned to the Legal Entity’s legal form (if possible).\ne Propose another new legal form to be added to the ELF code list and update OtherLegalForm\naccordingly.\n¢ Send more convincing documentation for the proposed legal form.\nState Transition and Validation Rules for Common Data File formats Page 34 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2669,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.123Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o Annul the LEl, but only if the outcome of the discussion is that the proposed legal form is not\neligible for an LEI.\n\n¢ In cases, where the suggested legal form has been accepted, the LEl issuer SHALL update all\napplicable records with the new ELF code, including records that are RETIRED, MERGED not later\nthan one month after publication, unless another implementation time has been set.\n\no If EntityLegalFormCode is populated with 8888 or 9999, OtherLegalForm SHALL include the\ncorrect name of the entity's legal form where no ELF code exists. Therefore, OtherLegalForm\nSHALL NOT contain any ELF code or undescriptive text like “OTHER”, “N/A” or “None”. The name\nprovided as free text SHALL be the same as used in the request sent to GLEIF to add the source to\nthe RA list.\n\n2.9 Language, translation and transliteration\n\ne Where LEl record fields allow for an optional (as per LEI-CDF) language tag, this tag SHALL always\nbe provided. This SHALL be an IETF Language Code conforming to the latest RFC from IETF BCP\n47.\n\ne For transliterated names and addresses then the language code SHALL specify the language of\nthe name or address prior to transliteration.\n\no TransliteratedOtherEntityNames SHALL include a list of ASClI-transliterated (i.e. Latin- or\nRomanized) representations of names for the Legal Entity in all cases of non-romanized\nLegalName.\n\no If using TransliteratedAddressType, the transliterated elements that correspond to the\nmandatory and optional information provided in either the LegalAddress, HeadquartersAddress,\nor OtherAddress SHALL be required, given any of these elements are provided in a non-latin\nalphabet.\n\ne If alegal name or address is provided in an alternative language, both the primary field and the\nalternative SHALL have a language tag, and both SHALL NOT be the same.\n\nState Transition and Validation Rules for Common Data File formats Page 35 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1997,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.124Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3 General State Transition and Validation Rules\nThese rules SHALL apply to the general Use Case for issuing and managing an LE| for a Legal Entity as\nwell as publishing the LEI Record Set. An LEI Record Set with complete Reference Data is composed\nof data fields that are published in different XML files. Each XML file has its own name space and\nschema file. These are:\ne LEl Entity Data (Level 1):\n* Name space: lei\no .xsd file: https://www.gleif.org/content/2-about-lei/6-common-data-file-format/1-\nupcoming-versions/2021-03-04_lei-cdf-v3-1.xsd\no LEI Relationship Data (Level 2):\no Name space: rr\no .xsd file: https://www.gleif.org/content/2-about-lei/6-common-data-file-format/1-\nupcoming-versions/2021-03-04_rr-cdf-v2-1.xsd\no Reporting exception Data (Level 2):\n¢ Name space: repex\no .xsd file: https://www.gleif.org/content/2-about-lei/6-common-data-file-format/1-\nupcoming-versions/2021-07-20_reporting-exceptions-format-v2-1.xsd\nThe complete Xpath is shown in the field description for each field. The schema description in the\n.xsd file provides a more technical definition of each element, including format restrictions, allowed\nvalues, etc. In case there is a discrepancy between the required cardinality of a field in this document\nand the corresponding CDF file, the definition in this document SHALL prevail.\nState Transition and Validation Rules for Common Data File formats Page 36 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1507,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.124Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.1 Header Section (applicable to all files)\nlei:LEIHeader\nrr:Header\nrepex:Header\n_ Contains the file upload information for this file.\n/lei:LEIData/lei:LEIHeader\n/rr:RelationshipData/rr:Header\n/repex:ReportingExceptionData/repex:Header\nThe Header Section describes the context for the LEI Records contained in the main body of the file.\nThe Header Section includes information on the origin and timestamp of the data. The content of the\nHeader Section SHALL NOT be required to interpret the data content of any LEI Record; each LEI\nRecord is self-contained. The Header Section includes the following elements:\ne Content Date\ne Originator\no File Content\no Delta Start\ne Record Count\n° Extension\nState Transition and Validation Rules for Common Data File formats Page 37 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":878,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.124Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.2 Content Date\nlei:ContentDate\nrr:ContentDate\nrepex:ContentDate\n_ The date and time as of which the data contained in the file is valid.\n/lei:LEIData/lei:LEIHeader/lei:ContentDate\n/rr:RelationshipData/rr:Header/rr:ContentDate\n/repex:ReportingExceptionData/repex:Header/repex:ContentDate\nThe Content Date for each record defines the date and time as of which the data contained in the file\nis valid. The following rules apply:\no The ContentDate SHALL be equal to or later than the latest InitialRegistrationDate in the file.\no The ContentDate SHALL be equal to or later than the latest LastUpdateDate in the file.\no The ContentDate SHALL be later than the DeltaStart date for delta files.\n3.3 Originator\nlei:Originator\nrr:Originator\nrepex:Originator\n_ The LEI of the LEl issuer that created the content of this file.\n/lei:LEIData/lei:LEIHeader/lei:Originator\n/rr:RelationshipData/rr:Header/rr:Originator\n/repex:ReportingExceptionData/repex:Header/repex:Originator\nState Transition and Validation Rules for Common Data File formats Page 38 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1148,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.124Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"e The Originator SHALL be a valid LEI with correct check digits as specified in the 1ISO 17442\nstandard document.\no The Originator SHALL contain the LEI of the LEl issuer publishing the file.\no If FileContent is not GLEIF_FULL_PUBLISHED or GLEIF_DELTA_PUBLISHED, Originator SHALL be\npopulated.\n3.4 File Content\nlei:FileContent\nrr:FileContent\nrepex:Content\n_ A code describing the content of this file.\n/lei:LEIData/lei:LEIHeader/lei:FileContent\n/rr:RelationshipData/rr:Header/rr:FileContent\n/repex:ReportingExceptionData/repex:Header/repex:FileContent\n¢ The value LOU_FULL_PUBLISHED for FileContent SHALL be used to designate a file containing all\nup-to-date LEI Records published by an LEl issuer.\no If FileContent is LOU_FULL_PUBLISHED, then DeltaStart SHALL NOT be present.\n¢ The value LOU_DELTA_PUBLISHED for FileContent is used to designate a file containing only LEI\nRecords newly added or changed since an LOU’s last upload.\no If FileContent is LOU_DELTA_PUBLISHED, then DeltaStart SHALL be present.\no If FileContent is neither LOU_DELTA_PUBLISHED nor GLEIF_DELTA_PUBLISHED, DeltaStart SHALL\nNOT be present.\nState Transition and Validation Rules for Common Data File formats Page 39 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1298,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.124Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.5 Delta Start\nlei:DeltaStart\nrr:DeltaStart\nrepex:DeltaStart\nThe date and time of the baseline relative to which this file contains\nnew or changed records.\n/lei:LEIData/lei:LEIHeader/lei:DeltaStart\n/rr:RelationshipData/rr:Header/rr:DeltaStart\n/repex:ReportingExceptionData/repex:Header/repex:DeltaStart\nCurrently, delta files are not provided or accepted by GLEIF.\no If Header contains the DeltaStart element, then FileContent SHALL be LOU_DELTA_PUBLISHED or\nGLEIF_DELTA_PUBLISHED.\n3.6 Record Count\nlei:RecordCount\nrr:RecordCount\nrepex:RecordCount\n_ The number of records in this file.\n/lei:LEIData/lei:LEIHeader/lei:RecordCount\n/rr:RelationshipData/rr:Header/rr:RecordCount\n/repex:ReportingExceptionData/repex:Header/repex:RecordCount\ne The number of instances of lei:LEIRecord, rr:Relationship or repex:ReportingException contained\nin this file SHALL equal the value of RecordCount.\nState Transition and Validation Rules for Common Data File formats Page 40 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1069,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.124Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.11 Lack of renewal —Legal Entity......ccccoeeviviieeiiiiiiiiee i scvvieeeessivieeeessssennnn. 107\n4.12 Lack of renewal — Related Legal Entity including head offices, fund managers,\numbrella and master fuNdS.........cccveeeiiiiiieiiere e ineee e e 107\n4.13 Update of LEI Reference Data due to Legal Entity Events .........ccccceevvvveeeeine.. 107\n4.13.1Legal Entity Event — Event timeline and status..........cccecceevviviiieeeinisceeeecnsiieeenn. 108\n4.13.2Legal Entity Event — Legal Name changes ......cccccevvveeeeivvieeesicciiieeececsiieeeseesvveeen e, 109\n4.13.3Legal Entity Event — Business or trading name changes ........ccccccceeevieeeiiiiiieennnnn, 112\n4.13.4Legal Entity Event — Address information changes........ccccevveevcvecviecceeeninennnn. 114\n4.13.5Legal Entity Event — Legal form changes........cccccvvveeveeecieeevcie e ceeecvvieeeeeesveees 116\n4.13.6Legal Entity Event — ACQUISITION ....coivviiiiieiiiiiie e csiieee s seeeee s esseveeee e 124\n4.13.7Legal Entity Event — AbSOrption ......cccveeeiiiiiieii e ccsiieeeecccrvieesssssvieee s sssnveeeeeees 125\n4.13.8Legal Entity EVENt — IMEIEI ..ccveeieeieiieeie ettt cssriitee et eesssavie e asssvseee s ssssveneeanns 128\n4.13.9Legal Entity Event — Transformation of a Subsidiary to an International Branch 131\n4.13.10 Legal Entity Event — Acquisition of an International Branch.......................... 134\n4.13.11 Legal Entity Event — Break-up ....ccccccceeeviieeiieiiieee s cciieeeeceviieeessesiieee s sssnieeeeeens 137\n4.13.12 Legal Entity Event — DeMErger....cccuveiivviviieiiiiieeeeeisieeeesssiieeessssneeessssvenneanns 140\n4.13.13 Legal Entity Event — Spin-0ff ......cccccoeiiiiiiie et sie e 142\n4.13.14 Legal Entity Event — Transformation of an International Branch to a Subsidiary\n144\n4.13.15 Legal Entity Event —BankruptCy .....ccccevvvveericiviieenscisiieeesecivieessessvieeesessvveneeeens 147\n4.13.16 Legal Entity Event — INnSOIVENCY.....uveevivviiiiiiiiiiiie e criieeeesssieee e essiieeee e 150\n4.13.17 Legal Entity Event — Liquidation.......ccccceuveeiiiiviieeiiiniieiecssiieeecsssieeeeessieeeeenns 150\n4.13.18 Legal Entity Event — DisSOIULION ......cccccviiiiiiiiiieee s cciiieeecciiieeeseesiieee s eesiieeeeeees 151\n4.13.19 Legal Entity Event — Voluntary Arrangement.........ccccceeveeviveeriecsieeeseesveenneens 151\n4.13.20 Legal Entity Event — Reverse Tak@oVver ......cccoceeeeivvveeieenniieeeinssieeesensnenneenns 154\n4.13.21 Legal Entity Event — Transformation of an Umbrella Fund to a Stand-Alone\n4.13.22 Legal Entity Event — Effects on parent and child relationships...................... 158\n4.13.23 Legal Entity Event — Erroneously introduced Legal Entity Event ................... 160\n4.14 Update of LEI Reference Data other than due to Legal Entity Events ................ 162\n4.15 LEI Record update — Registration information changes..........cccccceeviiiieeni . 162\n4.16 LEI Record update — Reporting Exception changes to Relationship Records......162\n4.17 LEI Record Set update — Entity or Relationship Data changes..........ccccceeeeeeee.. 163\n4.18 LEI Record Set update — Change of fund manager ........ccccoevvvvveievviiiiieeee i 163\n4.19 LEI Record Set update — Transfer......occcvveeviiiiiieiee i csssieee s sieieee s sssineen. 163\n4.20 Registration errors — Exclusivity Violation (duplication)......c...cccccevvveeeieeeen... 167\n4.21 Registration error — Relationship Record or reporting exception is a duplicate 167\n4.22 Registration error — Eligibility violation (invalid LEl issuance) ............................ 168\n4.23 Issue New LEl for an US company incorporated in one state but operating in\nANOTNET oo s e e s s s sanaae e e s s snsssaeeeses LO8\nG State Transition and Validation Rules for Common Data File formats Page 5 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":3843,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.124Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o Iflei:LEIRecord, rr:Relationship or repex:ReportingException is empty, then RecordCount SHALL\nbe 0.\no RecordCount SHALL NOT be negative (less than 0).\n3.7 Extension (applicable to multiple Header Sections and data\nsections)\nlei:Extension\nrr:Extension\nrepex:Extension\nThis Extension element contains any additional elements required to\nextend the Header or data container element.\n~/lei:Extension\n~/rr:Extension\n~/repex:Extension\no Extension elements MAY be included in all Header Sections and several data section elements\n(see corresponding .xsd files for details).\no There are no restrictions on the contents of the Extension element. For this reason, it is\nrecommended to inform recipients which elements to expect here.\nState Transition and Validation Rules for Common Data File formats Page 41 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":909,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.124Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.8 LEI Record\nContains LEI Reference Data including details of the LEI's registration\nwith the ManagingLOU.\n_ /lei:LEIData/lei:LEIRecords/lei:LEIRecord\nThe LEI Record is a container holding all Level 1 Reference Data including Entity Data and details of\nthe LEI's Registration with the ManagingLOU.\no Optional Extension elements MAY be included.\n3.9 LEI Code (context: LEI-CDF)\nThe 1SO 17442 compatible identifier for the Legal Entity described in\nthe Entity section.\n_ /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:LEl\ne The LEI Code SHALL be ISO 17442 compliant.\ne An LElI Code SHALL be used only once (uniqueness).\n¢ Only one LEl per Legal Entity may be reported (exclusivity).\no The LEl issuer SHALL be responsible for checking for duplicate LEls (uniqueness and exclusivity)\nprior to issuing, updating, renewing and transferring an LEl and publishing the LEI Record Set.\nState Transition and Validation Rules for Common Data File formats Page 42 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1060,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.124Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.10 Legal Name\n\n_ The legal name of the Legal Entity.\n\n_ /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:LegalName\n\no LegalName SHALL be the legal name of the entity in a local language and character set commonly\nused in the registration authority or in other authoritative validation sources.\n\n¢ LegalName SHALL be the primary legal name in case of being in a jurisdiction with more than one\nlegal name (e.g., in different languages).\n\n3.11 Other Entity Names\n\n_ lei:OtherEntityNames\n\nAn optional list of other names (excluding transliterations) for the\nLegal Entity.\n\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity\n/lei:OtherEntityNames\n\nThe OtherEntityNames element is a container including one or more other names for the Legal Entity\n\ntogether with a specification of a name type.\n\no The Legal Entity MAY provide an official, registered name for the Legal Entity in another language\nor a translated version of the entity's legal name. However, as far the local registry provides a\ntranslated or transliterated version of the legal name, these SHALL be made available in the\nappropriate element as part of the LEI Record Set.\n\nState Transition and Validation Rules for Common Data File formats Page 43 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1330,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.124Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"¢ Avalue of type OtherEntityName in a file conforming to this standard SHALL include an optional\nlanguage code, permitting OtherEntityName to be repeated as many times as necessary to\nexpress the same name type in multiple languages.\n\n¢ The language code of an OtherEntityName with type ALTERNATIVE_LANGUAGE_LEGAL_NAME\nSHALL NOT be the same as the LegalName's language code.\n\no OtherEntityName with type PREVIOUS_LEGAL_NAME SHALL NOT be the same as the current\nLegalName.\n\no OtherEntityName with type TRADING_OR_OPERATING_NAME SHALL NOT be the same as the\ncurrent LegalName.\n\n3.12 Transliterated Other Entity Names\n\n_ lei:TransliteratedOtherEntityNames\n\nAn optional list of ASClI-transliterated (i.e. Latin- or Romanized)\nrepresentations of names for the Legal Entity.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity\n/lei:TransliteratedOtherEntityNames\n\nThe TransliteratedOtherEntityNames element is a container including one or more transliterated\n\nnames for the Legal Entity together with a specification of the transliteration procedure.\n\no If populated, the TransliteratedOtherEntityNames SHALL include a list of ASClI-transliterated (i.e.\nLatin- or Romanized) representations of names for the Legal Entity in all cases of non-romanized\nLegalName.\n\no The general rules for transliteration SHALL apply (see section 2.9).\n\nState Transition and Validation Rules for Common Data File formats Page 44 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1513,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.124Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.13 Legal Address\nThe address of the Legal Entity as recorded in the registration of the\nLegal Entity in its legal jurisdiction.\n\n_ /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:LegalAddress\n\nThe LegalAddress element is a container including mandatory and optional elements comprising the\n\nentity’s legal address.\n\no LegalAddress SHALL be the address of the entity as recorded in the registration of the entity.\n\ne For an International Branch, LegalAddress SHALL be the address of the entity in the host country.\n\ne Forafund entity, LegalAddress SHALL be a current address provided in the business registry in\nwhich the entity was formed (for funds that are incorporated) or by the financial regulatory\nauthority where the entity is registered (for all other cases). If no such address is provided, a\nregistered address from the fund’s constituting documents SHALL be recorded as LegalAddress. If\nsuch documents are also not available, the registered address of the fund managing entity\nresponsible for the legal affairs of the fund SHALL be recorded as LegalAddress. In this case, a\n“care of” address structure (MailRouting) SHALL be used to signal that the address is one of a\ndifferent entity. See the LEI ROC policy on Fund Relationships and Guidelines for the registration\nof Investment Funds in the Global LEI System?® for details.\n\no If the entity is not registered, LegalAddress SHALL be the address mentioned in any document\nused to validate the existence of the entity, or, in lack of, the entity's declared center of control\n(same as HeadquartersAddress).\n\no The general rules for reporting addresses SHALL apply (see section 2.7).\n\n5 https://www.leiroc.org/publications/gls/roc_20190520-1.pdf\n\nState Transition and Validation Rules for Common Data File formats Page 45 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1901,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.124Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.14 Headquarters Address\n\n_ lei:HeadquartersAddress\n\n_ The address of the headquarters of the Legal Entity.\n\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Entity/lei:HeadquartersAddress\n\nThe HeadquartersAddress element is a container including mandatory and optional elements\n\ncomprising the entity’s headquarters address.\n\n¢ HeadquartersAddress SHALL be the address of the main office or center of control of a company\nor organization.\n\n¢ HeadquartersAddress MAY be the same as the LegalAddress of the Legal Entity.\n\ne For an International Branch, HeadquartersAddress SHALL be the address of the head office.\n\no For afund entity, HeadquartersAddress SHALL be the registered address of the fund managing\nentity. A “care of” address structure (MailRouting) SHALL be used to signal that the address is\none of a different entity.\n\ne For a Government Entity, HeadquartersAddress SHALL be the address of the entity itself or the\naddress of the authorized entity managing the LEI registration on behalf of the Government\nEntity. The address MAY be the same as LegalAddress. If another entity manages the registration,\na “care of” address structure (MailRouting) SHALL be used including the name of the entity\nmanaging the LEI registration.\n\ne For an International Organization with distributed field operations and no discernable main office\nor center of control, HeadquartersAddress SHALL be the location of a secretariat or similar\nadministrative central function.\n\no The general rules for reporting addresses SHALL apply (see section 2.7).\n\nState Transition and Validation Rules for Common Data File formats Page 46 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1723,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.125Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.15 Other Addresses\nAn optional list of other addresses for the Legal Entity, excluding\ntransliterations.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Entity/lei:OtherAddresses\nThe OtherAddresses element is a container including one or more other addresses associated with\nthe Legal Entity, including a specification of the type of address.\n¢ The language code of another address with type ALTERNATIVE_LANGUAGE_LEGAL_ADDRESS\nSHALL NOT be the same as that of the Legal Entity's LegalAddress.\n¢ The language code of any other address of type\nALTERNATIVE_LANGUAGE_HEADQUARTERS ADDRESS SHALL NOT be the same as that of the\nLegal Entity's primary HeadquartersAddress.\no Addresses in alternative languages SHALL describe the same location but SHALL NOT be literally\nidentical across all fields included.\ne The general rules for reporting addresses SHALL apply (see section 2.7).\n3.16 Transliterated Other Addresses\n_ lei:TransliteratedOtherAddresses\n_ An optional list of transliterated addresses for the Legal Entity.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Entity/lei:TransliteratedOtherAddresses\nState Transition and Validation Rules for Common Data File formats Page 47 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1286,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.125Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"The TransliteratedOtherAddresses element is a container including one or more transliterations of\nthe Legal Entity’s addresses.\no The general rules for reporting addresses SHALL apply (see section 2.7).\no The general rules for transliteration SHALL apply (see section 2.9).\n3.17 Registration Authority\n_ lei:RegistrationAuthority\nInformation about the official authority in the Legal Entity's\njurisdiction of legal registration, for example a business registry, and\nthe corresponding identification of the Legal Entity by that official\nsource.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Entity/lei:RegistrationAuthority\nThe RegistrationAuthority element is a container including a mandatory RegistrationAuthoritylD and\nthe optional RegistrationAuthorityEntitylD and OtherRegistrationAuthoritylD. The Legal Entity is\nresponsible to supply its local Registration Authority and identifier. This is for mapping to the local\nRegistration Authority.\no The rules for using GLEIF Registration Authority codes SHALL apply (see section 2.2.3)\nState Transition and Validation Rules for Common Data File formats Page 48 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1220,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.125Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.18 Registration Authority ID\n_ lei:RegistrationAuthoritylD\nThe reference code of the Registration Authority, taken from the\nRegistration Authorities Code List maintained by GLEIF.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity\n/lei:RegistrationAuthority/lei:RegistrationAuthoritylD\no RegistrationAuthoritylD SHALL be populated with a valid code from the Registration Authorities\nlist.\no For Legal Entities that are not registered in a registry, RegistrationAuthoritylD SHALL be\nRA999999.\no For EntityCategory BRANCH RegistrationAuthoritylD SHALL NOT be populated with the value\nRA999999.\no The general rules for Registration and Validation SHALL apply (see section 2.2).\n3.19 Other Registration Authority ID\n_ lei:OtherRegistrationAuthoritylD\nA legacy / historical reference code of a Registration Authority which\nis not yet entered in the Registration Authorities Code List (RA list)\nmaintained by GLEIF, or the designation of an interim register until\nsuch time as an entry from RA list can be delivered.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity\n/lei:RegistrationAuthority/lei:OtherRegistrationAuthoritylD\no OtherRegistrationAuthoritylD MAY be present when RegistrationAuthoritylD is populated.\nState Transition and Validation Rules for Common Data File formats Page 49 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1400,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.125Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o If RegistrationAuthorityID is RA888888, OtherRegistrationAuthoritylD SHALL include the name of\nthe Registration Authority, as submitted in the request sent to GLEIF to add a new code to the RA\nlist (see section 2.2.3).\n3.20 Registration Authority Entity ID\n_ lei:RegistrationAuthorityEntitylD\nThe identifier of the Legal Entity at the indicated Registration\nAuthority. Typically, the identifier of the Legal Entity as maintained by\na business registry in the jurisdiction of legal registration, or if the\nLegal Entity is one that is not recorded in a business registry, the\nidentifier of the Legal Entity in the appropriate Registration Authority.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity\n/lei:RegistrationAuthority/lei:RegistrationAuthorityEntitylD\no If the Registration Authority provides an entity ID, RegistrationAuthorityEntitylD SHALL be\npopulated with the entity ID from the register. If the authoritative source does not provide an\nentity ID, RegistrationAuthorityEntitylD SHALL NOT be included. This applies also, if RA888888 is\nused.\no RegistrationAuthorityEntitylD SHALL be populated, if lei:ValidationSources is\nFULLY_CORROBORTATED or PARTIALLY_CORROBORATED, with following exceptions:\n¢ The Legal Entity category (EntityCategory) is marked as FUND.\no RegistrationAuthorityEntitylD SHALL NOT be populated, if RegistrationAuthorityID is RA999999\nor one of the RA Codes identifying sources known to not providing an entity ID.\nState Transition and Validation Rules for Common Data File formats Page 50 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1634,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.125Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.24 Issue New LEI — Financial institution inthe US ............ccoe il 169\nAbout this Document\nThis document describes Business Rules for the issuance, updating, management and publication of\nLEI Reference Data according to the Common Data File (CDF) formats LEI-CDF 3.1, RR-CDF 2.1 and\nRepex-CDF 2.1.\nChange History\nThis section records the history of all changes to this document.\n2023-03-07 2.7.1 Clarified use of legal form for international branches GLEIF\n(3.21)\n2023-02-09 2.7 Add use cases for corporations and financial GLEIF\ninstitutions in the US (4.23, 4.24)\nProvide additional clarification on existing rules and\nguidelines for branches, funds in formation, and legal\nentity events (3.24, 3.31, 3.40, 3.52, 3.58, 4.2, 4.3, 4.4,\n4.8,4.13.1).\nRemove references which elements have been\nadded/deprecated in the latest CDF transition.\n2022-04-01 2.6 Added chapter 4.13.23 on resolving incorrectly GLEIF\nreported Legal Entity Events\nProvide additional clarification on existing rules and\nguidelines (2.1.2, 2.3.2, 2.7, 3.20, 3.26, 3.27, 3.36, 3.46,\n3.60, 3.61, 4.6, 4.13.1, 4.13.5, 4.13.9, 4.13.17, 4.13.18\nState Transition and Validation Rules for Common Data File formats Page 6 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1297,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.126Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.21 Legal Jurisdiction\n_ lei:Legallurisdiction\nThe jurisdiction of legal formation of the Legal Entity; i.e. where the\nlegal form of the Legal Entity originates.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Entity/lei:Legallurisdiction\no Legallurisdiction SHALL be a country or subdivision code from the GLEIF Accepted Legal\nJurisdictions Code List (https://www.gleif.org/en/about-lei/code-lists/gleif-accepted-legal-\njurisdictions-code-list). As per July 2020, all LEls SHALL be compliant with this list.\no Legallurisdiction SHALL contain the country or region where the Legal Entity Form originates. As\nsuch, the content of Legallurisdiction is linked to the content of LegalForm.\ne A company with a legal form from country A which has its address(es) in country B SHALL have A\nas its Legallurisdiction.\n¢ An International Branch SHALL always have the LegalForm and Legallurisdiction of the Legal\nEntity to which it belongs.\no For an International Organization established by treaties or other specific multinational\nagreements governed by international laws, Legallurisdiction SHALL be one of the following:\no UN, if the entity is the United Nations, one of their specialized agencies or other affiliated\norganizations.\no EU, if the entity is established by a treaty signed by all members of the European Union and\nno other countries.\no XX, in all other cases.\nState Transition and Validation Rules for Common Data File formats Page 51 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1550,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.126Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.22 Entity Category\nIndicates (where applicable) the category of Legal Entity identified by\nthis LEI Record, as a more specific category within the broad\ndefinition given in ISO 17442. These categories are based on Use\nCases specified in LEI-ROC policies, found at\nhttp://www.leiroc.org/list/leiroc_gls/index.htm.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Entity/lei:EntityCategory\n\nEntityCategory contains the general category of certain types of Legal Entities that are subject to\n\nspecial rules within the Global LEI System.\n\no For Legal Entities that are funds, individuals acting in a business capacity or International\nBranches, the EntityCategories of FUND, SOLE_ PROPRIETOR or BRANCH SHALL be assigned,\nrespectively.\n\no For Legal Entities that are Government entities, the EntityCategory\nRESIDENT_GOVERNMENT_ENTITY SHALL be assigned with an appropriate sub-category, where\napplicable.\n\no For organizations established by international agreement that may not be (only) subject to the\nlaws or regulations of the country or countries in which they are located, the EntityCategory\nINTERNATIONAL_ORGANIZATION SHALL be assigned.\n\no For Legal Entities that are not funds, individuals acting in a business capacity, International\nBranches, Government entities or International Organizations, the EntityCategory of GENERAL\nSHALL be assigned .\n\nAn LEI Record SHALL be identified as BRANCH, if:\n\n¢ The Branch is an International Branch as defined, outside of the head office’s jurisdiction. For\npurposes of the LEI-ROC policy document, jurisdiction is synonymous with country and\nInternational Branch is defined as a non-incorporated establishment of a Legal Entity, when this\nestablishment is located in a separate jurisdiction from the jurisdiction in which the head office\nof the (same) Legal Entity is located, i.e., in a host jurisdiction outside of its home jurisdiction.\nUnder this definition, an establishment may consist of a single office or other business premises,\n\nState Transition and Validation Rules for Common Data File formats Page 52 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2164,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.126Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"or of several offices (i.e., a branch network) in different locations of the same host jurisdiction:\neven in the latter case, only one LElI would be issued per host jurisdiction, essentially amounting\nto, one country-one LEI. Unlike foreign subsidiaries of a parent entity, which are separately\nincorporated as separate Legal Entities or organized under the laws of the host jurisdictions, an\nInternational Branch, as defined here, is legally dependent on the (head office) Legal Entity it\nbelongs to and cannot exist without its (head office) Legal Entity;\n\ne The Branch is registered in a publicly accessible local business registry, local regulatory registry or\ntax registry, preferably an RA source;\n\no The Legal Entity the Branch belongs to already has an LEIl so that the LEI of the (head office) Legal\nEntity can always be associated with the LEI of the International Branch in the Global LEI System;\nand\n\no The Reference Data of the International Branch in the LEI system includes a Branch relationship\nlinking the Branch to its (head office) Legal Entity.\n\nAn LEI Record SHALL be identified as FUND, if:\n\n¢ Inline with the governance principles of the Global LEI System, the Legal Entity reports being an\ninvestment fund, defined as a collective investment scheme (or pooled investment) beneficially\nowned by multiple investors and managed on behalf of those investors by an asset manager or\nby the fund itself.\n\n¢ Investment funds or collective investment schemes MAY not always be registered, or MAY be\nsubject to varying degrees of regulation, and there is therefore no single legal or regulatory\ndefinition. Above definition of fund entities SHALL apply to funds incorporated as a company as\nwell as funds established by contract.\n\no The LElissuer SHALL verify that the report of the Legal Entity being a fund is correct. LEl issuers\nare not required to verify whether an entity not reporting itself as a fund is a fund, except\nminimum due diligence including:\n\no whether the name of the fund includes the mention that it is a fund or any equivalent in the\nrelevant language and legal framework;\n\no whether the legal form necessarily means that the entity is a FUND;\n\n* whether the registry used to establish the existence of the entity is specific to funds;\n\no if the LEl of the Legal Entity is the EndNodelD of an ACTIVE relationship with\nRelationshipType IS_FEEDER_TO.\n\nAn LEI Record SHALL be identified as SOLE_PROPRIETOR, if:\n\nState Transition and Validation Rules for Common Data File formats Page 53 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2628,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.126Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"¢ The entity is a type of enterprise that is owned and operated by one person or family\nbusiness (married couple, mothers, fathers, siblings, etc.) and in which there is no legal\ndistinction between the owner’s assets and liabilities and the business entity.\no The person or family business has unlimited personal responsibility for all losses and debts.\n¢ Inseveral countries it would be possible to identify a Sole Proprietor from the business registry\n(RA source); in such cases all Registration Authority information should be incorporated.\nAn LEI Record SHALL be identified as RESIDENT_GOVERNMENT _ENTITY, if:\n¢ The Legal Entity is a non-market producer, part of a central, state or local government, social\nsecurity funds or a non-profit institution (NPI) controlled by government units.\no The definition of Government Entities® in the Global LEl System is in line with the underlying ISO\n17442 standard and further guided by the System of National Accounts (SNA).\no Astate owned, but independent general Legal Entity or Fund not part of or controlled by the\ngovernment SHALL NOT be categorized as RESIDENT_GOVERNMENT_ENTITY but rather as\nGENERAL or FUND, respectively.\nAn LEI Record SHALL be identified as INTERNATIONAL_ORGANIZATION, if:\no The Legal Entity is a non-resident unit, created by international agreement or other\narrangements for the provision of non-market services or financial intermediation at the\ninternational level.\no The special characteristics of an “international organization” as this term is used in the SNA may\nbe summarized as follows:\n¢ The members of an international organization are either national states or other\ninternational organizations whose members are national states; they thus derive their\nauthority either directly from the national states that are their members or indirectly from\nthem through other international organizations.\n\n¢ They are entities established by formal political agreements between their members that\nhave the status of international treaties; their existence is recognized by law in their member\ncountries.\n\n* Because they are established by international agreement, they are accorded sovereign\nstatus; that is, international organizations are not subject to the laws or regulations of the\n\n8 https://www.leiroc.org/publications/gls/roc_20201229.pdf\n\nState Transition and Validation Rules for Common Data File formats Page 54 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2504,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.126Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"country, or countries, in which they are located; they are not treated as resident institutional\nunits of the countries in which they are located.\n¢ International organizations are created for various purposes including, among others, the\n\nfollowing types of activities:\n\ne The provision of non-market services of a collective nature for the benefit of their\nmembers.\n\n¢ Financial intermediation at an international level, that is, channeling funds between\nlenders and borrowers in different countries.\n\n3.23 EntitySubCategory\n\nIndicates and specifies further (where applicable) the sub-category\n(sub-sector) of Legal Entity identified by this LElI Record and already\ncategorized by the EntityCategory field.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Entity/lei:EntitySubCategory\n\nEntitySubCategory contains the sub-category/sub-sector of certain categories of Legal Entities that\n\nare subject to special rules within the Global LEI System.\n\no Legal Entities other than RESIDENT_GOVERNMENT_ENTITY (i.e., GENERAL, FUND, BRANCH,\nSOLE_PROPRIETOR, INTERNATIONAL ORGANIZATION) SHALL NOT declare any subsector or sub-\ncategory.\n\no Legal Entities that are classified as RESIDENT_GOVERNMENT_ENTITY in the EntityCategory field\nSHALL declare its Government subsector, if available and applicable.\n\nFigure 5 provides a schematic overview of the structure of a General Government and sets the\n\nbaseline for the subsector definitions.\n\nState Transition and Validation Rules for Common Data File formats Page 55 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1611,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.127Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"General Government\nCentral Administration\nState Government\nSocial Security\nFunds Local Government\nLocal Local Local Local Local Local\nGovernment Government Government Government Government Government\nAl A2 B1 B2 C1 C2\nLocal Local Local Local Local Local\nGovernment Government Government Government Government Government\nA3 A4 B3 B4 c3 c4\nPublic corporation 1 Public corporation 2 Public corporation 3 Public corporation n\no\n\nFigure 5: Scheme of a General Government\n\nAn LEI Record SHALL be identified as CENTRAL_GOVERNMENT, if:\n\n¢ The central government subsector consists of the institutional units plus non-profit institution\n(NPI) controlled by the central government institutions (paragraph 4.134 of the SNA). Paragraph\n4.135 of the SNA defines central administration as comprising all institutional units that extend\ntheir authority over the entire territory of the country.\n\nAn LEI Record SHALL be identified as STATE_GOVERNMENT, if:\n\no The state government subsector consists of the institutional units that exercise some\ngovernment functions at a level below that of the central government and above that of the\ngovernment institutional units existing at a local level. These are institutional units whose fiscal,\nlegislative and executive authority extends over individual states in which the country, as a\nwhole, may be divided. In some countries, especially small countries, individual states and state\ngovernments may not exist (paragraph 4.141 of the SNA). The state government usually has the\nfiscal authority to levy taxes on institutional units that are resident in or engage in economic\nactivities or transactions within its area of competence (paragraph 4.142 of the SNA).\n\nAn LEI Record SHALL be identified as LOCAL_GOVERNMENT, if:\n\n¢ The local government subsector consists of local governments that are separate institutional\nunits. The scope of their authority is generally much less than that of central government or state\ngovernments, and they may or may not, be entitled to levy taxes on institutional units resident in\n\nState Transition and Validation Rules for Common Data File formats Page 56 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2230,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.127Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"their areas (paragraph 4.145 of the SNA).\n\nAn LEI Record SHALL be identified as SOCIAL_SECURITY, if:\n\ne Social security schemes are social insurance schemes that cover the community as a whole or\nlarge sections of the community and are imposed and controlled by government units. The\nschemes cover a wide variety of programmes, providing benefits in cash or in kind for old age,\ninvalidity or death, survivors, sickness and maternity, work injury, unemployment, family\nallowance, health care, etc. (paragraph 4.124 of the SNA). They can operate at all levels of\nGovernment (paragraph 4.147 of the SNA). When social security schemes are separately\norganized from the other activities of government units and hold their assets and liabilities\nseparately from the latter and engage in financial transactions on their own account, they qualify\nas institutional units that are described as social security funds. However, institutional\narrangements in respect of social security schemes differ from country to country and in some\ncountries they may become so closely integrated with the other finances of government as to\nbring into question whether they should be treated as separate institutional units. (paragraph\n4.125 of the SNA).\n\nIf a Government Entity does not fit the definitions of one of these sub-categories, EntitySubCategory\n\nSHALL NOT be provided.\n\n3.24 Legal Form\n\n_ The legal form of the Legal Entity.\n\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:LegalForm\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:LegalForm\n\n/lei:EntityLegalFormCode\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:LegalForm\n/lei:OtherLegalForm\n\nThe legal form of the Legal Entity is represented by the LegalForm container. It consists of two\n\nelements: EntityLegalFormCode and OtherLegalForm.\n\no EntityLegalFormCode SHALL be taken from the ISO 20275 Entity Legal Form (ELF) Code list\nmaintained by GLEIF.\n\nState Transition and Validation Rules for Common Data File formats Page 57 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2108,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.127Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o If EntityCategory is not BRANCH, the ELF code SHALL have a legal jurisdiction matching the LEI’s\nLegallurisdiction.\no If EntityCategory is BRANCH, LegalForm SHALL be the legal form of the (head office) Legal Entity.\ne For an International Organization, LegalForm SHALL be 9999, the reserved code for jurisdictions\nnot on the ELF code list. OtherLegalForm SHALL include the name of the treaty establishing the\nentity. If a series of treaties or updates of treaties were signed to form the entity, only the latest\none establishing it in its current form SHALL be included.\no The general rules for Entity Legal Form Reporting SHALL apply (see section 2.8).\ne If one of the reserved ELF codes is used, OtherLegalForm SHALL be present.\no If any non-reserved ELF code is used, OtherLegalForm SHALL be omitted.\n3.25 Entity Status\nThe operational and/or legal registration status of the Legal Entity\n(may be ACTIVE, INACTIVE or NULL).\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Entity/lei:EntityStatus\nThe EntityStatus of an LEI Record SHALL indicate the status of the Legal Entity itself. It is linked to\nother data fields related to especially INACTIVE entities or records (e.g., SuccessorLEl,\nRegistationStatus).\no If EntityStatus is set to ACTIVE, the RegistrationStatus SHALL NOT be set to RETIRED.\no Accepted values for the field are:\no ACTIVE: As of the last report or update, the Legal Entity reported that it was legally registered\nand operating.\no INACTIVE: It has been determined that the Legal Entity that was assigned the LEl is no longer\nlegally registered and/or operating, as indicated by a recorded Legal Entity Event.\ne NULL: Providing an ACTIVE or INACTIVE status of the Legal Entity is not applicable .\nState Transition and Validation Rules for Common Data File formats Page 58 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1904,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.127Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o If EntityStatus is set to INACTIVE, the RegistrationStatus SHALL NOT be set to either ISSUED or\nLAPSED and SHALL NOT be PENDING_TRANSFER or PENDING_ARCHIVAL, except for very rare\ncases that require the transfer of an LEI Record representing an inactive Legal Entity.\n\n¢ The EntityStatus is set to NULL in following cases:\n\no The LEl reaches one of the end stages of its lifecycle representing an error — ANNULLED or\nDUPLICATE.\no The LElisissued for a FUND entity in a jurisdiction (e.g., Spain), where the existence of an LElI\nis a prerequisite to be able to register the entity itself (see section 4.3).\n3.26 Entity Creation Date\nThe date on which the Legal Entity was first established, as\nrepresented by ISO 8601 (as defined in ISO 17442).\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/\nlei:EntityCreationDate\n\no The date when the Legal Entity has been created, formed or incorporated SHALL be provided for\nall LEI Record Sets not yet reached an end stage of their lifecycle.\n\n¢ The information SHALL be extracted from the local registry (if applicable and the entity is a\nregistered entity) or from the legal documents provided by the entity (in case of entity supplied\ndata only). This information provides additional value to the LEI Record Set and will simplify the\nefforts with future mapping partners. It will also enable a high-automated process for mapping\nand potential duplicate identification.\n\n¢ The date provided SHALL be in ISO 8601 datetime format with a minimum value 0001-01-\n01T00:00:00.\n\n¢ If only the year and month of the creation are known and no information about the exact day of\nthe month is availble, the LEIl issuer SHALL use the first day of the respective month.\n\n¢ If the entity is a BRANCH, EntityCreationDate SHALL be the date of the creation of the Branch\nitself and not the date of the creation of the (head office) Legal Entity to which it belongs.\n\nState Transition and Validation Rules for Common Data File formats Page 59 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2080,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.127Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.27 Successor Entity\n\n_ One or more Legal Entities that continue or replace this LEI.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Entity/lei:SuccessorEntity\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Entity/lei:SuccessorEntity/lei:SuccessorLEl\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Entity/lei:SuccessorEntity/lei:SuccessorEntityName\n\nThe SuccessorEntity element is a container including one or more successor entities, identified by\n\neither an LEl or by legal name.\n\no The SuccessorEntity container SHALL be used to report the surviving or new LEI Record Set in\ncases of an Exclusivity Violation or when a Legal Entity Event occurred, requiring the provision of\none or more Successor Entity information.\n\no The SuccessorEntity SHALL be identified either by LEl or by LegalName.\n\no If RegistrationStatus is DUPLICATE, SuccessorLEI SHALL include the LEI of the surviving LEI\nRegistration and SuccessorEntityName SHALL NOT be included.\n\no If one of the following Legal Entity Events has been recorded in the LegalEntityEvents section, the\nSuccessorLElI SHALL be provided, in case the successor Legal Entity holds an LEI; and\nSuccessorEntityName SHALL be provided, in case the successor Legal Entity does not hold an LEI:\no DEMERGER\no SPINOFF\no ACQUISITION_BRANCH\no TRANSFORMATION_BRANCH_TO_SUBSIDIARY\no TRANSFORMATION_UMBRELLA_TO_STANDALONE\no BREAKUP\n+ MERGERS_AND_ACQUISITIONS\n\no If one of the following Legal Entity Events involves a successor entity, the SuccessorLElI SHALL be\nprovided, in case the successor Legal Entity holds an LEI; and SuccessorEntityName SHALL be\nprovided, in case the successor Legal Entity does not hold an LEI:\n\nState Transition and Validation Rules for Common Data File formats Page 60 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1838,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.127Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"2021-12-22 2.5 Added use case for change in fund management (4.18). | GLEIF\nProvide additional clarification on existing rules and\nguidelines (2,2,3, 2.8, 3.24, 3.29, 3.33, 3.36, 3.51, 3.61,\n4.2,4.4,4.7,4.13.1,4.13.3,4.13.4, 4.13.5, 4.13.8,\n4.13.9,4.13.13, 4.13.15, 4.13.16, 4.13.19, 4.21)\n\n2021-09-30 2.4 Provide additional clarification on existing rules and GLEIF\nguidelines (3.36, 3.51, 3.53 several use cases in chapter\n4)\n\nReflect changes due to Repex-CDF 1.2 (3.65, 4.14) and\ndeprecation of the Provisional Node Identifier (PNI)\n(2.1.2,2.2.2,3.49,4.1.2,4.8,4.9,4.13.22, 4.18, 4.20)\nIntroduction of RA777777 (2.2.3, 3.44, 3.45, 3.46, 4.6,\n4.7)\n\n2021-06-21 2.3 Provide additional clarification on existing rules and GLEIF\nguidelines (3.20, 3.23, 3.30, 3.46, 3.57, 4.18)\n\n2021-03-08 2.2 Introduced changes due to ROC policy on Government | GLEIF\nEntities and International Organizations (3.22, 3.23,\n3.53,4.6,4.7)\n\nProvide additional clarification on existing rules and\nguidelines\n\n2020-12-17 2.1 Highlight text elements and paragraphs with the CDF GLEIF\nformat version when these become effective\nProvide additional clarification on existing rules and\nguidelines (2.2, 2.3, 3.20, 3.26, 4.1, 4.11)\n\n2020-07-31 2.0 Updated general structure of the document GLEIF\nCombined STVR for Level 1 and Level 2\nUpdated general rules in chapter 2 to clarify existing\nrules and guidelines (2.2, 2.3, 2.7, 2.8, 2.9)\n\nIncluded per element description and rules for relevant\n\nXML elements in chapter 3.\n\nRevised existing and added new Use Cases in chapter 4.\n\nIntroduced changes due to LEI-ROC Fund Relationship\n\npolicy implementation (2.1.2, 3.50)\n\nIntroduced changes due to LEI-ROC Legal Entity Events\n\npolicy implementation (new elements 3.27-3.36)\n\nUpdated description and rules for EntityCategory (3.22)\n\nUpdated description and rules for EntityStatus (3.24)\nState Transition and Validation Rules for Common Data File formats Page 7 of 170\n\n@ Public Version 2.7.1 Final\n\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2036,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.127Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"+ CHANGE_LEGAL_NAME\n+ CHANGE_OTHER_NAMES\n¢ CHANGE_LEGAL_FORM\no BANCRUPTCY\n¢ LIQUIDATION\no If the SuccessorLEl is provided, the SuccessorEntityName SHALL NOT be present and vice versa.\no If the SuccessorLEl is provided, it SHALL NOT have the same LEI as the replaced entity’s LEI\nRecord.\n3.28 Legal Entity Events\n_ lei:LegalEntityEvents\nContainer for a finite number of events specified by the LEI ROC in\nthe life of a Legal Entity that would impact the Reference Data in the\nGlobal LEI System.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity\n/lei:LegalEntityEvents\n¢ The container Legal Entity Events SHALL be provided, when at least one of the Legal Entity Event\ntypes in scope occurred.\no The container SHALL contain at least one Legal Entity Event instance or one Legal Entity Event\nGroup instance.\nState Transition and Validation Rules for Common Data File formats Page 61 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":991,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.127Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.29 Legal Entity Event\n_ lei:LegalEntityEvents\nContainer for a finite number of events specified by the LEI ROC in\nthe life of a Legal Entity that would impact the Reference Data in the\nGlobal LEI System.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity\n/lei:LegalEntityEvents\ne Each Legal Entity Event container SHALL include two to four attributes, associated with event\nstatus and grouping of Legal Entity Events:\no @group_type: This mandatory attribute defines, whether or not this Legal Entity Event is\npart of a group of events. Allowed enumerations:\n\no STANDALONE: Single / standalone Legal Entity Event with no combination of multiple\nevents.\n\no CHANGE_LEGAL_FORM_AND_NAME: Legal Entity Event including change of the legal\nname triggered by change of the legal form.\n\no COMPLEX_CHANGE_LEGAL_FORM: Legal Entity Event including change of the Legal\nEntity status triggered by change of the legal form.\n\ne REVERSE_TAKEOVER: This event is part of a reverse takeover Legal Entity Event.\n\no @event_status: This mandatory attribute defines the status of the Legal Entity Event with\nregard to the event timeline. Allowed enumerations:\n\n* IN_PROGRESS: The Legal Entity Event activity and processing is in progress.\n\no WITHDRAWN_CANCELLED: The Legal Entity Event as announced will not occur.\n\no COMPLETED: The Legal Entity Event activity and processing have been completed as of\nthe LegalEntityEventEffectiveDate.\n\no @group_id: An identifier assigned to link events that are part of the same group of multiple\nor complex events:\n\ne SHALL be the exact same string for all events linked together.\n\ne SHALL be provided for events having a @group_type\nCHANGE_LEGAL_FORM_AND_NAME or REVERSE_TAKEOVER and SHALL NOT be\npopulated for events having a @group_type STANDALONE or\nCOMPLEX_CHANGE_LEGAL_FORM events.\n\nState Transition and Validation Rules for Common Data File formats Page 62 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1989,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.127Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"e @group_sequence_no: A number which indicates the sequence of each Legal Entity Event\nwithin a group of events.\ne SHALL NOT be populated for STANDALONE events.\ne SHALL be provided for event groups with a logical sequence of events, like a\nREVERSE_TAKEOVER event group.\ne SHALL NOT be populated, if the event sequence is not important as all events happen at\nthe exact same time, for example a change in legal name due to a change in legal form\n(event type CHANGE_LEGAL_FORM_AND_NAME).\n¢ The event that happened first SHALL have @group_sequence_no 1 (one), the next 2\n(two), etc. Each @group_sequence_no SHALL be used only once within a group.\n¢ Inorder to describe Legal Entity Events, each Legal Entity Event container SHALL contain the\nfollowing fields:\no LegalEntityEventType\no LegalEntityEventEffectiveDate\no LegalEntityEventRecordedDate\n* ValidationDocuments\n¢ ValidationReference (optional)\no AffectedFields\no LegalEntityEvent elements SHALL NOT be updated.\n¢ Anew LegalEntityEvent element SHALL be created, if an already existing LegalEntityEvent\nchanges its @event_status from IN_PROGRESS to COMPLETED or WITHDRAWN_CANCELLED.\no A LegalEntityEvent with @event_status IN_PROGRESS SHALL NOT be removed in case a\nfollow up event with @event_status COMPLETED or WITHDRAWN_CANCELLED is introduced.\ne A LegalEntityEvent MAY be updated, if only typing errors or similar minor inconsistencies are\nremediated.\nState Transition and Validation Rules for Common Data File formats Page 63 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1592,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.127Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.30 Legal Entity Event Type\n_ lei:LegalEntityEventType\n_ The type of Legal Entity Event.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/\nlei:LegalEntityEvents/lei:LegalEntityEvent/\nlei:LegalEntityEventType\no Legal Entity Event Type SHALL be always provided as part of the descriptive data of a Legal Entity\nEvent\n¢ The following types of Legal Entity Events SHALL be recorded in the Global LEI System as part of\nthe LEI Record Set. Data collection for high priority Legal Entity Events SHALL begin with the\n\nimplementation of LEI-CDF 3.1. Events with a medium or low priority SHALL be collected at a\n\nlater date but MAY also be included earlier.\n\ne High priority Legal Entity Events (to be implemented by 31 March 2022):\n\no CHANGE_LEGAL_NAME: Change in the legal name of the Legal Entity.\n\ne CHANGE_OTHER_NAMES: Change in the trade- or doing business name of the Legal Entity.\n\no CHANGE_LEGAL_ADDRESS: Change in the legal address of the Legal Entity.\n\no CHANGE_HQ_ADDRESS: Change in the Headquarters Address of the Legal Entity.\n\no CHANGE_LEGAL_FORM: Change in the legal form of the Legal Entity.\n\ne ACQUISITION_BRANCH: The acquiring Legal Entity purchases an International Branch entity.\n\no TRANSFORMATION_BRANCH_TO_SUBSIDIARY: The transfer of all of the assets and liabilities\nof a Legal Entity in relation to an International Branch to the new Subsidiary entity in\nexchange for the transfer of securities representing the capital of the Subsidiary entity\nreceiving the transfer.\n\no TRANSFORMATION_SUBSIDIARY_TO_BRANCH: The transfer of all of the assets and liabilities\nof a Subsidiary to an International Branch entity in exchange for the transfer of securities of\nthe Legal Entity to which the Branch belongs, representing the capital of the International\nBranch entity receiving the transfer.\n\no TRANSFORMATION_UMBRELLA_TO _STANDALONE: Change in legal form from a Fund Legal\nEntity structure with one or more than one sub-funds/compartments to a Fund Legal Entity\nstructure without sub-funds/compartments.\n\nState Transition and Validation Rules for Common Data File formats Page 64 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2204,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.128Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o DISSOLUTION: (i) A voluntary termination of operations, (ii) a general assignment for the\nbenefit of the Legal Entity’s creditors or (iii) any other liquidation, dissolution or winding up\nof the Legal Entity (excluding a Liquidity Event), whether voluntary or involuntary.\n\n¢ Medium priority Legal Entity Events (TBD):\n\n» BREAKUP: A break-up is a corporate action in which a single company splits into two or more\nindependent, separately run companies. Regulators also can mandate break-ups of\ncompanies for anti-trust reasons.\n\no MERGERS_AND_ACQUISITIONS: The consolidation of Legal Entities or assets through various\ntypes of financial transactions, including mergers, acquisitions, consolidations, tender offers,\npurchase of assets and management acquisitions.\n\no DEMERGER: Distribution of securities issued by another Legal Entity. The distributed\nsecurities may either be of a newly created or of an existing Legal Entity. For example, spin-\noff, demerger, unbundling, divestment.\n\no SPINOFF: A special case of demerger where the shareholders of the original entity are\ncompensated for the value loss of the original entity via shares of the new entity or via\ndividend.\n\no Low priority Legal Entity Events (TBD):\n\no BANKRUPTCY: Legal status of a Legal Entity unable to pay creditors. Bankruptcy usually\ninvolves a formal court ruling. Securities may become valueless.\n\n¢ LIQUIDATION: Distribution of cash, assets or both of a Legal Entity. Debt may be paid in order\nof priority based on preferred claims to assets specified by the security.\n\no VOLUNTARY_ARRANGEMENT: A procedure that allows a Legal Entity to settle debts by\npaying only a proportion of the amount that it owes to creditors or to come to some other\narrangement with its creditors over the payment of its debts.\n\no INSOLVENCY: The entry of a decree or order by a court or agency or supervisory authority\nhaving jurisdiction in the premises the appointment of a trustee-in-bankruptcy or similar\nofficial for such party in any insolvency, readjustment of debt, marshalling of assets and\nliabilities, or similar proceedings, or for the winding up or liquidation of their respective\naffairs.\n\no ABSORPTION: Absorption is a form of merger where there is a combination of two or more\ncompanies into an 'existing company'. In the case of absorption, only one company survives,\nand all others lose their identity. (The addition of Absorption to the list of Legal Entity Events\ncovered by the policy is under review with the LEI-ROC.)\n\no REVERSE_TAKEOVER: A reverse takeover is the acquisition of a larger, publicly traded\ncompany by a smaller private company. It involves complex series of events including\nacquisition, absorption and name change.\n\nState Transition and Validation Rules for Common Data File formats Page 65 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2896,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.128Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.31 Legal Entity Event Effective Date\n\n_ lei:LegalEntityEventEffectiveDate\n\n_ The date when the Legal Entity Event becomes legally effective.\n\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/\nlei:LegalEntityEvents/lei:LegalEntityEvent/lei:/\nlei:LegalEntityEventEffectiveDate\n\no LegalEntityEventEffectiveDate SHALL provide the date (not considering the time) when the Legal\nEntity Event becomes legally effective, if the date is known or in the past (event_status\nCOMPLETED).\n\no LegalEntityEventEffectiveDate MAY be omitted, if the date is not known (applies only, if the\nevent_status of the Legal Entity Event is IN_PROGRESS or WITHDRAWN_CANCELLED). If the date\nis known for not yet completed Legal Entity Events, LegalEntityEventEffectiveDate SHALL be\nprovided.\n\ne The format SHALL be according to the ISO 8601 standard. The time part of the content SHALL be\nalways '00:00:00' independent of the provided Time Zone.\n\no LegalEntityEventEffectiveDate SHALL be provided as part of the descriptive data of a Legal Entity\nEvent.\n\no LegalEntityEventEffectiveDate SHALL be limited to dates after 0001-01-01T00:00:00.\n\no LegalEntityEventEffectiveDate MAY be equal to LegalEntityEventRecordedDate if the actual\nLegalEntityEventEffectiveDate is not known.\n\nState Transition and Validation Rules for Common Data File formats Page 66 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1437,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.128Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.32 Legal Entity Event Recorded Date\n_ lei:LegalEntityEventRecordedDate\nThe date when the Legal Entity Event was recorded in the Global LEI\nSystem\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/\nlei:LegalEntityEvents/lei:Legal EntityEvent/\nlei:LegalEntityEventRecordedDate\no LegalEntityEventRecordedDate SHALL be always provided as part of the descriptive data of a\nLegal Entity Event.\no LegalEntityEventRecordedDate SHALL provide the date and timestamp when the Legal Entity\nEvent was recorded in the Global LEI System.\no Ifthe event_status is COMPLETED, LegalEntityEventRecordedDate SHALL be equal to, or after the\nLegalEntityEventEffectiveDate.\n3.33 Validation Documents (context: LEI-CDF)\n_ lei:ValidationDocuments\nType of source document(s) used for validating the\nLegal Entity Event.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/\nlei:LegalEntityEvents/lei:Legal EntityEvent/\nlei:ValidationDocuments\no The type of Validation documents used to corroborate the Legal Entity Event SHALL be provided.\ne Currently accepted type of documents to validate Legal Entity Events are:\no ACCOUNTS_FILING: A consolidated financial (accounting) statement, prepared and submitted\nto the relevant authority.\nState Transition and Validation Rules for Common Data File formats Page 67 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1394,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.128Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"¢ REGULATORY_FILING: A regulatory filing providing public information on Legal Entities\nand/or their relationships (e.g.: documents submitted to a (financial) regulator).\ne SUPPORTING_DOCUMENTS: Other documents supporting the validation of Legal Entities\nand/or their relationships (e.g.: business registers or other authoritative sources).\no CONTRACTS: Contract(s) attesting to the validity of Legal Entities and/or their relationships.\no OTHER_OFFICIAL_DOCUMENTS: Other official document(s) attesting to the validity of Legal\nEntities and/or their relationships (e.g.: notarized documents).\n3.34 Validation Reference (context: LEI-CDF)\n_ lei:ValidationReference\nA reference to a specific document or other source used as the basis\nof validation for this Legal Entity Event.\nlei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/\nlei:LegalEntityEvents/lei:Legal EntityEvent/\nlei:ValidationReference\no The content of ValidationReference SHALL contain a reference to a specific document or other\nsource used as the basis of Legal Entity Event Validation for this record.\n3.35 Affected Fields\nA list of LEI Record Set elements that are expected to be updated in\nthe LEI Record Set as a result of a Legal Entity Event.\nlei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/\nlei:LegalEntityEvents/lei:LegalEntityEvent/\nlei:AffectedFields\nAffectedFields is a container element including one or more AffectedField elements.\nState Transition and Validation Rules for Common Data File formats Page 68 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1597,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.128Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o This container SHALL include all relevant changes to the LEI Record Set due to the Legal Entity\nEvent.\n\no This container can only exist within a Legal Entity Event element.\n\n3.36 Affected Field\n\nA single element and its value that is expected to be updated in the\nLEl Record Set as a result of a Legal Entity Event.\nlei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/\nlei:LegalEntityEvents/lei:LegalEntityEvent/\nlei:AffectedFields/lei:AffectedField\n\nEach AffectedField refers to an LEI Record Set element that will be affected by the Legal Entity Event.\n\no AffectedField SHALL include an attribute (@field_xpath), referring to the full Xpath to a single\nelement that is expected to be updated in the LEI Record Set as a result of a Legal Entity Event.\n\no The value of AffectedField SHALL be the expected value of the data element due to Legal Entity\nEvent. Values for Legal Entity Events in progress (@event_status IN_PROGRESS) MAY not be\nalways available, but the LEl issuer SHALL report these elements if available.\n\no For events with @event_status COMPLETED, leading to the introduction of one or more\nSuccessorEntitiy entries, AffectedFields SHALL be provided, presenting the values of the recorded\nsuccessor entities.\n\no If no SuccessorEntity was introduced due to the Legal Entity Event with @event_status\nCOMPLETED or WITHDRAWN_CANCELLED, AffectedFields SHALL NOT be provided.\n\no Expected values for the attribute @field_xpath are:\n\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:LegalName\n\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:OtherEntityNames/lei:OtherEntityNam\ne\n\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:OtherEntityNames/lei:OtherEntityNam\ne@type\n\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:TransliteratedOtherEntityNames/lei:Tr\nansliteratedOtherEntityName\nState Transition and Validation Rules for Common Data File formats Page 69 of 170\n\n@ Public Version 2.7.1 Final\n\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2024,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.128Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:TransliteratedOtherEntityNames/lei:Tr\nansliteratedOtherEntityName@type\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:LegalAddress/*\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:HeadquartersAddress/*\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:OtherAddresses/*\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:TransliteratedOtherAddresses/*\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:Legallurisdiction\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:EntityCategory\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:LegalForm/lei:EntityLegalFormCode\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:LegalForm/lei:OtherLegalForm\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:SuccessorEntity/lei:SuccessorLEl\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:SuccessorEntity/lei:SuccessorEntityNa\nme\no /rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord/rr:Relationship/rr:EndNo\nde/rr:NodelD\no /rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord/rr:Relationship/rr:EndNo\nde/rr:NodeType\no /rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord/rr:Relationship/rr:Relatio\nnshipType\no /[repex:ReportingExceptionData/repex:ReportingExceptions/repex:Exception/repex:Exceptio\nnCategory\no /[repex:ReportingExceptionData/repex:ReportingExceptions/repex:Exception/repex:Exceptio\nnReason\ne For all above mentioned address containers (LegalAddress, HeadquartersAddress,\nOtherAddresses and TransliteratedOtherAddresses) the concrete data elements SHALL be\nprovided.\nState Transition and Validation Rules for Common Data File formats Page 70 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1851,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.128Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Updated description and rules for SuccessorEntity\n(3.26)\nUpdate description and rules for RelationshipStatus\n(3.52)\nDeprecated AssociatedEntity (3.67),\nEntityExpirationDate (3.68) and EntityExpirationReason\n(3.69)\nClarification on branch entities (4.2)\n2018-01-26 1.2 2.2.5 — updated as ELF code list is now available GLEIF\n2.8 - 2\" bullet point updated from\nIf ValidationSources is ENTITY_SUPPLIED_ONLY then\nValidationAuthorityID and ValidationAuthorityEntitylD\nMUST NOT be populated to\nIf ValidationSources is ENTITY_SUPPLIED_ONLY then\nValidationAuthorityID is RA999999\n2.9 — last bullet point: added or RA999999 has been\nentered). In these cases, OtherRegistrationAuthoritylD\nmay provide information on the documents supplied\nby the Legal Entity for Validation.\n3.1 - LegalName: added in the local language and\ncharacter set.\n3.2 — LegalAddress: added This is the jurisdiction of\nlegal formation and registration of the branch entity.\n3.16 — added If the LEI-CDF record is also a head office\nthen the associated branch entities must all be in\nstatus ISSUED following the renewal of the head office\nLEI.\n2017-05-04 1.1 2.2: added included in Originator GLEIF\n2.4: updated\n2.6: replaced relationships with LEls\n2.9: updated\n2.11: removed PENDING\n3.8: added branches\n3.17: added branches\n2016-11-30 1.0 Final version GLEIF\nState Transition and Validation Rules for Common Data File formats Page 8 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1505,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.128Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.37 Initial Registration Date (context: LEI-CDF)\n\n_ lei:InitialRegistrationDate\nThe date of the first LEl assignment, being the date of publication of\nthe identifier and its supporting data record as represented in I1SO\n8601.\n\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Registration/lei:InitialRegistrationDate\n\n¢ InitialRegistrationDate SHALL be set with the date when the LEI Record transits from the internal,\n\nnot published status PENDING_VALIDATION to ISSUED.\n\ne Once set, InitialRegistrationDate SHALL NOT be updated. This applies also when the LEI Record\n\nSet is being transferred to a different LEI issuer.\n\no The InitialRegistrationDate SHALL NOT be later than LastUpdateDate or NextRenewalDate.\n\n3.38 Last Update Date (context: LEI-CDF)\n\n_ Date/time the LEI Record was most recently updated.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Registration/lei:LastUpdateDate\n\n* Any update to an LEl record SHALL be indicated by setting the LastUpdateDate to the date the\n\nupdate occurred.\n\no There SHALL be at least one other field in the record that changed when LastUpdateDate is\n\nupdated.\n\no There SHALL NOT be any update to any other field without also an update to LastUpdateDate.\n\no LastUpdateDate SHALL NOT be earlier than InitialRegistrationDate.\n\no lastUpdateDate SHALL NOT be a date in the future.\n\nState Transition and Validation Rules for Common Data File formats Page 71 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1503,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.128Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.39 Registration Status (context: LEI-CDF)\n_ lei:RegistrationStatus\nThe status of the Legal Entity's LEI registration with the\nManagingLOU.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Registration/lei:RegistrationStatus\n\nThe element RegistrationStatus describes the status of the LEI registration.\n\no If RegistrationStatus is ISSUED, then EntityStatus SHALL be ACTIVE and ValidationSources SHALL\nNOT be PENDING.\n\no If RegistrationStatus is ISSUED, then NextRenewalDate SHALL be greater than or equal to the\nContentDate of the XML file.\n\no If RegistrationStatus is LAPSED, then NextRenewalDate SHALL be earlier than ContentDate.\n\no If the RegistrationStatus is LAPSED, the LEI Reference Data MAY still be updated.\n\no If RegistrationStatus is DUPLICATE, then SuccessorEntity SHALL be populated.\n\no If RegistrationStatus is ANNULLED, then SuccessorEntity MAY be populated.\n\no If the RegistrationStatus is RETIRED, no further updates to Entity sections of registration records\nin these states SHALL occur. Exceptions are allowed for updated information about the correct\nstatus, mapping to new code lists or ensuring high data quality of the record.\n\no MERGED — DEPRECATED .\n\n3.40Next Renewal Date (context: LEI-CDF)\n\n_ lei:NextRenewalDate\n\nThe next date by which the LEI registration should be renewed and\nre-certified by the Legal Entity.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Registration/lei:NextRenewalDate\n\no NextRenewalDate SHALL be later than InitialRegistrationDate.\n\nState Transition and Validation Rules for Common Data File formats Page 72 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1669,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.129Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"* NextRenewalDate SHALL NOT be later than ContentDate plus one year and sixty days.\n3.41 Managing LOU (context: LEI-CDF)\nThe LEI of the LOU that is responsible for administering this LEI\nregistration.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Registration/lei:ManagingLOU\nManagingLOU identifies the LEl issuer currently managing the LEI Record.\n¢ ManagingLOU SHALL be populated with the LEI of the LEl issuer.\n¢ ManagingLOU SHALL be populated with the LEI of a GLEIF Accredited LEl issuer for all LElI Record\nSet files published. Exceptions are allowed only for Candidate LEl issuers during testing and\nonboarding.\n¢ ManagingLOU SHALL be identical to the Originator in the file header for all LEI Record Sets\nuploaded to GLEIF.\n3.42 Validation Sources (context: LEI-CDF)\n_ lei:ValidationSources\nThe level of Validation of the Reference Data provided by the\nregistrant.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Registration/lei:ValidationSources\nThe LEl issuer notes the level of Validation in the Reference Data via the element ValidationSources:\no If ValidationSources is either PARTIALLY_CORROBORATED or FULLY_CORROBORATED then a\nspecific ValidationAuthoritylD SHALL be populated and which SHALL be different from RA999999\nand RA888888. The ValidationAuthorityEntitylD SHALL be populated given the register is\navailable for publication.\nState Transition and Validation Rules for Common Data File formats Page 73 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1533,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.129Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o If ValidationSources is ENTITY_SUPPLIED_ONLY then ValidationAuthoritylD SHALL be either\nRA999999 or RA888888.\no If ValidationSources is set to PENDING, then the LEIl record SHALL NOT be published and is only\nfor internal LOU use.\no The general rules laid out in section 2.2 SHALL apply.\n3.43 Validation Authority\n_ lei:ValidationAuthority\nInformation about the (primary) official authority in the Legal Entity's\njurisdiction of legal registration, for example a business registry, and\nthe corresponding identification of the Legal Entity by that official\nsource used to validate the Legal Entity Reference Data.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Registration/lei:ValidationAuthority\ne The container ValidationAuthority SHALL be provided and the LEl issuer is responsible to supply\nthe related information according to the rules described in section 2.2.\n3.44 Validation Authority ID\n_ lei:ValidationAuthoritylD\nThe reference code of the Registration Authority, taken from the\nRegistration Authorities Code List (RA list) maintained by GLEIF.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Registration/lei:ValidationAuthority\n/lei:ValidationAuthorityID\n¢ ValidationAuthoritylD SHALL be populated with a valid code from the Registration Authorities list\n(see section 2.2).\no For LEI Records that are not validated against a registry, ValidationAuthoritylD SHALL be\nRA999999.\nState Transition and Validation Rules for Common Data File formats Page 74 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1572,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.129Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o For Government Entities and International Organizations, RA777777 SHALL be used in case there\nis no information available in any regular registration authority and Public Legal Documents are\nused instead for partially or fully corroborated records.\n\n3.45 Other Validation Authority ID\n\n_ lei:OtherValidationAuthoritylD\n\nA legacy / historical reference code of a Registration Authority which\nis not yet entered in the Registration Authorities Code List (RA list)\nmaintained by GLEIF, or the designation of an interim register until\nsuch time as an entry from RA list can be delivered.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Registration/lei:ValidationAuthority\n/lei:OtherValidationAuthoritylD\n\no OtherValidationAuthoritylID MAY be present when ValidationAuthoritylID is populated.\n\no If ValidationAuthorityID is RA888888, OtherValidationAuthoritylD SHALL include the name of the\nRegistration Authority, as submitted in the request sent to GLEIF to add a new code to the RA list\n(see section 2.2).\n\no If ValidationAuthorityID is RA777777, OtherValidationAuthoritylD SHALL include the name and\nreference and where possible the link to the documents used for corroboration.\n\nState Transition and Validation Rules for Common Data File formats Page 75 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1364,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.129Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.46 Validation Authority Entity ID\n\n_ lei:ValidationAuthorityEntitylD\nThe identifier of the entity at the indicated Registration Authority.\nTypically, the identifier of the Legal Entity as maintained by a\nbusiness registry in the jurisdiction of legal registration, or if the\nentity is one that is not recorded in a business registry (e.g., one of\nthe varieties of funds registered instead with financial regulators),\nthe identifier of the entity in the appropriate Registration Authority.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Registration/lei:ValidationAuthority\n/lei:ValidationAuthorityEntitylD\n\no If the Registration Authority used for Validation provides an entity ID,\n\nValidationAuthorityEntitylD SHALL be populated with the entity ID from the authoritative source.\n\no If the authoritative source does not provide an entity ID, ValidationAuthorityEntitylD SHALL NOT\n\nbe included.\n\no IfRA777777 or RA888888 is used, the ValidationAuthorityEntitylD MAY be provided depending\n\non the source.\n\n¢ ValidationAuthorityEntityID SHALL NOT be populated, if ValidationAuthoritylD is RA999999 or\n\none of the RA Codes identifying sources known to not providing an entity ID.\n\n3.47 Other Validation Authorities\n\n_ lei:OtherValidationAuthorities\nAn optional list of additional Registration Authorities used by the LEI\nissuer to validate the entity data.\n\n_ {0,1} with {1,n} lei:OtherValidationAuthority included\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Registration/lei:OtherValidationAuthorities\n\ne OtherValidationAuthorities is a container that MAY be included to provide information about\n\nadditional Validation Authorities used for Validation.\nState Transition and Validation Rules for Common Data File formats Page 76 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1838,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.129Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o All subsets in OtherValidationAuthorities MAY repeat the same source as ValidationAuthority in\ncase the source uses different local identifiers for the same legal entity.\no Every subset in OtherValidationAuthorities SHALL be unique within this registration.\no OtherValidationAuthorities SHALL NOT include any subset having ValidationAuthorityID as\nRA999999.\n3.48 Start Node\n_ An LEI for the Legal Entity at the start of a directional relationship.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Relationship/rr:StartNode\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Relationship/rr:StartNode/rr:NodelD\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Relationship/rr:StartNode/rr:NodeType\nThe StartNode identifies the entity which is, where applicable, the child or lower node of a\nhierarchical relationship.\no StartNode/NodelD SHALL be the LEI of the child entity in the relationship.\no StartNode/NodeType SHALL be LEI.\no StartNode/NodelD SHALL be different from EndNode/NodelD.\nState Transition and Validation Rules for Common Data File formats Page 77 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1234,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.129Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.49 End Node\nAn LEl or ISO 17442-compatible ID for the Legal Entity at the end of a\ndirectional relationship.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Relationship/rr:EndNode\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Relationship/rr:EndNode/rr:NodelD\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Relationship/rr:EndNode/rr:NodeType\nThe EndNode identifies the entity which is, where applicable, the parent or higher node of a\nhierarchical relationship.\n¢ EndNode/NodelD SHALL be the LEI of the direct or ultimate accounting consolidating parent\nentity in the relationship.\no EndNode/NodelD SHALL be different from the StartNode/NodelD.\n© EndNode/NodeType SHALL be LEI in case the EndNode/NodelD contains an LEI.\n3.50 Relationship Type\nA unique code designating the specific category of a directional\nrelationship between two Legal Entities.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Relationship/rr:RelationshipType\no RelationshipType SHALL specify relationship between the StartNode and the EndNode.\nCurrently, three use-cases for relationships exist in the Global LEI System:\n1. Accounting Consolidating Parent Relationship:\nState Transition and Validation Rules for Common Data File formats Page 78 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1421,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.129Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o For the direct accounting consolidating parent, RelationshipType SHALL be\nIS_DIRECTLY_CONSOLIDATED_BY\n\ne For the ultimate accounting consolidating parent, RelationshipType SHALL be\nIS_ULTIMATELY_CONSOLIDATED_BY\n\n2. International Branch Relationship:\n\n¢ The RelationshipType SHALL be IS_INTERNATIONAL_BRANCH_OF for a Branch entity when\nconnecting to its head office.\n\nBoth above-mentioned use-cases are mutually exclusive; if an active consolidating relationship is\npresent, there cannot be an active Branch Relationship and vice versa.\n3. Fund Relationships are (see Figure 6) :\n\n¢ RelationshipType SHALL be IS_FUND-MANAGED_BY, if the StartNode is a fund managed by a\nmain management entity in a Fund Management Entity relationship. The EndNode is legally\nresponsible for the constitution and operation of the fund.\n\no RelationshipType SHALL be IS SUBFUND_OF, if the StartNode is a sub-fund to an umbrella\nfund in an Umbrella Structure relationship. The EndNode is a Legal Entity with one or more\nthan one sub-funds/compartments where each sub-fund/compartment has its own\ninvestment objectives, separate investment policies and strategies, segregation of assets,\nseparate investors and which has segregated liability between sub-funds/compartments.\n\no RelationshipType SHALL be IS_FEEDER_TO, if the StartNode is a Feeder Fund, that is (almost)\nexclusively invested in a single other fund in a Master-Feeder Relationship. The EndNode is\nthe Master Fund that has identical investment strategies.\n\n4 \\\nISSUBFWbERTO\nIS_FUND-MANAGED_BY \\\n\\_{/\nFigure 6: Fund Relationship types\n\nState Transition and Validation Rules for Common Data File formats Page 79 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1759,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.129Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.51 Relationship Periods\nA collection of paired beginning and end dates relating to the\nrelationship itself, periods (e.g., accounting cycles) covered by\ndocuments demonstrating the relationship, or the filing date(s) of\nthose documents.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Relationship/rr:RelationshipPeriods\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Relationship/rr:RelationshipPeriods/rr:StartDate\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Relationship/rr:RelationshipPeriods/rr:EndDate\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Relationship/rr:RelationshipPeriods/rr:PeriodType\nRelationshipPeriods contain three elements:\no StartDate: Date the relationship begins\no EndDate: Date the relationship ends\no PeriodType: The kind of relationship period\n¢ The StartDate of a RelationshipPeriod SHALL NOT be later than the EndDate, if provided.\no The StartDate SHALL NOT be later than the Relationship Record’s LastUpdateDate.\no The StartDate SHALL NOT be earlier than the LEI Record’s EntityCreationDate.\no Relationship Records can have multiple RelationshipPeriods simultaneously, but only one at a\ntime for any given PeriodType.\no ARelationshipPeriod SHALL always include StartDate and PeriodType. EndDate is optional and\nSHALL NOT be provided if the period has no defined EndDate or the date is unknown.\no All Relationship Records SHALL include exactly one RelationshipPeriod with PeriodType\nRELATIONSHIP_PERIOD.\nState Transition and Validation Rules for Common Data File formats Page 80 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1716,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.130Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"All changes made during creation (for clarity and reading ease as well as significant changes),\nincrease the version number by 0.1.\nThe approved PID is considered to be the final version and gets version number 1.0.\nState Transition and Validation Rules for Common Data File formats Page 9 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":398,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.130Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o Relationships with RelationshipType IS_DIRECTLY_CONSOLIDATED_BY and\nIS_ULTIMATELY_CONSOLIDATED_BY SHALL include one RelationshipPeriod with PeriodType\nACCOUNTING_PERIOD.\n\no Relationships with RelationshipType IS_INTERNATIONAL_BRANCH_OF MAY include one\nRelationshipPeriod with PeriodType ACCOUNTING_PERIOD.\n\no Relationships with RelationshipType IS_FUND-MANAGED_BY, IS_SUBFUND_OF and\nIS FEEDER_TO SHALL NOT include any RelationshipPeriod with PeriodType\nACCOUNTING_PERIOD.\n\no Relationship Records MAY include one RelationshipPeriod with PeriodType\nDOCUMENT_FILING_PERIOD.\n\nRelationshipPeriod with PeriodType = RELATIONSHIP_PERIOD\n\nIndicates the duration of the relationship itself, regardless of when the relationship was first included\n\nin the Global LEI System. The StartDate would indicate the earliest date at which the relationship\n\nexisted. If that information is not available or exactly known, it SHALL be the earliest date where the\nvalidity of the relationship could be corroborated. Usually, this date will be earlier than the\n\nInitialRegistrationDate of the relationship. For ACTIVE relationships, EndDate SHALL NOT be included,\n\nwhile for INACTIVE relationships, EndDate SHALL be populated with the last date the relationship\n\nexisted. StartDate and, once provided, EndDate would not generally be updated, unless the originally\nrecorded date was incorrect.\n\nRelationshipPeriod with PeriodType = ACCOUNTING_PERIOD\n\nIndicates the time period reflected in the source document (generally distinct from the date of the\n\ndocument) and is intended to indicate the accounting period covered by the most recent Validation\n\ndocuments. The accounting period for relationships based on accounting consolidation SHALL be\nupdated with the latest accounting period during renewals.\n\nRelationshipPeriod with PeriodType = DOCUMENT_FILING_PERIOD\n\nIndicates the date of the document filing or publication. This only applies where the Validation\n\ndocuments are filed or publicly available. The StartDate SHALL be the date of document filing or\n\npublication.\n\nIf the Validation documents also indicate the period over which the filing applies, the EndDate SHALL\n\nbe the end date of this period. Although entities should be encouraged to provide the exact dates\n\nwhen known, start and end dates MAY be approximated by the date of the situation described in the\nfirst accounting statement showing consolidation or the end of consolidation, respectively. For\ninstance, what is sought here is not that the accounting statement used for Validation is for the year\n\n2019, but that the relationship was valid at least as of 31 December 2019.\n\nState Transition and Validation Rules for Common Data File formats Page 81 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2812,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.130Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.52 Relationship Status\n_ rr:RelationshipStatus\nThe status of the Legal Entities' relationship itself: ACTIVE, INACTIVE\nor NULL.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Relationship/rr:RelationshipStatus\no RelationshipStatus SHALL reflect the status of the relationship.\n¢ RelationshipStatus SHALL be ACTIVE if both Legal Entities are operational and the relationship\nbetween them is current and verified.\no RelationshipStatus SHALL be INACTIVE if one of the Legal Entities ceased to exist or the\nrelationship is no longer current.\no RelationshipStatus SHALL be NULL if the RegistrationStatus of the Relationship Record is\nDUPLICATE or ANNULLED .\no RelationshipStatus MAY be NULL in the exceptional case of a fund in formation (see chapter 4.4).\n3.53 Relationship Qualifiers\n_ rr:RelationshipQualifiers\nAny additional qualitative attributes that help to categorize\nthe relationship.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Relationship/rr:RelationshipQualifiers\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord/r\nr:Relationship/rr:RelationshipQualifiers/rr:RelationshipQualifier/rr:Q\nualifierDimension\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord/r\nr:Relationship/rr:RelationshipQualifiers/rr:RelationshipQualifier/rr:Q\nualifierCategory\nState Transition and Validation Rules for Common Data File formats Page 82 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1519,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.130Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Definitions of accounting consolidation and other relationship types could vary by jurisdiction. The\nLegal Entity reports the accounting consolidation, which is verified by the LEl issuer. Available values\nare:\n\no rr:QualifierDimension:\n\ne ACCOUNTING_STANDARD: The accounting standard applied to determine the definition of\ne.g., ultimate or direct accounting consolidating parent for the relationship detailed in this\nRelationshipRecord. The relevant accounting standard is that applicable to the EndNode (the\n\"parent” entity).\n\ne rr:QualifierCategory:\n\no US_GAAP: United States-Generally Accepted Accounting Principles.\n\no IFRS: International Financial Reporting Standard (developed by the International Accounting\nStandards Board — IASB see http://www.ifrs.org)\n\no OTHER_ACCOUNTING_STANDARD: A financial reporting (accounting) standard not otherwise\nlisted in the latest version of the relationship data file format.\n\no GOVERNMENT_ACCOUNTING_STANDARD: Used for entities consolidated under the\nInternational Public Sector Accounting Standard (IPSAS 35) or National Government or\nFederal Government accounting standards specifically developed for Government entities in\ntheir state or local jurisdiction.\n\nThe declaration of the consolidating standards SHALL follow below rules and hierarchies:\n\n* International standards SHALL overrule local GAAPs.\n\no The GOVERNMENT_ACCOUNTING_STANDARD SHALL be used only when both StartNode and\nEndNode are categorized as RESIDENT_GOVERNMENT_ENTITY or\nINTERNATIONAL_ORGANIZATION, respectively.\n\no Entities categorized as RESIDENT_GOVERNMENT_ENTITY SHALL declare direct and ultimate\nparent only by GOVERNMENT_ACCOUNTING_STANDARD; none of the other accounting\nstandards SHALL be used.\n\nState Transition and Validation Rules for Common Data File formats Page 83 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1906,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.130Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.54 Relationship Quantifiers\n_ rr:RelationshipQuantifier\nAny additional quantitative attributes that help to categorize\nthe relationship.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Relationship/rr:RelationshipQuantifiers\n¢ The Quantifier Dimension allows adding quantitative attributes to a relationship, like the\npercentage of shares the parent holds, etc.\n3.55 Initial Registration Date (context: RR-CDF)\nThe date at which the relationship information was first collected by\nthe ManaginglLOU.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Registration/rr:InitialRegistrationDate\no InitialRegistrationDate SHALL be set when the Relationship Data Record transits from the\ninternal, not published status PENDING_VALIDATION to PUBLISHED, analog to the\nInitialRegistrationDate within the context of LEI Data.\no LEl Records for Level 1 and Level 2 Reference Data MAY have a different InitialRegistrationDate,\ndepending on when each record was entered into the Global LEI System.\no Likewise, different Relationship Records for the same child entity MAY have different\nInitialRegistrationDates.\ne Once set, InitialRegistrationDate SHALL NOT be updated. This applies also when the Relationship\nRecords is being transferred to a different LEl issuer.\n¢ The InitialRegistrationDate SHALL not be later than LastUpdateDate or NextRenewalDate.\nState Transition and Validation Rules for Common Data File formats Page 84 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1567,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.130Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.56 Last Update Date (context: RR-CDF)\n\nThe date at which the information was most recently updated by the\nManagingLOU.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Registration/rr:LastUpdateDate\n\n¢ Any update to a Relationship Record SHALL be indicated by setting the LastUpdateDate to the\ndate the update occurred.\n\no There SHALL be at least one other field in the record that changed when LastUpdateDate is\nupdated.\n\no There SHALL NOT be any update to any other field without also an update to LastUpdateDate.\n\no LlastUpdateDate SHALL NOT be earlier than InitialRegistrationDate.\n\no lastUpdateDate SHALL never be a date in the future.\n\n3.57 Registration Status (context: RR-CDF)\n\n_ rr:RegistrationStatus\n\nThe status of the Legal Entity's Relationship Record\n\nregistration with the ManagingLOU.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Registration/rr:RegistrationStatus\n\nThe element RegistrationStatus describes the status of the relationship registration.\n\no If RegistrationStatus is PENDING_VALIDATION, the record SHALL NOT be published in any files\nwith Content Type LOU_FULL_PUBLISHED, LOU_DELTA_PUBLISHED, GLEIF_FULL_PUBLISHED, or\nGLEIF_DELTA_PUBLISHED.\n\no If RegistrationStatus is PUBLISHED, then RelationshipStatus SHALL be ACTIVE, and\nValidationSources SHALL NOT be PENDING.\n\nState Transition and Validation Rules for Common Data File formats Page 85 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1525,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.130Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o If RegistrationStatus is PUBLISHED, then NextRenewalDate SHALL be greater than or equal to the\nContentDate.\no If RegistrationStatus is RETIRED, then RelationshipStatus SHALL be INACTIVE.\n¢ A RegistrationStatus of CANCELLED SHALL NOT be published.\no If RegistrationStatus is LAPSED, then NextRenewalDate SHALL be earlier than ContentDate.\n3.58 Next Renewal Date (context: RR-CDF)\nThe next date by which the relationship information SHALL be\nrenewed and re-certified by the Legal Entity.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Registration/rr:NextRenewalDate\no NextRenewalDate SHALL be later than InitialRegistrationDate.\n¢ The NextRenewalDate for relationships with RelationshipType IS_DIRECTLY_CONSOLIDATED_BY\nor IS_ULTIMATELY_CONSOLIDATED_BY SHALL be the same for the child LEl and the Relationship\nRecords.\nState Transition and Validation Rules for Common Data File formats Page 86 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1025,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.130Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.59 Managing LOU (context: RR-CDF)\nThe LEI of the LOU that is responsible for administering this\nRelationship Record.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Registration/rr:ManagingLOU\nManagingLOU identifies the LEl issuer currently managing the LEI Relationship Records.\n¢ ManagingLOU SHALL be populated with the LEI of the LEl issuer.\n¢ ManagingLOU SHALL be populated with the LEI of a GLEIF Accredited LEl issuer for all LElI Record\nfiles published. Exceptions are allowed only for Candidate LEl issuers during testing and\nonboarding.\n¢ ManagingLOU SHALL be identical to the Originator in the file header for all LElI Records uploaded\nto GLEIF.\n¢ ManagingLOU SHALL be identical to the ManagingLOU in the LEI Record for the child Legal Entity\nrepresented by the StartNode of the relationship.\n3.60 Validation Sources (context: RR-CDF)\n_ rr:ValidationSources\n_ Level of relationship Validation.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Registration/rr:ValidationSources\n¢ ValidationSources SHALL be FULLY_CORROBORATED, if an accounting consolidation relationship\ncan be validated using current and confirmed consolidated financial statements or other\naccepted documents. Fund relationships SHALL be FULLY_CORROBORATED, if the relationship\ncan be validated using regulatory filings to regulators or central banks as well as registers and\ndatabases kept by competent authorities. A fund prospectus vetted by such authority is also\naccepted, even if the source of the document is the fund manager and not the regulator.\nState Transition and Validation Rules for Common Data File formats Page 87 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1762,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.130Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o ValidationSources SHALL be PARTIALLY_CORROBORATED, if the accepted documents have\ndifferent definitions of accounting consolidation or if the documents make it likely that an\naccounting consolidation relationship exists but the confirmed financial statements do not\ninclude this situation, yet.\n\n¢ ValidationSources SHALL be ENTITY_SUPPLIED_ONLY, if the conditions for assigning\nFULLY_CORROBORATED or PARTIALLY _CORROBORATED are not met and the Validation relies\nsolely on unconfirmed documents provided by the Legal Entity. For fund relationships, this also\nincludes a prospectus not (yet) vetted by the authorities.\n\n3.61 Validation Documents (context: RR-CDF)\n\n_ rr:ValidationDocuments\n\nType of source document(s) used for validating the\n\nrelationship.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Registration/rr:ValidationDocuments\n\n¢ The type of Validation documents used to corroborate the relationship SHALL be provided.\n\nCurrently accepted type of documents to validate relationships are:\n\no ACCOUNTS_FILING: A consolidated financial (accounting) statement, prepared and submitted\nto the relevant authority.\n\no REGULATORY_FILING: A regulatory filing providing public information on Legal Entities\nand/or their relationships (e.g.: documents submitted to a (financial) regulator, including a\nfund prospectus made available on the regulator’s web site).\n\ne SUPPORTING_DOCUMENTS: Other documents supporting the validation of legal entities\nand/or their relationships (e.g.: business registers or other authoritative sources, such as\nofficial fund register or databases for regulated fund entities provided by the regulator).\n\no CONTRACTS: Contract(s) attesting to the validity of Legal Entities and/or their relationships.\n\no OTHER_OFFICIAL_DOCUMENTS: Other official document(s) attesting to the validity of Legal\nEntities and/or their relationships (e.g.: notarized documents or a fund prospectus provided\nby the fund manager).\n\ne If ValidationSources is ENTITY_SUPPLIED_ONLY the ValidationDocuments are none of the sources\nadmitted for FULLY_CORROBORATED and PARTIALLY_CORROBORATED.\n\nState Transition and Validation Rules for Common Data File formats Page 88 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2302,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.131Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o If ValidationDocuments is REGULATORY_FILING, the ValidationReference element SHALL be\npresent and contain, if available, the filing URL (including name and full path). The filing URL MAY\ncontain other standard identifiers e.g., DOI (Digital Object Identifier).\n\n3.62 Validation Reference (context: RR-CDF)\n\n_ rr:ValidationReference\n\nA reference to a specific document or other source used as the\nbasis of relationship Validation for this Relationship Record.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Registration/rr:ValidationReference\n\no The content of ValidationReference SHALL contain a reference to a specific document or other\nsource used as the basis of relationship Validation for this record.\n\n3.63 LEI (context: Repex-CDF)\n\n_ The LEI for the Legal Entity which raised this exception.\n\n/repex:ReportingExceptionData/repex:ReportingExceptions\n/repex:Exception/repex:LEl\n\ne SHALL contain the LEI of the entity reporting the exception (i.e.: the child Legal Entity).\n\ne The EntityCategory in the record assigned to this LEI SHALL NOT be BRANCH.\n\n3.64 Exception Category\n\nState Transition and Validation Rules for Common Data File formats Page 89 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1290,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.131Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"A category of mandatory information reporting, beyond the\nminimum required for Legal Entity identification, which the Legal\nEntity declines, giving reasons and references where applicable.\n/repex:ReportingExceptionData/repex:ReportingExceptions\n/repex:Exception/repex:ExceptionCategory\n\nThe ExceptionCategory of a Reporting exception defines whether the exception applies to the\n\nreporting of the direct parent or the ultimate parent.\n\no Relationship Records and Reporting exceptions SHALL be mutually exclusive for the same parent\nreporting (direct vs. ultimate).\n\no If a Reporting exception having ExceptionCategory\nDIRECT_ACCOUNTING_CONSOLIDATING_PARENT is present, no active Relationship Records\nhaving RelationshipType IS_DIRECTLY_CONSOLIDATED_BY SHALL be present.\n\no If a Reporting exception having ExceptionCategory\nULTIMATE_ACCOUNTING_CONSOLIDATING_PARENT is present, no active Relationship Records\nhaving RelationshipType IS_ULTIMATELY_CONSOLIDATED_BY SHALL be present.\n\n3.65 Exception Reason\n\nA single reason provided by the Legal Entity for declining to\nprovide the mandatory report of a specified type of information\n(beyond the minimum Reference Data needed purely for\nidentification of the Legal Entity).\n/repex:ReportingExceptionData/repex:ReportingExceptions\n/repex:Exception/repex:ExceptionReason\n\nThe LEI-ROC has specified scenarios where the child Legal Entity may report it does not have a parent\n\naccording to the definition used or it may decline to provide parent information.\n\nThe LEl issuer MAY also report an exception given the parent does not have an LEI yet. Different\n\nexception reasons apply in each scenario:\n\nState Transition and Validation Rules for Common Data File formats Page 90 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1825,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.131Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"1 Introduction\n\nThe State Transition and Validation Rules (STVR) describe Business Rules and their technical\n\nimplementation for the issuance, updating, management and publication of LEI Reference Data\n\naccording to the Common Data File (CDF) formats.\n\n¢ Rules enforced by the XML schema are documented in the xsd files for LEI-CDF, RR-CDF and\nREPEX-CDF in their latest version.\n\n¢ Rules required in addition to the XML schema definition (also called Business Rules, data\nmanagement rules, STVR) are documented separately here.\n\nNOTE: These Business Rules are written by GLEIF to provide specific steps for the LEl issuers to follow\n\nin producing and quality assuring the LEI data they provide to GLEIF and publish in the Global LEI\n\nSystem.\n\nNOTE: Each CDF data field is presented here with:\n\n¢ Element name\n\no Description or rationale (source) per data element\n\ne Cardinality\n\no The Xpath identifying the unique data field in its CDF XML representation\n\no General rules\n\nNOTE: During implementation and transition periods between versions of the related CDF formats,\n\nthere might be certain descriptions, listing or explanations relevant only for a specific version of the\n\nCDF formats. These could relate to the upcoming version as well as to the retiring version. In order to\n\nmake these differences more visible to the reader, in this document such elements are highlighted\n\nwith the information about the related version. Some examples, but nor limited to these are (added\n\nin LEI-CDF x.x), (updated in RR-CDF x.x), (deprecated in LEI-CDF x.x).\n\n1.1 Terms and Definitions\n\nBranch/International A lead International Branch or International Branch network outside\n\nBranch of the headquarters’ jurisdiction.\n\nBusiness Rule GLEIF’s legal, organizational and technical rules for implementation\nof the LEI-ROC’s high-level policies for LEl data beyond the technical\nrules enforced by the relevant XML schema.\n\nState Transition and Validation Rules for Common Data File formats Page 10 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2093,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.131Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"e Child Legal Entity reports it does not have a parent according to the definition used:\no NATURAL_PERSONS: the child Legal Entity is controlled by (a) natural person(s).\n© NON_CONSOLIDATING: the child Legal Entity is not subject to reporting in consolidated\nfinancial statements.\no NO_KNOWN_PERSON: there is no known person controlling the child Legal Entity (e.g.,\ndiversified shareholding).\no Child Legal Entity reports it does have a parent according to the definition used but this parent\ndoes not yet have an LEI:\n+ NO_LEI\no Child Legal Entity has an accounting consolidation parent relationship but declines to provide\nparent information due to other obstacles:\no NON_PUBLIC for all of the below use cases:\n\ne Obstacles in the laws or regulations of a jurisdiction prevent the child Legal Entity from\nproviding or publishing this information.\n\ne The child Legal Entity reports that the consent of the parent was necessary under the\napplicable legal framework and the parent did not consent or could not be contacted.\n\n¢ Binding legal commitments such as the articles governing the child Legal Entity, or a\ncontract prevent the child Legal Entity from providing or publishing this information.\nThis is distinct from laws or regulations of a jurisdiction that prevent the child Legal\nEntity from providing or publishing information on its parent.\n\no The child Legal Entity has sought to consult the parent entity about the reporting of the\nparent information to the Global LEI System but could not confirm the absence of\ndetriment in a way that can appropriately prevent liability risks for the child Legal Entity\n(or those acting on its behalf) under the applicable legal framework. The disclosure of\nthis information would be detrimental to the child Legal Entity or the relevant parent.\n\no The disclosure of this information would be detrimental to the Legal Entity or the\nrelevant parent. This will include reasons generally accepted by public authorities in\nsimilar circumstances, based on a declaration by the entity.\n\no Restrictions:\n¢ In case a Government Entity (EntityCategory RESIDENT_GOVERNMENT_ENTITY) needs to\ndeclare a reporting exception other than NO_LEI, the reason for it SHALL only be\n\nNO_KNOWN_PERSON.\n\nState Transition and Validation Rules for Common Data File formats Page 91 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2413,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.131Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.66 Exception Reference\n_ repex:ExceptionReference\nReferences of the law, regulation or other element of the legal\nframework to support reason(s) provided by the Legal Entity for\ndeclining to provide information on its parents.\n/repex:ReportingExceptionData/repex:ReportingExceptions\n/repex:Exception/repex:ExceptionReference\no ExceptionReference SHALL include the references of the law, regulation or other element of the\nlegal framework supporting the reason provided by the child Legal Entity for declining to provide\ninformation on its parents.\n3.67 Associated Entity — DEPRECATED\n_ lei:AssociatedEntity\nAnother entity associated with this entity if needed to fully identify\nthis entity or to place it in an appropriate context.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity\n/lei:AssociatedEntity\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity\n/lei:AssociatedEntity@type\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity\n/lei:AssociatedEntity/lei:AssociatedLEl\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity\n/lei:AssociatedEntity/lei:AssociatedEntityName\no The AssociatedEntity itself SHALL be used in instances in which the legal identity of a FUND\ncannot be described sufficiently well by its own LegalName alone.\n¢ The AssociatedEntity element SHALL be used to provide the LEl or name of another entity such as\nan umbrella fund, fund manager or other hierarchically relevant entity.\nThis field has been removed from the LEl Common Data Format to avoid redundancy, as the\ninformation will be consistently provided in the fund relationship related fields.\nState Transition and Validation Rules for Common Data File formats Page 92 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1767,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.131Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.68 Entity Expiration Date — DEPRECATED\n_ lei:EntityExpirationDate\nThe date that the Legal Entity ceased to operate, whether due to\ndissolution, merger or acquisition.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Entity/lei:EntityExpirationDate\nThe element EntityExpirationDate is only supplied if the Legal Entity has ceased to exist or no longer\noperates as a separate Legal Entity.\n¢ EntityExpirationDate SHALL contain the date the entity ceased to exist. If the exact date is not\nknown, the date the Managing LOU was made aware that the entity is no longer active SHALL be\nentered.\no If EntityExpirationDate is present, then EntityExpirationReason SHALL be present.\no If EntityExpirationDate is present, then EntityStatus SHALL be INACTIVE.\no If EntityExpirationDate is not present, then EntityExpirationReason SHALL NOT be present.\no EntityExpirationDate SHALL be provided only after the fact, meaning it SHALL NOT be later than\nContentDate in the header or LastUpdateDate of the record.\nThis field has been removed from the LEl Common Data Format to avoid redundancy, as the\ninformation will be consistently provided in the Legal Entity Events related fields.\n3.69 Entity Expiration Reason — DEPRECATED\n_ The reason that a Legal Entity ceased to exist and/or operate.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Entity/lei:EntityExpirationReason\nThe element EntityExpirationReason is only supplied if the Legal Entity has ceased to exist or no\nlonger operates as a separate Legal Entity.\nState Transition and Validation Rules for Common Data File formats Page 93 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1683,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.131Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o EntityExpirationReason SHALL contain the reason why the entity is no longer active.\n\no If EntityExpirationReason is present, then EntityExpirationDate SHALL be present.\n\n« If EntityExpirationReason is present, then EntityStatus SHALL be INACTIVE.\n\no If EntityExpirationReason is not present, then EntityExpirationDate SHALL NOT be present.\n\nThis field has been removed from the LEl Common Data Format to avoid redundancy, as the\n\ninformation will be consistently provided in the Legal Entity Events related fields.\nState Transition and Validation Rules for Common Data File formats Page 94 of 170\n\n@ Public Version 2.7.1 Final\n\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":702,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.132Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4 Use Cases\nThe following Use Cases provide rules and guidelines for LEI registration and renewal, updates to the\nLEI Record Set due to Legal Entity Events, and the handling of registration errors.\n4.1 Issue New LEI that is not branch, fund, sole proprietor,\ngovernment entity or international organization\nWhen a Legal Entity is requesting a new LEI code, the LEl issuer:\no SHALL check that there is not already an LEI code assigned to the entity (avoiding Exclusivity\nViolations)\ne Assign a unique LEI code (avoiding uniqueness violations)\n¢ Validate and publish at least the following:\n¢ LegalName as stated in the Registration Authority or other official source\ne OtherEntityNames and TransliteratedNames, if applicable\no LegalForm and Legallurisdiction\no Complete LegalAddress and HeadquartersAddress\n¢ TransliteratedAddresses and OtherAddresses, if applicable\no EntityCategory SHALL be GENERAL\no EntitySubCategory SHALL NOT be provided\no EntityStatus SHALL be ACTIVE (specific exceptions for NULL and in very rare cases exceptions\nMAY be granted by GLEIF after reporting explicitly the exact Use Case to GLEIF for directly\nissuing LEls for INACTIVE Legal Entities)\no RegistrationAuthority SHALL be included\n¢ ValidationSources SHALL be included\n¢ ValidationAuthority SHALL be included\no InitialRegistrationDate SHALL be the date the record is initially published\no LastUpdateDate SHALL be equal to InitialRegistrationDate\n¢ NextRenewalDate SHALL NOT be more than one year after InitialRegistrationDate\n¢ ManagingLOU SHALL be the LEI of a GLEIF Accredited LEl issuer\nG State Transition and Validation Rules for Common Data File formats Page 95 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1757,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.132Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"¢ Two Relationship Records, one for the direct and one for the ultimate accounting\nconsolidating parent, SHALL be included, following the general rules for Legal Entity\nrelationship information (see 2.1.2) and the applicable Use Case(s) from chapters 4.1.1, 4.1.2,\n4.1.3 and 4.1.4. Different Use Cases can apply for the direct and ultimate parent.\n\no Relationship Records describing a Branch or fund relationship SHALL NOT be included.\n\n4.1.1 Relationship with a parent Legal Entity with an LEI\n\ne When an LEl is initially issued for a Legal Entity and the child Legal Entity has an accounting\nconsolidating direct and/or ultimate parent relationship, a Relationship Record SHALL be\npublished for each relationship.\n\n¢ Only relationships that are ACTIVE by the time of the registration shall be considered.\n\no The RegistrationStatus SHALL be PUBLISHED and the RelationshipStatus SHALL be ACTIVE.\n\no Relationships that ended prior to the initial registration SHALL NOT be included. Relationships\nthat ended after initial registration SHALL be updated as described in the Use Cases for Legal\nEntity Events (see section 4.13).\n\nWhen the child Legal Entity states having (a) parent(s) that is identified with an LEI, the LEl issuer:\n\n« Validates and publishes (a) Relationship Record(s) with at least the following:\n\no StartNode/NodelD SHALL be the same as the newly assigned LEI of the child Legal Entity.\n\no EndNode/NodelD SHALL be the LEI code already assigned to the parent Legal Entity and\npublished in the Global LEI Repository by the time this record is published.\n\no The RelationshipStatus SHALL be ACTIVE.\n\no RelationshipPeriod with PeriodType RELATIONSHIP_PERIOD SHALL be included with\nStartDate and no EndDate.\n\no RelationshipPeriod with PeriodType ACCOUNTING_PERIOD SHALL be included with StartDate\nand EndDate.\n\no RelationshipPeriod with PeriodType DOCUMENT_FILING_PERIOD MAY be included with\nStartDate and no EndDate.\n\n4.1.2 Relationship with a parent Legal Entity without an LEI\n\nIn the case a child Legal Entity reports an accounting consolidating parent relationship with a Legal\n\nEntity that does not have an LEI, the LEl issuer:\n\no SHALL publish a Reporting Exception Record with the appropriate ExceptionCategory and an\nExceptionReason NO_LEI.\n\no SHALL remove the existing relationship exception of type NO_LEI from the upload file, in case a\npublic relationship record to another LEl is introduced.\n\nState Transition and Validation Rules for Common Data File formats Page 96 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2600,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.132Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"e SHALL not be under an obligation to verify that the provided reason is valid but SHALL respond to\nany challenges of this state.\n4.1.3 No accounting consolidation parent relationship\nIf the Legal Entity reports not having (a) parent(s) according to the definition of accounting\nconsolidation, the LEl issuer:\no SHALL publish a Reporting Exception Record with the appropriate ExceptionCategory and an\nExceptionReason NON_CONSOLIDATION, NATURAL_PERSONS or NO_KNOWN_PERSON.\ne SHALL not be under an obligation to verify that the provided reason is valid but SHALL respond to\nany challenges of this state.\nTypically, LEIs that are pointed as ultimate parent entities exhibit these exception reasons.\n4.1.4 Accounting consolidation parent relationship not reported due to legal obstacles\n(opt-out)\nIf the child Legal Entity states any legal obstacles for providing parent relationship information that\nwould otherwise be included with a Relationship Record, the LEl issuer:\no SHALL publish a Reporting Exception Record with the appropriate ExceptionCategory and an\nExceptionReason NON_PUBLIC.\ne SHALL not be under an obligation to verify that the provided reason is valid but SHALL respond to\nany challenges of this state.\n4.2 Issue New LEI - Branch\nWhen a new LEl is requested for an International Branch, the LEl issuer:\ne SHALL ensure that the entity requesting the LEl is an International Branch of the (head office)\nLegal Entity, to which it belongs\no SHALL verify that the (head office) Legal Entity has an LEI with RegistrationStatus ISSUED.\ne SHALL ensure that the Branch is located in a different country as the (head office) Legal Entity.\no SHALL ensure that no other LEI has been issued to a Branch of the (head office) Legal Entity in the\nsame host country.\no SHALL validate that the Branch is registered in the local Registration Authority.\no SHALL validate and publish at least the following:\no LegalName as stated in the Registration Authority.\no LegalAddress SHALL be the address of the Branch in its host country.\no HeadquartersAddress SHALL be the legal address of the (head office) Legal Entity.\nState Transition and Validation Rules for Common Data File formats Page 97 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2293,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.132Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o EntityCategory SHALL be BRANCH.\no EntitySubCategory SHALL NOT be provided.\no LegalForm SHALL be the LegalForm of the (head office) Legal Entity.\no Legallurisdiction SHALL be the Legallurisdiction of the (head office) Legal Entity.\no ValidationSources SHALL NOT be ENTITY_SUPPLIED_ONLY.\no SHALL publish exactly one Relationship Record with:\ne StartNode SHALL be the new LEI of the Branch.\n¢ EndNode SHALL be the LEI of the (head office) Legal Entity.\no RelationshipType SHALL be IS_INTERNATIONAL_BRANCH_OF.\no RelationshipStatus SHALL be ACTIVE.\no RelationshipPeriod with PeriodType RELATIONSHIP_PERIOD SHALL be included with\nStartDate and no EndDate.\no RelationshipPeriods with other PeriodTypes MAY be included.\ne SHALL NOT publish Reporting Exception Records.\nFigure 7 describes the reporting of Branch entities implementing the concept International Branch\nfor a (head office) Legal Entity. This means that there is only one Branch-LEl issued per host country.\nHowever, this LEI represents all locations and/or offices within the jurisdiction. The (head office of\nthe) Legal Entity decides on and provides the correct Reference Data for all its International\nBranches.\nS\nSNTERNATONALBRANCTERNATONALBRANCHOF\n@ /\nLEIC LEIC LEIC LEIB LEIB LEIB\nLocation 1 Location2 Location 3 Location 1 Location2 Location 3\nFigure 7: Example for Branch relationships\nState Transition and Validation Rules for Common Data File formats Page 98 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1537,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.132Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.3 Issue New LEIl - Fund\n\nWhen a new LEI code is requested for a FUND, in addition to or differing from section 4.1 and section\n2.1.2, the LEl issuer:\n\no SHALL validate and publish at least the following:\n\no LegalAddress is the current address provided in the business registry in which the entity was\nformed (which would generally be the case for funds that are incorporated) or (in other\ncases) the address recorded in the primary Registration Authority of the fund.\n\n¢ HeadquartersAddress is the address of the fund manager.\n\no Legallurisdiction SHALL match the LegalForm of the entity, and MAY in some cases be\ndifferent from the jurisdiction of the LegalAddress.\n\no EntityCategory SHALL be FUND.\n\no EntitySubCategory SHALL NOT be provided.\n\no If the fund entity is in scope of the LEI ROC policy on fund relationships, then it SHALL report\nall mandatory fund relationships. See chapter 2.1.2.\n\n¢ The Validation Authority of a fund SHALL always be the financial regulator registering the\nfund where applicable.\n\no If the fund prospectus is not vetted by authorities, ValidationSources SHALL be\nENTITY_SUPPLIED_ONLY.\n\n¢ In cases where the fund entity is self-managed, the fund entity MAY report a relationship of\ntype IS_FUND-MANAGED_BY, in which the end node of the relationship points to the same\nfund entity (see\n\no Figure 8, LEI F). This is an indication that a fund is self-managed, to distinguish from the\nscenario when a fund has not opted out of reporting a relationship.\n\nFigure 8 provides an example of LEl network including fund relationships. For simplicity and clean\nrepresentation, not all required Relationship Records are provided for the second (LEI D, LEI E, LEI G)\nand third level (LEI H, LEI B, LEI C, LEI | LEI J).\nState Transition and Validation Rules for Common Data File formats Page 99 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1924,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.132Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"LEI H (NOT A FUND) LEI B (NOT A FUND) LEI C (NOT A FUND) LEI I (NOT A FUND) LEIJ (NOT A FUND)\nK IS_DIRECTLY_CONSOLIDATED_BY / IS_ULTIMATELY_T(\\:ONSOLIDATED_BY /\\\nIS_FUND-MANAGED_BY y’cONSOLIDATED_BY ycws%lomeo_gy\n? LEI G (NOT A FUND) LEID - FUND (UMBRELLA) LEI E - FUND (MASTER) T\nIS_DIRECTLY_CONSOLIDATED_BY /K IS_SUBFUND_OF / FEEDER_TO IS_ULTIMATELY_CONSOLIDATED_BY\nIS_ULTIMATELY_CONSOLIDATED_BY % | IS_FEEDER_TO ‘ IS_DIRECTLY_CONSOLIDATED_BY\n/__\\ /\n¥\\O/&F”\"”@:fl/®\nLEI A - FUND LEI F - FUND\nFigure 8: Example of network including fund entities and their relationships\nState Transition and Validation Rules for Common Data File formats Page 100 of 170\nGLEIF) Public Version 2.7.1 Final\n2022-04-01_State-Transition-Validation-Rules_v2.6_final.docx 2023-03-07\n","contentLength":759,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:36:35.132Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"@’ Protect dletto) st\n\nState Transition and\nValidation Rules for\nCommon Data File formats\n","contentLength":90,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.138Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Table of Contents\nY Yo 101 R 4 o TR 0 T YL U] 44 =T 4 Y\nAN | 1o o 1V T ' o TP | ||\n1.1 Terms and Definitions......ccccceeeviiiiiieie it csiieeee s sneee e s s sneeeeessnnnene 10\n1.2 Terminology and Typographical Conventions .........ccccecevveeeeivinineeeeinnnieeneeensiennn 12\n2 Lifecycle and General CoNCePtS.....cccerrueerenirrnecrenrrennceenceenncrnncesnecseneseneeee 14\n2.1 LEIRecord Set Reference Data ......ccccceeeeeiiiieeeeiiiiiicie s csssieeee s ssineeee s sssvvveeeesnnnenn 14\n2.1.1 Legal Entity data (Level 1 data — ‘“Who is WhO') ....cccovevvivicccieeeceecee e, 14\n2.1.2 Legal Entity relationship information (Level 2 data — “Who owns whom’)............ 14\n2.2 Corroboration of LEI Record Set .......ccccvivviiiiiiiiiiiiiieeee e ssieie e s ssiineeeeennn 21\n2.2.1 LEIREGISTIatioN ..ccceeiieeiiiiieie ettt e re e e e e e s s erneeneneeeaneanenes 21\n2.2.2 Validation c...uueeii et ee s srae e s snaees 22\n2.2.3 Application of GLEIF Registration Authorities List ........cccccccevevvieeccciesceeiiieeennn. 25\n2.3 LIf@ CYCIE coeeeee e s e sraae e e s s snnneaeeennn 27\n2.3.1 Registration Status COES .....ccuieiiiiiiiiei ittt ssrreee s seraees 28\n2.3.2 Changes in Registration Status due to Legal Entity Events .......c.cccveeviecviieeeriennen. 30\n2.3.3 Changes in Registration Status when a registration error is resolved.................... 31\n2.4 Registration Status Codes for Transient PUrpOSES......cccccevvvveeeeeriniinieensesiiinieeeennnn 31\n2.5 RENEWAI ciiiiciiiieiee e e s e ae e e snareeesenes 32\n2.6 1SO 3166 Conformance of Address and Jurisdiction Fields.............ccccceeeinnnennnnn. 32\n2.7 AdAress REPOITING ..uuviiiiiiiiiiiieee ettt eee s re e e sraae e ee s s sssaeeee s essaasaaaeesesens 33\n2.8 Entity Legal FOrm RePOItiNg ....cccvvcuuiiiiiiiiiiiieiieciiiiece s esssieeee s sveeeee s ssssvveeeeannnens 34\n2.9 Language, translation and transliteration ..........ccccceceeeiiivi s 35\n3 General State Transition and Validation Rules...........cccccccceeerrreennnnnnne.... 36\n3.1 Header Section (applicable to all files) .....cccceevveeeiieeiiiiieeceecee e 37\n3.2 CONTENT DAt e e e e e s DO\nR I O [ g 7= {1 o -1 (o] TP P TR PUPPPUPPPPPPRPPPOPOPRRRRRC 1o\nK I 1 L= @o | 1= | SO PSP PPPRUPPPPURPRPRPPNC 1 |\n3.5 Delta Start..cccccciiiee e sraeeee s sssnnneesesnsssnnnaeeen e 40\n3.6 ReCOrd COUNL .uviiiieiiiiiiiie sttt esie e e siieeee s s s snnneeessnsnnneesssssssnnnneeen s 40\n3.7 Extension (applicable to multiple Header Sections and data sections) ................41\n3.8 LEIRECOIT ettt s s sttte s sarre e e s ssvive e ae s s s sasbnaesesssnnnanesessnnnnnnenessnes B2\n3.9 LEI Code (context: LEI-CDF)......ccccieieiiiieeiiiiieciiieeessiieessevee e sieeeessvnessssnneessnnneee s 42\n3.10 Legal NAME c.iiiiiie ittt ee s ee s e s sra e e eesssvaneeessssasnnnnessssnnsneeeess B3\n3.11 Other ENntity NAmMES c.uuuiiiiiiiiiieiee ettt svrae e s sssvnneee s s s sainnae e s s snnneeee s 43\nG State Transition and Validation Rules for Common Data File formats Page 2 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":3087,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.138Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Common Data Files Format | The mandatory requirements for the structure and content of Legal\n\n(CDF) Entity Reference Data.\n\nELF code / ELF code list Abbreviation for the ISO 20275: Entity Legal Forms (ELF) code and\ncode list.\n\nExclusivity Violation Registration error where a Legal Entity has more than one LEI.\n\nGeneral Government Consists of institutional units that, in addition to fulfilling their\n\nSector political responsibilities and their role of economic regulation,\nproduce services (and possibly goods) for individual or collective\nconsumption mainly on a non-market basis and redistribute income\nand wealth.\n\nInstitutional Unit An institutional unit is an economic entity that is capable, in its own\nright, of owning assets, incurring liabilities and engaging in economic\nactivities and in transactions with other entities.\n\nInternational Organizations | Non-resident units created by international agreements or other\narrangements for the provision of non-market services or financial\nintermediation at the international level.\n\nLegal Entity Legal person or structure that is organized under the laws of any\njurisdiction (as defined in ISO 17442).\n\nLEl issuer, LOU An entity issuing and managing LEI Records; also referred to as\nManagingLOU, Managing LOU or just LOU (Local Operating Unit).\n\nLEI Record An XML data record in LEI-CDF format detailing one LEl record as\nreported by a Legal Entity to its LOU, and by the LOU to GLEIF.\n\nLEI Record Set An XML data record in CDF format describing one Legal Entity,\nincluding its related relationship information.\n\nRA code / RA list Abbreviation for the GLEIF Registration Authorities (RA) code and\nlist.\n\nReference Data The entity description and registration information recorded in the\nLEI Record Set.\n\nRelationship Record (RR) An XML data record in RR-CDF format detailing one relationship type\nbetween two Legal Entities, as reported by a Legal Entity to its LOU,\nand by the LOU to GLEIF.\n\nState Transition and Validation Rules for Common Data File formats Page 11 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2135,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.138Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"¢ The StartNode of a fund relationship SHALL be a fund entity, categorized by using the correct\nEntityCategory value FUND.\no If the RelationshipType is:\ne IS _SUBFUND_OF, then the EndNode of the relationship SHALL be a fund entity, categorized\nby using the correct EntityCategory value FUND (see\no Figure 8, relationship LEI A -> LEI D).\ne IS_FUND-MANAGED_BY, then the EndNode of the relationship SHALL be:\no afund entity, categorized by using the correct EntityCategory value FUND (see\no Figure 8, relationship LEI F -> LEI F).\ne aregular entity, categorized by using the correct EntityCategory value GENERAL (see\no Figure 8, relationship LEI A -> LEI G).\n* asole proprietor entity, categorized by using the correct EntityCategory value\nSOLE_PROPRIETOR.\ne IS _FEEDER_TO, then the EndNode of the relationship SHALL be a fund entity, categorized by\nusing the correct EntityCategory value FUND (see\no Figure 8, relationship LEI A -> LEI E).\n¢ For fund entities, if the requirement for financial consolidation requirement persists, direct and\nultimate parent entities SHALL be reported (see\no Figure 8, relationships LEI D -> LEI B and LEI C); In general for fund entities apply the same rules\nas described in chapter 2.1.2.\n¢ Fund entities MAY provide exact one Relationship Record of a type IS_SUBFUND_OF and\nIS_FEEDER_TO.\n¢ Reported ACTIVE fund relationships SHALL at least provide one RelationshipPeriod with\nPeriodeType RELATIONSHIP_PERIOD with a StartDate but no EndDate. Additional\nRelationshipPeriods MAY be included, if applicable (see 3.51).\n¢ Independent of what role in a relationship a fund entity plays (e.g., sub-fund, umbrella fund), the\nLegalName of the entity SHALL be its standalone LegalName and SHALL NOT include\nconcatenation of any related entities; in cases where an ‘Umbrella Structure’ relationship is\npresent, GLEIF will represent the names of the both the fund and the umbrella entities on LEI\nSearch as has been specified in the LEI-ROC policy.\n4.4 Issue New LEI - Fund in formation\nIn some jurisdictions or financial markets, fund entities require an LEl in order to register the fund or\nset up clearing accounts, before they become active from a legal perspective. In such cases, LEI\nState Transition and Validation Rules for Common Data File formats Page 101 of 170\nGLEIF Public Version 2.7.1 Final\n2022-04-01_State-Transition-Validation-Rules_v2.6_final.docx 2023-03-07\n","contentLength":2400,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.138Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"issuers SHALL follow these guidelines for setting up and maintaining the LEI Record for a not yet\n\nactive FUND:\n\ne The LEl issuer SHALL take due diligence to verify that the fund meets or will shortly meet the\nrequirements for entering the process requiring the LEI.\n\no The LEl issuer SHALL create and validate an LEI Record for the fund, as described above, including\nall relevant relationships and based on the available information and with the following special\nrules:\n\no EntityStatus SHALL be temporary set to NULL.\no EntityCreationDate SHALL NOT be populated.\no If afund relationship is introduced:\no RelationshipStatus SHALL be temporary set to NULL.\no RegistrationStatus of the relationship record SHALL be PUBLISHED.\ne StartDate of the RelationshipPeriod with PeriodType RELATIONSHIP_PERIOD SHALL NOT be\npopulated.\n\no During the setup of the fund, the LEl issuer SHALL work with the Legal Entity to keep the LEI\nRecord up to date with any Reference Data changes (e.g., a change in the name of the fund) and\nupdates the LEI Record Set accordingly. The LEl issuer SHALL be especially alert to the situation\nwhen the fund becomes a legally active entity, or the fund registration process is cancelled or\nwithdrawn.\n\n¢ If the fund becomes legally active, the LEl issuer SHALL update the LEI Record:\n\no EntityStatus SHALL be ACTIVE.\n\no EntityCreationDate SHALL be the date the legal status was achieved.\n\no If applicable, StartDate of the RelationshipPeriod with PeriodType RELATIONSHIP_PERIOD\nSHALL be the date the date the legal status was achieved.\n\no If the fund registration process is cancelled or withdrawn, the LEl issuer SHALL update the LEI\nRecord:\n\no RegistrationStatus of the LEI Record Set SHALL be ANNULLED.\n\no LElissuers SHALL monitor LEI Records for funds in formation closely and SHALL NOT keep them\nfor much longer in an uncertain state as it usually takes to register a fund in that jurisdiction.\n\nState Transition and Validation Rules for Common Data File formats Page 102 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2109,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.138Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o After the official registration of the fund entity is completed, the LEI Record Set SHALL be\nupdated accordingly.\n\n4.5 Issue New LEI - Sole proprietor\n\nWhen a new LEl is requested for a Sole Proprietor, in addition to or differing from section 4.1, the LEI\n\nissuer:\n\no SHALL ensure that the Legal Entity is registered in a Registration Authority\n\no SHALL validate and publish at least the following:\n\no RegistrationAuthorityID different from 'RA999999' and RegistrationAuthorityEntity|D SHALL\nbe included.\n\no EntityCategory SHALL be SOLE_PROPRIETOR.\n\no EntitySubCategory SHALL NOT be provided.\n\no LegalForm SHALL be a legal form applicable to Sole Proprietors in that jurisdiction.\n\no ValidationSources SHALL NOT be ENTITY_SUPPLIED_ONLY.\n\n4.6 Issue New LElI — Government entity\n\nWhen a new LEl is requested for a Government Entity as defined in chapters 3.22 and 3.23, in\naddition to or differing from section 4.1, the LEl issuer:\n\no SHALL validate and publish at least the following:\n\n+ EntityCategory SHALL be RESIDENT_GOVERNMENT_ENTITY.\n\no EntitySubCategory SHALL be CENTRAL GOVERNMENT, STATE GOVERNMENT, LOCAL\nGOVERNMENT or SOCIAL SECURITY, as applicable. If none of these sub-categories applies,\nEntitySubCategory SHALL NOT be provided.\n\n¢ If the Government Entity is registered in a registry or other authoritative source listed in the\nRA Code list in that country or jurisdiction, RegistrationAuthority SHALL be included\nrespectively and ValidationSources SHALL NOT be ENTITY_SUPPLIED_ONLY (unless the\nreserved code RA888888 is used to identify the authoritative source).\n\no If the Government Entity is not registered, but referred to in laws, regulations or decrees\nmade public by competent authorities, these public legal documents SHALL be used for\nvalidation and ValidationSources SHALL be either FULLY_CORROBORATED or\nPARTIALLY_CORROBORATED, depending on the extend of data elements validated against\nthat source. In this case RegistrationAuthoritylD RA999999 and ValidationAuthoritylD\nRA777777 SHALL be used and the document reference SHALL be added in the field\nOtherValidationAuthorityID.\n\nState Transition and Validation Rules for Common Data File formats Page 103 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2293,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.138Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o LegalAddress SHALL be the address recorded in the register or other authoritative source, if\nthe Government Entity is registered, or the official seat of the Government Entity as defined\nin their jurisdiction.\n\no HeadquartersAddress SHALL be the address of the Government Entity or the address of the\nauthorized entity managing the LEI registration on behalf of the Government Entity. The\naddress MAY be the same as LegalAddress. If another entity manages the registration,\nHeadquartersAddress SHALL include a ‘care-of’ part including the name of the entity\nmanaging the LEl registration.\n\no If the Government Entity has a dedicated legal form in the local jurisdiction according to the\nELF Code list, EntityLegalForm SHALL be included. If not, the appropriate reserved code (8888\nor 9999) SHALL be used together with a fitting descriptive term in the OtherLegalEntityForm\nfield.\n\n* If the Government Entity is declaring a direct and/or ultimate parent, the accounting\nstandard SHALL be GOVERNMENT_ACCOUNTING_STANDARD and the parent entity SHALL be\ncategorized as RESIDENT_GOVERNMENT_ENTITY as well. If no direct and/or ultimate parent\nis declared, a Reporting Exception with ExceptionReason NO_KNOWN_PERSON SHALL be\nincluded.\n\no If the Government Entity has a direct and/or ultimate parent that does not have an LEl, a\nReporting Exception with ExceptionReason NO_LEI SHALL be included.\n\nIf an LEI has been issued to a Government Entity prior to the implementation of LEI-CDF 3.1, the LEI\nissuer SHALL adapt the record in accordance with above rules during the next renewal at the latest.\nNote: Legal entities related to the European Union or related bodies SHALL NOT be categorized as\nGENERAL or RESIDENT_GOVERNMENT_ENTITY but rather as INTERNATIONAL_ORGANIZATION.\n4.7 Issue New LEI — International organization\n\nWhen a new LEl is requested for an International Organization as defined in chapter 3.22, which is\nnot organized in the specific legal form of a jurisdiction, in addition to or differing from section 4.1,\nthe LEl issuer:\n\no SHALL validate and publish at least the following:\n\no EntityCategory SHALL be INTERNATIONAL ORGANIZATION.\n\no EntitySubCategory SHALL NOT be provided.\n\n¢ HeadquartersAddress SHALL be the main base of operations or, in case most employees work\nin distributed field operations, the location of a secretariat or similar administrative central\nfunction.\n\n¢ The concept of LegalAddress as defined in the GLEIS does not apply to International\nOrganizations. LegalAddress SHALL be the same as HeadquartersAddress.\n\nState Transition and Validation Rules for Common Data File formats Page 104 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2731,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.139Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o If the RA Code list includes an authoritative source for International Organizations that can\nbe used to validate the data, that RA Code SHALL be included as RegistrationAuthority and\nValidationAuthority. In case the entity is not registered in any public registry, RA999999\nSHALL be used for RegistrationAuthoritylD. If there are also no Public Legal Documents\navailable that can be used to validate the data, RA999999 SHALL also be used as\nValidationAuthoritylD.\n\no ValidationAuthoritylD SHALL be RA777777 in case there is no information available in any\nregular registration authority and Public Legal Documents are used instead.\n\no AsInternational Organizations are established by treaties or other specific multinational\nagreements governed by international law, the concept of legal jurisdiction does not apply as\nfor other entities established under a national law. Legallurisdiction SHALL be the one of the\nfollowing:\n\no UN, if the entity is the United Nations, one of their specialized agencies or other\naffiliated organizations.\n\no EU, if the entity is established by a treaty signed by all members of the European Union\nand no other countries.\n\no XX, in all other cases.\n\no LegalForm SHALL be 9999, the reserved code for jurisdictions not on the ELF code list.\nOtherlLegalForm SHALL include the name of the treaty establishing the entity. If a series of\ntreaties or updates of treaties were signed to form or change the International Organization,\nonly the latest one establishing it in its current form SHALL be included.\n\no If the International Organization is declaring a direct and/or ultimate parent the parent entity\nSHALL be categorized as INTERNATIONAL_ORGANIZATION as well. If no direct and/or\nultimate parent is declared, a Reporting Exception with ExceptionReason\nNO_KNOWN_PERSON SHALL be included.\n\nIf an LEI has been issued to an International Organization prior to the implementation of LEI-CDF 3.1,\nthe LEl issuer SHALL adapt the record in accordance with above rules during the next renewal at the\nlatest.\n4.8 LEI Record Renewal\nIf a Legal Entity renews its LEI Record (see 2.5 Renewal above), the LEl issuer:\no SHALL validate that the Legal Entity is operational.\no SHALL validate the LEI Reference Data including all updates provided by the Legal Entity.\nState Transition and Validation Rules for Common Data File formats Page 105 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2470,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.139Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o SHALL validate that all reported ACTIVE relationships are still current and update the dates in\nperiods with PeriodType ACCOUNTING_PERIOD and DOCUMENT _FILING_PERIOD accordingly, if\npresent; if one or more relationships are no longer current, the Use Case 4.13.22 applies.\n\ne For a Fund entity, SHALL validate that all reported ACTIVE fund relationships (RelationshipType\nIS_ FUND-MANAGED_BY, IS SUBFUND_OF and IS_FEEDER_TO) are still current and update the\ndates in periods with PeriodType ACCOUNTING_PERIOD and DOCUMENT_FILING_PERIOD\naccordingly, if present; if one or more relationships are no longer current, the Use Case 4.13.22\napplies.\n\no SHALL check, if a parent without LEI (Exception reason NO_LEl) can be replaced by an LEI\nrelationship (see Use Case 4.9).\n\no SHALL check with the Legal Entity, if a reported exception due to legal obstacles still applies and\nreplace with a new Relationship Record if it is no longer valid.\n\ne SHALL set a new NextRenewalDate not more than 12 months after the current NextRenewalDate\nor the date of last Validation of the record, whichever is later; this applies to the Entity Data as\nwell as all ACTIVE Relationship Records.\n\ne For a Branch entity, SHALL ensure that the LEI Record of the (head office) Legal Entity has\nRegistrationStatus ISSUED; the Branch LElI Record SHALL NOT be renewed, if the\nRegistrationStatus of its head office LAPSED.\n\n4.9 LEI Record update — Parent Legal Entity without an LEIl requests\n\nan LEI\n\nThis Use Case applies where a parent without an LEI requests an LEI. As soon as the child Legal Entity\n\nis aware of this information, it needs to inform its LEIl issuer. The LEl issuer of the child entity:\n\no SHALL create the applicable Relationship Records(s) according to Use Cases 4.1.1.\n\no SHALL remove the NO_LEI Reporting exception record(s) from publication.\n\n4.10 LEI Record update — Relationship Record changes to Reporting\n\nException\n\nThis Use Case applies where the child Legal Entity reports a Reporting Exception after initially\n\ndeclaring a relationship. The LEl issuer:\n\ne SHALL annul the Relationship Record in case it was entered erroneously in the system.\n\no SHALL retire the Relationship Record in case the relationship for instance expired.\n\nState Transition and Validation Rules for Common Data File formats Page 106 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2418,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.139Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o In either case, the LOU SHALL continue publishing the ANNULLED/RETIRED Relationship\nRecord(s).\n\no SHALL create a new Reporting Exception and publish it.\n\n4.11 Lack of renewal — Legal Entity\n\nIf a Legal Entity does not renew its LElI Record (see Use Case 4.8), with reaching the\n\nNextRenewalDate, the LEl issuer:\n\no SHALL check with the registration and/or Validation Authority for the given Legal Entity (if\navailable), whether the entity is still active. If the Legal Entity stopped operations, then the rules\nfor retiring an LEIl apply here, or if applicable, the details of a corresponding Legal Entity Event.\n\nThe fact that an International Branch’s LEI Record is LAPSED SHALL NOT allow for the issuance of a\n\nsecond LEI Record for a Branch in the same host jurisdiction.\n\n4.12 Lack of renewal — Related Legal Entity including head offices,\n\nfund managers, umbrella and master funds\n\nIf the LEl Record of a related Legal Entity (the EndNode of an active relationship) is not renewed, all\n\nactive accounting consolidating, Fund Management Entities, Umbrella Structures and Master-Feeder\n\nRelationship Records having this entity’s LEl as EndNodelD SHALL NOT be updated, if the lack of\n\nrenewal of the parent Legal Entity is the only change.\n\nIf the parent Legal Entity is the head office of a Branch entity, the LEl issuer of the Branch SHALL set\n\nthe Branch’s LEI Record, including the Relationship Records, to LAPSED (see section 4.6). This SHALL\n\nbe ensured by the Branch LEI Record having the same NextRenewalDate as the head office LElI\n\nRecord, whether or not both records are managed by the same or by different LEIl issuers and\n\nregardless of any renewal request submitted by the Branch entity but not by the head office.\n\n4.13 Update of LEI Reference Data due to Legal Entity Events\n\nThe Reference Data of an LEI Record may change due to Legal Entity Events. The LEl issuer is\n\nresponsible to verify changed Reference Data. If the LEl issuer is ultimately unable to verify the\n\nchanged Reference Data, the Validation Sources SHALL change to PARTIALLY CORROBORATED or\n\nENTITY_SUPPLIED_ONLY.\n\nWhenever an element of the Reference Data is updated, the respective LastUpdateDate (LEI Record\n\nor Relationship Records) SHALL be updated with the current date and time as well.\n\nIf LEI Reference Data is updated to just correct an error or add missing data to an element associated\n\nwith Legal Entity Events (e.g., LegalName, LegalAddress, EntityLegalForm), but the Legal Entity itself\n\ndid not change, no Legal Entity Event SHALL be recorded together with the reference data update.\n\nState Transition and Validation Rules for Common Data File formats Page 107 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2774,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.139Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Legal Entity Events can occur as\n\n¢ Single Standalone events (e.g., an address change)\n\n¢ Sequence of Standalone events (e.g., a change in legal name after a merger or demerger)\n\n¢ Standalone Events that occur simultaneously (e.g., a change in legal name in the course of an\nabsorption)\n\ne Grouped events that happen at the same time (e.g., a change in legal form that also changes the\nlegal name)\n\ne Grouped events in a logical succession (e.g., reverse take-over).\n\n4.13.1 Legal Entity Event — Event timeline and status\n\nSome events MAY be able to be confirmed officially before the event becomes legally effective. For\n\nother events, becoming legally effective will be the only binding confirmation for the event. There\n\nMAY be cases where a Legal Entity Event has been confirmed officially but later will be withdrawn or\n\ncancelled before becoming legally effective.\n\nTo capture different timelines and statuses, each Legal Entity Event has an attribute defining the\n\nstatus of the event (see section 3.29):\n\no @event_status SHALL be IN_PROGRESS, if the Legal Entity Event is confirmed by an official\nsource (which could be the Legal Entity itself) but has not become legally effective yet. Not all\nevents MAY be able to be confirmed and recorded in the Global LEI System before the\nLegalEntityEventEffectiveDate.\n\no LegalEntityEventEffectiveDate SHALL be a future date (if the effective date is known) or\nSHALL be omitted (if the date is unknown).\n\no All provided AffectedFields SHALL include the values of the LEI Reference Data as expected to\nchange as a result of a completed Legal Entity Event.\n\n¢ The values provided in the attribute @field_xpath of the AffectedFields element SHALL be as\nlisted in section 3.36.\n\no @event_status SHALL be COMPLETED, if the Legal Entity Event is confirmed and legally effective.\no LegalEntityEventEffectiveDate SHALL be present and earlier or equal to\n\nLegalEntityEventRecordedDate.\n\n@event_status SHALL be WITHDRAWN_CANCELLED, if an event has been reported with\n\n@event_status IN_PROGRESS but has been determined to not be completed due to withdrawal or\n\ncancellation. This status SHALL be used only when it is confirmed that the event will not happen —a\n\ndelay past an expected effective date SHALL NOT result in a cancellation. Figure 9 gives further\n\ndetails on the application of event timelines.\nState Transition and Validation Rules for Common Data File formats Page 108 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2529,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.139Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"@event_status WITHDRAWN_CANCELLED SHALL also be used to cancel events that have been\npublished in the LEI Record by mistake. In this case the event with @event_status\nWITHDRAWN_CANCELLED SHALL have the exact same reference data as the erroneously introduced\nevent with @event_status COMPLETED with the exception of the LegalEntityEventRecordedDate.\nLegalEntityEvent:\no @entity_status:\nWITHDRAWN_CANCELLED\no LegalEntityEventRecordedDate:\ne 2020-06-01T00:00:00+02:00\n@event_status: IN_PROGRESS\n@event_status: WITHDRAWN_CANCELLED\nLegalEntityEvent:\no @entity_status: IN_PROGRESS\nLegalEntityEventEffectiveDate:\n: & y @event_status: COMPLETED\no 2020-11-20T00:00:00+02:00\no LegalEntityEventRecordedDate: LegalEntityEvent:\no 2020-04-20T00:00:00+02:00\no @entity_status: COMPLETED\n¢ LegalEntityEventEffectiveDate: 2020-11-\nAffectedFields: 20T00:00:00+02:00\no Expected attribute values that will o LegalEntityEventRecordedDate: 2020-\nbe effective on November 20, 2020. 12-05T00:00:00+02:00\nFigure 9: Application of event timeline and event status\n4.13.2 Legal Entity Event — Legal Name changes\nThis Use Case only applies where the legal name changes and the Legal Entity remains an operating\nentity. This event applies to all entity categories. For cases where the LegalName changed due to a\nchange of LegalForm, see Use Case 4.13.5.\nThe LEl issuer:\ne SHALL update LegalName accordingly, as recorded by an official Registration Authority.\no SHALL create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be omitted.\nState Transition and Validation Rules for Common Data File formats Page 109 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1797,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.139Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be CHANGE_LEGAL NAME.\no LegalEntityEventEffectiveDate SHALL be the date the change in LegalName becomes effective\nin the Legal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no If @event_statusis IN_PROGRESS, the LEl issuer SHALL provide information regarding the\nAffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide lei:LegalName\ne SHALL provide lei:OtherEntityNames\no MAY provide lei:TransliteratedOtherEntityNames\no MAY provide lei:SuccessorEntity\ne SHALL include a new OtherEntityName with OtherEntityNameType PREVIOUS_LEGAL_NAME.\no SHALL update OtherEntityName with OtherEntityNameType\nALTERNATIVE_LANGUAGE_LEGAL_NAME, if necessary.\no SHALL update TransliteratedOtherEntityNames, if necessary.\nIf the change of the Legal Entity name is due to the formation of a new Legal Entity, then a new LEI\nSHALL be issued for the new Legal Entity (see sections 4.1 and 4.3) and the SuccessorEntity /\nSuccessorlLEl field of the old LEI Record SHALL be updated with the new LEI (see sections 4.13.22).\nState Transition and Validation Rules for Common Data File formats Page 110 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1355,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.139Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Reporting Exception An XML data record in REPEX-CDF format detailing the reported\nRecord (Repex) exception for not reporting a relationship type in a relationship\nrecord, as reported by a Legal Entity to its LOU, and by the LOU to\nGLEIF.\nSystem of National The System of National Accounts (SNA) is the internationally agreed\nAccounts (SNA) standard set of recommendations on how to compile measures of\neconomic activity. The SNA defines resident Government Entities as\nnon-market producers, part of the central, state or local\ngovernment, social security funds or non-profit institutions (NPI)\ncontrolled by government units.\n(https://unstats.un.org/unsd/nationalaccount/sna.asp)\nSubsidiary A Legal Entity controlled by a holding company.\nTransition Rule A rule stipulating what LOUs, GLEIF and Legal Entities must do when\nan LEI Record Set changes from one allowed state to another.\nUse Case A specific operation scenario which applies one or more Business\nRules.\nValidation Ensures complete, reasonable, sensible data within acceptable\nboundaries by checking the data that is being entered.\nVerification Entered data matches exactly the Validation source.\n1.2 Terminology and Typographical Conventions\nWithin this document, the terms, as will be SHALL and MAY, are to be interpreted as specified in\nAnnex G of the ISO/IEC Directives, Part 2, 2001, 4th edition:\nSHALL (NOT) Requirement\nMAY Permission / Possibility\nWhen used in this way, these terms will always be shown in ALL CAPS; when these words appear in\nordinary typeface, they are intended to have their ordinary English meaning. All sections of this\nState Transition and Validation Rules for Common Data File formats Page 12 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1793,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.139Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"O LegalName changes O\n—>\nLEI A LEI A\nPre Event Post Event\nLEI A LEIA\nEntity: Entity:\no LegalName: ,Former LegalName“ o LegalName: ,New LegalName“\no OtherEntityName: “Former LegalName”\nRegistration: o OtherEntityNameType:\no lei:RegistrationStatus: ISSUED PREVIOUS_LEGAL_NAME\no LastUpdateDate: 2019-07-01T11:13:00+01:00\nRegistration:\no RegistrationStatus: ISSUED\no LastUpdateDate:\no 2020-04-16T17:43:00+02:00\nLegalEntityEvent:\no @group_type: STANDALONE\no @event_status: COMPLETED\no LegalEntityEventType: CHANGE_LEGAL_NAME\no LegalEntityEventEffectiveDate:\ne 2020-04-13T00:00:00.000Z\no LegalEntityEventRecordedDate:\ne 2020-04-16T00:00:00.000Z\no ValidationDocuments:\nSUPPORTING_DOCUMENTS\no ValidationReference:\nhttp://pub_registry.gov/new_entity_docs.pdf\nExample 1: The Legal Entity “Former LegalName” with an LEI A changed its name to “New LegalName” with effective\ndate April 13, 2020. The LEl issuer updated the record and published it in the Global LEI System on April 16, 2020. The\nchange of the name can be validated in the business registry where the Legal Entity is registered.\nState Transition and Validation Rules for Common Data File formats Page 111 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1269,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.139Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.13.3 Legal Entity Event — Business or trading name changes\nThis Use Case only applies where a business or trading name changes, the LegalName does not\nchange and the Legal Entity remains an operating entity. This event applies to all entity categories\nexcept for Government entities.\nThe LEl issuer:\no SHALL update OtherEntityName with OtherEntityNameType TRADING_OR_OPERATING_NAME\naccordingly.\no SHALL create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be CHANGE_OTHER_NAMES.\no LegalEntityEventEffectiveDate SHALL be the date the change in OtherEntityName becomes\neffective in the Legal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no If @event_statusis IN_PROGRESS, the LEl issuer SHALL provide information regarding the\nAffectedFields: For @field_xpath the LEl issuer usually\ne SHALL provide lei:OtherEntityNames\no MAY provide lei:TransliteratedOtherEntityNames\no MAY provide lei:SuccessorEntity\nIf the change of the Legal Entity’s business or trading name is due to the formation of a new Legal\nEntity, then a new LEI SHALL be issued for the new Legal Entity (see Use Cases 4.1 and 4.3) and the\nSuccessorEntity / SuccessorLEl field of the old LEI Record SHALL be updated with the new LEI (see\nUse Case 4.13.22).\nState Transition and Validation Rules for Common Data File formats Page 112 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1685,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.139Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"O Business or trading name changes O\nN — S\nLEI A LEI A\nPre Event Post Event\nLEI A LEI A\nEntity: Entity:\no LegalName: “Good company name” o LegalName: “Good company name”\no OtherEntityName: “GoodCo”\nRegistration: o OtherEntityNameType:\no lei:RegistrationStatus: LAPSED TRADING_OR_OPERATING_NAME\no LastUpdateDate: 2019-07-01T11:13:00+01:00\no NextRenewalDate: 2020-01- Registration:\n01T00:00:00+01:00 o lei:RegistrationStatus: ISSUED\no LastUpdateDate: 2020-01-23T10:42:00+02:00\no NextRenewalDate: 2021-01-\n01T00:00:00+01:00\nLegalEntityEvent:\no @group_type: STANDALONE\no @event_status: COMPLETED\no LegalEntityEventType:\nCHANGE_OTHER_NAMES\no LegalEntityEventEffectiveDate:\ne 2020-01-15T00:00:00.000Z\no LegalEntityEventRecordedDate:\ne 2020-01-23T00:00:00.000Z\no ValidationDocuments: CONTRACTS\no ValidationReference: Notarized documents\nExample 2: The Legal Entity ,,Good company name“ uses “GoodCo” as a new trading name as of January 15, 2020. The\nLegal Entity Event was recorded in the Global LEI System on January 23, 2020 in the course of renewal, after initially the\nLEI lapsed.\nState Transition and Validation Rules for Common Data File formats Page 113 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1266,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.139Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.13.4 Legal Entity Event — Address information changes\nThis Use Case only applies where the LegalAddress or HeadquartersAddress changes and the Legal\nEntity remains an operating entity. This event applies to all entity categories.\nThe LEl issuer:\no SHALL update LegalAddress and/or HeadquartersAddress accordingly.\no SHALL create a new LegalEntityEvent for each address changed with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be CHANGE_LEGAL_ADDRESS or CHANGE_HQ_ADDRESS,\nrespectively.\no LegalEntityEventEffectiveDate SHALL be the date the change in address becomes effective in\nthe Legal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no If @event_statusis IN_PROGRESS, the LEl issuer SHALL provide information regarding the\nAffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide lei:LegalAddress/* and/or lei:HeadquartersAddress/*\no MAY provide lei:OtherAddresses/*\n* MAY provide lei:TransliteratedOtherAddresses/*\no MAY provide lei:SuccessorEntity\ne Forall above mentioned address containers (LegalAddress, HeadquartersAddress,\nOtherAddresses and TransliteratedOtherAddresses) the concrete data elements SHALL be\nprovided.\no SHALL update OtherAddresses with type ALTERNATIVE_LANGUAGE_LEGAL_ADDRESS and/or\nALTERNATIVE_LANGUAGE_HEADQUARTERS_ADDRESS, if necessary.\no SHALL update TransliteratedOtherAddresses, if necessary.\no SHALL check, if also the Registration Information changed (see Use Case 4.15).\nIf the change of the legal address is due to the formation of a new Legal Entity, then a new LEI SHALL\nbe issued (see Use Cases 4.1 and 4.3) and the SuccessorEntity / SuccessorLEl field of the old LEI\nrecord SHALL be updated with the new LEI (see Use Case 4.13.22). Example 3 provides a specific use\ncase for changing address information.\nState Transition and Validation Rules for Common Data File formats Page 114 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2199,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.139Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"O Address information changes O\n———>\nLEI A LEI A\nIn-progress Event Post Event\nLEI A LEI A\nEntity: Entity:\no FirstAddressLine: “Streetname former legal o FirstAddressLine: “Streetname new legal\naddress 1” address 5”\no AddressNumber: 1 o AddressNumber: 5\nRegistration: Registration:\no RegistrationStatus: ISSUED o RegistrationStatus: ISSUED\no LastUpdateDate: 2019-07-01T11:13:00+01:00 o LastUpdateDate: 2020-01-23T710:42:00+02:00\nLegalEntityEvent: LegalEntityEvent:\no @group_type: STANDALONE o @group_type: STANDALONE\no @event_status: IN_PROGRESS o @event_status: IN_PROGRESS\no LegalEntityEventType: o LegalEntityEventType:\nCHANGE_LEGAL_ADDRESS CHANGE_LEGAL_ADDRESS\no LegalEntityEventEffectiveDate: o LegalEntityEventEffectiveDate:\ne 2020-01-15T00:00:00.000Z e 2020-01-15T00:00:00.000Z\no LegalEntityEventRecordedDate: o LegalEntityEventRecordedDate:\ne 2019-07-07T00:00:00+01:00 e 2019-07-07T00:00:00+01:00\no ValidationDocuments: ¢ ValidationDocuments:\nSUPPORTING_DOCUMENTS SUPPORTING_DOCUMENTS\no ValidationReference: o ValidationReference:\nhttp://pub_registry.gov/new_entity_docs.pdf http://pub_registry.gov/new_entity_docs.pdf\nAffectedFields: LegalEntityEvent:\no Entity/LegalAddress/FirstAddressLine: o @group_type: STANDALONE\no @event_status: COMPLETED\no LegalEntityEventType:\nCHANGE_LEGAL_ADDRESS\no LegalEntityEventEffectiveDate:\nExample 3: The Legal Entity makes available the information about a change in the legal address that will become\neffective on January 15, 2020. In the example only the street and address number change. The change of the legal\naddress was recorded in the Global LEI System on July 7, 2019 as in-progress event. The completion of the Legal Entity\nEvent was validated in the local registry and recorded in the Global LEI System on January 23, 2020.\nState Transition and Validation Rules for Common Data File formats Page 115 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1973,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.139Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.13.5 Legal Entity Event — Legal form changes\nA change of the legal form potentially has different degrees of impact on the Legal Entity. The\nfollowing three Use Cases describe the most common variants. They apply to all entity categories.\nFor cases where an ELF code is supplied for the first time, see section 2.8 instead.\nThe first Use Case (Example 4) applies when only the legal form changes and the Legal Entity remains\nan operating entity. An example could be that the legal forms used in the Legal Entity’s jurisdiction\nare transformed into other legal forms while preserving the legal status of the Legal Entities.\nIn this case, the LEl issuer:\ne SHALL update LegalForm accordingly, following the general rules for Entity Legal Form Reporting\n(see section 2.8).\no SHALL create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be CHANGE_LEGAL_FORM.\no LegalEntityEventEffectiveDate SHALL be the date the change in the legal form becomes\neffective in the Legal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no If @event_statusis IN_PROGRESS, the LEl issuer SHALL provide information regarding the\nAffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide lei:EntityLegalFormCode and lei:OtherLegalForm, if necessary\no MAY provide lei:Legallurisdiction\no MAY provide lei:SuccessorEntity\no SHALL check, if also Registration Information has changed (see Use Case 4.15).\nState Transition and Validation Rules for Common Data File formats Page 116 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1848,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.139Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"O LegalForm changes O\n———’\nLEI A LEI A\nIn-progress Event Post Event\nLEI A LEI A\n\nEntity: Entity:\n\no EntityLegalFormCode: 059 o EntitylegalFormCode: Y1Q4\n\nRegistration: Registration\n\no RegistrationStatus: ISSUED o RegistrationStatus: ISSUED\n\no LlastUpdateDate: 2019-07-01711:13:00+01:00 o LastUpdateDate: 2020-01-23T710:42:00+02:00\n\nLegalEntityEvent: LegalEntityEvent:\n\no @group_type: STANDALONE o @group_type: STANDALONE\n\no @event_status: IN_PROGRESS o @event_status: IN_PROGRESS\n\no LegalEntityEventType: o LegalEntityEventType:\n\nCHANGE_LEGAL_FORM CHANGE_LEGAL_FORM\n\no LegalEntityEventEffectiveDate: o LegalEntityEventEffectiveDate:\n\ne 2020-01-15T00:00:00.000Z e 2020-01-15T00:00:00.000Z\n\no LegalEntityEventRecordedDate: o LegalEntityEventRecordedDate:\n\ne 2019-07-01T00:00:00+01:00 e 2019-07-01T00:00:00+01:00\n\no ValidationDocuments: ¢ ValidationDocuments:\nSUPPORTING_DOCUMENTS SUPPORTING_DOCUMENTS\n\no ValidationReference: o ValidationReference:\nhttp://registry.gov/evidence.pdf http://registry.gov/evidence.pdf\n\nAffectedFields: AffectedFields:\n\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:E o /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:E\nntity/lei:LegalForm/lei:EntityLegalFormCode: ntity/lei:LegalForm/lei:EntityLegalFormCode:\nY1Q4 Y1Q4\n\nLegalEntityEvent:\no @group_type: STANDALONE\no @event_status: COMPLETED\no LegalEntityEventType:\nCHANGE_LEGAL_FORM\no LegalEntityEventEffectiveDate:\ne 2020-01-15T00:00:00.000Z\no LegalEntityEventRecordedDate:\ne 2020-01-23T00:00:00.000Z\n¢ ValidationDocuments:\nSUPPORTING_DOCUMENTS\no ValidationReference:\nhttp://registry.gov/evidence.pdf\nExample 4: The Legal Entity changes its legal form from ELF O59C to ELF Y1Q4 with effective date January 15, 2020. The\nLEl issuer has published this change on July 1, 2019 prior to the effective date. The completion of the Legal Entity Event\nwas recorded in the Global LEI System on January 23, 2020.\nState Transition and Validation Rules for Common Data File formats Page 117 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2074,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.139Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"The second Use Case (Example 5) applies when also the legal name changes due to the legal form\nchange and the Legal Entity remains an operating entity.\nIn this case, the LEl issuer:\no SHALL update LegalForm accordingly, following the general rules for Entity Legal Form Reporting\n(see section 2.8).\no SHALL create a new LegalEntityEvent for the legal form change with:\no @group_type SHALL be CHANGE_LEGAL_FORM_AND_NAME.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be a unique identifier (e.g., a hash value calculated from the combination\nof the LEl, EventType and EffectiveDate).\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be CHANGE_LEGAL_FORM.\no LegalEntityEventEffectiveDate SHALL be the date the change in the legal form becomes\neffective in the Legal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no If @event_status is IN_PROGRESS, the LEl issuer SHALL provide information regarding the\nAffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide lei:EntityLegalFormCode and lei:OtherLegalForm, if necessary\no MAY provide lei:Legallurisdiction\no MAY provide lei:SuccessorEntity\no SHALL create a new LegalEntityEvent for the legal name change with (see Use Case 4.13.2):\no @group_type SHALL be CHANGE_LEGAL FORM_AND_NAME.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be the same unique identifier used for the previous event.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be CHANGE_LEGAL NAME.\no LegalEntityEventEffectiveDate SHALL be the date the change in the legal form becomes\neffective in the Legal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\nState Transition and Validation Rules for Common Data File formats Page 118 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2070,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.139Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o If @event_statusis IN_PROGRESS, the LEl issuer SHALL provide information regarding the\n\nAffectedFields: For @field_xpath the LEl issuer usually\n\no SHALL provide lei:LegalName\n\ne SHALL provide lei:OtherEntityNames\n\no MAY provide lei:TransliteratedOtherEntityNames\n\no MAY provide lei:SuccessorEntity\n\no SHALL check, if also Registration Information has changed (see section 4.15).\nState Transition and Validation Rules for Common Data File formats Page 119 of 170\n@ Public Version 2.7.1 Final\n\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":566,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.139Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"LegalForm and LegalName change\n-\nPre Event Post Event\nLEI A LEI A\nEntity: Entity:\no EntityLegalFormCode: FGVH o EntityLegalFormCode: O85W\no LegalName: “Company Name Inc” o LegalName: “Company Name LLC”\nRegistration: Registration:\no lei:RegistrationStatus: ISSUED o lei:RegistrationStatus: ISSUED\no lastUpdateDate: 2019-07-01711:13:00+01:00 o LastUpdateDate: 2020-01-23T10:42:00+02:00\nLegalEntityEvent:\no @group_type:\nCHANGE_LEGAL_FORM_AND_NAME\no @group_id: dfecd444f23463443a98n12a\no @event_status: COMPLETED\no LegalEntityEventType:\nCHANGE_LEGAL_FORM\no LegalEntityEventEffectiveDate:\ne 2020-01-15T00:00:00.000Z\no LegalEntityEventRecordedDate:\ne 2020-01-23T00:00:00.000Z\no ValidationDocuments:\nSUPPORTING_DOCUMENTS\ne ValidationReference:\nhttp://pub_registry.gov/new_entity_docs.pdf\nLegalEntityEvent:\no @group_type:\nCHANGE_LEGAL_FORM_AND_NAME\no @group_id: dfecd444f23463443a98n12a\no @event_status: COMPLETED\no LegalEntityEventType:\nCHANGE_LEGAL_NAME\no ValidationDocuments:\nSUPPORTING_DOCUMENTS\no LegalEntityEventEffectiveDate:\ne 2020-01-15T00:00:00.000Z\no LegalEntityEventRecordedDate:\ne 2020-01-23T00:00:00.000Z\no ValidationDocuments:\nSUPPORTING_DOCUMENTS\ne ValidationReference:\nhttp://pub_registry.gov/new_entity_docs.pdf\nExample 5: The Legal Entity changes its legal form from ELF FGVH to ELF O85W with effective date January 15, 2020 and\nadditionally changes its legal name. The completion of the Legal Entity Event was recorded in the Global LEI System on\nJanuary 23, 2020.\nState Transition and Validation Rules for Common Data File formats Page 120 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1667,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.139Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"document, with the exception of the Introduction, are normative, except where explicitly noted as\nnon-normative. The following typographical conventions are used throughout the document:\no ALL CAPS type is used for the special terms enumerated above and when in the text is referred to\na data field value from an enumerated list.\no CamelCase type is used to refer to the data elements as declared in the CDF XML Schema\nDefinition (xsd).\nState Transition and Validation Rules for Common Data File formats Page 13 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":620,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.139Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"The third Use Case (Example 6) applies when the legal form change creates a new Legal Entity while\nthe previous Legal Entity ceases to exist.\n\nIn this case, the LEl issuer:\n\no SHALL retire the LEI Record Set of the previous Legal Entity:\n\no Set RegistrationStatus to RETIRED.\n\no Set RegistrationStatus of all current Relationship Records to RETIRED with RelationshipStatus\nINACTIVE; set EndDate of RelationshipPeriod with PeriodType RELATIONSHIP_PERIOD as\nLegalEntityEventEffectiveDate of the event (see below).\n\no Setthe new Legal Entity (see below) as SuccessorEntity.\n\ne Create a new LegalEntityEvent for the LEI Record Set of the previous Legal Entity with:\n\no @group_type SHALL be COMPLEX_CHANGE_LEGAL_FORM.\n\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\n\no @group_id SHALL be omitted.\n\no @group_sequence_no SHALL be omitted.\n\no LegalEntityEventType SHALL be CHANGE_LEGAL_FORM.\n\no LegalEntityEventEffectiveDate SHALL be date the change in the legal form becomes effective\nin the Legal Jurisdiction of the Legal Entity.\n\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\n\no If @event_statusis IN_PROGRESS, the LEl issuer SHALL provide information regarding the\nAffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide lei:EntityLegalFormCode and lei:OtherLegalForm, if necessary\no MAY provide lei:Legallurisdiction\no MAY provide lei:LegalName\no MAY provide lei:OtherEntityNames\no MAY provide lei:TransliteratedOtherEntityNames\no MAY provide lei:SuccessorEntity\n\no If @event_status is COMPLETED and there is at least one SuccessorEntity entry added to the LEI\n\nRecord Set, the LEl issuer SHALL provide information regarding the AffectedFields: For\n\n@field_xpath the LEl issuer usually\n\no SHALL provide lei:SuccessorEntity\n\no Issue a new LEI Record (see Use Cases 4.1 and 4.3), including all appropriate relationships.\nState Transition and Validation Rules for Common Data File formats Page 121 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2099,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.139Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o For the newly issued LEI Record, create a new LegalEntityEvent with:\no @group_type SHALL be COMPLEX_CHANGE_LEGAL_FORM.\no @event_status SHALL be COMPLETED.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be CHANGE_LEGAL_FORM.\no LegalEntityEventEffectiveDate SHALL be the date when the change in the legal form becomes\neffective in the Legal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no AffectedFields SHALL be omitted.\nState Transition and Validation Rules for Common Data File formats Page 122 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":749,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.139Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"LegalForm changes and LEI A retires\n_————’\nPost Event Post Event\nLEIA LEI B (Create new LEI Record Set)\nEntity: Entity:\no EntityLegalFormCode: FGVH o EntityLegalFormCode: O85W\no LegalName: Company inc o LegalName: Company LLC\no SuccessorlLEl: B o EntityCreationDate:\ne 2020-01-15T00:00:00.000Z\nRegistration:\no lei:RegistrationStatus: RETIRED Registration:\no lei:LastUpdateDate: o lei:RegistrationStatus: ISSUED\no 2020-01-23T10:42:00+02:00 o lei:LastUpdateDate:\no 2020-01-23T10:42:00+02:00\nRelationship:\no rr:RegistrationStatus: RETIRED LegalEntityEvent:\no rr:RelationshipStatus: INACTIVE o @group_type:\no rr:LastUpdateDate: COMPLEX_CHANGE_LEGAL_FORM\no 2020-01-23T10:42:00+02:00 e @event_status: COMPLETED\no LegalEntityEventType:\nLegalEntityEvent: CHANGE_LEGAL_FORM\n° (@group_type: o LegalEntityEventEffectiveDate:\nCOMPLEX_CHANGE_LEGAL_FORM e 2020-01-15T00:00:00.000Z\no @event_status: COMPLETED o LegalEntityEventRecordedDate:\no LegalEntityEventType: e 2020-01-23T00:00:00.000Z\nCHANGE_LEGAL_FORM ¢ ValidationDocuments:\no LegalEntityEventEffectiveDate: SUPPORTING_DOCUMENTS\ne 2020-01-15T00:00:00.000Z o ValidationReference:\no LegalEntityEventRecordedDate: http://pub_registry.gov/new_entity_docs.pdf\no 2020-01-23T00:00:00+01:00\no ValidationDocuments:\nSUPPORTING_DOCUMENTS\no ValidationReference:\nhttp://pub_registry.gov/new_entity docs.pdf\nAffectedFields:\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:E\nntity/lei:SuccessorEntity/lei:SuccessorLEl:\nLEI B\nExample 6: Legal Entity LEI A changes its legal form from ELF O59C to ELF NSNT with effective date January 15, 2020. As a\nconsequence, LEI A retires, and an LEI Record Set for LEI B is created. The completion of the Legal Entity Event was\nrecorded in the Global LEI System on January 23, 2020.\nState Transition and Validation Rules for Common Data File formats Page 123 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1938,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.139Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"A legal form change could result in one of the three above described scenarios. The LEl issuer SHALL\nassess and evaluate the documents at hand and decide which of the three scenarios apply in the\nparticular case.\n4.13.6 Legal Entity Event — Acquisition\nLegal Entity A (general Legal Entity or Fund, but not Branch, Government Entity or International\nOrganization), either independent/stand-alone or Subsidiary/sub-fund/compartment, is acquired by\nanother Legal Entity B but remains a separate/segregated Legal Entity.\nThe LEl issuer managing the record of entity A SHALL:\no Retire any current Relationship Records and/or stop publishing Reporting Exception Records for\nA.\no Create new relationships/exceptions with parent Legal Entity B (including Fund relationships, if\napplicable).\no Create a new LegalEntityEvent (single, combined or group, as applicable) with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be MERGERS_AND_ACQUISITIONS.\no LegalEntityEventEffectiveDate SHALL be the date the acquisition becomes effective in the\nLegal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no If @event_statusis IN_PROGRESS, the LEl issuer SHALL provide information regarding the\nAffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide rr:EndNode/rr:NodelD\no SHALL provide rr:EndNode/rr:NodeType\no SHALL provide rr:RelationshipType\n* MAY provide repex:ExceptionCategory\no MAY provide repex:ExceptionReason\nState Transition and Validation Rules for Common Data File formats Page 124 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1849,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.139Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"O Acquired by O\n- >\nLEIA LEIB\nPost Event\nLEI A\nRelationship:\no rr:RegistrationStatus: RETIRED\no rr:LastUpdateDate: 2020-04-16T17:43:00.000Z\no Create new RelationshipRecords, if applicable\no Stop publishing ReportingExceptions, if applicable\nLegalEntityEvent:\no @group_type: STANDALONE\no @event_status: COMPLETED\no LegalEntityEventType: MERGERS_AND_ACQUISITIONS\no LegalEntityEventEffectiveDate: 2020-03-02T00:00:00.000Z\no LegalEntityEventRecordedDate: 2020-04-16T00:00:00.000Z\no ValidationDocuments: SUPPORTING_DOCUMENTS\no ValidationReference: http://registry.gov/evidence.pdf\nExample 7: The Legal Entity with LEI A is acquired by Legal Entity with LEI B with effective date on March 2, 2020 and\nrecorded in the Global LEI System on April 16, 2020.\n4.13.7 Legal Entity Event — Absorption\nLegal Entity A (general Legal Entity or Fund, but not Branch, Government Entity or International\nOrganization), either independent/stand-alone or Subsidiary/sub-fund/compartment, is acquired by\nanother Legal Entity B (may or may not be in a parent relationship with A). All assets/shares of Legal\nEntity A are absorbed by Legal Entity B and A ceases to exist as an active Legal Entity.\nNote: The addition of Absorption to the list of Legal Entity Events covered by the policy is under\nreview with the LEI-ROC.\nThe LEl issuer managing the record of Legal Entity A SHALL:\no Retire LEI Record Set of absorbed Legal Entity A:\no Set RegistrationStatus RETIRED.\ne Set current relationships to RETIRED, if applicable.\no Set Legal Entity B as SuccessorEntity.\nState Transition and Validation Rules for Common Data File formats Page 125 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1726,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.140Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be ABSORPTION.\no LegalEntityEventEffectiveDate SHALL be the date the Absorption becomes effective in the\nLegal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no If @event_status is IN_PROGRESS or COMPLETED, the LEl issuer SHALL provide information\nregarding the AffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide lei:SuccessorEntity\nThe LEl issuer managing the record of entity B SHALL:\no Record the absorption of Legal Entity A by creating a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be ABSORPTION.\no LegalEntityEventEffectiveDate SHALL be the date the Absorption becomes effective in the\nLegal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\n© AffectedFields SHALL be omitted.\nNote: LEI Records for A and B MAY be managed by different LEl issuers. Nevertheless, there SHALL be\nconsistency for the LegalEntityEventEffectiveDate and ValidationReference of the event; Recorded\nDate MAY be different.\nState Transition and Validation Rules for Common Data File formats Page 126 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1645,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.140Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"O Absorbed by O\nR\nLEI A LEIB\nPost Event Post Event\nLEI A LEI B\nEntity: LegalEntityEvent:\no SuccessorEntity: LEI B o @group_type: STANDALONE\no @event_status: COMPLETED\nRegistration: o LegalEntityEventType: ABSORPTION\no RegistrationStatus: RETIRED o LegalEntityEventEffectiveDate:\no LastUpdateDate: 2020-01-23T10:42:00+02:00 e 2020-01-20T00:00:00.000Z\no LegalEntityEventRecordedDate:\nRelationship: e 2020-01-23T00:00:00.000Z\no Stop publishing ReportingExceptions » ValidationDocuments:\nSUPPORTING_DOCUMENTS\nRelationship Registraion: « ValidationReference:\no RegistrationStatus: RETIRED http://registry.gov/evidence.pdf\no LastUpdateDate: 2020-01-23T10:42:00+02:00\nLegalEntityEvent:\no @group_type: STANDALONE\no @event_status: COMPLETED\no LegalEntityEventType: ABSORPTION\no LegalEntityEventEffectiveDate:\ne 2020-01-20T00:00:00.000Z\no LegalEntityEventRecordedDate:\ne 2020-01-23T00:00:00.000Z\no ValidationDocuments:\nSUPPORTING_DOCUMENTS\no ValidationReference:\nhttp://registry.gov/evidence.pdf\nAffectedFields:\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:E\nntity/lei:SuccessorEntity/lei:SuccessorLEl:\nLEI B\nExample 8: The Legal Entity with LEI A is absorbed by a Legal Entity with an LEI B with effective date January 20, 2020 and\nboth records have been updated on the same date January 23, 2020.\nState Transition and Validation Rules for Common Data File formats Page 127 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1480,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.140Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.13.8 Legal Entity Event — Merger\nA common example how a Merger is processed and its outcome:\nLegal Entity A (not a Branch) and Legal Entity B (not a Branch either and usually of a similar category\nas A) combine their shares/assets and together form a new Legal Entity C (general Legal Entity or\nFund, but not Branch). A and B cease to exist as Legal Entities after the Merger.\nThe LEl issuer(s) managing the LEI Record Sets of entities A and B SHALL:\no Retire records of entity A and entity B once @event_status is COMPLETED:\no Set RegistrationStatus RETIRED.\no Set EntityStatus INACTIVE.\ne Set current relationships to RETIRED, if applicable.\no Set Legal Entity C as SuccessorEntity.\no Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be MERGERS_AND_ACQUISITIONS.\no LegalEntityEventEffectiveDate SHALL be the date the Merger becomes effective in the Legal\nJurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no If @event_status is IN_PROGRESS or COMPLETED, the LEl issuer SHALL provide information\nregarding the AffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide lei:SuccessorEntity\nThe LEl issuer creating the new LEI Record for Legal Entity C SHALL:\n¢ Issue a new LEI Record (see Use Case Issue new LEI), including all appropriate relationships.\no Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be omitted.\nG State Transition and Validation Rules for Common Data File formats Page 128 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1912,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.140Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be MERGERS_AND_ACQUISITIONS.\no LegalEntityEventEffectiveDate SHALL be the date the Merger becomes effective in the Legal\nJurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no AffectedFields SHALL be omitted.\nLEIB\nMerge O\nLEIC\nLEI A\nPre Event Post Event\nState Transition and Validation Rules for Common Data File formats Page 129 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":590,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.140Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Pre & Post Event Post Event\nLEI A; LEIB LEI C (Create new LEI Record Set)\nEntity: Entity:\no EntityStatus: INACTIVE (Post Event) o LegalName: “New Firm LLC”\no SuccessorEntity: LEI C (Post Event) o EntityStatus: ACTIVE\no CreationDate:\nRegistration LE| A: 2020-04-19T00:00:00+02:00\no RegistrationStatus: RETIRED (Post Event)\no LastUpdateDate (Post Event): Registration:\no LEI A: 2020-04-20T13:43:25+02:00 o RegistrationStatus: ISSUED\no LEIB: 2020-05-20T13:43:25+02:00 ¢ InitialRegistrationDate:\n2020-04-20T00:00:00+02:00\nRelationship (Post Event):\n« Stop publishing ReportingExceptions LegalEntityEvent:\no @group_type: STANDALONE\nRelationship Registration (Post Event): o @event_status: COMPLETED\no RegistrationStatus: RETIRED o LegalEntityEventType:\nMERGERS_AND_ACQUISITIONS\nLegalEntityEvent (Pre & Post Event): o LegalEntityEventEffectiveDate:\no @group_type: STANDALONE o 2020-04-19T00:00:00+02:00\no @entity_status: IN_PROGRESS o LegalEntityEventRecordedDate:\no LegalEntityEventType: MERGERS_AND_ACQUISITIONS o 2020-04-20T00:00:00+02:00\no LegalEntityEventEffectiveDate: o ValidationDocuments: CONTRACTS\ne 2020-04-19T00:00:00+02:00 o ValidationReference: Notarized documents\no LegalEntityEventRecordedDate:\no LEI A: 2020-03-11T00:00:00+02:00\ne LEIB: 2020-03-13T00:00:00+02:00\no ValidationDocuments: SUPPORTING_DOCUMENTS\no ValidationReference: http://registry.gov/evidence.pdf .\nExample 9: LEI A and LEI B merge into LEI C (new Legal\n. Entity). LEI A and LEI B cease to exist on April 19, 2020.\nAffectedFields: The LEl issuer of LEI A was made aware of the\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei: incoming merger on 11 March 2020, while the LEI\nSuccessorEntity/lei:SuccessorLEl: LEI C issuer of LEI B was made aware of the incoming\nmerger on 13 March 2020. Both LOUs were given the\nLegalEntityEvent (Post Event): information that the legal name of LEI C will be “New\n« @group_type: STANDALONE Firn:l LLC” and that the merger will be complete.d on 19\n« @entity_status: COMPLETED April 2020. The recorded dates.of the Legal Entity\n- Events MAY vary between the involved records, as\no LegalEntityEventType: MERGERS_AND_ACQUISITIONS these may be managed by different LEI issuers.\no LegalEntityEventEffectiveDate:\no 2020-04-19T00:00:00+02:00\no LegalEntityEventRecordedDate:\ne LEI A: 2020-04-20T00:00:00+02:00\ne LEI B: 2020-05-20T00:00:00+02:00\no ValidationDocuments: SUPPORTING_DOCUMENTS\no ValidationReference: http://registry.gov/evidence.pdf\nAffectedFields:\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:\nSuccessorEntity/lei:SuccessorLEl: LEI C\nState Transition and Validation Rules for Common Data File formats Page 130 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2768,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.140Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"2 Lifecycle and General Concepts\n\n2.1 LEI Record Set Reference Data\n\nThe LEI Record Set consists of a set of one LEI record and its corresponding Relationship Records (RR),\n\nand Reporting Exception Records (Repex) that give the full Level 1 and Level 2 Reference Data for\n\nthat LEL.\n\nLEI records, Relationship Records and Reporting Exception Records each consist of a pre-defined set\n\nof mandatory and optional data elements. The following types of elements are used within the LEI\n\nRecord Set:\n\no Fixed list of allowed values (enumerations): only values defined in the respective xsd file are\nallowed. Example element: RegistrationStatus.\n\no Codes from a code list: only values from the current version of the referenced code list are\nallowed. Example element: LegalFormCode.\n\no Fixed format: only values with a specific format pattern are allowed. Example element: LEI.\n\no Free text: any content allowed. The xsd MAY have some restrictions defined (length, character\nset, no leading/trailing spaces). The content of a free text element SHALL NOT be “N/A” or similar\nplaceholder. Example element: LegalName.\n\n2.1.1 Legal Entity data (Level 1 data — ‘Who is who’)\n\nThe Legal Entity Identifier (LEl) connects to key Reference Data that provides the information on a\n\nLegal Entity identifiable with an LEI. The ISO 17442 standard developed by the International\n\nOrganization for Standardization defines a set of attributes that comprises the most essential\n\nelements of identification. The standard specifies the minimum Reference Data, which must be\n\nsupplied for each LEIl and further requirements for the LEI code and provided Reference Data. For the\ncomplete scope and content of the standard, please refer to the International Organization for\n\nStandardization®.\n\nWith the inclusion of Legal Entity Events and the related update of the Common Data File format to\n\nversion 3.1, the Legal Entity data will be enriched with Legal Entity Event information that impacts\n\nthe Legal Entity and changes their reference data.\n\n2.1.2 Legal Entity relationship information (Level 2 data — ‘Who owns whom’)\n\nLegal Entity relationship information describe the relationship between two Legal Entities. All\n\nrelationships have a specific type describing the kind of the relationship and two end points defining\n\nL https://www.iso.org/standard/75998.html\n\nState Transition and Validation Rules for Common Data File formats Page 14 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2526,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.143Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.13.9 Legal Entity Event — Transformation of a Subsidiary to an International Branch\nLegal Entity A (a general Legal Entity) in country X, a Subsidiary of parent Legal Entity B in country Y,\nis absorbed by Legal Entity B and turned into an International Branch. All shares/assets and liabilities\nof Legal Entity A are absorbed by Legal Entity B. This Legal Entity Event can only be recorded if Legal\nEntity A fulfills all the requirements for International Branches within the Global LEI System (see\nsection 4.2); otherwise, a different Legal Entity Event could apply. In case Legal Entity A is in the\nhome jurisdiction of Legal Entity B and it has been transformed to a Branch entity, the LEI of Legal\nEntity A SHALL be set to RETIRED since an International Branch LEI cannot be assigned in the home\njurisdiction. In that scenario the Legal Entity Event of type ABSORPTION MAY apply.\nFor the transformation of a subsidiary to an international branch, the LEl issuer managing the LEI\nRecord Set of Legal Entity A SHALL:\ne Update LEI Record Set of Legal Entity A to Branch:\no Set current relationships with Legal Entity B to RETIRED.\no Create a new relationship with Legal Entity B with RelationshipType\nIS_INTERNATIONAL BRANCH_OF; StartDate of the RelationshipPeriod with PeriodType\nRELATIONSHIP_PERIOD SHALL be the LegalEntityEventEffectiveDate of the Legal Entity Event\n(see below).\no Set EntityCategory to BRANCH.\ne Set the LegalForm and the ELF code to the LegalForm and the ELF code of the (head office)\nLegal Entity B.\no Set the Legal Jurisdiction to the Legal Jurisdiction of the (head office) Legal Entity B.\no Setthe RegistrationStatus (lei and rr) to either ISSUED or LAPSED, depending on the\nRegistrationStatus of the (head office) Legal Entity B.\no Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be TRANSFORMATION_SUBSIDIARY_TO_BRANCH\no LegalEntityEventEffectiveDate SHALL be the date the transformation becomes effective\nin the Legal Jurisdiction of the Legal Entity\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the\nGlobal LEI System.\nState Transition and Validation Rules for Common Data File formats Page 131 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2465,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.143Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o If @event_status is IN_PROGRESS, the LEl issuer SHALL provide information regarding\nthe AffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide rr:EndNode/rr:NodelD\no SHALL provide rr:EndNode/rr:NodeType\no SHALL provide rr:RelationshipType\no SHALL provide lei:EntityCategory\ne SHALL provide lei:SuccessorEntity, if applicable\no If @event_status is COMPLETED, the LEl issuer SHALL provide information regarding the\nAffectedFields: For @field_xpath the LEl issuer usually\ne SHALL provide lei:SuccessorEntity, if applicable\nState Transition and Validation Rules for Common Data File formats Page 132 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":723,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.143Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Switzerland O Transformed into O Belgium\nLET A International branch of LEI B\nPost Event Post Event\nLEI B\nLEI A\nEntity:\nEntity: o EntityLegalformCode: N5NT\ne EntityCategory: BRANCH o Legallurisdiction: BE\no EntityLegalformCode: N5NT\no Legallurisdiction: BE Registration:\no RegistrationStatus: ISSUED\nRegistration:\no RegistrationStatus: ISSUED Relationship Registration:\no RegistrationStatus: PUBLISHED\nRelationship: © LastUpdateDate:\no RegistrationStatus of previous relationships with LEI s 2020-04-20T13:43:25+02:00\nB: RETIRED\no Create new RelationshipRecord with LEI B with\nRelationship/RelationshipType\nIS INTERNATIONAL BRANCH OF Example 10: The Legal Entity with LEI A,\n* RelationshipPeriodStartDate: r:::\\csi;cnlrisez ?rl:tb:adr:ai:\\‘{c::nl-aili:;\\:l branch\n° 2020-04-18T00:00:00+02:00 of Legal Entity B with effective date April\n18, 2020. Both records have been\nRelationship Registration: updated on the same date April 20, 2020.\no RegistrationStatus: PUBLISHED\no LastUpdateDate: 2020-04-20T13:43:25+02:00\nLegalEntityEvent:\no @group_type: STANDALONE\no @entity_status: COMPLETED\no LegalEntityEventType:\nTRANSFORMATION_SUBSIDIARY_TO_BRANCH\no LegalEntityEventEffectiveDate:\no 2020-04-18T00:00:00+02:00\no LegalEntityEventRecordedDate:\no 2020-04-20T00:00:00+02:00\no ValidationDocuments: CONTRACTS\no ValidationReference: Notarized documents\nIf applicable, LegalEntityEvent:\no @group_type: STANDALONE\no @entity_status: COMPLETED\no LegalEntityEventType: CHANGE_LEGAL_FORM\no LegalEntityEventEffectiveDate:\no 2020-04-18T00:00:00+02:00\no LegalEntityEventRecordedDate:\no 2020-04-20T00:00:00+02:00\no ValidationDocuments: CONTRACTS\no ValidationReference: Notarized documents\nState Transition and Validation Rules for Common Data File formats Page 133 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1860,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.143Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.13.10 Legal Entity Event — Acquisition of an International Branch\nA common example how Acquisition of an International Branch is processed and its outcome:\nInternational Branch A of (head office) Legal Entity B, is acquired by Legal Entity C and henceforth\noperates as Branch for (head office) Legal Entity C. The assets and liabilities related to the Branch are\nfully or partially transferred from Legal Entity B to Legal Entity C. Legal Entity B will have International\nBranch A deleted from the official registry (RA source). Legal Entity C will register a new International\nBranch D in the official registry. This Legal Entity Event can only be recorded if Legal Entity D fulfills all\nthe requirements for International Branches within the Global LEI System (see section 4.2).\nThe LEl issuer managing the LEI Record Set of International Branch A SHALL:\no Set the RegistrationStatus (lei and rr) to RETIRED\no Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be ACQUISITION_BRANCH.\no LegalEntityEventEffectiveDate SHALL be the date the acquisition of the Branch becomes\neffective in the Legal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no If @event_statusis IN_PROGRESS or COMPLETED, the LEl issuer SHALL provide information\nregarding the AffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide lei:SuccessorEntity\no Set the new International Branch (see below) as SuccessorEntity.\nThe LEl issuer managing the LEI Record Set of Branch entity D SHALL:\no Create a new LEI Record for a Branch, if the conditions for issuing an LEI Record for a Branch are\nmet (see Use Case 4.2).\no Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be COMPLETED.\no @group_id SHALL be omitted.\nState Transition and Validation Rules for Common Data File formats Page 134 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2206,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.143Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be ACQUISITION_BRANCH.\no LegalEntityEventEffectiveDate SHALL be the date the acquisition of the Branch becomes\neffective in the Legal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no AffectedFields SHALL be omitted.\no The EntityCreationDate SHALL be the LegalEntiyEventEffectiveDate of entity A’s event with\nLegalEntityEventType ACQUISITION_BRANCH.\n¢ The LegalEntityEventEffectiveDate SHALL be the date the Acquisition becomes effective in the\nLegal Jurisdiction of Branch entity A.\ne Set the LegalForm and the ELF code to the LegalForm and the ELF code of the (head office) Legal\nEntity C.\no Set the Legal Jurisdiction to the Legal Jurisdiction of the (head office) Legal Entity C.\n¢ Create a Relationship Record with the head office C and RelationshipType\nIS_INTERNATIONAL _BRANCH_OF; the StartDate of the RelationshipPeriod with PeriodType\nRELATIONSHIP_PERIOD SHALL be the EntityCreationDate.\no Legal Entity D can acquire an LEl only in case it is not in the home jurisdiction of Legal Entity C.\nState Transition and Validation Rules for Common Data File formats Page 135 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1341,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.143Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"LEI C\nEntity:\no EntityLegalFormCode: N5NT\no Legallurisdiction: BE\nO Transfers assets & liabilities O\n—>\nLEIB LEIC\nFormer INTERNATIONAL_BRANCH_OF\nIS_INTERNATIONAL_BRANCH_OF\nchd\\‘edw\nLEIA LEI D (Create new LEI Record Set)\nEntity: Entity:\ne SuccessorEntity: LEI D o EntitiyCreationDate:\ne 2020-04-19T00:00:00+02:00\nRegistration: o EntityLegalFormCode: N5NT\no RegistrationStatus: RETIRED o Legallurisidiction: BE\no LastUpdateDate: 2020-04-20T13:43:25+02:00\nRelationship:\nRelationship: ° RelationshipType:\no Stop publishing ReportingExceptions IS_INTERNATIONAL_BRANCH_OF\no RelationshipPeriodType:\nRelationship Registration: RELATIONSHIP_PERIOD\no RegistrationStatus: RETIRED * RelationshipPeriodStartDate:\ne 2020-04-19T00:00:00+02:00\nLegalEntityEvent: o LastUpdateDate: 2020-04-20T13:43:25+02:00\no @group_type: STANDALONE\no @entity_status: COMPLETED LegalEntityEvent:\no LegalEntityEventType: ACQUISITION_BRANCH o @group_type: STANDALONE\no LegalEntityEventEffectiveDate: o @entity_status: COMPLETED\n¢ 2020-04-19T00:00:00+02:00 o LegalEntityEventType: ACQUISITION_BRANCH\no LegalEntityEventRecordedDate: o LegalEntityEventEffectiveDate:\ne 2020-04-20T00:00:00+02:00 e 2020-04-19T00:00:00+02:00\ne ValidationDocuments: REGULATORY_FILING o LegalEntityEventRecordedDate:\ne 2020-04-20T00:00:00+02:00c\nAffectedFields: + ValidationDocuments: REGULATORY_FILING\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:E\nntity/lei:SuccessorEntity/lei:SuccessorLEl:\nLEID\nExample 11: The Legal Entity with LEI A, which is an International Branch of B, is acquired by Legal Entity with an LEI C\nwith effective date April 19, 2020. The Legal Entity with LEI A ceases to exist and a new Legal Entity with LEI D is issued as\ninternational Branch of Legal Entity with LEI C. The LElI Record Sets of LEI A and LEI D have been updated on the same\ndate April 20, 2020.\nState Transition and Validation Rules for Common Data File formats Page 136 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2022,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.143Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.13.11 Legal Entity Event — Break-up\nLegal Entity A (general Legal Entity or Government Entity) completely separates into two or more\nindependent Legal Entities B and C (plus D, E, ...). Entity A will cease to exist as an independent Legal\nEntity.\nA common example how Break-up is processed and its outcome if entity A ceases to exists:\nThe LEl issuer managing the LEl Record Set of entity A SHALL:\ne Retire the LEI Record Set of Legal Entity A:\no Set RegistrationStatus RETIRED.\ne Set current relationships to RETIRED, if applicable.\ne SHALL include SuccessorEntity for every newly created entity after the separation.\no Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be BREAKUP.\no LegalEntityEventEffectiveDate SHALL be the date the Break-up becomes effective in the Legal\nJurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no If @event_statusis IN_PROGRESS or COMPLETED, the LEl issuer SHALL provide information\nregarding the AffectedFields: For @field_xpath the LEl issuer usually\ne SHALL provide lei:SuccessorEntity for all independent Legal Entities created\nThe LEl issuer(s) managing the records of entities B, C, ... SHALL:\no Create new LEI Records for the new Legal Entity(ies) (see Use Case 4.1).\no Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be COMPLETED.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\nG State Transition and Validation Rules for Common Data File formats Page 137 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1852,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.143Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o LegalEntityEventType SHALL be BREAKUP.\no LegalEntityEventEffectiveDate SHALL be the date the Break-up becomes effective in the Legal\nJurisdiction of the new Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no AffectedFields SHALL be omitted.\nState Transition and Validation Rules for Common Data File formats Page 138 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":495,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.146Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"LEIB LEIC LEID(E, F,..)\nv\nBreak-up\nLEI A\nLEI A LEIB, C, (D, E,F,..)\nEntity: o Create new LEI Record Sets\no SuccessorEntity: LEI B\no SuccessorEntity: LEI C LegalEntityEvent:\nRegistration: o @group_type: STANDALONE\no RegistrationStatus: RETIRED o @event_status: COMPLETED\no LegalEntityEventType: BREAKUP\nRelationship: + LegalEntityEventEffectiveDate:\n© Stop publishing ReportingExceptions © 2020-04-12T00:00:00+02:00\no LegalEntityEventRecordedDate:\nRelationship Registration + 2020-04-20T00:00:00+02:00\n© RegistrationStatus: RETIRED + ValidationDocuments:\n_ SUPPORTING_DOCUMENTS\nLegalEntityEvent: » ValidationReference:\n© @group_type: STANDALONE http://registry.gov/evidence.pdf\no @event_status: COMPLETED\no LegalEntityEventType: BREAKUP\no LegalEntityEventEffectiveDate:\no 2020-04-12T00:00:00+02:00\no LegalEntityEventRecordedDate:\no 2020-04-20T00:00:00+02:00\no ValidationDocuments:\nSUPPORTING_DOCUMENTS\no ValidationReference:\nhttp://registry.gov/evidence.pdf\nAffectedFields:\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Ent\nity/lei:SuccessorEntity/lei:SuccessorLEl: LEI B\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Ent\nity/lei:SuccessorEntity/lei:SuccessorLEl: LEI C\nExample 12: The Legal Entity with LEI A is separated into LEI B and LEI C with effective date April 12, 2020. The Legal\nEntity with LEI A ceases to exist. Theoretically, it is possible that LEI A is split into additional Legal Entities (LEID, E, F, ...).\nThe LEI Record Sets of LEI A and LEI D have been updated on the same date April 20, 2020.\nState Transition and Validation Rules for Common Data File formats Page 139 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1712,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.147Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.13.12 Legal Entity Event — Demerger\n\nA part or division of Legal Entity A (general Legal Entity or Government Entity) is separated into a new\n\nseparate entity, Subsidiary Legal Entity B. Part of Legal Entity A’s shares/assets and liabilities are\n\ntransferred to B.\n\nThe LEl issuer managing the LEI Record Set of Legal Entity A SHALL:\n\no Create a new LegalEntityEvent with:\n\no @group_type SHALL be STANDALONE.\n\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\n\no @group_id SHALL be omitted.\n\no @group_sequence_no SHALL be omitted.\n\no LegalEntityEventType SHALL be DEMERGER.\n\no LegalEntityEventEffectiveDate SHALL be the date the Demerger becomes effective in the\nLegal Jurisdiction of the Legal Entity.\n\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\n\no If @event_statusis IN_PROGRESS or COMPLETED, the LEl issuer SHALL provide information\nregarding the AffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide lei:SuccessorEntity\n\no Set LEI B as SuccessorEntity.\n\nThe LEl issuer managing the LEI Record Set of entity B SHALL:\n\n¢ Create a new LEI Record Set for the new Legal Entity B (see Use Case 4.1).\n\n* Create accounting consolidation relationship(s) with Legal Entity A, as applicable; StartDate of\nthe RelationshipPeriod with PeriodType RELATIONSHIP_PERIOD SHALL be the effective date that\nthe Legal Entity event became effective in the Legal Jurisdiction of the new Legal Entity (see\nbelow).\n\no Create a new LegalEntityEvent with:\n\no @group_type SHALL be STANDALONE.\n\no @event_status SHALL be COMPLETED.\n\no @group_id SHALL be omitted.\n\no @group_sequence_no SHALL be omitted.\n\no LegalEntityEventType SHALL be DEMERGER.\nState Transition and Validation Rules for Common Data File formats Page 140 of 170\n\n@ Public Version 2.7.1 Final\n\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1910,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.147Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"the Legal Entities linked by the relationship. Currently, relationship information for accounting\nconsolidation parents, for branches and for funds are defined within the Global LEI System.\nAccounting consolidating parent relationship\nAccounting consolidating parent relationship information is based on existing accounting definitions\nimplemented in the International Financial Reporting Standard (IFRS) or the United States Generally\nAccepted Accounting Principles (US GAAP), but other accounting standards are also accepted.\nThe direct accounting consolidating parent of Legal Entity X would be defined as the lowest level\nLegal Entity that prepares consolidated financial statements that consolidate entity X, based on the\naccounting definition of consolidation applying to this parent.\nThe ultimate accounting consolidating parent of entity X would be the highest level Legal Entity\npreparing consolidated financial statements that consolidate entity X, based on the accounting\ndefinition of consolidation applying to this parent. The ultimate accounting consolidating parent\nSHALL NOT have accounting consolidating parent relationships of its own.\nAccording to the definitions of direct and ultimate parents, a Legal Entity cannot declare a\nconsolidation relationship for one parent and a non-consolidating exception for the other. If the\ndirect accounting consolidation parent is controlled, but not consolidated, by another entity, it is also\nconsidered to be the ultimate parent within the Global LEI System (see Figure 1). Likewise, if the child\nLegal Entity is controlled, but not consolidated, by an entity that itself is controlled by an entity\nconsolidating the child Legal Entity, the consolidating entity would be both direct and ultimate parent\n(see Figure 2, example b).\nBy the same definition, only entities with two non-consolidating exceptions can be viable candidates\nfor being declared as an ultimate parent of another entity. GLEIF created a set of data quality checks\nto ensure compliance with this requirement, assigning errors to both the LEl issuer of the child Legal\nEntity record and of the ultimate parent record when inconsistent parent relationships are detected.\nIt is expected that LEl issuers, as part of the Validation and Verification of Level 2 data, check if the\nultimate parent identified by an LEI has consistent parent information. LEl issuer SHALL use LEI\nSearch 2.0, Level 2 XML files (relationship and exception files) and/or Golden Copy files to identify\ninformation regarding the ultimate parent's relationships (if any).\nState Transition and Validation Rules for Common Data File formats Page 15 of 170\n@ Public Version 2.7.1 Final\nG 2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2755,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.147Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o LegalEntityEventEffectiveDate SHALL be the date the Demerger becomes effective in the\nLegal Jurisdiction of the new Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no AffectedFields SHALL be omitted.\nO Demerger O\n—>\nLEI A LEIB\nLEIA LEI B (Create new LEI Record Set)\nEntity: Entity:\no SuccessorEntity: LEI B o EntityCreationDate:\no 2020-04-12T00:00:00+02:00\nLegalEntityEvent:\no @group_type: STANDALONE Relationship:\no @event_status: COMPLETED o Create accounting consolidation\n+ LegalEntityEventType: DEMERGER relationship(s)\no LegalEntityEventEffectiveDate: o RelationshipPeriodStartDate:\no 2020-04-12T00:00:00+02:00 o 2020-04-12T00:00:00+02:00\n+ LegalEntityEventRecordedDate: © RelationshipPeriodType:\n+ 2020-04-20T00:00:00+02:00 RELATIONSHIP_PERIOD\n° ValidationDocuments: L LaStUpdateDate: 2020-04-20T13:43:25+02:00\nSUPPORTING_DOCUMENTS\n« ValidationReference: LegalEntityEvent:\nhttp://registry.gov/evidence.pdf © @group_type: STANDALONE\no @event_status: COMPLETED\nAffectedFields: o LegalEntityEventType: DEMERGER\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/I ¢ LegalEntityEventEffectiveDate:\nei:Entity/lei:SuccessorEntity/lei:Successor e 2020-04-12T00:00:00+02:00\nLEI: LEI B o LegalEntityEventRecordedDate:\no 2020-04-20T00:00:00+02:00\no ValidationDocuments:\nSUPPORTING_DOCUMENTS\no ValidationReference:\nhttp://registry.gov/evidence.pdf\nExample 13: The Legal Entity with LEI A is separated into LEI B with effective date April 12, 2020. The Legal Entity with LEI\nA continues to exist. The LEI Record Sets of LEI A and LEI D have been updated on the same date April 20, 2020.\nState Transition and Validation Rules for Common Data File formats Page 141 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1838,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.147Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.13.13 Legal Entity Event — Spin-off\nA part, division or Subsidiary of Legal Entity A (general Legal Entity) is separated into Legal Entity B,\nwhich could be a new or existing Legal Entity. In case of an existing Legal Entity B, Legal Entity B will\nno longer remain as a Subsidiary of Legal Entity A after completion of the Spin-off. Part of Legal Entity\nA’s shares/assets and liabilities are transferred to Legal Entity B; shareholders of Legal Entity A are\ncompensated for the asset value or loss by either receiving shares from Legal Entity B or via dividend.\nThe LEl issuer managing the LEI Record Set of Legal Entity A SHALL:\no Provide a SuccessorEntity.\no Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be SPINOFF.\no LegalEntityEventEffectiveDate SHALL be the date the Spin-off becomes effective in the Legal\nJurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no If @event_status is IN_PROGRESS or COMPLETED, the LEl issuer SHALL provide information\nregarding the AffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide lei:SuccessorEntity\nThe LEl issuer managing the LEI Record Set of Legal Entity B SHALL:\no Create a new LEI Record for the new Legal Entity B (see Use Case 4.1), if applicable.\no Retire any excisting relationships between Legal Entity B and Legal Entity A, if Legal Entity B\nalready exists,\no Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be COMPLETED, in case a new Legal Entity is created.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED, in case\nLegal Entity B already existed before the Spin-off.\no @group_id SHALL be omitted.\nState Transition and Validation Rules for Common Data File formats Page 142 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2110,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.147Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be SPINOFF.\no LegalEntityEventEffectiveDate SHALL be the date the Spin-off becomes effective in the\nLegalljurisdiction of the new Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no AffectedFields SHALL be omitted.\nO Spin-off O\n—>\nLEI A LEIB\nLEIA LEI B (existing entity, prev. subsidiary)\nEntity: Relationship:\no SuccessorEntity: LEI B o RelationshipStatus: RETIRED\no RelationshipPeriodEndDate:\nLegalEntityEvent: e 2020-04-18T00:00:00+02:00\n© @group_type: STANDALONE o RelationshipPeriodType:\no @event_status: COMPLETED RELATIONSHIP_PERIOD\n© LegalEntityEventType: SPINOFF o LastUpdateDate: 2020-04-20T13:43:25+02:00\no LegalEntityEventEffectiveDate:\no 2020-04-18T00:00:00+02:00 LegalEntityEvent:\no LegalEntityEventRecordedDate: o @group_type: STANDALONE\no 2020-04-20T00:00:00+02:00 o @event_status: COMPLETED\no ValidationDocuments: o LegalEntityEventType: SPINOFF\nSUPPORTING_DOCUMENTS o LegalEntityEventEffectiveDate:\no ValidationReference: e 2020-04-18T00:00:00+02:00\nhttp://registry.gov/evidence.pdf o LegalEntityEventRecordedDate:\no 2020-04-20T00:00:00+02:00\nAffectedFields: o ValidationDocuments:\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/| SUPPORTING_DOCUMENTS\nei:Entity/lei:SuccessorEntity/lei:Successor o ValidationReference:\nLEI: LEIB http://registry.gov/evidence.pdf\nExample 14: The Legal Entity with LEI A is separated into LEI B with effective date April 18, 2020. The Legal Entity with LEI\nA continues to exist. The former relationship record between LEI B and LEI A is set to RegistrationStatus RETIRED. The LEI\nRecord Sets of LEI A and LEI B have been updated on the same date April 20, 2020.\nState Transition and Validation Rules for Common Data File formats Page 143 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1934,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.147Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"O Spin-off O\n—>\nLEIA LEIB\nLEI A\nEntity: LEl B (new entity, prev. division of A)\ne SuccessorEntity: LEI B\nEntity:\nLegalEntityEvent: o EntityCreationDate:\n« @group_type: STANDALONE + 2020-04-18T00:00:00+02:00\no @event_status: COMPLETED\no LegalEntityEventType: SPINOFF LegalEntityEvent:\no LegalEntityEventEffectiveDate: © @group_type: STANDALONE\no 2020-04-18T00:00:00+02:00 ¢ @event_status: COMPLETED\no LegalEntityEventRecordedDate: o LegalEntityEventType: SPINOFF\ne 2020-04-20T00:00:00+02:00 o LegalEntityEventEffectiveDate:\no ValidationDocuments: e 2020-04-18T00:00:00+02:00\nSUPPORTING_DOCUMENTS o LegalEntityEventRecordedDate:\ne ValidationReference: e 2020-04-20T00:00:00+02:00\nhttp://registry.gov/evidence.pdf o ValidationDocuments:\nSUPPORTING_DOCUMENTS\nAffectedFields: o ValidationReference:\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/I http://registry.gov/evidence.pdf\nei:Entity/lei:SuccessorEntity/lei:Successor\nLEI: LEI B\nExample 15: The Legal Entity with LEI A is separated into LEI B with effective date April 18, 2020. The Legal Entity with LEI\nA continues to exist. The entity for LEI Record Set B has been created as a result of the Spin Off on April 20, 2020.\n4.13.14 Legal Entity Event — Transformation of an International Branch to a\nSubsidiary\nInternational Branch A of (head office) Legal Entity B, is separated from Legal Entity B and becomes a\nnew Legal Entity C, a Subsidiary of Legal Entity B; part of Legal Entity B’s shares/assets and liabilities\nare transferred to new Legal Entity C.\nThe LEl issuer managing the LEI Record of Legal Entity A SHALL:\ne Retire the LEI Record Set of Legal Entity A:\n\no Set RegistrationStatus to RETIRED.\n\no Set RegistrationStatus of all current Relationship Records to RETIRED with RelationshipStatus\nINACTIVE; set EndDate of RelationshipPeriod with PeriodType RELATIONSHIP_PERIOD as\nEffective Date of the LegalEntityEvent (see below).\n\no Set Legal Entity C as SuccessorEntity.\n\no Create a new LegalEntityEvent with:\nState Transition and Validation Rules for Common Data File formats Page 144 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2162,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.147Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o @group_type SHALL be STANDALONE.\n\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\n\no @group_id SHALL be omitted.\n\no @group_sequence_no SHALL be omitted.\n\n+ LegalEntityEventType SHALL be TRANSFORMATION_BRANCH_TO_SUBSIDIARY.\n\no LegalEntityEventEffectiveDate SHALL be the date the transformation becomes effective in\nthe Legal Jurisdiction of the Legal Entity.\n\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\n\no If @event_status is IN_PROGRESS, or COMPLETED, the LEl issuer SHALL provide information\nregarding the AffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide lei:SuccessorEntity\n\ne The LEl issuer managing the LEI Record of the new Legal Entity C SHALL:\n\no Create new LEI Records for the new Legal Entity(ies) (see section 4.1)\n\no Create a new accounting consolidation relationship(s) with Legal Entity B, as applicable;\nStartDate of the RelationshipPeriod with PeriodType RELATIONSHIP_PERIOD SHALL be the\nLegalEntityEventEffectiveDate that the Legal Entity event became effective in the Legal\nJurisdiction of the new Legal Entity (see below).\n\no Create a new LegalEntityEvent with:\n\no @group_type SHALL be STANDALONE.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no @event_Status SHALL be COMPLETED\n+ LegalEntityEventType SHALL be TRANSFORMATION_BRANCH_TO_SUBSIDIARY.\no LegalEntityEventEffectiveDate SHALL be the date the transformation becomes effective in\nthe Legal Jurisdiction of the new Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no AffectedFields SHALL be omitted.\nState Transition and Validation Rules for Common Data File formats Page 145 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1862,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.147Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"0\nFormer NTERNAW s\\mw&mwcomm DATED_BY\nSucceeded by\n—>\nS %\no LEIA LEI C (Create new LEI Record Set)\nEntity: Entity:\no SuccessorEntity: LEI C o EntityCreationDate:\ne 2020-04-17T00:00:00+02:00\nRegistration:\no RegistrationStatus: RETIRED Relationship:\no LastUpdateDate: 2020-04-20T13:43:25+02:00 o Create accounting consolidation\nrelationship(s)\nRelationship: o RelationshipPeriodStartDate:\no RelationshipPeriodEndDate: e 2020-04-17T00:00:00+02:00\ne 2020-04-17T00:00:00+02:00 o RelationshipPeriodType:\no RelationshipPeriodType: RELATIONSHIP_PERIOD\nRELATIONSHIP_PERIOD o LastUpdateDate: 2020-04-20T13:43:25+02:00\nRelationship Registration: LegalEntityEvent:\no RegistrationStatus: RETIRED o @group_type: STANDALONE\no @event_status: COMPLETED\nLegalEntityEvent: + LegalEntityEventType:\n° (@group_type: STANDALONE TRANSFORMATION_BRANCH_TO_SUBSIDIARY\n¢ @event_status: COMPLETED o LegalEntityEventEffectiveDate:\n¢ LegalEntityEventType: e 2020-04-17T00:00:00+02:00\nTRANSFORMATION_BRANCH_TO_SUBSIDIARY + LegalEntityEventRecordedDate:\no LegalEntityEventEffectiveDate: o 2020-04-20T00:00:00+02:00\n° 2020-04-17T00:00:00+02:00 o ValidationDocuments:\no LegalEntityEventRecordedDate: SUPPORTING_DOCUMENTS\no 2020-04-20T00:00:00+02:00 o ValidationReference:\n¢ ValidationDocuments: http://registry.gov/evidence.pdf\nSUPPORTING_DOCUMENTS\no ValidationReference:\nhttp://registry.gov/evidence.pdf\nAffectedFields:\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:E\nntity/lei:SuccessorEntity/lei:SuccessorLEl: LEI\nC\nExample 16: The Legal Entity with LEI A, which is an International Branch of LEI B, is transformed into a Subsidiary of LEI B\nwith effective date April 17, 2020. The Legal Entity with LEI B is now the direct and/or ultimate parent of LEI C. The Legal\nentity with LEI A ceases to exist and a new Legal Entity with LEI C is created as successor of LEI A. The LEI Record Sets of\nLEI A and LEI C have been updated on the same date April 20, 2020.\nState Transition and Validation Rules for Common Data File formats Page 146 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2120,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.147Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.13.15 Legal Entity Event — Bankruptcy\nLegal Entity A (general Legal Entity or Government Entity) declares Bankruptcy based on the laws of\nits jurisdiction. During the process, the Legal Entity could no longer be operational, and could still\nexist as Legal Entity. Once the process is completed, all or part of the Legal Entity could survive, and\nthe LEI remains ISSUED or the Legal Entity could become inactive and the LEIl is RETIRED. Bankruptcy\nevents are often followed by Liquidation, Insolvency or Dissolution events which will determine the\nfinal status of the Legal Entity and its LEI.\nWhile the Bankruptcy is in progress, the LEl issuer managing the LEI Record Set of Legal Entity A\nSHALL:\no Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status MAY be IN_PROGRESS.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be BANKRUPTCY.\no LegalEntityEventEffectiveDate SHALL be the date the Bankruptcy becomes effective in the\nLegal Jurisdiction of Legal Entity A.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no If @event_status is IN_PROGRESS or COMPLETED, the LEl issuer SHALL provide information\nregarding the AffectedFields: For @field_xpath the LEl issuer usually\no MAY provide lei:SuccessorEntity\no Keep the LEI Record Set of Legal Entity A as it is, but check if a change in legal name and/or in\nlegal form applies; create the respective Legal Entity Events, including all other LEI Record Set\nupdates, if necessary. Depending on the laws and regulations in the Legal Entity’s jurisdiction, the\nchange in legal form and/or legal name MAY already be effective, in which case the\n@event_status of these events SHALL be COMPLETED rather than IN_PROGRESS.\nOnce the Bankruptcy event is completed the LEl issuer managing the LEI Record Set of entity A\nSHALL:\no Create a new LegalEntityEvent with:\no @event_status SHALL be COMPLETED.\no LegalEntityEventEffectiveDate SHALL be the date the Bankruptcy becomes effective in the\nLegal Jurisdiction of Legal Entity A.\nState Transition and Validation Rules for Common Data File formats Page 147 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2291,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.147Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no AffectedFields SHALL be omitted.\nState Transition and Validation Rules for Common Data File formats Page 148 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":322,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.147Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Bankruptcy\n- O O o Oy >\nS S\nIn-progress Event Post Event\nLEI A LEI A\nLegalEntityEvent: Registration:\no @group_type: STANDALONE o RegistrationStatus: RETIRED\no @event_status: IN_PROGRESS\no LegalEntityEventType: BANKRUPTCY Relationship:\no LegalEntityEventEffectiveDate: o Create accounting consolidation relationship(s)\no 2020-09-08T00:00:00+02:00 o RelationshipPeriodEndDate:\no LegalEntityEventRecordedDate: e 2020-04-19T00:00:00+02:00\ne 2020-02-09T00:00:00+02:00 o RelationshipPeriodType: RELATIONSHIP_PERIOD\no ValidationDocuments: o LastUpdateDate:\nSUPPORTING_DOCUMENTS e 2020-04-20713:43:25+02:00\ne ValidationReference:\nhttp://registry.gov/evidence.pdf LegalEntityEvent:\no @group_type: STANDALONE\no @event_status: IN_PROGRESS\no LegalEntityEventType: BANKRUPTCY\nExample 17: The Legal Entity LEI A goes ¢ LegalEntityEventEffectiveDate:\nbankrupt. The process of Bankruptcy was e 2020-09-08T00:00:00+02:00\nscheduled to end on September 8, 2020 and o LegalEntityEventRecordedDate:\nwas recorded in the Global LEI System on s 2020-02-09T00:00:00+02:00\nFebruary 9, 2020. In this example, no « ValidationDocuments: SUPPORTING_DOCUMENTS\nrelevant information describing the Legal s -\nEntity is changed and therefore no ‘ Valldatlon'Reference: .\nAffectedFields are included. The Bankruptcy http://registry.gov/evidence.pdf\nwas completed on October 19, 2020 behind\nschedule. The completion of the Legal Entity LegalEntityEvent:\nEvent was recorded in the Global LEI System o @group_type: STANDALONE\non November 20, 2020. As a consequence of s @event_status: COMPLETED\nthe bankruptcy, the Legal Entity has ceased o LegalEntityEventType: BANKRUPTCY\nto exist due toa dissomtio.n even.t on o LegalEntityEventEffectiveDate:\nDecember 19, 2020. The dissolution was\nrecorded in the Global LEI System on ¢ 2020-10-19T00:00:00+02:00\nDecember 20, 2020. o LegalEntityEventRecordedDate:\ne 2020-11-20T00:00:00+02:00\nLegalEntityEvent:\no @group_type: STANDALONE\no @event_status: COMPLETED\no LegalEntityEventType: DISSOLUTION\no LegalEntityEventEffectiveDate:\ne 2020-12-19T00:00:00+02:00\no LegalEntityEventRecordedDate:\ne 2020-12-20T00:00:00+02:00\ne ValidationDocuments: SUPPORTING_DOCUMENTS\ne ValidationReference:\nhttp://registry.gov/evidence.pdf\nState Transition and Validation Rules for Common Data File formats Page 149 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2413,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.147Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.13.16 Legal Entity Event — Insolvency\n\nLegal Entity A (general Legal Entity or Government Entity) declares itself insolvent based on the laws\nof its jurisdiction. This Legal Entity Event is handled like a Bankruptcy, except for the different\nLegalEntityEventType recorded.\n\nIn contrast to Bankruptcy, the LEl issuer managing the LegalEntityEvent of Legal Entity A SHALL:\n\no Use INSOLVENCY as LegalEntityEventType.\n\n4.13.17 Legal Entity Event — Liquidation\n\nLegal Entity A (general Legal Entity or Government Entity) closes all business activities due to\nLiguidation. This Legal Entity Event always leads to the retirement of the LEl and the Legal Entity\nbecoming INACTIVE when the Legal Entity Event reached @event_status COMPLETED. Liquidation\ncan be the result of a Bankruptcy or of an Insolvency.\n\nThe LEl issuer managing the LEI Record Set of Legal Entity A SHALL:\n\no Retire the LEI Record Set of Legal Entity A, if @event_status is COMPLETED:\n\no Set RegistrationStatus to RETIRED.\n\no Set EntityStatus to INACTIVE.\n\no Set RegistrationStatus of all current Relationship Records to RETIRED with RelationshipStatus\nINACTIVE; set EndDate of RelationshipPeriod with PeriodType RELATIONSHIP_PERIOD as\nEffective Date of the LegalEntityEvent (see below).\n\no Create a new LegalEntityEvent with:\n\no @group_type SHALL be STANDALONE.\n\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\n\no @group_id SHALL be omitted.\n\no @group_sequence_no SHALL be omitted.\n\no LegalEntityEventType SHALL be LIQUIDATION.\n\no LegalEntityEventEffectiveDate SHALL be the date the LIQUIDATION becomes effective in the\nLegal Jurisdiction of Legal Entity A.\n\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\n\no If @event_statusis IN_PROGRESS or COMPLETED, the LEl issuer SHALL provide information\nregarding the AffectedFields: For @field_xpath the LEl issuer usually\no MAY provide lei:SuccessorEntity\n\nState Transition and Validation Rules for Common Data File formats Page 150 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2131,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.147Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Non-consolidating Non-consolidating\nException Exception\n%}T PARENT\\/ULTIMATE/PA\\RENT\n@\\?\nDIRECT PARENT\n@ EJ‘LTIMI/\\TE PARE;\\]T\n\\I: \\\"\\ ULTIMATE PARENT\nA ! ULTIMATE PARENT\nULTIMATE PARENT /\nDIRECT PARENT\nFigure 1: General view on one complete network chain and the representation of the Relationship Records to the\nultimate parent LEI.\nChild reporting (bottom-up) principle\nInitially only child entities may report level 2 data (the relationship information to their parent\nentities) to minimize difficulties arising from complex Business Rules dependent on the reporting\nentity and de-duplication. This also covers a parent entity instructing its child entity or entities to\nreport parent information, and also delegated reporting by a parent entity on behalf of any child\nentities.\nGiven this rule, reporting of child entities without an LEl is NOT possible under any circumstance.\nState Transition and Validation Rules for Common Data File formats Page 16 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1067,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.147Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.13.18 Legal Entity Event — Dissolution\nLegal Entity A (general Legal Entity of Government Entity) voluntarily closes all business activities.\nThis Legal Entity Event always leads to the retirement of the LElI and the Legal Entity becoming\nINACTIVE when the Legal Entity Event reached @event_status COMPLETED. This Legal Entity Event is\nhandled like Liquidation, except for the different Legal EntityEventType and the different expected\n@field_xpath.\nIn contrast to Liquidation, the LEl issuer managing the LEI Record Set of Legal Entity A SHALL create a\nnew LegalEntityEvent with:\no LegalEntityEventType SHALL be DISSOLUTION.\no If @event_status is IN_PROGRESS or COMPLETED, the LEl issuer SHALL provide information\nregarding the AffectedFields: For @field_xpath the LEl issuer usually\no MAY provide lei:SuccessorEntity\n4.13.19 Legal Entity Event — Voluntary Arrangement\nA company Voluntary Arrangement (CVA) allows a Legal Entity A (general Legal Entity or Government\nEntity) to negotiate with its creditors the settlement of any debts by paying only a portion of the\namounts owed or by some other arrangement to pay the debt. This Legal Entity Event does not lead\nto retirement of the LEL.\nThe LEl issuer managing the LEI Record Set of Legal Entity A SHALL:\no Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be VOLUNTARY_ARRANGEMENT\no @event_status SHALL be IN_PROGRESS.\no LegalEntityEventEffectiveDate SHALL be the date the CVA becomes effective in the Legal\nJurisdiction of Legal Entity A.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no AffectedFields SHALL be omitted.\nOnce the CVA is completed, the LEl issuer managing the LEI Record Set of entity A SHALL:\nState Transition and Validation Rules for Common Data File formats Page 151 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2068,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.147Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be COMPLETED\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be VOLUNTARY_ARRANGEMENT.\no LegalEntityEventEffectiveDate SHALL be the date the CVA becomes effective in the Legal\nJurisdiction of Legal Entity A.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no AffectedFields SHALL be omitted.\nState Transition and Validation Rules for Common Data File formats Page 152 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":675,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.147Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"O Voluntary Arrangement O\n_————’\nLEI A LEI A\nPre Event Post Event\nLEI A LEI A\nLegalEntityEvent: LegalEntityEvent:\no @group_type: STANDALONE o @group_type: STANDALONE\no @event_status: IN_PROGRESS o @event_status: IN_PROGRESS\no LegalEntityEventType: o LegalEntityEventType:\nVOLUNTARY_ARRANGEMENT_IN_PROGRESS VOLUNTARY_ARRANGEMENT_IN_PROGRESS\no LegalEntityEventEffectiveDate: [ ] o LegalEntityEventEffectiveDate: [ ]\no LegalEntityEventRecordedDate: o LegalEntityEventRecordedDate:\ne 2020-03-05T09:00:00+02:00 e 2020-03-05T09:00:00+02:00\no ValidationDocuments: CONTRACTS o ValidationDocuments: CONTRACTS\nLegalEntityEvent:\no @group_type: STANDALONE\no @event_status: COMPLETED\no LegalEntityEventType:\nVOLUNTARY_ARRANGEMENT\no LegalEntityEventEffectiveDate:\no 2020-04-19T00:00:00+02:00\no LegalEntityEventRecordedDate:\no 2020-04-20T09:00:00+02:00\no ValidationDocuments: CONTRACTS\nExample 18: Legal Entity LEI A engages in a company Voluntary Arrangement without any knowledge regarding the\nexpected effective date. The process of the Voluntary Arrangement was recorded in the Global LEI System on March 5,\n2020. The Voluntary Arrangement was completed on April 19, 2020. The completion of the Legal Entity Event was\nrecorded in the Global LEI System on April 20, 2020.\nState Transition and Validation Rules for Common Data File formats Page 153 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1452,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.147Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.13.20 Legal Entity Event — Reverse Takeover\nA Reverse Takeover describes the following scenario:\n1. Entity Bis acquired by entity A\n2. Entity Ais absorbed by B\n3. Entity B changes its LegalName to A\nThe result has a surviving entity with the original LegalName of entity A and the LEI of entity B. The\nLEI Record of entity A will be RETIRED and point to the LEI of entity B as SuccessorEntity.\nTo record this Legal Entity Event, the LEl issuer of entity A SHALL update the LEI Record as following:\no Set RegistrationStatus RETIRED.\no Set Legal Entity B as SuccessorEntity.\ne Set current relationships to RETIRED, if applicable.\no Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED, based on\nthe status of the event (see section 4.13.1).\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be MERGERS_AND_ACQUISITIONS.\n¢ LegalEntityEventEffectiveDate SHALL be the date the Reverse Takeover becomes effective in\nthe Legal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\n¢ ValidationDocument and the optional ValidationReference SHALL indicate the sources used\nfor validating the Legal Entity Event.\no If @event_statusis IN_PROGRESS or COMPLETED, the LEl issuer SHALL provide information\nregarding the AffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide lei:SuccessorEntity\nThe LEl issuer of entity B SHALL record the Reverse Takeover event as a group of three events, linked\ntogether and set in the correct sequence order:\n¢ Create a new LegalEntityEvent with:\no @group_type SHALL be REVERSE_TAKEOVER.\nState Transition and Validation Rules for Common Data File formats Page 154 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1935,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.148Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be a unique identifier (e.g., a hash value calculated from the combination\nof the LEl, EventType and EffectiveDate).\no @group_sequence_no SHALL be 1 (one).\no LegalEntityEventType SHALL be MERGERS_AND_ACQUISITIONS.\n¢ LegalEntityEventEffectiveDate SHALL be the date the Reverse Takeover becomes effective in\nthe Legal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\n¢ ValidationDocument and the optional ValidationReference SHALL indicate the sources used\nfor validating the Legal Entity Event.\no AffectedFields SHALL be omitted.\ne Create a new LegalEntityEvent with:\no @group_type SHALL be REVERSE_TAKEOVER.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be the same unique identifier used for the previous event.\no @group_sequence_no SHALL be 2 (two).\no LegalEntityEventType SHALL be ABSORPTION.\no LegalEntityEventEffectiveDate SHALL be the same date as for the previous event.\no LegalEntityEventRecordedDate SHALL be the same date as for the previous event.\n¢ ValidationDocument and the optional ValidationReference SHALL indicate the sources used\nfor validating the Legal Entity Event.\no AffectedFields SHALL be omitted.\no Create a new LegalEntityEvent with:\no @group_type SHALL be REVERSE_TAKEOVER.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be the same unique identifier used for the previous event.\no @group_sequence_no SHALL be 3 (three).\no LegalEntityEventType SHALL be CHANGE_LEGAL_NAME.\nG State Transition and Validation Rules for Common Data File formats Page 155 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1855,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.148Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o LegalEntityEventEffectiveDate SHALL be the same date as for the previous event.\no LegalEntityEventRecordedDate SHALL be the same date as for the previous event.\n¢ ValidationDocument and the optional ValidationReference SHALL indicate the sources used\nfor validating the Legal Entity Event.\no If @event_statusis IN_PROGRESS, the LEl issuer SHALL provide information regarding the\nAffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide lei:LegalName\no MAY provide lei:OtherEntityNames\no MAY provide lei:TransliteratedOtherEntityNames\n¢ The LegalName of LEI B SHALL change to LegalName of LEI A.\nState Transition and Validation Rules for Common Data File formats Page 156 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":796,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.148Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"1 Acquired by\nA/Z/-\\bs;edby\\\n_—mmm\nS S\nLEI A LEI B\nEntity: Entity:\no “SuccessorEntity: LEI B” o LegalName: “Company B.V.“\no LegalName: Company B.V.\nLegalEntityEvent:\nRegistration: o @group_type: REVERSE_TAKEOVER\no RegistrationStatus: RETIRED o @event_status: COMPLETED\no @group_id: dfecd444f23463443a98n12a\nRelationship: o @group_sequence_no: 1\n* Remove ReportingExceptions o LegalEntityEventType:\no lastUpdateDate: 2020-04-20T13:43:25+02:00 MERGERS_AND_ACQUISITIONS\no LegalEntityEventEffectiveDate:\nRelationship Registration: © 2020-04-19T00:00:00+02:00\n* RegistrationStatus: RETIRED o LegalEntityEventRecordedDate:\no 2020-04-20T00:00:00+02:00\nLegalEntityEvent: « ValidationDocuments: ACCOUNTS_FILING\no @group_type: STANDALONE\no @event_status: COMPLETED LegalEntityEvent:\n© LegalEntityEventType: o @group_type: REVERSE_TAKEOVER\nMERGERS_AND_ACQUISITIONS s @event_status: COMPLETED\n© LegalEntityEventEffectiveDate: + @group_id: dfecd444f23463443a98n12a\n© 2020-04-19T00:00:00+02:00 « @group_sequence_no: 2\n© LegalEntityEventRecordedDate: + LegalEntityEventType: ABSORPTION\n¢ 2020-04-20T11:30:00+02:00 » LegalEntityEventEffectiveDate:\no ValidationDocuments: ACCOUNTS_FILING s 2020-04-19T00:00:00+02:00\no ValidationReference: Consolidated financial + LegalEntityEventRecordedDate:\nstatement o 2020-04-20T11:30:00+02:00\no ValidationDocuments: ACCOUNTS_FILING\nAffectedFields:\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:E LegalEntityEvent:\nntity/lei:SuccessorEntity/lei:SuccessorLEl: « @group_type: REVERSE_TAKEOVER\nLEI B + @event_status: COMPLETED\no @group_id: dfecd444f23463443a98n12a\no (@group_sequence_no: 3\no LegalEntityEventType: CHANGE_LEGAL_NAME\no LegalEntityEventEffectiveDate:\no 2020-04-19T00:00:00+02:00\no LegalEntityEventRecordedDate:\ne 2020-04-20T11:30:00+02:00\no ValidationDocuments: ACCOUNTS_FILING\nExample 19: Reverse Takeover\nState Transition and Validation Rules for Common Data File formats Page 157 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2050,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.148Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.13.21 Legal Entity Event — Transformation of an Umbrella Fund to a Stand-Alone\nFund\nWhen an umbrella fund A is converted into a stand-alone fund, all sub-funds/compartments of\numbrella fund A (fund entities with a IS_SUBFUND_OF relationship with umbrella fund A) are either\nmerged into umbrella fund A or need to be separated from umbrella fund A with a different Legal\nEntity Event recorded for the sub-fund(s). This Use Case assumes, that all (remaining) sub-funds are\nmerged into the umbrella fund prior to the conversion.\nThe LEl issuer managing the LEI Record Sets of any sub-fund of umbrella fund A SHALL:\ne Set the sub-fund relationship to RETIRED.\no Set the RegistrationStatus of each sub-fund to RETIRED.\no Set the umbrella fund as SuccessorEntity.\nThe LEl issuer managing the LEl Record Sets of umbrella fund entity A SHALL:\no Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED, based on\nthe status of the event (see section 4.13.1).\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be TRANSFORMATION_UMBRELLA_TO_STANDALONE.\no LegalEntityEventEffectiveDate SHALL be the date the transformation becomes effective in\nthe Legal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no If @event_statusis IN_PROGRESS or COMPLETED, the LEl issuer SHALL provide information\nregarding the AffectedFields: For @field_xpath the LEl issuer usually\no MAY provide lei:SuccessorEntity\n4.13.22 Legal Entity Event — Effects on parent and child relationships\nA Legal Entity Event applied to a Legal Entity can also affect all relationships where the entity is the\nEndNode (parent). Several cases have already been described above. In addition, there is need to\nlook at cases if the parent Legal Entity is RETIRED and hence no longer active or if a Legal Entity that\nwas an ultimate parent has been acquired and now has parent relationships.\nState Transition and Validation Rules for Common Data File formats Page 158 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2246,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.148Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"As soon as the LEl issuer of any child Legal Entity is aware of the retirement of the parent, the LEI\n\nissuer SHALL:\n\no Update all affected relationships to RETIRED.\n\no Create new Relationship Records or reporting exceptions, as applicable.\n\ne The LEl issuer of the child entity works with the child Legal Entity to record the new direct or\nultimate parent Legal Entity relationship.\n\nThe LEl issuer of the child Legal Entity can be informed about the change in the parent’s\n\nRegistrationStatus either\n\no by the child Legal Entity at the time of renewal,\n\n* viathe challenge process\n\ne orduring the course of normal business operations\n\nGiven the LEl issuer of the parent Legal Entity becomes aware of this change to the parent Legal\n\nEntity via the challenge process or during the course of normal business, the LEl issuer should notify\n\nthe LEl issuer of the child Legal Entity and request the LEl issuer of the child Legal Entity to provide\n\nupdated information on the direct or ultimate parent Legal Entity.\n\no If the child Legal Entity has active Relationship Records with rr:RegistrationStatus PUBLISHED or\n\nLAPSED reported, these are updated as follows:\n\no RelationshipStatus SHALL be INACTIVE.\n\no rr:RegistrationStatus SHALL be RETIRED.\n\no RelationshipPeriods with PeriodType RELATIONSHIP_PERIOD SHALL have EndDate populated\nwith the date the parent Legal Entity ceased to exist (same as the\nLegalEntityEventEffectiveDate that retired the parent Legal Entity).\n\no Relationship Records that are already RETIRED, DUPLICATE or ANNULLED are not updated.\n\no The LEl issuer of the child Legal Entity creates a new set of relationship data for the direct and/or\n\nultimate parent Legal Entity based on the updated information.\n\nFor an International Branch relationship, if the (head office) Legal Entity it belongs to merges or\n\nretires and is no longer active, the LEI Record Set of a Branch needs to be updated as well. Either the\n\n(head office) Legal Entity or the International Branch notifies their LEIl issuer at the time of renewal,\n\nthe LEl issuer is made aware via the challenge process, or the LEl issuer becomes aware of the (head\nState Transition and Validation Rules for Common Data File formats Page 159 of 170\n\n@ Public Version 2.7.1 Final\n\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2328,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.148Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"office) Legal Entity retiring during the course of normal business. The LEl issuer of the International\nBranch SHALL change the Branch entity’s LElI Record Set to the RegistrationStatus of RETIRED to have\nthe same status as the (head office) Legal Entity (see above Use Cases 4.8.1 or 4.8.2 respectively).\n4.13.23 Legal Entity Event — Erroneously introduced Legal Entity Event\nIf a Legal Entity Event has been falsely introduced to the LEI Repository, the LEl issuer SHALL:\ne Continue uploading the erroneously introduced Legal Entity Event\no Create an additional Legal Entity Event with:\no @event_status WITHDRAWN_CANCELLED\no LegalEntityEventRecordedDate representing the date the event was cancelled\no All remaining reference data shall be identical to the erroneously introduced legal entity\nevent\nState Transition and Validation Rules for Common Data File formats Page 160 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":986,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.148Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"With the exception of branches, all Legal Entities SHALL report relationship data for both direct and\nultimate accounting consolidating parent. Each relationship SHALL be reported by either a\nRelationship Record or a Reporting Exception Record. See Figure 1 for possible combinations.\nOnly one parent Legal Entity per child may be reported per unique relationship type with published\nregistration status. Direct and ultimate parent can be the same Legal Entity, still the child reports one\nrelationship of each type. The parent entity can be represented by:\ne an LEl for those parent Legal Entities with an LEI;\no an exception with exception reason NO_LEl in case the parent Legal Entity does not have an LEI.\nDIRECT PARENT\\/ULHMATE PARENT DIRECT Pw PARENT\na) b)\nDIRECT PARENTVULTIMATE PARENT DIRECT PARENT\\/ ULTIMATE PARENT\nc) .H d) ‘a\nState Transition and Validation Rules for Common Data File formats Page 17 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1020,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.148Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"O Remediation of an incorrectly reported event O\nIntroduction of incorrect event Resolved incorrect event\nLEI A LEI A\nRegistration: Registration:\no RegistrationStatus: RETIRED o RegistrationStatus: ISSUED\no LastUpdateDate: 2020-01-23T08:41:00+02:00 o LastUpdateDate: 2020-01-25T10:42:00+02:00\nLegalEntityEvent: LegalEntityEvent:\no @group_type: STANDALONE o @group_type: STANDALONE\no @event_status: COMPLETED o @event_status: COMPLETED\no LegalEntityEventType: DISSOLUTION o LegalEntityEventType: DISSOLUTION\no LegalEntityEventEffectiveDate: o LegalEntityEventEffectiveDate:\ne 2020-01-20T00:00:00.000Z e 2020-01-20T00:00:00.000Z\no LegalEntityEventRecordedDate: o LegalEntityEventRecordedDate:\no 2020-01-23T08:41:00+02:00 o 2020-01-23T08:41:00+02:00\no ValidationDocuments: o ValidationDocuments:\nSUPPORTING_DOCUMENTS SUPPORTING_DOCUMENTS\no ValidationReference: o ValidationReference:\nhttp://registry.gov/evidence.pdf http://registry.gov/evidence.pdf\nLegalEntityEvent:\no @group_type: STANDALONE\no @event_status: WITHDRAWN_CANCELLED\no LegalEntityEventType: DISSOLUTION\no LegalEntityEventEffectiveDate:\ne 2020-01-20T00:00:00.000Z\no LegalEntityEventRecordedDate:\ne 2020-01-25T10:42:00+02:00\no ValidationDocuments:\nSUPPORTING_DOCUMENTS\no ValidationReference:\nhttp://registry.gov/evidence.pdf\nExample 20: LEI A was erroneously set to RETIRED on 23 January 2020 and a Legal Entity Event with LegalEntityEventType\nDISSOLUTION was introduced. The LEl issuer acknowledged the incorrect Legal Entity Event on 25 January 2020 and\ncreated an additional Legal Entity Event with @event_status WITHDRAWN_CANCELLED to indicate that the previously\nrecorded Legal Entity Event was incorrect. The RegistrationStatus of the LEI Record returns to ISSUED.\nState Transition and Validation Rules for Common Data File formats Page 161 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1920,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.148Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.14 Update of LEI Reference Data other than due to Legal Entity\nEvents\nThe Reference Data of an LEI Record Set may change without the occurrence of specific Legal Entity\nEvents, for instance due to data updated by the Legal Entity or challenged data. The LEl issuer is\nresponsible to verify changed or challenged Reference Data. If the LEl issuer is ultimately unable to\nfully corroborate Reference Data updated or confirmed by the Legal Entity, the Validation Sources\nmust change to PARTIALLY CORROBORATED or ENTITY_SUPPLIED_ONLY.\nWhenever an element of the Reference Data is updated, the respective LastUpdateDate (LEI Record\nor Relationship Records) SHALL be updated with the current date and time as well.\n4.15 LEI Record update — Registration information changes\nThis Use Case only applies where the registration information changes, and the Legal Entity remains\nan operating entity. Usually, this would happen as part of a Legal Entity Event (e.g.: legal form\nchange), but the registration information change does not trigger a Legal Entity Event itself.\nThe LEl issuer:\no SHALL update lei:RegistrationAuthority accordingly, following the general rules for Registration\nAuthority Reporting (see section 2.2.3).\no SHALL check, if an update to lei:ValidationAuthority, lei:ValidationOtherAuthorities and/or\nlei:ValidationSources is required.\nThis also includes cases where a non-reserved Registration Authority code is supplied for the first\ntime (see section 2.2.3 for the Transition Rules after an RA list update).\n4.16 LEI Record update — Reporting Exception changes to\nRelationship Records\nThis Use Case applies where the child Legal Entity reports a parent Legal Entity after initial opt-out\nreporting.\nThe LEl issuer:\no SHALL create the applicable Relationship Record(s) according to Use Cases 4.1.1 and/or 4.1.2.\ne SHALL remove the superseded reporting exception record(s) from publication.\nIf the ExceptionReason was NO_LEI, Use Case 4.11 applies instead.\nState Transition and Validation Rules for Common Data File formats Page 162 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2153,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.148Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.17 LEI Record Set update — Entity or Relationship Data changes\n\nThis Use Case applies where any data element in the entity data or the Relationship data or a\n\nreporting exception changes that is not the result of one of the other Use Cases (usually, this is only\n\nnecessary to amend registration or validation errors).\n\nThe LEl issuer:\n\ne SHALL update the respective data element(s) accordingly.\n\ne SHALL not make any additional changes, except for updating LastUpdateDate.\n\n4.18 LEI Record Set update — Change of fund manager\n\nThis Use Case applies when the management of a fund entity changes from fund manager with LEI A\n\nto fund manager with LEI B and the fund entity itself is still active.\n\nThe LEl issuer:\n\ne SHALL set the rr:RegistrationStatus of the fund relationship record with EndNodelD LEI A to\nRETIRED. The EndDate of the RelationshipPeriod with PeriodType RELATIONSHIP_PERIOD SHALL\nbe the date of the change.\n\ne SHALL introduce a new fund relationship record with rr:RegistrationStatus PUBLISHED with\nEndNodelD LEI B. The StartDate of the RelationshipPeriod with PeriodType\nRELATIONSHIP_PERIOD SHALL be the date of the change.\n\n4.19 LEI Record Set update — Transfer\n\nA Legal Entity's LEI Record can be transferred from one LEl issuer to another. All Relationship Records\n\n(active and inactive) are also transferred. The following sections describe the updates to the LEI\n\nRecord Set only. For details on timelines and responsibility, refer to the Supporting Documentation\n\nfor Transfers.\n\nIn general, only LEI Record Sets representing operational Legal Entities can be transferred\n\n(RegistrationStatus ISSUED or LAPSED). In rare cases, LEI Record Sets representing inactive Legal\n\nEntities (RegistrationStatus RETIRED) and even invalid records (RegistrationStatus DUPLICATE or\n\nANNULLED) will transfer from one LEl issuer to another. In such cases the Receiving LOU should\n\nprovide an explanation to the Sending LOU (e.g.: the closure of one LEl issuer).\n\nA transfer is initiated after the request from the Legal Entity by the Receiving LOU. The Receiving LOU\n\ninforms the Sending LOU about the transfer request, providing evidence for the authorization of the\n\nrequestor. The Sending LOU confirms the transfer with their contact to the Legal Entity. If no\nresponse from the Legal Entity can be received within the timeframe defined in supporting transfer\nprotocol documentation, the Sending LOU SHALL accept the transfer request.\nState Transition and Validation Rules for Common Data File formats Page 163 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2632,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.148Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Sending LOU Perspective:\n\nWhen the Sending LOU receives the transfer request, the LEI Record Set is updated as follows:\n\no lei:RegistrationStatus SHALL be PENDING_TRANSFER.\n\no rr:RegistrationStatus SHALL be PENDING_TRANSFER for all Relationship Records.\n\nWhen the Sending LOU confirms the transfer request and verifies that the updated\n\nRegistrationStatus is displayed in the Golden Copy, the LEI Record Set is updated as follows:\n\no lei:RegistrationStatus SHALL be PENDING_ARCHIVAL that was PENDING_TRANSFER before.\n\no rr:RegistrationStatus SHALL be PENDING_ARCHIVAL for all Relationship Records that were\nPENDING_TRANSFER before.\n\nThe Sending LOU verifies in the Golden Copy Files, generated by GLEIF, that its own LEI Record Set is\n\ndisplayed as PENDING_ARCHIVAL. After the Receiving LOU’s LEI Record Set is published in the Golden\n\nCopy, the Sending LOU updates their LElI Record Set as follows:\n\no lei:RegistrationStatus SHALL be TRANSFERRED that was PENDING_ARCHIVAL before and\nremoved from files uploaded to GLEIF.\n\no rr:RegistrationStatus SHALL be TRANSFERRED for all Relationship Records that were\nPENDING_ARCHIVAL before and removed from files uploaded to GLEIF.\n\ne All remaining Relationship Records and all Reporting Exception Records are removed from files\nuploaded to GLEIF.\n\nReceiving LOU Perspective:\n\nThe Receiving LOU validates all LEI Reference Data during transfer and once the Sending LOU\n\npublishes the LEI Record with RegistrationStatus PENDING_ARCHIVAL, the Receiving LOU SHALL\n\npublish a complete set of entity and relationship data, including historical and/or internal\nrelationships:\n\no lei:RegistrationStatus SHALL be ISSUED, unless, in very rare cases, the LEI Record was RETIRED,\nDUPLICATE or ANNULLED prior to the transfer request, in which case, the original\nRegistrationStatus is retained; the Receiving LOU SHALL NOT publish the LElI Record with\nRegistrationStatus LAPSED after the transfer is completed, even if that was the recorded status\npublished by the Sending LOU. All LAPSED LEIs SHALL be renewed during transfer.\n\nState Transition and Validation Rules for Common Data File formats Page 164 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2241,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.148Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o rr:RegistrationStatus SHALL be PUBLISHED for all ACTIVE Relationship Records; INACTIVE\nRelationship Records that were ANNULLED by the Sending LOU are retained with the\nRegistrationStatus they had prior to the transfer; the Receiving LOU SHALL keep historical\nRelationship Records unchanged except for amending data quality issues (e.g.: due to missing\nRelationshipPeriods).\n\no InitialRegistrationDate for all LEI Record Sets SHALL NOT be updated but retained as it was\nbefore the transfer (adapting to a different time zone is accepted but not required).\n\nFigure 10 further clarifies the transfer protocol. Each row represents a time unit, e.g., one business\n\nday.\n\nState Transition and Validation Rules for Common Data File formats Page 165 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":852,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.148Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Receiving LOU Sending LOU\nInitiation of Transfer\nThe Legal Entity informs its new\nmanaging LOU (Receiving LOU)\nrequesting a transfer. The LOU O\ncontacts the current managing LOU [RSUET, LACRED]\n(Sending LOU) and triggers a LEIA\ntransfer.\nO\\ PENDING_\nLEIA TRANSFER\nThe Sending LOU sends confirmation of the\nLEI Transfer request back to the Receiving\nLOU. The Sending LOU notifies the Legal\nEntity that the transfer will occur after 3\nbusiness days, if no objection is received.\nThe Transfer Objection Form is attached to\nthe notification.\nO\\ PENDING_\nLEIA ARCHIVAL\nThe Sending LOU receives\nconfirmation from the Legal Entity or\nthe Legal Entity has not responded\nwithin 3 business days.\nLEIA\nO\\ PENDING _\nThe Receiving LOU validates the LEIA ARCHIVAL\nmost recent data of the LEI Record\nSet and publishes the record.\nThe Sending LOU stops publishing\nthe LEI Record Set after the LEI\nO— Record Set appears in the Golden\nLEIA Copy Files generated by GLEIF with\nManagingLOU = Receiving LOU.\nTransfer Completed\nFigure 10: Exemplary timeline of an LEI transfer\nState Transition and Validation Rules for Common Data File formats Page 166 of 170\nGLEIF) Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1243,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.148Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.20 Registration errors — Exclusivity Violation (duplication)\nIf a Legal Entity has more than one LEI, the Legal Entity SHALL choose which LEI Record Set survives.\nIf the contact point for both LEls is non-responsive, then the earliest LEI survives. The DUPLICATE\nstatus is assigned to the non-surviving registration (i.e. the LEI that should no longer be used).\no lei:RegistrationStatus SHALL be DUPLICATE\ne SuccessorLElI SHALL be the LEI of the surviving registration\no for Branch entities, the survivor SHALL be another Branch entity in the same host jurisdiction; if\nthe Branch entity was registered in the same jurisdiction as the head office, lei:RegistrationStatus\nSHALL be ANNULLED instead (see Use Case 4.17 Registration error — Eligibility violation)\no rr:RegistrationStatus SHALL be ANNULLED for all relationships\nIf a parent Legal Entity (i.e.: the entity represented by the EndNodelD of a Relationship Record) is a\nduplicate, the LEl issuer of the child Legal Entity adjusts all not ANNULLED Relationship Records with\nthis parent Legal Entity as EndNote as follows:\no rr:RegistrationStatus of existing Relationship Records SHALL be ANNULLED\n¢ new Relationship Records SHALL be created with the surviving parent Legal Entity’s LEIl as\nEndNodelD\n4.21 Registration error — Relationship Record or reporting exception\nis a duplicate\nA child LEI record SHALL have only a maximum of one relationship data set of each type at a time. If\nthere is more than one published at the same time, duplicate Relationship Records exist. There are\nthree ways, duplicate Relationship Records can be introduced:\n* More than one ACTIVE Relationship Record with the exact same StartNode, same\nRelationshipType but different EndNodes are published, or\n* More than one Relationship Record with the exact same StartNode, same RelationshipType,\nsame EndNode and same StartDate for PeriodType RELATIONSHIP_PERIOD is published.\ne One ACTIVE accounting consolidation parent relationship is published together with a\ncorresponding reporting exception for the same parent (direct/ultimate).\nState Transition and Validation Rules for Common Data File formats Page 167 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2256,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.148Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"For the first case, the LEl issuer SHALL determine which Relationship Record is correct currently; all\nother duplicate records need to be set either to INACTIVE, if they represent no longer current\nrelationships, or to ANNULLED, if they were created erroneously.\n\n4.22 Registration error — Eligibility violation (invalid LEl issuance)\n\nIf an LEI registration is identified as erroneous or invalid after it is issued, the LEl issuer SHALL set the\n\nrecord to an ANNULLED state but keep it as published records in the Global LEI System to support the\n\nhistorical record and to provide resolution to any external query of the LEI. If the record represented\n\na parent Legal Entity (i.e.: is the EndNode in a Relationship Records), the LEl issuer of the child Legal\n\nEntity SHALL update all affected relationships as if the parent were a duplicate (see section 4.20).\n\n4.23 Issue New LEI for an US company incorporated in one state but\n\noperating in another\n\nIn the US, the state where a company is incorporated may not necessarily be the state where the\n\ncompany has its main base of operations. When a Legal Entity incorporated in the US is requesting a\n\nnew LEI code, in addition to or differing from section 4.1, the LEl issuer:\n\nSHALL validate and publish at least the following:\n\no RegistrationAuthority SHALL be the register where the entity is incorporated.\n\no Legallurisdiction SHALL match with the state of incorporation.\n\no EntityLegalFormCode SHALL match with Legallurisdiction.\n\no LegalAddress SHALL be the address displayed in the RegistrationAuthority.\n\ne HeadquartersAddress SHALL be the main location of business operations.\n\no If the entity is registered with a business name or as a foreign company in the state where the\nheadquarters are located, this registration SHALL be included in the ValidationAuthority or in\nOtherValidationAuthorities.\n\n¢ ValidationSources SHALL be FULLY_CORROBORATED, if all relevant elements can be\ncorroborated via the provided ValidationAuthority and OtherValidationAuthorities; it SHALL be\nPARTIALLY_CORROBORATED if not all relevant elements can be corroborated.\n\nState Transition and Validation Rules for Common Data File formats Page 168 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2292,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.148Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.24 Issue New LEI - Financial institution in the US\n\nBanks, credit unions, and other financial institutions in the US can be chartered on a state level or on\n\na federal level and are subject to regulations and supervision from multiple governmental\n\nauthorities. When a new LEl is requested for financial institution in the US (e.g., National Banks and\n\nFederal Savings Associations, State Banks, Credit Unions, Bank Holding Companies, Edge Act\n\nCorporations), in addition to or differing from section 4.1, the LEl issuer:\n\no SHALL consult the FDIC’s “BankFind Suit”, the FFIEC’s NIC institution search, the OOC's list of\nfinancial institutions, or the NCUA’s “Research a Credit Union Tool” and determine if the LEI\napplicant is a National Bank, Federal Savings Association, Federal Credit Union, or a state-\nchartered institution.\n\nIf the LEl applicant is chartered on a federal level, following rules apply:\n\no Legallurisdiction SHALL be US.\n\no EntityLegalForm SHALL be an ELF code assigned on federal (US) level representing the respective\ntype of financial institution (e.g., “62VJ” for National Bank).\n\no The LEl issuer SHALL determine under which authority the entity is chartered and populate the\nrespective RA code as RegistrationAuthoritylD\n\no RegistrationAuthorityEntitylD SHALL be the local identifier representing the entity; it SHALL be\nthe ‘native’ identifier assigned by that authority (e.g., the OCC’s charter license number) as some\nalso provide identifiers assigned by other authorities (e.g., FDIC certificate number).\n\n¢ ValidationAuthoritylD SHALL be one of the authorities consulted to determine that the entity is\nfederally chartered (FDIC, OCC, FFIEC, or NCUA). Having a different authority than in\nRegistrationAuthoritylD MAY support the identification of potential duplicates.\nValidationAuthorityEntity|D SHALL be the ‘native’ entity identifier assigned by that authority.\n\no OtherValidationAuthorities MAY be included to refer to further authorities (e.g., local business\nregister) used for the corroboration of the reference data.\n\nIf the LEIl applicant is chartered on a state level, the following rules apply:\n\no Legallurisdiction SHALL be the state where the state-chartered institution is chartered.\n\no EntityLegalForm SHALL be the Legal Form code that best describes the nature of the financial\ninstitution using the relevant ELF codes for that state.\n\no The LEl issuer SHALL determine under which authority the entity is chartered and populate the\nrespective RA code as RegistrationAuthoritylD\n\no RegistrationAuthorityEntitylD SHALL be the local identifier representing the entity; it SHALL be\nthe ‘native’ identifier assigned by that authority.\n\nState Transition and Validation Rules for Common Data File formats Page 169 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2866,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.148Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"¢ ValidationAuthoritylD SHALL be one of the authorities consulted to determine that the entity is\nstate-chartered (FDIC, OCC, FFIEC, or NCUA). ValidationAuthorityEntitylD SHALL be the ‘native’\nentity identifier assigned by that authority.\ne OtherValidationAuthorities MAY be included to refer to further authorities (e.g., local business\nregister) used for the corroboration of the reference data.\nState Transition and Validation Rules for Common Data File formats Page 170 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":582,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.149Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Figure 2: Examples for level 2 declaration within an LEI Record Set - a) describes the expected Use Case of an LEI A\ndeclaring two different LEls as direct and ultimate parent; b) LEI A declares same LEI B as direct and ultimate parent by\nproviding two separated Relationship Records; c) LEI A declares an LEI B as direct parent and an exception (e.g., NO_LEI)\nfor its ultimate parent relationship; d) LEI A declares two exceptions.\nA child Legal Entity SHALL never have an accounting consolidation parent or branch relationship with\nitself; the LEI identifying the parent must be different from the LEI identifying the child entity.\nReporting accounting consolidating direct and ultimate parent is mandatory for all Legal Entities with\nthe exception of branches (see below). In cases where the Legal Entity has declined to provide the\nmandatory reporting of a specified type of relationship information (direct or ultimate parent), the\nreason is explicitly declared in relationship Reporting Exception Record. This information is reported\nat the time of LEl Issuance, LEI Renewal, or LEl Transfer, whichever happens first.\nExceptions are reported as provided by the Legal Entity. The LOU creates a reporting exception\ninstead of a Relationship Records. The LOU SHALL remove the exception record given:\no the child subsequently reports the respective direct or the ultimate parent.\n¢ the child entity subsequently ends (LEI RegistrationStatus of RETIRED, ANNULLED, or DUPLICATE).\no after a transfer to another LOU has been completed.\nException reason reporting\nIn the case that a Legal Entity is aware that it has a relationship of the relevant type but withholds\nthe details due to legal concerns, the Legal Entity SHALL provide an opt out reason NON_PUBLIC.\nReasons are recorded in a manner specified by the LEI-ROC and reported in the Reporting Exception\nRecords file. No relationship information SHALL be recorded by the LEl issuer. The opt out reason is\ncollected as part of the LEl Record of the reporting entity. As noted by the LEI-ROC, it would be the\nprerogative of any competent regulator requiring this information to determine whether the opt out\nwas justified.\nNon-consolidating exceptions have one of the following reasons: NATURAL_PERSONS,\nNON_CONSOLIDATING or NO_KNOWN_PERSON. This group of exceptions can only be assigned to\nboth parents or to neither of them and never in combination with an active relationship or another\nexception reason indicating that an unreported accounting consolidation relationship exists.\nNo parent according to the definition used\nIf the Legal Entity reports that it has no accounting consolidating parent relationships, this\ninformation is collected and reported in the Reporting Exception Records file.\nParent without LEI\nIn the case that one or both Relationship Records include a parent without an LEl, this information is\nalso reported in the Reporting Exception Records file for publication.\nState Transition and Validation Rules for Common Data File formats Page 18 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":3128,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.149Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Resolving parentage conflicts\n\nParentage conflicts describe situations where the reported relationship information for direct and\n\nultimate parent is not consistent with the definition of parent relationships based on accounting\n\nconsolidation or if the declared ultimate parent is not a viable candidate for being an ultimate\nparent.\n\nCommon reasons for inconsistent information:\n\no Declared ultimate parent has parents: the ultimate parent has public parent relationships.\n\no Declared ultimate parent has incorrect exceptions: the ultimate parent SHALL have exactly 2\nexceptions — one for its direct and one for its ultimate parent — with proper exception reasons\n(NATURAL_PERSONS, NON_CONSOLIDATING, NO_KNOWN_PERSON). Reporting Exception\nRecords with other reasons are inconsistent to being declared as an ultimate parent.\n\no Declared ultimate parent has at least one public Reporting Exception Record with reason NO_LEI.\n\no Declared ultimate parent is inactive, or LEl record is invalid: the RegistrationStatus of the\nultimate parent's LEl record is RETIRED, MERGED , DUPLICATE or ANNULLED.\n\no Declared ultimate parent is an International Branch: the ultimate parent can never be defined as\na BRANCH.\n\nIn case of inconsistent information, the LEl issuer SHALL confirm the relationship information of the\n\nLEI record managed by them (can be the child Legal Entity, the declared ultimate parent or both).\n\nThis also can involve contacting the involved Legal Entities but the most up to date consolidated\n\nfinancial statements remain the primary source for validating Level 2 data. If the current information\n\nis found to be incorrect, the LEl issuer SHALL update the relationship information accordingly. If the\ncurrent information is confirmed as correct, the LEl issuer SHALL approach the other LEl issuer(s)\ninvolved by raising a challenge and providing evidence of how the data should be corrected. At this\nstage, the LEl issuer MAY publish the record even if the parentage conflict has not been resolved.\n\nChallenges MAY be raised using GLEIF's Challenge Facility integrated in LEI Search on GLEIF website?.\n\nThe other LEl issuer then re-validates their record(s) and responds to the challenge accordingly. If the\n\nchallenge is not accepted, both LEl issuers need to discuss this matter further with all involved\n\nparties.\n\nBranch relationships\n\nBranches are part of the same legal person as their head office, and can be described as different\n\nestablishments, or locations, of the same corporate entity, whereas a Subsidiary is a legal person\n\ndistinct from its parent. However, International Branches may have independent requirements for\nregulatory reporting and are therefore eligible for their own LEls. A Branch relationship describes the\nrelationship between an International Branch and its head office. The Branch LEI MAY represent\n\n2 https://search.gleif.org/\n\nState Transition and Validation Rules for Common Data File formats Page 19 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":3061,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.149Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"multiple offices or locations of a Legal Entity in a host country jurisdiction. The Legal Entity SHALL\n\nprovide the address information and additional Reference Data of the Branch. A Branch SHALL NOT\n\ndeclare a direct or ultimate accounting consolidating parent relationship or report exceptions.\n\nFund relationships\n\nFor Fund entities the following three relationship types are available (see section 3.50):\n\n¢ Fund Management Entity: A Legal Entity that is considered as the main management entity of a\nfund when it is legally responsible for the constitution and operation of the fund. Such\nresponsibility will include the day-to-day management of a fund's investments and management\nof a fund’s risks, or the appointment of others for that purpose. In the latter case, the entity to\nwhich these functions may have been delegated is not considered to be a Fund Management\nEntity. The Fund Management Entity can be the fund itself, if the fund is self-managed. In this\ncase there MAY be a relationship for which StartNode and EndNode are populated with the LEI of\nthe fund.\n\no Umbrella Structures: An Umbrella Structure is a Legal Entity with one or more than one sub-\nfunds/compartments where each sub-fund/compartment has its own investment objectives,\nseparate investment policies and strategies, segregation of assets, separate investors and which\nhas segregated liability between sub-funds/compartments. U.S. Series Funds and Japanese “non-\ninvestment management funds” are to be identified as Umbrella Structures in the Global LEI\nSystem.\n\no Master-Feeder: A relationship, where a Feeder Fund is exclusively, or almost exclusively, invested\nin a single other fund (e.g., U.S, EU UCITS), or several funds that have identical investment\nstrategies (for the latter, provided this situation is qualified as a Master-Feeder Relationship\nunder the applicable laws and regulations, e.g., some alternative investment funds in the EU)\nreferred to as a Master Fund (or Master Funds). It is clarified that this covers only cases where\nthis relationship is organized in the legal documentation of the feeder fund and does not cover\nrelationships where a fund’s assets are invested in multiple other funds (fund of fund structure).\n\nThe collection of new fund relationships in the Global LEI System SHALL be mandatory:\n\na) If the relationship is mandated to be reported and publicly available in the relevant\njurisdiction AND if the LEl is mandatory for the related entity in the relevant jurisdiction\n\nb) For the relationship between an Umbrella Structure and a sub-fund or compartment or other\nsub-structure.\n\nIn all cases where a fund relationship is reported, StartNode and EndNode of the relationship SHALL\n\nbe LEI codes.\n\nState Transition and Validation Rules for Common Data File formats Page 20 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2906,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.149Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.12 Transliterated Other Entity Names.....cccccevvvviiieiiinniiiiiieeccciiiece e ssssiieeeeen 44\n3.13 Legal AQAIESS ...vvuieeeiiiieeeeereiiitte e srte e etrrr e e s e ssrire e ee s s s saibeaae e s s sananeeessnsnnneeaesenes 4D\n3.14 Headquarters AdAreSS ......ccuvuviieeiiiiiiiieeeesiiiieee e esssiieeeessssiiesesessssnnseesssssssnseeessnns 40\n3.15 Other AdAreSSES ..ceeivviieeee ittt eeesie e e e s esssireeee s sasieeae e s s snnaneeessnsnsnseeessnsn BT\n3.16 Transliterated Other Addresses.......cvviviviiiiiviiee e essiieee e seveeeessssnnneee e 47\n3.17 Registration AULNOIILY ..ccciiiiiiiiieiiiiciiiececie e ssnnneee e 48\n3.18 Registration AUthOrIty ID ...cccvveiiiiiiiiiieeie e e s ssnnneee e 49\n3.19 Other Registration AUthOrity ID.......cccceeeviiiiiiiee s ssieneee 0. 49\n3.20 Registration Authority Entity ID......cccccveiiiiiiiiiiie i ceciieeee s esiiieeeessssiiieeeeeen. D0\n3.21 Legal JUriSAICTiON ...cicciiieeie ettt s ee s eee e s s sraae e essssnnneeesenes DL\n3.22 ENTitY Cat@OrY ettt ettt e e e e e e e e eeereaesne e s D2\n3.23 ENtitySUDCAtEEOIY .uuiiiiiii ittt ettt ee s e ae e s s state e eessnaaeeeeenes DD\n3.24 Legal FOIM ciiiiiiiiee ettt ette e e rrae e e s e srabe e ae s s s sasbaaeeesssannanesessnnnsssenessnes DT\n3.25 ENtItY STAtUS .cuieiiiie ettt te e e s aaaeeeeenes DO\n3.26 Entity Creation Date ...ttt DO\n3.27 SUCCESSOr ENTItY oot e s e eeeeeeeeeeeesnen OO\n3.28 Legal ENtity EVENTS ..cccvveiiii ittt sttt e esiieeee s siiieeae e s s snaneeesssnnnneaesanns O\n3.29 Legal ENtity EVENT oottt ee s siie e s srane e e s ssnaaeee e enes O2\n3.30 Legal ENtity EVENT TYPE .ciiiiiiiiiiiieieeciiieeeecriiieee s es e ee e s srae e e e s sssnneeeessssssnnaeaen e O4\n3.31 Legal Entity Event Effective Date.......cccceevevivieee it ssiiaeee 0000, 06\n3.32 Legal Entity Event Recorded Date........ccccoeviiieeeiiiiiieeie s ensiieeie s sevieeesssinieee e 07\n3.33 Validation Documents (context: LEI-CDF).......ccccceevviieeeiiieeeceeeessiieesvee e siieeeennn 67\n3.34 Validation Reference (context: LEI-CDF)......ccccccveiiviieeiiiiieeecieee e e esiee e eeiieeennn. 68\n3.35 Affected FIEldS ..uuiiii ittt ssrreeee a0 D8\n3.36 Affected Field. ... e s s naeeee e enes 0O\n3.37 Initial Registration Date (context: LEI-CDF) ........cccovvveeeiviieeecieeeeesivieesceeeesiieenennn 71\n3.38 Last Update Date (context: LEI-CDF)......cccccveeeieeeriiieeeiiiieeeciieeessiiesessveeesveeeesnnnn 71\n3.39 Registration Status (context: LEI-CDF) ..c.covvveeiiieeiiiieecciee e sevieee s 72\n3.40 Next Renewal Date (context: LEI-CDF)....ccccuueeeieeeiiiieeciiiieeciieee e e esvee e svvveeeennnn 72\n3.41 Managing LOU (context: LEI-CDF)....ccccviiiiiiie e ccieeesstee s eeeee s svieeessvaee e 73\n3.42 Validation Sources (context: LEI-CDF)......ccccueveiiiieeciieeeciieeesiiee e eeeeeesieessssineeennn 73\n3.43 Validation AULNOIItY......ceiiiiiiiiiec e ee s seanneee e 1\n3.44 Validation AUthOFItY ID ....ccooveiiiieiiiciiiiecce e erae e ssvreeee s snvnnneeenn 1\n3.45 Other Validation AUthOrity ID.....ccooviiiiiiiiiiiiece et ssivveee e e 1D\n3.46 Validation Authority Entity ID.....ccooviiiiiiiiiiiiiece et seeve e sieaeee a0 10\n3.47 Other Validation AUthOIItIES.......coviviiiiiiiiiiiieee et ssiaaeee e 10\n348 STArt NOGE....eieiieie et srire e ee s s s saaieae s e s s sanaaeeessnnsnneaessnes 1T\nG State Transition and Validation Rules for Common Data File formats Page 3 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":3461,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.149Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"The reporting of the Umbrella Structure MAY be triggered by the umbrella entity as well as by its\ncompartments or sub-funds. However, the relationships are then technically recorded following the\nexisting approach of bottom-up declaration (see section 3.50).\nParent reporting for Government Entities\nGeneral Government Entities are related to each other in the sense that all of them belong to the\nGovernment sector. However, there is no “control” of one Government Entity over another in the\nmeaning attributed to “control” in the IFRS or US GAAP. The consolidation procedures may be quite\ndifferent among government entities and the standards used to identify parent relationships\nbetween general entities would not apply. Government entities that are controlled by another\nGovernment Entity SHALL declare parent relationships according to the usual Global LEI System rules\nbut are likely to use specific accounting standards — GOVERNMENT_ACCOUNTING_STANDARD.\nIn the cases that the parent is unknown, the existing relationship exception for\n“NO_KNOWN_PERSON“is to be used.\n2.2 Corroboration of LElI Record Set\n2.2.1 LEI Registration\ne The process by which Legal Entities are issued LEls and the corresponding Reference Data is\nadded and published in the Global LEI System after successful Validation.\no Asageneral rule, only active Legal Entities can request an LEI.\n° When the LEl is initially issued, the RegistrationStatus SHALL be ISSUED and EntityStatus SHALL\nbe ACTIVE.\n¢ Inrare cases, a regulatory framework may require that inactive entities that do not have an LEI\nneed to be identified with an LEI. Then the LEIl record MAY be issued initially with\nRegistrationStatus RETIRED and EntityStatus INACTIVE.\no If a Legal Entity has (a) parent(s) according to the definitions described above, (a) Relationship\nRecord(s) SHALL be published.\n¢ Only relationships that are active by the time of the registration SHALL be recorded.\nRelationships that ended prior to the initial registration SHALL be excluded.\n* When a Legal Entity cannot provide information on its direct and/or ultimate parents, a\nReporting Exception Record SHALL be published instead.\no The Reporting Exception Record includes the applicable reason for not providing (a) Relationship\nRecord(s). If the reason changes over time, the Reporting Exception Record SHALL be updated.\nState Transition and Validation Rules for Common Data File formats Page 21 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2534,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.150Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"2.2.2 Validation\n\nThe LEI Reference Data includes all elements of an LEI Record that describe the Legal Entity itself and\n\nall of its relationships. The LEI Registration details that describe the state of the LEI Record itself are\n\nnot part of the LEI Reference Data.\n\nThe Legal Entity is responsible to supply its Reference Data when a new LEl is requested. The LOU\n\nverifies the existence of the Legal Entity and the Reference Data based on reliable public sources,\n\nprimarily the sources as mentioned on the RA list. If the data is not available from public sources,\nthen the data MAY be provided by the Legal Entity. Available information from the authoritative\nsource used for Validation SHALL be entered in ValidationAuthority. If more than one authoritative\nsource was used, OtherValidationAuthorities SHALL be populated with information from additional\nsources.\n\ne The LElissuer is responsible for validating and verifying the Reference Data of the LEIl Record,\nusing public (RA) sources where available and relying on entity supplied documents, if no public\nsource can be consulted.\n\no The LEl issuer also is responsible to validate any changes and updates to LEI Records.\n\no The LEl issuer SHALL note the level of Validation in the Reference Data via the element\nValidationSources.\n\no If public sources from the RA list were used to validate the LEI Reference Data, ValidationSources\nSHALL be either FULLY_CORROBORATED, if all LEI Reference Data can be verified, or\nPARTIALLY_CORROBORATED, if only some of the LEI Reference Data can be verified.\n\no If public sources from the RA list were used to validate the LEI Reference Data and all data apart\nfrom the postal code and region can be verified using the public sources, the LEl issuer SHALL add\nthe postal code and region information and ValidationSources SHALL be FULLY_CORROBRATED,\nas the postal code and region are a derivative of the verified address.\n\no If the Validation relies on sources provided by the Legal Entity or other sources not included in\nthe RA list, ValidationSources SHALL be ENTITY_SUPPLIED_ONLY.\n\n* Insome jurisdiction, Government entities are not registered by any Registration Authority.\nHowever, the Government Entity is established by a public legislation or statute, that can be\nreferred to for corroboration. If such public legal document is the source used for corroboration,\nValidationSources SHALL be FULLY _CORROBORATED, if all data elements could be corroborated\nfrom the document, or PARTIALLY_CORROBORATED, if some data elements could be\ncorroborated. Using such documents for validation of unregistered Government entities SHALL\nbe the preferred validation process compared to relying only on entity supplied information.\n\no If ValidationSources is PENDING, the LEI Record SHALL NOT be published and is for the LEI\nissuer's internal use only.\n\no The same authoritative source SHALL NOT appear more than once in ValidationAuthority and/or\nOtherValidationAuthorities but one of the sources MAY be the same as RegistrationAuthority.\n\nState Transition and Validation Rules for Common Data File formats Page 22 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":3213,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.151Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o OtherValidationAuthorities SHALL NOT include RA999999 (see chapter 2.2.3) as\nValidationAuthorityID.\n\no OtherValidationAuthorities MAY contain additional information about an authorititative source\nand local identifiers, in order to enrich the LEI Record Set and support verification by a third\nparty, the public or just to enhance and enable a mapping exercise.\n\no If the Legal Entity has declared relationships, the LEl issuer is responsible to validate that the\nrelationship between the two Legal Entities exists.\n\no The LElissuer is responsible for validating that the LEl presented in an EndNode of a relationship\nindeed represents the Legal Entity declared in the documents used for validating the\nrelationship.\n\ne The LElissuer is not responsible for validating Reporting Exception reasons reported.\n\ne The LElissuer is not responsible for validating a Legal Entity’s statement that there is no parent\naccording to the accounting consolidating definition used but SHALL respond to any challenges to\nthat status.\n\no The LElissuer is not expected to validate the Reference Data associated with the LEI presented as\nEndNode unless the LEl issuer is also the LEl issuer of the EndNode’s LEI Record Set.\n\ne The LElissuer is responsible for ensuring that a relationship is made to an active entity. This\nmeans the parent LEI should not have a RegistrationStatus of DUPLICATE, RETIRED, MERGED , or\nANNULLED at the time of the initial Relationship Records issuance. Rare cases, where an LEl is\nissued initially to an inactive entity are exempted from this rule.\n\no The LEl issuer SHALL accept or deny a Relationship Record based on the result of its Validation.\n\no The LEl issuer SHALL revalidate the complete LEI Reference Data at each renewal. When LEI\nReference Data is updated (e.g.: by the Legal Entity or due to a challenge), the updated data\nSHALL also be validated.\n\nPrimary sources are required for the Validation of accounting consolidating parent relationships.\n\nThese include only the following documents:\n\n1. Consolidated financial statements are a key source to validate parent relationships. Such reports\nmay be prepared and submitted to the relevant authority quarterly or annually or attested to by\na third-party auditor and not submitted to an authority.\n\n2. Regulatory filings (i.e., reports to a securities regulator or a bank supervisor) are another\nimportant source. When validating using a regulatory filing, the filing name must be provided (as\nwell as the path if available). Best practice would be to include the Digital Object Identifier (DOI)\nof the document.\n\n3. Other types of allowable sources include other documents supporting the preparation of\nconsolidated financial statements, contracts, and other official documents.\n\nState Transition and Validation Rules for Common Data File formats Page 23 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2939,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.151Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Proprietary products containing secondary data derived from a variety of sources are not considered\nas valid sources for Validation of relationship data. Only an original source of the above-mentioned\nquality is acceptable. The level of corroboration depends on the sources used for Validation:\n\n¢ The ValidationSources of a Relationship Records is FULLY _CORROBORATED if\no (i) there are consolidated financial statements, other documents supporting the preparation\n\nof consolidated financial statements coming from or otherwise confirmed by the external\nauditor, or regulatory filings\n\ne AND (ii) these documents establish the consolidation relationship and mention the name of\nboth related entities.\n\no The ValidationSources of a Relationship Record is PARTIALLY_CORROBORATED, if\no (i) the definition of parent used in regulatory filings differs from the accounting consolidation\n\ndefinition, but filings assist in corroborating the information provided by the child Legal\nEntity that the conditions of consolidation are met. Only accounting consolidation\nrelationships are expected to be reported and the LEl issuer is not expected to conduct an\nanalysis of differences between the regulatory sources and the accounting standard.\nGenerally, the type of source, or the fact that the source does not refer to accounting\nstandards will inform the LEl issuer that this category should be used;\n\no OR (ii) Official documents such as regulatory filings or contracts make it likely that the\nconditions of accounting consolidation are met, or have ceased to be met, when\nconsolidated accounts reflecting the new situation have not been established yet.\n\n¢ The ValidationSources of a Relationship Records is ENTITY_SUPPLIED_ONLY if\ne (i) the conditions for FULLY_CORROBORATED or PARTIALLY_CORROBORATED would have\n\nbeen met, except that the documents used for Validation are usually not publicly available in\nthe legal jurisdiction(s) of the child and parent Legal Entities;\n\ne AND (ii) the child Legal Entity provided official documents for the purpose of validating the\nrelationship.\n\nFund entities can have fund relationships in addition to the above described accounting consolidating\n\nparent relationships. A fund prospectus would be a good source for validating the different Fund\n\nrelationships:\n\ne Providing prospectus certified by a regulatory authority from GLEIF RA list SHALL be set to\nFULLY_CORROBORATED and the corresponding RA code SHALL be documented in the Validation\nAuthority container.\n\ne Providing prospectus not vetted by any authority SHALL be reported as ENTITY_SUPPLIED _ONLY.\n\nState Transition and Validation Rules for Common Data File formats Page 24 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2779,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.151Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"The Validation Authority of a fund entity SHALL be the financial regulator registering the fund.\n\n2.2.3 Application of GLEIF Registration Authorities List\n\nLEl issuers SHALL ensure the cross reference to the local authoritative source is standardized and\n\nincluded in an LEI record. GLEIF maintains and publishes a list with Registration Authority (RA) Codes®\n\nthat SHALL be used to populate RegistrationAuthoritylD and ValidationAuthorityID. This list includes\nspecific and unique codes for all authoritative sources accepted by GLEIF as well as three reserved RA\ncodes (RA777777, RA888888 and RA999999).\n\nSpecific RA code (not RA777777, RA888888 or RA999999):\n\n» If a specific RA code is available, it SHALL be used in RegistrationAuthoritylD and/or\nValidationAuthorityID.\n\no If RegistrationAuthoritylID is populated with a specific RA code, OtherRegistrationAuthoritylD\nSHALL NOT be provided; the same applies to ValidationAuthorityID and\nOtherValidationAuthorityID.\n\n¢ If ValidationAuthorityID is populated with a specific RA code, ValidationSources SHALL NOT be\nENTITY_SUPPLIED_ONLY.\n\no If a specific code is removed from the RA list, the LEl issuer SHALL update all affected records,\nwith a correct new code within the specified implementation time. The new code SHALL NOT be\nRA888888 with the name of the just removed registration authority as OtherAuthorityID.\n\nReserved RA code RA777777:\n\no The RA code RA777777 is used for General Government Entities and International Organizations\nonly in case there is no information available in any regular registration authority and Public\nLegal Documents are used for validation instead.\n\no If ValidationAuthoritylID is populated with RA777777, OtherValidationAuthoritylD SHALL be\npopulated with the name of the source as free text or if available with the link to the documents\nused for validation.\n\no RegistrationAuthoritylD and OtherRegistrationAuthoritylD SHALL NOT be populated with\nRA777777.\n\no If ValidationAuthorityID is RA777777, the RegistrationAuthoritylD SHALL be RA888888 or\nRA999999 only (please consult Figure 3)\n\n3 https://www.gleif.org/en/about-lei/code-lists/gleif-registration-authorities-list#\n\nState Transition and Validation Rules for Common Data File formats Page 25 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2348,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.151Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o If ValidationAuthorityID is RA777777, ValidationSources SHALL shall be\nPARTIALLY_CORROBORATED or FULLY_CORROBORATED.\n\nReserved RA code RA888888:\n\no The RA code RA888888 is used as an interim code. This indicates that a Registration/Validation\nAuthority is not available on the RA list, but the addition of a relevant source, which could be\nused for the LEl in question, has been requested to GLEIF.\n\no This code SHALL be used only after a request to add a new RA source has been sent by email to\nralist@gleif.org with further description of the source.\n\no All requests for new RA codes (or modifications) are collected over time and processed in time\nfor the periodical publication of a new version of the RA list. The approximate date(s) for the\npublication of a new version are communicated well in advance.\n\n* In cases, where the suggested source has NOT been accepted as authoritative source, the LEI\nissuer needs to provide a new suggestion for a source in order to ensure proper corroboration\nwithin a month, if no other implementation time is defined. If no other source could be identified\nfor Validation and Verification of the Legal Entity and its Reference Data, the correspondent\nfields SHALL be changed to RA999999.\n\n* In cases, where the suggested source has been accepted as an authoritative source, the LEl issuer\nSHALL replace the reserved code with the new code and adjust the corroboration level\naccordingly within the time frame communicated for the implementation of the new version of\nthe RA list.\n\n¢ The reserved code RA888888 SHALL NOT be used for longer than a month after publication of\nthe new version of the RA list which includes the new valid RA code, unless a different\nimplementation time has been defined.\n\no If RegistrationAuthorityID is populated with RA888888, OtherRegistrationAuthoritylD SHALL be\npopulated with the name of the source as free text; the same applies to ValidationAuthoritylD\nand OtherValidationAuthorityID.\n\n¢ The name provided as free text SHALL be the same as used in the request sent to GLEIF to add\nthe source to the RA list.\n\no If RegistrationAuthorityID or ValidationAuthorityID is RA888888, ValidationSources SHALL only be\nset to the lowest corroboration level, namely ENTITY_SUPPLIED_ONLY.\n\nReserved RA code RA999999:\n\ne The RA code RA999999 refers to situations when no Registration Authority can be defined for a\nLegal Entity. The LEl issuers are obliged to use their full efforts and local expertise to ensure that\nthe applicant is an existing Legal Entity and is eligible to obtain an LEl and also document this\ninformation accordingly.\n\nState Transition and Validation Rules for Common Data File formats Page 26 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2789,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.151Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o If RA999999 is used as identifier for the source, the respective EntitylD SHALL NOT be populated.\nPlaceholders like “N/A”, “None”, etc. SHALL NOT be used.\n¢ If ValidationAuthorityID is RA999999, ValidationSources SHALL be ENTITY_SUPPLIED_ONLY.\ne RA999999 SHALL NOT be used in OtherValidationAuthorityID or for records with EntityCategory\nBRANCH.\nFigure 3 below shows the allowed combinations of reserved RA codes for RegistrationAuthoritylD\nand ValidationAuthority ID.\nValidationAuthoritylD\nSpecifc\nRA777777 RA888888 RA999999 ValidationAuthoritylD\nRegistrationAuthoritylD\nSpecific Not ok Not ok Not ok Ok\nRegistrationAuthoritylD ot okay ot okay ot okay ay\nFigure 3: Overview of allowed combinations of reserved and specific RA codes for RegistrationAuthoritylD and\nValidationAuthoritylD\n2.3 Life cycle\nFigure 4 highlights the existing general STVR in the registration status of an LEIl, from its creation in\nthe internal LEl issuer systems until reaching a so-called end state. In addition, the life cycle includes\nand describes the process of transferring an LElI Record Set from one LEl issuer to another.\nThe life cycle is divided into “Internal” states, that are managed by the LEl issuer but not shared with\nthe public, and “Published” states, that are included in the Global LEI Repository. For instance,\nPENDING_VALIDATION is Internal with respect to publication because LEI registrations are expected\nto be fully validated prior to the LEI being assigned, issued, and published. An expected part of the\nlife cycle of an LEl registration is the timely update and periodic Validation of its Reference Data. This\nperiodic Validation needs to be performed at least once a year. If a record is not validated again\nwithin this timeframe, the registration status code will be set to LAPSED, meaning the Validation is\noverdue.\nState Transition and Validation Rules for Common Data File formats Page 27 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2012,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.151Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"1\nPUBLISHED\n- /‘///J>77777\\7\\\nINTERNAL H\nREGISTRATION LIFE CYCLE\n: .\nSTART ISSUING PROCESS TRANSIENT\n\\/ |\n\\ END STATES |\nTRANsFERED]<—1\n\nFigure 4: High-level general representation of the life cycle of an LEI\n\n2.3.1 Registration Status Codes\n\nThe RegistrationStatus operational data element indicates the state that an LEI Record can have over\n\nits life cycle.\n\nThe defined status codes fall into four broad categories:\n\n1. Registration life cycle: These are codes applied in the normal life cycle of an LEl registration from\nsubmission through issuance through the termination of the registration when the entity\nbecomes inactive.\n\n2. Registration Errors: These are codes that are needed to correct errors that may occur in LEI\nregistration process.\n\n3. Transient conditions: These are codes that support certain transient conditions describing the\ntransfer of an LEl registration from one LEIl issuer to another.\n\n4. Deprecated statuses: Values that have been accepted in the past, and due to changes in\nunderlying standards, policies and/or rules, have be amended as invalid or no longer in use.\n\nEach RegistrationStatus code holds information regarding the publication of the LEI Record Set as\n\nshown in below table:\n\ne Published: The LEI Record Set is included in the public files published by the LEl issuer and GLEIF.\n\nState Transition and Validation Rules for Common Data File formats Page 28 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1509,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.151Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"¢ Transient: The LEI Record Set is included in the public file published by the LEl issuer, but only\nduring a record transfer from one LEl issuer to another. It may not be included in files published\nby GLEIF, if the same LEl is already published by another LEl issuer.\n\ne Archived: The LEI Record Set is not included in the public file published by the LEl issuer or by\nGLEIF but is retained by the LEl issuer as part of its archival records.\n\n¢ Internal: The LEI Record Set is not included in the public file published by the LEl issuer or by\nGLEIF but may be exchanged between LEI issuers and/or GLEIF as part of the Validation process\nprior to issuance.\n\no Deprecated: The RegistrationStatus has been deprecated and SHALL NOT be used anymore. LEI\nRecords with this RegistrationStatus MAY appear in historical LEI Record files but have been\nupdated to a different status in current data files.\n\nThe following table categorizes the RegistrationStatusEnum codes:\n\nPENDING_VALIDATION Registration life cycle Internal\n\nISSUED Registration life cycle Published\n\nPUBLISHED Registration life cycle Published\n\nDUPLICATE Registration Errors Published\n\nLAPSED Registration life cycle Published\n\nMERGED Deprecated Deprecated\n\nRETIRED Registration life cycle Published\n\nANNULLED Registration Errors Published\n\nCANCELLED Registration Errors Archived\n\nTRANSFERRED Transient condition Archived\n\nPENDING_TRANSFER Transient condition Transient\n\nPENDING_ARCHIVAL Transient condition Transient\n\nThe value MERGED in the RegistrationStatus field is deprecated with the LEI-CDF 3.1 being effective.\nState Transition and Validation Rules for Common Data File formats Page 29 of 170\n@ Public Version 2.7.1 Final\n\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1764,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.151Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"2.3.2 Changes in Registration Status due to Legal Entity Events\nWhile the RegistrationStatus has information about the LEI Record itself and not necessarily\ndescribes the state of the Legal Entity, some Legal Entity Events also trigger a transition in\nRegistrationStatus. Each of the following events documented with its exact effective date SHALL\nchange the RegistrationStatus of the LEI Record to RETIRED according to the existing rules:\no Liquidation (@event_status COMPLETED)\n¢ Insolvency (@event_status COMPLETED)\no Dissolution of a Legal Entity, including International Branches and Subsidiaries (@event_status\nCOMPLETED)\ne Mergers and Acquisitions (for the Legal Entity which ceases operation as a result of a merger)\nRETIRED is an end state of an LEl Record Set, and an update that assigns this RegistrationStatus code\nto the LEI Record Set is the last regular update that is made to that record. Therefore, the\nEntityStatus and the RelationshipStatus are set to INACTIVE once this end state has been reached. In\norder to satisfy the 1ISO 17442 persistence criteria of the LEI (i.e., the ability to properly interpret\nexisting and historical records and reports that refer to LEls in this state), these LEI Records are still\npart of the published LEI records. The LEI Record Set MAY still be updated to comply with the\nimplementation of new code lists or to amend data quality issues caused by the record. In such cases\nGLEIF needs to be informed about the data updates.\nThe following Legal Entity Events SHALL be documented together with the EffectiveDate of the event\nand SHALL remain in their current RegistrationStatus (expected to be either ISSUED or LAPSED):\n¢ Changeinlegal name (@group_type STANDALONE)\ne Change in trade or doing business name\no Change in legal address\no Change in headquarters address\n¢ Change of legal form\no Demergers and Spinoffs (for the entity that has been demerged or spin off)\ne Absorption\no Voluntary Arrangement\no Acquisition of an international branch (for the branch entity)\no Transformation of an international branch into a Subsidiary (for the entity that has been\ntransformed into a Subsidiary)\ne Transformation of a Subsidiary to an international branch (for the entity that has been\ntransformed into an international branch)\nState Transition and Validation Rules for Common Data File formats Page 30 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2459,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.151Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"349 ENA NOUE ettt ettt e e s s saabn e s e s s snaae e e e s snnnneeesenes 1O\n3.50 RelationShip TYPE cooiiiiiiiei et ae e sraae e s ssnaneeeeenes 1O\n3.51 Relationship PEriods .....ccciiiiiiiiiiiiiiiiiiieeee sttt srne e s sssnieeee s seinneeeeees S0\n3.52 Relationship StAtUS ...uvviiiiiiiiiie e 82\n3.53 Relationship QUAlIfIErS.......ooviuiieiiiiriiiee e ee e e 82\n3.54 Relationship QUaNLIfIErs ......c.uivviiiiiiiiiee e ieee e S\n3.55 |Initial Registration Date (context: RR-CDF).......ccccceeverivriieecicieee e 84\n3.56 Last Update Date (context: RR-CDF) .......ccccveeeiiieiiiiieecriiee e s e sieeee 0000 85\n3.57 Registration Status (context: RR-CDF) .....ccccceeeiieiiiiiieciiiee e 85\n3.58 Next Renewal Date (context: RR-CDF)....ccccveeeuiiieiiieeeiiiee e e seiieeee00. 80\n3.59 Managing LOU (context: RR-CDF) ......cccceeiiiieeiiieeeciies e sstve e e sive e 8 7\n3.60 Validation Sources (context: RR-CDF) .....ccccueeeiieiiiiiieeisiiee e esiie e siveee e 8 7\n3.61 Validation Documents (context: RR-CDF) .......cccceviviiieeiiiiee e s, 88\n3.62 Validation Reference (context: RR-CDF) .......ccccvveeiivieeeiiiiie e ssiee e siieeeen00n 89\n3.63 LEI (context: REPEX-CDF)..ccccciiiecieeeiiieeesitiie e ceeeeesiie e essvee s saee e e s savaesssnee s snnveeesnnee 89\n3.64 EXCePtion CateBOrY ....cooiiiiiiiiiiiiiceee ettt ee e OO\n3.65 EXCePtion REASON....ccoiiiiiiiiiiieeieitie e e e e e s e s e eeeesneenenesnens D0\n3.66 EXCEPLiON RETEIENCE ...uuiiiii ittt srae e ssaaaeee e enes D2\n3.67 Associated Entity — DEPRECATED .......cuvviviiiiiiiieeeeiiiieece s essiieeeeesssneneeesssnnneeeeenns 92\n3.68 Entity Expiration Date — DEPRECATED ......ccoocutiiiiiiiiiiieee s ciiiiieee s essiinneeee e ssnneeee . 93\n3.69 Entity Expiration Reason — DEPRECATED.........ccccvivmiiiiiiiiiieieeeeeeeeeeeeeeeeeeeieiiennnnn. 93\nL ¥ LY - 1 R |-\n4.1 Issue New LEI that is not branch, fund, sole proprietor, government entity or\n\ninternational Organization ........cccvueeeiiiinieeie e 9D\n4.1.1 Relationship with a parent Legal Entity with an LEl.........ccccovvviiiiviiiieiiiniieeeennn.. 96\n4.1.2 Relationship with a parent Legal Entity without an LEl .........cccccceeviviiiiiiinieennnn... 96\n4.1.3 No accounting consolidation parent relationship........cccoccevieviieeiiiiviiniiesieeen e 97\n\n4.1.4 Accounting consolidation parent relationship not reported due to legal obstacles\n(o] 2o 10 1 | TS TS USURORSSPRP < ¥\n4.2 Issue NeW LEI = Branch .......coooviuiiiiiiiiiiiiiee e cssiieie e svveeeee s ssvnneeesssssinnnne s 97\n4.3 Issue NeW LEI = FUNd .....oviiiiiiiiiiiecceciiieece e esieee e svane e e e s ssnnneee s snssannenees 99\n4.4 Issue New LEI —Fund in formation ........cccccevvviiiiiiinniiiienscciieeeesssiiieee e esnnnnnn. 101\n4.5 Issue New LEI —Sole proprietor.....ccccoccvveeeeiiiiieeeeiiisiieeeeesssieeeeeesscveneesssnsnnneees 103\n4.6 Issue New LElI —Government entity........cccceviimimiiiiiiiiiiin e eececccveeeeeeeeen... 103\n4.7 Issue New LEI —International organization .........ccccceeeviveeeiiiiiieeeeeinniiiee e 104\n4.8 LEIRecOrd RENEWAl ..cuvvviiiiiiiiiiiieieeciiiecce et essiieie e sieeeeessssnnseeessnssennnns 10D\n4.9 LEl Record update — Parent Legal Entity without an LEI requests an LEl............106\n4.10 LEI Record update — Relationship Record changes to Reporting Exception .......106\nG State Transition and Validation Rules for Common Data File formats Page 4 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":3466,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.151Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"¢ Umbrella fund changes its structure to a stand-alone fund (for the new stand-alone fund)\n\no Bankruptcy (@event_status IN_PROGRESS)\n\n¢ Liquidation (@event_status IN_PROGRESS)\n\no Insolvency (@event_status IN_PROGRESS)\n\no Dissolution of an entity, including international branches and subsidiaries (@event_status\nIN_PROGRESS)\n\no Break ups (for any part of the original Legal Entity that remains in operation and for any new\nLegal Entities that are formed as part of the terms of the breakup)\n\n2.3.3 Changes in Registration Status when a registration error is resolved\n\nThere are three registration status codes that apply to situations in which a registration assignment\n\nerror has been made: DUPLICATE, ANNULLED, and CANCELLED.\n\no The DUPLICATE code refers to the non-surviving record under an Exclusivity Violation.\n\no The ANNULLED code applied to any other type of assignment error detected after an LEI\nregistration has been publicly issued.\n\no The CANCELLED code refers to any type of assignment error detected before publication.\n\nThese error states are terminal: no further updates to Entity sections of registration records in these\n\nstates SHALL occur. Records in the DUPLICATE or ANNULLED states SHALL be retained as published\n\nrecords in the Global LEI System to support the historical record and to provide resolution to any\nexternal query of the LEI. The LEI Record Set MAY still be updated to comply with the\nimplementation of new code lists or to amend data quality issues caused by the record. In such cases\n\nGLEIF needs to be informed about the data updates. Records with the state CANCELLED SHALL be\n\nretained internally by an LEl issuer to support auditing.\n\n2.4 Registration Status Codes for Transient Purposes\n\nThree registration status codes exist to accommodate the transfer of the management of an LElI\n\nregistration from one LEl issuer to another: PENDING_TRANSFER, PENDING_ARCHIVAL,\n\nTRANSFERRED.\n\no PENDING_TRANSFER and PENDING_ARCHIVAL are used in the transitional period between the\nreceipt of a porting request by a Sending LOU and the final confirmation of the transfer.\n\no The TRANSFERRED code is used in the archival records of a Sending LOU after having successfully\ncompleted the transfer of that responsibility to another (Receiving) LOU. A record in this state is\nnot published but kept internally by the prior LOU for audit trail purposes.\n\nFor a short period of time a given record may appear more than once in a published concatenated\n\nfile. This case occurs at the end of the transfer process, when the Sending LOU publishes their file\n\nState Transition and Validation Rules for Common Data File formats Page 31 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2760,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.151Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"with RegistrationStatus PENDING_ARCHIVAL and the Receiving LOU publishes their file with the\nregistration status ISSUED. The time window for these transient states is limited by a transfer\nprotocol shared between GLEIF and the LEl issuers (see Use Case 4.19). On average, transfers SHALL\nbe completed within five to ten business days.\n2.5 Renewal\nRenewal is the process that triggers the periodic Validation of an LEI Record Set. Renewal is required\none year after the initial registration and every year thereafter. The Next Renewal Date in the\nrecord’s registration section indicates the date when the next renewal is due. If a record is not\nrenewed in due time, the LEl issuer shall validate that the entity is still operating. Given the entity is\nstill operating, the Registration Status SHALL be set to LAPSED and the Next Renewal Date SHALL NOT\nbe updated.\nThe renewal of an LEI Record is initiated by the Legal Entity. The LEIl issuer SHALL inform the Legal\nEntity at least six weeks prior to the next renewal date and remind the Legal Entity to renew the LEI\nRecord Set. Any changes to the LEI Reference Data SHALL be updated by the Legal Entity and\nvalidated by the LEl issuer. After this is completed, the Registration Status remains ISSUED and one\nyear is added to the Next Renewal Date. A LAPSED record MAY be renewed as well and return to an\nISSUED state at any point of time.\n2.6 1SO 3166 Conformance of Address and Jurisdiction Fields\nThe following LEI-CDF data fields must contain current, valid ISO 3166 country (or region, where\napplicable) codes taken from the ISO 3166 code lists. The XML schema for the LEI-CDF validates only\nthe format (pattern) of these fields, not the specific codes used.\no CountryCode in all addresses\no RegionCode in all addresses\no Legallurisdiction\nThe RegionCode SHALL be an ISO 3166-2 subdivision code assigned under the CountryCode.\nDepending on the jurisdiction, either a country code or a region code or either of both SHALL be used\nin Legallurisdiction. Details on this are defined in the GLEIF Accepted Legal Jurisdictions Code List*.\n4 GLEIF Accepted Legal Jurisdictions Code List: https://www.gleif.org/en/about-lei/code-lists/gleif-accepted-\nlegal-jurisdictions-code-list\nState Transition and Validation Rules for Common Data File formats Page 32 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2411,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.151Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"2.7 Address Reporting\n\nAn LEI Record SHALL have at least a LegalAddress (where the entity is legally registered) and a\n\nHeadquartersAddress (where the main center of control of the entity resides). LegalAddress and\n\nHeadquartersAddress MAY be the same. Both addresses MAY also be in different countries and/or in\n\ncountries different from Legallurisdiction. If the Legal Entity has only one address recorded in an\n\nofficial Registration Authority, LegalAddress and HeadquartersAddress SHALL be the same address,\nexcept for entities categorized as FUND or BRANCH which have special rules for\n\nHeadquartersAddress (see 3.13 and 3.14 below). If the registry has partial address information, for\n\ninstance a seat of the company recorded only with the city name and a second field with a complete\n\naddress, the latter SHALL be used for LegalAddress and HeadquartersAddress, even if the address is\nin a different city than the city of the seat. In case of doubts, the LEl issuer SHALL contact the\nauthoritative source for further clarification and validation of the data.\n\nIf the address recorded in the registry is not complete, the LEl issuer SHALL collect the missing\n\nelements from the Legal Entity and set ValidationSources to PARTIALLY_CORROBORATED, except\n\nwhen only postal code and/or region is added by the LOU. In this case, the record can be still\n\nFULLY_CORROBORATED (see chapter 2.2.2). In case the HeadquartersAddress could be validated in\n\nan autoritative source different from the primary one, this could be added in the container\n\nOtherValidationAutorities and the corroboration status MAY be set FULLY_CORROBORATED.\n\nAll addresses reported SHALL be complete and include the following mandatory elements:\n\no FirstAddressLine SHALL include the first line describing the address. Up to three additional lines\nMAY be included.\n\no City SHALL be the name of the city in local language and alphabet.\n\no PostalCode SHALL be the postal code in the format specified by the local postal service. For\ncountries that do not use postal codes in addresses, this optional element SHALL NOT be\nprovided.\n\no Region SHALL be the 1ISO 3166-2 region code of the address. For countries that do not have\nregion codes, this optional element SHALL NOT be provided.\n\ne Country SHALL be the ISO 3166-1 country code of the address.\n\nAddresses MAY include optional elements for additional relevant parts of an address to be recorded\n\nin a structured way:\n\n¢ MailRouting MAY contain explicit routing information or “care of” address.\n\no AddressNumber MAY contain the building number.\n\n¢ AddressNumberWithinBuilding MAY contain an internal location within a building, for example to\nidentify the floor, suite or an apartment.\n\nState Transition and Validation Rules for Common Data File formats Page 33 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2892,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.151Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"The information in these optional fields SHALL also be included in FirstAddressLine or\nAdditionalAddressLines. The content of the mandatory elements SHALL NOT be repeated in any\nother field (e.g., the postal code SHALL NOT be included in the designated City field).\n\n2.8 Entity Legal Form Reporting\n\nLEl issuers SHALL ensure that cross reference to the entity legal form is standardized and included in\n\nan LEl record. GLEIF maintains the ISO 20275 standard and publishes the Entity Legal Forms (ELF)\n\nCode List. Codes from that list SHALL be used to populate EntityLegalFormCode. This list includes\n\nspecific and unique codes for all legal forms identified per jurisdiction and two reserved ELF codes\n\n(8888 and 9999) that are valid across jurisdictions.\n\nSpecific ELF code (not 8888 or 9999):\n\no If a specific ELF code is available for an entity's legal form in the entity's legal jurisdiction, it\nSHALL be used in EntityLegalFormCode.\n\no If EntityLegalFormCode is populated with a specific ELF code, OtherLegalForm SHALL NOT be\nprovided.\n\no If a specific code is removed from the ELF code list, the LEl issuer SHALL update all affected\nrecords representing an ACTIVE Legal Entity with a correct new code. The new ELF code SHALL\nNOT be 8888 or 9999 with the name of the just removed legal form as OtherLegalForm.\n\nReserved ELF codes 8888 and 9999:\n\ne Reserved ELF code 8888 is to be used when a new ELF code (for a legal form not yet on the list) is\nrequested by an LEl issuer from GLEIF for a jurisdiction which is on the ELF code list.\n\no Reserved ELF code 9999 is to be used for LEIs from a jurisdiction which is not on the ELF code list\nyet.\n\n¢ The reserved code 8888 SHALL be used only after a request email to elf@gleif.org with further\ndescription of the legal form has been sent.\n\no All requests for new ELF codes (and modifications) are collected over time and processed in time\nfor the periodical publication of a new version of the ELF code list. The approximate date(s) for\nthe publication of a new version SHALL be published well in advance.\n\n¢ In cases, where the suggested legal form has NOT been accepted, based on the reason for the\nrejection, the LEl issuer SHALL select one of the following options:\n\no Use a different existing ELF code assigned to the Legal Entity’s legal form (if possible).\ne Propose another new legal form to be added to the ELF code list and update OtherLegalForm\naccordingly.\n¢ Send more convincing documentation for the proposed legal form.\nState Transition and Validation Rules for Common Data File formats Page 34 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2669,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.152Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o Annul the LEl, but only if the outcome of the discussion is that the proposed legal form is not\neligible for an LEI.\n\n¢ In cases, where the suggested legal form has been accepted, the LEl issuer SHALL update all\napplicable records with the new ELF code, including records that are RETIRED, MERGED not later\nthan one month after publication, unless another implementation time has been set.\n\no If EntityLegalFormCode is populated with 8888 or 9999, OtherLegalForm SHALL include the\ncorrect name of the entity's legal form where no ELF code exists. Therefore, OtherLegalForm\nSHALL NOT contain any ELF code or undescriptive text like “OTHER”, “N/A” or “None”. The name\nprovided as free text SHALL be the same as used in the request sent to GLEIF to add the source to\nthe RA list.\n\n2.9 Language, translation and transliteration\n\ne Where LEl record fields allow for an optional (as per LEI-CDF) language tag, this tag SHALL always\nbe provided. This SHALL be an IETF Language Code conforming to the latest RFC from IETF BCP\n47.\n\ne For transliterated names and addresses then the language code SHALL specify the language of\nthe name or address prior to transliteration.\n\no TransliteratedOtherEntityNames SHALL include a list of ASClI-transliterated (i.e. Latin- or\nRomanized) representations of names for the Legal Entity in all cases of non-romanized\nLegalName.\n\no If using TransliteratedAddressType, the transliterated elements that correspond to the\nmandatory and optional information provided in either the LegalAddress, HeadquartersAddress,\nor OtherAddress SHALL be required, given any of these elements are provided in a non-latin\nalphabet.\n\ne If alegal name or address is provided in an alternative language, both the primary field and the\nalternative SHALL have a language tag, and both SHALL NOT be the same.\n\nState Transition and Validation Rules for Common Data File formats Page 35 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1997,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.152Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3 General State Transition and Validation Rules\nThese rules SHALL apply to the general Use Case for issuing and managing an LE| for a Legal Entity as\nwell as publishing the LEI Record Set. An LEI Record Set with complete Reference Data is composed\nof data fields that are published in different XML files. Each XML file has its own name space and\nschema file. These are:\ne LEl Entity Data (Level 1):\n* Name space: lei\no .xsd file: https://www.gleif.org/content/2-about-lei/6-common-data-file-format/1-\nupcoming-versions/2021-03-04_lei-cdf-v3-1.xsd\no LEI Relationship Data (Level 2):\no Name space: rr\no .xsd file: https://www.gleif.org/content/2-about-lei/6-common-data-file-format/1-\nupcoming-versions/2021-03-04_rr-cdf-v2-1.xsd\no Reporting exception Data (Level 2):\n¢ Name space: repex\no .xsd file: https://www.gleif.org/content/2-about-lei/6-common-data-file-format/1-\nupcoming-versions/2021-07-20_reporting-exceptions-format-v2-1.xsd\nThe complete Xpath is shown in the field description for each field. The schema description in the\n.xsd file provides a more technical definition of each element, including format restrictions, allowed\nvalues, etc. In case there is a discrepancy between the required cardinality of a field in this document\nand the corresponding CDF file, the definition in this document SHALL prevail.\nState Transition and Validation Rules for Common Data File formats Page 36 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1507,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.152Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.1 Header Section (applicable to all files)\nlei:LEIHeader\nrr:Header\nrepex:Header\n_ Contains the file upload information for this file.\n/lei:LEIData/lei:LEIHeader\n/rr:RelationshipData/rr:Header\n/repex:ReportingExceptionData/repex:Header\nThe Header Section describes the context for the LEI Records contained in the main body of the file.\nThe Header Section includes information on the origin and timestamp of the data. The content of the\nHeader Section SHALL NOT be required to interpret the data content of any LEI Record; each LEI\nRecord is self-contained. The Header Section includes the following elements:\ne Content Date\ne Originator\no File Content\no Delta Start\ne Record Count\n° Extension\nState Transition and Validation Rules for Common Data File formats Page 37 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":878,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.152Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.2 Content Date\nlei:ContentDate\nrr:ContentDate\nrepex:ContentDate\n_ The date and time as of which the data contained in the file is valid.\n/lei:LEIData/lei:LEIHeader/lei:ContentDate\n/rr:RelationshipData/rr:Header/rr:ContentDate\n/repex:ReportingExceptionData/repex:Header/repex:ContentDate\nThe Content Date for each record defines the date and time as of which the data contained in the file\nis valid. The following rules apply:\no The ContentDate SHALL be equal to or later than the latest InitialRegistrationDate in the file.\no The ContentDate SHALL be equal to or later than the latest LastUpdateDate in the file.\no The ContentDate SHALL be later than the DeltaStart date for delta files.\n3.3 Originator\nlei:Originator\nrr:Originator\nrepex:Originator\n_ The LEI of the LEl issuer that created the content of this file.\n/lei:LEIData/lei:LEIHeader/lei:Originator\n/rr:RelationshipData/rr:Header/rr:Originator\n/repex:ReportingExceptionData/repex:Header/repex:Originator\nState Transition and Validation Rules for Common Data File formats Page 38 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1148,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.153Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"e The Originator SHALL be a valid LEI with correct check digits as specified in the 1ISO 17442\nstandard document.\no The Originator SHALL contain the LEI of the LEl issuer publishing the file.\no If FileContent is not GLEIF_FULL_PUBLISHED or GLEIF_DELTA_PUBLISHED, Originator SHALL be\npopulated.\n3.4 File Content\nlei:FileContent\nrr:FileContent\nrepex:Content\n_ A code describing the content of this file.\n/lei:LEIData/lei:LEIHeader/lei:FileContent\n/rr:RelationshipData/rr:Header/rr:FileContent\n/repex:ReportingExceptionData/repex:Header/repex:FileContent\n¢ The value LOU_FULL_PUBLISHED for FileContent SHALL be used to designate a file containing all\nup-to-date LEI Records published by an LEl issuer.\no If FileContent is LOU_FULL_PUBLISHED, then DeltaStart SHALL NOT be present.\n¢ The value LOU_DELTA_PUBLISHED for FileContent is used to designate a file containing only LEI\nRecords newly added or changed since an LOU’s last upload.\no If FileContent is LOU_DELTA_PUBLISHED, then DeltaStart SHALL be present.\no If FileContent is neither LOU_DELTA_PUBLISHED nor GLEIF_DELTA_PUBLISHED, DeltaStart SHALL\nNOT be present.\nState Transition and Validation Rules for Common Data File formats Page 39 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1298,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.153Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.5 Delta Start\nlei:DeltaStart\nrr:DeltaStart\nrepex:DeltaStart\nThe date and time of the baseline relative to which this file contains\nnew or changed records.\n/lei:LEIData/lei:LEIHeader/lei:DeltaStart\n/rr:RelationshipData/rr:Header/rr:DeltaStart\n/repex:ReportingExceptionData/repex:Header/repex:DeltaStart\nCurrently, delta files are not provided or accepted by GLEIF.\no If Header contains the DeltaStart element, then FileContent SHALL be LOU_DELTA_PUBLISHED or\nGLEIF_DELTA_PUBLISHED.\n3.6 Record Count\nlei:RecordCount\nrr:RecordCount\nrepex:RecordCount\n_ The number of records in this file.\n/lei:LEIData/lei:LEIHeader/lei:RecordCount\n/rr:RelationshipData/rr:Header/rr:RecordCount\n/repex:ReportingExceptionData/repex:Header/repex:RecordCount\ne The number of instances of lei:LEIRecord, rr:Relationship or repex:ReportingException contained\nin this file SHALL equal the value of RecordCount.\nState Transition and Validation Rules for Common Data File formats Page 40 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1069,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.153Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.11 Lack of renewal —Legal Entity......ccccoeeviviieeiiiiiiiiee i scvvieeeessivieeeessssennnn. 107\n4.12 Lack of renewal — Related Legal Entity including head offices, fund managers,\numbrella and master fuNdS.........cccveeeiiiiiieiiere e ineee e e 107\n4.13 Update of LEI Reference Data due to Legal Entity Events .........ccccceevvvveeeeine.. 107\n4.13.1Legal Entity Event — Event timeline and status..........cccecceevviviiieeeinisceeeecnsiieeenn. 108\n4.13.2Legal Entity Event — Legal Name changes ......cccccevvveeeeivvieeesicciiieeececsiieeeseesvveeen e, 109\n4.13.3Legal Entity Event — Business or trading name changes ........ccccccceeevieeeiiiiiieennnnn, 112\n4.13.4Legal Entity Event — Address information changes........ccccevveevcvecviecceeeninennnn. 114\n4.13.5Legal Entity Event — Legal form changes........cccccvvveeveeecieeevcie e ceeecvvieeeeeesveees 116\n4.13.6Legal Entity Event — ACQUISITION ....coivviiiiieiiiiiie e csiieee s seeeee s esseveeee e 124\n4.13.7Legal Entity Event — AbSOrption ......cccveeeiiiiiieii e ccsiieeeecccrvieesssssvieee s sssnveeeeeees 125\n4.13.8Legal Entity EVENt — IMEIEI ..ccveeieeieiieeie ettt cssriitee et eesssavie e asssvseee s ssssveneeanns 128\n4.13.9Legal Entity Event — Transformation of a Subsidiary to an International Branch 131\n4.13.10 Legal Entity Event — Acquisition of an International Branch.......................... 134\n4.13.11 Legal Entity Event — Break-up ....ccccccceeeviieeiieiiieee s cciieeeeceviieeessesiieee s sssnieeeeeens 137\n4.13.12 Legal Entity Event — DeMErger....cccuveiivviviieiiiiieeeeeisieeeesssiieeessssneeessssvenneanns 140\n4.13.13 Legal Entity Event — Spin-0ff ......cccccoeiiiiiiie et sie e 142\n4.13.14 Legal Entity Event — Transformation of an International Branch to a Subsidiary\n144\n4.13.15 Legal Entity Event —BankruptCy .....ccccevvvveericiviieenscisiieeesecivieessessvieeesessvveneeeens 147\n4.13.16 Legal Entity Event — INnSOIVENCY.....uveevivviiiiiiiiiiiie e criieeeesssieee e essiieeee e 150\n4.13.17 Legal Entity Event — Liquidation.......ccccceuveeiiiiviieeiiiniieiecssiieeecsssieeeeessieeeeenns 150\n4.13.18 Legal Entity Event — DisSOIULION ......cccccviiiiiiiiiieee s cciiieeecciiieeeseesiieee s eesiieeeeeees 151\n4.13.19 Legal Entity Event — Voluntary Arrangement.........ccccceeveeviveeriecsieeeseesveenneens 151\n4.13.20 Legal Entity Event — Reverse Tak@oVver ......cccoceeeeivvveeieenniieeeinssieeesensnenneenns 154\n4.13.21 Legal Entity Event — Transformation of an Umbrella Fund to a Stand-Alone\n4.13.22 Legal Entity Event — Effects on parent and child relationships...................... 158\n4.13.23 Legal Entity Event — Erroneously introduced Legal Entity Event ................... 160\n4.14 Update of LEI Reference Data other than due to Legal Entity Events ................ 162\n4.15 LEI Record update — Registration information changes..........cccccceeviiiieeni . 162\n4.16 LEI Record update — Reporting Exception changes to Relationship Records......162\n4.17 LEI Record Set update — Entity or Relationship Data changes..........ccccceeeeeeee.. 163\n4.18 LEI Record Set update — Change of fund manager ........ccccoevvvvveievviiiiieeee i 163\n4.19 LEI Record Set update — Transfer......occcvveeviiiiiieiee i csssieee s sieieee s sssineen. 163\n4.20 Registration errors — Exclusivity Violation (duplication)......c...cccccevvveeeieeeen... 167\n4.21 Registration error — Relationship Record or reporting exception is a duplicate 167\n4.22 Registration error — Eligibility violation (invalid LEl issuance) ............................ 168\n4.23 Issue New LEl for an US company incorporated in one state but operating in\nANOTNET oo s e e s s s sanaae e e s s snsssaeeeses LO8\nG State Transition and Validation Rules for Common Data File formats Page 5 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":3843,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.153Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o Iflei:LEIRecord, rr:Relationship or repex:ReportingException is empty, then RecordCount SHALL\nbe 0.\no RecordCount SHALL NOT be negative (less than 0).\n3.7 Extension (applicable to multiple Header Sections and data\nsections)\nlei:Extension\nrr:Extension\nrepex:Extension\nThis Extension element contains any additional elements required to\nextend the Header or data container element.\n~/lei:Extension\n~/rr:Extension\n~/repex:Extension\no Extension elements MAY be included in all Header Sections and several data section elements\n(see corresponding .xsd files for details).\no There are no restrictions on the contents of the Extension element. For this reason, it is\nrecommended to inform recipients which elements to expect here.\nState Transition and Validation Rules for Common Data File formats Page 41 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":909,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.153Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.8 LEI Record\nContains LEI Reference Data including details of the LEI's registration\nwith the ManagingLOU.\n_ /lei:LEIData/lei:LEIRecords/lei:LEIRecord\nThe LEI Record is a container holding all Level 1 Reference Data including Entity Data and details of\nthe LEI's Registration with the ManagingLOU.\no Optional Extension elements MAY be included.\n3.9 LEI Code (context: LEI-CDF)\nThe 1SO 17442 compatible identifier for the Legal Entity described in\nthe Entity section.\n_ /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:LEl\ne The LEI Code SHALL be ISO 17442 compliant.\ne An LElI Code SHALL be used only once (uniqueness).\n¢ Only one LEl per Legal Entity may be reported (exclusivity).\no The LEl issuer SHALL be responsible for checking for duplicate LEls (uniqueness and exclusivity)\nprior to issuing, updating, renewing and transferring an LEl and publishing the LEI Record Set.\nState Transition and Validation Rules for Common Data File formats Page 42 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1060,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.153Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.10 Legal Name\n\n_ The legal name of the Legal Entity.\n\n_ /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:LegalName\n\no LegalName SHALL be the legal name of the entity in a local language and character set commonly\nused in the registration authority or in other authoritative validation sources.\n\n¢ LegalName SHALL be the primary legal name in case of being in a jurisdiction with more than one\nlegal name (e.g., in different languages).\n\n3.11 Other Entity Names\n\n_ lei:OtherEntityNames\n\nAn optional list of other names (excluding transliterations) for the\nLegal Entity.\n\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity\n/lei:OtherEntityNames\n\nThe OtherEntityNames element is a container including one or more other names for the Legal Entity\n\ntogether with a specification of a name type.\n\no The Legal Entity MAY provide an official, registered name for the Legal Entity in another language\nor a translated version of the entity's legal name. However, as far the local registry provides a\ntranslated or transliterated version of the legal name, these SHALL be made available in the\nappropriate element as part of the LEI Record Set.\n\nState Transition and Validation Rules for Common Data File formats Page 43 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1330,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.154Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"¢ Avalue of type OtherEntityName in a file conforming to this standard SHALL include an optional\nlanguage code, permitting OtherEntityName to be repeated as many times as necessary to\nexpress the same name type in multiple languages.\n\n¢ The language code of an OtherEntityName with type ALTERNATIVE_LANGUAGE_LEGAL_NAME\nSHALL NOT be the same as the LegalName's language code.\n\no OtherEntityName with type PREVIOUS_LEGAL_NAME SHALL NOT be the same as the current\nLegalName.\n\no OtherEntityName with type TRADING_OR_OPERATING_NAME SHALL NOT be the same as the\ncurrent LegalName.\n\n3.12 Transliterated Other Entity Names\n\n_ lei:TransliteratedOtherEntityNames\n\nAn optional list of ASClI-transliterated (i.e. Latin- or Romanized)\nrepresentations of names for the Legal Entity.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity\n/lei:TransliteratedOtherEntityNames\n\nThe TransliteratedOtherEntityNames element is a container including one or more transliterated\n\nnames for the Legal Entity together with a specification of the transliteration procedure.\n\no If populated, the TransliteratedOtherEntityNames SHALL include a list of ASClI-transliterated (i.e.\nLatin- or Romanized) representations of names for the Legal Entity in all cases of non-romanized\nLegalName.\n\no The general rules for transliteration SHALL apply (see section 2.9).\n\nState Transition and Validation Rules for Common Data File formats Page 44 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1513,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.156Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.13 Legal Address\nThe address of the Legal Entity as recorded in the registration of the\nLegal Entity in its legal jurisdiction.\n\n_ /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:LegalAddress\n\nThe LegalAddress element is a container including mandatory and optional elements comprising the\n\nentity’s legal address.\n\no LegalAddress SHALL be the address of the entity as recorded in the registration of the entity.\n\ne For an International Branch, LegalAddress SHALL be the address of the entity in the host country.\n\ne Forafund entity, LegalAddress SHALL be a current address provided in the business registry in\nwhich the entity was formed (for funds that are incorporated) or by the financial regulatory\nauthority where the entity is registered (for all other cases). If no such address is provided, a\nregistered address from the fund’s constituting documents SHALL be recorded as LegalAddress. If\nsuch documents are also not available, the registered address of the fund managing entity\nresponsible for the legal affairs of the fund SHALL be recorded as LegalAddress. In this case, a\n“care of” address structure (MailRouting) SHALL be used to signal that the address is one of a\ndifferent entity. See the LEI ROC policy on Fund Relationships and Guidelines for the registration\nof Investment Funds in the Global LEI System?® for details.\n\no If the entity is not registered, LegalAddress SHALL be the address mentioned in any document\nused to validate the existence of the entity, or, in lack of, the entity's declared center of control\n(same as HeadquartersAddress).\n\no The general rules for reporting addresses SHALL apply (see section 2.7).\n\n5 https://www.leiroc.org/publications/gls/roc_20190520-1.pdf\n\nState Transition and Validation Rules for Common Data File formats Page 45 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1901,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.156Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.14 Headquarters Address\n\n_ lei:HeadquartersAddress\n\n_ The address of the headquarters of the Legal Entity.\n\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Entity/lei:HeadquartersAddress\n\nThe HeadquartersAddress element is a container including mandatory and optional elements\n\ncomprising the entity’s headquarters address.\n\n¢ HeadquartersAddress SHALL be the address of the main office or center of control of a company\nor organization.\n\n¢ HeadquartersAddress MAY be the same as the LegalAddress of the Legal Entity.\n\ne For an International Branch, HeadquartersAddress SHALL be the address of the head office.\n\no For afund entity, HeadquartersAddress SHALL be the registered address of the fund managing\nentity. A “care of” address structure (MailRouting) SHALL be used to signal that the address is\none of a different entity.\n\ne For a Government Entity, HeadquartersAddress SHALL be the address of the entity itself or the\naddress of the authorized entity managing the LEI registration on behalf of the Government\nEntity. The address MAY be the same as LegalAddress. If another entity manages the registration,\na “care of” address structure (MailRouting) SHALL be used including the name of the entity\nmanaging the LEI registration.\n\ne For an International Organization with distributed field operations and no discernable main office\nor center of control, HeadquartersAddress SHALL be the location of a secretariat or similar\nadministrative central function.\n\no The general rules for reporting addresses SHALL apply (see section 2.7).\n\nState Transition and Validation Rules for Common Data File formats Page 46 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1723,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.156Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.15 Other Addresses\nAn optional list of other addresses for the Legal Entity, excluding\ntransliterations.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Entity/lei:OtherAddresses\nThe OtherAddresses element is a container including one or more other addresses associated with\nthe Legal Entity, including a specification of the type of address.\n¢ The language code of another address with type ALTERNATIVE_LANGUAGE_LEGAL_ADDRESS\nSHALL NOT be the same as that of the Legal Entity's LegalAddress.\n¢ The language code of any other address of type\nALTERNATIVE_LANGUAGE_HEADQUARTERS ADDRESS SHALL NOT be the same as that of the\nLegal Entity's primary HeadquartersAddress.\no Addresses in alternative languages SHALL describe the same location but SHALL NOT be literally\nidentical across all fields included.\ne The general rules for reporting addresses SHALL apply (see section 2.7).\n3.16 Transliterated Other Addresses\n_ lei:TransliteratedOtherAddresses\n_ An optional list of transliterated addresses for the Legal Entity.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Entity/lei:TransliteratedOtherAddresses\nState Transition and Validation Rules for Common Data File formats Page 47 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1286,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.156Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"The TransliteratedOtherAddresses element is a container including one or more transliterations of\nthe Legal Entity’s addresses.\no The general rules for reporting addresses SHALL apply (see section 2.7).\no The general rules for transliteration SHALL apply (see section 2.9).\n3.17 Registration Authority\n_ lei:RegistrationAuthority\nInformation about the official authority in the Legal Entity's\njurisdiction of legal registration, for example a business registry, and\nthe corresponding identification of the Legal Entity by that official\nsource.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Entity/lei:RegistrationAuthority\nThe RegistrationAuthority element is a container including a mandatory RegistrationAuthoritylD and\nthe optional RegistrationAuthorityEntitylD and OtherRegistrationAuthoritylD. The Legal Entity is\nresponsible to supply its local Registration Authority and identifier. This is for mapping to the local\nRegistration Authority.\no The rules for using GLEIF Registration Authority codes SHALL apply (see section 2.2.3)\nState Transition and Validation Rules for Common Data File formats Page 48 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1220,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.156Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.18 Registration Authority ID\n_ lei:RegistrationAuthoritylD\nThe reference code of the Registration Authority, taken from the\nRegistration Authorities Code List maintained by GLEIF.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity\n/lei:RegistrationAuthority/lei:RegistrationAuthoritylD\no RegistrationAuthoritylD SHALL be populated with a valid code from the Registration Authorities\nlist.\no For Legal Entities that are not registered in a registry, RegistrationAuthoritylD SHALL be\nRA999999.\no For EntityCategory BRANCH RegistrationAuthoritylD SHALL NOT be populated with the value\nRA999999.\no The general rules for Registration and Validation SHALL apply (see section 2.2).\n3.19 Other Registration Authority ID\n_ lei:OtherRegistrationAuthoritylD\nA legacy / historical reference code of a Registration Authority which\nis not yet entered in the Registration Authorities Code List (RA list)\nmaintained by GLEIF, or the designation of an interim register until\nsuch time as an entry from RA list can be delivered.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity\n/lei:RegistrationAuthority/lei:OtherRegistrationAuthoritylD\no OtherRegistrationAuthoritylD MAY be present when RegistrationAuthoritylD is populated.\nState Transition and Validation Rules for Common Data File formats Page 49 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1400,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.156Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o If RegistrationAuthorityID is RA888888, OtherRegistrationAuthoritylD SHALL include the name of\nthe Registration Authority, as submitted in the request sent to GLEIF to add a new code to the RA\nlist (see section 2.2.3).\n3.20 Registration Authority Entity ID\n_ lei:RegistrationAuthorityEntitylD\nThe identifier of the Legal Entity at the indicated Registration\nAuthority. Typically, the identifier of the Legal Entity as maintained by\na business registry in the jurisdiction of legal registration, or if the\nLegal Entity is one that is not recorded in a business registry, the\nidentifier of the Legal Entity in the appropriate Registration Authority.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity\n/lei:RegistrationAuthority/lei:RegistrationAuthorityEntitylD\no If the Registration Authority provides an entity ID, RegistrationAuthorityEntitylD SHALL be\npopulated with the entity ID from the register. If the authoritative source does not provide an\nentity ID, RegistrationAuthorityEntitylD SHALL NOT be included. This applies also, if RA888888 is\nused.\no RegistrationAuthorityEntitylD SHALL be populated, if lei:ValidationSources is\nFULLY_CORROBORTATED or PARTIALLY_CORROBORATED, with following exceptions:\n¢ The Legal Entity category (EntityCategory) is marked as FUND.\no RegistrationAuthorityEntitylD SHALL NOT be populated, if RegistrationAuthorityID is RA999999\nor one of the RA Codes identifying sources known to not providing an entity ID.\nState Transition and Validation Rules for Common Data File formats Page 50 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1634,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.158Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.24 Issue New LEI — Financial institution inthe US ............ccoe il 169\nAbout this Document\nThis document describes Business Rules for the issuance, updating, management and publication of\nLEI Reference Data according to the Common Data File (CDF) formats LEI-CDF 3.1, RR-CDF 2.1 and\nRepex-CDF 2.1.\nChange History\nThis section records the history of all changes to this document.\n2023-03-07 2.7.1 Clarified use of legal form for international branches GLEIF\n(3.21)\n2023-02-09 2.7 Add use cases for corporations and financial GLEIF\ninstitutions in the US (4.23, 4.24)\nProvide additional clarification on existing rules and\nguidelines for branches, funds in formation, and legal\nentity events (3.24, 3.31, 3.40, 3.52, 3.58, 4.2, 4.3, 4.4,\n4.8,4.13.1).\nRemove references which elements have been\nadded/deprecated in the latest CDF transition.\n2022-04-01 2.6 Added chapter 4.13.23 on resolving incorrectly GLEIF\nreported Legal Entity Events\nProvide additional clarification on existing rules and\nguidelines (2.1.2, 2.3.2, 2.7, 3.20, 3.26, 3.27, 3.36, 3.46,\n3.60, 3.61, 4.6, 4.13.1, 4.13.5, 4.13.9, 4.13.17, 4.13.18\nState Transition and Validation Rules for Common Data File formats Page 6 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1297,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.158Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.21 Legal Jurisdiction\n_ lei:Legallurisdiction\nThe jurisdiction of legal formation of the Legal Entity; i.e. where the\nlegal form of the Legal Entity originates.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Entity/lei:Legallurisdiction\no Legallurisdiction SHALL be a country or subdivision code from the GLEIF Accepted Legal\nJurisdictions Code List (https://www.gleif.org/en/about-lei/code-lists/gleif-accepted-legal-\njurisdictions-code-list). As per July 2020, all LEls SHALL be compliant with this list.\no Legallurisdiction SHALL contain the country or region where the Legal Entity Form originates. As\nsuch, the content of Legallurisdiction is linked to the content of LegalForm.\ne A company with a legal form from country A which has its address(es) in country B SHALL have A\nas its Legallurisdiction.\n¢ An International Branch SHALL always have the LegalForm and Legallurisdiction of the Legal\nEntity to which it belongs.\no For an International Organization established by treaties or other specific multinational\nagreements governed by international laws, Legallurisdiction SHALL be one of the following:\no UN, if the entity is the United Nations, one of their specialized agencies or other affiliated\norganizations.\no EU, if the entity is established by a treaty signed by all members of the European Union and\nno other countries.\no XX, in all other cases.\nState Transition and Validation Rules for Common Data File formats Page 51 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1550,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.159Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.22 Entity Category\nIndicates (where applicable) the category of Legal Entity identified by\nthis LEI Record, as a more specific category within the broad\ndefinition given in ISO 17442. These categories are based on Use\nCases specified in LEI-ROC policies, found at\nhttp://www.leiroc.org/list/leiroc_gls/index.htm.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Entity/lei:EntityCategory\n\nEntityCategory contains the general category of certain types of Legal Entities that are subject to\n\nspecial rules within the Global LEI System.\n\no For Legal Entities that are funds, individuals acting in a business capacity or International\nBranches, the EntityCategories of FUND, SOLE_ PROPRIETOR or BRANCH SHALL be assigned,\nrespectively.\n\no For Legal Entities that are Government entities, the EntityCategory\nRESIDENT_GOVERNMENT_ENTITY SHALL be assigned with an appropriate sub-category, where\napplicable.\n\no For organizations established by international agreement that may not be (only) subject to the\nlaws or regulations of the country or countries in which they are located, the EntityCategory\nINTERNATIONAL_ORGANIZATION SHALL be assigned.\n\no For Legal Entities that are not funds, individuals acting in a business capacity, International\nBranches, Government entities or International Organizations, the EntityCategory of GENERAL\nSHALL be assigned .\n\nAn LEI Record SHALL be identified as BRANCH, if:\n\n¢ The Branch is an International Branch as defined, outside of the head office’s jurisdiction. For\npurposes of the LEI-ROC policy document, jurisdiction is synonymous with country and\nInternational Branch is defined as a non-incorporated establishment of a Legal Entity, when this\nestablishment is located in a separate jurisdiction from the jurisdiction in which the head office\nof the (same) Legal Entity is located, i.e., in a host jurisdiction outside of its home jurisdiction.\nUnder this definition, an establishment may consist of a single office or other business premises,\n\nState Transition and Validation Rules for Common Data File formats Page 52 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2164,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.159Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"or of several offices (i.e., a branch network) in different locations of the same host jurisdiction:\neven in the latter case, only one LElI would be issued per host jurisdiction, essentially amounting\nto, one country-one LEI. Unlike foreign subsidiaries of a parent entity, which are separately\nincorporated as separate Legal Entities or organized under the laws of the host jurisdictions, an\nInternational Branch, as defined here, is legally dependent on the (head office) Legal Entity it\nbelongs to and cannot exist without its (head office) Legal Entity;\n\ne The Branch is registered in a publicly accessible local business registry, local regulatory registry or\ntax registry, preferably an RA source;\n\no The Legal Entity the Branch belongs to already has an LEIl so that the LEI of the (head office) Legal\nEntity can always be associated with the LEI of the International Branch in the Global LEI System;\nand\n\no The Reference Data of the International Branch in the LEI system includes a Branch relationship\nlinking the Branch to its (head office) Legal Entity.\n\nAn LEI Record SHALL be identified as FUND, if:\n\n¢ Inline with the governance principles of the Global LEI System, the Legal Entity reports being an\ninvestment fund, defined as a collective investment scheme (or pooled investment) beneficially\nowned by multiple investors and managed on behalf of those investors by an asset manager or\nby the fund itself.\n\n¢ Investment funds or collective investment schemes MAY not always be registered, or MAY be\nsubject to varying degrees of regulation, and there is therefore no single legal or regulatory\ndefinition. Above definition of fund entities SHALL apply to funds incorporated as a company as\nwell as funds established by contract.\n\no The LElissuer SHALL verify that the report of the Legal Entity being a fund is correct. LEl issuers\nare not required to verify whether an entity not reporting itself as a fund is a fund, except\nminimum due diligence including:\n\no whether the name of the fund includes the mention that it is a fund or any equivalent in the\nrelevant language and legal framework;\n\no whether the legal form necessarily means that the entity is a FUND;\n\n* whether the registry used to establish the existence of the entity is specific to funds;\n\no if the LEl of the Legal Entity is the EndNodelD of an ACTIVE relationship with\nRelationshipType IS_FEEDER_TO.\n\nAn LEI Record SHALL be identified as SOLE_PROPRIETOR, if:\n\nState Transition and Validation Rules for Common Data File formats Page 53 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2628,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.159Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"¢ The entity is a type of enterprise that is owned and operated by one person or family\nbusiness (married couple, mothers, fathers, siblings, etc.) and in which there is no legal\ndistinction between the owner’s assets and liabilities and the business entity.\no The person or family business has unlimited personal responsibility for all losses and debts.\n¢ Inseveral countries it would be possible to identify a Sole Proprietor from the business registry\n(RA source); in such cases all Registration Authority information should be incorporated.\nAn LEI Record SHALL be identified as RESIDENT_GOVERNMENT _ENTITY, if:\n¢ The Legal Entity is a non-market producer, part of a central, state or local government, social\nsecurity funds or a non-profit institution (NPI) controlled by government units.\no The definition of Government Entities® in the Global LEl System is in line with the underlying ISO\n17442 standard and further guided by the System of National Accounts (SNA).\no Astate owned, but independent general Legal Entity or Fund not part of or controlled by the\ngovernment SHALL NOT be categorized as RESIDENT_GOVERNMENT_ENTITY but rather as\nGENERAL or FUND, respectively.\nAn LEI Record SHALL be identified as INTERNATIONAL_ORGANIZATION, if:\no The Legal Entity is a non-resident unit, created by international agreement or other\narrangements for the provision of non-market services or financial intermediation at the\ninternational level.\no The special characteristics of an “international organization” as this term is used in the SNA may\nbe summarized as follows:\n¢ The members of an international organization are either national states or other\ninternational organizations whose members are national states; they thus derive their\nauthority either directly from the national states that are their members or indirectly from\nthem through other international organizations.\n\n¢ They are entities established by formal political agreements between their members that\nhave the status of international treaties; their existence is recognized by law in their member\ncountries.\n\n* Because they are established by international agreement, they are accorded sovereign\nstatus; that is, international organizations are not subject to the laws or regulations of the\n\n8 https://www.leiroc.org/publications/gls/roc_20201229.pdf\n\nState Transition and Validation Rules for Common Data File formats Page 54 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2504,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.159Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"country, or countries, in which they are located; they are not treated as resident institutional\nunits of the countries in which they are located.\n¢ International organizations are created for various purposes including, among others, the\n\nfollowing types of activities:\n\ne The provision of non-market services of a collective nature for the benefit of their\nmembers.\n\n¢ Financial intermediation at an international level, that is, channeling funds between\nlenders and borrowers in different countries.\n\n3.23 EntitySubCategory\n\nIndicates and specifies further (where applicable) the sub-category\n(sub-sector) of Legal Entity identified by this LElI Record and already\ncategorized by the EntityCategory field.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Entity/lei:EntitySubCategory\n\nEntitySubCategory contains the sub-category/sub-sector of certain categories of Legal Entities that\n\nare subject to special rules within the Global LEI System.\n\no Legal Entities other than RESIDENT_GOVERNMENT_ENTITY (i.e., GENERAL, FUND, BRANCH,\nSOLE_PROPRIETOR, INTERNATIONAL ORGANIZATION) SHALL NOT declare any subsector or sub-\ncategory.\n\no Legal Entities that are classified as RESIDENT_GOVERNMENT_ENTITY in the EntityCategory field\nSHALL declare its Government subsector, if available and applicable.\n\nFigure 5 provides a schematic overview of the structure of a General Government and sets the\n\nbaseline for the subsector definitions.\n\nState Transition and Validation Rules for Common Data File formats Page 55 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1611,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.159Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"General Government\nCentral Administration\nState Government\nSocial Security\nFunds Local Government\nLocal Local Local Local Local Local\nGovernment Government Government Government Government Government\nAl A2 B1 B2 C1 C2\nLocal Local Local Local Local Local\nGovernment Government Government Government Government Government\nA3 A4 B3 B4 c3 c4\nPublic corporation 1 Public corporation 2 Public corporation 3 Public corporation n\no\n\nFigure 5: Scheme of a General Government\n\nAn LEI Record SHALL be identified as CENTRAL_GOVERNMENT, if:\n\n¢ The central government subsector consists of the institutional units plus non-profit institution\n(NPI) controlled by the central government institutions (paragraph 4.134 of the SNA). Paragraph\n4.135 of the SNA defines central administration as comprising all institutional units that extend\ntheir authority over the entire territory of the country.\n\nAn LEI Record SHALL be identified as STATE_GOVERNMENT, if:\n\no The state government subsector consists of the institutional units that exercise some\ngovernment functions at a level below that of the central government and above that of the\ngovernment institutional units existing at a local level. These are institutional units whose fiscal,\nlegislative and executive authority extends over individual states in which the country, as a\nwhole, may be divided. In some countries, especially small countries, individual states and state\ngovernments may not exist (paragraph 4.141 of the SNA). The state government usually has the\nfiscal authority to levy taxes on institutional units that are resident in or engage in economic\nactivities or transactions within its area of competence (paragraph 4.142 of the SNA).\n\nAn LEI Record SHALL be identified as LOCAL_GOVERNMENT, if:\n\n¢ The local government subsector consists of local governments that are separate institutional\nunits. The scope of their authority is generally much less than that of central government or state\ngovernments, and they may or may not, be entitled to levy taxes on institutional units resident in\n\nState Transition and Validation Rules for Common Data File formats Page 56 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2230,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.159Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"their areas (paragraph 4.145 of the SNA).\n\nAn LEI Record SHALL be identified as SOCIAL_SECURITY, if:\n\ne Social security schemes are social insurance schemes that cover the community as a whole or\nlarge sections of the community and are imposed and controlled by government units. The\nschemes cover a wide variety of programmes, providing benefits in cash or in kind for old age,\ninvalidity or death, survivors, sickness and maternity, work injury, unemployment, family\nallowance, health care, etc. (paragraph 4.124 of the SNA). They can operate at all levels of\nGovernment (paragraph 4.147 of the SNA). When social security schemes are separately\norganized from the other activities of government units and hold their assets and liabilities\nseparately from the latter and engage in financial transactions on their own account, they qualify\nas institutional units that are described as social security funds. However, institutional\narrangements in respect of social security schemes differ from country to country and in some\ncountries they may become so closely integrated with the other finances of government as to\nbring into question whether they should be treated as separate institutional units. (paragraph\n4.125 of the SNA).\n\nIf a Government Entity does not fit the definitions of one of these sub-categories, EntitySubCategory\n\nSHALL NOT be provided.\n\n3.24 Legal Form\n\n_ The legal form of the Legal Entity.\n\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:LegalForm\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:LegalForm\n\n/lei:EntityLegalFormCode\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:LegalForm\n/lei:OtherLegalForm\n\nThe legal form of the Legal Entity is represented by the LegalForm container. It consists of two\n\nelements: EntityLegalFormCode and OtherLegalForm.\n\no EntityLegalFormCode SHALL be taken from the ISO 20275 Entity Legal Form (ELF) Code list\nmaintained by GLEIF.\n\nState Transition and Validation Rules for Common Data File formats Page 57 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2108,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.159Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o If EntityCategory is not BRANCH, the ELF code SHALL have a legal jurisdiction matching the LEI’s\nLegallurisdiction.\no If EntityCategory is BRANCH, LegalForm SHALL be the legal form of the (head office) Legal Entity.\ne For an International Organization, LegalForm SHALL be 9999, the reserved code for jurisdictions\nnot on the ELF code list. OtherLegalForm SHALL include the name of the treaty establishing the\nentity. If a series of treaties or updates of treaties were signed to form the entity, only the latest\none establishing it in its current form SHALL be included.\no The general rules for Entity Legal Form Reporting SHALL apply (see section 2.8).\ne If one of the reserved ELF codes is used, OtherLegalForm SHALL be present.\no If any non-reserved ELF code is used, OtherLegalForm SHALL be omitted.\n3.25 Entity Status\nThe operational and/or legal registration status of the Legal Entity\n(may be ACTIVE, INACTIVE or NULL).\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Entity/lei:EntityStatus\nThe EntityStatus of an LEI Record SHALL indicate the status of the Legal Entity itself. It is linked to\nother data fields related to especially INACTIVE entities or records (e.g., SuccessorLEl,\nRegistationStatus).\no If EntityStatus is set to ACTIVE, the RegistrationStatus SHALL NOT be set to RETIRED.\no Accepted values for the field are:\no ACTIVE: As of the last report or update, the Legal Entity reported that it was legally registered\nand operating.\no INACTIVE: It has been determined that the Legal Entity that was assigned the LEl is no longer\nlegally registered and/or operating, as indicated by a recorded Legal Entity Event.\ne NULL: Providing an ACTIVE or INACTIVE status of the Legal Entity is not applicable .\nState Transition and Validation Rules for Common Data File formats Page 58 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1904,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.160Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o If EntityStatus is set to INACTIVE, the RegistrationStatus SHALL NOT be set to either ISSUED or\nLAPSED and SHALL NOT be PENDING_TRANSFER or PENDING_ARCHIVAL, except for very rare\ncases that require the transfer of an LEI Record representing an inactive Legal Entity.\n\n¢ The EntityStatus is set to NULL in following cases:\n\no The LEl reaches one of the end stages of its lifecycle representing an error — ANNULLED or\nDUPLICATE.\no The LElisissued for a FUND entity in a jurisdiction (e.g., Spain), where the existence of an LElI\nis a prerequisite to be able to register the entity itself (see section 4.3).\n3.26 Entity Creation Date\nThe date on which the Legal Entity was first established, as\nrepresented by ISO 8601 (as defined in ISO 17442).\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/\nlei:EntityCreationDate\n\no The date when the Legal Entity has been created, formed or incorporated SHALL be provided for\nall LEI Record Sets not yet reached an end stage of their lifecycle.\n\n¢ The information SHALL be extracted from the local registry (if applicable and the entity is a\nregistered entity) or from the legal documents provided by the entity (in case of entity supplied\ndata only). This information provides additional value to the LEI Record Set and will simplify the\nefforts with future mapping partners. It will also enable a high-automated process for mapping\nand potential duplicate identification.\n\n¢ The date provided SHALL be in ISO 8601 datetime format with a minimum value 0001-01-\n01T00:00:00.\n\n¢ If only the year and month of the creation are known and no information about the exact day of\nthe month is availble, the LEIl issuer SHALL use the first day of the respective month.\n\n¢ If the entity is a BRANCH, EntityCreationDate SHALL be the date of the creation of the Branch\nitself and not the date of the creation of the (head office) Legal Entity to which it belongs.\n\nState Transition and Validation Rules for Common Data File formats Page 59 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2080,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.160Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.27 Successor Entity\n\n_ One or more Legal Entities that continue or replace this LEI.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Entity/lei:SuccessorEntity\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Entity/lei:SuccessorEntity/lei:SuccessorLEl\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Entity/lei:SuccessorEntity/lei:SuccessorEntityName\n\nThe SuccessorEntity element is a container including one or more successor entities, identified by\n\neither an LEl or by legal name.\n\no The SuccessorEntity container SHALL be used to report the surviving or new LEI Record Set in\ncases of an Exclusivity Violation or when a Legal Entity Event occurred, requiring the provision of\none or more Successor Entity information.\n\no The SuccessorEntity SHALL be identified either by LEl or by LegalName.\n\no If RegistrationStatus is DUPLICATE, SuccessorLEI SHALL include the LEI of the surviving LEI\nRegistration and SuccessorEntityName SHALL NOT be included.\n\no If one of the following Legal Entity Events has been recorded in the LegalEntityEvents section, the\nSuccessorLElI SHALL be provided, in case the successor Legal Entity holds an LEI; and\nSuccessorEntityName SHALL be provided, in case the successor Legal Entity does not hold an LEI:\no DEMERGER\no SPINOFF\no ACQUISITION_BRANCH\no TRANSFORMATION_BRANCH_TO_SUBSIDIARY\no TRANSFORMATION_UMBRELLA_TO_STANDALONE\no BREAKUP\n+ MERGERS_AND_ACQUISITIONS\n\no If one of the following Legal Entity Events involves a successor entity, the SuccessorLElI SHALL be\nprovided, in case the successor Legal Entity holds an LEI; and SuccessorEntityName SHALL be\nprovided, in case the successor Legal Entity does not hold an LEI:\n\nState Transition and Validation Rules for Common Data File formats Page 60 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1838,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.160Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"2021-12-22 2.5 Added use case for change in fund management (4.18). | GLEIF\nProvide additional clarification on existing rules and\nguidelines (2,2,3, 2.8, 3.24, 3.29, 3.33, 3.36, 3.51, 3.61,\n4.2,4.4,4.7,4.13.1,4.13.3,4.13.4, 4.13.5, 4.13.8,\n4.13.9,4.13.13, 4.13.15, 4.13.16, 4.13.19, 4.21)\n\n2021-09-30 2.4 Provide additional clarification on existing rules and GLEIF\nguidelines (3.36, 3.51, 3.53 several use cases in chapter\n4)\n\nReflect changes due to Repex-CDF 1.2 (3.65, 4.14) and\ndeprecation of the Provisional Node Identifier (PNI)\n(2.1.2,2.2.2,3.49,4.1.2,4.8,4.9,4.13.22, 4.18, 4.20)\nIntroduction of RA777777 (2.2.3, 3.44, 3.45, 3.46, 4.6,\n4.7)\n\n2021-06-21 2.3 Provide additional clarification on existing rules and GLEIF\nguidelines (3.20, 3.23, 3.30, 3.46, 3.57, 4.18)\n\n2021-03-08 2.2 Introduced changes due to ROC policy on Government | GLEIF\nEntities and International Organizations (3.22, 3.23,\n3.53,4.6,4.7)\n\nProvide additional clarification on existing rules and\nguidelines\n\n2020-12-17 2.1 Highlight text elements and paragraphs with the CDF GLEIF\nformat version when these become effective\nProvide additional clarification on existing rules and\nguidelines (2.2, 2.3, 3.20, 3.26, 4.1, 4.11)\n\n2020-07-31 2.0 Updated general structure of the document GLEIF\nCombined STVR for Level 1 and Level 2\nUpdated general rules in chapter 2 to clarify existing\nrules and guidelines (2.2, 2.3, 2.7, 2.8, 2.9)\n\nIncluded per element description and rules for relevant\n\nXML elements in chapter 3.\n\nRevised existing and added new Use Cases in chapter 4.\n\nIntroduced changes due to LEI-ROC Fund Relationship\n\npolicy implementation (2.1.2, 3.50)\n\nIntroduced changes due to LEI-ROC Legal Entity Events\n\npolicy implementation (new elements 3.27-3.36)\n\nUpdated description and rules for EntityCategory (3.22)\n\nUpdated description and rules for EntityStatus (3.24)\nState Transition and Validation Rules for Common Data File formats Page 7 of 170\n\n@ Public Version 2.7.1 Final\n\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2036,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.160Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"+ CHANGE_LEGAL_NAME\n+ CHANGE_OTHER_NAMES\n¢ CHANGE_LEGAL_FORM\no BANCRUPTCY\n¢ LIQUIDATION\no If the SuccessorLEl is provided, the SuccessorEntityName SHALL NOT be present and vice versa.\no If the SuccessorLEl is provided, it SHALL NOT have the same LEI as the replaced entity’s LEI\nRecord.\n3.28 Legal Entity Events\n_ lei:LegalEntityEvents\nContainer for a finite number of events specified by the LEI ROC in\nthe life of a Legal Entity that would impact the Reference Data in the\nGlobal LEI System.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity\n/lei:LegalEntityEvents\n¢ The container Legal Entity Events SHALL be provided, when at least one of the Legal Entity Event\ntypes in scope occurred.\no The container SHALL contain at least one Legal Entity Event instance or one Legal Entity Event\nGroup instance.\nState Transition and Validation Rules for Common Data File formats Page 61 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":991,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.160Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.29 Legal Entity Event\n_ lei:LegalEntityEvents\nContainer for a finite number of events specified by the LEI ROC in\nthe life of a Legal Entity that would impact the Reference Data in the\nGlobal LEI System.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity\n/lei:LegalEntityEvents\ne Each Legal Entity Event container SHALL include two to four attributes, associated with event\nstatus and grouping of Legal Entity Events:\no @group_type: This mandatory attribute defines, whether or not this Legal Entity Event is\npart of a group of events. Allowed enumerations:\n\no STANDALONE: Single / standalone Legal Entity Event with no combination of multiple\nevents.\n\no CHANGE_LEGAL_FORM_AND_NAME: Legal Entity Event including change of the legal\nname triggered by change of the legal form.\n\no COMPLEX_CHANGE_LEGAL_FORM: Legal Entity Event including change of the Legal\nEntity status triggered by change of the legal form.\n\ne REVERSE_TAKEOVER: This event is part of a reverse takeover Legal Entity Event.\n\no @event_status: This mandatory attribute defines the status of the Legal Entity Event with\nregard to the event timeline. Allowed enumerations:\n\n* IN_PROGRESS: The Legal Entity Event activity and processing is in progress.\n\no WITHDRAWN_CANCELLED: The Legal Entity Event as announced will not occur.\n\no COMPLETED: The Legal Entity Event activity and processing have been completed as of\nthe LegalEntityEventEffectiveDate.\n\no @group_id: An identifier assigned to link events that are part of the same group of multiple\nor complex events:\n\ne SHALL be the exact same string for all events linked together.\n\ne SHALL be provided for events having a @group_type\nCHANGE_LEGAL_FORM_AND_NAME or REVERSE_TAKEOVER and SHALL NOT be\npopulated for events having a @group_type STANDALONE or\nCOMPLEX_CHANGE_LEGAL_FORM events.\n\nState Transition and Validation Rules for Common Data File formats Page 62 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1989,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.160Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"e @group_sequence_no: A number which indicates the sequence of each Legal Entity Event\nwithin a group of events.\ne SHALL NOT be populated for STANDALONE events.\ne SHALL be provided for event groups with a logical sequence of events, like a\nREVERSE_TAKEOVER event group.\ne SHALL NOT be populated, if the event sequence is not important as all events happen at\nthe exact same time, for example a change in legal name due to a change in legal form\n(event type CHANGE_LEGAL_FORM_AND_NAME).\n¢ The event that happened first SHALL have @group_sequence_no 1 (one), the next 2\n(two), etc. Each @group_sequence_no SHALL be used only once within a group.\n¢ Inorder to describe Legal Entity Events, each Legal Entity Event container SHALL contain the\nfollowing fields:\no LegalEntityEventType\no LegalEntityEventEffectiveDate\no LegalEntityEventRecordedDate\n* ValidationDocuments\n¢ ValidationReference (optional)\no AffectedFields\no LegalEntityEvent elements SHALL NOT be updated.\n¢ Anew LegalEntityEvent element SHALL be created, if an already existing LegalEntityEvent\nchanges its @event_status from IN_PROGRESS to COMPLETED or WITHDRAWN_CANCELLED.\no A LegalEntityEvent with @event_status IN_PROGRESS SHALL NOT be removed in case a\nfollow up event with @event_status COMPLETED or WITHDRAWN_CANCELLED is introduced.\ne A LegalEntityEvent MAY be updated, if only typing errors or similar minor inconsistencies are\nremediated.\nState Transition and Validation Rules for Common Data File formats Page 63 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1592,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.160Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.30 Legal Entity Event Type\n_ lei:LegalEntityEventType\n_ The type of Legal Entity Event.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/\nlei:LegalEntityEvents/lei:LegalEntityEvent/\nlei:LegalEntityEventType\no Legal Entity Event Type SHALL be always provided as part of the descriptive data of a Legal Entity\nEvent\n¢ The following types of Legal Entity Events SHALL be recorded in the Global LEI System as part of\nthe LEI Record Set. Data collection for high priority Legal Entity Events SHALL begin with the\n\nimplementation of LEI-CDF 3.1. Events with a medium or low priority SHALL be collected at a\n\nlater date but MAY also be included earlier.\n\ne High priority Legal Entity Events (to be implemented by 31 March 2022):\n\no CHANGE_LEGAL_NAME: Change in the legal name of the Legal Entity.\n\ne CHANGE_OTHER_NAMES: Change in the trade- or doing business name of the Legal Entity.\n\no CHANGE_LEGAL_ADDRESS: Change in the legal address of the Legal Entity.\n\no CHANGE_HQ_ADDRESS: Change in the Headquarters Address of the Legal Entity.\n\no CHANGE_LEGAL_FORM: Change in the legal form of the Legal Entity.\n\ne ACQUISITION_BRANCH: The acquiring Legal Entity purchases an International Branch entity.\n\no TRANSFORMATION_BRANCH_TO_SUBSIDIARY: The transfer of all of the assets and liabilities\nof a Legal Entity in relation to an International Branch to the new Subsidiary entity in\nexchange for the transfer of securities representing the capital of the Subsidiary entity\nreceiving the transfer.\n\no TRANSFORMATION_SUBSIDIARY_TO_BRANCH: The transfer of all of the assets and liabilities\nof a Subsidiary to an International Branch entity in exchange for the transfer of securities of\nthe Legal Entity to which the Branch belongs, representing the capital of the International\nBranch entity receiving the transfer.\n\no TRANSFORMATION_UMBRELLA_TO _STANDALONE: Change in legal form from a Fund Legal\nEntity structure with one or more than one sub-funds/compartments to a Fund Legal Entity\nstructure without sub-funds/compartments.\n\nState Transition and Validation Rules for Common Data File formats Page 64 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2204,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.161Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o DISSOLUTION: (i) A voluntary termination of operations, (ii) a general assignment for the\nbenefit of the Legal Entity’s creditors or (iii) any other liquidation, dissolution or winding up\nof the Legal Entity (excluding a Liquidity Event), whether voluntary or involuntary.\n\n¢ Medium priority Legal Entity Events (TBD):\n\n» BREAKUP: A break-up is a corporate action in which a single company splits into two or more\nindependent, separately run companies. Regulators also can mandate break-ups of\ncompanies for anti-trust reasons.\n\no MERGERS_AND_ACQUISITIONS: The consolidation of Legal Entities or assets through various\ntypes of financial transactions, including mergers, acquisitions, consolidations, tender offers,\npurchase of assets and management acquisitions.\n\no DEMERGER: Distribution of securities issued by another Legal Entity. The distributed\nsecurities may either be of a newly created or of an existing Legal Entity. For example, spin-\noff, demerger, unbundling, divestment.\n\no SPINOFF: A special case of demerger where the shareholders of the original entity are\ncompensated for the value loss of the original entity via shares of the new entity or via\ndividend.\n\no Low priority Legal Entity Events (TBD):\n\no BANKRUPTCY: Legal status of a Legal Entity unable to pay creditors. Bankruptcy usually\ninvolves a formal court ruling. Securities may become valueless.\n\n¢ LIQUIDATION: Distribution of cash, assets or both of a Legal Entity. Debt may be paid in order\nof priority based on preferred claims to assets specified by the security.\n\no VOLUNTARY_ARRANGEMENT: A procedure that allows a Legal Entity to settle debts by\npaying only a proportion of the amount that it owes to creditors or to come to some other\narrangement with its creditors over the payment of its debts.\n\no INSOLVENCY: The entry of a decree or order by a court or agency or supervisory authority\nhaving jurisdiction in the premises the appointment of a trustee-in-bankruptcy or similar\nofficial for such party in any insolvency, readjustment of debt, marshalling of assets and\nliabilities, or similar proceedings, or for the winding up or liquidation of their respective\naffairs.\n\no ABSORPTION: Absorption is a form of merger where there is a combination of two or more\ncompanies into an 'existing company'. In the case of absorption, only one company survives,\nand all others lose their identity. (The addition of Absorption to the list of Legal Entity Events\ncovered by the policy is under review with the LEI-ROC.)\n\no REVERSE_TAKEOVER: A reverse takeover is the acquisition of a larger, publicly traded\ncompany by a smaller private company. It involves complex series of events including\nacquisition, absorption and name change.\n\nState Transition and Validation Rules for Common Data File formats Page 65 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2896,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.161Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.31 Legal Entity Event Effective Date\n\n_ lei:LegalEntityEventEffectiveDate\n\n_ The date when the Legal Entity Event becomes legally effective.\n\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/\nlei:LegalEntityEvents/lei:LegalEntityEvent/lei:/\nlei:LegalEntityEventEffectiveDate\n\no LegalEntityEventEffectiveDate SHALL provide the date (not considering the time) when the Legal\nEntity Event becomes legally effective, if the date is known or in the past (event_status\nCOMPLETED).\n\no LegalEntityEventEffectiveDate MAY be omitted, if the date is not known (applies only, if the\nevent_status of the Legal Entity Event is IN_PROGRESS or WITHDRAWN_CANCELLED). If the date\nis known for not yet completed Legal Entity Events, LegalEntityEventEffectiveDate SHALL be\nprovided.\n\ne The format SHALL be according to the ISO 8601 standard. The time part of the content SHALL be\nalways '00:00:00' independent of the provided Time Zone.\n\no LegalEntityEventEffectiveDate SHALL be provided as part of the descriptive data of a Legal Entity\nEvent.\n\no LegalEntityEventEffectiveDate SHALL be limited to dates after 0001-01-01T00:00:00.\n\no LegalEntityEventEffectiveDate MAY be equal to LegalEntityEventRecordedDate if the actual\nLegalEntityEventEffectiveDate is not known.\n\nState Transition and Validation Rules for Common Data File formats Page 66 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1437,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.161Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.32 Legal Entity Event Recorded Date\n_ lei:LegalEntityEventRecordedDate\nThe date when the Legal Entity Event was recorded in the Global LEI\nSystem\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/\nlei:LegalEntityEvents/lei:Legal EntityEvent/\nlei:LegalEntityEventRecordedDate\no LegalEntityEventRecordedDate SHALL be always provided as part of the descriptive data of a\nLegal Entity Event.\no LegalEntityEventRecordedDate SHALL provide the date and timestamp when the Legal Entity\nEvent was recorded in the Global LEI System.\no Ifthe event_status is COMPLETED, LegalEntityEventRecordedDate SHALL be equal to, or after the\nLegalEntityEventEffectiveDate.\n3.33 Validation Documents (context: LEI-CDF)\n_ lei:ValidationDocuments\nType of source document(s) used for validating the\nLegal Entity Event.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/\nlei:LegalEntityEvents/lei:Legal EntityEvent/\nlei:ValidationDocuments\no The type of Validation documents used to corroborate the Legal Entity Event SHALL be provided.\ne Currently accepted type of documents to validate Legal Entity Events are:\no ACCOUNTS_FILING: A consolidated financial (accounting) statement, prepared and submitted\nto the relevant authority.\nState Transition and Validation Rules for Common Data File formats Page 67 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1394,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.161Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"¢ REGULATORY_FILING: A regulatory filing providing public information on Legal Entities\nand/or their relationships (e.g.: documents submitted to a (financial) regulator).\ne SUPPORTING_DOCUMENTS: Other documents supporting the validation of Legal Entities\nand/or their relationships (e.g.: business registers or other authoritative sources).\no CONTRACTS: Contract(s) attesting to the validity of Legal Entities and/or their relationships.\no OTHER_OFFICIAL_DOCUMENTS: Other official document(s) attesting to the validity of Legal\nEntities and/or their relationships (e.g.: notarized documents).\n3.34 Validation Reference (context: LEI-CDF)\n_ lei:ValidationReference\nA reference to a specific document or other source used as the basis\nof validation for this Legal Entity Event.\nlei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/\nlei:LegalEntityEvents/lei:Legal EntityEvent/\nlei:ValidationReference\no The content of ValidationReference SHALL contain a reference to a specific document or other\nsource used as the basis of Legal Entity Event Validation for this record.\n3.35 Affected Fields\nA list of LEI Record Set elements that are expected to be updated in\nthe LEI Record Set as a result of a Legal Entity Event.\nlei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/\nlei:LegalEntityEvents/lei:LegalEntityEvent/\nlei:AffectedFields\nAffectedFields is a container element including one or more AffectedField elements.\nState Transition and Validation Rules for Common Data File formats Page 68 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1597,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.161Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o This container SHALL include all relevant changes to the LEI Record Set due to the Legal Entity\nEvent.\n\no This container can only exist within a Legal Entity Event element.\n\n3.36 Affected Field\n\nA single element and its value that is expected to be updated in the\nLEl Record Set as a result of a Legal Entity Event.\nlei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/\nlei:LegalEntityEvents/lei:LegalEntityEvent/\nlei:AffectedFields/lei:AffectedField\n\nEach AffectedField refers to an LEI Record Set element that will be affected by the Legal Entity Event.\n\no AffectedField SHALL include an attribute (@field_xpath), referring to the full Xpath to a single\nelement that is expected to be updated in the LEI Record Set as a result of a Legal Entity Event.\n\no The value of AffectedField SHALL be the expected value of the data element due to Legal Entity\nEvent. Values for Legal Entity Events in progress (@event_status IN_PROGRESS) MAY not be\nalways available, but the LEl issuer SHALL report these elements if available.\n\no For events with @event_status COMPLETED, leading to the introduction of one or more\nSuccessorEntitiy entries, AffectedFields SHALL be provided, presenting the values of the recorded\nsuccessor entities.\n\no If no SuccessorEntity was introduced due to the Legal Entity Event with @event_status\nCOMPLETED or WITHDRAWN_CANCELLED, AffectedFields SHALL NOT be provided.\n\no Expected values for the attribute @field_xpath are:\n\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:LegalName\n\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:OtherEntityNames/lei:OtherEntityNam\ne\n\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:OtherEntityNames/lei:OtherEntityNam\ne@type\n\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:TransliteratedOtherEntityNames/lei:Tr\nansliteratedOtherEntityName\nState Transition and Validation Rules for Common Data File formats Page 69 of 170\n\n@ Public Version 2.7.1 Final\n\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2024,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.161Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:TransliteratedOtherEntityNames/lei:Tr\nansliteratedOtherEntityName@type\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:LegalAddress/*\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:HeadquartersAddress/*\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:OtherAddresses/*\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:TransliteratedOtherAddresses/*\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:Legallurisdiction\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:EntityCategory\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:LegalForm/lei:EntityLegalFormCode\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:LegalForm/lei:OtherLegalForm\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:SuccessorEntity/lei:SuccessorLEl\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:SuccessorEntity/lei:SuccessorEntityNa\nme\no /rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord/rr:Relationship/rr:EndNo\nde/rr:NodelD\no /rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord/rr:Relationship/rr:EndNo\nde/rr:NodeType\no /rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord/rr:Relationship/rr:Relatio\nnshipType\no /[repex:ReportingExceptionData/repex:ReportingExceptions/repex:Exception/repex:Exceptio\nnCategory\no /[repex:ReportingExceptionData/repex:ReportingExceptions/repex:Exception/repex:Exceptio\nnReason\ne For all above mentioned address containers (LegalAddress, HeadquartersAddress,\nOtherAddresses and TransliteratedOtherAddresses) the concrete data elements SHALL be\nprovided.\nState Transition and Validation Rules for Common Data File formats Page 70 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1851,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.161Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Updated description and rules for SuccessorEntity\n(3.26)\nUpdate description and rules for RelationshipStatus\n(3.52)\nDeprecated AssociatedEntity (3.67),\nEntityExpirationDate (3.68) and EntityExpirationReason\n(3.69)\nClarification on branch entities (4.2)\n2018-01-26 1.2 2.2.5 — updated as ELF code list is now available GLEIF\n2.8 - 2\" bullet point updated from\nIf ValidationSources is ENTITY_SUPPLIED_ONLY then\nValidationAuthorityID and ValidationAuthorityEntitylD\nMUST NOT be populated to\nIf ValidationSources is ENTITY_SUPPLIED_ONLY then\nValidationAuthorityID is RA999999\n2.9 — last bullet point: added or RA999999 has been\nentered). In these cases, OtherRegistrationAuthoritylD\nmay provide information on the documents supplied\nby the Legal Entity for Validation.\n3.1 - LegalName: added in the local language and\ncharacter set.\n3.2 — LegalAddress: added This is the jurisdiction of\nlegal formation and registration of the branch entity.\n3.16 — added If the LEI-CDF record is also a head office\nthen the associated branch entities must all be in\nstatus ISSUED following the renewal of the head office\nLEI.\n2017-05-04 1.1 2.2: added included in Originator GLEIF\n2.4: updated\n2.6: replaced relationships with LEls\n2.9: updated\n2.11: removed PENDING\n3.8: added branches\n3.17: added branches\n2016-11-30 1.0 Final version GLEIF\nState Transition and Validation Rules for Common Data File formats Page 8 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1505,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.162Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.37 Initial Registration Date (context: LEI-CDF)\n\n_ lei:InitialRegistrationDate\nThe date of the first LEl assignment, being the date of publication of\nthe identifier and its supporting data record as represented in I1SO\n8601.\n\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Registration/lei:InitialRegistrationDate\n\n¢ InitialRegistrationDate SHALL be set with the date when the LEI Record transits from the internal,\n\nnot published status PENDING_VALIDATION to ISSUED.\n\ne Once set, InitialRegistrationDate SHALL NOT be updated. This applies also when the LEI Record\n\nSet is being transferred to a different LEI issuer.\n\no The InitialRegistrationDate SHALL NOT be later than LastUpdateDate or NextRenewalDate.\n\n3.38 Last Update Date (context: LEI-CDF)\n\n_ Date/time the LEI Record was most recently updated.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Registration/lei:LastUpdateDate\n\n* Any update to an LEl record SHALL be indicated by setting the LastUpdateDate to the date the\n\nupdate occurred.\n\no There SHALL be at least one other field in the record that changed when LastUpdateDate is\n\nupdated.\n\no There SHALL NOT be any update to any other field without also an update to LastUpdateDate.\n\no LastUpdateDate SHALL NOT be earlier than InitialRegistrationDate.\n\no lastUpdateDate SHALL NOT be a date in the future.\n\nState Transition and Validation Rules for Common Data File formats Page 71 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1503,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.162Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.39 Registration Status (context: LEI-CDF)\n_ lei:RegistrationStatus\nThe status of the Legal Entity's LEI registration with the\nManagingLOU.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Registration/lei:RegistrationStatus\n\nThe element RegistrationStatus describes the status of the LEI registration.\n\no If RegistrationStatus is ISSUED, then EntityStatus SHALL be ACTIVE and ValidationSources SHALL\nNOT be PENDING.\n\no If RegistrationStatus is ISSUED, then NextRenewalDate SHALL be greater than or equal to the\nContentDate of the XML file.\n\no If RegistrationStatus is LAPSED, then NextRenewalDate SHALL be earlier than ContentDate.\n\no If the RegistrationStatus is LAPSED, the LEI Reference Data MAY still be updated.\n\no If RegistrationStatus is DUPLICATE, then SuccessorEntity SHALL be populated.\n\no If RegistrationStatus is ANNULLED, then SuccessorEntity MAY be populated.\n\no If the RegistrationStatus is RETIRED, no further updates to Entity sections of registration records\nin these states SHALL occur. Exceptions are allowed for updated information about the correct\nstatus, mapping to new code lists or ensuring high data quality of the record.\n\no MERGED — DEPRECATED .\n\n3.40Next Renewal Date (context: LEI-CDF)\n\n_ lei:NextRenewalDate\n\nThe next date by which the LEI registration should be renewed and\nre-certified by the Legal Entity.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Registration/lei:NextRenewalDate\n\no NextRenewalDate SHALL be later than InitialRegistrationDate.\n\nState Transition and Validation Rules for Common Data File formats Page 72 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1669,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.162Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"* NextRenewalDate SHALL NOT be later than ContentDate plus one year and sixty days.\n3.41 Managing LOU (context: LEI-CDF)\nThe LEI of the LOU that is responsible for administering this LEI\nregistration.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Registration/lei:ManagingLOU\nManagingLOU identifies the LEl issuer currently managing the LEI Record.\n¢ ManagingLOU SHALL be populated with the LEI of the LEl issuer.\n¢ ManagingLOU SHALL be populated with the LEI of a GLEIF Accredited LEl issuer for all LElI Record\nSet files published. Exceptions are allowed only for Candidate LEl issuers during testing and\nonboarding.\n¢ ManagingLOU SHALL be identical to the Originator in the file header for all LEI Record Sets\nuploaded to GLEIF.\n3.42 Validation Sources (context: LEI-CDF)\n_ lei:ValidationSources\nThe level of Validation of the Reference Data provided by the\nregistrant.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Registration/lei:ValidationSources\nThe LEl issuer notes the level of Validation in the Reference Data via the element ValidationSources:\no If ValidationSources is either PARTIALLY_CORROBORATED or FULLY_CORROBORATED then a\nspecific ValidationAuthoritylD SHALL be populated and which SHALL be different from RA999999\nand RA888888. The ValidationAuthorityEntitylD SHALL be populated given the register is\navailable for publication.\nState Transition and Validation Rules for Common Data File formats Page 73 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1533,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.162Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o If ValidationSources is ENTITY_SUPPLIED_ONLY then ValidationAuthoritylD SHALL be either\nRA999999 or RA888888.\no If ValidationSources is set to PENDING, then the LEIl record SHALL NOT be published and is only\nfor internal LOU use.\no The general rules laid out in section 2.2 SHALL apply.\n3.43 Validation Authority\n_ lei:ValidationAuthority\nInformation about the (primary) official authority in the Legal Entity's\njurisdiction of legal registration, for example a business registry, and\nthe corresponding identification of the Legal Entity by that official\nsource used to validate the Legal Entity Reference Data.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Registration/lei:ValidationAuthority\ne The container ValidationAuthority SHALL be provided and the LEl issuer is responsible to supply\nthe related information according to the rules described in section 2.2.\n3.44 Validation Authority ID\n_ lei:ValidationAuthoritylD\nThe reference code of the Registration Authority, taken from the\nRegistration Authorities Code List (RA list) maintained by GLEIF.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Registration/lei:ValidationAuthority\n/lei:ValidationAuthorityID\n¢ ValidationAuthoritylD SHALL be populated with a valid code from the Registration Authorities list\n(see section 2.2).\no For LEI Records that are not validated against a registry, ValidationAuthoritylD SHALL be\nRA999999.\nState Transition and Validation Rules for Common Data File formats Page 74 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1572,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.162Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o For Government Entities and International Organizations, RA777777 SHALL be used in case there\nis no information available in any regular registration authority and Public Legal Documents are\nused instead for partially or fully corroborated records.\n\n3.45 Other Validation Authority ID\n\n_ lei:OtherValidationAuthoritylD\n\nA legacy / historical reference code of a Registration Authority which\nis not yet entered in the Registration Authorities Code List (RA list)\nmaintained by GLEIF, or the designation of an interim register until\nsuch time as an entry from RA list can be delivered.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Registration/lei:ValidationAuthority\n/lei:OtherValidationAuthoritylD\n\no OtherValidationAuthoritylID MAY be present when ValidationAuthoritylID is populated.\n\no If ValidationAuthorityID is RA888888, OtherValidationAuthoritylD SHALL include the name of the\nRegistration Authority, as submitted in the request sent to GLEIF to add a new code to the RA list\n(see section 2.2).\n\no If ValidationAuthorityID is RA777777, OtherValidationAuthoritylD SHALL include the name and\nreference and where possible the link to the documents used for corroboration.\n\nState Transition and Validation Rules for Common Data File formats Page 75 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1364,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.163Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.46 Validation Authority Entity ID\n\n_ lei:ValidationAuthorityEntitylD\nThe identifier of the entity at the indicated Registration Authority.\nTypically, the identifier of the Legal Entity as maintained by a\nbusiness registry in the jurisdiction of legal registration, or if the\nentity is one that is not recorded in a business registry (e.g., one of\nthe varieties of funds registered instead with financial regulators),\nthe identifier of the entity in the appropriate Registration Authority.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Registration/lei:ValidationAuthority\n/lei:ValidationAuthorityEntitylD\n\no If the Registration Authority used for Validation provides an entity ID,\n\nValidationAuthorityEntitylD SHALL be populated with the entity ID from the authoritative source.\n\no If the authoritative source does not provide an entity ID, ValidationAuthorityEntitylD SHALL NOT\n\nbe included.\n\no IfRA777777 or RA888888 is used, the ValidationAuthorityEntitylD MAY be provided depending\n\non the source.\n\n¢ ValidationAuthorityEntityID SHALL NOT be populated, if ValidationAuthoritylD is RA999999 or\n\none of the RA Codes identifying sources known to not providing an entity ID.\n\n3.47 Other Validation Authorities\n\n_ lei:OtherValidationAuthorities\nAn optional list of additional Registration Authorities used by the LEI\nissuer to validate the entity data.\n\n_ {0,1} with {1,n} lei:OtherValidationAuthority included\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Registration/lei:OtherValidationAuthorities\n\ne OtherValidationAuthorities is a container that MAY be included to provide information about\n\nadditional Validation Authorities used for Validation.\nState Transition and Validation Rules for Common Data File formats Page 76 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1838,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.163Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o All subsets in OtherValidationAuthorities MAY repeat the same source as ValidationAuthority in\ncase the source uses different local identifiers for the same legal entity.\no Every subset in OtherValidationAuthorities SHALL be unique within this registration.\no OtherValidationAuthorities SHALL NOT include any subset having ValidationAuthorityID as\nRA999999.\n3.48 Start Node\n_ An LEI for the Legal Entity at the start of a directional relationship.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Relationship/rr:StartNode\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Relationship/rr:StartNode/rr:NodelD\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Relationship/rr:StartNode/rr:NodeType\nThe StartNode identifies the entity which is, where applicable, the child or lower node of a\nhierarchical relationship.\no StartNode/NodelD SHALL be the LEI of the child entity in the relationship.\no StartNode/NodeType SHALL be LEI.\no StartNode/NodelD SHALL be different from EndNode/NodelD.\nState Transition and Validation Rules for Common Data File formats Page 77 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1234,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.163Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.49 End Node\nAn LEl or ISO 17442-compatible ID for the Legal Entity at the end of a\ndirectional relationship.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Relationship/rr:EndNode\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Relationship/rr:EndNode/rr:NodelD\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Relationship/rr:EndNode/rr:NodeType\nThe EndNode identifies the entity which is, where applicable, the parent or higher node of a\nhierarchical relationship.\n¢ EndNode/NodelD SHALL be the LEI of the direct or ultimate accounting consolidating parent\nentity in the relationship.\no EndNode/NodelD SHALL be different from the StartNode/NodelD.\n© EndNode/NodeType SHALL be LEI in case the EndNode/NodelD contains an LEI.\n3.50 Relationship Type\nA unique code designating the specific category of a directional\nrelationship between two Legal Entities.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Relationship/rr:RelationshipType\no RelationshipType SHALL specify relationship between the StartNode and the EndNode.\nCurrently, three use-cases for relationships exist in the Global LEI System:\n1. Accounting Consolidating Parent Relationship:\nState Transition and Validation Rules for Common Data File formats Page 78 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1421,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.163Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o For the direct accounting consolidating parent, RelationshipType SHALL be\nIS_DIRECTLY_CONSOLIDATED_BY\n\ne For the ultimate accounting consolidating parent, RelationshipType SHALL be\nIS_ULTIMATELY_CONSOLIDATED_BY\n\n2. International Branch Relationship:\n\n¢ The RelationshipType SHALL be IS_INTERNATIONAL_BRANCH_OF for a Branch entity when\nconnecting to its head office.\n\nBoth above-mentioned use-cases are mutually exclusive; if an active consolidating relationship is\npresent, there cannot be an active Branch Relationship and vice versa.\n3. Fund Relationships are (see Figure 6) :\n\n¢ RelationshipType SHALL be IS_FUND-MANAGED_BY, if the StartNode is a fund managed by a\nmain management entity in a Fund Management Entity relationship. The EndNode is legally\nresponsible for the constitution and operation of the fund.\n\no RelationshipType SHALL be IS SUBFUND_OF, if the StartNode is a sub-fund to an umbrella\nfund in an Umbrella Structure relationship. The EndNode is a Legal Entity with one or more\nthan one sub-funds/compartments where each sub-fund/compartment has its own\ninvestment objectives, separate investment policies and strategies, segregation of assets,\nseparate investors and which has segregated liability between sub-funds/compartments.\n\no RelationshipType SHALL be IS_FEEDER_TO, if the StartNode is a Feeder Fund, that is (almost)\nexclusively invested in a single other fund in a Master-Feeder Relationship. The EndNode is\nthe Master Fund that has identical investment strategies.\n\n4 \\\nISSUBFWbERTO\nIS_FUND-MANAGED_BY \\\n\\_{/\nFigure 6: Fund Relationship types\n\nState Transition and Validation Rules for Common Data File formats Page 79 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1759,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.163Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.51 Relationship Periods\nA collection of paired beginning and end dates relating to the\nrelationship itself, periods (e.g., accounting cycles) covered by\ndocuments demonstrating the relationship, or the filing date(s) of\nthose documents.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Relationship/rr:RelationshipPeriods\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Relationship/rr:RelationshipPeriods/rr:StartDate\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Relationship/rr:RelationshipPeriods/rr:EndDate\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Relationship/rr:RelationshipPeriods/rr:PeriodType\nRelationshipPeriods contain three elements:\no StartDate: Date the relationship begins\no EndDate: Date the relationship ends\no PeriodType: The kind of relationship period\n¢ The StartDate of a RelationshipPeriod SHALL NOT be later than the EndDate, if provided.\no The StartDate SHALL NOT be later than the Relationship Record’s LastUpdateDate.\no The StartDate SHALL NOT be earlier than the LEI Record’s EntityCreationDate.\no Relationship Records can have multiple RelationshipPeriods simultaneously, but only one at a\ntime for any given PeriodType.\no ARelationshipPeriod SHALL always include StartDate and PeriodType. EndDate is optional and\nSHALL NOT be provided if the period has no defined EndDate or the date is unknown.\no All Relationship Records SHALL include exactly one RelationshipPeriod with PeriodType\nRELATIONSHIP_PERIOD.\nState Transition and Validation Rules for Common Data File formats Page 80 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1716,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.163Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"All changes made during creation (for clarity and reading ease as well as significant changes),\nincrease the version number by 0.1.\nThe approved PID is considered to be the final version and gets version number 1.0.\nState Transition and Validation Rules for Common Data File formats Page 9 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":398,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.163Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o Relationships with RelationshipType IS_DIRECTLY_CONSOLIDATED_BY and\nIS_ULTIMATELY_CONSOLIDATED_BY SHALL include one RelationshipPeriod with PeriodType\nACCOUNTING_PERIOD.\n\no Relationships with RelationshipType IS_INTERNATIONAL_BRANCH_OF MAY include one\nRelationshipPeriod with PeriodType ACCOUNTING_PERIOD.\n\no Relationships with RelationshipType IS_FUND-MANAGED_BY, IS_SUBFUND_OF and\nIS FEEDER_TO SHALL NOT include any RelationshipPeriod with PeriodType\nACCOUNTING_PERIOD.\n\no Relationship Records MAY include one RelationshipPeriod with PeriodType\nDOCUMENT_FILING_PERIOD.\n\nRelationshipPeriod with PeriodType = RELATIONSHIP_PERIOD\n\nIndicates the duration of the relationship itself, regardless of when the relationship was first included\n\nin the Global LEI System. The StartDate would indicate the earliest date at which the relationship\n\nexisted. If that information is not available or exactly known, it SHALL be the earliest date where the\nvalidity of the relationship could be corroborated. Usually, this date will be earlier than the\n\nInitialRegistrationDate of the relationship. For ACTIVE relationships, EndDate SHALL NOT be included,\n\nwhile for INACTIVE relationships, EndDate SHALL be populated with the last date the relationship\n\nexisted. StartDate and, once provided, EndDate would not generally be updated, unless the originally\nrecorded date was incorrect.\n\nRelationshipPeriod with PeriodType = ACCOUNTING_PERIOD\n\nIndicates the time period reflected in the source document (generally distinct from the date of the\n\ndocument) and is intended to indicate the accounting period covered by the most recent Validation\n\ndocuments. The accounting period for relationships based on accounting consolidation SHALL be\nupdated with the latest accounting period during renewals.\n\nRelationshipPeriod with PeriodType = DOCUMENT_FILING_PERIOD\n\nIndicates the date of the document filing or publication. This only applies where the Validation\n\ndocuments are filed or publicly available. The StartDate SHALL be the date of document filing or\n\npublication.\n\nIf the Validation documents also indicate the period over which the filing applies, the EndDate SHALL\n\nbe the end date of this period. Although entities should be encouraged to provide the exact dates\n\nwhen known, start and end dates MAY be approximated by the date of the situation described in the\nfirst accounting statement showing consolidation or the end of consolidation, respectively. For\ninstance, what is sought here is not that the accounting statement used for Validation is for the year\n\n2019, but that the relationship was valid at least as of 31 December 2019.\n\nState Transition and Validation Rules for Common Data File formats Page 81 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2812,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.164Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.52 Relationship Status\n_ rr:RelationshipStatus\nThe status of the Legal Entities' relationship itself: ACTIVE, INACTIVE\nor NULL.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Relationship/rr:RelationshipStatus\no RelationshipStatus SHALL reflect the status of the relationship.\n¢ RelationshipStatus SHALL be ACTIVE if both Legal Entities are operational and the relationship\nbetween them is current and verified.\no RelationshipStatus SHALL be INACTIVE if one of the Legal Entities ceased to exist or the\nrelationship is no longer current.\no RelationshipStatus SHALL be NULL if the RegistrationStatus of the Relationship Record is\nDUPLICATE or ANNULLED .\no RelationshipStatus MAY be NULL in the exceptional case of a fund in formation (see chapter 4.4).\n3.53 Relationship Qualifiers\n_ rr:RelationshipQualifiers\nAny additional qualitative attributes that help to categorize\nthe relationship.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Relationship/rr:RelationshipQualifiers\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord/r\nr:Relationship/rr:RelationshipQualifiers/rr:RelationshipQualifier/rr:Q\nualifierDimension\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord/r\nr:Relationship/rr:RelationshipQualifiers/rr:RelationshipQualifier/rr:Q\nualifierCategory\nState Transition and Validation Rules for Common Data File formats Page 82 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1519,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.164Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Definitions of accounting consolidation and other relationship types could vary by jurisdiction. The\nLegal Entity reports the accounting consolidation, which is verified by the LEl issuer. Available values\nare:\n\no rr:QualifierDimension:\n\ne ACCOUNTING_STANDARD: The accounting standard applied to determine the definition of\ne.g., ultimate or direct accounting consolidating parent for the relationship detailed in this\nRelationshipRecord. The relevant accounting standard is that applicable to the EndNode (the\n\"parent” entity).\n\ne rr:QualifierCategory:\n\no US_GAAP: United States-Generally Accepted Accounting Principles.\n\no IFRS: International Financial Reporting Standard (developed by the International Accounting\nStandards Board — IASB see http://www.ifrs.org)\n\no OTHER_ACCOUNTING_STANDARD: A financial reporting (accounting) standard not otherwise\nlisted in the latest version of the relationship data file format.\n\no GOVERNMENT_ACCOUNTING_STANDARD: Used for entities consolidated under the\nInternational Public Sector Accounting Standard (IPSAS 35) or National Government or\nFederal Government accounting standards specifically developed for Government entities in\ntheir state or local jurisdiction.\n\nThe declaration of the consolidating standards SHALL follow below rules and hierarchies:\n\n* International standards SHALL overrule local GAAPs.\n\no The GOVERNMENT_ACCOUNTING_STANDARD SHALL be used only when both StartNode and\nEndNode are categorized as RESIDENT_GOVERNMENT_ENTITY or\nINTERNATIONAL_ORGANIZATION, respectively.\n\no Entities categorized as RESIDENT_GOVERNMENT_ENTITY SHALL declare direct and ultimate\nparent only by GOVERNMENT_ACCOUNTING_STANDARD; none of the other accounting\nstandards SHALL be used.\n\nState Transition and Validation Rules for Common Data File formats Page 83 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1906,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.164Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.54 Relationship Quantifiers\n_ rr:RelationshipQuantifier\nAny additional quantitative attributes that help to categorize\nthe relationship.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Relationship/rr:RelationshipQuantifiers\n¢ The Quantifier Dimension allows adding quantitative attributes to a relationship, like the\npercentage of shares the parent holds, etc.\n3.55 Initial Registration Date (context: RR-CDF)\nThe date at which the relationship information was first collected by\nthe ManaginglLOU.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Registration/rr:InitialRegistrationDate\no InitialRegistrationDate SHALL be set when the Relationship Data Record transits from the\ninternal, not published status PENDING_VALIDATION to PUBLISHED, analog to the\nInitialRegistrationDate within the context of LEI Data.\no LEl Records for Level 1 and Level 2 Reference Data MAY have a different InitialRegistrationDate,\ndepending on when each record was entered into the Global LEI System.\no Likewise, different Relationship Records for the same child entity MAY have different\nInitialRegistrationDates.\ne Once set, InitialRegistrationDate SHALL NOT be updated. This applies also when the Relationship\nRecords is being transferred to a different LEl issuer.\n¢ The InitialRegistrationDate SHALL not be later than LastUpdateDate or NextRenewalDate.\nState Transition and Validation Rules for Common Data File formats Page 84 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1567,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.164Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.56 Last Update Date (context: RR-CDF)\n\nThe date at which the information was most recently updated by the\nManagingLOU.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Registration/rr:LastUpdateDate\n\n¢ Any update to a Relationship Record SHALL be indicated by setting the LastUpdateDate to the\ndate the update occurred.\n\no There SHALL be at least one other field in the record that changed when LastUpdateDate is\nupdated.\n\no There SHALL NOT be any update to any other field without also an update to LastUpdateDate.\n\no LlastUpdateDate SHALL NOT be earlier than InitialRegistrationDate.\n\no lastUpdateDate SHALL never be a date in the future.\n\n3.57 Registration Status (context: RR-CDF)\n\n_ rr:RegistrationStatus\n\nThe status of the Legal Entity's Relationship Record\n\nregistration with the ManagingLOU.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Registration/rr:RegistrationStatus\n\nThe element RegistrationStatus describes the status of the relationship registration.\n\no If RegistrationStatus is PENDING_VALIDATION, the record SHALL NOT be published in any files\nwith Content Type LOU_FULL_PUBLISHED, LOU_DELTA_PUBLISHED, GLEIF_FULL_PUBLISHED, or\nGLEIF_DELTA_PUBLISHED.\n\no If RegistrationStatus is PUBLISHED, then RelationshipStatus SHALL be ACTIVE, and\nValidationSources SHALL NOT be PENDING.\n\nState Transition and Validation Rules for Common Data File formats Page 85 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1525,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.164Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o If RegistrationStatus is PUBLISHED, then NextRenewalDate SHALL be greater than or equal to the\nContentDate.\no If RegistrationStatus is RETIRED, then RelationshipStatus SHALL be INACTIVE.\n¢ A RegistrationStatus of CANCELLED SHALL NOT be published.\no If RegistrationStatus is LAPSED, then NextRenewalDate SHALL be earlier than ContentDate.\n3.58 Next Renewal Date (context: RR-CDF)\nThe next date by which the relationship information SHALL be\nrenewed and re-certified by the Legal Entity.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Registration/rr:NextRenewalDate\no NextRenewalDate SHALL be later than InitialRegistrationDate.\n¢ The NextRenewalDate for relationships with RelationshipType IS_DIRECTLY_CONSOLIDATED_BY\nor IS_ULTIMATELY_CONSOLIDATED_BY SHALL be the same for the child LEl and the Relationship\nRecords.\nState Transition and Validation Rules for Common Data File formats Page 86 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1025,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.164Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.59 Managing LOU (context: RR-CDF)\nThe LEI of the LOU that is responsible for administering this\nRelationship Record.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Registration/rr:ManagingLOU\nManagingLOU identifies the LEl issuer currently managing the LEI Relationship Records.\n¢ ManagingLOU SHALL be populated with the LEI of the LEl issuer.\n¢ ManagingLOU SHALL be populated with the LEI of a GLEIF Accredited LEl issuer for all LElI Record\nfiles published. Exceptions are allowed only for Candidate LEl issuers during testing and\nonboarding.\n¢ ManagingLOU SHALL be identical to the Originator in the file header for all LElI Records uploaded\nto GLEIF.\n¢ ManagingLOU SHALL be identical to the ManagingLOU in the LEI Record for the child Legal Entity\nrepresented by the StartNode of the relationship.\n3.60 Validation Sources (context: RR-CDF)\n_ rr:ValidationSources\n_ Level of relationship Validation.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Registration/rr:ValidationSources\n¢ ValidationSources SHALL be FULLY_CORROBORATED, if an accounting consolidation relationship\ncan be validated using current and confirmed consolidated financial statements or other\naccepted documents. Fund relationships SHALL be FULLY_CORROBORATED, if the relationship\ncan be validated using regulatory filings to regulators or central banks as well as registers and\ndatabases kept by competent authorities. A fund prospectus vetted by such authority is also\naccepted, even if the source of the document is the fund manager and not the regulator.\nState Transition and Validation Rules for Common Data File formats Page 87 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1762,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.164Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o ValidationSources SHALL be PARTIALLY_CORROBORATED, if the accepted documents have\ndifferent definitions of accounting consolidation or if the documents make it likely that an\naccounting consolidation relationship exists but the confirmed financial statements do not\ninclude this situation, yet.\n\n¢ ValidationSources SHALL be ENTITY_SUPPLIED_ONLY, if the conditions for assigning\nFULLY_CORROBORATED or PARTIALLY _CORROBORATED are not met and the Validation relies\nsolely on unconfirmed documents provided by the Legal Entity. For fund relationships, this also\nincludes a prospectus not (yet) vetted by the authorities.\n\n3.61 Validation Documents (context: RR-CDF)\n\n_ rr:ValidationDocuments\n\nType of source document(s) used for validating the\n\nrelationship.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Registration/rr:ValidationDocuments\n\n¢ The type of Validation documents used to corroborate the relationship SHALL be provided.\n\nCurrently accepted type of documents to validate relationships are:\n\no ACCOUNTS_FILING: A consolidated financial (accounting) statement, prepared and submitted\nto the relevant authority.\n\no REGULATORY_FILING: A regulatory filing providing public information on Legal Entities\nand/or their relationships (e.g.: documents submitted to a (financial) regulator, including a\nfund prospectus made available on the regulator’s web site).\n\ne SUPPORTING_DOCUMENTS: Other documents supporting the validation of legal entities\nand/or their relationships (e.g.: business registers or other authoritative sources, such as\nofficial fund register or databases for regulated fund entities provided by the regulator).\n\no CONTRACTS: Contract(s) attesting to the validity of Legal Entities and/or their relationships.\n\no OTHER_OFFICIAL_DOCUMENTS: Other official document(s) attesting to the validity of Legal\nEntities and/or their relationships (e.g.: notarized documents or a fund prospectus provided\nby the fund manager).\n\ne If ValidationSources is ENTITY_SUPPLIED_ONLY the ValidationDocuments are none of the sources\nadmitted for FULLY_CORROBORATED and PARTIALLY_CORROBORATED.\n\nState Transition and Validation Rules for Common Data File formats Page 88 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2302,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.165Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o If ValidationDocuments is REGULATORY_FILING, the ValidationReference element SHALL be\npresent and contain, if available, the filing URL (including name and full path). The filing URL MAY\ncontain other standard identifiers e.g., DOI (Digital Object Identifier).\n\n3.62 Validation Reference (context: RR-CDF)\n\n_ rr:ValidationReference\n\nA reference to a specific document or other source used as the\nbasis of relationship Validation for this Relationship Record.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Registration/rr:ValidationReference\n\no The content of ValidationReference SHALL contain a reference to a specific document or other\nsource used as the basis of relationship Validation for this record.\n\n3.63 LEI (context: Repex-CDF)\n\n_ The LEI for the Legal Entity which raised this exception.\n\n/repex:ReportingExceptionData/repex:ReportingExceptions\n/repex:Exception/repex:LEl\n\ne SHALL contain the LEI of the entity reporting the exception (i.e.: the child Legal Entity).\n\ne The EntityCategory in the record assigned to this LEI SHALL NOT be BRANCH.\n\n3.64 Exception Category\n\nState Transition and Validation Rules for Common Data File formats Page 89 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1290,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.165Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"A category of mandatory information reporting, beyond the\nminimum required for Legal Entity identification, which the Legal\nEntity declines, giving reasons and references where applicable.\n/repex:ReportingExceptionData/repex:ReportingExceptions\n/repex:Exception/repex:ExceptionCategory\n\nThe ExceptionCategory of a Reporting exception defines whether the exception applies to the\n\nreporting of the direct parent or the ultimate parent.\n\no Relationship Records and Reporting exceptions SHALL be mutually exclusive for the same parent\nreporting (direct vs. ultimate).\n\no If a Reporting exception having ExceptionCategory\nDIRECT_ACCOUNTING_CONSOLIDATING_PARENT is present, no active Relationship Records\nhaving RelationshipType IS_DIRECTLY_CONSOLIDATED_BY SHALL be present.\n\no If a Reporting exception having ExceptionCategory\nULTIMATE_ACCOUNTING_CONSOLIDATING_PARENT is present, no active Relationship Records\nhaving RelationshipType IS_ULTIMATELY_CONSOLIDATED_BY SHALL be present.\n\n3.65 Exception Reason\n\nA single reason provided by the Legal Entity for declining to\nprovide the mandatory report of a specified type of information\n(beyond the minimum Reference Data needed purely for\nidentification of the Legal Entity).\n/repex:ReportingExceptionData/repex:ReportingExceptions\n/repex:Exception/repex:ExceptionReason\n\nThe LEI-ROC has specified scenarios where the child Legal Entity may report it does not have a parent\n\naccording to the definition used or it may decline to provide parent information.\n\nThe LEl issuer MAY also report an exception given the parent does not have an LEI yet. Different\n\nexception reasons apply in each scenario:\n\nState Transition and Validation Rules for Common Data File formats Page 90 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1825,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.165Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"1 Introduction\n\nThe State Transition and Validation Rules (STVR) describe Business Rules and their technical\n\nimplementation for the issuance, updating, management and publication of LEI Reference Data\n\naccording to the Common Data File (CDF) formats.\n\n¢ Rules enforced by the XML schema are documented in the xsd files for LEI-CDF, RR-CDF and\nREPEX-CDF in their latest version.\n\n¢ Rules required in addition to the XML schema definition (also called Business Rules, data\nmanagement rules, STVR) are documented separately here.\n\nNOTE: These Business Rules are written by GLEIF to provide specific steps for the LEl issuers to follow\n\nin producing and quality assuring the LEI data they provide to GLEIF and publish in the Global LEI\n\nSystem.\n\nNOTE: Each CDF data field is presented here with:\n\n¢ Element name\n\no Description or rationale (source) per data element\n\ne Cardinality\n\no The Xpath identifying the unique data field in its CDF XML representation\n\no General rules\n\nNOTE: During implementation and transition periods between versions of the related CDF formats,\n\nthere might be certain descriptions, listing or explanations relevant only for a specific version of the\n\nCDF formats. These could relate to the upcoming version as well as to the retiring version. In order to\n\nmake these differences more visible to the reader, in this document such elements are highlighted\n\nwith the information about the related version. Some examples, but nor limited to these are (added\n\nin LEI-CDF x.x), (updated in RR-CDF x.x), (deprecated in LEI-CDF x.x).\n\n1.1 Terms and Definitions\n\nBranch/International A lead International Branch or International Branch network outside\n\nBranch of the headquarters’ jurisdiction.\n\nBusiness Rule GLEIF’s legal, organizational and technical rules for implementation\nof the LEI-ROC’s high-level policies for LEl data beyond the technical\nrules enforced by the relevant XML schema.\n\nState Transition and Validation Rules for Common Data File formats Page 10 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2093,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.166Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"e Child Legal Entity reports it does not have a parent according to the definition used:\no NATURAL_PERSONS: the child Legal Entity is controlled by (a) natural person(s).\n© NON_CONSOLIDATING: the child Legal Entity is not subject to reporting in consolidated\nfinancial statements.\no NO_KNOWN_PERSON: there is no known person controlling the child Legal Entity (e.g.,\ndiversified shareholding).\no Child Legal Entity reports it does have a parent according to the definition used but this parent\ndoes not yet have an LEI:\n+ NO_LEI\no Child Legal Entity has an accounting consolidation parent relationship but declines to provide\nparent information due to other obstacles:\no NON_PUBLIC for all of the below use cases:\n\ne Obstacles in the laws or regulations of a jurisdiction prevent the child Legal Entity from\nproviding or publishing this information.\n\ne The child Legal Entity reports that the consent of the parent was necessary under the\napplicable legal framework and the parent did not consent or could not be contacted.\n\n¢ Binding legal commitments such as the articles governing the child Legal Entity, or a\ncontract prevent the child Legal Entity from providing or publishing this information.\nThis is distinct from laws or regulations of a jurisdiction that prevent the child Legal\nEntity from providing or publishing information on its parent.\n\no The child Legal Entity has sought to consult the parent entity about the reporting of the\nparent information to the Global LEI System but could not confirm the absence of\ndetriment in a way that can appropriately prevent liability risks for the child Legal Entity\n(or those acting on its behalf) under the applicable legal framework. The disclosure of\nthis information would be detrimental to the child Legal Entity or the relevant parent.\n\no The disclosure of this information would be detrimental to the Legal Entity or the\nrelevant parent. This will include reasons generally accepted by public authorities in\nsimilar circumstances, based on a declaration by the entity.\n\no Restrictions:\n¢ In case a Government Entity (EntityCategory RESIDENT_GOVERNMENT_ENTITY) needs to\ndeclare a reporting exception other than NO_LEI, the reason for it SHALL only be\n\nNO_KNOWN_PERSON.\n\nState Transition and Validation Rules for Common Data File formats Page 91 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2413,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.166Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.66 Exception Reference\n_ repex:ExceptionReference\nReferences of the law, regulation or other element of the legal\nframework to support reason(s) provided by the Legal Entity for\ndeclining to provide information on its parents.\n/repex:ReportingExceptionData/repex:ReportingExceptions\n/repex:Exception/repex:ExceptionReference\no ExceptionReference SHALL include the references of the law, regulation or other element of the\nlegal framework supporting the reason provided by the child Legal Entity for declining to provide\ninformation on its parents.\n3.67 Associated Entity — DEPRECATED\n_ lei:AssociatedEntity\nAnother entity associated with this entity if needed to fully identify\nthis entity or to place it in an appropriate context.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity\n/lei:AssociatedEntity\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity\n/lei:AssociatedEntity@type\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity\n/lei:AssociatedEntity/lei:AssociatedLEl\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity\n/lei:AssociatedEntity/lei:AssociatedEntityName\no The AssociatedEntity itself SHALL be used in instances in which the legal identity of a FUND\ncannot be described sufficiently well by its own LegalName alone.\n¢ The AssociatedEntity element SHALL be used to provide the LEl or name of another entity such as\nan umbrella fund, fund manager or other hierarchically relevant entity.\nThis field has been removed from the LEl Common Data Format to avoid redundancy, as the\ninformation will be consistently provided in the fund relationship related fields.\nState Transition and Validation Rules for Common Data File formats Page 92 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1767,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.166Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.68 Entity Expiration Date — DEPRECATED\n_ lei:EntityExpirationDate\nThe date that the Legal Entity ceased to operate, whether due to\ndissolution, merger or acquisition.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Entity/lei:EntityExpirationDate\nThe element EntityExpirationDate is only supplied if the Legal Entity has ceased to exist or no longer\noperates as a separate Legal Entity.\n¢ EntityExpirationDate SHALL contain the date the entity ceased to exist. If the exact date is not\nknown, the date the Managing LOU was made aware that the entity is no longer active SHALL be\nentered.\no If EntityExpirationDate is present, then EntityExpirationReason SHALL be present.\no If EntityExpirationDate is present, then EntityStatus SHALL be INACTIVE.\no If EntityExpirationDate is not present, then EntityExpirationReason SHALL NOT be present.\no EntityExpirationDate SHALL be provided only after the fact, meaning it SHALL NOT be later than\nContentDate in the header or LastUpdateDate of the record.\nThis field has been removed from the LEl Common Data Format to avoid redundancy, as the\ninformation will be consistently provided in the Legal Entity Events related fields.\n3.69 Entity Expiration Reason — DEPRECATED\n_ The reason that a Legal Entity ceased to exist and/or operate.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Entity/lei:EntityExpirationReason\nThe element EntityExpirationReason is only supplied if the Legal Entity has ceased to exist or no\nlonger operates as a separate Legal Entity.\nState Transition and Validation Rules for Common Data File formats Page 93 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1683,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.166Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o EntityExpirationReason SHALL contain the reason why the entity is no longer active.\n\no If EntityExpirationReason is present, then EntityExpirationDate SHALL be present.\n\n« If EntityExpirationReason is present, then EntityStatus SHALL be INACTIVE.\n\no If EntityExpirationReason is not present, then EntityExpirationDate SHALL NOT be present.\n\nThis field has been removed from the LEl Common Data Format to avoid redundancy, as the\n\ninformation will be consistently provided in the Legal Entity Events related fields.\nState Transition and Validation Rules for Common Data File formats Page 94 of 170\n\n@ Public Version 2.7.1 Final\n\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":702,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.166Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4 Use Cases\nThe following Use Cases provide rules and guidelines for LEI registration and renewal, updates to the\nLEI Record Set due to Legal Entity Events, and the handling of registration errors.\n4.1 Issue New LEI that is not branch, fund, sole proprietor,\ngovernment entity or international organization\nWhen a Legal Entity is requesting a new LEI code, the LEl issuer:\no SHALL check that there is not already an LEI code assigned to the entity (avoiding Exclusivity\nViolations)\ne Assign a unique LEI code (avoiding uniqueness violations)\n¢ Validate and publish at least the following:\n¢ LegalName as stated in the Registration Authority or other official source\ne OtherEntityNames and TransliteratedNames, if applicable\no LegalForm and Legallurisdiction\no Complete LegalAddress and HeadquartersAddress\n¢ TransliteratedAddresses and OtherAddresses, if applicable\no EntityCategory SHALL be GENERAL\no EntitySubCategory SHALL NOT be provided\no EntityStatus SHALL be ACTIVE (specific exceptions for NULL and in very rare cases exceptions\nMAY be granted by GLEIF after reporting explicitly the exact Use Case to GLEIF for directly\nissuing LEls for INACTIVE Legal Entities)\no RegistrationAuthority SHALL be included\n¢ ValidationSources SHALL be included\n¢ ValidationAuthority SHALL be included\no InitialRegistrationDate SHALL be the date the record is initially published\no LastUpdateDate SHALL be equal to InitialRegistrationDate\n¢ NextRenewalDate SHALL NOT be more than one year after InitialRegistrationDate\n¢ ManagingLOU SHALL be the LEI of a GLEIF Accredited LEl issuer\nG State Transition and Validation Rules for Common Data File formats Page 95 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1757,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.166Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"¢ Two Relationship Records, one for the direct and one for the ultimate accounting\nconsolidating parent, SHALL be included, following the general rules for Legal Entity\nrelationship information (see 2.1.2) and the applicable Use Case(s) from chapters 4.1.1, 4.1.2,\n4.1.3 and 4.1.4. Different Use Cases can apply for the direct and ultimate parent.\n\no Relationship Records describing a Branch or fund relationship SHALL NOT be included.\n\n4.1.1 Relationship with a parent Legal Entity with an LEI\n\ne When an LEl is initially issued for a Legal Entity and the child Legal Entity has an accounting\nconsolidating direct and/or ultimate parent relationship, a Relationship Record SHALL be\npublished for each relationship.\n\n¢ Only relationships that are ACTIVE by the time of the registration shall be considered.\n\no The RegistrationStatus SHALL be PUBLISHED and the RelationshipStatus SHALL be ACTIVE.\n\no Relationships that ended prior to the initial registration SHALL NOT be included. Relationships\nthat ended after initial registration SHALL be updated as described in the Use Cases for Legal\nEntity Events (see section 4.13).\n\nWhen the child Legal Entity states having (a) parent(s) that is identified with an LEI, the LEl issuer:\n\n« Validates and publishes (a) Relationship Record(s) with at least the following:\n\no StartNode/NodelD SHALL be the same as the newly assigned LEI of the child Legal Entity.\n\no EndNode/NodelD SHALL be the LEI code already assigned to the parent Legal Entity and\npublished in the Global LEI Repository by the time this record is published.\n\no The RelationshipStatus SHALL be ACTIVE.\n\no RelationshipPeriod with PeriodType RELATIONSHIP_PERIOD SHALL be included with\nStartDate and no EndDate.\n\no RelationshipPeriod with PeriodType ACCOUNTING_PERIOD SHALL be included with StartDate\nand EndDate.\n\no RelationshipPeriod with PeriodType DOCUMENT_FILING_PERIOD MAY be included with\nStartDate and no EndDate.\n\n4.1.2 Relationship with a parent Legal Entity without an LEI\n\nIn the case a child Legal Entity reports an accounting consolidating parent relationship with a Legal\n\nEntity that does not have an LEI, the LEl issuer:\n\no SHALL publish a Reporting Exception Record with the appropriate ExceptionCategory and an\nExceptionReason NO_LEI.\n\no SHALL remove the existing relationship exception of type NO_LEI from the upload file, in case a\npublic relationship record to another LEl is introduced.\n\nState Transition and Validation Rules for Common Data File formats Page 96 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2600,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.166Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"e SHALL not be under an obligation to verify that the provided reason is valid but SHALL respond to\nany challenges of this state.\n4.1.3 No accounting consolidation parent relationship\nIf the Legal Entity reports not having (a) parent(s) according to the definition of accounting\nconsolidation, the LEl issuer:\no SHALL publish a Reporting Exception Record with the appropriate ExceptionCategory and an\nExceptionReason NON_CONSOLIDATION, NATURAL_PERSONS or NO_KNOWN_PERSON.\ne SHALL not be under an obligation to verify that the provided reason is valid but SHALL respond to\nany challenges of this state.\nTypically, LEIs that are pointed as ultimate parent entities exhibit these exception reasons.\n4.1.4 Accounting consolidation parent relationship not reported due to legal obstacles\n(opt-out)\nIf the child Legal Entity states any legal obstacles for providing parent relationship information that\nwould otherwise be included with a Relationship Record, the LEl issuer:\no SHALL publish a Reporting Exception Record with the appropriate ExceptionCategory and an\nExceptionReason NON_PUBLIC.\ne SHALL not be under an obligation to verify that the provided reason is valid but SHALL respond to\nany challenges of this state.\n4.2 Issue New LEI - Branch\nWhen a new LEl is requested for an International Branch, the LEl issuer:\ne SHALL ensure that the entity requesting the LEl is an International Branch of the (head office)\nLegal Entity, to which it belongs\no SHALL verify that the (head office) Legal Entity has an LEI with RegistrationStatus ISSUED.\ne SHALL ensure that the Branch is located in a different country as the (head office) Legal Entity.\no SHALL ensure that no other LEI has been issued to a Branch of the (head office) Legal Entity in the\nsame host country.\no SHALL validate that the Branch is registered in the local Registration Authority.\no SHALL validate and publish at least the following:\no LegalName as stated in the Registration Authority.\no LegalAddress SHALL be the address of the Branch in its host country.\no HeadquartersAddress SHALL be the legal address of the (head office) Legal Entity.\nState Transition and Validation Rules for Common Data File formats Page 97 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2293,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.167Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o EntityCategory SHALL be BRANCH.\no EntitySubCategory SHALL NOT be provided.\no LegalForm SHALL be the LegalForm of the (head office) Legal Entity.\no Legallurisdiction SHALL be the Legallurisdiction of the (head office) Legal Entity.\no ValidationSources SHALL NOT be ENTITY_SUPPLIED_ONLY.\no SHALL publish exactly one Relationship Record with:\ne StartNode SHALL be the new LEI of the Branch.\n¢ EndNode SHALL be the LEI of the (head office) Legal Entity.\no RelationshipType SHALL be IS_INTERNATIONAL_BRANCH_OF.\no RelationshipStatus SHALL be ACTIVE.\no RelationshipPeriod with PeriodType RELATIONSHIP_PERIOD SHALL be included with\nStartDate and no EndDate.\no RelationshipPeriods with other PeriodTypes MAY be included.\ne SHALL NOT publish Reporting Exception Records.\nFigure 7 describes the reporting of Branch entities implementing the concept International Branch\nfor a (head office) Legal Entity. This means that there is only one Branch-LEl issued per host country.\nHowever, this LEI represents all locations and/or offices within the jurisdiction. The (head office of\nthe) Legal Entity decides on and provides the correct Reference Data for all its International\nBranches.\nS\nSNTERNATONALBRANCTERNATONALBRANCHOF\n@ /\nLEIC LEIC LEIC LEIB LEIB LEIB\nLocation 1 Location2 Location 3 Location 1 Location2 Location 3\nFigure 7: Example for Branch relationships\nState Transition and Validation Rules for Common Data File formats Page 98 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1537,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.167Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.3 Issue New LEIl - Fund\n\nWhen a new LEI code is requested for a FUND, in addition to or differing from section 4.1 and section\n2.1.2, the LEl issuer:\n\no SHALL validate and publish at least the following:\n\no LegalAddress is the current address provided in the business registry in which the entity was\nformed (which would generally be the case for funds that are incorporated) or (in other\ncases) the address recorded in the primary Registration Authority of the fund.\n\n¢ HeadquartersAddress is the address of the fund manager.\n\no Legallurisdiction SHALL match the LegalForm of the entity, and MAY in some cases be\ndifferent from the jurisdiction of the LegalAddress.\n\no EntityCategory SHALL be FUND.\n\no EntitySubCategory SHALL NOT be provided.\n\no If the fund entity is in scope of the LEI ROC policy on fund relationships, then it SHALL report\nall mandatory fund relationships. See chapter 2.1.2.\n\n¢ The Validation Authority of a fund SHALL always be the financial regulator registering the\nfund where applicable.\n\no If the fund prospectus is not vetted by authorities, ValidationSources SHALL be\nENTITY_SUPPLIED_ONLY.\n\n¢ In cases where the fund entity is self-managed, the fund entity MAY report a relationship of\ntype IS_FUND-MANAGED_BY, in which the end node of the relationship points to the same\nfund entity (see\n\no Figure 8, LEI F). This is an indication that a fund is self-managed, to distinguish from the\nscenario when a fund has not opted out of reporting a relationship.\n\nFigure 8 provides an example of LEl network including fund relationships. For simplicity and clean\nrepresentation, not all required Relationship Records are provided for the second (LEI D, LEI E, LEI G)\nand third level (LEI H, LEI B, LEI C, LEI | LEI J).\nState Transition and Validation Rules for Common Data File formats Page 99 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1924,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.167Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"LEI H (NOT A FUND) LEI B (NOT A FUND) LEI C (NOT A FUND) LEI I (NOT A FUND) LEIJ (NOT A FUND)\nK IS_DIRECTLY_CONSOLIDATED_BY / IS_ULTIMATELY_T(\\:ONSOLIDATED_BY /\\\nIS_FUND-MANAGED_BY y’cONSOLIDATED_BY ycws%lomeo_gy\n? LEI G (NOT A FUND) LEID - FUND (UMBRELLA) LEI E - FUND (MASTER) T\nIS_DIRECTLY_CONSOLIDATED_BY /K IS_SUBFUND_OF / FEEDER_TO IS_ULTIMATELY_CONSOLIDATED_BY\nIS_ULTIMATELY_CONSOLIDATED_BY % | IS_FEEDER_TO ‘ IS_DIRECTLY_CONSOLIDATED_BY\n/__\\ /\n¥\\O/&F”\"”@:fl/®\nLEI A - FUND LEI F - FUND\nFigure 8: Example of network including fund entities and their relationships\nState Transition and Validation Rules for Common Data File formats Page 100 of 170\nGLEIF) Public Version 2.7.1 Final\n2022-04-01_State-Transition-Validation-Rules_v2.6_final.docx 2023-03-07\n","contentLength":759,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:42:38.167Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"@’ Protect dletto) st\n\nState Transition and\nValidation Rules for\nCommon Data File formats\n","contentLength":90,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.787Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Table of Contents\nY Yo 101 R 4 o TR 0 T YL U] 44 =T 4 Y\nAN | 1o o 1V T ' o TP | ||\n1.1 Terms and Definitions......ccccceeeviiiiiieie it csiieeee s sneee e s s sneeeeessnnnene 10\n1.2 Terminology and Typographical Conventions .........ccccecevveeeeivinineeeeinnnieeneeensiennn 12\n2 Lifecycle and General CoNCePtS.....cccerrueerenirrnecrenrrennceenceenncrnncesnecseneseneeee 14\n2.1 LEIRecord Set Reference Data ......ccccceeeeeiiiieeeeiiiiiicie s csssieeee s ssineeee s sssvvveeeesnnnenn 14\n2.1.1 Legal Entity data (Level 1 data — ‘“Who is WhO') ....cccovevvivicccieeeceecee e, 14\n2.1.2 Legal Entity relationship information (Level 2 data — “Who owns whom’)............ 14\n2.2 Corroboration of LEI Record Set .......ccccvivviiiiiiiiiiiiiieeee e ssieie e s ssiineeeeennn 21\n2.2.1 LEIREGISTIatioN ..ccceeiieeiiiiieie ettt e re e e e e e s s erneeneneeeaneanenes 21\n2.2.2 Validation c...uueeii et ee s srae e s snaees 22\n2.2.3 Application of GLEIF Registration Authorities List ........cccccccevevvieeccciesceeiiieeennn. 25\n2.3 LIf@ CYCIE coeeeee e s e sraae e e s s snnneaeeennn 27\n2.3.1 Registration Status COES .....ccuieiiiiiiiiei ittt ssrreee s seraees 28\n2.3.2 Changes in Registration Status due to Legal Entity Events .......c.cccveeviecviieeeriennen. 30\n2.3.3 Changes in Registration Status when a registration error is resolved.................... 31\n2.4 Registration Status Codes for Transient PUrpOSES......cccccevvvveeeeeriniinieensesiiinieeeennnn 31\n2.5 RENEWAI ciiiiciiiieiee e e s e ae e e snareeesenes 32\n2.6 1SO 3166 Conformance of Address and Jurisdiction Fields.............ccccceeeinnnennnnn. 32\n2.7 AdAress REPOITING ..uuviiiiiiiiiiiieee ettt eee s re e e sraae e ee s s sssaeeee s essaasaaaeesesens 33\n2.8 Entity Legal FOrm RePOItiNg ....cccvvcuuiiiiiiiiiiiieiieciiiiece s esssieeee s sveeeee s ssssvveeeeannnens 34\n2.9 Language, translation and transliteration ..........ccccceceeeiiivi s 35\n3 General State Transition and Validation Rules...........cccccccceeerrreennnnnnne.... 36\n3.1 Header Section (applicable to all files) .....cccceevveeeiieeiiiiieeceecee e 37\n3.2 CONTENT DAt e e e e e s DO\nR I O [ g 7= {1 o -1 (o] TP P TR PUPPPUPPPPPPRPPPOPOPRRRRRC 1o\nK I 1 L= @o | 1= | SO PSP PPPRUPPPPURPRPRPPNC 1 |\n3.5 Delta Start..cccccciiiee e sraeeee s sssnnneesesnsssnnnaeeen e 40\n3.6 ReCOrd COUNL .uviiiieiiiiiiiie sttt esie e e siieeee s s s snnneeessnsnnneesssssssnnnneeen s 40\n3.7 Extension (applicable to multiple Header Sections and data sections) ................41\n3.8 LEIRECOIT ettt s s sttte s sarre e e s ssvive e ae s s s sasbnaesesssnnnanesessnnnnnnenessnes B2\n3.9 LEI Code (context: LEI-CDF)......ccccieieiiiieeiiiiieciiieeessiieessevee e sieeeessvnessssnneessnnneee s 42\n3.10 Legal NAME c.iiiiiie ittt ee s ee s e s sra e e eesssvaneeessssasnnnnessssnnsneeeess B3\n3.11 Other ENntity NAmMES c.uuuiiiiiiiiiieiee ettt svrae e s sssvnneee s s s sainnae e s s snnneeee s 43\nG State Transition and Validation Rules for Common Data File formats Page 2 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":3087,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.787Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Common Data Files Format | The mandatory requirements for the structure and content of Legal\n\n(CDF) Entity Reference Data.\n\nELF code / ELF code list Abbreviation for the ISO 20275: Entity Legal Forms (ELF) code and\ncode list.\n\nExclusivity Violation Registration error where a Legal Entity has more than one LEI.\n\nGeneral Government Consists of institutional units that, in addition to fulfilling their\n\nSector political responsibilities and their role of economic regulation,\nproduce services (and possibly goods) for individual or collective\nconsumption mainly on a non-market basis and redistribute income\nand wealth.\n\nInstitutional Unit An institutional unit is an economic entity that is capable, in its own\nright, of owning assets, incurring liabilities and engaging in economic\nactivities and in transactions with other entities.\n\nInternational Organizations | Non-resident units created by international agreements or other\narrangements for the provision of non-market services or financial\nintermediation at the international level.\n\nLegal Entity Legal person or structure that is organized under the laws of any\njurisdiction (as defined in ISO 17442).\n\nLEl issuer, LOU An entity issuing and managing LEI Records; also referred to as\nManagingLOU, Managing LOU or just LOU (Local Operating Unit).\n\nLEI Record An XML data record in LEI-CDF format detailing one LEl record as\nreported by a Legal Entity to its LOU, and by the LOU to GLEIF.\n\nLEI Record Set An XML data record in CDF format describing one Legal Entity,\nincluding its related relationship information.\n\nRA code / RA list Abbreviation for the GLEIF Registration Authorities (RA) code and\nlist.\n\nReference Data The entity description and registration information recorded in the\nLEI Record Set.\n\nRelationship Record (RR) An XML data record in RR-CDF format detailing one relationship type\nbetween two Legal Entities, as reported by a Legal Entity to its LOU,\nand by the LOU to GLEIF.\n\nState Transition and Validation Rules for Common Data File formats Page 11 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2135,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.787Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"¢ The StartNode of a fund relationship SHALL be a fund entity, categorized by using the correct\nEntityCategory value FUND.\no If the RelationshipType is:\ne IS _SUBFUND_OF, then the EndNode of the relationship SHALL be a fund entity, categorized\nby using the correct EntityCategory value FUND (see\no Figure 8, relationship LEI A -> LEI D).\ne IS_FUND-MANAGED_BY, then the EndNode of the relationship SHALL be:\no afund entity, categorized by using the correct EntityCategory value FUND (see\no Figure 8, relationship LEI F -> LEI F).\ne aregular entity, categorized by using the correct EntityCategory value GENERAL (see\no Figure 8, relationship LEI A -> LEI G).\n* asole proprietor entity, categorized by using the correct EntityCategory value\nSOLE_PROPRIETOR.\ne IS _FEEDER_TO, then the EndNode of the relationship SHALL be a fund entity, categorized by\nusing the correct EntityCategory value FUND (see\no Figure 8, relationship LEI A -> LEI E).\n¢ For fund entities, if the requirement for financial consolidation requirement persists, direct and\nultimate parent entities SHALL be reported (see\no Figure 8, relationships LEI D -> LEI B and LEI C); In general for fund entities apply the same rules\nas described in chapter 2.1.2.\n¢ Fund entities MAY provide exact one Relationship Record of a type IS_SUBFUND_OF and\nIS_FEEDER_TO.\n¢ Reported ACTIVE fund relationships SHALL at least provide one RelationshipPeriod with\nPeriodeType RELATIONSHIP_PERIOD with a StartDate but no EndDate. Additional\nRelationshipPeriods MAY be included, if applicable (see 3.51).\n¢ Independent of what role in a relationship a fund entity plays (e.g., sub-fund, umbrella fund), the\nLegalName of the entity SHALL be its standalone LegalName and SHALL NOT include\nconcatenation of any related entities; in cases where an ‘Umbrella Structure’ relationship is\npresent, GLEIF will represent the names of the both the fund and the umbrella entities on LEI\nSearch as has been specified in the LEI-ROC policy.\n4.4 Issue New LEI - Fund in formation\nIn some jurisdictions or financial markets, fund entities require an LEl in order to register the fund or\nset up clearing accounts, before they become active from a legal perspective. In such cases, LEI\nState Transition and Validation Rules for Common Data File formats Page 101 of 170\nGLEIF Public Version 2.7.1 Final\n2022-04-01_State-Transition-Validation-Rules_v2.6_final.docx 2023-03-07\n","contentLength":2400,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.787Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"issuers SHALL follow these guidelines for setting up and maintaining the LEI Record for a not yet\n\nactive FUND:\n\ne The LEl issuer SHALL take due diligence to verify that the fund meets or will shortly meet the\nrequirements for entering the process requiring the LEI.\n\no The LEl issuer SHALL create and validate an LEI Record for the fund, as described above, including\nall relevant relationships and based on the available information and with the following special\nrules:\n\no EntityStatus SHALL be temporary set to NULL.\no EntityCreationDate SHALL NOT be populated.\no If afund relationship is introduced:\no RelationshipStatus SHALL be temporary set to NULL.\no RegistrationStatus of the relationship record SHALL be PUBLISHED.\ne StartDate of the RelationshipPeriod with PeriodType RELATIONSHIP_PERIOD SHALL NOT be\npopulated.\n\no During the setup of the fund, the LEl issuer SHALL work with the Legal Entity to keep the LEI\nRecord up to date with any Reference Data changes (e.g., a change in the name of the fund) and\nupdates the LEI Record Set accordingly. The LEl issuer SHALL be especially alert to the situation\nwhen the fund becomes a legally active entity, or the fund registration process is cancelled or\nwithdrawn.\n\n¢ If the fund becomes legally active, the LEl issuer SHALL update the LEI Record:\n\no EntityStatus SHALL be ACTIVE.\n\no EntityCreationDate SHALL be the date the legal status was achieved.\n\no If applicable, StartDate of the RelationshipPeriod with PeriodType RELATIONSHIP_PERIOD\nSHALL be the date the date the legal status was achieved.\n\no If the fund registration process is cancelled or withdrawn, the LEl issuer SHALL update the LEI\nRecord:\n\no RegistrationStatus of the LEI Record Set SHALL be ANNULLED.\n\no LElissuers SHALL monitor LEI Records for funds in formation closely and SHALL NOT keep them\nfor much longer in an uncertain state as it usually takes to register a fund in that jurisdiction.\n\nState Transition and Validation Rules for Common Data File formats Page 102 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2109,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.787Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o After the official registration of the fund entity is completed, the LEI Record Set SHALL be\nupdated accordingly.\n\n4.5 Issue New LEI - Sole proprietor\n\nWhen a new LEl is requested for a Sole Proprietor, in addition to or differing from section 4.1, the LEI\n\nissuer:\n\no SHALL ensure that the Legal Entity is registered in a Registration Authority\n\no SHALL validate and publish at least the following:\n\no RegistrationAuthorityID different from 'RA999999' and RegistrationAuthorityEntity|D SHALL\nbe included.\n\no EntityCategory SHALL be SOLE_PROPRIETOR.\n\no EntitySubCategory SHALL NOT be provided.\n\no LegalForm SHALL be a legal form applicable to Sole Proprietors in that jurisdiction.\n\no ValidationSources SHALL NOT be ENTITY_SUPPLIED_ONLY.\n\n4.6 Issue New LElI — Government entity\n\nWhen a new LEl is requested for a Government Entity as defined in chapters 3.22 and 3.23, in\naddition to or differing from section 4.1, the LEl issuer:\n\no SHALL validate and publish at least the following:\n\n+ EntityCategory SHALL be RESIDENT_GOVERNMENT_ENTITY.\n\no EntitySubCategory SHALL be CENTRAL GOVERNMENT, STATE GOVERNMENT, LOCAL\nGOVERNMENT or SOCIAL SECURITY, as applicable. If none of these sub-categories applies,\nEntitySubCategory SHALL NOT be provided.\n\n¢ If the Government Entity is registered in a registry or other authoritative source listed in the\nRA Code list in that country or jurisdiction, RegistrationAuthority SHALL be included\nrespectively and ValidationSources SHALL NOT be ENTITY_SUPPLIED_ONLY (unless the\nreserved code RA888888 is used to identify the authoritative source).\n\no If the Government Entity is not registered, but referred to in laws, regulations or decrees\nmade public by competent authorities, these public legal documents SHALL be used for\nvalidation and ValidationSources SHALL be either FULLY_CORROBORATED or\nPARTIALLY_CORROBORATED, depending on the extend of data elements validated against\nthat source. In this case RegistrationAuthoritylD RA999999 and ValidationAuthoritylD\nRA777777 SHALL be used and the document reference SHALL be added in the field\nOtherValidationAuthorityID.\n\nState Transition and Validation Rules for Common Data File formats Page 103 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2293,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.787Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o LegalAddress SHALL be the address recorded in the register or other authoritative source, if\nthe Government Entity is registered, or the official seat of the Government Entity as defined\nin their jurisdiction.\n\no HeadquartersAddress SHALL be the address of the Government Entity or the address of the\nauthorized entity managing the LEI registration on behalf of the Government Entity. The\naddress MAY be the same as LegalAddress. If another entity manages the registration,\nHeadquartersAddress SHALL include a ‘care-of’ part including the name of the entity\nmanaging the LEl registration.\n\no If the Government Entity has a dedicated legal form in the local jurisdiction according to the\nELF Code list, EntityLegalForm SHALL be included. If not, the appropriate reserved code (8888\nor 9999) SHALL be used together with a fitting descriptive term in the OtherLegalEntityForm\nfield.\n\n* If the Government Entity is declaring a direct and/or ultimate parent, the accounting\nstandard SHALL be GOVERNMENT_ACCOUNTING_STANDARD and the parent entity SHALL be\ncategorized as RESIDENT_GOVERNMENT_ENTITY as well. If no direct and/or ultimate parent\nis declared, a Reporting Exception with ExceptionReason NO_KNOWN_PERSON SHALL be\nincluded.\n\no If the Government Entity has a direct and/or ultimate parent that does not have an LEl, a\nReporting Exception with ExceptionReason NO_LEI SHALL be included.\n\nIf an LEI has been issued to a Government Entity prior to the implementation of LEI-CDF 3.1, the LEI\nissuer SHALL adapt the record in accordance with above rules during the next renewal at the latest.\nNote: Legal entities related to the European Union or related bodies SHALL NOT be categorized as\nGENERAL or RESIDENT_GOVERNMENT_ENTITY but rather as INTERNATIONAL_ORGANIZATION.\n4.7 Issue New LEI — International organization\n\nWhen a new LEl is requested for an International Organization as defined in chapter 3.22, which is\nnot organized in the specific legal form of a jurisdiction, in addition to or differing from section 4.1,\nthe LEl issuer:\n\no SHALL validate and publish at least the following:\n\no EntityCategory SHALL be INTERNATIONAL ORGANIZATION.\n\no EntitySubCategory SHALL NOT be provided.\n\n¢ HeadquartersAddress SHALL be the main base of operations or, in case most employees work\nin distributed field operations, the location of a secretariat or similar administrative central\nfunction.\n\n¢ The concept of LegalAddress as defined in the GLEIS does not apply to International\nOrganizations. LegalAddress SHALL be the same as HeadquartersAddress.\n\nState Transition and Validation Rules for Common Data File formats Page 104 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2731,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.788Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o If the RA Code list includes an authoritative source for International Organizations that can\nbe used to validate the data, that RA Code SHALL be included as RegistrationAuthority and\nValidationAuthority. In case the entity is not registered in any public registry, RA999999\nSHALL be used for RegistrationAuthoritylD. If there are also no Public Legal Documents\navailable that can be used to validate the data, RA999999 SHALL also be used as\nValidationAuthoritylD.\n\no ValidationAuthoritylD SHALL be RA777777 in case there is no information available in any\nregular registration authority and Public Legal Documents are used instead.\n\no AsInternational Organizations are established by treaties or other specific multinational\nagreements governed by international law, the concept of legal jurisdiction does not apply as\nfor other entities established under a national law. Legallurisdiction SHALL be the one of the\nfollowing:\n\no UN, if the entity is the United Nations, one of their specialized agencies or other\naffiliated organizations.\n\no EU, if the entity is established by a treaty signed by all members of the European Union\nand no other countries.\n\no XX, in all other cases.\n\no LegalForm SHALL be 9999, the reserved code for jurisdictions not on the ELF code list.\nOtherlLegalForm SHALL include the name of the treaty establishing the entity. If a series of\ntreaties or updates of treaties were signed to form or change the International Organization,\nonly the latest one establishing it in its current form SHALL be included.\n\no If the International Organization is declaring a direct and/or ultimate parent the parent entity\nSHALL be categorized as INTERNATIONAL_ORGANIZATION as well. If no direct and/or\nultimate parent is declared, a Reporting Exception with ExceptionReason\nNO_KNOWN_PERSON SHALL be included.\n\nIf an LEI has been issued to an International Organization prior to the implementation of LEI-CDF 3.1,\nthe LEl issuer SHALL adapt the record in accordance with above rules during the next renewal at the\nlatest.\n4.8 LEI Record Renewal\nIf a Legal Entity renews its LEI Record (see 2.5 Renewal above), the LEl issuer:\no SHALL validate that the Legal Entity is operational.\no SHALL validate the LEI Reference Data including all updates provided by the Legal Entity.\nState Transition and Validation Rules for Common Data File formats Page 105 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2470,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.788Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o SHALL validate that all reported ACTIVE relationships are still current and update the dates in\nperiods with PeriodType ACCOUNTING_PERIOD and DOCUMENT _FILING_PERIOD accordingly, if\npresent; if one or more relationships are no longer current, the Use Case 4.13.22 applies.\n\ne For a Fund entity, SHALL validate that all reported ACTIVE fund relationships (RelationshipType\nIS_ FUND-MANAGED_BY, IS SUBFUND_OF and IS_FEEDER_TO) are still current and update the\ndates in periods with PeriodType ACCOUNTING_PERIOD and DOCUMENT_FILING_PERIOD\naccordingly, if present; if one or more relationships are no longer current, the Use Case 4.13.22\napplies.\n\no SHALL check, if a parent without LEI (Exception reason NO_LEl) can be replaced by an LEI\nrelationship (see Use Case 4.9).\n\no SHALL check with the Legal Entity, if a reported exception due to legal obstacles still applies and\nreplace with a new Relationship Record if it is no longer valid.\n\ne SHALL set a new NextRenewalDate not more than 12 months after the current NextRenewalDate\nor the date of last Validation of the record, whichever is later; this applies to the Entity Data as\nwell as all ACTIVE Relationship Records.\n\ne For a Branch entity, SHALL ensure that the LEI Record of the (head office) Legal Entity has\nRegistrationStatus ISSUED; the Branch LElI Record SHALL NOT be renewed, if the\nRegistrationStatus of its head office LAPSED.\n\n4.9 LEI Record update — Parent Legal Entity without an LEIl requests\n\nan LEI\n\nThis Use Case applies where a parent without an LEI requests an LEI. As soon as the child Legal Entity\n\nis aware of this information, it needs to inform its LEIl issuer. The LEl issuer of the child entity:\n\no SHALL create the applicable Relationship Records(s) according to Use Cases 4.1.1.\n\no SHALL remove the NO_LEI Reporting exception record(s) from publication.\n\n4.10 LEI Record update — Relationship Record changes to Reporting\n\nException\n\nThis Use Case applies where the child Legal Entity reports a Reporting Exception after initially\n\ndeclaring a relationship. The LEl issuer:\n\ne SHALL annul the Relationship Record in case it was entered erroneously in the system.\n\no SHALL retire the Relationship Record in case the relationship for instance expired.\n\nState Transition and Validation Rules for Common Data File formats Page 106 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2418,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.788Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o In either case, the LOU SHALL continue publishing the ANNULLED/RETIRED Relationship\nRecord(s).\n\no SHALL create a new Reporting Exception and publish it.\n\n4.11 Lack of renewal — Legal Entity\n\nIf a Legal Entity does not renew its LElI Record (see Use Case 4.8), with reaching the\n\nNextRenewalDate, the LEl issuer:\n\no SHALL check with the registration and/or Validation Authority for the given Legal Entity (if\navailable), whether the entity is still active. If the Legal Entity stopped operations, then the rules\nfor retiring an LEIl apply here, or if applicable, the details of a corresponding Legal Entity Event.\n\nThe fact that an International Branch’s LEI Record is LAPSED SHALL NOT allow for the issuance of a\n\nsecond LEI Record for a Branch in the same host jurisdiction.\n\n4.12 Lack of renewal — Related Legal Entity including head offices,\n\nfund managers, umbrella and master funds\n\nIf the LEl Record of a related Legal Entity (the EndNode of an active relationship) is not renewed, all\n\nactive accounting consolidating, Fund Management Entities, Umbrella Structures and Master-Feeder\n\nRelationship Records having this entity’s LEl as EndNodelD SHALL NOT be updated, if the lack of\n\nrenewal of the parent Legal Entity is the only change.\n\nIf the parent Legal Entity is the head office of a Branch entity, the LEl issuer of the Branch SHALL set\n\nthe Branch’s LEI Record, including the Relationship Records, to LAPSED (see section 4.6). This SHALL\n\nbe ensured by the Branch LEI Record having the same NextRenewalDate as the head office LElI\n\nRecord, whether or not both records are managed by the same or by different LEIl issuers and\n\nregardless of any renewal request submitted by the Branch entity but not by the head office.\n\n4.13 Update of LEI Reference Data due to Legal Entity Events\n\nThe Reference Data of an LEI Record may change due to Legal Entity Events. The LEl issuer is\n\nresponsible to verify changed Reference Data. If the LEl issuer is ultimately unable to verify the\n\nchanged Reference Data, the Validation Sources SHALL change to PARTIALLY CORROBORATED or\n\nENTITY_SUPPLIED_ONLY.\n\nWhenever an element of the Reference Data is updated, the respective LastUpdateDate (LEI Record\n\nor Relationship Records) SHALL be updated with the current date and time as well.\n\nIf LEI Reference Data is updated to just correct an error or add missing data to an element associated\n\nwith Legal Entity Events (e.g., LegalName, LegalAddress, EntityLegalForm), but the Legal Entity itself\n\ndid not change, no Legal Entity Event SHALL be recorded together with the reference data update.\n\nState Transition and Validation Rules for Common Data File formats Page 107 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2774,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.788Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Legal Entity Events can occur as\n\n¢ Single Standalone events (e.g., an address change)\n\n¢ Sequence of Standalone events (e.g., a change in legal name after a merger or demerger)\n\n¢ Standalone Events that occur simultaneously (e.g., a change in legal name in the course of an\nabsorption)\n\ne Grouped events that happen at the same time (e.g., a change in legal form that also changes the\nlegal name)\n\ne Grouped events in a logical succession (e.g., reverse take-over).\n\n4.13.1 Legal Entity Event — Event timeline and status\n\nSome events MAY be able to be confirmed officially before the event becomes legally effective. For\n\nother events, becoming legally effective will be the only binding confirmation for the event. There\n\nMAY be cases where a Legal Entity Event has been confirmed officially but later will be withdrawn or\n\ncancelled before becoming legally effective.\n\nTo capture different timelines and statuses, each Legal Entity Event has an attribute defining the\n\nstatus of the event (see section 3.29):\n\no @event_status SHALL be IN_PROGRESS, if the Legal Entity Event is confirmed by an official\nsource (which could be the Legal Entity itself) but has not become legally effective yet. Not all\nevents MAY be able to be confirmed and recorded in the Global LEI System before the\nLegalEntityEventEffectiveDate.\n\no LegalEntityEventEffectiveDate SHALL be a future date (if the effective date is known) or\nSHALL be omitted (if the date is unknown).\n\no All provided AffectedFields SHALL include the values of the LEI Reference Data as expected to\nchange as a result of a completed Legal Entity Event.\n\n¢ The values provided in the attribute @field_xpath of the AffectedFields element SHALL be as\nlisted in section 3.36.\n\no @event_status SHALL be COMPLETED, if the Legal Entity Event is confirmed and legally effective.\no LegalEntityEventEffectiveDate SHALL be present and earlier or equal to\n\nLegalEntityEventRecordedDate.\n\n@event_status SHALL be WITHDRAWN_CANCELLED, if an event has been reported with\n\n@event_status IN_PROGRESS but has been determined to not be completed due to withdrawal or\n\ncancellation. This status SHALL be used only when it is confirmed that the event will not happen —a\n\ndelay past an expected effective date SHALL NOT result in a cancellation. Figure 9 gives further\n\ndetails on the application of event timelines.\nState Transition and Validation Rules for Common Data File formats Page 108 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2529,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.788Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"@event_status WITHDRAWN_CANCELLED SHALL also be used to cancel events that have been\npublished in the LEI Record by mistake. In this case the event with @event_status\nWITHDRAWN_CANCELLED SHALL have the exact same reference data as the erroneously introduced\nevent with @event_status COMPLETED with the exception of the LegalEntityEventRecordedDate.\nLegalEntityEvent:\no @entity_status:\nWITHDRAWN_CANCELLED\no LegalEntityEventRecordedDate:\ne 2020-06-01T00:00:00+02:00\n@event_status: IN_PROGRESS\n@event_status: WITHDRAWN_CANCELLED\nLegalEntityEvent:\no @entity_status: IN_PROGRESS\nLegalEntityEventEffectiveDate:\n: & y @event_status: COMPLETED\no 2020-11-20T00:00:00+02:00\no LegalEntityEventRecordedDate: LegalEntityEvent:\no 2020-04-20T00:00:00+02:00\no @entity_status: COMPLETED\n¢ LegalEntityEventEffectiveDate: 2020-11-\nAffectedFields: 20T00:00:00+02:00\no Expected attribute values that will o LegalEntityEventRecordedDate: 2020-\nbe effective on November 20, 2020. 12-05T00:00:00+02:00\nFigure 9: Application of event timeline and event status\n4.13.2 Legal Entity Event — Legal Name changes\nThis Use Case only applies where the legal name changes and the Legal Entity remains an operating\nentity. This event applies to all entity categories. For cases where the LegalName changed due to a\nchange of LegalForm, see Use Case 4.13.5.\nThe LEl issuer:\ne SHALL update LegalName accordingly, as recorded by an official Registration Authority.\no SHALL create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be omitted.\nState Transition and Validation Rules for Common Data File formats Page 109 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1797,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.788Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be CHANGE_LEGAL NAME.\no LegalEntityEventEffectiveDate SHALL be the date the change in LegalName becomes effective\nin the Legal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no If @event_statusis IN_PROGRESS, the LEl issuer SHALL provide information regarding the\nAffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide lei:LegalName\ne SHALL provide lei:OtherEntityNames\no MAY provide lei:TransliteratedOtherEntityNames\no MAY provide lei:SuccessorEntity\ne SHALL include a new OtherEntityName with OtherEntityNameType PREVIOUS_LEGAL_NAME.\no SHALL update OtherEntityName with OtherEntityNameType\nALTERNATIVE_LANGUAGE_LEGAL_NAME, if necessary.\no SHALL update TransliteratedOtherEntityNames, if necessary.\nIf the change of the Legal Entity name is due to the formation of a new Legal Entity, then a new LEI\nSHALL be issued for the new Legal Entity (see sections 4.1 and 4.3) and the SuccessorEntity /\nSuccessorlLEl field of the old LEI Record SHALL be updated with the new LEI (see sections 4.13.22).\nState Transition and Validation Rules for Common Data File formats Page 110 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1355,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.788Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Reporting Exception An XML data record in REPEX-CDF format detailing the reported\nRecord (Repex) exception for not reporting a relationship type in a relationship\nrecord, as reported by a Legal Entity to its LOU, and by the LOU to\nGLEIF.\nSystem of National The System of National Accounts (SNA) is the internationally agreed\nAccounts (SNA) standard set of recommendations on how to compile measures of\neconomic activity. The SNA defines resident Government Entities as\nnon-market producers, part of the central, state or local\ngovernment, social security funds or non-profit institutions (NPI)\ncontrolled by government units.\n(https://unstats.un.org/unsd/nationalaccount/sna.asp)\nSubsidiary A Legal Entity controlled by a holding company.\nTransition Rule A rule stipulating what LOUs, GLEIF and Legal Entities must do when\nan LEI Record Set changes from one allowed state to another.\nUse Case A specific operation scenario which applies one or more Business\nRules.\nValidation Ensures complete, reasonable, sensible data within acceptable\nboundaries by checking the data that is being entered.\nVerification Entered data matches exactly the Validation source.\n1.2 Terminology and Typographical Conventions\nWithin this document, the terms, as will be SHALL and MAY, are to be interpreted as specified in\nAnnex G of the ISO/IEC Directives, Part 2, 2001, 4th edition:\nSHALL (NOT) Requirement\nMAY Permission / Possibility\nWhen used in this way, these terms will always be shown in ALL CAPS; when these words appear in\nordinary typeface, they are intended to have their ordinary English meaning. All sections of this\nState Transition and Validation Rules for Common Data File formats Page 12 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1793,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.788Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"O LegalName changes O\n—>\nLEI A LEI A\nPre Event Post Event\nLEI A LEIA\nEntity: Entity:\no LegalName: ,Former LegalName“ o LegalName: ,New LegalName“\no OtherEntityName: “Former LegalName”\nRegistration: o OtherEntityNameType:\no lei:RegistrationStatus: ISSUED PREVIOUS_LEGAL_NAME\no LastUpdateDate: 2019-07-01T11:13:00+01:00\nRegistration:\no RegistrationStatus: ISSUED\no LastUpdateDate:\no 2020-04-16T17:43:00+02:00\nLegalEntityEvent:\no @group_type: STANDALONE\no @event_status: COMPLETED\no LegalEntityEventType: CHANGE_LEGAL_NAME\no LegalEntityEventEffectiveDate:\ne 2020-04-13T00:00:00.000Z\no LegalEntityEventRecordedDate:\ne 2020-04-16T00:00:00.000Z\no ValidationDocuments:\nSUPPORTING_DOCUMENTS\no ValidationReference:\nhttp://pub_registry.gov/new_entity_docs.pdf\nExample 1: The Legal Entity “Former LegalName” with an LEI A changed its name to “New LegalName” with effective\ndate April 13, 2020. The LEl issuer updated the record and published it in the Global LEI System on April 16, 2020. The\nchange of the name can be validated in the business registry where the Legal Entity is registered.\nState Transition and Validation Rules for Common Data File formats Page 111 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1269,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.788Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.13.3 Legal Entity Event — Business or trading name changes\nThis Use Case only applies where a business or trading name changes, the LegalName does not\nchange and the Legal Entity remains an operating entity. This event applies to all entity categories\nexcept for Government entities.\nThe LEl issuer:\no SHALL update OtherEntityName with OtherEntityNameType TRADING_OR_OPERATING_NAME\naccordingly.\no SHALL create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be CHANGE_OTHER_NAMES.\no LegalEntityEventEffectiveDate SHALL be the date the change in OtherEntityName becomes\neffective in the Legal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no If @event_statusis IN_PROGRESS, the LEl issuer SHALL provide information regarding the\nAffectedFields: For @field_xpath the LEl issuer usually\ne SHALL provide lei:OtherEntityNames\no MAY provide lei:TransliteratedOtherEntityNames\no MAY provide lei:SuccessorEntity\nIf the change of the Legal Entity’s business or trading name is due to the formation of a new Legal\nEntity, then a new LEI SHALL be issued for the new Legal Entity (see Use Cases 4.1 and 4.3) and the\nSuccessorEntity / SuccessorLEl field of the old LEI Record SHALL be updated with the new LEI (see\nUse Case 4.13.22).\nState Transition and Validation Rules for Common Data File formats Page 112 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1685,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.788Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"O Business or trading name changes O\nN — S\nLEI A LEI A\nPre Event Post Event\nLEI A LEI A\nEntity: Entity:\no LegalName: “Good company name” o LegalName: “Good company name”\no OtherEntityName: “GoodCo”\nRegistration: o OtherEntityNameType:\no lei:RegistrationStatus: LAPSED TRADING_OR_OPERATING_NAME\no LastUpdateDate: 2019-07-01T11:13:00+01:00\no NextRenewalDate: 2020-01- Registration:\n01T00:00:00+01:00 o lei:RegistrationStatus: ISSUED\no LastUpdateDate: 2020-01-23T10:42:00+02:00\no NextRenewalDate: 2021-01-\n01T00:00:00+01:00\nLegalEntityEvent:\no @group_type: STANDALONE\no @event_status: COMPLETED\no LegalEntityEventType:\nCHANGE_OTHER_NAMES\no LegalEntityEventEffectiveDate:\ne 2020-01-15T00:00:00.000Z\no LegalEntityEventRecordedDate:\ne 2020-01-23T00:00:00.000Z\no ValidationDocuments: CONTRACTS\no ValidationReference: Notarized documents\nExample 2: The Legal Entity ,,Good company name“ uses “GoodCo” as a new trading name as of January 15, 2020. The\nLegal Entity Event was recorded in the Global LEI System on January 23, 2020 in the course of renewal, after initially the\nLEI lapsed.\nState Transition and Validation Rules for Common Data File formats Page 113 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1266,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.788Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.13.4 Legal Entity Event — Address information changes\nThis Use Case only applies where the LegalAddress or HeadquartersAddress changes and the Legal\nEntity remains an operating entity. This event applies to all entity categories.\nThe LEl issuer:\no SHALL update LegalAddress and/or HeadquartersAddress accordingly.\no SHALL create a new LegalEntityEvent for each address changed with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be CHANGE_LEGAL_ADDRESS or CHANGE_HQ_ADDRESS,\nrespectively.\no LegalEntityEventEffectiveDate SHALL be the date the change in address becomes effective in\nthe Legal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no If @event_statusis IN_PROGRESS, the LEl issuer SHALL provide information regarding the\nAffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide lei:LegalAddress/* and/or lei:HeadquartersAddress/*\no MAY provide lei:OtherAddresses/*\n* MAY provide lei:TransliteratedOtherAddresses/*\no MAY provide lei:SuccessorEntity\ne Forall above mentioned address containers (LegalAddress, HeadquartersAddress,\nOtherAddresses and TransliteratedOtherAddresses) the concrete data elements SHALL be\nprovided.\no SHALL update OtherAddresses with type ALTERNATIVE_LANGUAGE_LEGAL_ADDRESS and/or\nALTERNATIVE_LANGUAGE_HEADQUARTERS_ADDRESS, if necessary.\no SHALL update TransliteratedOtherAddresses, if necessary.\no SHALL check, if also the Registration Information changed (see Use Case 4.15).\nIf the change of the legal address is due to the formation of a new Legal Entity, then a new LEI SHALL\nbe issued (see Use Cases 4.1 and 4.3) and the SuccessorEntity / SuccessorLEl field of the old LEI\nrecord SHALL be updated with the new LEI (see Use Case 4.13.22). Example 3 provides a specific use\ncase for changing address information.\nState Transition and Validation Rules for Common Data File formats Page 114 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2199,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.788Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"O Address information changes O\n———>\nLEI A LEI A\nIn-progress Event Post Event\nLEI A LEI A\nEntity: Entity:\no FirstAddressLine: “Streetname former legal o FirstAddressLine: “Streetname new legal\naddress 1” address 5”\no AddressNumber: 1 o AddressNumber: 5\nRegistration: Registration:\no RegistrationStatus: ISSUED o RegistrationStatus: ISSUED\no LastUpdateDate: 2019-07-01T11:13:00+01:00 o LastUpdateDate: 2020-01-23T710:42:00+02:00\nLegalEntityEvent: LegalEntityEvent:\no @group_type: STANDALONE o @group_type: STANDALONE\no @event_status: IN_PROGRESS o @event_status: IN_PROGRESS\no LegalEntityEventType: o LegalEntityEventType:\nCHANGE_LEGAL_ADDRESS CHANGE_LEGAL_ADDRESS\no LegalEntityEventEffectiveDate: o LegalEntityEventEffectiveDate:\ne 2020-01-15T00:00:00.000Z e 2020-01-15T00:00:00.000Z\no LegalEntityEventRecordedDate: o LegalEntityEventRecordedDate:\ne 2019-07-07T00:00:00+01:00 e 2019-07-07T00:00:00+01:00\no ValidationDocuments: ¢ ValidationDocuments:\nSUPPORTING_DOCUMENTS SUPPORTING_DOCUMENTS\no ValidationReference: o ValidationReference:\nhttp://pub_registry.gov/new_entity_docs.pdf http://pub_registry.gov/new_entity_docs.pdf\nAffectedFields: LegalEntityEvent:\no Entity/LegalAddress/FirstAddressLine: o @group_type: STANDALONE\no @event_status: COMPLETED\no LegalEntityEventType:\nCHANGE_LEGAL_ADDRESS\no LegalEntityEventEffectiveDate:\nExample 3: The Legal Entity makes available the information about a change in the legal address that will become\neffective on January 15, 2020. In the example only the street and address number change. The change of the legal\naddress was recorded in the Global LEI System on July 7, 2019 as in-progress event. The completion of the Legal Entity\nEvent was validated in the local registry and recorded in the Global LEI System on January 23, 2020.\nState Transition and Validation Rules for Common Data File formats Page 115 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1973,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.788Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.13.5 Legal Entity Event — Legal form changes\nA change of the legal form potentially has different degrees of impact on the Legal Entity. The\nfollowing three Use Cases describe the most common variants. They apply to all entity categories.\nFor cases where an ELF code is supplied for the first time, see section 2.8 instead.\nThe first Use Case (Example 4) applies when only the legal form changes and the Legal Entity remains\nan operating entity. An example could be that the legal forms used in the Legal Entity’s jurisdiction\nare transformed into other legal forms while preserving the legal status of the Legal Entities.\nIn this case, the LEl issuer:\ne SHALL update LegalForm accordingly, following the general rules for Entity Legal Form Reporting\n(see section 2.8).\no SHALL create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be CHANGE_LEGAL_FORM.\no LegalEntityEventEffectiveDate SHALL be the date the change in the legal form becomes\neffective in the Legal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no If @event_statusis IN_PROGRESS, the LEl issuer SHALL provide information regarding the\nAffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide lei:EntityLegalFormCode and lei:OtherLegalForm, if necessary\no MAY provide lei:Legallurisdiction\no MAY provide lei:SuccessorEntity\no SHALL check, if also Registration Information has changed (see Use Case 4.15).\nState Transition and Validation Rules for Common Data File formats Page 116 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1848,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.788Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"O LegalForm changes O\n———’\nLEI A LEI A\nIn-progress Event Post Event\nLEI A LEI A\n\nEntity: Entity:\n\no EntityLegalFormCode: 059 o EntitylegalFormCode: Y1Q4\n\nRegistration: Registration\n\no RegistrationStatus: ISSUED o RegistrationStatus: ISSUED\n\no LlastUpdateDate: 2019-07-01711:13:00+01:00 o LastUpdateDate: 2020-01-23T710:42:00+02:00\n\nLegalEntityEvent: LegalEntityEvent:\n\no @group_type: STANDALONE o @group_type: STANDALONE\n\no @event_status: IN_PROGRESS o @event_status: IN_PROGRESS\n\no LegalEntityEventType: o LegalEntityEventType:\n\nCHANGE_LEGAL_FORM CHANGE_LEGAL_FORM\n\no LegalEntityEventEffectiveDate: o LegalEntityEventEffectiveDate:\n\ne 2020-01-15T00:00:00.000Z e 2020-01-15T00:00:00.000Z\n\no LegalEntityEventRecordedDate: o LegalEntityEventRecordedDate:\n\ne 2019-07-01T00:00:00+01:00 e 2019-07-01T00:00:00+01:00\n\no ValidationDocuments: ¢ ValidationDocuments:\nSUPPORTING_DOCUMENTS SUPPORTING_DOCUMENTS\n\no ValidationReference: o ValidationReference:\nhttp://registry.gov/evidence.pdf http://registry.gov/evidence.pdf\n\nAffectedFields: AffectedFields:\n\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:E o /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:E\nntity/lei:LegalForm/lei:EntityLegalFormCode: ntity/lei:LegalForm/lei:EntityLegalFormCode:\nY1Q4 Y1Q4\n\nLegalEntityEvent:\no @group_type: STANDALONE\no @event_status: COMPLETED\no LegalEntityEventType:\nCHANGE_LEGAL_FORM\no LegalEntityEventEffectiveDate:\ne 2020-01-15T00:00:00.000Z\no LegalEntityEventRecordedDate:\ne 2020-01-23T00:00:00.000Z\n¢ ValidationDocuments:\nSUPPORTING_DOCUMENTS\no ValidationReference:\nhttp://registry.gov/evidence.pdf\nExample 4: The Legal Entity changes its legal form from ELF O59C to ELF Y1Q4 with effective date January 15, 2020. The\nLEl issuer has published this change on July 1, 2019 prior to the effective date. The completion of the Legal Entity Event\nwas recorded in the Global LEI System on January 23, 2020.\nState Transition and Validation Rules for Common Data File formats Page 117 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2074,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.788Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"The second Use Case (Example 5) applies when also the legal name changes due to the legal form\nchange and the Legal Entity remains an operating entity.\nIn this case, the LEl issuer:\no SHALL update LegalForm accordingly, following the general rules for Entity Legal Form Reporting\n(see section 2.8).\no SHALL create a new LegalEntityEvent for the legal form change with:\no @group_type SHALL be CHANGE_LEGAL_FORM_AND_NAME.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be a unique identifier (e.g., a hash value calculated from the combination\nof the LEl, EventType and EffectiveDate).\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be CHANGE_LEGAL_FORM.\no LegalEntityEventEffectiveDate SHALL be the date the change in the legal form becomes\neffective in the Legal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no If @event_status is IN_PROGRESS, the LEl issuer SHALL provide information regarding the\nAffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide lei:EntityLegalFormCode and lei:OtherLegalForm, if necessary\no MAY provide lei:Legallurisdiction\no MAY provide lei:SuccessorEntity\no SHALL create a new LegalEntityEvent for the legal name change with (see Use Case 4.13.2):\no @group_type SHALL be CHANGE_LEGAL FORM_AND_NAME.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be the same unique identifier used for the previous event.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be CHANGE_LEGAL NAME.\no LegalEntityEventEffectiveDate SHALL be the date the change in the legal form becomes\neffective in the Legal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\nState Transition and Validation Rules for Common Data File formats Page 118 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2070,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.788Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o If @event_statusis IN_PROGRESS, the LEl issuer SHALL provide information regarding the\n\nAffectedFields: For @field_xpath the LEl issuer usually\n\no SHALL provide lei:LegalName\n\ne SHALL provide lei:OtherEntityNames\n\no MAY provide lei:TransliteratedOtherEntityNames\n\no MAY provide lei:SuccessorEntity\n\no SHALL check, if also Registration Information has changed (see section 4.15).\nState Transition and Validation Rules for Common Data File formats Page 119 of 170\n@ Public Version 2.7.1 Final\n\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":566,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.788Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"LegalForm and LegalName change\n-\nPre Event Post Event\nLEI A LEI A\nEntity: Entity:\no EntityLegalFormCode: FGVH o EntityLegalFormCode: O85W\no LegalName: “Company Name Inc” o LegalName: “Company Name LLC”\nRegistration: Registration:\no lei:RegistrationStatus: ISSUED o lei:RegistrationStatus: ISSUED\no lastUpdateDate: 2019-07-01711:13:00+01:00 o LastUpdateDate: 2020-01-23T10:42:00+02:00\nLegalEntityEvent:\no @group_type:\nCHANGE_LEGAL_FORM_AND_NAME\no @group_id: dfecd444f23463443a98n12a\no @event_status: COMPLETED\no LegalEntityEventType:\nCHANGE_LEGAL_FORM\no LegalEntityEventEffectiveDate:\ne 2020-01-15T00:00:00.000Z\no LegalEntityEventRecordedDate:\ne 2020-01-23T00:00:00.000Z\no ValidationDocuments:\nSUPPORTING_DOCUMENTS\ne ValidationReference:\nhttp://pub_registry.gov/new_entity_docs.pdf\nLegalEntityEvent:\no @group_type:\nCHANGE_LEGAL_FORM_AND_NAME\no @group_id: dfecd444f23463443a98n12a\no @event_status: COMPLETED\no LegalEntityEventType:\nCHANGE_LEGAL_NAME\no ValidationDocuments:\nSUPPORTING_DOCUMENTS\no LegalEntityEventEffectiveDate:\ne 2020-01-15T00:00:00.000Z\no LegalEntityEventRecordedDate:\ne 2020-01-23T00:00:00.000Z\no ValidationDocuments:\nSUPPORTING_DOCUMENTS\ne ValidationReference:\nhttp://pub_registry.gov/new_entity_docs.pdf\nExample 5: The Legal Entity changes its legal form from ELF FGVH to ELF O85W with effective date January 15, 2020 and\nadditionally changes its legal name. The completion of the Legal Entity Event was recorded in the Global LEI System on\nJanuary 23, 2020.\nState Transition and Validation Rules for Common Data File formats Page 120 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1667,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.788Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"document, with the exception of the Introduction, are normative, except where explicitly noted as\nnon-normative. The following typographical conventions are used throughout the document:\no ALL CAPS type is used for the special terms enumerated above and when in the text is referred to\na data field value from an enumerated list.\no CamelCase type is used to refer to the data elements as declared in the CDF XML Schema\nDefinition (xsd).\nState Transition and Validation Rules for Common Data File formats Page 13 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":620,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.788Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"The third Use Case (Example 6) applies when the legal form change creates a new Legal Entity while\nthe previous Legal Entity ceases to exist.\n\nIn this case, the LEl issuer:\n\no SHALL retire the LEI Record Set of the previous Legal Entity:\n\no Set RegistrationStatus to RETIRED.\n\no Set RegistrationStatus of all current Relationship Records to RETIRED with RelationshipStatus\nINACTIVE; set EndDate of RelationshipPeriod with PeriodType RELATIONSHIP_PERIOD as\nLegalEntityEventEffectiveDate of the event (see below).\n\no Setthe new Legal Entity (see below) as SuccessorEntity.\n\ne Create a new LegalEntityEvent for the LEI Record Set of the previous Legal Entity with:\n\no @group_type SHALL be COMPLEX_CHANGE_LEGAL_FORM.\n\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\n\no @group_id SHALL be omitted.\n\no @group_sequence_no SHALL be omitted.\n\no LegalEntityEventType SHALL be CHANGE_LEGAL_FORM.\n\no LegalEntityEventEffectiveDate SHALL be date the change in the legal form becomes effective\nin the Legal Jurisdiction of the Legal Entity.\n\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\n\no If @event_statusis IN_PROGRESS, the LEl issuer SHALL provide information regarding the\nAffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide lei:EntityLegalFormCode and lei:OtherLegalForm, if necessary\no MAY provide lei:Legallurisdiction\no MAY provide lei:LegalName\no MAY provide lei:OtherEntityNames\no MAY provide lei:TransliteratedOtherEntityNames\no MAY provide lei:SuccessorEntity\n\no If @event_status is COMPLETED and there is at least one SuccessorEntity entry added to the LEI\n\nRecord Set, the LEl issuer SHALL provide information regarding the AffectedFields: For\n\n@field_xpath the LEl issuer usually\n\no SHALL provide lei:SuccessorEntity\n\no Issue a new LEI Record (see Use Cases 4.1 and 4.3), including all appropriate relationships.\nState Transition and Validation Rules for Common Data File formats Page 121 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2099,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.788Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o For the newly issued LEI Record, create a new LegalEntityEvent with:\no @group_type SHALL be COMPLEX_CHANGE_LEGAL_FORM.\no @event_status SHALL be COMPLETED.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be CHANGE_LEGAL_FORM.\no LegalEntityEventEffectiveDate SHALL be the date when the change in the legal form becomes\neffective in the Legal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no AffectedFields SHALL be omitted.\nState Transition and Validation Rules for Common Data File formats Page 122 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":749,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.788Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"LegalForm changes and LEI A retires\n_————’\nPost Event Post Event\nLEIA LEI B (Create new LEI Record Set)\nEntity: Entity:\no EntityLegalFormCode: FGVH o EntityLegalFormCode: O85W\no LegalName: Company inc o LegalName: Company LLC\no SuccessorlLEl: B o EntityCreationDate:\ne 2020-01-15T00:00:00.000Z\nRegistration:\no lei:RegistrationStatus: RETIRED Registration:\no lei:LastUpdateDate: o lei:RegistrationStatus: ISSUED\no 2020-01-23T10:42:00+02:00 o lei:LastUpdateDate:\no 2020-01-23T10:42:00+02:00\nRelationship:\no rr:RegistrationStatus: RETIRED LegalEntityEvent:\no rr:RelationshipStatus: INACTIVE o @group_type:\no rr:LastUpdateDate: COMPLEX_CHANGE_LEGAL_FORM\no 2020-01-23T10:42:00+02:00 e @event_status: COMPLETED\no LegalEntityEventType:\nLegalEntityEvent: CHANGE_LEGAL_FORM\n° (@group_type: o LegalEntityEventEffectiveDate:\nCOMPLEX_CHANGE_LEGAL_FORM e 2020-01-15T00:00:00.000Z\no @event_status: COMPLETED o LegalEntityEventRecordedDate:\no LegalEntityEventType: e 2020-01-23T00:00:00.000Z\nCHANGE_LEGAL_FORM ¢ ValidationDocuments:\no LegalEntityEventEffectiveDate: SUPPORTING_DOCUMENTS\ne 2020-01-15T00:00:00.000Z o ValidationReference:\no LegalEntityEventRecordedDate: http://pub_registry.gov/new_entity_docs.pdf\no 2020-01-23T00:00:00+01:00\no ValidationDocuments:\nSUPPORTING_DOCUMENTS\no ValidationReference:\nhttp://pub_registry.gov/new_entity docs.pdf\nAffectedFields:\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:E\nntity/lei:SuccessorEntity/lei:SuccessorLEl:\nLEI B\nExample 6: Legal Entity LEI A changes its legal form from ELF O59C to ELF NSNT with effective date January 15, 2020. As a\nconsequence, LEI A retires, and an LEI Record Set for LEI B is created. The completion of the Legal Entity Event was\nrecorded in the Global LEI System on January 23, 2020.\nState Transition and Validation Rules for Common Data File formats Page 123 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1938,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.788Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"A legal form change could result in one of the three above described scenarios. The LEl issuer SHALL\nassess and evaluate the documents at hand and decide which of the three scenarios apply in the\nparticular case.\n4.13.6 Legal Entity Event — Acquisition\nLegal Entity A (general Legal Entity or Fund, but not Branch, Government Entity or International\nOrganization), either independent/stand-alone or Subsidiary/sub-fund/compartment, is acquired by\nanother Legal Entity B but remains a separate/segregated Legal Entity.\nThe LEl issuer managing the record of entity A SHALL:\no Retire any current Relationship Records and/or stop publishing Reporting Exception Records for\nA.\no Create new relationships/exceptions with parent Legal Entity B (including Fund relationships, if\napplicable).\no Create a new LegalEntityEvent (single, combined or group, as applicable) with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be MERGERS_AND_ACQUISITIONS.\no LegalEntityEventEffectiveDate SHALL be the date the acquisition becomes effective in the\nLegal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no If @event_statusis IN_PROGRESS, the LEl issuer SHALL provide information regarding the\nAffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide rr:EndNode/rr:NodelD\no SHALL provide rr:EndNode/rr:NodeType\no SHALL provide rr:RelationshipType\n* MAY provide repex:ExceptionCategory\no MAY provide repex:ExceptionReason\nState Transition and Validation Rules for Common Data File formats Page 124 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1849,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.788Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"O Acquired by O\n- >\nLEIA LEIB\nPost Event\nLEI A\nRelationship:\no rr:RegistrationStatus: RETIRED\no rr:LastUpdateDate: 2020-04-16T17:43:00.000Z\no Create new RelationshipRecords, if applicable\no Stop publishing ReportingExceptions, if applicable\nLegalEntityEvent:\no @group_type: STANDALONE\no @event_status: COMPLETED\no LegalEntityEventType: MERGERS_AND_ACQUISITIONS\no LegalEntityEventEffectiveDate: 2020-03-02T00:00:00.000Z\no LegalEntityEventRecordedDate: 2020-04-16T00:00:00.000Z\no ValidationDocuments: SUPPORTING_DOCUMENTS\no ValidationReference: http://registry.gov/evidence.pdf\nExample 7: The Legal Entity with LEI A is acquired by Legal Entity with LEI B with effective date on March 2, 2020 and\nrecorded in the Global LEI System on April 16, 2020.\n4.13.7 Legal Entity Event — Absorption\nLegal Entity A (general Legal Entity or Fund, but not Branch, Government Entity or International\nOrganization), either independent/stand-alone or Subsidiary/sub-fund/compartment, is acquired by\nanother Legal Entity B (may or may not be in a parent relationship with A). All assets/shares of Legal\nEntity A are absorbed by Legal Entity B and A ceases to exist as an active Legal Entity.\nNote: The addition of Absorption to the list of Legal Entity Events covered by the policy is under\nreview with the LEI-ROC.\nThe LEl issuer managing the record of Legal Entity A SHALL:\no Retire LEI Record Set of absorbed Legal Entity A:\no Set RegistrationStatus RETIRED.\ne Set current relationships to RETIRED, if applicable.\no Set Legal Entity B as SuccessorEntity.\nState Transition and Validation Rules for Common Data File formats Page 125 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1726,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.788Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be ABSORPTION.\no LegalEntityEventEffectiveDate SHALL be the date the Absorption becomes effective in the\nLegal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no If @event_status is IN_PROGRESS or COMPLETED, the LEl issuer SHALL provide information\nregarding the AffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide lei:SuccessorEntity\nThe LEl issuer managing the record of entity B SHALL:\no Record the absorption of Legal Entity A by creating a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be ABSORPTION.\no LegalEntityEventEffectiveDate SHALL be the date the Absorption becomes effective in the\nLegal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\n© AffectedFields SHALL be omitted.\nNote: LEI Records for A and B MAY be managed by different LEl issuers. Nevertheless, there SHALL be\nconsistency for the LegalEntityEventEffectiveDate and ValidationReference of the event; Recorded\nDate MAY be different.\nState Transition and Validation Rules for Common Data File formats Page 126 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1645,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.788Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"O Absorbed by O\nR\nLEI A LEIB\nPost Event Post Event\nLEI A LEI B\nEntity: LegalEntityEvent:\no SuccessorEntity: LEI B o @group_type: STANDALONE\no @event_status: COMPLETED\nRegistration: o LegalEntityEventType: ABSORPTION\no RegistrationStatus: RETIRED o LegalEntityEventEffectiveDate:\no LastUpdateDate: 2020-01-23T10:42:00+02:00 e 2020-01-20T00:00:00.000Z\no LegalEntityEventRecordedDate:\nRelationship: e 2020-01-23T00:00:00.000Z\no Stop publishing ReportingExceptions » ValidationDocuments:\nSUPPORTING_DOCUMENTS\nRelationship Registraion: « ValidationReference:\no RegistrationStatus: RETIRED http://registry.gov/evidence.pdf\no LastUpdateDate: 2020-01-23T10:42:00+02:00\nLegalEntityEvent:\no @group_type: STANDALONE\no @event_status: COMPLETED\no LegalEntityEventType: ABSORPTION\no LegalEntityEventEffectiveDate:\ne 2020-01-20T00:00:00.000Z\no LegalEntityEventRecordedDate:\ne 2020-01-23T00:00:00.000Z\no ValidationDocuments:\nSUPPORTING_DOCUMENTS\no ValidationReference:\nhttp://registry.gov/evidence.pdf\nAffectedFields:\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:E\nntity/lei:SuccessorEntity/lei:SuccessorLEl:\nLEI B\nExample 8: The Legal Entity with LEI A is absorbed by a Legal Entity with an LEI B with effective date January 20, 2020 and\nboth records have been updated on the same date January 23, 2020.\nState Transition and Validation Rules for Common Data File formats Page 127 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1480,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.788Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.13.8 Legal Entity Event — Merger\nA common example how a Merger is processed and its outcome:\nLegal Entity A (not a Branch) and Legal Entity B (not a Branch either and usually of a similar category\nas A) combine their shares/assets and together form a new Legal Entity C (general Legal Entity or\nFund, but not Branch). A and B cease to exist as Legal Entities after the Merger.\nThe LEl issuer(s) managing the LEI Record Sets of entities A and B SHALL:\no Retire records of entity A and entity B once @event_status is COMPLETED:\no Set RegistrationStatus RETIRED.\no Set EntityStatus INACTIVE.\ne Set current relationships to RETIRED, if applicable.\no Set Legal Entity C as SuccessorEntity.\no Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be MERGERS_AND_ACQUISITIONS.\no LegalEntityEventEffectiveDate SHALL be the date the Merger becomes effective in the Legal\nJurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no If @event_status is IN_PROGRESS or COMPLETED, the LEl issuer SHALL provide information\nregarding the AffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide lei:SuccessorEntity\nThe LEl issuer creating the new LEI Record for Legal Entity C SHALL:\n¢ Issue a new LEI Record (see Use Case Issue new LEI), including all appropriate relationships.\no Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be omitted.\nG State Transition and Validation Rules for Common Data File formats Page 128 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1912,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.791Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be MERGERS_AND_ACQUISITIONS.\no LegalEntityEventEffectiveDate SHALL be the date the Merger becomes effective in the Legal\nJurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no AffectedFields SHALL be omitted.\nLEIB\nMerge O\nLEIC\nLEI A\nPre Event Post Event\nState Transition and Validation Rules for Common Data File formats Page 129 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":590,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.792Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Pre & Post Event Post Event\nLEI A; LEIB LEI C (Create new LEI Record Set)\nEntity: Entity:\no EntityStatus: INACTIVE (Post Event) o LegalName: “New Firm LLC”\no SuccessorEntity: LEI C (Post Event) o EntityStatus: ACTIVE\no CreationDate:\nRegistration LE| A: 2020-04-19T00:00:00+02:00\no RegistrationStatus: RETIRED (Post Event)\no LastUpdateDate (Post Event): Registration:\no LEI A: 2020-04-20T13:43:25+02:00 o RegistrationStatus: ISSUED\no LEIB: 2020-05-20T13:43:25+02:00 ¢ InitialRegistrationDate:\n2020-04-20T00:00:00+02:00\nRelationship (Post Event):\n« Stop publishing ReportingExceptions LegalEntityEvent:\no @group_type: STANDALONE\nRelationship Registration (Post Event): o @event_status: COMPLETED\no RegistrationStatus: RETIRED o LegalEntityEventType:\nMERGERS_AND_ACQUISITIONS\nLegalEntityEvent (Pre & Post Event): o LegalEntityEventEffectiveDate:\no @group_type: STANDALONE o 2020-04-19T00:00:00+02:00\no @entity_status: IN_PROGRESS o LegalEntityEventRecordedDate:\no LegalEntityEventType: MERGERS_AND_ACQUISITIONS o 2020-04-20T00:00:00+02:00\no LegalEntityEventEffectiveDate: o ValidationDocuments: CONTRACTS\ne 2020-04-19T00:00:00+02:00 o ValidationReference: Notarized documents\no LegalEntityEventRecordedDate:\no LEI A: 2020-03-11T00:00:00+02:00\ne LEIB: 2020-03-13T00:00:00+02:00\no ValidationDocuments: SUPPORTING_DOCUMENTS\no ValidationReference: http://registry.gov/evidence.pdf .\nExample 9: LEI A and LEI B merge into LEI C (new Legal\n. Entity). LEI A and LEI B cease to exist on April 19, 2020.\nAffectedFields: The LEl issuer of LEI A was made aware of the\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei: incoming merger on 11 March 2020, while the LEI\nSuccessorEntity/lei:SuccessorLEl: LEI C issuer of LEI B was made aware of the incoming\nmerger on 13 March 2020. Both LOUs were given the\nLegalEntityEvent (Post Event): information that the legal name of LEI C will be “New\n« @group_type: STANDALONE Firn:l LLC” and that the merger will be complete.d on 19\n« @entity_status: COMPLETED April 2020. The recorded dates.of the Legal Entity\n- Events MAY vary between the involved records, as\no LegalEntityEventType: MERGERS_AND_ACQUISITIONS these may be managed by different LEI issuers.\no LegalEntityEventEffectiveDate:\no 2020-04-19T00:00:00+02:00\no LegalEntityEventRecordedDate:\ne LEI A: 2020-04-20T00:00:00+02:00\ne LEI B: 2020-05-20T00:00:00+02:00\no ValidationDocuments: SUPPORTING_DOCUMENTS\no ValidationReference: http://registry.gov/evidence.pdf\nAffectedFields:\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:\nSuccessorEntity/lei:SuccessorLEl: LEI C\nState Transition and Validation Rules for Common Data File formats Page 130 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2768,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.792Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"2 Lifecycle and General Concepts\n\n2.1 LEI Record Set Reference Data\n\nThe LEI Record Set consists of a set of one LEI record and its corresponding Relationship Records (RR),\n\nand Reporting Exception Records (Repex) that give the full Level 1 and Level 2 Reference Data for\n\nthat LEL.\n\nLEI records, Relationship Records and Reporting Exception Records each consist of a pre-defined set\n\nof mandatory and optional data elements. The following types of elements are used within the LEI\n\nRecord Set:\n\no Fixed list of allowed values (enumerations): only values defined in the respective xsd file are\nallowed. Example element: RegistrationStatus.\n\no Codes from a code list: only values from the current version of the referenced code list are\nallowed. Example element: LegalFormCode.\n\no Fixed format: only values with a specific format pattern are allowed. Example element: LEI.\n\no Free text: any content allowed. The xsd MAY have some restrictions defined (length, character\nset, no leading/trailing spaces). The content of a free text element SHALL NOT be “N/A” or similar\nplaceholder. Example element: LegalName.\n\n2.1.1 Legal Entity data (Level 1 data — ‘Who is who’)\n\nThe Legal Entity Identifier (LEl) connects to key Reference Data that provides the information on a\n\nLegal Entity identifiable with an LEI. The ISO 17442 standard developed by the International\n\nOrganization for Standardization defines a set of attributes that comprises the most essential\n\nelements of identification. The standard specifies the minimum Reference Data, which must be\n\nsupplied for each LEIl and further requirements for the LEI code and provided Reference Data. For the\ncomplete scope and content of the standard, please refer to the International Organization for\n\nStandardization®.\n\nWith the inclusion of Legal Entity Events and the related update of the Common Data File format to\n\nversion 3.1, the Legal Entity data will be enriched with Legal Entity Event information that impacts\n\nthe Legal Entity and changes their reference data.\n\n2.1.2 Legal Entity relationship information (Level 2 data — ‘Who owns whom’)\n\nLegal Entity relationship information describe the relationship between two Legal Entities. All\n\nrelationships have a specific type describing the kind of the relationship and two end points defining\n\nL https://www.iso.org/standard/75998.html\n\nState Transition and Validation Rules for Common Data File formats Page 14 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2526,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.792Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.13.9 Legal Entity Event — Transformation of a Subsidiary to an International Branch\nLegal Entity A (a general Legal Entity) in country X, a Subsidiary of parent Legal Entity B in country Y,\nis absorbed by Legal Entity B and turned into an International Branch. All shares/assets and liabilities\nof Legal Entity A are absorbed by Legal Entity B. This Legal Entity Event can only be recorded if Legal\nEntity A fulfills all the requirements for International Branches within the Global LEI System (see\nsection 4.2); otherwise, a different Legal Entity Event could apply. In case Legal Entity A is in the\nhome jurisdiction of Legal Entity B and it has been transformed to a Branch entity, the LEI of Legal\nEntity A SHALL be set to RETIRED since an International Branch LEI cannot be assigned in the home\njurisdiction. In that scenario the Legal Entity Event of type ABSORPTION MAY apply.\nFor the transformation of a subsidiary to an international branch, the LEl issuer managing the LEI\nRecord Set of Legal Entity A SHALL:\ne Update LEI Record Set of Legal Entity A to Branch:\no Set current relationships with Legal Entity B to RETIRED.\no Create a new relationship with Legal Entity B with RelationshipType\nIS_INTERNATIONAL BRANCH_OF; StartDate of the RelationshipPeriod with PeriodType\nRELATIONSHIP_PERIOD SHALL be the LegalEntityEventEffectiveDate of the Legal Entity Event\n(see below).\no Set EntityCategory to BRANCH.\ne Set the LegalForm and the ELF code to the LegalForm and the ELF code of the (head office)\nLegal Entity B.\no Set the Legal Jurisdiction to the Legal Jurisdiction of the (head office) Legal Entity B.\no Setthe RegistrationStatus (lei and rr) to either ISSUED or LAPSED, depending on the\nRegistrationStatus of the (head office) Legal Entity B.\no Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be TRANSFORMATION_SUBSIDIARY_TO_BRANCH\no LegalEntityEventEffectiveDate SHALL be the date the transformation becomes effective\nin the Legal Jurisdiction of the Legal Entity\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the\nGlobal LEI System.\nState Transition and Validation Rules for Common Data File formats Page 131 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2465,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.792Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o If @event_status is IN_PROGRESS, the LEl issuer SHALL provide information regarding\nthe AffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide rr:EndNode/rr:NodelD\no SHALL provide rr:EndNode/rr:NodeType\no SHALL provide rr:RelationshipType\no SHALL provide lei:EntityCategory\ne SHALL provide lei:SuccessorEntity, if applicable\no If @event_status is COMPLETED, the LEl issuer SHALL provide information regarding the\nAffectedFields: For @field_xpath the LEl issuer usually\ne SHALL provide lei:SuccessorEntity, if applicable\nState Transition and Validation Rules for Common Data File formats Page 132 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":723,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.792Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Switzerland O Transformed into O Belgium\nLET A International branch of LEI B\nPost Event Post Event\nLEI B\nLEI A\nEntity:\nEntity: o EntityLegalformCode: N5NT\ne EntityCategory: BRANCH o Legallurisdiction: BE\no EntityLegalformCode: N5NT\no Legallurisdiction: BE Registration:\no RegistrationStatus: ISSUED\nRegistration:\no RegistrationStatus: ISSUED Relationship Registration:\no RegistrationStatus: PUBLISHED\nRelationship: © LastUpdateDate:\no RegistrationStatus of previous relationships with LEI s 2020-04-20T13:43:25+02:00\nB: RETIRED\no Create new RelationshipRecord with LEI B with\nRelationship/RelationshipType\nIS INTERNATIONAL BRANCH OF Example 10: The Legal Entity with LEI A,\n* RelationshipPeriodStartDate: r:::\\csi;cnlrisez ?rl:tb:adr:ai:\\‘{c::nl-aili:;\\:l branch\n° 2020-04-18T00:00:00+02:00 of Legal Entity B with effective date April\n18, 2020. Both records have been\nRelationship Registration: updated on the same date April 20, 2020.\no RegistrationStatus: PUBLISHED\no LastUpdateDate: 2020-04-20T13:43:25+02:00\nLegalEntityEvent:\no @group_type: STANDALONE\no @entity_status: COMPLETED\no LegalEntityEventType:\nTRANSFORMATION_SUBSIDIARY_TO_BRANCH\no LegalEntityEventEffectiveDate:\no 2020-04-18T00:00:00+02:00\no LegalEntityEventRecordedDate:\no 2020-04-20T00:00:00+02:00\no ValidationDocuments: CONTRACTS\no ValidationReference: Notarized documents\nIf applicable, LegalEntityEvent:\no @group_type: STANDALONE\no @entity_status: COMPLETED\no LegalEntityEventType: CHANGE_LEGAL_FORM\no LegalEntityEventEffectiveDate:\no 2020-04-18T00:00:00+02:00\no LegalEntityEventRecordedDate:\no 2020-04-20T00:00:00+02:00\no ValidationDocuments: CONTRACTS\no ValidationReference: Notarized documents\nState Transition and Validation Rules for Common Data File formats Page 133 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1860,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.792Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.13.10 Legal Entity Event — Acquisition of an International Branch\nA common example how Acquisition of an International Branch is processed and its outcome:\nInternational Branch A of (head office) Legal Entity B, is acquired by Legal Entity C and henceforth\noperates as Branch for (head office) Legal Entity C. The assets and liabilities related to the Branch are\nfully or partially transferred from Legal Entity B to Legal Entity C. Legal Entity B will have International\nBranch A deleted from the official registry (RA source). Legal Entity C will register a new International\nBranch D in the official registry. This Legal Entity Event can only be recorded if Legal Entity D fulfills all\nthe requirements for International Branches within the Global LEI System (see section 4.2).\nThe LEl issuer managing the LEI Record Set of International Branch A SHALL:\no Set the RegistrationStatus (lei and rr) to RETIRED\no Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be ACQUISITION_BRANCH.\no LegalEntityEventEffectiveDate SHALL be the date the acquisition of the Branch becomes\neffective in the Legal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no If @event_statusis IN_PROGRESS or COMPLETED, the LEl issuer SHALL provide information\nregarding the AffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide lei:SuccessorEntity\no Set the new International Branch (see below) as SuccessorEntity.\nThe LEl issuer managing the LEI Record Set of Branch entity D SHALL:\no Create a new LEI Record for a Branch, if the conditions for issuing an LEI Record for a Branch are\nmet (see Use Case 4.2).\no Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be COMPLETED.\no @group_id SHALL be omitted.\nState Transition and Validation Rules for Common Data File formats Page 134 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2206,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.793Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be ACQUISITION_BRANCH.\no LegalEntityEventEffectiveDate SHALL be the date the acquisition of the Branch becomes\neffective in the Legal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no AffectedFields SHALL be omitted.\no The EntityCreationDate SHALL be the LegalEntiyEventEffectiveDate of entity A’s event with\nLegalEntityEventType ACQUISITION_BRANCH.\n¢ The LegalEntityEventEffectiveDate SHALL be the date the Acquisition becomes effective in the\nLegal Jurisdiction of Branch entity A.\ne Set the LegalForm and the ELF code to the LegalForm and the ELF code of the (head office) Legal\nEntity C.\no Set the Legal Jurisdiction to the Legal Jurisdiction of the (head office) Legal Entity C.\n¢ Create a Relationship Record with the head office C and RelationshipType\nIS_INTERNATIONAL _BRANCH_OF; the StartDate of the RelationshipPeriod with PeriodType\nRELATIONSHIP_PERIOD SHALL be the EntityCreationDate.\no Legal Entity D can acquire an LEl only in case it is not in the home jurisdiction of Legal Entity C.\nState Transition and Validation Rules for Common Data File formats Page 135 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1341,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.793Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"LEI C\nEntity:\no EntityLegalFormCode: N5NT\no Legallurisdiction: BE\nO Transfers assets & liabilities O\n—>\nLEIB LEIC\nFormer INTERNATIONAL_BRANCH_OF\nIS_INTERNATIONAL_BRANCH_OF\nchd\\‘edw\nLEIA LEI D (Create new LEI Record Set)\nEntity: Entity:\ne SuccessorEntity: LEI D o EntitiyCreationDate:\ne 2020-04-19T00:00:00+02:00\nRegistration: o EntityLegalFormCode: N5NT\no RegistrationStatus: RETIRED o Legallurisidiction: BE\no LastUpdateDate: 2020-04-20T13:43:25+02:00\nRelationship:\nRelationship: ° RelationshipType:\no Stop publishing ReportingExceptions IS_INTERNATIONAL_BRANCH_OF\no RelationshipPeriodType:\nRelationship Registration: RELATIONSHIP_PERIOD\no RegistrationStatus: RETIRED * RelationshipPeriodStartDate:\ne 2020-04-19T00:00:00+02:00\nLegalEntityEvent: o LastUpdateDate: 2020-04-20T13:43:25+02:00\no @group_type: STANDALONE\no @entity_status: COMPLETED LegalEntityEvent:\no LegalEntityEventType: ACQUISITION_BRANCH o @group_type: STANDALONE\no LegalEntityEventEffectiveDate: o @entity_status: COMPLETED\n¢ 2020-04-19T00:00:00+02:00 o LegalEntityEventType: ACQUISITION_BRANCH\no LegalEntityEventRecordedDate: o LegalEntityEventEffectiveDate:\ne 2020-04-20T00:00:00+02:00 e 2020-04-19T00:00:00+02:00\ne ValidationDocuments: REGULATORY_FILING o LegalEntityEventRecordedDate:\ne 2020-04-20T00:00:00+02:00c\nAffectedFields: + ValidationDocuments: REGULATORY_FILING\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:E\nntity/lei:SuccessorEntity/lei:SuccessorLEl:\nLEID\nExample 11: The Legal Entity with LEI A, which is an International Branch of B, is acquired by Legal Entity with an LEI C\nwith effective date April 19, 2020. The Legal Entity with LEI A ceases to exist and a new Legal Entity with LEI D is issued as\ninternational Branch of Legal Entity with LEI C. The LElI Record Sets of LEI A and LEI D have been updated on the same\ndate April 20, 2020.\nState Transition and Validation Rules for Common Data File formats Page 136 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2022,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.793Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.13.11 Legal Entity Event — Break-up\nLegal Entity A (general Legal Entity or Government Entity) completely separates into two or more\nindependent Legal Entities B and C (plus D, E, ...). Entity A will cease to exist as an independent Legal\nEntity.\nA common example how Break-up is processed and its outcome if entity A ceases to exists:\nThe LEl issuer managing the LEl Record Set of entity A SHALL:\ne Retire the LEI Record Set of Legal Entity A:\no Set RegistrationStatus RETIRED.\ne Set current relationships to RETIRED, if applicable.\ne SHALL include SuccessorEntity for every newly created entity after the separation.\no Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be BREAKUP.\no LegalEntityEventEffectiveDate SHALL be the date the Break-up becomes effective in the Legal\nJurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no If @event_statusis IN_PROGRESS or COMPLETED, the LEl issuer SHALL provide information\nregarding the AffectedFields: For @field_xpath the LEl issuer usually\ne SHALL provide lei:SuccessorEntity for all independent Legal Entities created\nThe LEl issuer(s) managing the records of entities B, C, ... SHALL:\no Create new LEI Records for the new Legal Entity(ies) (see Use Case 4.1).\no Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be COMPLETED.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\nG State Transition and Validation Rules for Common Data File formats Page 137 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1852,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.793Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o LegalEntityEventType SHALL be BREAKUP.\no LegalEntityEventEffectiveDate SHALL be the date the Break-up becomes effective in the Legal\nJurisdiction of the new Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no AffectedFields SHALL be omitted.\nState Transition and Validation Rules for Common Data File formats Page 138 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":495,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.793Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"LEIB LEIC LEID(E, F,..)\nv\nBreak-up\nLEI A\nLEI A LEIB, C, (D, E,F,..)\nEntity: o Create new LEI Record Sets\no SuccessorEntity: LEI B\no SuccessorEntity: LEI C LegalEntityEvent:\nRegistration: o @group_type: STANDALONE\no RegistrationStatus: RETIRED o @event_status: COMPLETED\no LegalEntityEventType: BREAKUP\nRelationship: + LegalEntityEventEffectiveDate:\n© Stop publishing ReportingExceptions © 2020-04-12T00:00:00+02:00\no LegalEntityEventRecordedDate:\nRelationship Registration + 2020-04-20T00:00:00+02:00\n© RegistrationStatus: RETIRED + ValidationDocuments:\n_ SUPPORTING_DOCUMENTS\nLegalEntityEvent: » ValidationReference:\n© @group_type: STANDALONE http://registry.gov/evidence.pdf\no @event_status: COMPLETED\no LegalEntityEventType: BREAKUP\no LegalEntityEventEffectiveDate:\no 2020-04-12T00:00:00+02:00\no LegalEntityEventRecordedDate:\no 2020-04-20T00:00:00+02:00\no ValidationDocuments:\nSUPPORTING_DOCUMENTS\no ValidationReference:\nhttp://registry.gov/evidence.pdf\nAffectedFields:\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Ent\nity/lei:SuccessorEntity/lei:SuccessorLEl: LEI B\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Ent\nity/lei:SuccessorEntity/lei:SuccessorLEl: LEI C\nExample 12: The Legal Entity with LEI A is separated into LEI B and LEI C with effective date April 12, 2020. The Legal\nEntity with LEI A ceases to exist. Theoretically, it is possible that LEI A is split into additional Legal Entities (LEID, E, F, ...).\nThe LEI Record Sets of LEI A and LEI D have been updated on the same date April 20, 2020.\nState Transition and Validation Rules for Common Data File formats Page 139 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1712,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.793Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.13.12 Legal Entity Event — Demerger\n\nA part or division of Legal Entity A (general Legal Entity or Government Entity) is separated into a new\n\nseparate entity, Subsidiary Legal Entity B. Part of Legal Entity A’s shares/assets and liabilities are\n\ntransferred to B.\n\nThe LEl issuer managing the LEI Record Set of Legal Entity A SHALL:\n\no Create a new LegalEntityEvent with:\n\no @group_type SHALL be STANDALONE.\n\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\n\no @group_id SHALL be omitted.\n\no @group_sequence_no SHALL be omitted.\n\no LegalEntityEventType SHALL be DEMERGER.\n\no LegalEntityEventEffectiveDate SHALL be the date the Demerger becomes effective in the\nLegal Jurisdiction of the Legal Entity.\n\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\n\no If @event_statusis IN_PROGRESS or COMPLETED, the LEl issuer SHALL provide information\nregarding the AffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide lei:SuccessorEntity\n\no Set LEI B as SuccessorEntity.\n\nThe LEl issuer managing the LEI Record Set of entity B SHALL:\n\n¢ Create a new LEI Record Set for the new Legal Entity B (see Use Case 4.1).\n\n* Create accounting consolidation relationship(s) with Legal Entity A, as applicable; StartDate of\nthe RelationshipPeriod with PeriodType RELATIONSHIP_PERIOD SHALL be the effective date that\nthe Legal Entity event became effective in the Legal Jurisdiction of the new Legal Entity (see\nbelow).\n\no Create a new LegalEntityEvent with:\n\no @group_type SHALL be STANDALONE.\n\no @event_status SHALL be COMPLETED.\n\no @group_id SHALL be omitted.\n\no @group_sequence_no SHALL be omitted.\n\no LegalEntityEventType SHALL be DEMERGER.\nState Transition and Validation Rules for Common Data File formats Page 140 of 170\n\n@ Public Version 2.7.1 Final\n\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1910,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.793Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"the Legal Entities linked by the relationship. Currently, relationship information for accounting\nconsolidation parents, for branches and for funds are defined within the Global LEI System.\nAccounting consolidating parent relationship\nAccounting consolidating parent relationship information is based on existing accounting definitions\nimplemented in the International Financial Reporting Standard (IFRS) or the United States Generally\nAccepted Accounting Principles (US GAAP), but other accounting standards are also accepted.\nThe direct accounting consolidating parent of Legal Entity X would be defined as the lowest level\nLegal Entity that prepares consolidated financial statements that consolidate entity X, based on the\naccounting definition of consolidation applying to this parent.\nThe ultimate accounting consolidating parent of entity X would be the highest level Legal Entity\npreparing consolidated financial statements that consolidate entity X, based on the accounting\ndefinition of consolidation applying to this parent. The ultimate accounting consolidating parent\nSHALL NOT have accounting consolidating parent relationships of its own.\nAccording to the definitions of direct and ultimate parents, a Legal Entity cannot declare a\nconsolidation relationship for one parent and a non-consolidating exception for the other. If the\ndirect accounting consolidation parent is controlled, but not consolidated, by another entity, it is also\nconsidered to be the ultimate parent within the Global LEI System (see Figure 1). Likewise, if the child\nLegal Entity is controlled, but not consolidated, by an entity that itself is controlled by an entity\nconsolidating the child Legal Entity, the consolidating entity would be both direct and ultimate parent\n(see Figure 2, example b).\nBy the same definition, only entities with two non-consolidating exceptions can be viable candidates\nfor being declared as an ultimate parent of another entity. GLEIF created a set of data quality checks\nto ensure compliance with this requirement, assigning errors to both the LEl issuer of the child Legal\nEntity record and of the ultimate parent record when inconsistent parent relationships are detected.\nIt is expected that LEl issuers, as part of the Validation and Verification of Level 2 data, check if the\nultimate parent identified by an LEI has consistent parent information. LEl issuer SHALL use LEI\nSearch 2.0, Level 2 XML files (relationship and exception files) and/or Golden Copy files to identify\ninformation regarding the ultimate parent's relationships (if any).\nState Transition and Validation Rules for Common Data File formats Page 15 of 170\n@ Public Version 2.7.1 Final\nG 2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2755,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.795Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o LegalEntityEventEffectiveDate SHALL be the date the Demerger becomes effective in the\nLegal Jurisdiction of the new Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no AffectedFields SHALL be omitted.\nO Demerger O\n—>\nLEI A LEIB\nLEIA LEI B (Create new LEI Record Set)\nEntity: Entity:\no SuccessorEntity: LEI B o EntityCreationDate:\no 2020-04-12T00:00:00+02:00\nLegalEntityEvent:\no @group_type: STANDALONE Relationship:\no @event_status: COMPLETED o Create accounting consolidation\n+ LegalEntityEventType: DEMERGER relationship(s)\no LegalEntityEventEffectiveDate: o RelationshipPeriodStartDate:\no 2020-04-12T00:00:00+02:00 o 2020-04-12T00:00:00+02:00\n+ LegalEntityEventRecordedDate: © RelationshipPeriodType:\n+ 2020-04-20T00:00:00+02:00 RELATIONSHIP_PERIOD\n° ValidationDocuments: L LaStUpdateDate: 2020-04-20T13:43:25+02:00\nSUPPORTING_DOCUMENTS\n« ValidationReference: LegalEntityEvent:\nhttp://registry.gov/evidence.pdf © @group_type: STANDALONE\no @event_status: COMPLETED\nAffectedFields: o LegalEntityEventType: DEMERGER\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/I ¢ LegalEntityEventEffectiveDate:\nei:Entity/lei:SuccessorEntity/lei:Successor e 2020-04-12T00:00:00+02:00\nLEI: LEI B o LegalEntityEventRecordedDate:\no 2020-04-20T00:00:00+02:00\no ValidationDocuments:\nSUPPORTING_DOCUMENTS\no ValidationReference:\nhttp://registry.gov/evidence.pdf\nExample 13: The Legal Entity with LEI A is separated into LEI B with effective date April 12, 2020. The Legal Entity with LEI\nA continues to exist. The LEI Record Sets of LEI A and LEI D have been updated on the same date April 20, 2020.\nState Transition and Validation Rules for Common Data File formats Page 141 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1838,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.795Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.13.13 Legal Entity Event — Spin-off\nA part, division or Subsidiary of Legal Entity A (general Legal Entity) is separated into Legal Entity B,\nwhich could be a new or existing Legal Entity. In case of an existing Legal Entity B, Legal Entity B will\nno longer remain as a Subsidiary of Legal Entity A after completion of the Spin-off. Part of Legal Entity\nA’s shares/assets and liabilities are transferred to Legal Entity B; shareholders of Legal Entity A are\ncompensated for the asset value or loss by either receiving shares from Legal Entity B or via dividend.\nThe LEl issuer managing the LEI Record Set of Legal Entity A SHALL:\no Provide a SuccessorEntity.\no Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be SPINOFF.\no LegalEntityEventEffectiveDate SHALL be the date the Spin-off becomes effective in the Legal\nJurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no If @event_status is IN_PROGRESS or COMPLETED, the LEl issuer SHALL provide information\nregarding the AffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide lei:SuccessorEntity\nThe LEl issuer managing the LEI Record Set of Legal Entity B SHALL:\no Create a new LEI Record for the new Legal Entity B (see Use Case 4.1), if applicable.\no Retire any excisting relationships between Legal Entity B and Legal Entity A, if Legal Entity B\nalready exists,\no Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be COMPLETED, in case a new Legal Entity is created.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED, in case\nLegal Entity B already existed before the Spin-off.\no @group_id SHALL be omitted.\nState Transition and Validation Rules for Common Data File formats Page 142 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2110,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.796Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be SPINOFF.\no LegalEntityEventEffectiveDate SHALL be the date the Spin-off becomes effective in the\nLegalljurisdiction of the new Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no AffectedFields SHALL be omitted.\nO Spin-off O\n—>\nLEI A LEIB\nLEIA LEI B (existing entity, prev. subsidiary)\nEntity: Relationship:\no SuccessorEntity: LEI B o RelationshipStatus: RETIRED\no RelationshipPeriodEndDate:\nLegalEntityEvent: e 2020-04-18T00:00:00+02:00\n© @group_type: STANDALONE o RelationshipPeriodType:\no @event_status: COMPLETED RELATIONSHIP_PERIOD\n© LegalEntityEventType: SPINOFF o LastUpdateDate: 2020-04-20T13:43:25+02:00\no LegalEntityEventEffectiveDate:\no 2020-04-18T00:00:00+02:00 LegalEntityEvent:\no LegalEntityEventRecordedDate: o @group_type: STANDALONE\no 2020-04-20T00:00:00+02:00 o @event_status: COMPLETED\no ValidationDocuments: o LegalEntityEventType: SPINOFF\nSUPPORTING_DOCUMENTS o LegalEntityEventEffectiveDate:\no ValidationReference: e 2020-04-18T00:00:00+02:00\nhttp://registry.gov/evidence.pdf o LegalEntityEventRecordedDate:\no 2020-04-20T00:00:00+02:00\nAffectedFields: o ValidationDocuments:\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/| SUPPORTING_DOCUMENTS\nei:Entity/lei:SuccessorEntity/lei:Successor o ValidationReference:\nLEI: LEIB http://registry.gov/evidence.pdf\nExample 14: The Legal Entity with LEI A is separated into LEI B with effective date April 18, 2020. The Legal Entity with LEI\nA continues to exist. The former relationship record between LEI B and LEI A is set to RegistrationStatus RETIRED. The LEI\nRecord Sets of LEI A and LEI B have been updated on the same date April 20, 2020.\nState Transition and Validation Rules for Common Data File formats Page 143 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1934,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.796Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"O Spin-off O\n—>\nLEIA LEIB\nLEI A\nEntity: LEl B (new entity, prev. division of A)\ne SuccessorEntity: LEI B\nEntity:\nLegalEntityEvent: o EntityCreationDate:\n« @group_type: STANDALONE + 2020-04-18T00:00:00+02:00\no @event_status: COMPLETED\no LegalEntityEventType: SPINOFF LegalEntityEvent:\no LegalEntityEventEffectiveDate: © @group_type: STANDALONE\no 2020-04-18T00:00:00+02:00 ¢ @event_status: COMPLETED\no LegalEntityEventRecordedDate: o LegalEntityEventType: SPINOFF\ne 2020-04-20T00:00:00+02:00 o LegalEntityEventEffectiveDate:\no ValidationDocuments: e 2020-04-18T00:00:00+02:00\nSUPPORTING_DOCUMENTS o LegalEntityEventRecordedDate:\ne ValidationReference: e 2020-04-20T00:00:00+02:00\nhttp://registry.gov/evidence.pdf o ValidationDocuments:\nSUPPORTING_DOCUMENTS\nAffectedFields: o ValidationReference:\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/I http://registry.gov/evidence.pdf\nei:Entity/lei:SuccessorEntity/lei:Successor\nLEI: LEI B\nExample 15: The Legal Entity with LEI A is separated into LEI B with effective date April 18, 2020. The Legal Entity with LEI\nA continues to exist. The entity for LEI Record Set B has been created as a result of the Spin Off on April 20, 2020.\n4.13.14 Legal Entity Event — Transformation of an International Branch to a\nSubsidiary\nInternational Branch A of (head office) Legal Entity B, is separated from Legal Entity B and becomes a\nnew Legal Entity C, a Subsidiary of Legal Entity B; part of Legal Entity B’s shares/assets and liabilities\nare transferred to new Legal Entity C.\nThe LEl issuer managing the LEI Record of Legal Entity A SHALL:\ne Retire the LEI Record Set of Legal Entity A:\n\no Set RegistrationStatus to RETIRED.\n\no Set RegistrationStatus of all current Relationship Records to RETIRED with RelationshipStatus\nINACTIVE; set EndDate of RelationshipPeriod with PeriodType RELATIONSHIP_PERIOD as\nEffective Date of the LegalEntityEvent (see below).\n\no Set Legal Entity C as SuccessorEntity.\n\no Create a new LegalEntityEvent with:\nState Transition and Validation Rules for Common Data File formats Page 144 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2162,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.796Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o @group_type SHALL be STANDALONE.\n\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\n\no @group_id SHALL be omitted.\n\no @group_sequence_no SHALL be omitted.\n\n+ LegalEntityEventType SHALL be TRANSFORMATION_BRANCH_TO_SUBSIDIARY.\n\no LegalEntityEventEffectiveDate SHALL be the date the transformation becomes effective in\nthe Legal Jurisdiction of the Legal Entity.\n\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\n\no If @event_status is IN_PROGRESS, or COMPLETED, the LEl issuer SHALL provide information\nregarding the AffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide lei:SuccessorEntity\n\ne The LEl issuer managing the LEI Record of the new Legal Entity C SHALL:\n\no Create new LEI Records for the new Legal Entity(ies) (see section 4.1)\n\no Create a new accounting consolidation relationship(s) with Legal Entity B, as applicable;\nStartDate of the RelationshipPeriod with PeriodType RELATIONSHIP_PERIOD SHALL be the\nLegalEntityEventEffectiveDate that the Legal Entity event became effective in the Legal\nJurisdiction of the new Legal Entity (see below).\n\no Create a new LegalEntityEvent with:\n\no @group_type SHALL be STANDALONE.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no @event_Status SHALL be COMPLETED\n+ LegalEntityEventType SHALL be TRANSFORMATION_BRANCH_TO_SUBSIDIARY.\no LegalEntityEventEffectiveDate SHALL be the date the transformation becomes effective in\nthe Legal Jurisdiction of the new Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no AffectedFields SHALL be omitted.\nState Transition and Validation Rules for Common Data File formats Page 145 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1862,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.796Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"0\nFormer NTERNAW s\\mw&mwcomm DATED_BY\nSucceeded by\n—>\nS %\no LEIA LEI C (Create new LEI Record Set)\nEntity: Entity:\no SuccessorEntity: LEI C o EntityCreationDate:\ne 2020-04-17T00:00:00+02:00\nRegistration:\no RegistrationStatus: RETIRED Relationship:\no LastUpdateDate: 2020-04-20T13:43:25+02:00 o Create accounting consolidation\nrelationship(s)\nRelationship: o RelationshipPeriodStartDate:\no RelationshipPeriodEndDate: e 2020-04-17T00:00:00+02:00\ne 2020-04-17T00:00:00+02:00 o RelationshipPeriodType:\no RelationshipPeriodType: RELATIONSHIP_PERIOD\nRELATIONSHIP_PERIOD o LastUpdateDate: 2020-04-20T13:43:25+02:00\nRelationship Registration: LegalEntityEvent:\no RegistrationStatus: RETIRED o @group_type: STANDALONE\no @event_status: COMPLETED\nLegalEntityEvent: + LegalEntityEventType:\n° (@group_type: STANDALONE TRANSFORMATION_BRANCH_TO_SUBSIDIARY\n¢ @event_status: COMPLETED o LegalEntityEventEffectiveDate:\n¢ LegalEntityEventType: e 2020-04-17T00:00:00+02:00\nTRANSFORMATION_BRANCH_TO_SUBSIDIARY + LegalEntityEventRecordedDate:\no LegalEntityEventEffectiveDate: o 2020-04-20T00:00:00+02:00\n° 2020-04-17T00:00:00+02:00 o ValidationDocuments:\no LegalEntityEventRecordedDate: SUPPORTING_DOCUMENTS\no 2020-04-20T00:00:00+02:00 o ValidationReference:\n¢ ValidationDocuments: http://registry.gov/evidence.pdf\nSUPPORTING_DOCUMENTS\no ValidationReference:\nhttp://registry.gov/evidence.pdf\nAffectedFields:\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:E\nntity/lei:SuccessorEntity/lei:SuccessorLEl: LEI\nC\nExample 16: The Legal Entity with LEI A, which is an International Branch of LEI B, is transformed into a Subsidiary of LEI B\nwith effective date April 17, 2020. The Legal Entity with LEI B is now the direct and/or ultimate parent of LEI C. The Legal\nentity with LEI A ceases to exist and a new Legal Entity with LEI C is created as successor of LEI A. The LEI Record Sets of\nLEI A and LEI C have been updated on the same date April 20, 2020.\nState Transition and Validation Rules for Common Data File formats Page 146 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2120,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.796Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.13.15 Legal Entity Event — Bankruptcy\nLegal Entity A (general Legal Entity or Government Entity) declares Bankruptcy based on the laws of\nits jurisdiction. During the process, the Legal Entity could no longer be operational, and could still\nexist as Legal Entity. Once the process is completed, all or part of the Legal Entity could survive, and\nthe LEI remains ISSUED or the Legal Entity could become inactive and the LEIl is RETIRED. Bankruptcy\nevents are often followed by Liquidation, Insolvency or Dissolution events which will determine the\nfinal status of the Legal Entity and its LEI.\nWhile the Bankruptcy is in progress, the LEl issuer managing the LEI Record Set of Legal Entity A\nSHALL:\no Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status MAY be IN_PROGRESS.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be BANKRUPTCY.\no LegalEntityEventEffectiveDate SHALL be the date the Bankruptcy becomes effective in the\nLegal Jurisdiction of Legal Entity A.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no If @event_status is IN_PROGRESS or COMPLETED, the LEl issuer SHALL provide information\nregarding the AffectedFields: For @field_xpath the LEl issuer usually\no MAY provide lei:SuccessorEntity\no Keep the LEI Record Set of Legal Entity A as it is, but check if a change in legal name and/or in\nlegal form applies; create the respective Legal Entity Events, including all other LEI Record Set\nupdates, if necessary. Depending on the laws and regulations in the Legal Entity’s jurisdiction, the\nchange in legal form and/or legal name MAY already be effective, in which case the\n@event_status of these events SHALL be COMPLETED rather than IN_PROGRESS.\nOnce the Bankruptcy event is completed the LEl issuer managing the LEI Record Set of entity A\nSHALL:\no Create a new LegalEntityEvent with:\no @event_status SHALL be COMPLETED.\no LegalEntityEventEffectiveDate SHALL be the date the Bankruptcy becomes effective in the\nLegal Jurisdiction of Legal Entity A.\nState Transition and Validation Rules for Common Data File formats Page 147 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2291,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.796Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no AffectedFields SHALL be omitted.\nState Transition and Validation Rules for Common Data File formats Page 148 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":322,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.796Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Bankruptcy\n- O O o Oy >\nS S\nIn-progress Event Post Event\nLEI A LEI A\nLegalEntityEvent: Registration:\no @group_type: STANDALONE o RegistrationStatus: RETIRED\no @event_status: IN_PROGRESS\no LegalEntityEventType: BANKRUPTCY Relationship:\no LegalEntityEventEffectiveDate: o Create accounting consolidation relationship(s)\no 2020-09-08T00:00:00+02:00 o RelationshipPeriodEndDate:\no LegalEntityEventRecordedDate: e 2020-04-19T00:00:00+02:00\ne 2020-02-09T00:00:00+02:00 o RelationshipPeriodType: RELATIONSHIP_PERIOD\no ValidationDocuments: o LastUpdateDate:\nSUPPORTING_DOCUMENTS e 2020-04-20713:43:25+02:00\ne ValidationReference:\nhttp://registry.gov/evidence.pdf LegalEntityEvent:\no @group_type: STANDALONE\no @event_status: IN_PROGRESS\no LegalEntityEventType: BANKRUPTCY\nExample 17: The Legal Entity LEI A goes ¢ LegalEntityEventEffectiveDate:\nbankrupt. The process of Bankruptcy was e 2020-09-08T00:00:00+02:00\nscheduled to end on September 8, 2020 and o LegalEntityEventRecordedDate:\nwas recorded in the Global LEI System on s 2020-02-09T00:00:00+02:00\nFebruary 9, 2020. In this example, no « ValidationDocuments: SUPPORTING_DOCUMENTS\nrelevant information describing the Legal s -\nEntity is changed and therefore no ‘ Valldatlon'Reference: .\nAffectedFields are included. The Bankruptcy http://registry.gov/evidence.pdf\nwas completed on October 19, 2020 behind\nschedule. The completion of the Legal Entity LegalEntityEvent:\nEvent was recorded in the Global LEI System o @group_type: STANDALONE\non November 20, 2020. As a consequence of s @event_status: COMPLETED\nthe bankruptcy, the Legal Entity has ceased o LegalEntityEventType: BANKRUPTCY\nto exist due toa dissomtio.n even.t on o LegalEntityEventEffectiveDate:\nDecember 19, 2020. The dissolution was\nrecorded in the Global LEI System on ¢ 2020-10-19T00:00:00+02:00\nDecember 20, 2020. o LegalEntityEventRecordedDate:\ne 2020-11-20T00:00:00+02:00\nLegalEntityEvent:\no @group_type: STANDALONE\no @event_status: COMPLETED\no LegalEntityEventType: DISSOLUTION\no LegalEntityEventEffectiveDate:\ne 2020-12-19T00:00:00+02:00\no LegalEntityEventRecordedDate:\ne 2020-12-20T00:00:00+02:00\ne ValidationDocuments: SUPPORTING_DOCUMENTS\ne ValidationReference:\nhttp://registry.gov/evidence.pdf\nState Transition and Validation Rules for Common Data File formats Page 149 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2413,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.796Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.13.16 Legal Entity Event — Insolvency\n\nLegal Entity A (general Legal Entity or Government Entity) declares itself insolvent based on the laws\nof its jurisdiction. This Legal Entity Event is handled like a Bankruptcy, except for the different\nLegalEntityEventType recorded.\n\nIn contrast to Bankruptcy, the LEl issuer managing the LegalEntityEvent of Legal Entity A SHALL:\n\no Use INSOLVENCY as LegalEntityEventType.\n\n4.13.17 Legal Entity Event — Liquidation\n\nLegal Entity A (general Legal Entity or Government Entity) closes all business activities due to\nLiguidation. This Legal Entity Event always leads to the retirement of the LEl and the Legal Entity\nbecoming INACTIVE when the Legal Entity Event reached @event_status COMPLETED. Liquidation\ncan be the result of a Bankruptcy or of an Insolvency.\n\nThe LEl issuer managing the LEI Record Set of Legal Entity A SHALL:\n\no Retire the LEI Record Set of Legal Entity A, if @event_status is COMPLETED:\n\no Set RegistrationStatus to RETIRED.\n\no Set EntityStatus to INACTIVE.\n\no Set RegistrationStatus of all current Relationship Records to RETIRED with RelationshipStatus\nINACTIVE; set EndDate of RelationshipPeriod with PeriodType RELATIONSHIP_PERIOD as\nEffective Date of the LegalEntityEvent (see below).\n\no Create a new LegalEntityEvent with:\n\no @group_type SHALL be STANDALONE.\n\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\n\no @group_id SHALL be omitted.\n\no @group_sequence_no SHALL be omitted.\n\no LegalEntityEventType SHALL be LIQUIDATION.\n\no LegalEntityEventEffectiveDate SHALL be the date the LIQUIDATION becomes effective in the\nLegal Jurisdiction of Legal Entity A.\n\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\n\no If @event_statusis IN_PROGRESS or COMPLETED, the LEl issuer SHALL provide information\nregarding the AffectedFields: For @field_xpath the LEl issuer usually\no MAY provide lei:SuccessorEntity\n\nState Transition and Validation Rules for Common Data File formats Page 150 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2131,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.796Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Non-consolidating Non-consolidating\nException Exception\n%}T PARENT\\/ULTIMATE/PA\\RENT\n@\\?\nDIRECT PARENT\n@ EJ‘LTIMI/\\TE PARE;\\]T\n\\I: \\\"\\ ULTIMATE PARENT\nA ! ULTIMATE PARENT\nULTIMATE PARENT /\nDIRECT PARENT\nFigure 1: General view on one complete network chain and the representation of the Relationship Records to the\nultimate parent LEI.\nChild reporting (bottom-up) principle\nInitially only child entities may report level 2 data (the relationship information to their parent\nentities) to minimize difficulties arising from complex Business Rules dependent on the reporting\nentity and de-duplication. This also covers a parent entity instructing its child entity or entities to\nreport parent information, and also delegated reporting by a parent entity on behalf of any child\nentities.\nGiven this rule, reporting of child entities without an LEl is NOT possible under any circumstance.\nState Transition and Validation Rules for Common Data File formats Page 16 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1067,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.796Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.13.18 Legal Entity Event — Dissolution\nLegal Entity A (general Legal Entity of Government Entity) voluntarily closes all business activities.\nThis Legal Entity Event always leads to the retirement of the LElI and the Legal Entity becoming\nINACTIVE when the Legal Entity Event reached @event_status COMPLETED. This Legal Entity Event is\nhandled like Liquidation, except for the different Legal EntityEventType and the different expected\n@field_xpath.\nIn contrast to Liquidation, the LEl issuer managing the LEI Record Set of Legal Entity A SHALL create a\nnew LegalEntityEvent with:\no LegalEntityEventType SHALL be DISSOLUTION.\no If @event_status is IN_PROGRESS or COMPLETED, the LEl issuer SHALL provide information\nregarding the AffectedFields: For @field_xpath the LEl issuer usually\no MAY provide lei:SuccessorEntity\n4.13.19 Legal Entity Event — Voluntary Arrangement\nA company Voluntary Arrangement (CVA) allows a Legal Entity A (general Legal Entity or Government\nEntity) to negotiate with its creditors the settlement of any debts by paying only a portion of the\namounts owed or by some other arrangement to pay the debt. This Legal Entity Event does not lead\nto retirement of the LEL.\nThe LEl issuer managing the LEI Record Set of Legal Entity A SHALL:\no Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be VOLUNTARY_ARRANGEMENT\no @event_status SHALL be IN_PROGRESS.\no LegalEntityEventEffectiveDate SHALL be the date the CVA becomes effective in the Legal\nJurisdiction of Legal Entity A.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no AffectedFields SHALL be omitted.\nOnce the CVA is completed, the LEl issuer managing the LEI Record Set of entity A SHALL:\nState Transition and Validation Rules for Common Data File formats Page 151 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2068,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.796Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be COMPLETED\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be VOLUNTARY_ARRANGEMENT.\no LegalEntityEventEffectiveDate SHALL be the date the CVA becomes effective in the Legal\nJurisdiction of Legal Entity A.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no AffectedFields SHALL be omitted.\nState Transition and Validation Rules for Common Data File formats Page 152 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":675,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.797Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"O Voluntary Arrangement O\n_————’\nLEI A LEI A\nPre Event Post Event\nLEI A LEI A\nLegalEntityEvent: LegalEntityEvent:\no @group_type: STANDALONE o @group_type: STANDALONE\no @event_status: IN_PROGRESS o @event_status: IN_PROGRESS\no LegalEntityEventType: o LegalEntityEventType:\nVOLUNTARY_ARRANGEMENT_IN_PROGRESS VOLUNTARY_ARRANGEMENT_IN_PROGRESS\no LegalEntityEventEffectiveDate: [ ] o LegalEntityEventEffectiveDate: [ ]\no LegalEntityEventRecordedDate: o LegalEntityEventRecordedDate:\ne 2020-03-05T09:00:00+02:00 e 2020-03-05T09:00:00+02:00\no ValidationDocuments: CONTRACTS o ValidationDocuments: CONTRACTS\nLegalEntityEvent:\no @group_type: STANDALONE\no @event_status: COMPLETED\no LegalEntityEventType:\nVOLUNTARY_ARRANGEMENT\no LegalEntityEventEffectiveDate:\no 2020-04-19T00:00:00+02:00\no LegalEntityEventRecordedDate:\no 2020-04-20T09:00:00+02:00\no ValidationDocuments: CONTRACTS\nExample 18: Legal Entity LEI A engages in a company Voluntary Arrangement without any knowledge regarding the\nexpected effective date. The process of the Voluntary Arrangement was recorded in the Global LEI System on March 5,\n2020. The Voluntary Arrangement was completed on April 19, 2020. The completion of the Legal Entity Event was\nrecorded in the Global LEI System on April 20, 2020.\nState Transition and Validation Rules for Common Data File formats Page 153 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1452,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.797Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.13.20 Legal Entity Event — Reverse Takeover\nA Reverse Takeover describes the following scenario:\n1. Entity Bis acquired by entity A\n2. Entity Ais absorbed by B\n3. Entity B changes its LegalName to A\nThe result has a surviving entity with the original LegalName of entity A and the LEI of entity B. The\nLEI Record of entity A will be RETIRED and point to the LEI of entity B as SuccessorEntity.\nTo record this Legal Entity Event, the LEl issuer of entity A SHALL update the LEI Record as following:\no Set RegistrationStatus RETIRED.\no Set Legal Entity B as SuccessorEntity.\ne Set current relationships to RETIRED, if applicable.\no Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED, based on\nthe status of the event (see section 4.13.1).\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be MERGERS_AND_ACQUISITIONS.\n¢ LegalEntityEventEffectiveDate SHALL be the date the Reverse Takeover becomes effective in\nthe Legal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\n¢ ValidationDocument and the optional ValidationReference SHALL indicate the sources used\nfor validating the Legal Entity Event.\no If @event_statusis IN_PROGRESS or COMPLETED, the LEl issuer SHALL provide information\nregarding the AffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide lei:SuccessorEntity\nThe LEl issuer of entity B SHALL record the Reverse Takeover event as a group of three events, linked\ntogether and set in the correct sequence order:\n¢ Create a new LegalEntityEvent with:\no @group_type SHALL be REVERSE_TAKEOVER.\nState Transition and Validation Rules for Common Data File formats Page 154 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1935,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.797Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be a unique identifier (e.g., a hash value calculated from the combination\nof the LEl, EventType and EffectiveDate).\no @group_sequence_no SHALL be 1 (one).\no LegalEntityEventType SHALL be MERGERS_AND_ACQUISITIONS.\n¢ LegalEntityEventEffectiveDate SHALL be the date the Reverse Takeover becomes effective in\nthe Legal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\n¢ ValidationDocument and the optional ValidationReference SHALL indicate the sources used\nfor validating the Legal Entity Event.\no AffectedFields SHALL be omitted.\ne Create a new LegalEntityEvent with:\no @group_type SHALL be REVERSE_TAKEOVER.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be the same unique identifier used for the previous event.\no @group_sequence_no SHALL be 2 (two).\no LegalEntityEventType SHALL be ABSORPTION.\no LegalEntityEventEffectiveDate SHALL be the same date as for the previous event.\no LegalEntityEventRecordedDate SHALL be the same date as for the previous event.\n¢ ValidationDocument and the optional ValidationReference SHALL indicate the sources used\nfor validating the Legal Entity Event.\no AffectedFields SHALL be omitted.\no Create a new LegalEntityEvent with:\no @group_type SHALL be REVERSE_TAKEOVER.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be the same unique identifier used for the previous event.\no @group_sequence_no SHALL be 3 (three).\no LegalEntityEventType SHALL be CHANGE_LEGAL_NAME.\nG State Transition and Validation Rules for Common Data File formats Page 155 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1855,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.797Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o LegalEntityEventEffectiveDate SHALL be the same date as for the previous event.\no LegalEntityEventRecordedDate SHALL be the same date as for the previous event.\n¢ ValidationDocument and the optional ValidationReference SHALL indicate the sources used\nfor validating the Legal Entity Event.\no If @event_statusis IN_PROGRESS, the LEl issuer SHALL provide information regarding the\nAffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide lei:LegalName\no MAY provide lei:OtherEntityNames\no MAY provide lei:TransliteratedOtherEntityNames\n¢ The LegalName of LEI B SHALL change to LegalName of LEI A.\nState Transition and Validation Rules for Common Data File formats Page 156 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":796,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.797Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"1 Acquired by\nA/Z/-\\bs;edby\\\n_—mmm\nS S\nLEI A LEI B\nEntity: Entity:\no “SuccessorEntity: LEI B” o LegalName: “Company B.V.“\no LegalName: Company B.V.\nLegalEntityEvent:\nRegistration: o @group_type: REVERSE_TAKEOVER\no RegistrationStatus: RETIRED o @event_status: COMPLETED\no @group_id: dfecd444f23463443a98n12a\nRelationship: o @group_sequence_no: 1\n* Remove ReportingExceptions o LegalEntityEventType:\no lastUpdateDate: 2020-04-20T13:43:25+02:00 MERGERS_AND_ACQUISITIONS\no LegalEntityEventEffectiveDate:\nRelationship Registration: © 2020-04-19T00:00:00+02:00\n* RegistrationStatus: RETIRED o LegalEntityEventRecordedDate:\no 2020-04-20T00:00:00+02:00\nLegalEntityEvent: « ValidationDocuments: ACCOUNTS_FILING\no @group_type: STANDALONE\no @event_status: COMPLETED LegalEntityEvent:\n© LegalEntityEventType: o @group_type: REVERSE_TAKEOVER\nMERGERS_AND_ACQUISITIONS s @event_status: COMPLETED\n© LegalEntityEventEffectiveDate: + @group_id: dfecd444f23463443a98n12a\n© 2020-04-19T00:00:00+02:00 « @group_sequence_no: 2\n© LegalEntityEventRecordedDate: + LegalEntityEventType: ABSORPTION\n¢ 2020-04-20T11:30:00+02:00 » LegalEntityEventEffectiveDate:\no ValidationDocuments: ACCOUNTS_FILING s 2020-04-19T00:00:00+02:00\no ValidationReference: Consolidated financial + LegalEntityEventRecordedDate:\nstatement o 2020-04-20T11:30:00+02:00\no ValidationDocuments: ACCOUNTS_FILING\nAffectedFields:\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:E LegalEntityEvent:\nntity/lei:SuccessorEntity/lei:SuccessorLEl: « @group_type: REVERSE_TAKEOVER\nLEI B + @event_status: COMPLETED\no @group_id: dfecd444f23463443a98n12a\no (@group_sequence_no: 3\no LegalEntityEventType: CHANGE_LEGAL_NAME\no LegalEntityEventEffectiveDate:\no 2020-04-19T00:00:00+02:00\no LegalEntityEventRecordedDate:\ne 2020-04-20T11:30:00+02:00\no ValidationDocuments: ACCOUNTS_FILING\nExample 19: Reverse Takeover\nState Transition and Validation Rules for Common Data File formats Page 157 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2050,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.797Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.13.21 Legal Entity Event — Transformation of an Umbrella Fund to a Stand-Alone\nFund\nWhen an umbrella fund A is converted into a stand-alone fund, all sub-funds/compartments of\numbrella fund A (fund entities with a IS_SUBFUND_OF relationship with umbrella fund A) are either\nmerged into umbrella fund A or need to be separated from umbrella fund A with a different Legal\nEntity Event recorded for the sub-fund(s). This Use Case assumes, that all (remaining) sub-funds are\nmerged into the umbrella fund prior to the conversion.\nThe LEl issuer managing the LEI Record Sets of any sub-fund of umbrella fund A SHALL:\ne Set the sub-fund relationship to RETIRED.\no Set the RegistrationStatus of each sub-fund to RETIRED.\no Set the umbrella fund as SuccessorEntity.\nThe LEl issuer managing the LEl Record Sets of umbrella fund entity A SHALL:\no Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED, based on\nthe status of the event (see section 4.13.1).\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be TRANSFORMATION_UMBRELLA_TO_STANDALONE.\no LegalEntityEventEffectiveDate SHALL be the date the transformation becomes effective in\nthe Legal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no If @event_statusis IN_PROGRESS or COMPLETED, the LEl issuer SHALL provide information\nregarding the AffectedFields: For @field_xpath the LEl issuer usually\no MAY provide lei:SuccessorEntity\n4.13.22 Legal Entity Event — Effects on parent and child relationships\nA Legal Entity Event applied to a Legal Entity can also affect all relationships where the entity is the\nEndNode (parent). Several cases have already been described above. In addition, there is need to\nlook at cases if the parent Legal Entity is RETIRED and hence no longer active or if a Legal Entity that\nwas an ultimate parent has been acquired and now has parent relationships.\nState Transition and Validation Rules for Common Data File formats Page 158 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2246,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.797Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"As soon as the LEl issuer of any child Legal Entity is aware of the retirement of the parent, the LEI\n\nissuer SHALL:\n\no Update all affected relationships to RETIRED.\n\no Create new Relationship Records or reporting exceptions, as applicable.\n\ne The LEl issuer of the child entity works with the child Legal Entity to record the new direct or\nultimate parent Legal Entity relationship.\n\nThe LEl issuer of the child Legal Entity can be informed about the change in the parent’s\n\nRegistrationStatus either\n\no by the child Legal Entity at the time of renewal,\n\n* viathe challenge process\n\ne orduring the course of normal business operations\n\nGiven the LEl issuer of the parent Legal Entity becomes aware of this change to the parent Legal\n\nEntity via the challenge process or during the course of normal business, the LEl issuer should notify\n\nthe LEl issuer of the child Legal Entity and request the LEl issuer of the child Legal Entity to provide\n\nupdated information on the direct or ultimate parent Legal Entity.\n\no If the child Legal Entity has active Relationship Records with rr:RegistrationStatus PUBLISHED or\n\nLAPSED reported, these are updated as follows:\n\no RelationshipStatus SHALL be INACTIVE.\n\no rr:RegistrationStatus SHALL be RETIRED.\n\no RelationshipPeriods with PeriodType RELATIONSHIP_PERIOD SHALL have EndDate populated\nwith the date the parent Legal Entity ceased to exist (same as the\nLegalEntityEventEffectiveDate that retired the parent Legal Entity).\n\no Relationship Records that are already RETIRED, DUPLICATE or ANNULLED are not updated.\n\no The LEl issuer of the child Legal Entity creates a new set of relationship data for the direct and/or\n\nultimate parent Legal Entity based on the updated information.\n\nFor an International Branch relationship, if the (head office) Legal Entity it belongs to merges or\n\nretires and is no longer active, the LEI Record Set of a Branch needs to be updated as well. Either the\n\n(head office) Legal Entity or the International Branch notifies their LEIl issuer at the time of renewal,\n\nthe LEl issuer is made aware via the challenge process, or the LEl issuer becomes aware of the (head\nState Transition and Validation Rules for Common Data File formats Page 159 of 170\n\n@ Public Version 2.7.1 Final\n\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2328,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.797Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"office) Legal Entity retiring during the course of normal business. The LEl issuer of the International\nBranch SHALL change the Branch entity’s LElI Record Set to the RegistrationStatus of RETIRED to have\nthe same status as the (head office) Legal Entity (see above Use Cases 4.8.1 or 4.8.2 respectively).\n4.13.23 Legal Entity Event — Erroneously introduced Legal Entity Event\nIf a Legal Entity Event has been falsely introduced to the LEI Repository, the LEl issuer SHALL:\ne Continue uploading the erroneously introduced Legal Entity Event\no Create an additional Legal Entity Event with:\no @event_status WITHDRAWN_CANCELLED\no LegalEntityEventRecordedDate representing the date the event was cancelled\no All remaining reference data shall be identical to the erroneously introduced legal entity\nevent\nState Transition and Validation Rules for Common Data File formats Page 160 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":986,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.797Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"With the exception of branches, all Legal Entities SHALL report relationship data for both direct and\nultimate accounting consolidating parent. Each relationship SHALL be reported by either a\nRelationship Record or a Reporting Exception Record. See Figure 1 for possible combinations.\nOnly one parent Legal Entity per child may be reported per unique relationship type with published\nregistration status. Direct and ultimate parent can be the same Legal Entity, still the child reports one\nrelationship of each type. The parent entity can be represented by:\ne an LEl for those parent Legal Entities with an LEI;\no an exception with exception reason NO_LEl in case the parent Legal Entity does not have an LEI.\nDIRECT PARENT\\/ULHMATE PARENT DIRECT Pw PARENT\na) b)\nDIRECT PARENTVULTIMATE PARENT DIRECT PARENT\\/ ULTIMATE PARENT\nc) .H d) ‘a\nState Transition and Validation Rules for Common Data File formats Page 17 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1020,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.797Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"O Remediation of an incorrectly reported event O\nIntroduction of incorrect event Resolved incorrect event\nLEI A LEI A\nRegistration: Registration:\no RegistrationStatus: RETIRED o RegistrationStatus: ISSUED\no LastUpdateDate: 2020-01-23T08:41:00+02:00 o LastUpdateDate: 2020-01-25T10:42:00+02:00\nLegalEntityEvent: LegalEntityEvent:\no @group_type: STANDALONE o @group_type: STANDALONE\no @event_status: COMPLETED o @event_status: COMPLETED\no LegalEntityEventType: DISSOLUTION o LegalEntityEventType: DISSOLUTION\no LegalEntityEventEffectiveDate: o LegalEntityEventEffectiveDate:\ne 2020-01-20T00:00:00.000Z e 2020-01-20T00:00:00.000Z\no LegalEntityEventRecordedDate: o LegalEntityEventRecordedDate:\no 2020-01-23T08:41:00+02:00 o 2020-01-23T08:41:00+02:00\no ValidationDocuments: o ValidationDocuments:\nSUPPORTING_DOCUMENTS SUPPORTING_DOCUMENTS\no ValidationReference: o ValidationReference:\nhttp://registry.gov/evidence.pdf http://registry.gov/evidence.pdf\nLegalEntityEvent:\no @group_type: STANDALONE\no @event_status: WITHDRAWN_CANCELLED\no LegalEntityEventType: DISSOLUTION\no LegalEntityEventEffectiveDate:\ne 2020-01-20T00:00:00.000Z\no LegalEntityEventRecordedDate:\ne 2020-01-25T10:42:00+02:00\no ValidationDocuments:\nSUPPORTING_DOCUMENTS\no ValidationReference:\nhttp://registry.gov/evidence.pdf\nExample 20: LEI A was erroneously set to RETIRED on 23 January 2020 and a Legal Entity Event with LegalEntityEventType\nDISSOLUTION was introduced. The LEl issuer acknowledged the incorrect Legal Entity Event on 25 January 2020 and\ncreated an additional Legal Entity Event with @event_status WITHDRAWN_CANCELLED to indicate that the previously\nrecorded Legal Entity Event was incorrect. The RegistrationStatus of the LEI Record returns to ISSUED.\nState Transition and Validation Rules for Common Data File formats Page 161 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1920,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.797Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.14 Update of LEI Reference Data other than due to Legal Entity\nEvents\nThe Reference Data of an LEI Record Set may change without the occurrence of specific Legal Entity\nEvents, for instance due to data updated by the Legal Entity or challenged data. The LEl issuer is\nresponsible to verify changed or challenged Reference Data. If the LEl issuer is ultimately unable to\nfully corroborate Reference Data updated or confirmed by the Legal Entity, the Validation Sources\nmust change to PARTIALLY CORROBORATED or ENTITY_SUPPLIED_ONLY.\nWhenever an element of the Reference Data is updated, the respective LastUpdateDate (LEI Record\nor Relationship Records) SHALL be updated with the current date and time as well.\n4.15 LEI Record update — Registration information changes\nThis Use Case only applies where the registration information changes, and the Legal Entity remains\nan operating entity. Usually, this would happen as part of a Legal Entity Event (e.g.: legal form\nchange), but the registration information change does not trigger a Legal Entity Event itself.\nThe LEl issuer:\no SHALL update lei:RegistrationAuthority accordingly, following the general rules for Registration\nAuthority Reporting (see section 2.2.3).\no SHALL check, if an update to lei:ValidationAuthority, lei:ValidationOtherAuthorities and/or\nlei:ValidationSources is required.\nThis also includes cases where a non-reserved Registration Authority code is supplied for the first\ntime (see section 2.2.3 for the Transition Rules after an RA list update).\n4.16 LEI Record update — Reporting Exception changes to\nRelationship Records\nThis Use Case applies where the child Legal Entity reports a parent Legal Entity after initial opt-out\nreporting.\nThe LEl issuer:\no SHALL create the applicable Relationship Record(s) according to Use Cases 4.1.1 and/or 4.1.2.\ne SHALL remove the superseded reporting exception record(s) from publication.\nIf the ExceptionReason was NO_LEI, Use Case 4.11 applies instead.\nState Transition and Validation Rules for Common Data File formats Page 162 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2153,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.797Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.17 LEI Record Set update — Entity or Relationship Data changes\n\nThis Use Case applies where any data element in the entity data or the Relationship data or a\n\nreporting exception changes that is not the result of one of the other Use Cases (usually, this is only\n\nnecessary to amend registration or validation errors).\n\nThe LEl issuer:\n\ne SHALL update the respective data element(s) accordingly.\n\ne SHALL not make any additional changes, except for updating LastUpdateDate.\n\n4.18 LEI Record Set update — Change of fund manager\n\nThis Use Case applies when the management of a fund entity changes from fund manager with LEI A\n\nto fund manager with LEI B and the fund entity itself is still active.\n\nThe LEl issuer:\n\ne SHALL set the rr:RegistrationStatus of the fund relationship record with EndNodelD LEI A to\nRETIRED. The EndDate of the RelationshipPeriod with PeriodType RELATIONSHIP_PERIOD SHALL\nbe the date of the change.\n\ne SHALL introduce a new fund relationship record with rr:RegistrationStatus PUBLISHED with\nEndNodelD LEI B. The StartDate of the RelationshipPeriod with PeriodType\nRELATIONSHIP_PERIOD SHALL be the date of the change.\n\n4.19 LEI Record Set update — Transfer\n\nA Legal Entity's LEI Record can be transferred from one LEl issuer to another. All Relationship Records\n\n(active and inactive) are also transferred. The following sections describe the updates to the LEI\n\nRecord Set only. For details on timelines and responsibility, refer to the Supporting Documentation\n\nfor Transfers.\n\nIn general, only LEI Record Sets representing operational Legal Entities can be transferred\n\n(RegistrationStatus ISSUED or LAPSED). In rare cases, LEI Record Sets representing inactive Legal\n\nEntities (RegistrationStatus RETIRED) and even invalid records (RegistrationStatus DUPLICATE or\n\nANNULLED) will transfer from one LEl issuer to another. In such cases the Receiving LOU should\n\nprovide an explanation to the Sending LOU (e.g.: the closure of one LEl issuer).\n\nA transfer is initiated after the request from the Legal Entity by the Receiving LOU. The Receiving LOU\n\ninforms the Sending LOU about the transfer request, providing evidence for the authorization of the\n\nrequestor. The Sending LOU confirms the transfer with their contact to the Legal Entity. If no\nresponse from the Legal Entity can be received within the timeframe defined in supporting transfer\nprotocol documentation, the Sending LOU SHALL accept the transfer request.\nState Transition and Validation Rules for Common Data File formats Page 163 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2632,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.798Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Sending LOU Perspective:\n\nWhen the Sending LOU receives the transfer request, the LEI Record Set is updated as follows:\n\no lei:RegistrationStatus SHALL be PENDING_TRANSFER.\n\no rr:RegistrationStatus SHALL be PENDING_TRANSFER for all Relationship Records.\n\nWhen the Sending LOU confirms the transfer request and verifies that the updated\n\nRegistrationStatus is displayed in the Golden Copy, the LEI Record Set is updated as follows:\n\no lei:RegistrationStatus SHALL be PENDING_ARCHIVAL that was PENDING_TRANSFER before.\n\no rr:RegistrationStatus SHALL be PENDING_ARCHIVAL for all Relationship Records that were\nPENDING_TRANSFER before.\n\nThe Sending LOU verifies in the Golden Copy Files, generated by GLEIF, that its own LEI Record Set is\n\ndisplayed as PENDING_ARCHIVAL. After the Receiving LOU’s LEI Record Set is published in the Golden\n\nCopy, the Sending LOU updates their LElI Record Set as follows:\n\no lei:RegistrationStatus SHALL be TRANSFERRED that was PENDING_ARCHIVAL before and\nremoved from files uploaded to GLEIF.\n\no rr:RegistrationStatus SHALL be TRANSFERRED for all Relationship Records that were\nPENDING_ARCHIVAL before and removed from files uploaded to GLEIF.\n\ne All remaining Relationship Records and all Reporting Exception Records are removed from files\nuploaded to GLEIF.\n\nReceiving LOU Perspective:\n\nThe Receiving LOU validates all LEI Reference Data during transfer and once the Sending LOU\n\npublishes the LEI Record with RegistrationStatus PENDING_ARCHIVAL, the Receiving LOU SHALL\n\npublish a complete set of entity and relationship data, including historical and/or internal\nrelationships:\n\no lei:RegistrationStatus SHALL be ISSUED, unless, in very rare cases, the LEI Record was RETIRED,\nDUPLICATE or ANNULLED prior to the transfer request, in which case, the original\nRegistrationStatus is retained; the Receiving LOU SHALL NOT publish the LElI Record with\nRegistrationStatus LAPSED after the transfer is completed, even if that was the recorded status\npublished by the Sending LOU. All LAPSED LEIs SHALL be renewed during transfer.\n\nState Transition and Validation Rules for Common Data File formats Page 164 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2241,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.798Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o rr:RegistrationStatus SHALL be PUBLISHED for all ACTIVE Relationship Records; INACTIVE\nRelationship Records that were ANNULLED by the Sending LOU are retained with the\nRegistrationStatus they had prior to the transfer; the Receiving LOU SHALL keep historical\nRelationship Records unchanged except for amending data quality issues (e.g.: due to missing\nRelationshipPeriods).\n\no InitialRegistrationDate for all LEI Record Sets SHALL NOT be updated but retained as it was\nbefore the transfer (adapting to a different time zone is accepted but not required).\n\nFigure 10 further clarifies the transfer protocol. Each row represents a time unit, e.g., one business\n\nday.\n\nState Transition and Validation Rules for Common Data File formats Page 165 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":852,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.798Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Receiving LOU Sending LOU\nInitiation of Transfer\nThe Legal Entity informs its new\nmanaging LOU (Receiving LOU)\nrequesting a transfer. The LOU O\ncontacts the current managing LOU [RSUET, LACRED]\n(Sending LOU) and triggers a LEIA\ntransfer.\nO\\ PENDING_\nLEIA TRANSFER\nThe Sending LOU sends confirmation of the\nLEI Transfer request back to the Receiving\nLOU. The Sending LOU notifies the Legal\nEntity that the transfer will occur after 3\nbusiness days, if no objection is received.\nThe Transfer Objection Form is attached to\nthe notification.\nO\\ PENDING_\nLEIA ARCHIVAL\nThe Sending LOU receives\nconfirmation from the Legal Entity or\nthe Legal Entity has not responded\nwithin 3 business days.\nLEIA\nO\\ PENDING _\nThe Receiving LOU validates the LEIA ARCHIVAL\nmost recent data of the LEI Record\nSet and publishes the record.\nThe Sending LOU stops publishing\nthe LEI Record Set after the LEI\nO— Record Set appears in the Golden\nLEIA Copy Files generated by GLEIF with\nManagingLOU = Receiving LOU.\nTransfer Completed\nFigure 10: Exemplary timeline of an LEI transfer\nState Transition and Validation Rules for Common Data File formats Page 166 of 170\nGLEIF) Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1243,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.798Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.20 Registration errors — Exclusivity Violation (duplication)\nIf a Legal Entity has more than one LEI, the Legal Entity SHALL choose which LEI Record Set survives.\nIf the contact point for both LEls is non-responsive, then the earliest LEI survives. The DUPLICATE\nstatus is assigned to the non-surviving registration (i.e. the LEI that should no longer be used).\no lei:RegistrationStatus SHALL be DUPLICATE\ne SuccessorLElI SHALL be the LEI of the surviving registration\no for Branch entities, the survivor SHALL be another Branch entity in the same host jurisdiction; if\nthe Branch entity was registered in the same jurisdiction as the head office, lei:RegistrationStatus\nSHALL be ANNULLED instead (see Use Case 4.17 Registration error — Eligibility violation)\no rr:RegistrationStatus SHALL be ANNULLED for all relationships\nIf a parent Legal Entity (i.e.: the entity represented by the EndNodelD of a Relationship Record) is a\nduplicate, the LEl issuer of the child Legal Entity adjusts all not ANNULLED Relationship Records with\nthis parent Legal Entity as EndNote as follows:\no rr:RegistrationStatus of existing Relationship Records SHALL be ANNULLED\n¢ new Relationship Records SHALL be created with the surviving parent Legal Entity’s LEIl as\nEndNodelD\n4.21 Registration error — Relationship Record or reporting exception\nis a duplicate\nA child LEI record SHALL have only a maximum of one relationship data set of each type at a time. If\nthere is more than one published at the same time, duplicate Relationship Records exist. There are\nthree ways, duplicate Relationship Records can be introduced:\n* More than one ACTIVE Relationship Record with the exact same StartNode, same\nRelationshipType but different EndNodes are published, or\n* More than one Relationship Record with the exact same StartNode, same RelationshipType,\nsame EndNode and same StartDate for PeriodType RELATIONSHIP_PERIOD is published.\ne One ACTIVE accounting consolidation parent relationship is published together with a\ncorresponding reporting exception for the same parent (direct/ultimate).\nState Transition and Validation Rules for Common Data File formats Page 167 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2256,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.798Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"For the first case, the LEl issuer SHALL determine which Relationship Record is correct currently; all\nother duplicate records need to be set either to INACTIVE, if they represent no longer current\nrelationships, or to ANNULLED, if they were created erroneously.\n\n4.22 Registration error — Eligibility violation (invalid LEl issuance)\n\nIf an LEI registration is identified as erroneous or invalid after it is issued, the LEl issuer SHALL set the\n\nrecord to an ANNULLED state but keep it as published records in the Global LEI System to support the\n\nhistorical record and to provide resolution to any external query of the LEI. If the record represented\n\na parent Legal Entity (i.e.: is the EndNode in a Relationship Records), the LEl issuer of the child Legal\n\nEntity SHALL update all affected relationships as if the parent were a duplicate (see section 4.20).\n\n4.23 Issue New LEI for an US company incorporated in one state but\n\noperating in another\n\nIn the US, the state where a company is incorporated may not necessarily be the state where the\n\ncompany has its main base of operations. When a Legal Entity incorporated in the US is requesting a\n\nnew LEI code, in addition to or differing from section 4.1, the LEl issuer:\n\nSHALL validate and publish at least the following:\n\no RegistrationAuthority SHALL be the register where the entity is incorporated.\n\no Legallurisdiction SHALL match with the state of incorporation.\n\no EntityLegalFormCode SHALL match with Legallurisdiction.\n\no LegalAddress SHALL be the address displayed in the RegistrationAuthority.\n\ne HeadquartersAddress SHALL be the main location of business operations.\n\no If the entity is registered with a business name or as a foreign company in the state where the\nheadquarters are located, this registration SHALL be included in the ValidationAuthority or in\nOtherValidationAuthorities.\n\n¢ ValidationSources SHALL be FULLY_CORROBORATED, if all relevant elements can be\ncorroborated via the provided ValidationAuthority and OtherValidationAuthorities; it SHALL be\nPARTIALLY_CORROBORATED if not all relevant elements can be corroborated.\n\nState Transition and Validation Rules for Common Data File formats Page 168 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2292,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.798Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.24 Issue New LEI - Financial institution in the US\n\nBanks, credit unions, and other financial institutions in the US can be chartered on a state level or on\n\na federal level and are subject to regulations and supervision from multiple governmental\n\nauthorities. When a new LEl is requested for financial institution in the US (e.g., National Banks and\n\nFederal Savings Associations, State Banks, Credit Unions, Bank Holding Companies, Edge Act\n\nCorporations), in addition to or differing from section 4.1, the LEl issuer:\n\no SHALL consult the FDIC’s “BankFind Suit”, the FFIEC’s NIC institution search, the OOC's list of\nfinancial institutions, or the NCUA’s “Research a Credit Union Tool” and determine if the LEI\napplicant is a National Bank, Federal Savings Association, Federal Credit Union, or a state-\nchartered institution.\n\nIf the LEl applicant is chartered on a federal level, following rules apply:\n\no Legallurisdiction SHALL be US.\n\no EntityLegalForm SHALL be an ELF code assigned on federal (US) level representing the respective\ntype of financial institution (e.g., “62VJ” for National Bank).\n\no The LEl issuer SHALL determine under which authority the entity is chartered and populate the\nrespective RA code as RegistrationAuthoritylD\n\no RegistrationAuthorityEntitylD SHALL be the local identifier representing the entity; it SHALL be\nthe ‘native’ identifier assigned by that authority (e.g., the OCC’s charter license number) as some\nalso provide identifiers assigned by other authorities (e.g., FDIC certificate number).\n\n¢ ValidationAuthoritylD SHALL be one of the authorities consulted to determine that the entity is\nfederally chartered (FDIC, OCC, FFIEC, or NCUA). Having a different authority than in\nRegistrationAuthoritylD MAY support the identification of potential duplicates.\nValidationAuthorityEntity|D SHALL be the ‘native’ entity identifier assigned by that authority.\n\no OtherValidationAuthorities MAY be included to refer to further authorities (e.g., local business\nregister) used for the corroboration of the reference data.\n\nIf the LEIl applicant is chartered on a state level, the following rules apply:\n\no Legallurisdiction SHALL be the state where the state-chartered institution is chartered.\n\no EntityLegalForm SHALL be the Legal Form code that best describes the nature of the financial\ninstitution using the relevant ELF codes for that state.\n\no The LEl issuer SHALL determine under which authority the entity is chartered and populate the\nrespective RA code as RegistrationAuthoritylD\n\no RegistrationAuthorityEntitylD SHALL be the local identifier representing the entity; it SHALL be\nthe ‘native’ identifier assigned by that authority.\n\nState Transition and Validation Rules for Common Data File formats Page 169 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2866,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.798Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"¢ ValidationAuthoritylD SHALL be one of the authorities consulted to determine that the entity is\nstate-chartered (FDIC, OCC, FFIEC, or NCUA). ValidationAuthorityEntitylD SHALL be the ‘native’\nentity identifier assigned by that authority.\ne OtherValidationAuthorities MAY be included to refer to further authorities (e.g., local business\nregister) used for the corroboration of the reference data.\nState Transition and Validation Rules for Common Data File formats Page 170 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":582,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.798Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Figure 2: Examples for level 2 declaration within an LEI Record Set - a) describes the expected Use Case of an LEI A\ndeclaring two different LEls as direct and ultimate parent; b) LEI A declares same LEI B as direct and ultimate parent by\nproviding two separated Relationship Records; c) LEI A declares an LEI B as direct parent and an exception (e.g., NO_LEI)\nfor its ultimate parent relationship; d) LEI A declares two exceptions.\nA child Legal Entity SHALL never have an accounting consolidation parent or branch relationship with\nitself; the LEI identifying the parent must be different from the LEI identifying the child entity.\nReporting accounting consolidating direct and ultimate parent is mandatory for all Legal Entities with\nthe exception of branches (see below). In cases where the Legal Entity has declined to provide the\nmandatory reporting of a specified type of relationship information (direct or ultimate parent), the\nreason is explicitly declared in relationship Reporting Exception Record. This information is reported\nat the time of LEl Issuance, LEI Renewal, or LEl Transfer, whichever happens first.\nExceptions are reported as provided by the Legal Entity. The LOU creates a reporting exception\ninstead of a Relationship Records. The LOU SHALL remove the exception record given:\no the child subsequently reports the respective direct or the ultimate parent.\n¢ the child entity subsequently ends (LEI RegistrationStatus of RETIRED, ANNULLED, or DUPLICATE).\no after a transfer to another LOU has been completed.\nException reason reporting\nIn the case that a Legal Entity is aware that it has a relationship of the relevant type but withholds\nthe details due to legal concerns, the Legal Entity SHALL provide an opt out reason NON_PUBLIC.\nReasons are recorded in a manner specified by the LEI-ROC and reported in the Reporting Exception\nRecords file. No relationship information SHALL be recorded by the LEl issuer. The opt out reason is\ncollected as part of the LEl Record of the reporting entity. As noted by the LEI-ROC, it would be the\nprerogative of any competent regulator requiring this information to determine whether the opt out\nwas justified.\nNon-consolidating exceptions have one of the following reasons: NATURAL_PERSONS,\nNON_CONSOLIDATING or NO_KNOWN_PERSON. This group of exceptions can only be assigned to\nboth parents or to neither of them and never in combination with an active relationship or another\nexception reason indicating that an unreported accounting consolidation relationship exists.\nNo parent according to the definition used\nIf the Legal Entity reports that it has no accounting consolidating parent relationships, this\ninformation is collected and reported in the Reporting Exception Records file.\nParent without LEI\nIn the case that one or both Relationship Records include a parent without an LEl, this information is\nalso reported in the Reporting Exception Records file for publication.\nState Transition and Validation Rules for Common Data File formats Page 18 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":3128,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.798Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Resolving parentage conflicts\n\nParentage conflicts describe situations where the reported relationship information for direct and\n\nultimate parent is not consistent with the definition of parent relationships based on accounting\n\nconsolidation or if the declared ultimate parent is not a viable candidate for being an ultimate\nparent.\n\nCommon reasons for inconsistent information:\n\no Declared ultimate parent has parents: the ultimate parent has public parent relationships.\n\no Declared ultimate parent has incorrect exceptions: the ultimate parent SHALL have exactly 2\nexceptions — one for its direct and one for its ultimate parent — with proper exception reasons\n(NATURAL_PERSONS, NON_CONSOLIDATING, NO_KNOWN_PERSON). Reporting Exception\nRecords with other reasons are inconsistent to being declared as an ultimate parent.\n\no Declared ultimate parent has at least one public Reporting Exception Record with reason NO_LEI.\n\no Declared ultimate parent is inactive, or LEl record is invalid: the RegistrationStatus of the\nultimate parent's LEl record is RETIRED, MERGED , DUPLICATE or ANNULLED.\n\no Declared ultimate parent is an International Branch: the ultimate parent can never be defined as\na BRANCH.\n\nIn case of inconsistent information, the LEl issuer SHALL confirm the relationship information of the\n\nLEI record managed by them (can be the child Legal Entity, the declared ultimate parent or both).\n\nThis also can involve contacting the involved Legal Entities but the most up to date consolidated\n\nfinancial statements remain the primary source for validating Level 2 data. If the current information\n\nis found to be incorrect, the LEl issuer SHALL update the relationship information accordingly. If the\ncurrent information is confirmed as correct, the LEl issuer SHALL approach the other LEl issuer(s)\ninvolved by raising a challenge and providing evidence of how the data should be corrected. At this\nstage, the LEl issuer MAY publish the record even if the parentage conflict has not been resolved.\n\nChallenges MAY be raised using GLEIF's Challenge Facility integrated in LEI Search on GLEIF website?.\n\nThe other LEl issuer then re-validates their record(s) and responds to the challenge accordingly. If the\n\nchallenge is not accepted, both LEl issuers need to discuss this matter further with all involved\n\nparties.\n\nBranch relationships\n\nBranches are part of the same legal person as their head office, and can be described as different\n\nestablishments, or locations, of the same corporate entity, whereas a Subsidiary is a legal person\n\ndistinct from its parent. However, International Branches may have independent requirements for\nregulatory reporting and are therefore eligible for their own LEls. A Branch relationship describes the\nrelationship between an International Branch and its head office. The Branch LEI MAY represent\n\n2 https://search.gleif.org/\n\nState Transition and Validation Rules for Common Data File formats Page 19 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":3061,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.798Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"multiple offices or locations of a Legal Entity in a host country jurisdiction. The Legal Entity SHALL\n\nprovide the address information and additional Reference Data of the Branch. A Branch SHALL NOT\n\ndeclare a direct or ultimate accounting consolidating parent relationship or report exceptions.\n\nFund relationships\n\nFor Fund entities the following three relationship types are available (see section 3.50):\n\n¢ Fund Management Entity: A Legal Entity that is considered as the main management entity of a\nfund when it is legally responsible for the constitution and operation of the fund. Such\nresponsibility will include the day-to-day management of a fund's investments and management\nof a fund’s risks, or the appointment of others for that purpose. In the latter case, the entity to\nwhich these functions may have been delegated is not considered to be a Fund Management\nEntity. The Fund Management Entity can be the fund itself, if the fund is self-managed. In this\ncase there MAY be a relationship for which StartNode and EndNode are populated with the LEI of\nthe fund.\n\no Umbrella Structures: An Umbrella Structure is a Legal Entity with one or more than one sub-\nfunds/compartments where each sub-fund/compartment has its own investment objectives,\nseparate investment policies and strategies, segregation of assets, separate investors and which\nhas segregated liability between sub-funds/compartments. U.S. Series Funds and Japanese “non-\ninvestment management funds” are to be identified as Umbrella Structures in the Global LEI\nSystem.\n\no Master-Feeder: A relationship, where a Feeder Fund is exclusively, or almost exclusively, invested\nin a single other fund (e.g., U.S, EU UCITS), or several funds that have identical investment\nstrategies (for the latter, provided this situation is qualified as a Master-Feeder Relationship\nunder the applicable laws and regulations, e.g., some alternative investment funds in the EU)\nreferred to as a Master Fund (or Master Funds). It is clarified that this covers only cases where\nthis relationship is organized in the legal documentation of the feeder fund and does not cover\nrelationships where a fund’s assets are invested in multiple other funds (fund of fund structure).\n\nThe collection of new fund relationships in the Global LEI System SHALL be mandatory:\n\na) If the relationship is mandated to be reported and publicly available in the relevant\njurisdiction AND if the LEl is mandatory for the related entity in the relevant jurisdiction\n\nb) For the relationship between an Umbrella Structure and a sub-fund or compartment or other\nsub-structure.\n\nIn all cases where a fund relationship is reported, StartNode and EndNode of the relationship SHALL\n\nbe LEI codes.\n\nState Transition and Validation Rules for Common Data File formats Page 20 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2906,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.798Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.12 Transliterated Other Entity Names.....cccccevvvviiieiiinniiiiiieeccciiiece e ssssiieeeeen 44\n3.13 Legal AQAIESS ...vvuieeeiiiieeeeereiiitte e srte e etrrr e e s e ssrire e ee s s s saibeaae e s s sananeeessnsnnneeaesenes 4D\n3.14 Headquarters AdAreSS ......ccuvuviieeiiiiiiiieeeesiiiieee e esssiieeeessssiiesesessssnnseesssssssnseeessnns 40\n3.15 Other AdAreSSES ..ceeivviieeee ittt eeesie e e e s esssireeee s sasieeae e s s snnaneeessnsnsnseeessnsn BT\n3.16 Transliterated Other Addresses.......cvviviviiiiiviiee e essiieee e seveeeessssnnneee e 47\n3.17 Registration AULNOIILY ..ccciiiiiiiiieiiiiciiiececie e ssnnneee e 48\n3.18 Registration AUthOrIty ID ...cccvveiiiiiiiiiieeie e e s ssnnneee e 49\n3.19 Other Registration AUthOrity ID.......cccceeeviiiiiiiee s ssieneee 0. 49\n3.20 Registration Authority Entity ID......cccccveiiiiiiiiiiie i ceciieeee s esiiieeeessssiiieeeeeen. D0\n3.21 Legal JUriSAICTiON ...cicciiieeie ettt s ee s eee e s s sraae e essssnnneeesenes DL\n3.22 ENTitY Cat@OrY ettt ettt e e e e e e e e eeereaesne e s D2\n3.23 ENtitySUDCAtEEOIY .uuiiiiiii ittt ettt ee s e ae e s s state e eessnaaeeeeenes DD\n3.24 Legal FOIM ciiiiiiiiee ettt ette e e rrae e e s e srabe e ae s s s sasbaaeeesssannanesessnnnsssenessnes DT\n3.25 ENtItY STAtUS .cuieiiiie ettt te e e s aaaeeeeenes DO\n3.26 Entity Creation Date ...ttt DO\n3.27 SUCCESSOr ENTItY oot e s e eeeeeeeeeeeesnen OO\n3.28 Legal ENtity EVENTS ..cccvveiiii ittt sttt e esiieeee s siiieeae e s s snaneeesssnnnneaesanns O\n3.29 Legal ENtity EVENT oottt ee s siie e s srane e e s ssnaaeee e enes O2\n3.30 Legal ENtity EVENT TYPE .ciiiiiiiiiiiieieeciiieeeecriiieee s es e ee e s srae e e e s sssnneeeessssssnnaeaen e O4\n3.31 Legal Entity Event Effective Date.......cccceevevivieee it ssiiaeee 0000, 06\n3.32 Legal Entity Event Recorded Date........ccccoeviiieeeiiiiiieeie s ensiieeie s sevieeesssinieee e 07\n3.33 Validation Documents (context: LEI-CDF).......ccccceevviieeeiiieeeceeeessiieesvee e siieeeennn 67\n3.34 Validation Reference (context: LEI-CDF)......ccccccveiiviieeiiiiieeecieee e e esiee e eeiieeennn. 68\n3.35 Affected FIEldS ..uuiiii ittt ssrreeee a0 D8\n3.36 Affected Field. ... e s s naeeee e enes 0O\n3.37 Initial Registration Date (context: LEI-CDF) ........cccovvveeeiviieeecieeeeesivieesceeeesiieenennn 71\n3.38 Last Update Date (context: LEI-CDF)......cccccveeeieeeriiieeeiiiieeeciieeessiiesessveeesveeeesnnnn 71\n3.39 Registration Status (context: LEI-CDF) ..c.covvveeiiieeiiiieecciee e sevieee s 72\n3.40 Next Renewal Date (context: LEI-CDF)....ccccuueeeieeeiiiieeciiiieeciieee e e esvee e svvveeeennnn 72\n3.41 Managing LOU (context: LEI-CDF)....ccccviiiiiiie e ccieeesstee s eeeee s svieeessvaee e 73\n3.42 Validation Sources (context: LEI-CDF)......ccccueveiiiieeciieeeciieeesiiee e eeeeeesieessssineeennn 73\n3.43 Validation AULNOIItY......ceiiiiiiiiiec e ee s seanneee e 1\n3.44 Validation AUthOFItY ID ....ccooveiiiieiiiciiiiecce e erae e ssvreeee s snvnnneeenn 1\n3.45 Other Validation AUthOrity ID.....ccooviiiiiiiiiiiiece et ssivveee e e 1D\n3.46 Validation Authority Entity ID.....ccooviiiiiiiiiiiiiece et seeve e sieaeee a0 10\n3.47 Other Validation AUthOIItIES.......coviviiiiiiiiiiiieee et ssiaaeee e 10\n348 STArt NOGE....eieiieie et srire e ee s s s saaieae s e s s sanaaeeessnnsnneaessnes 1T\nG State Transition and Validation Rules for Common Data File formats Page 3 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":3461,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.799Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"The reporting of the Umbrella Structure MAY be triggered by the umbrella entity as well as by its\ncompartments or sub-funds. However, the relationships are then technically recorded following the\nexisting approach of bottom-up declaration (see section 3.50).\nParent reporting for Government Entities\nGeneral Government Entities are related to each other in the sense that all of them belong to the\nGovernment sector. However, there is no “control” of one Government Entity over another in the\nmeaning attributed to “control” in the IFRS or US GAAP. The consolidation procedures may be quite\ndifferent among government entities and the standards used to identify parent relationships\nbetween general entities would not apply. Government entities that are controlled by another\nGovernment Entity SHALL declare parent relationships according to the usual Global LEI System rules\nbut are likely to use specific accounting standards — GOVERNMENT_ACCOUNTING_STANDARD.\nIn the cases that the parent is unknown, the existing relationship exception for\n“NO_KNOWN_PERSON“is to be used.\n2.2 Corroboration of LElI Record Set\n2.2.1 LEI Registration\ne The process by which Legal Entities are issued LEls and the corresponding Reference Data is\nadded and published in the Global LEI System after successful Validation.\no Asageneral rule, only active Legal Entities can request an LEI.\n° When the LEl is initially issued, the RegistrationStatus SHALL be ISSUED and EntityStatus SHALL\nbe ACTIVE.\n¢ Inrare cases, a regulatory framework may require that inactive entities that do not have an LEI\nneed to be identified with an LEI. Then the LEIl record MAY be issued initially with\nRegistrationStatus RETIRED and EntityStatus INACTIVE.\no If a Legal Entity has (a) parent(s) according to the definitions described above, (a) Relationship\nRecord(s) SHALL be published.\n¢ Only relationships that are active by the time of the registration SHALL be recorded.\nRelationships that ended prior to the initial registration SHALL be excluded.\n* When a Legal Entity cannot provide information on its direct and/or ultimate parents, a\nReporting Exception Record SHALL be published instead.\no The Reporting Exception Record includes the applicable reason for not providing (a) Relationship\nRecord(s). If the reason changes over time, the Reporting Exception Record SHALL be updated.\nState Transition and Validation Rules for Common Data File formats Page 21 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2534,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.799Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"2.2.2 Validation\n\nThe LEI Reference Data includes all elements of an LEI Record that describe the Legal Entity itself and\n\nall of its relationships. The LEI Registration details that describe the state of the LEI Record itself are\n\nnot part of the LEI Reference Data.\n\nThe Legal Entity is responsible to supply its Reference Data when a new LEl is requested. The LOU\n\nverifies the existence of the Legal Entity and the Reference Data based on reliable public sources,\n\nprimarily the sources as mentioned on the RA list. If the data is not available from public sources,\nthen the data MAY be provided by the Legal Entity. Available information from the authoritative\nsource used for Validation SHALL be entered in ValidationAuthority. If more than one authoritative\nsource was used, OtherValidationAuthorities SHALL be populated with information from additional\nsources.\n\ne The LElissuer is responsible for validating and verifying the Reference Data of the LEIl Record,\nusing public (RA) sources where available and relying on entity supplied documents, if no public\nsource can be consulted.\n\no The LEl issuer also is responsible to validate any changes and updates to LEI Records.\n\no The LEl issuer SHALL note the level of Validation in the Reference Data via the element\nValidationSources.\n\no If public sources from the RA list were used to validate the LEI Reference Data, ValidationSources\nSHALL be either FULLY_CORROBORATED, if all LEI Reference Data can be verified, or\nPARTIALLY_CORROBORATED, if only some of the LEI Reference Data can be verified.\n\no If public sources from the RA list were used to validate the LEI Reference Data and all data apart\nfrom the postal code and region can be verified using the public sources, the LEl issuer SHALL add\nthe postal code and region information and ValidationSources SHALL be FULLY_CORROBRATED,\nas the postal code and region are a derivative of the verified address.\n\no If the Validation relies on sources provided by the Legal Entity or other sources not included in\nthe RA list, ValidationSources SHALL be ENTITY_SUPPLIED_ONLY.\n\n* Insome jurisdiction, Government entities are not registered by any Registration Authority.\nHowever, the Government Entity is established by a public legislation or statute, that can be\nreferred to for corroboration. If such public legal document is the source used for corroboration,\nValidationSources SHALL be FULLY _CORROBORATED, if all data elements could be corroborated\nfrom the document, or PARTIALLY_CORROBORATED, if some data elements could be\ncorroborated. Using such documents for validation of unregistered Government entities SHALL\nbe the preferred validation process compared to relying only on entity supplied information.\n\no If ValidationSources is PENDING, the LEI Record SHALL NOT be published and is for the LEI\nissuer's internal use only.\n\no The same authoritative source SHALL NOT appear more than once in ValidationAuthority and/or\nOtherValidationAuthorities but one of the sources MAY be the same as RegistrationAuthority.\n\nState Transition and Validation Rules for Common Data File formats Page 22 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":3213,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.801Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o OtherValidationAuthorities SHALL NOT include RA999999 (see chapter 2.2.3) as\nValidationAuthorityID.\n\no OtherValidationAuthorities MAY contain additional information about an authorititative source\nand local identifiers, in order to enrich the LEI Record Set and support verification by a third\nparty, the public or just to enhance and enable a mapping exercise.\n\no If the Legal Entity has declared relationships, the LEl issuer is responsible to validate that the\nrelationship between the two Legal Entities exists.\n\no The LElissuer is responsible for validating that the LEl presented in an EndNode of a relationship\nindeed represents the Legal Entity declared in the documents used for validating the\nrelationship.\n\ne The LElissuer is not responsible for validating Reporting Exception reasons reported.\n\ne The LElissuer is not responsible for validating a Legal Entity’s statement that there is no parent\naccording to the accounting consolidating definition used but SHALL respond to any challenges to\nthat status.\n\no The LElissuer is not expected to validate the Reference Data associated with the LEI presented as\nEndNode unless the LEl issuer is also the LEl issuer of the EndNode’s LEI Record Set.\n\ne The LElissuer is responsible for ensuring that a relationship is made to an active entity. This\nmeans the parent LEI should not have a RegistrationStatus of DUPLICATE, RETIRED, MERGED , or\nANNULLED at the time of the initial Relationship Records issuance. Rare cases, where an LEl is\nissued initially to an inactive entity are exempted from this rule.\n\no The LEl issuer SHALL accept or deny a Relationship Record based on the result of its Validation.\n\no The LEl issuer SHALL revalidate the complete LEI Reference Data at each renewal. When LEI\nReference Data is updated (e.g.: by the Legal Entity or due to a challenge), the updated data\nSHALL also be validated.\n\nPrimary sources are required for the Validation of accounting consolidating parent relationships.\n\nThese include only the following documents:\n\n1. Consolidated financial statements are a key source to validate parent relationships. Such reports\nmay be prepared and submitted to the relevant authority quarterly or annually or attested to by\na third-party auditor and not submitted to an authority.\n\n2. Regulatory filings (i.e., reports to a securities regulator or a bank supervisor) are another\nimportant source. When validating using a regulatory filing, the filing name must be provided (as\nwell as the path if available). Best practice would be to include the Digital Object Identifier (DOI)\nof the document.\n\n3. Other types of allowable sources include other documents supporting the preparation of\nconsolidated financial statements, contracts, and other official documents.\n\nState Transition and Validation Rules for Common Data File formats Page 23 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2939,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.801Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Proprietary products containing secondary data derived from a variety of sources are not considered\nas valid sources for Validation of relationship data. Only an original source of the above-mentioned\nquality is acceptable. The level of corroboration depends on the sources used for Validation:\n\n¢ The ValidationSources of a Relationship Records is FULLY _CORROBORATED if\no (i) there are consolidated financial statements, other documents supporting the preparation\n\nof consolidated financial statements coming from or otherwise confirmed by the external\nauditor, or regulatory filings\n\ne AND (ii) these documents establish the consolidation relationship and mention the name of\nboth related entities.\n\no The ValidationSources of a Relationship Record is PARTIALLY_CORROBORATED, if\no (i) the definition of parent used in regulatory filings differs from the accounting consolidation\n\ndefinition, but filings assist in corroborating the information provided by the child Legal\nEntity that the conditions of consolidation are met. Only accounting consolidation\nrelationships are expected to be reported and the LEl issuer is not expected to conduct an\nanalysis of differences between the regulatory sources and the accounting standard.\nGenerally, the type of source, or the fact that the source does not refer to accounting\nstandards will inform the LEl issuer that this category should be used;\n\no OR (ii) Official documents such as regulatory filings or contracts make it likely that the\nconditions of accounting consolidation are met, or have ceased to be met, when\nconsolidated accounts reflecting the new situation have not been established yet.\n\n¢ The ValidationSources of a Relationship Records is ENTITY_SUPPLIED_ONLY if\ne (i) the conditions for FULLY_CORROBORATED or PARTIALLY_CORROBORATED would have\n\nbeen met, except that the documents used for Validation are usually not publicly available in\nthe legal jurisdiction(s) of the child and parent Legal Entities;\n\ne AND (ii) the child Legal Entity provided official documents for the purpose of validating the\nrelationship.\n\nFund entities can have fund relationships in addition to the above described accounting consolidating\n\nparent relationships. A fund prospectus would be a good source for validating the different Fund\n\nrelationships:\n\ne Providing prospectus certified by a regulatory authority from GLEIF RA list SHALL be set to\nFULLY_CORROBORATED and the corresponding RA code SHALL be documented in the Validation\nAuthority container.\n\ne Providing prospectus not vetted by any authority SHALL be reported as ENTITY_SUPPLIED _ONLY.\n\nState Transition and Validation Rules for Common Data File formats Page 24 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2779,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.802Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"The Validation Authority of a fund entity SHALL be the financial regulator registering the fund.\n\n2.2.3 Application of GLEIF Registration Authorities List\n\nLEl issuers SHALL ensure the cross reference to the local authoritative source is standardized and\n\nincluded in an LEI record. GLEIF maintains and publishes a list with Registration Authority (RA) Codes®\n\nthat SHALL be used to populate RegistrationAuthoritylD and ValidationAuthorityID. This list includes\nspecific and unique codes for all authoritative sources accepted by GLEIF as well as three reserved RA\ncodes (RA777777, RA888888 and RA999999).\n\nSpecific RA code (not RA777777, RA888888 or RA999999):\n\n» If a specific RA code is available, it SHALL be used in RegistrationAuthoritylD and/or\nValidationAuthorityID.\n\no If RegistrationAuthoritylID is populated with a specific RA code, OtherRegistrationAuthoritylD\nSHALL NOT be provided; the same applies to ValidationAuthorityID and\nOtherValidationAuthorityID.\n\n¢ If ValidationAuthorityID is populated with a specific RA code, ValidationSources SHALL NOT be\nENTITY_SUPPLIED_ONLY.\n\no If a specific code is removed from the RA list, the LEl issuer SHALL update all affected records,\nwith a correct new code within the specified implementation time. The new code SHALL NOT be\nRA888888 with the name of the just removed registration authority as OtherAuthorityID.\n\nReserved RA code RA777777:\n\no The RA code RA777777 is used for General Government Entities and International Organizations\nonly in case there is no information available in any regular registration authority and Public\nLegal Documents are used for validation instead.\n\no If ValidationAuthoritylID is populated with RA777777, OtherValidationAuthoritylD SHALL be\npopulated with the name of the source as free text or if available with the link to the documents\nused for validation.\n\no RegistrationAuthoritylD and OtherRegistrationAuthoritylD SHALL NOT be populated with\nRA777777.\n\no If ValidationAuthorityID is RA777777, the RegistrationAuthoritylD SHALL be RA888888 or\nRA999999 only (please consult Figure 3)\n\n3 https://www.gleif.org/en/about-lei/code-lists/gleif-registration-authorities-list#\n\nState Transition and Validation Rules for Common Data File formats Page 25 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2348,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.802Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o If ValidationAuthorityID is RA777777, ValidationSources SHALL shall be\nPARTIALLY_CORROBORATED or FULLY_CORROBORATED.\n\nReserved RA code RA888888:\n\no The RA code RA888888 is used as an interim code. This indicates that a Registration/Validation\nAuthority is not available on the RA list, but the addition of a relevant source, which could be\nused for the LEl in question, has been requested to GLEIF.\n\no This code SHALL be used only after a request to add a new RA source has been sent by email to\nralist@gleif.org with further description of the source.\n\no All requests for new RA codes (or modifications) are collected over time and processed in time\nfor the periodical publication of a new version of the RA list. The approximate date(s) for the\npublication of a new version are communicated well in advance.\n\n* In cases, where the suggested source has NOT been accepted as authoritative source, the LEI\nissuer needs to provide a new suggestion for a source in order to ensure proper corroboration\nwithin a month, if no other implementation time is defined. If no other source could be identified\nfor Validation and Verification of the Legal Entity and its Reference Data, the correspondent\nfields SHALL be changed to RA999999.\n\n* In cases, where the suggested source has been accepted as an authoritative source, the LEl issuer\nSHALL replace the reserved code with the new code and adjust the corroboration level\naccordingly within the time frame communicated for the implementation of the new version of\nthe RA list.\n\n¢ The reserved code RA888888 SHALL NOT be used for longer than a month after publication of\nthe new version of the RA list which includes the new valid RA code, unless a different\nimplementation time has been defined.\n\no If RegistrationAuthorityID is populated with RA888888, OtherRegistrationAuthoritylD SHALL be\npopulated with the name of the source as free text; the same applies to ValidationAuthoritylD\nand OtherValidationAuthorityID.\n\n¢ The name provided as free text SHALL be the same as used in the request sent to GLEIF to add\nthe source to the RA list.\n\no If RegistrationAuthorityID or ValidationAuthorityID is RA888888, ValidationSources SHALL only be\nset to the lowest corroboration level, namely ENTITY_SUPPLIED_ONLY.\n\nReserved RA code RA999999:\n\ne The RA code RA999999 refers to situations when no Registration Authority can be defined for a\nLegal Entity. The LEl issuers are obliged to use their full efforts and local expertise to ensure that\nthe applicant is an existing Legal Entity and is eligible to obtain an LEl and also document this\ninformation accordingly.\n\nState Transition and Validation Rules for Common Data File formats Page 26 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2789,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.802Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o If RA999999 is used as identifier for the source, the respective EntitylD SHALL NOT be populated.\nPlaceholders like “N/A”, “None”, etc. SHALL NOT be used.\n¢ If ValidationAuthorityID is RA999999, ValidationSources SHALL be ENTITY_SUPPLIED_ONLY.\ne RA999999 SHALL NOT be used in OtherValidationAuthorityID or for records with EntityCategory\nBRANCH.\nFigure 3 below shows the allowed combinations of reserved RA codes for RegistrationAuthoritylD\nand ValidationAuthority ID.\nValidationAuthoritylD\nSpecifc\nRA777777 RA888888 RA999999 ValidationAuthoritylD\nRegistrationAuthoritylD\nSpecific Not ok Not ok Not ok Ok\nRegistrationAuthoritylD ot okay ot okay ot okay ay\nFigure 3: Overview of allowed combinations of reserved and specific RA codes for RegistrationAuthoritylD and\nValidationAuthoritylD\n2.3 Life cycle\nFigure 4 highlights the existing general STVR in the registration status of an LEIl, from its creation in\nthe internal LEl issuer systems until reaching a so-called end state. In addition, the life cycle includes\nand describes the process of transferring an LElI Record Set from one LEl issuer to another.\nThe life cycle is divided into “Internal” states, that are managed by the LEl issuer but not shared with\nthe public, and “Published” states, that are included in the Global LEI Repository. For instance,\nPENDING_VALIDATION is Internal with respect to publication because LEI registrations are expected\nto be fully validated prior to the LEI being assigned, issued, and published. An expected part of the\nlife cycle of an LEl registration is the timely update and periodic Validation of its Reference Data. This\nperiodic Validation needs to be performed at least once a year. If a record is not validated again\nwithin this timeframe, the registration status code will be set to LAPSED, meaning the Validation is\noverdue.\nState Transition and Validation Rules for Common Data File formats Page 27 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2012,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.802Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"1\nPUBLISHED\n- /‘///J>77777\\7\\\nINTERNAL H\nREGISTRATION LIFE CYCLE\n: .\nSTART ISSUING PROCESS TRANSIENT\n\\/ |\n\\ END STATES |\nTRANsFERED]<—1\n\nFigure 4: High-level general representation of the life cycle of an LEI\n\n2.3.1 Registration Status Codes\n\nThe RegistrationStatus operational data element indicates the state that an LEI Record can have over\n\nits life cycle.\n\nThe defined status codes fall into four broad categories:\n\n1. Registration life cycle: These are codes applied in the normal life cycle of an LEl registration from\nsubmission through issuance through the termination of the registration when the entity\nbecomes inactive.\n\n2. Registration Errors: These are codes that are needed to correct errors that may occur in LEI\nregistration process.\n\n3. Transient conditions: These are codes that support certain transient conditions describing the\ntransfer of an LEl registration from one LEIl issuer to another.\n\n4. Deprecated statuses: Values that have been accepted in the past, and due to changes in\nunderlying standards, policies and/or rules, have be amended as invalid or no longer in use.\n\nEach RegistrationStatus code holds information regarding the publication of the LEI Record Set as\n\nshown in below table:\n\ne Published: The LEI Record Set is included in the public files published by the LEl issuer and GLEIF.\n\nState Transition and Validation Rules for Common Data File formats Page 28 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1509,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.802Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"¢ Transient: The LEI Record Set is included in the public file published by the LEl issuer, but only\nduring a record transfer from one LEl issuer to another. It may not be included in files published\nby GLEIF, if the same LEl is already published by another LEl issuer.\n\ne Archived: The LEI Record Set is not included in the public file published by the LEl issuer or by\nGLEIF but is retained by the LEl issuer as part of its archival records.\n\n¢ Internal: The LEI Record Set is not included in the public file published by the LEl issuer or by\nGLEIF but may be exchanged between LEI issuers and/or GLEIF as part of the Validation process\nprior to issuance.\n\no Deprecated: The RegistrationStatus has been deprecated and SHALL NOT be used anymore. LEI\nRecords with this RegistrationStatus MAY appear in historical LEI Record files but have been\nupdated to a different status in current data files.\n\nThe following table categorizes the RegistrationStatusEnum codes:\n\nPENDING_VALIDATION Registration life cycle Internal\n\nISSUED Registration life cycle Published\n\nPUBLISHED Registration life cycle Published\n\nDUPLICATE Registration Errors Published\n\nLAPSED Registration life cycle Published\n\nMERGED Deprecated Deprecated\n\nRETIRED Registration life cycle Published\n\nANNULLED Registration Errors Published\n\nCANCELLED Registration Errors Archived\n\nTRANSFERRED Transient condition Archived\n\nPENDING_TRANSFER Transient condition Transient\n\nPENDING_ARCHIVAL Transient condition Transient\n\nThe value MERGED in the RegistrationStatus field is deprecated with the LEI-CDF 3.1 being effective.\nState Transition and Validation Rules for Common Data File formats Page 29 of 170\n@ Public Version 2.7.1 Final\n\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1764,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.802Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"2.3.2 Changes in Registration Status due to Legal Entity Events\nWhile the RegistrationStatus has information about the LEI Record itself and not necessarily\ndescribes the state of the Legal Entity, some Legal Entity Events also trigger a transition in\nRegistrationStatus. Each of the following events documented with its exact effective date SHALL\nchange the RegistrationStatus of the LEI Record to RETIRED according to the existing rules:\no Liquidation (@event_status COMPLETED)\n¢ Insolvency (@event_status COMPLETED)\no Dissolution of a Legal Entity, including International Branches and Subsidiaries (@event_status\nCOMPLETED)\ne Mergers and Acquisitions (for the Legal Entity which ceases operation as a result of a merger)\nRETIRED is an end state of an LEl Record Set, and an update that assigns this RegistrationStatus code\nto the LEI Record Set is the last regular update that is made to that record. Therefore, the\nEntityStatus and the RelationshipStatus are set to INACTIVE once this end state has been reached. In\norder to satisfy the 1ISO 17442 persistence criteria of the LEI (i.e., the ability to properly interpret\nexisting and historical records and reports that refer to LEls in this state), these LEI Records are still\npart of the published LEI records. The LEI Record Set MAY still be updated to comply with the\nimplementation of new code lists or to amend data quality issues caused by the record. In such cases\nGLEIF needs to be informed about the data updates.\nThe following Legal Entity Events SHALL be documented together with the EffectiveDate of the event\nand SHALL remain in their current RegistrationStatus (expected to be either ISSUED or LAPSED):\n¢ Changeinlegal name (@group_type STANDALONE)\ne Change in trade or doing business name\no Change in legal address\no Change in headquarters address\n¢ Change of legal form\no Demergers and Spinoffs (for the entity that has been demerged or spin off)\ne Absorption\no Voluntary Arrangement\no Acquisition of an international branch (for the branch entity)\no Transformation of an international branch into a Subsidiary (for the entity that has been\ntransformed into a Subsidiary)\ne Transformation of a Subsidiary to an international branch (for the entity that has been\ntransformed into an international branch)\nState Transition and Validation Rules for Common Data File formats Page 30 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2459,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.802Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"349 ENA NOUE ettt ettt e e s s saabn e s e s s snaae e e e s snnnneeesenes 1O\n3.50 RelationShip TYPE cooiiiiiiiei et ae e sraae e s ssnaneeeeenes 1O\n3.51 Relationship PEriods .....ccciiiiiiiiiiiiiiiiiiieeee sttt srne e s sssnieeee s seinneeeeees S0\n3.52 Relationship StAtUS ...uvviiiiiiiiiie e 82\n3.53 Relationship QUAlIfIErS.......ooviuiieiiiiriiiee e ee e e 82\n3.54 Relationship QUaNLIfIErs ......c.uivviiiiiiiiiee e ieee e S\n3.55 |Initial Registration Date (context: RR-CDF).......ccccceeverivriieecicieee e 84\n3.56 Last Update Date (context: RR-CDF) .......ccccveeeiiieiiiiieecriiee e s e sieeee 0000 85\n3.57 Registration Status (context: RR-CDF) .....ccccceeeiieiiiiiieciiiee e 85\n3.58 Next Renewal Date (context: RR-CDF)....ccccveeeuiiieiiieeeiiiee e e seiieeee00. 80\n3.59 Managing LOU (context: RR-CDF) ......cccceeiiiieeiiieeeciies e sstve e e sive e 8 7\n3.60 Validation Sources (context: RR-CDF) .....ccccueeeiieiiiiiieeisiiee e esiie e siveee e 8 7\n3.61 Validation Documents (context: RR-CDF) .......cccceviviiieeiiiiee e s, 88\n3.62 Validation Reference (context: RR-CDF) .......ccccvveeiivieeeiiiiie e ssiee e siieeeen00n 89\n3.63 LEI (context: REPEX-CDF)..ccccciiiecieeeiiieeesitiie e ceeeeesiie e essvee s saee e e s savaesssnee s snnveeesnnee 89\n3.64 EXCePtion CateBOrY ....cooiiiiiiiiiiiiiceee ettt ee e OO\n3.65 EXCePtion REASON....ccoiiiiiiiiiiieeieitie e e e e e s e s e eeeesneenenesnens D0\n3.66 EXCEPLiON RETEIENCE ...uuiiiii ittt srae e ssaaaeee e enes D2\n3.67 Associated Entity — DEPRECATED .......cuvviviiiiiiiieeeeiiiieece s essiieeeeesssneneeesssnnneeeeenns 92\n3.68 Entity Expiration Date — DEPRECATED ......ccoocutiiiiiiiiiiieee s ciiiiieee s essiinneeee e ssnneeee . 93\n3.69 Entity Expiration Reason — DEPRECATED.........ccccvivmiiiiiiiiiieieeeeeeeeeeeeeeeeeeeieiiennnnn. 93\nL ¥ LY - 1 R |-\n4.1 Issue New LEI that is not branch, fund, sole proprietor, government entity or\n\ninternational Organization ........cccvueeeiiiinieeie e 9D\n4.1.1 Relationship with a parent Legal Entity with an LEl.........ccccovvviiiiviiiieiiiniieeeennn.. 96\n4.1.2 Relationship with a parent Legal Entity without an LEl .........cccccceeviviiiiiiinieennnn... 96\n4.1.3 No accounting consolidation parent relationship........cccoccevieviieeiiiiviiniiesieeen e 97\n\n4.1.4 Accounting consolidation parent relationship not reported due to legal obstacles\n(o] 2o 10 1 | TS TS USURORSSPRP < ¥\n4.2 Issue NeW LEI = Branch .......coooviuiiiiiiiiiiiiiee e cssiieie e svveeeee s ssvnneeesssssinnnne s 97\n4.3 Issue NeW LEI = FUNd .....oviiiiiiiiiiiecceciiieece e esieee e svane e e e s ssnnneee s snssannenees 99\n4.4 Issue New LEI —Fund in formation ........cccccevvviiiiiiinniiiienscciieeeesssiiieee e esnnnnnn. 101\n4.5 Issue New LEI —Sole proprietor.....ccccoccvveeeeiiiiieeeeiiisiieeeeesssieeeeeesscveneesssnsnnneees 103\n4.6 Issue New LElI —Government entity........cccceviimimiiiiiiiiiiin e eececccveeeeeeeeen... 103\n4.7 Issue New LEI —International organization .........ccccceeeviveeeiiiiiieeeeeinniiiee e 104\n4.8 LEIRecOrd RENEWAl ..cuvvviiiiiiiiiiiieieeciiiecce et essiieie e sieeeeessssnnseeessnssennnns 10D\n4.9 LEl Record update — Parent Legal Entity without an LEI requests an LEl............106\n4.10 LEI Record update — Relationship Record changes to Reporting Exception .......106\nG State Transition and Validation Rules for Common Data File formats Page 4 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":3466,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.802Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"¢ Umbrella fund changes its structure to a stand-alone fund (for the new stand-alone fund)\n\no Bankruptcy (@event_status IN_PROGRESS)\n\n¢ Liquidation (@event_status IN_PROGRESS)\n\no Insolvency (@event_status IN_PROGRESS)\n\no Dissolution of an entity, including international branches and subsidiaries (@event_status\nIN_PROGRESS)\n\no Break ups (for any part of the original Legal Entity that remains in operation and for any new\nLegal Entities that are formed as part of the terms of the breakup)\n\n2.3.3 Changes in Registration Status when a registration error is resolved\n\nThere are three registration status codes that apply to situations in which a registration assignment\n\nerror has been made: DUPLICATE, ANNULLED, and CANCELLED.\n\no The DUPLICATE code refers to the non-surviving record under an Exclusivity Violation.\n\no The ANNULLED code applied to any other type of assignment error detected after an LEI\nregistration has been publicly issued.\n\no The CANCELLED code refers to any type of assignment error detected before publication.\n\nThese error states are terminal: no further updates to Entity sections of registration records in these\n\nstates SHALL occur. Records in the DUPLICATE or ANNULLED states SHALL be retained as published\n\nrecords in the Global LEI System to support the historical record and to provide resolution to any\nexternal query of the LEI. The LEI Record Set MAY still be updated to comply with the\nimplementation of new code lists or to amend data quality issues caused by the record. In such cases\n\nGLEIF needs to be informed about the data updates. Records with the state CANCELLED SHALL be\n\nretained internally by an LEl issuer to support auditing.\n\n2.4 Registration Status Codes for Transient Purposes\n\nThree registration status codes exist to accommodate the transfer of the management of an LElI\n\nregistration from one LEl issuer to another: PENDING_TRANSFER, PENDING_ARCHIVAL,\n\nTRANSFERRED.\n\no PENDING_TRANSFER and PENDING_ARCHIVAL are used in the transitional period between the\nreceipt of a porting request by a Sending LOU and the final confirmation of the transfer.\n\no The TRANSFERRED code is used in the archival records of a Sending LOU after having successfully\ncompleted the transfer of that responsibility to another (Receiving) LOU. A record in this state is\nnot published but kept internally by the prior LOU for audit trail purposes.\n\nFor a short period of time a given record may appear more than once in a published concatenated\n\nfile. This case occurs at the end of the transfer process, when the Sending LOU publishes their file\n\nState Transition and Validation Rules for Common Data File formats Page 31 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2760,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.802Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"with RegistrationStatus PENDING_ARCHIVAL and the Receiving LOU publishes their file with the\nregistration status ISSUED. The time window for these transient states is limited by a transfer\nprotocol shared between GLEIF and the LEl issuers (see Use Case 4.19). On average, transfers SHALL\nbe completed within five to ten business days.\n2.5 Renewal\nRenewal is the process that triggers the periodic Validation of an LEI Record Set. Renewal is required\none year after the initial registration and every year thereafter. The Next Renewal Date in the\nrecord’s registration section indicates the date when the next renewal is due. If a record is not\nrenewed in due time, the LEl issuer shall validate that the entity is still operating. Given the entity is\nstill operating, the Registration Status SHALL be set to LAPSED and the Next Renewal Date SHALL NOT\nbe updated.\nThe renewal of an LEI Record is initiated by the Legal Entity. The LEIl issuer SHALL inform the Legal\nEntity at least six weeks prior to the next renewal date and remind the Legal Entity to renew the LEI\nRecord Set. Any changes to the LEI Reference Data SHALL be updated by the Legal Entity and\nvalidated by the LEl issuer. After this is completed, the Registration Status remains ISSUED and one\nyear is added to the Next Renewal Date. A LAPSED record MAY be renewed as well and return to an\nISSUED state at any point of time.\n2.6 1SO 3166 Conformance of Address and Jurisdiction Fields\nThe following LEI-CDF data fields must contain current, valid ISO 3166 country (or region, where\napplicable) codes taken from the ISO 3166 code lists. The XML schema for the LEI-CDF validates only\nthe format (pattern) of these fields, not the specific codes used.\no CountryCode in all addresses\no RegionCode in all addresses\no Legallurisdiction\nThe RegionCode SHALL be an ISO 3166-2 subdivision code assigned under the CountryCode.\nDepending on the jurisdiction, either a country code or a region code or either of both SHALL be used\nin Legallurisdiction. Details on this are defined in the GLEIF Accepted Legal Jurisdictions Code List*.\n4 GLEIF Accepted Legal Jurisdictions Code List: https://www.gleif.org/en/about-lei/code-lists/gleif-accepted-\nlegal-jurisdictions-code-list\nState Transition and Validation Rules for Common Data File formats Page 32 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2411,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.802Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"2.7 Address Reporting\n\nAn LEI Record SHALL have at least a LegalAddress (where the entity is legally registered) and a\n\nHeadquartersAddress (where the main center of control of the entity resides). LegalAddress and\n\nHeadquartersAddress MAY be the same. Both addresses MAY also be in different countries and/or in\n\ncountries different from Legallurisdiction. If the Legal Entity has only one address recorded in an\n\nofficial Registration Authority, LegalAddress and HeadquartersAddress SHALL be the same address,\nexcept for entities categorized as FUND or BRANCH which have special rules for\n\nHeadquartersAddress (see 3.13 and 3.14 below). If the registry has partial address information, for\n\ninstance a seat of the company recorded only with the city name and a second field with a complete\n\naddress, the latter SHALL be used for LegalAddress and HeadquartersAddress, even if the address is\nin a different city than the city of the seat. In case of doubts, the LEl issuer SHALL contact the\nauthoritative source for further clarification and validation of the data.\n\nIf the address recorded in the registry is not complete, the LEl issuer SHALL collect the missing\n\nelements from the Legal Entity and set ValidationSources to PARTIALLY_CORROBORATED, except\n\nwhen only postal code and/or region is added by the LOU. In this case, the record can be still\n\nFULLY_CORROBORATED (see chapter 2.2.2). In case the HeadquartersAddress could be validated in\n\nan autoritative source different from the primary one, this could be added in the container\n\nOtherValidationAutorities and the corroboration status MAY be set FULLY_CORROBORATED.\n\nAll addresses reported SHALL be complete and include the following mandatory elements:\n\no FirstAddressLine SHALL include the first line describing the address. Up to three additional lines\nMAY be included.\n\no City SHALL be the name of the city in local language and alphabet.\n\no PostalCode SHALL be the postal code in the format specified by the local postal service. For\ncountries that do not use postal codes in addresses, this optional element SHALL NOT be\nprovided.\n\no Region SHALL be the 1ISO 3166-2 region code of the address. For countries that do not have\nregion codes, this optional element SHALL NOT be provided.\n\ne Country SHALL be the ISO 3166-1 country code of the address.\n\nAddresses MAY include optional elements for additional relevant parts of an address to be recorded\n\nin a structured way:\n\n¢ MailRouting MAY contain explicit routing information or “care of” address.\n\no AddressNumber MAY contain the building number.\n\n¢ AddressNumberWithinBuilding MAY contain an internal location within a building, for example to\nidentify the floor, suite or an apartment.\n\nState Transition and Validation Rules for Common Data File formats Page 33 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2892,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.803Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"The information in these optional fields SHALL also be included in FirstAddressLine or\nAdditionalAddressLines. The content of the mandatory elements SHALL NOT be repeated in any\nother field (e.g., the postal code SHALL NOT be included in the designated City field).\n\n2.8 Entity Legal Form Reporting\n\nLEl issuers SHALL ensure that cross reference to the entity legal form is standardized and included in\n\nan LEl record. GLEIF maintains the ISO 20275 standard and publishes the Entity Legal Forms (ELF)\n\nCode List. Codes from that list SHALL be used to populate EntityLegalFormCode. This list includes\n\nspecific and unique codes for all legal forms identified per jurisdiction and two reserved ELF codes\n\n(8888 and 9999) that are valid across jurisdictions.\n\nSpecific ELF code (not 8888 or 9999):\n\no If a specific ELF code is available for an entity's legal form in the entity's legal jurisdiction, it\nSHALL be used in EntityLegalFormCode.\n\no If EntityLegalFormCode is populated with a specific ELF code, OtherLegalForm SHALL NOT be\nprovided.\n\no If a specific code is removed from the ELF code list, the LEl issuer SHALL update all affected\nrecords representing an ACTIVE Legal Entity with a correct new code. The new ELF code SHALL\nNOT be 8888 or 9999 with the name of the just removed legal form as OtherLegalForm.\n\nReserved ELF codes 8888 and 9999:\n\ne Reserved ELF code 8888 is to be used when a new ELF code (for a legal form not yet on the list) is\nrequested by an LEl issuer from GLEIF for a jurisdiction which is on the ELF code list.\n\no Reserved ELF code 9999 is to be used for LEIs from a jurisdiction which is not on the ELF code list\nyet.\n\n¢ The reserved code 8888 SHALL be used only after a request email to elf@gleif.org with further\ndescription of the legal form has been sent.\n\no All requests for new ELF codes (and modifications) are collected over time and processed in time\nfor the periodical publication of a new version of the ELF code list. The approximate date(s) for\nthe publication of a new version SHALL be published well in advance.\n\n¢ In cases, where the suggested legal form has NOT been accepted, based on the reason for the\nrejection, the LEl issuer SHALL select one of the following options:\n\no Use a different existing ELF code assigned to the Legal Entity’s legal form (if possible).\ne Propose another new legal form to be added to the ELF code list and update OtherLegalForm\naccordingly.\n¢ Send more convincing documentation for the proposed legal form.\nState Transition and Validation Rules for Common Data File formats Page 34 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2669,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.803Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o Annul the LEl, but only if the outcome of the discussion is that the proposed legal form is not\neligible for an LEI.\n\n¢ In cases, where the suggested legal form has been accepted, the LEl issuer SHALL update all\napplicable records with the new ELF code, including records that are RETIRED, MERGED not later\nthan one month after publication, unless another implementation time has been set.\n\no If EntityLegalFormCode is populated with 8888 or 9999, OtherLegalForm SHALL include the\ncorrect name of the entity's legal form where no ELF code exists. Therefore, OtherLegalForm\nSHALL NOT contain any ELF code or undescriptive text like “OTHER”, “N/A” or “None”. The name\nprovided as free text SHALL be the same as used in the request sent to GLEIF to add the source to\nthe RA list.\n\n2.9 Language, translation and transliteration\n\ne Where LEl record fields allow for an optional (as per LEI-CDF) language tag, this tag SHALL always\nbe provided. This SHALL be an IETF Language Code conforming to the latest RFC from IETF BCP\n47.\n\ne For transliterated names and addresses then the language code SHALL specify the language of\nthe name or address prior to transliteration.\n\no TransliteratedOtherEntityNames SHALL include a list of ASClI-transliterated (i.e. Latin- or\nRomanized) representations of names for the Legal Entity in all cases of non-romanized\nLegalName.\n\no If using TransliteratedAddressType, the transliterated elements that correspond to the\nmandatory and optional information provided in either the LegalAddress, HeadquartersAddress,\nor OtherAddress SHALL be required, given any of these elements are provided in a non-latin\nalphabet.\n\ne If alegal name or address is provided in an alternative language, both the primary field and the\nalternative SHALL have a language tag, and both SHALL NOT be the same.\n\nState Transition and Validation Rules for Common Data File formats Page 35 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1997,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.803Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3 General State Transition and Validation Rules\nThese rules SHALL apply to the general Use Case for issuing and managing an LE| for a Legal Entity as\nwell as publishing the LEI Record Set. An LEI Record Set with complete Reference Data is composed\nof data fields that are published in different XML files. Each XML file has its own name space and\nschema file. These are:\ne LEl Entity Data (Level 1):\n* Name space: lei\no .xsd file: https://www.gleif.org/content/2-about-lei/6-common-data-file-format/1-\nupcoming-versions/2021-03-04_lei-cdf-v3-1.xsd\no LEI Relationship Data (Level 2):\no Name space: rr\no .xsd file: https://www.gleif.org/content/2-about-lei/6-common-data-file-format/1-\nupcoming-versions/2021-03-04_rr-cdf-v2-1.xsd\no Reporting exception Data (Level 2):\n¢ Name space: repex\no .xsd file: https://www.gleif.org/content/2-about-lei/6-common-data-file-format/1-\nupcoming-versions/2021-07-20_reporting-exceptions-format-v2-1.xsd\nThe complete Xpath is shown in the field description for each field. The schema description in the\n.xsd file provides a more technical definition of each element, including format restrictions, allowed\nvalues, etc. In case there is a discrepancy between the required cardinality of a field in this document\nand the corresponding CDF file, the definition in this document SHALL prevail.\nState Transition and Validation Rules for Common Data File formats Page 36 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1507,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.803Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.1 Header Section (applicable to all files)\nlei:LEIHeader\nrr:Header\nrepex:Header\n_ Contains the file upload information for this file.\n/lei:LEIData/lei:LEIHeader\n/rr:RelationshipData/rr:Header\n/repex:ReportingExceptionData/repex:Header\nThe Header Section describes the context for the LEI Records contained in the main body of the file.\nThe Header Section includes information on the origin and timestamp of the data. The content of the\nHeader Section SHALL NOT be required to interpret the data content of any LEI Record; each LEI\nRecord is self-contained. The Header Section includes the following elements:\ne Content Date\ne Originator\no File Content\no Delta Start\ne Record Count\n° Extension\nState Transition and Validation Rules for Common Data File formats Page 37 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":878,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.803Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.2 Content Date\nlei:ContentDate\nrr:ContentDate\nrepex:ContentDate\n_ The date and time as of which the data contained in the file is valid.\n/lei:LEIData/lei:LEIHeader/lei:ContentDate\n/rr:RelationshipData/rr:Header/rr:ContentDate\n/repex:ReportingExceptionData/repex:Header/repex:ContentDate\nThe Content Date for each record defines the date and time as of which the data contained in the file\nis valid. The following rules apply:\no The ContentDate SHALL be equal to or later than the latest InitialRegistrationDate in the file.\no The ContentDate SHALL be equal to or later than the latest LastUpdateDate in the file.\no The ContentDate SHALL be later than the DeltaStart date for delta files.\n3.3 Originator\nlei:Originator\nrr:Originator\nrepex:Originator\n_ The LEI of the LEl issuer that created the content of this file.\n/lei:LEIData/lei:LEIHeader/lei:Originator\n/rr:RelationshipData/rr:Header/rr:Originator\n/repex:ReportingExceptionData/repex:Header/repex:Originator\nState Transition and Validation Rules for Common Data File formats Page 38 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1148,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.803Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"e The Originator SHALL be a valid LEI with correct check digits as specified in the 1ISO 17442\nstandard document.\no The Originator SHALL contain the LEI of the LEl issuer publishing the file.\no If FileContent is not GLEIF_FULL_PUBLISHED or GLEIF_DELTA_PUBLISHED, Originator SHALL be\npopulated.\n3.4 File Content\nlei:FileContent\nrr:FileContent\nrepex:Content\n_ A code describing the content of this file.\n/lei:LEIData/lei:LEIHeader/lei:FileContent\n/rr:RelationshipData/rr:Header/rr:FileContent\n/repex:ReportingExceptionData/repex:Header/repex:FileContent\n¢ The value LOU_FULL_PUBLISHED for FileContent SHALL be used to designate a file containing all\nup-to-date LEI Records published by an LEl issuer.\no If FileContent is LOU_FULL_PUBLISHED, then DeltaStart SHALL NOT be present.\n¢ The value LOU_DELTA_PUBLISHED for FileContent is used to designate a file containing only LEI\nRecords newly added or changed since an LOU’s last upload.\no If FileContent is LOU_DELTA_PUBLISHED, then DeltaStart SHALL be present.\no If FileContent is neither LOU_DELTA_PUBLISHED nor GLEIF_DELTA_PUBLISHED, DeltaStart SHALL\nNOT be present.\nState Transition and Validation Rules for Common Data File formats Page 39 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1298,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.803Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.5 Delta Start\nlei:DeltaStart\nrr:DeltaStart\nrepex:DeltaStart\nThe date and time of the baseline relative to which this file contains\nnew or changed records.\n/lei:LEIData/lei:LEIHeader/lei:DeltaStart\n/rr:RelationshipData/rr:Header/rr:DeltaStart\n/repex:ReportingExceptionData/repex:Header/repex:DeltaStart\nCurrently, delta files are not provided or accepted by GLEIF.\no If Header contains the DeltaStart element, then FileContent SHALL be LOU_DELTA_PUBLISHED or\nGLEIF_DELTA_PUBLISHED.\n3.6 Record Count\nlei:RecordCount\nrr:RecordCount\nrepex:RecordCount\n_ The number of records in this file.\n/lei:LEIData/lei:LEIHeader/lei:RecordCount\n/rr:RelationshipData/rr:Header/rr:RecordCount\n/repex:ReportingExceptionData/repex:Header/repex:RecordCount\ne The number of instances of lei:LEIRecord, rr:Relationship or repex:ReportingException contained\nin this file SHALL equal the value of RecordCount.\nState Transition and Validation Rules for Common Data File formats Page 40 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1069,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.803Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.11 Lack of renewal —Legal Entity......ccccoeeviviieeiiiiiiiiee i scvvieeeessivieeeessssennnn. 107\n4.12 Lack of renewal — Related Legal Entity including head offices, fund managers,\numbrella and master fuNdS.........cccveeeiiiiiieiiere e ineee e e 107\n4.13 Update of LEI Reference Data due to Legal Entity Events .........ccccceevvvveeeeine.. 107\n4.13.1Legal Entity Event — Event timeline and status..........cccecceevviviiieeeinisceeeecnsiieeenn. 108\n4.13.2Legal Entity Event — Legal Name changes ......cccccevvveeeeivvieeesicciiieeececsiieeeseesvveeen e, 109\n4.13.3Legal Entity Event — Business or trading name changes ........ccccccceeevieeeiiiiiieennnnn, 112\n4.13.4Legal Entity Event — Address information changes........ccccevveevcvecviecceeeninennnn. 114\n4.13.5Legal Entity Event — Legal form changes........cccccvvveeveeecieeevcie e ceeecvvieeeeeesveees 116\n4.13.6Legal Entity Event — ACQUISITION ....coivviiiiieiiiiiie e csiieee s seeeee s esseveeee e 124\n4.13.7Legal Entity Event — AbSOrption ......cccveeeiiiiiieii e ccsiieeeecccrvieesssssvieee s sssnveeeeeees 125\n4.13.8Legal Entity EVENt — IMEIEI ..ccveeieeieiieeie ettt cssriitee et eesssavie e asssvseee s ssssveneeanns 128\n4.13.9Legal Entity Event — Transformation of a Subsidiary to an International Branch 131\n4.13.10 Legal Entity Event — Acquisition of an International Branch.......................... 134\n4.13.11 Legal Entity Event — Break-up ....ccccccceeeviieeiieiiieee s cciieeeeceviieeessesiieee s sssnieeeeeens 137\n4.13.12 Legal Entity Event — DeMErger....cccuveiivviviieiiiiieeeeeisieeeesssiieeessssneeessssvenneanns 140\n4.13.13 Legal Entity Event — Spin-0ff ......cccccoeiiiiiiie et sie e 142\n4.13.14 Legal Entity Event — Transformation of an International Branch to a Subsidiary\n144\n4.13.15 Legal Entity Event —BankruptCy .....ccccevvvveericiviieenscisiieeesecivieessessvieeesessvveneeeens 147\n4.13.16 Legal Entity Event — INnSOIVENCY.....uveevivviiiiiiiiiiiie e criieeeesssieee e essiieeee e 150\n4.13.17 Legal Entity Event — Liquidation.......ccccceuveeiiiiviieeiiiniieiecssiieeecsssieeeeessieeeeenns 150\n4.13.18 Legal Entity Event — DisSOIULION ......cccccviiiiiiiiiieee s cciiieeecciiieeeseesiieee s eesiieeeeeees 151\n4.13.19 Legal Entity Event — Voluntary Arrangement.........ccccceeveeviveeriecsieeeseesveenneens 151\n4.13.20 Legal Entity Event — Reverse Tak@oVver ......cccoceeeeivvveeieenniieeeinssieeesensnenneenns 154\n4.13.21 Legal Entity Event — Transformation of an Umbrella Fund to a Stand-Alone\n4.13.22 Legal Entity Event — Effects on parent and child relationships...................... 158\n4.13.23 Legal Entity Event — Erroneously introduced Legal Entity Event ................... 160\n4.14 Update of LEI Reference Data other than due to Legal Entity Events ................ 162\n4.15 LEI Record update — Registration information changes..........cccccceeviiiieeni . 162\n4.16 LEI Record update — Reporting Exception changes to Relationship Records......162\n4.17 LEI Record Set update — Entity or Relationship Data changes..........ccccceeeeeeee.. 163\n4.18 LEI Record Set update — Change of fund manager ........ccccoevvvvveievviiiiieeee i 163\n4.19 LEI Record Set update — Transfer......occcvveeviiiiiieiee i csssieee s sieieee s sssineen. 163\n4.20 Registration errors — Exclusivity Violation (duplication)......c...cccccevvveeeieeeen... 167\n4.21 Registration error — Relationship Record or reporting exception is a duplicate 167\n4.22 Registration error — Eligibility violation (invalid LEl issuance) ............................ 168\n4.23 Issue New LEl for an US company incorporated in one state but operating in\nANOTNET oo s e e s s s sanaae e e s s snsssaeeeses LO8\nG State Transition and Validation Rules for Common Data File formats Page 5 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":3843,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.803Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o Iflei:LEIRecord, rr:Relationship or repex:ReportingException is empty, then RecordCount SHALL\nbe 0.\no RecordCount SHALL NOT be negative (less than 0).\n3.7 Extension (applicable to multiple Header Sections and data\nsections)\nlei:Extension\nrr:Extension\nrepex:Extension\nThis Extension element contains any additional elements required to\nextend the Header or data container element.\n~/lei:Extension\n~/rr:Extension\n~/repex:Extension\no Extension elements MAY be included in all Header Sections and several data section elements\n(see corresponding .xsd files for details).\no There are no restrictions on the contents of the Extension element. For this reason, it is\nrecommended to inform recipients which elements to expect here.\nState Transition and Validation Rules for Common Data File formats Page 41 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":909,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.803Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.8 LEI Record\nContains LEI Reference Data including details of the LEI's registration\nwith the ManagingLOU.\n_ /lei:LEIData/lei:LEIRecords/lei:LEIRecord\nThe LEI Record is a container holding all Level 1 Reference Data including Entity Data and details of\nthe LEI's Registration with the ManagingLOU.\no Optional Extension elements MAY be included.\n3.9 LEI Code (context: LEI-CDF)\nThe 1SO 17442 compatible identifier for the Legal Entity described in\nthe Entity section.\n_ /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:LEl\ne The LEI Code SHALL be ISO 17442 compliant.\ne An LElI Code SHALL be used only once (uniqueness).\n¢ Only one LEl per Legal Entity may be reported (exclusivity).\no The LEl issuer SHALL be responsible for checking for duplicate LEls (uniqueness and exclusivity)\nprior to issuing, updating, renewing and transferring an LEl and publishing the LEI Record Set.\nState Transition and Validation Rules for Common Data File formats Page 42 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1060,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.804Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.10 Legal Name\n\n_ The legal name of the Legal Entity.\n\n_ /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:LegalName\n\no LegalName SHALL be the legal name of the entity in a local language and character set commonly\nused in the registration authority or in other authoritative validation sources.\n\n¢ LegalName SHALL be the primary legal name in case of being in a jurisdiction with more than one\nlegal name (e.g., in different languages).\n\n3.11 Other Entity Names\n\n_ lei:OtherEntityNames\n\nAn optional list of other names (excluding transliterations) for the\nLegal Entity.\n\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity\n/lei:OtherEntityNames\n\nThe OtherEntityNames element is a container including one or more other names for the Legal Entity\n\ntogether with a specification of a name type.\n\no The Legal Entity MAY provide an official, registered name for the Legal Entity in another language\nor a translated version of the entity's legal name. However, as far the local registry provides a\ntranslated or transliterated version of the legal name, these SHALL be made available in the\nappropriate element as part of the LEI Record Set.\n\nState Transition and Validation Rules for Common Data File formats Page 43 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1330,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.804Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"¢ Avalue of type OtherEntityName in a file conforming to this standard SHALL include an optional\nlanguage code, permitting OtherEntityName to be repeated as many times as necessary to\nexpress the same name type in multiple languages.\n\n¢ The language code of an OtherEntityName with type ALTERNATIVE_LANGUAGE_LEGAL_NAME\nSHALL NOT be the same as the LegalName's language code.\n\no OtherEntityName with type PREVIOUS_LEGAL_NAME SHALL NOT be the same as the current\nLegalName.\n\no OtherEntityName with type TRADING_OR_OPERATING_NAME SHALL NOT be the same as the\ncurrent LegalName.\n\n3.12 Transliterated Other Entity Names\n\n_ lei:TransliteratedOtherEntityNames\n\nAn optional list of ASClI-transliterated (i.e. Latin- or Romanized)\nrepresentations of names for the Legal Entity.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity\n/lei:TransliteratedOtherEntityNames\n\nThe TransliteratedOtherEntityNames element is a container including one or more transliterated\n\nnames for the Legal Entity together with a specification of the transliteration procedure.\n\no If populated, the TransliteratedOtherEntityNames SHALL include a list of ASClI-transliterated (i.e.\nLatin- or Romanized) representations of names for the Legal Entity in all cases of non-romanized\nLegalName.\n\no The general rules for transliteration SHALL apply (see section 2.9).\n\nState Transition and Validation Rules for Common Data File formats Page 44 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1513,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.804Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.13 Legal Address\nThe address of the Legal Entity as recorded in the registration of the\nLegal Entity in its legal jurisdiction.\n\n_ /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:LegalAddress\n\nThe LegalAddress element is a container including mandatory and optional elements comprising the\n\nentity’s legal address.\n\no LegalAddress SHALL be the address of the entity as recorded in the registration of the entity.\n\ne For an International Branch, LegalAddress SHALL be the address of the entity in the host country.\n\ne Forafund entity, LegalAddress SHALL be a current address provided in the business registry in\nwhich the entity was formed (for funds that are incorporated) or by the financial regulatory\nauthority where the entity is registered (for all other cases). If no such address is provided, a\nregistered address from the fund’s constituting documents SHALL be recorded as LegalAddress. If\nsuch documents are also not available, the registered address of the fund managing entity\nresponsible for the legal affairs of the fund SHALL be recorded as LegalAddress. In this case, a\n“care of” address structure (MailRouting) SHALL be used to signal that the address is one of a\ndifferent entity. See the LEI ROC policy on Fund Relationships and Guidelines for the registration\nof Investment Funds in the Global LEI System?® for details.\n\no If the entity is not registered, LegalAddress SHALL be the address mentioned in any document\nused to validate the existence of the entity, or, in lack of, the entity's declared center of control\n(same as HeadquartersAddress).\n\no The general rules for reporting addresses SHALL apply (see section 2.7).\n\n5 https://www.leiroc.org/publications/gls/roc_20190520-1.pdf\n\nState Transition and Validation Rules for Common Data File formats Page 45 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1901,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.804Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.14 Headquarters Address\n\n_ lei:HeadquartersAddress\n\n_ The address of the headquarters of the Legal Entity.\n\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Entity/lei:HeadquartersAddress\n\nThe HeadquartersAddress element is a container including mandatory and optional elements\n\ncomprising the entity’s headquarters address.\n\n¢ HeadquartersAddress SHALL be the address of the main office or center of control of a company\nor organization.\n\n¢ HeadquartersAddress MAY be the same as the LegalAddress of the Legal Entity.\n\ne For an International Branch, HeadquartersAddress SHALL be the address of the head office.\n\no For afund entity, HeadquartersAddress SHALL be the registered address of the fund managing\nentity. A “care of” address structure (MailRouting) SHALL be used to signal that the address is\none of a different entity.\n\ne For a Government Entity, HeadquartersAddress SHALL be the address of the entity itself or the\naddress of the authorized entity managing the LEI registration on behalf of the Government\nEntity. The address MAY be the same as LegalAddress. If another entity manages the registration,\na “care of” address structure (MailRouting) SHALL be used including the name of the entity\nmanaging the LEI registration.\n\ne For an International Organization with distributed field operations and no discernable main office\nor center of control, HeadquartersAddress SHALL be the location of a secretariat or similar\nadministrative central function.\n\no The general rules for reporting addresses SHALL apply (see section 2.7).\n\nState Transition and Validation Rules for Common Data File formats Page 46 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1723,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.804Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.15 Other Addresses\nAn optional list of other addresses for the Legal Entity, excluding\ntransliterations.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Entity/lei:OtherAddresses\nThe OtherAddresses element is a container including one or more other addresses associated with\nthe Legal Entity, including a specification of the type of address.\n¢ The language code of another address with type ALTERNATIVE_LANGUAGE_LEGAL_ADDRESS\nSHALL NOT be the same as that of the Legal Entity's LegalAddress.\n¢ The language code of any other address of type\nALTERNATIVE_LANGUAGE_HEADQUARTERS ADDRESS SHALL NOT be the same as that of the\nLegal Entity's primary HeadquartersAddress.\no Addresses in alternative languages SHALL describe the same location but SHALL NOT be literally\nidentical across all fields included.\ne The general rules for reporting addresses SHALL apply (see section 2.7).\n3.16 Transliterated Other Addresses\n_ lei:TransliteratedOtherAddresses\n_ An optional list of transliterated addresses for the Legal Entity.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Entity/lei:TransliteratedOtherAddresses\nState Transition and Validation Rules for Common Data File formats Page 47 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1286,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.804Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"The TransliteratedOtherAddresses element is a container including one or more transliterations of\nthe Legal Entity’s addresses.\no The general rules for reporting addresses SHALL apply (see section 2.7).\no The general rules for transliteration SHALL apply (see section 2.9).\n3.17 Registration Authority\n_ lei:RegistrationAuthority\nInformation about the official authority in the Legal Entity's\njurisdiction of legal registration, for example a business registry, and\nthe corresponding identification of the Legal Entity by that official\nsource.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Entity/lei:RegistrationAuthority\nThe RegistrationAuthority element is a container including a mandatory RegistrationAuthoritylD and\nthe optional RegistrationAuthorityEntitylD and OtherRegistrationAuthoritylD. The Legal Entity is\nresponsible to supply its local Registration Authority and identifier. This is for mapping to the local\nRegistration Authority.\no The rules for using GLEIF Registration Authority codes SHALL apply (see section 2.2.3)\nState Transition and Validation Rules for Common Data File formats Page 48 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1220,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.804Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.18 Registration Authority ID\n_ lei:RegistrationAuthoritylD\nThe reference code of the Registration Authority, taken from the\nRegistration Authorities Code List maintained by GLEIF.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity\n/lei:RegistrationAuthority/lei:RegistrationAuthoritylD\no RegistrationAuthoritylD SHALL be populated with a valid code from the Registration Authorities\nlist.\no For Legal Entities that are not registered in a registry, RegistrationAuthoritylD SHALL be\nRA999999.\no For EntityCategory BRANCH RegistrationAuthoritylD SHALL NOT be populated with the value\nRA999999.\no The general rules for Registration and Validation SHALL apply (see section 2.2).\n3.19 Other Registration Authority ID\n_ lei:OtherRegistrationAuthoritylD\nA legacy / historical reference code of a Registration Authority which\nis not yet entered in the Registration Authorities Code List (RA list)\nmaintained by GLEIF, or the designation of an interim register until\nsuch time as an entry from RA list can be delivered.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity\n/lei:RegistrationAuthority/lei:OtherRegistrationAuthoritylD\no OtherRegistrationAuthoritylD MAY be present when RegistrationAuthoritylD is populated.\nState Transition and Validation Rules for Common Data File formats Page 49 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1400,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.805Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o If RegistrationAuthorityID is RA888888, OtherRegistrationAuthoritylD SHALL include the name of\nthe Registration Authority, as submitted in the request sent to GLEIF to add a new code to the RA\nlist (see section 2.2.3).\n3.20 Registration Authority Entity ID\n_ lei:RegistrationAuthorityEntitylD\nThe identifier of the Legal Entity at the indicated Registration\nAuthority. Typically, the identifier of the Legal Entity as maintained by\na business registry in the jurisdiction of legal registration, or if the\nLegal Entity is one that is not recorded in a business registry, the\nidentifier of the Legal Entity in the appropriate Registration Authority.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity\n/lei:RegistrationAuthority/lei:RegistrationAuthorityEntitylD\no If the Registration Authority provides an entity ID, RegistrationAuthorityEntitylD SHALL be\npopulated with the entity ID from the register. If the authoritative source does not provide an\nentity ID, RegistrationAuthorityEntitylD SHALL NOT be included. This applies also, if RA888888 is\nused.\no RegistrationAuthorityEntitylD SHALL be populated, if lei:ValidationSources is\nFULLY_CORROBORTATED or PARTIALLY_CORROBORATED, with following exceptions:\n¢ The Legal Entity category (EntityCategory) is marked as FUND.\no RegistrationAuthorityEntitylD SHALL NOT be populated, if RegistrationAuthorityID is RA999999\nor one of the RA Codes identifying sources known to not providing an entity ID.\nState Transition and Validation Rules for Common Data File formats Page 50 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1634,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.805Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.24 Issue New LEI — Financial institution inthe US ............ccoe il 169\nAbout this Document\nThis document describes Business Rules for the issuance, updating, management and publication of\nLEI Reference Data according to the Common Data File (CDF) formats LEI-CDF 3.1, RR-CDF 2.1 and\nRepex-CDF 2.1.\nChange History\nThis section records the history of all changes to this document.\n2023-03-07 2.7.1 Clarified use of legal form for international branches GLEIF\n(3.21)\n2023-02-09 2.7 Add use cases for corporations and financial GLEIF\ninstitutions in the US (4.23, 4.24)\nProvide additional clarification on existing rules and\nguidelines for branches, funds in formation, and legal\nentity events (3.24, 3.31, 3.40, 3.52, 3.58, 4.2, 4.3, 4.4,\n4.8,4.13.1).\nRemove references which elements have been\nadded/deprecated in the latest CDF transition.\n2022-04-01 2.6 Added chapter 4.13.23 on resolving incorrectly GLEIF\nreported Legal Entity Events\nProvide additional clarification on existing rules and\nguidelines (2.1.2, 2.3.2, 2.7, 3.20, 3.26, 3.27, 3.36, 3.46,\n3.60, 3.61, 4.6, 4.13.1, 4.13.5, 4.13.9, 4.13.17, 4.13.18\nState Transition and Validation Rules for Common Data File formats Page 6 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1297,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.806Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.21 Legal Jurisdiction\n_ lei:Legallurisdiction\nThe jurisdiction of legal formation of the Legal Entity; i.e. where the\nlegal form of the Legal Entity originates.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Entity/lei:Legallurisdiction\no Legallurisdiction SHALL be a country or subdivision code from the GLEIF Accepted Legal\nJurisdictions Code List (https://www.gleif.org/en/about-lei/code-lists/gleif-accepted-legal-\njurisdictions-code-list). As per July 2020, all LEls SHALL be compliant with this list.\no Legallurisdiction SHALL contain the country or region where the Legal Entity Form originates. As\nsuch, the content of Legallurisdiction is linked to the content of LegalForm.\ne A company with a legal form from country A which has its address(es) in country B SHALL have A\nas its Legallurisdiction.\n¢ An International Branch SHALL always have the LegalForm and Legallurisdiction of the Legal\nEntity to which it belongs.\no For an International Organization established by treaties or other specific multinational\nagreements governed by international laws, Legallurisdiction SHALL be one of the following:\no UN, if the entity is the United Nations, one of their specialized agencies or other affiliated\norganizations.\no EU, if the entity is established by a treaty signed by all members of the European Union and\nno other countries.\no XX, in all other cases.\nState Transition and Validation Rules for Common Data File formats Page 51 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1550,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.806Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.22 Entity Category\nIndicates (where applicable) the category of Legal Entity identified by\nthis LEI Record, as a more specific category within the broad\ndefinition given in ISO 17442. These categories are based on Use\nCases specified in LEI-ROC policies, found at\nhttp://www.leiroc.org/list/leiroc_gls/index.htm.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Entity/lei:EntityCategory\n\nEntityCategory contains the general category of certain types of Legal Entities that are subject to\n\nspecial rules within the Global LEI System.\n\no For Legal Entities that are funds, individuals acting in a business capacity or International\nBranches, the EntityCategories of FUND, SOLE_ PROPRIETOR or BRANCH SHALL be assigned,\nrespectively.\n\no For Legal Entities that are Government entities, the EntityCategory\nRESIDENT_GOVERNMENT_ENTITY SHALL be assigned with an appropriate sub-category, where\napplicable.\n\no For organizations established by international agreement that may not be (only) subject to the\nlaws or regulations of the country or countries in which they are located, the EntityCategory\nINTERNATIONAL_ORGANIZATION SHALL be assigned.\n\no For Legal Entities that are not funds, individuals acting in a business capacity, International\nBranches, Government entities or International Organizations, the EntityCategory of GENERAL\nSHALL be assigned .\n\nAn LEI Record SHALL be identified as BRANCH, if:\n\n¢ The Branch is an International Branch as defined, outside of the head office’s jurisdiction. For\npurposes of the LEI-ROC policy document, jurisdiction is synonymous with country and\nInternational Branch is defined as a non-incorporated establishment of a Legal Entity, when this\nestablishment is located in a separate jurisdiction from the jurisdiction in which the head office\nof the (same) Legal Entity is located, i.e., in a host jurisdiction outside of its home jurisdiction.\nUnder this definition, an establishment may consist of a single office or other business premises,\n\nState Transition and Validation Rules for Common Data File formats Page 52 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2164,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.806Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"or of several offices (i.e., a branch network) in different locations of the same host jurisdiction:\neven in the latter case, only one LElI would be issued per host jurisdiction, essentially amounting\nto, one country-one LEI. Unlike foreign subsidiaries of a parent entity, which are separately\nincorporated as separate Legal Entities or organized under the laws of the host jurisdictions, an\nInternational Branch, as defined here, is legally dependent on the (head office) Legal Entity it\nbelongs to and cannot exist without its (head office) Legal Entity;\n\ne The Branch is registered in a publicly accessible local business registry, local regulatory registry or\ntax registry, preferably an RA source;\n\no The Legal Entity the Branch belongs to already has an LEIl so that the LEI of the (head office) Legal\nEntity can always be associated with the LEI of the International Branch in the Global LEI System;\nand\n\no The Reference Data of the International Branch in the LEI system includes a Branch relationship\nlinking the Branch to its (head office) Legal Entity.\n\nAn LEI Record SHALL be identified as FUND, if:\n\n¢ Inline with the governance principles of the Global LEI System, the Legal Entity reports being an\ninvestment fund, defined as a collective investment scheme (or pooled investment) beneficially\nowned by multiple investors and managed on behalf of those investors by an asset manager or\nby the fund itself.\n\n¢ Investment funds or collective investment schemes MAY not always be registered, or MAY be\nsubject to varying degrees of regulation, and there is therefore no single legal or regulatory\ndefinition. Above definition of fund entities SHALL apply to funds incorporated as a company as\nwell as funds established by contract.\n\no The LElissuer SHALL verify that the report of the Legal Entity being a fund is correct. LEl issuers\nare not required to verify whether an entity not reporting itself as a fund is a fund, except\nminimum due diligence including:\n\no whether the name of the fund includes the mention that it is a fund or any equivalent in the\nrelevant language and legal framework;\n\no whether the legal form necessarily means that the entity is a FUND;\n\n* whether the registry used to establish the existence of the entity is specific to funds;\n\no if the LEl of the Legal Entity is the EndNodelD of an ACTIVE relationship with\nRelationshipType IS_FEEDER_TO.\n\nAn LEI Record SHALL be identified as SOLE_PROPRIETOR, if:\n\nState Transition and Validation Rules for Common Data File formats Page 53 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2628,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.807Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"¢ The entity is a type of enterprise that is owned and operated by one person or family\nbusiness (married couple, mothers, fathers, siblings, etc.) and in which there is no legal\ndistinction between the owner’s assets and liabilities and the business entity.\no The person or family business has unlimited personal responsibility for all losses and debts.\n¢ Inseveral countries it would be possible to identify a Sole Proprietor from the business registry\n(RA source); in such cases all Registration Authority information should be incorporated.\nAn LEI Record SHALL be identified as RESIDENT_GOVERNMENT _ENTITY, if:\n¢ The Legal Entity is a non-market producer, part of a central, state or local government, social\nsecurity funds or a non-profit institution (NPI) controlled by government units.\no The definition of Government Entities® in the Global LEl System is in line with the underlying ISO\n17442 standard and further guided by the System of National Accounts (SNA).\no Astate owned, but independent general Legal Entity or Fund not part of or controlled by the\ngovernment SHALL NOT be categorized as RESIDENT_GOVERNMENT_ENTITY but rather as\nGENERAL or FUND, respectively.\nAn LEI Record SHALL be identified as INTERNATIONAL_ORGANIZATION, if:\no The Legal Entity is a non-resident unit, created by international agreement or other\narrangements for the provision of non-market services or financial intermediation at the\ninternational level.\no The special characteristics of an “international organization” as this term is used in the SNA may\nbe summarized as follows:\n¢ The members of an international organization are either national states or other\ninternational organizations whose members are national states; they thus derive their\nauthority either directly from the national states that are their members or indirectly from\nthem through other international organizations.\n\n¢ They are entities established by formal political agreements between their members that\nhave the status of international treaties; their existence is recognized by law in their member\ncountries.\n\n* Because they are established by international agreement, they are accorded sovereign\nstatus; that is, international organizations are not subject to the laws or regulations of the\n\n8 https://www.leiroc.org/publications/gls/roc_20201229.pdf\n\nState Transition and Validation Rules for Common Data File formats Page 54 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2504,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.807Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"country, or countries, in which they are located; they are not treated as resident institutional\nunits of the countries in which they are located.\n¢ International organizations are created for various purposes including, among others, the\n\nfollowing types of activities:\n\ne The provision of non-market services of a collective nature for the benefit of their\nmembers.\n\n¢ Financial intermediation at an international level, that is, channeling funds between\nlenders and borrowers in different countries.\n\n3.23 EntitySubCategory\n\nIndicates and specifies further (where applicable) the sub-category\n(sub-sector) of Legal Entity identified by this LElI Record and already\ncategorized by the EntityCategory field.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Entity/lei:EntitySubCategory\n\nEntitySubCategory contains the sub-category/sub-sector of certain categories of Legal Entities that\n\nare subject to special rules within the Global LEI System.\n\no Legal Entities other than RESIDENT_GOVERNMENT_ENTITY (i.e., GENERAL, FUND, BRANCH,\nSOLE_PROPRIETOR, INTERNATIONAL ORGANIZATION) SHALL NOT declare any subsector or sub-\ncategory.\n\no Legal Entities that are classified as RESIDENT_GOVERNMENT_ENTITY in the EntityCategory field\nSHALL declare its Government subsector, if available and applicable.\n\nFigure 5 provides a schematic overview of the structure of a General Government and sets the\n\nbaseline for the subsector definitions.\n\nState Transition and Validation Rules for Common Data File formats Page 55 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1611,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.807Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"General Government\nCentral Administration\nState Government\nSocial Security\nFunds Local Government\nLocal Local Local Local Local Local\nGovernment Government Government Government Government Government\nAl A2 B1 B2 C1 C2\nLocal Local Local Local Local Local\nGovernment Government Government Government Government Government\nA3 A4 B3 B4 c3 c4\nPublic corporation 1 Public corporation 2 Public corporation 3 Public corporation n\no\n\nFigure 5: Scheme of a General Government\n\nAn LEI Record SHALL be identified as CENTRAL_GOVERNMENT, if:\n\n¢ The central government subsector consists of the institutional units plus non-profit institution\n(NPI) controlled by the central government institutions (paragraph 4.134 of the SNA). Paragraph\n4.135 of the SNA defines central administration as comprising all institutional units that extend\ntheir authority over the entire territory of the country.\n\nAn LEI Record SHALL be identified as STATE_GOVERNMENT, if:\n\no The state government subsector consists of the institutional units that exercise some\ngovernment functions at a level below that of the central government and above that of the\ngovernment institutional units existing at a local level. These are institutional units whose fiscal,\nlegislative and executive authority extends over individual states in which the country, as a\nwhole, may be divided. In some countries, especially small countries, individual states and state\ngovernments may not exist (paragraph 4.141 of the SNA). The state government usually has the\nfiscal authority to levy taxes on institutional units that are resident in or engage in economic\nactivities or transactions within its area of competence (paragraph 4.142 of the SNA).\n\nAn LEI Record SHALL be identified as LOCAL_GOVERNMENT, if:\n\n¢ The local government subsector consists of local governments that are separate institutional\nunits. The scope of their authority is generally much less than that of central government or state\ngovernments, and they may or may not, be entitled to levy taxes on institutional units resident in\n\nState Transition and Validation Rules for Common Data File formats Page 56 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2230,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.807Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"their areas (paragraph 4.145 of the SNA).\n\nAn LEI Record SHALL be identified as SOCIAL_SECURITY, if:\n\ne Social security schemes are social insurance schemes that cover the community as a whole or\nlarge sections of the community and are imposed and controlled by government units. The\nschemes cover a wide variety of programmes, providing benefits in cash or in kind for old age,\ninvalidity or death, survivors, sickness and maternity, work injury, unemployment, family\nallowance, health care, etc. (paragraph 4.124 of the SNA). They can operate at all levels of\nGovernment (paragraph 4.147 of the SNA). When social security schemes are separately\norganized from the other activities of government units and hold their assets and liabilities\nseparately from the latter and engage in financial transactions on their own account, they qualify\nas institutional units that are described as social security funds. However, institutional\narrangements in respect of social security schemes differ from country to country and in some\ncountries they may become so closely integrated with the other finances of government as to\nbring into question whether they should be treated as separate institutional units. (paragraph\n4.125 of the SNA).\n\nIf a Government Entity does not fit the definitions of one of these sub-categories, EntitySubCategory\n\nSHALL NOT be provided.\n\n3.24 Legal Form\n\n_ The legal form of the Legal Entity.\n\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:LegalForm\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:LegalForm\n\n/lei:EntityLegalFormCode\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:LegalForm\n/lei:OtherLegalForm\n\nThe legal form of the Legal Entity is represented by the LegalForm container. It consists of two\n\nelements: EntityLegalFormCode and OtherLegalForm.\n\no EntityLegalFormCode SHALL be taken from the ISO 20275 Entity Legal Form (ELF) Code list\nmaintained by GLEIF.\n\nState Transition and Validation Rules for Common Data File formats Page 57 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2108,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.807Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o If EntityCategory is not BRANCH, the ELF code SHALL have a legal jurisdiction matching the LEI’s\nLegallurisdiction.\no If EntityCategory is BRANCH, LegalForm SHALL be the legal form of the (head office) Legal Entity.\ne For an International Organization, LegalForm SHALL be 9999, the reserved code for jurisdictions\nnot on the ELF code list. OtherLegalForm SHALL include the name of the treaty establishing the\nentity. If a series of treaties or updates of treaties were signed to form the entity, only the latest\none establishing it in its current form SHALL be included.\no The general rules for Entity Legal Form Reporting SHALL apply (see section 2.8).\ne If one of the reserved ELF codes is used, OtherLegalForm SHALL be present.\no If any non-reserved ELF code is used, OtherLegalForm SHALL be omitted.\n3.25 Entity Status\nThe operational and/or legal registration status of the Legal Entity\n(may be ACTIVE, INACTIVE or NULL).\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Entity/lei:EntityStatus\nThe EntityStatus of an LEI Record SHALL indicate the status of the Legal Entity itself. It is linked to\nother data fields related to especially INACTIVE entities or records (e.g., SuccessorLEl,\nRegistationStatus).\no If EntityStatus is set to ACTIVE, the RegistrationStatus SHALL NOT be set to RETIRED.\no Accepted values for the field are:\no ACTIVE: As of the last report or update, the Legal Entity reported that it was legally registered\nand operating.\no INACTIVE: It has been determined that the Legal Entity that was assigned the LEl is no longer\nlegally registered and/or operating, as indicated by a recorded Legal Entity Event.\ne NULL: Providing an ACTIVE or INACTIVE status of the Legal Entity is not applicable .\nState Transition and Validation Rules for Common Data File formats Page 58 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1904,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.807Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o If EntityStatus is set to INACTIVE, the RegistrationStatus SHALL NOT be set to either ISSUED or\nLAPSED and SHALL NOT be PENDING_TRANSFER or PENDING_ARCHIVAL, except for very rare\ncases that require the transfer of an LEI Record representing an inactive Legal Entity.\n\n¢ The EntityStatus is set to NULL in following cases:\n\no The LEl reaches one of the end stages of its lifecycle representing an error — ANNULLED or\nDUPLICATE.\no The LElisissued for a FUND entity in a jurisdiction (e.g., Spain), where the existence of an LElI\nis a prerequisite to be able to register the entity itself (see section 4.3).\n3.26 Entity Creation Date\nThe date on which the Legal Entity was first established, as\nrepresented by ISO 8601 (as defined in ISO 17442).\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/\nlei:EntityCreationDate\n\no The date when the Legal Entity has been created, formed or incorporated SHALL be provided for\nall LEI Record Sets not yet reached an end stage of their lifecycle.\n\n¢ The information SHALL be extracted from the local registry (if applicable and the entity is a\nregistered entity) or from the legal documents provided by the entity (in case of entity supplied\ndata only). This information provides additional value to the LEI Record Set and will simplify the\nefforts with future mapping partners. It will also enable a high-automated process for mapping\nand potential duplicate identification.\n\n¢ The date provided SHALL be in ISO 8601 datetime format with a minimum value 0001-01-\n01T00:00:00.\n\n¢ If only the year and month of the creation are known and no information about the exact day of\nthe month is availble, the LEIl issuer SHALL use the first day of the respective month.\n\n¢ If the entity is a BRANCH, EntityCreationDate SHALL be the date of the creation of the Branch\nitself and not the date of the creation of the (head office) Legal Entity to which it belongs.\n\nState Transition and Validation Rules for Common Data File formats Page 59 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2080,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.807Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.27 Successor Entity\n\n_ One or more Legal Entities that continue or replace this LEI.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Entity/lei:SuccessorEntity\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Entity/lei:SuccessorEntity/lei:SuccessorLEl\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Entity/lei:SuccessorEntity/lei:SuccessorEntityName\n\nThe SuccessorEntity element is a container including one or more successor entities, identified by\n\neither an LEl or by legal name.\n\no The SuccessorEntity container SHALL be used to report the surviving or new LEI Record Set in\ncases of an Exclusivity Violation or when a Legal Entity Event occurred, requiring the provision of\none or more Successor Entity information.\n\no The SuccessorEntity SHALL be identified either by LEl or by LegalName.\n\no If RegistrationStatus is DUPLICATE, SuccessorLEI SHALL include the LEI of the surviving LEI\nRegistration and SuccessorEntityName SHALL NOT be included.\n\no If one of the following Legal Entity Events has been recorded in the LegalEntityEvents section, the\nSuccessorLElI SHALL be provided, in case the successor Legal Entity holds an LEI; and\nSuccessorEntityName SHALL be provided, in case the successor Legal Entity does not hold an LEI:\no DEMERGER\no SPINOFF\no ACQUISITION_BRANCH\no TRANSFORMATION_BRANCH_TO_SUBSIDIARY\no TRANSFORMATION_UMBRELLA_TO_STANDALONE\no BREAKUP\n+ MERGERS_AND_ACQUISITIONS\n\no If one of the following Legal Entity Events involves a successor entity, the SuccessorLElI SHALL be\nprovided, in case the successor Legal Entity holds an LEI; and SuccessorEntityName SHALL be\nprovided, in case the successor Legal Entity does not hold an LEI:\n\nState Transition and Validation Rules for Common Data File formats Page 60 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1838,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.807Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"2021-12-22 2.5 Added use case for change in fund management (4.18). | GLEIF\nProvide additional clarification on existing rules and\nguidelines (2,2,3, 2.8, 3.24, 3.29, 3.33, 3.36, 3.51, 3.61,\n4.2,4.4,4.7,4.13.1,4.13.3,4.13.4, 4.13.5, 4.13.8,\n4.13.9,4.13.13, 4.13.15, 4.13.16, 4.13.19, 4.21)\n\n2021-09-30 2.4 Provide additional clarification on existing rules and GLEIF\nguidelines (3.36, 3.51, 3.53 several use cases in chapter\n4)\n\nReflect changes due to Repex-CDF 1.2 (3.65, 4.14) and\ndeprecation of the Provisional Node Identifier (PNI)\n(2.1.2,2.2.2,3.49,4.1.2,4.8,4.9,4.13.22, 4.18, 4.20)\nIntroduction of RA777777 (2.2.3, 3.44, 3.45, 3.46, 4.6,\n4.7)\n\n2021-06-21 2.3 Provide additional clarification on existing rules and GLEIF\nguidelines (3.20, 3.23, 3.30, 3.46, 3.57, 4.18)\n\n2021-03-08 2.2 Introduced changes due to ROC policy on Government | GLEIF\nEntities and International Organizations (3.22, 3.23,\n3.53,4.6,4.7)\n\nProvide additional clarification on existing rules and\nguidelines\n\n2020-12-17 2.1 Highlight text elements and paragraphs with the CDF GLEIF\nformat version when these become effective\nProvide additional clarification on existing rules and\nguidelines (2.2, 2.3, 3.20, 3.26, 4.1, 4.11)\n\n2020-07-31 2.0 Updated general structure of the document GLEIF\nCombined STVR for Level 1 and Level 2\nUpdated general rules in chapter 2 to clarify existing\nrules and guidelines (2.2, 2.3, 2.7, 2.8, 2.9)\n\nIncluded per element description and rules for relevant\n\nXML elements in chapter 3.\n\nRevised existing and added new Use Cases in chapter 4.\n\nIntroduced changes due to LEI-ROC Fund Relationship\n\npolicy implementation (2.1.2, 3.50)\n\nIntroduced changes due to LEI-ROC Legal Entity Events\n\npolicy implementation (new elements 3.27-3.36)\n\nUpdated description and rules for EntityCategory (3.22)\n\nUpdated description and rules for EntityStatus (3.24)\nState Transition and Validation Rules for Common Data File formats Page 7 of 170\n\n@ Public Version 2.7.1 Final\n\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2036,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.807Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"+ CHANGE_LEGAL_NAME\n+ CHANGE_OTHER_NAMES\n¢ CHANGE_LEGAL_FORM\no BANCRUPTCY\n¢ LIQUIDATION\no If the SuccessorLEl is provided, the SuccessorEntityName SHALL NOT be present and vice versa.\no If the SuccessorLEl is provided, it SHALL NOT have the same LEI as the replaced entity’s LEI\nRecord.\n3.28 Legal Entity Events\n_ lei:LegalEntityEvents\nContainer for a finite number of events specified by the LEI ROC in\nthe life of a Legal Entity that would impact the Reference Data in the\nGlobal LEI System.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity\n/lei:LegalEntityEvents\n¢ The container Legal Entity Events SHALL be provided, when at least one of the Legal Entity Event\ntypes in scope occurred.\no The container SHALL contain at least one Legal Entity Event instance or one Legal Entity Event\nGroup instance.\nState Transition and Validation Rules for Common Data File formats Page 61 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":991,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.807Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.29 Legal Entity Event\n_ lei:LegalEntityEvents\nContainer for a finite number of events specified by the LEI ROC in\nthe life of a Legal Entity that would impact the Reference Data in the\nGlobal LEI System.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity\n/lei:LegalEntityEvents\ne Each Legal Entity Event container SHALL include two to four attributes, associated with event\nstatus and grouping of Legal Entity Events:\no @group_type: This mandatory attribute defines, whether or not this Legal Entity Event is\npart of a group of events. Allowed enumerations:\n\no STANDALONE: Single / standalone Legal Entity Event with no combination of multiple\nevents.\n\no CHANGE_LEGAL_FORM_AND_NAME: Legal Entity Event including change of the legal\nname triggered by change of the legal form.\n\no COMPLEX_CHANGE_LEGAL_FORM: Legal Entity Event including change of the Legal\nEntity status triggered by change of the legal form.\n\ne REVERSE_TAKEOVER: This event is part of a reverse takeover Legal Entity Event.\n\no @event_status: This mandatory attribute defines the status of the Legal Entity Event with\nregard to the event timeline. Allowed enumerations:\n\n* IN_PROGRESS: The Legal Entity Event activity and processing is in progress.\n\no WITHDRAWN_CANCELLED: The Legal Entity Event as announced will not occur.\n\no COMPLETED: The Legal Entity Event activity and processing have been completed as of\nthe LegalEntityEventEffectiveDate.\n\no @group_id: An identifier assigned to link events that are part of the same group of multiple\nor complex events:\n\ne SHALL be the exact same string for all events linked together.\n\ne SHALL be provided for events having a @group_type\nCHANGE_LEGAL_FORM_AND_NAME or REVERSE_TAKEOVER and SHALL NOT be\npopulated for events having a @group_type STANDALONE or\nCOMPLEX_CHANGE_LEGAL_FORM events.\n\nState Transition and Validation Rules for Common Data File formats Page 62 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1989,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.807Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"e @group_sequence_no: A number which indicates the sequence of each Legal Entity Event\nwithin a group of events.\ne SHALL NOT be populated for STANDALONE events.\ne SHALL be provided for event groups with a logical sequence of events, like a\nREVERSE_TAKEOVER event group.\ne SHALL NOT be populated, if the event sequence is not important as all events happen at\nthe exact same time, for example a change in legal name due to a change in legal form\n(event type CHANGE_LEGAL_FORM_AND_NAME).\n¢ The event that happened first SHALL have @group_sequence_no 1 (one), the next 2\n(two), etc. Each @group_sequence_no SHALL be used only once within a group.\n¢ Inorder to describe Legal Entity Events, each Legal Entity Event container SHALL contain the\nfollowing fields:\no LegalEntityEventType\no LegalEntityEventEffectiveDate\no LegalEntityEventRecordedDate\n* ValidationDocuments\n¢ ValidationReference (optional)\no AffectedFields\no LegalEntityEvent elements SHALL NOT be updated.\n¢ Anew LegalEntityEvent element SHALL be created, if an already existing LegalEntityEvent\nchanges its @event_status from IN_PROGRESS to COMPLETED or WITHDRAWN_CANCELLED.\no A LegalEntityEvent with @event_status IN_PROGRESS SHALL NOT be removed in case a\nfollow up event with @event_status COMPLETED or WITHDRAWN_CANCELLED is introduced.\ne A LegalEntityEvent MAY be updated, if only typing errors or similar minor inconsistencies are\nremediated.\nState Transition and Validation Rules for Common Data File formats Page 63 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1592,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.807Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.30 Legal Entity Event Type\n_ lei:LegalEntityEventType\n_ The type of Legal Entity Event.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/\nlei:LegalEntityEvents/lei:LegalEntityEvent/\nlei:LegalEntityEventType\no Legal Entity Event Type SHALL be always provided as part of the descriptive data of a Legal Entity\nEvent\n¢ The following types of Legal Entity Events SHALL be recorded in the Global LEI System as part of\nthe LEI Record Set. Data collection for high priority Legal Entity Events SHALL begin with the\n\nimplementation of LEI-CDF 3.1. Events with a medium or low priority SHALL be collected at a\n\nlater date but MAY also be included earlier.\n\ne High priority Legal Entity Events (to be implemented by 31 March 2022):\n\no CHANGE_LEGAL_NAME: Change in the legal name of the Legal Entity.\n\ne CHANGE_OTHER_NAMES: Change in the trade- or doing business name of the Legal Entity.\n\no CHANGE_LEGAL_ADDRESS: Change in the legal address of the Legal Entity.\n\no CHANGE_HQ_ADDRESS: Change in the Headquarters Address of the Legal Entity.\n\no CHANGE_LEGAL_FORM: Change in the legal form of the Legal Entity.\n\ne ACQUISITION_BRANCH: The acquiring Legal Entity purchases an International Branch entity.\n\no TRANSFORMATION_BRANCH_TO_SUBSIDIARY: The transfer of all of the assets and liabilities\nof a Legal Entity in relation to an International Branch to the new Subsidiary entity in\nexchange for the transfer of securities representing the capital of the Subsidiary entity\nreceiving the transfer.\n\no TRANSFORMATION_SUBSIDIARY_TO_BRANCH: The transfer of all of the assets and liabilities\nof a Subsidiary to an International Branch entity in exchange for the transfer of securities of\nthe Legal Entity to which the Branch belongs, representing the capital of the International\nBranch entity receiving the transfer.\n\no TRANSFORMATION_UMBRELLA_TO _STANDALONE: Change in legal form from a Fund Legal\nEntity structure with one or more than one sub-funds/compartments to a Fund Legal Entity\nstructure without sub-funds/compartments.\n\nState Transition and Validation Rules for Common Data File formats Page 64 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2204,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.808Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o DISSOLUTION: (i) A voluntary termination of operations, (ii) a general assignment for the\nbenefit of the Legal Entity’s creditors or (iii) any other liquidation, dissolution or winding up\nof the Legal Entity (excluding a Liquidity Event), whether voluntary or involuntary.\n\n¢ Medium priority Legal Entity Events (TBD):\n\n» BREAKUP: A break-up is a corporate action in which a single company splits into two or more\nindependent, separately run companies. Regulators also can mandate break-ups of\ncompanies for anti-trust reasons.\n\no MERGERS_AND_ACQUISITIONS: The consolidation of Legal Entities or assets through various\ntypes of financial transactions, including mergers, acquisitions, consolidations, tender offers,\npurchase of assets and management acquisitions.\n\no DEMERGER: Distribution of securities issued by another Legal Entity. The distributed\nsecurities may either be of a newly created or of an existing Legal Entity. For example, spin-\noff, demerger, unbundling, divestment.\n\no SPINOFF: A special case of demerger where the shareholders of the original entity are\ncompensated for the value loss of the original entity via shares of the new entity or via\ndividend.\n\no Low priority Legal Entity Events (TBD):\n\no BANKRUPTCY: Legal status of a Legal Entity unable to pay creditors. Bankruptcy usually\ninvolves a formal court ruling. Securities may become valueless.\n\n¢ LIQUIDATION: Distribution of cash, assets or both of a Legal Entity. Debt may be paid in order\nof priority based on preferred claims to assets specified by the security.\n\no VOLUNTARY_ARRANGEMENT: A procedure that allows a Legal Entity to settle debts by\npaying only a proportion of the amount that it owes to creditors or to come to some other\narrangement with its creditors over the payment of its debts.\n\no INSOLVENCY: The entry of a decree or order by a court or agency or supervisory authority\nhaving jurisdiction in the premises the appointment of a trustee-in-bankruptcy or similar\nofficial for such party in any insolvency, readjustment of debt, marshalling of assets and\nliabilities, or similar proceedings, or for the winding up or liquidation of their respective\naffairs.\n\no ABSORPTION: Absorption is a form of merger where there is a combination of two or more\ncompanies into an 'existing company'. In the case of absorption, only one company survives,\nand all others lose their identity. (The addition of Absorption to the list of Legal Entity Events\ncovered by the policy is under review with the LEI-ROC.)\n\no REVERSE_TAKEOVER: A reverse takeover is the acquisition of a larger, publicly traded\ncompany by a smaller private company. It involves complex series of events including\nacquisition, absorption and name change.\n\nState Transition and Validation Rules for Common Data File formats Page 65 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2896,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.808Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.31 Legal Entity Event Effective Date\n\n_ lei:LegalEntityEventEffectiveDate\n\n_ The date when the Legal Entity Event becomes legally effective.\n\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/\nlei:LegalEntityEvents/lei:LegalEntityEvent/lei:/\nlei:LegalEntityEventEffectiveDate\n\no LegalEntityEventEffectiveDate SHALL provide the date (not considering the time) when the Legal\nEntity Event becomes legally effective, if the date is known or in the past (event_status\nCOMPLETED).\n\no LegalEntityEventEffectiveDate MAY be omitted, if the date is not known (applies only, if the\nevent_status of the Legal Entity Event is IN_PROGRESS or WITHDRAWN_CANCELLED). If the date\nis known for not yet completed Legal Entity Events, LegalEntityEventEffectiveDate SHALL be\nprovided.\n\ne The format SHALL be according to the ISO 8601 standard. The time part of the content SHALL be\nalways '00:00:00' independent of the provided Time Zone.\n\no LegalEntityEventEffectiveDate SHALL be provided as part of the descriptive data of a Legal Entity\nEvent.\n\no LegalEntityEventEffectiveDate SHALL be limited to dates after 0001-01-01T00:00:00.\n\no LegalEntityEventEffectiveDate MAY be equal to LegalEntityEventRecordedDate if the actual\nLegalEntityEventEffectiveDate is not known.\n\nState Transition and Validation Rules for Common Data File formats Page 66 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1437,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.808Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.32 Legal Entity Event Recorded Date\n_ lei:LegalEntityEventRecordedDate\nThe date when the Legal Entity Event was recorded in the Global LEI\nSystem\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/\nlei:LegalEntityEvents/lei:Legal EntityEvent/\nlei:LegalEntityEventRecordedDate\no LegalEntityEventRecordedDate SHALL be always provided as part of the descriptive data of a\nLegal Entity Event.\no LegalEntityEventRecordedDate SHALL provide the date and timestamp when the Legal Entity\nEvent was recorded in the Global LEI System.\no Ifthe event_status is COMPLETED, LegalEntityEventRecordedDate SHALL be equal to, or after the\nLegalEntityEventEffectiveDate.\n3.33 Validation Documents (context: LEI-CDF)\n_ lei:ValidationDocuments\nType of source document(s) used for validating the\nLegal Entity Event.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/\nlei:LegalEntityEvents/lei:Legal EntityEvent/\nlei:ValidationDocuments\no The type of Validation documents used to corroborate the Legal Entity Event SHALL be provided.\ne Currently accepted type of documents to validate Legal Entity Events are:\no ACCOUNTS_FILING: A consolidated financial (accounting) statement, prepared and submitted\nto the relevant authority.\nState Transition and Validation Rules for Common Data File formats Page 67 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1394,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.808Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"¢ REGULATORY_FILING: A regulatory filing providing public information on Legal Entities\nand/or their relationships (e.g.: documents submitted to a (financial) regulator).\ne SUPPORTING_DOCUMENTS: Other documents supporting the validation of Legal Entities\nand/or their relationships (e.g.: business registers or other authoritative sources).\no CONTRACTS: Contract(s) attesting to the validity of Legal Entities and/or their relationships.\no OTHER_OFFICIAL_DOCUMENTS: Other official document(s) attesting to the validity of Legal\nEntities and/or their relationships (e.g.: notarized documents).\n3.34 Validation Reference (context: LEI-CDF)\n_ lei:ValidationReference\nA reference to a specific document or other source used as the basis\nof validation for this Legal Entity Event.\nlei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/\nlei:LegalEntityEvents/lei:Legal EntityEvent/\nlei:ValidationReference\no The content of ValidationReference SHALL contain a reference to a specific document or other\nsource used as the basis of Legal Entity Event Validation for this record.\n3.35 Affected Fields\nA list of LEI Record Set elements that are expected to be updated in\nthe LEI Record Set as a result of a Legal Entity Event.\nlei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/\nlei:LegalEntityEvents/lei:LegalEntityEvent/\nlei:AffectedFields\nAffectedFields is a container element including one or more AffectedField elements.\nState Transition and Validation Rules for Common Data File formats Page 68 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1597,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.808Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o This container SHALL include all relevant changes to the LEI Record Set due to the Legal Entity\nEvent.\n\no This container can only exist within a Legal Entity Event element.\n\n3.36 Affected Field\n\nA single element and its value that is expected to be updated in the\nLEl Record Set as a result of a Legal Entity Event.\nlei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/\nlei:LegalEntityEvents/lei:LegalEntityEvent/\nlei:AffectedFields/lei:AffectedField\n\nEach AffectedField refers to an LEI Record Set element that will be affected by the Legal Entity Event.\n\no AffectedField SHALL include an attribute (@field_xpath), referring to the full Xpath to a single\nelement that is expected to be updated in the LEI Record Set as a result of a Legal Entity Event.\n\no The value of AffectedField SHALL be the expected value of the data element due to Legal Entity\nEvent. Values for Legal Entity Events in progress (@event_status IN_PROGRESS) MAY not be\nalways available, but the LEl issuer SHALL report these elements if available.\n\no For events with @event_status COMPLETED, leading to the introduction of one or more\nSuccessorEntitiy entries, AffectedFields SHALL be provided, presenting the values of the recorded\nsuccessor entities.\n\no If no SuccessorEntity was introduced due to the Legal Entity Event with @event_status\nCOMPLETED or WITHDRAWN_CANCELLED, AffectedFields SHALL NOT be provided.\n\no Expected values for the attribute @field_xpath are:\n\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:LegalName\n\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:OtherEntityNames/lei:OtherEntityNam\ne\n\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:OtherEntityNames/lei:OtherEntityNam\ne@type\n\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:TransliteratedOtherEntityNames/lei:Tr\nansliteratedOtherEntityName\nState Transition and Validation Rules for Common Data File formats Page 69 of 170\n\n@ Public Version 2.7.1 Final\n\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2024,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.808Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:TransliteratedOtherEntityNames/lei:Tr\nansliteratedOtherEntityName@type\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:LegalAddress/*\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:HeadquartersAddress/*\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:OtherAddresses/*\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:TransliteratedOtherAddresses/*\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:Legallurisdiction\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:EntityCategory\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:LegalForm/lei:EntityLegalFormCode\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:LegalForm/lei:OtherLegalForm\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:SuccessorEntity/lei:SuccessorLEl\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:SuccessorEntity/lei:SuccessorEntityNa\nme\no /rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord/rr:Relationship/rr:EndNo\nde/rr:NodelD\no /rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord/rr:Relationship/rr:EndNo\nde/rr:NodeType\no /rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord/rr:Relationship/rr:Relatio\nnshipType\no /[repex:ReportingExceptionData/repex:ReportingExceptions/repex:Exception/repex:Exceptio\nnCategory\no /[repex:ReportingExceptionData/repex:ReportingExceptions/repex:Exception/repex:Exceptio\nnReason\ne For all above mentioned address containers (LegalAddress, HeadquartersAddress,\nOtherAddresses and TransliteratedOtherAddresses) the concrete data elements SHALL be\nprovided.\nState Transition and Validation Rules for Common Data File formats Page 70 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1851,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.808Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Updated description and rules for SuccessorEntity\n(3.26)\nUpdate description and rules for RelationshipStatus\n(3.52)\nDeprecated AssociatedEntity (3.67),\nEntityExpirationDate (3.68) and EntityExpirationReason\n(3.69)\nClarification on branch entities (4.2)\n2018-01-26 1.2 2.2.5 — updated as ELF code list is now available GLEIF\n2.8 - 2\" bullet point updated from\nIf ValidationSources is ENTITY_SUPPLIED_ONLY then\nValidationAuthorityID and ValidationAuthorityEntitylD\nMUST NOT be populated to\nIf ValidationSources is ENTITY_SUPPLIED_ONLY then\nValidationAuthorityID is RA999999\n2.9 — last bullet point: added or RA999999 has been\nentered). In these cases, OtherRegistrationAuthoritylD\nmay provide information on the documents supplied\nby the Legal Entity for Validation.\n3.1 - LegalName: added in the local language and\ncharacter set.\n3.2 — LegalAddress: added This is the jurisdiction of\nlegal formation and registration of the branch entity.\n3.16 — added If the LEI-CDF record is also a head office\nthen the associated branch entities must all be in\nstatus ISSUED following the renewal of the head office\nLEI.\n2017-05-04 1.1 2.2: added included in Originator GLEIF\n2.4: updated\n2.6: replaced relationships with LEls\n2.9: updated\n2.11: removed PENDING\n3.8: added branches\n3.17: added branches\n2016-11-30 1.0 Final version GLEIF\nState Transition and Validation Rules for Common Data File formats Page 8 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1505,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.808Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.37 Initial Registration Date (context: LEI-CDF)\n\n_ lei:InitialRegistrationDate\nThe date of the first LEl assignment, being the date of publication of\nthe identifier and its supporting data record as represented in I1SO\n8601.\n\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Registration/lei:InitialRegistrationDate\n\n¢ InitialRegistrationDate SHALL be set with the date when the LEI Record transits from the internal,\n\nnot published status PENDING_VALIDATION to ISSUED.\n\ne Once set, InitialRegistrationDate SHALL NOT be updated. This applies also when the LEI Record\n\nSet is being transferred to a different LEI issuer.\n\no The InitialRegistrationDate SHALL NOT be later than LastUpdateDate or NextRenewalDate.\n\n3.38 Last Update Date (context: LEI-CDF)\n\n_ Date/time the LEI Record was most recently updated.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Registration/lei:LastUpdateDate\n\n* Any update to an LEl record SHALL be indicated by setting the LastUpdateDate to the date the\n\nupdate occurred.\n\no There SHALL be at least one other field in the record that changed when LastUpdateDate is\n\nupdated.\n\no There SHALL NOT be any update to any other field without also an update to LastUpdateDate.\n\no LastUpdateDate SHALL NOT be earlier than InitialRegistrationDate.\n\no lastUpdateDate SHALL NOT be a date in the future.\n\nState Transition and Validation Rules for Common Data File formats Page 71 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1503,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.808Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.39 Registration Status (context: LEI-CDF)\n_ lei:RegistrationStatus\nThe status of the Legal Entity's LEI registration with the\nManagingLOU.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Registration/lei:RegistrationStatus\n\nThe element RegistrationStatus describes the status of the LEI registration.\n\no If RegistrationStatus is ISSUED, then EntityStatus SHALL be ACTIVE and ValidationSources SHALL\nNOT be PENDING.\n\no If RegistrationStatus is ISSUED, then NextRenewalDate SHALL be greater than or equal to the\nContentDate of the XML file.\n\no If RegistrationStatus is LAPSED, then NextRenewalDate SHALL be earlier than ContentDate.\n\no If the RegistrationStatus is LAPSED, the LEI Reference Data MAY still be updated.\n\no If RegistrationStatus is DUPLICATE, then SuccessorEntity SHALL be populated.\n\no If RegistrationStatus is ANNULLED, then SuccessorEntity MAY be populated.\n\no If the RegistrationStatus is RETIRED, no further updates to Entity sections of registration records\nin these states SHALL occur. Exceptions are allowed for updated information about the correct\nstatus, mapping to new code lists or ensuring high data quality of the record.\n\no MERGED — DEPRECATED .\n\n3.40Next Renewal Date (context: LEI-CDF)\n\n_ lei:NextRenewalDate\n\nThe next date by which the LEI registration should be renewed and\nre-certified by the Legal Entity.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Registration/lei:NextRenewalDate\n\no NextRenewalDate SHALL be later than InitialRegistrationDate.\n\nState Transition and Validation Rules for Common Data File formats Page 72 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1669,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.809Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"* NextRenewalDate SHALL NOT be later than ContentDate plus one year and sixty days.\n3.41 Managing LOU (context: LEI-CDF)\nThe LEI of the LOU that is responsible for administering this LEI\nregistration.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Registration/lei:ManagingLOU\nManagingLOU identifies the LEl issuer currently managing the LEI Record.\n¢ ManagingLOU SHALL be populated with the LEI of the LEl issuer.\n¢ ManagingLOU SHALL be populated with the LEI of a GLEIF Accredited LEl issuer for all LElI Record\nSet files published. Exceptions are allowed only for Candidate LEl issuers during testing and\nonboarding.\n¢ ManagingLOU SHALL be identical to the Originator in the file header for all LEI Record Sets\nuploaded to GLEIF.\n3.42 Validation Sources (context: LEI-CDF)\n_ lei:ValidationSources\nThe level of Validation of the Reference Data provided by the\nregistrant.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Registration/lei:ValidationSources\nThe LEl issuer notes the level of Validation in the Reference Data via the element ValidationSources:\no If ValidationSources is either PARTIALLY_CORROBORATED or FULLY_CORROBORATED then a\nspecific ValidationAuthoritylD SHALL be populated and which SHALL be different from RA999999\nand RA888888. The ValidationAuthorityEntitylD SHALL be populated given the register is\navailable for publication.\nState Transition and Validation Rules for Common Data File formats Page 73 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1533,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.809Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o If ValidationSources is ENTITY_SUPPLIED_ONLY then ValidationAuthoritylD SHALL be either\nRA999999 or RA888888.\no If ValidationSources is set to PENDING, then the LEIl record SHALL NOT be published and is only\nfor internal LOU use.\no The general rules laid out in section 2.2 SHALL apply.\n3.43 Validation Authority\n_ lei:ValidationAuthority\nInformation about the (primary) official authority in the Legal Entity's\njurisdiction of legal registration, for example a business registry, and\nthe corresponding identification of the Legal Entity by that official\nsource used to validate the Legal Entity Reference Data.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Registration/lei:ValidationAuthority\ne The container ValidationAuthority SHALL be provided and the LEl issuer is responsible to supply\nthe related information according to the rules described in section 2.2.\n3.44 Validation Authority ID\n_ lei:ValidationAuthoritylD\nThe reference code of the Registration Authority, taken from the\nRegistration Authorities Code List (RA list) maintained by GLEIF.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Registration/lei:ValidationAuthority\n/lei:ValidationAuthorityID\n¢ ValidationAuthoritylD SHALL be populated with a valid code from the Registration Authorities list\n(see section 2.2).\no For LEI Records that are not validated against a registry, ValidationAuthoritylD SHALL be\nRA999999.\nState Transition and Validation Rules for Common Data File formats Page 74 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1572,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.809Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o For Government Entities and International Organizations, RA777777 SHALL be used in case there\nis no information available in any regular registration authority and Public Legal Documents are\nused instead for partially or fully corroborated records.\n\n3.45 Other Validation Authority ID\n\n_ lei:OtherValidationAuthoritylD\n\nA legacy / historical reference code of a Registration Authority which\nis not yet entered in the Registration Authorities Code List (RA list)\nmaintained by GLEIF, or the designation of an interim register until\nsuch time as an entry from RA list can be delivered.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Registration/lei:ValidationAuthority\n/lei:OtherValidationAuthoritylD\n\no OtherValidationAuthoritylID MAY be present when ValidationAuthoritylID is populated.\n\no If ValidationAuthorityID is RA888888, OtherValidationAuthoritylD SHALL include the name of the\nRegistration Authority, as submitted in the request sent to GLEIF to add a new code to the RA list\n(see section 2.2).\n\no If ValidationAuthorityID is RA777777, OtherValidationAuthoritylD SHALL include the name and\nreference and where possible the link to the documents used for corroboration.\n\nState Transition and Validation Rules for Common Data File formats Page 75 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1364,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.809Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.46 Validation Authority Entity ID\n\n_ lei:ValidationAuthorityEntitylD\nThe identifier of the entity at the indicated Registration Authority.\nTypically, the identifier of the Legal Entity as maintained by a\nbusiness registry in the jurisdiction of legal registration, or if the\nentity is one that is not recorded in a business registry (e.g., one of\nthe varieties of funds registered instead with financial regulators),\nthe identifier of the entity in the appropriate Registration Authority.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Registration/lei:ValidationAuthority\n/lei:ValidationAuthorityEntitylD\n\no If the Registration Authority used for Validation provides an entity ID,\n\nValidationAuthorityEntitylD SHALL be populated with the entity ID from the authoritative source.\n\no If the authoritative source does not provide an entity ID, ValidationAuthorityEntitylD SHALL NOT\n\nbe included.\n\no IfRA777777 or RA888888 is used, the ValidationAuthorityEntitylD MAY be provided depending\n\non the source.\n\n¢ ValidationAuthorityEntityID SHALL NOT be populated, if ValidationAuthoritylD is RA999999 or\n\none of the RA Codes identifying sources known to not providing an entity ID.\n\n3.47 Other Validation Authorities\n\n_ lei:OtherValidationAuthorities\nAn optional list of additional Registration Authorities used by the LEI\nissuer to validate the entity data.\n\n_ {0,1} with {1,n} lei:OtherValidationAuthority included\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Registration/lei:OtherValidationAuthorities\n\ne OtherValidationAuthorities is a container that MAY be included to provide information about\n\nadditional Validation Authorities used for Validation.\nState Transition and Validation Rules for Common Data File formats Page 76 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1838,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.809Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o All subsets in OtherValidationAuthorities MAY repeat the same source as ValidationAuthority in\ncase the source uses different local identifiers for the same legal entity.\no Every subset in OtherValidationAuthorities SHALL be unique within this registration.\no OtherValidationAuthorities SHALL NOT include any subset having ValidationAuthorityID as\nRA999999.\n3.48 Start Node\n_ An LEI for the Legal Entity at the start of a directional relationship.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Relationship/rr:StartNode\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Relationship/rr:StartNode/rr:NodelD\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Relationship/rr:StartNode/rr:NodeType\nThe StartNode identifies the entity which is, where applicable, the child or lower node of a\nhierarchical relationship.\no StartNode/NodelD SHALL be the LEI of the child entity in the relationship.\no StartNode/NodeType SHALL be LEI.\no StartNode/NodelD SHALL be different from EndNode/NodelD.\nState Transition and Validation Rules for Common Data File formats Page 77 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1234,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.809Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.49 End Node\nAn LEl or ISO 17442-compatible ID for the Legal Entity at the end of a\ndirectional relationship.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Relationship/rr:EndNode\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Relationship/rr:EndNode/rr:NodelD\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Relationship/rr:EndNode/rr:NodeType\nThe EndNode identifies the entity which is, where applicable, the parent or higher node of a\nhierarchical relationship.\n¢ EndNode/NodelD SHALL be the LEI of the direct or ultimate accounting consolidating parent\nentity in the relationship.\no EndNode/NodelD SHALL be different from the StartNode/NodelD.\n© EndNode/NodeType SHALL be LEI in case the EndNode/NodelD contains an LEI.\n3.50 Relationship Type\nA unique code designating the specific category of a directional\nrelationship between two Legal Entities.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Relationship/rr:RelationshipType\no RelationshipType SHALL specify relationship between the StartNode and the EndNode.\nCurrently, three use-cases for relationships exist in the Global LEI System:\n1. Accounting Consolidating Parent Relationship:\nState Transition and Validation Rules for Common Data File formats Page 78 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1421,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.810Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o For the direct accounting consolidating parent, RelationshipType SHALL be\nIS_DIRECTLY_CONSOLIDATED_BY\n\ne For the ultimate accounting consolidating parent, RelationshipType SHALL be\nIS_ULTIMATELY_CONSOLIDATED_BY\n\n2. International Branch Relationship:\n\n¢ The RelationshipType SHALL be IS_INTERNATIONAL_BRANCH_OF for a Branch entity when\nconnecting to its head office.\n\nBoth above-mentioned use-cases are mutually exclusive; if an active consolidating relationship is\npresent, there cannot be an active Branch Relationship and vice versa.\n3. Fund Relationships are (see Figure 6) :\n\n¢ RelationshipType SHALL be IS_FUND-MANAGED_BY, if the StartNode is a fund managed by a\nmain management entity in a Fund Management Entity relationship. The EndNode is legally\nresponsible for the constitution and operation of the fund.\n\no RelationshipType SHALL be IS SUBFUND_OF, if the StartNode is a sub-fund to an umbrella\nfund in an Umbrella Structure relationship. The EndNode is a Legal Entity with one or more\nthan one sub-funds/compartments where each sub-fund/compartment has its own\ninvestment objectives, separate investment policies and strategies, segregation of assets,\nseparate investors and which has segregated liability between sub-funds/compartments.\n\no RelationshipType SHALL be IS_FEEDER_TO, if the StartNode is a Feeder Fund, that is (almost)\nexclusively invested in a single other fund in a Master-Feeder Relationship. The EndNode is\nthe Master Fund that has identical investment strategies.\n\n4 \\\nISSUBFWbERTO\nIS_FUND-MANAGED_BY \\\n\\_{/\nFigure 6: Fund Relationship types\n\nState Transition and Validation Rules for Common Data File formats Page 79 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1759,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.810Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.51 Relationship Periods\nA collection of paired beginning and end dates relating to the\nrelationship itself, periods (e.g., accounting cycles) covered by\ndocuments demonstrating the relationship, or the filing date(s) of\nthose documents.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Relationship/rr:RelationshipPeriods\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Relationship/rr:RelationshipPeriods/rr:StartDate\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Relationship/rr:RelationshipPeriods/rr:EndDate\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Relationship/rr:RelationshipPeriods/rr:PeriodType\nRelationshipPeriods contain three elements:\no StartDate: Date the relationship begins\no EndDate: Date the relationship ends\no PeriodType: The kind of relationship period\n¢ The StartDate of a RelationshipPeriod SHALL NOT be later than the EndDate, if provided.\no The StartDate SHALL NOT be later than the Relationship Record’s LastUpdateDate.\no The StartDate SHALL NOT be earlier than the LEI Record’s EntityCreationDate.\no Relationship Records can have multiple RelationshipPeriods simultaneously, but only one at a\ntime for any given PeriodType.\no ARelationshipPeriod SHALL always include StartDate and PeriodType. EndDate is optional and\nSHALL NOT be provided if the period has no defined EndDate or the date is unknown.\no All Relationship Records SHALL include exactly one RelationshipPeriod with PeriodType\nRELATIONSHIP_PERIOD.\nState Transition and Validation Rules for Common Data File formats Page 80 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1716,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.810Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"All changes made during creation (for clarity and reading ease as well as significant changes),\nincrease the version number by 0.1.\nThe approved PID is considered to be the final version and gets version number 1.0.\nState Transition and Validation Rules for Common Data File formats Page 9 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":398,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.810Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o Relationships with RelationshipType IS_DIRECTLY_CONSOLIDATED_BY and\nIS_ULTIMATELY_CONSOLIDATED_BY SHALL include one RelationshipPeriod with PeriodType\nACCOUNTING_PERIOD.\n\no Relationships with RelationshipType IS_INTERNATIONAL_BRANCH_OF MAY include one\nRelationshipPeriod with PeriodType ACCOUNTING_PERIOD.\n\no Relationships with RelationshipType IS_FUND-MANAGED_BY, IS_SUBFUND_OF and\nIS FEEDER_TO SHALL NOT include any RelationshipPeriod with PeriodType\nACCOUNTING_PERIOD.\n\no Relationship Records MAY include one RelationshipPeriod with PeriodType\nDOCUMENT_FILING_PERIOD.\n\nRelationshipPeriod with PeriodType = RELATIONSHIP_PERIOD\n\nIndicates the duration of the relationship itself, regardless of when the relationship was first included\n\nin the Global LEI System. The StartDate would indicate the earliest date at which the relationship\n\nexisted. If that information is not available or exactly known, it SHALL be the earliest date where the\nvalidity of the relationship could be corroborated. Usually, this date will be earlier than the\n\nInitialRegistrationDate of the relationship. For ACTIVE relationships, EndDate SHALL NOT be included,\n\nwhile for INACTIVE relationships, EndDate SHALL be populated with the last date the relationship\n\nexisted. StartDate and, once provided, EndDate would not generally be updated, unless the originally\nrecorded date was incorrect.\n\nRelationshipPeriod with PeriodType = ACCOUNTING_PERIOD\n\nIndicates the time period reflected in the source document (generally distinct from the date of the\n\ndocument) and is intended to indicate the accounting period covered by the most recent Validation\n\ndocuments. The accounting period for relationships based on accounting consolidation SHALL be\nupdated with the latest accounting period during renewals.\n\nRelationshipPeriod with PeriodType = DOCUMENT_FILING_PERIOD\n\nIndicates the date of the document filing or publication. This only applies where the Validation\n\ndocuments are filed or publicly available. The StartDate SHALL be the date of document filing or\n\npublication.\n\nIf the Validation documents also indicate the period over which the filing applies, the EndDate SHALL\n\nbe the end date of this period. Although entities should be encouraged to provide the exact dates\n\nwhen known, start and end dates MAY be approximated by the date of the situation described in the\nfirst accounting statement showing consolidation or the end of consolidation, respectively. For\ninstance, what is sought here is not that the accounting statement used for Validation is for the year\n\n2019, but that the relationship was valid at least as of 31 December 2019.\n\nState Transition and Validation Rules for Common Data File formats Page 81 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2812,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.810Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.52 Relationship Status\n_ rr:RelationshipStatus\nThe status of the Legal Entities' relationship itself: ACTIVE, INACTIVE\nor NULL.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Relationship/rr:RelationshipStatus\no RelationshipStatus SHALL reflect the status of the relationship.\n¢ RelationshipStatus SHALL be ACTIVE if both Legal Entities are operational and the relationship\nbetween them is current and verified.\no RelationshipStatus SHALL be INACTIVE if one of the Legal Entities ceased to exist or the\nrelationship is no longer current.\no RelationshipStatus SHALL be NULL if the RegistrationStatus of the Relationship Record is\nDUPLICATE or ANNULLED .\no RelationshipStatus MAY be NULL in the exceptional case of a fund in formation (see chapter 4.4).\n3.53 Relationship Qualifiers\n_ rr:RelationshipQualifiers\nAny additional qualitative attributes that help to categorize\nthe relationship.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Relationship/rr:RelationshipQualifiers\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord/r\nr:Relationship/rr:RelationshipQualifiers/rr:RelationshipQualifier/rr:Q\nualifierDimension\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord/r\nr:Relationship/rr:RelationshipQualifiers/rr:RelationshipQualifier/rr:Q\nualifierCategory\nState Transition and Validation Rules for Common Data File formats Page 82 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1519,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.810Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Definitions of accounting consolidation and other relationship types could vary by jurisdiction. The\nLegal Entity reports the accounting consolidation, which is verified by the LEl issuer. Available values\nare:\n\no rr:QualifierDimension:\n\ne ACCOUNTING_STANDARD: The accounting standard applied to determine the definition of\ne.g., ultimate or direct accounting consolidating parent for the relationship detailed in this\nRelationshipRecord. The relevant accounting standard is that applicable to the EndNode (the\n\"parent” entity).\n\ne rr:QualifierCategory:\n\no US_GAAP: United States-Generally Accepted Accounting Principles.\n\no IFRS: International Financial Reporting Standard (developed by the International Accounting\nStandards Board — IASB see http://www.ifrs.org)\n\no OTHER_ACCOUNTING_STANDARD: A financial reporting (accounting) standard not otherwise\nlisted in the latest version of the relationship data file format.\n\no GOVERNMENT_ACCOUNTING_STANDARD: Used for entities consolidated under the\nInternational Public Sector Accounting Standard (IPSAS 35) or National Government or\nFederal Government accounting standards specifically developed for Government entities in\ntheir state or local jurisdiction.\n\nThe declaration of the consolidating standards SHALL follow below rules and hierarchies:\n\n* International standards SHALL overrule local GAAPs.\n\no The GOVERNMENT_ACCOUNTING_STANDARD SHALL be used only when both StartNode and\nEndNode are categorized as RESIDENT_GOVERNMENT_ENTITY or\nINTERNATIONAL_ORGANIZATION, respectively.\n\no Entities categorized as RESIDENT_GOVERNMENT_ENTITY SHALL declare direct and ultimate\nparent only by GOVERNMENT_ACCOUNTING_STANDARD; none of the other accounting\nstandards SHALL be used.\n\nState Transition and Validation Rules for Common Data File formats Page 83 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1906,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.811Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.54 Relationship Quantifiers\n_ rr:RelationshipQuantifier\nAny additional quantitative attributes that help to categorize\nthe relationship.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Relationship/rr:RelationshipQuantifiers\n¢ The Quantifier Dimension allows adding quantitative attributes to a relationship, like the\npercentage of shares the parent holds, etc.\n3.55 Initial Registration Date (context: RR-CDF)\nThe date at which the relationship information was first collected by\nthe ManaginglLOU.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Registration/rr:InitialRegistrationDate\no InitialRegistrationDate SHALL be set when the Relationship Data Record transits from the\ninternal, not published status PENDING_VALIDATION to PUBLISHED, analog to the\nInitialRegistrationDate within the context of LEI Data.\no LEl Records for Level 1 and Level 2 Reference Data MAY have a different InitialRegistrationDate,\ndepending on when each record was entered into the Global LEI System.\no Likewise, different Relationship Records for the same child entity MAY have different\nInitialRegistrationDates.\ne Once set, InitialRegistrationDate SHALL NOT be updated. This applies also when the Relationship\nRecords is being transferred to a different LEl issuer.\n¢ The InitialRegistrationDate SHALL not be later than LastUpdateDate or NextRenewalDate.\nState Transition and Validation Rules for Common Data File formats Page 84 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1567,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.811Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.56 Last Update Date (context: RR-CDF)\n\nThe date at which the information was most recently updated by the\nManagingLOU.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Registration/rr:LastUpdateDate\n\n¢ Any update to a Relationship Record SHALL be indicated by setting the LastUpdateDate to the\ndate the update occurred.\n\no There SHALL be at least one other field in the record that changed when LastUpdateDate is\nupdated.\n\no There SHALL NOT be any update to any other field without also an update to LastUpdateDate.\n\no LlastUpdateDate SHALL NOT be earlier than InitialRegistrationDate.\n\no lastUpdateDate SHALL never be a date in the future.\n\n3.57 Registration Status (context: RR-CDF)\n\n_ rr:RegistrationStatus\n\nThe status of the Legal Entity's Relationship Record\n\nregistration with the ManagingLOU.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Registration/rr:RegistrationStatus\n\nThe element RegistrationStatus describes the status of the relationship registration.\n\no If RegistrationStatus is PENDING_VALIDATION, the record SHALL NOT be published in any files\nwith Content Type LOU_FULL_PUBLISHED, LOU_DELTA_PUBLISHED, GLEIF_FULL_PUBLISHED, or\nGLEIF_DELTA_PUBLISHED.\n\no If RegistrationStatus is PUBLISHED, then RelationshipStatus SHALL be ACTIVE, and\nValidationSources SHALL NOT be PENDING.\n\nState Transition and Validation Rules for Common Data File formats Page 85 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1525,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.811Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o If RegistrationStatus is PUBLISHED, then NextRenewalDate SHALL be greater than or equal to the\nContentDate.\no If RegistrationStatus is RETIRED, then RelationshipStatus SHALL be INACTIVE.\n¢ A RegistrationStatus of CANCELLED SHALL NOT be published.\no If RegistrationStatus is LAPSED, then NextRenewalDate SHALL be earlier than ContentDate.\n3.58 Next Renewal Date (context: RR-CDF)\nThe next date by which the relationship information SHALL be\nrenewed and re-certified by the Legal Entity.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Registration/rr:NextRenewalDate\no NextRenewalDate SHALL be later than InitialRegistrationDate.\n¢ The NextRenewalDate for relationships with RelationshipType IS_DIRECTLY_CONSOLIDATED_BY\nor IS_ULTIMATELY_CONSOLIDATED_BY SHALL be the same for the child LEl and the Relationship\nRecords.\nState Transition and Validation Rules for Common Data File formats Page 86 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1025,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.811Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.59 Managing LOU (context: RR-CDF)\nThe LEI of the LOU that is responsible for administering this\nRelationship Record.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Registration/rr:ManagingLOU\nManagingLOU identifies the LEl issuer currently managing the LEI Relationship Records.\n¢ ManagingLOU SHALL be populated with the LEI of the LEl issuer.\n¢ ManagingLOU SHALL be populated with the LEI of a GLEIF Accredited LEl issuer for all LElI Record\nfiles published. Exceptions are allowed only for Candidate LEl issuers during testing and\nonboarding.\n¢ ManagingLOU SHALL be identical to the Originator in the file header for all LElI Records uploaded\nto GLEIF.\n¢ ManagingLOU SHALL be identical to the ManagingLOU in the LEI Record for the child Legal Entity\nrepresented by the StartNode of the relationship.\n3.60 Validation Sources (context: RR-CDF)\n_ rr:ValidationSources\n_ Level of relationship Validation.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Registration/rr:ValidationSources\n¢ ValidationSources SHALL be FULLY_CORROBORATED, if an accounting consolidation relationship\ncan be validated using current and confirmed consolidated financial statements or other\naccepted documents. Fund relationships SHALL be FULLY_CORROBORATED, if the relationship\ncan be validated using regulatory filings to regulators or central banks as well as registers and\ndatabases kept by competent authorities. A fund prospectus vetted by such authority is also\naccepted, even if the source of the document is the fund manager and not the regulator.\nState Transition and Validation Rules for Common Data File formats Page 87 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1762,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.811Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o ValidationSources SHALL be PARTIALLY_CORROBORATED, if the accepted documents have\ndifferent definitions of accounting consolidation or if the documents make it likely that an\naccounting consolidation relationship exists but the confirmed financial statements do not\ninclude this situation, yet.\n\n¢ ValidationSources SHALL be ENTITY_SUPPLIED_ONLY, if the conditions for assigning\nFULLY_CORROBORATED or PARTIALLY _CORROBORATED are not met and the Validation relies\nsolely on unconfirmed documents provided by the Legal Entity. For fund relationships, this also\nincludes a prospectus not (yet) vetted by the authorities.\n\n3.61 Validation Documents (context: RR-CDF)\n\n_ rr:ValidationDocuments\n\nType of source document(s) used for validating the\n\nrelationship.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Registration/rr:ValidationDocuments\n\n¢ The type of Validation documents used to corroborate the relationship SHALL be provided.\n\nCurrently accepted type of documents to validate relationships are:\n\no ACCOUNTS_FILING: A consolidated financial (accounting) statement, prepared and submitted\nto the relevant authority.\n\no REGULATORY_FILING: A regulatory filing providing public information on Legal Entities\nand/or their relationships (e.g.: documents submitted to a (financial) regulator, including a\nfund prospectus made available on the regulator’s web site).\n\ne SUPPORTING_DOCUMENTS: Other documents supporting the validation of legal entities\nand/or their relationships (e.g.: business registers or other authoritative sources, such as\nofficial fund register or databases for regulated fund entities provided by the regulator).\n\no CONTRACTS: Contract(s) attesting to the validity of Legal Entities and/or their relationships.\n\no OTHER_OFFICIAL_DOCUMENTS: Other official document(s) attesting to the validity of Legal\nEntities and/or their relationships (e.g.: notarized documents or a fund prospectus provided\nby the fund manager).\n\ne If ValidationSources is ENTITY_SUPPLIED_ONLY the ValidationDocuments are none of the sources\nadmitted for FULLY_CORROBORATED and PARTIALLY_CORROBORATED.\n\nState Transition and Validation Rules for Common Data File formats Page 88 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2302,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.811Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o If ValidationDocuments is REGULATORY_FILING, the ValidationReference element SHALL be\npresent and contain, if available, the filing URL (including name and full path). The filing URL MAY\ncontain other standard identifiers e.g., DOI (Digital Object Identifier).\n\n3.62 Validation Reference (context: RR-CDF)\n\n_ rr:ValidationReference\n\nA reference to a specific document or other source used as the\nbasis of relationship Validation for this Relationship Record.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Registration/rr:ValidationReference\n\no The content of ValidationReference SHALL contain a reference to a specific document or other\nsource used as the basis of relationship Validation for this record.\n\n3.63 LEI (context: Repex-CDF)\n\n_ The LEI for the Legal Entity which raised this exception.\n\n/repex:ReportingExceptionData/repex:ReportingExceptions\n/repex:Exception/repex:LEl\n\ne SHALL contain the LEI of the entity reporting the exception (i.e.: the child Legal Entity).\n\ne The EntityCategory in the record assigned to this LEI SHALL NOT be BRANCH.\n\n3.64 Exception Category\n\nState Transition and Validation Rules for Common Data File formats Page 89 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1290,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.811Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"A category of mandatory information reporting, beyond the\nminimum required for Legal Entity identification, which the Legal\nEntity declines, giving reasons and references where applicable.\n/repex:ReportingExceptionData/repex:ReportingExceptions\n/repex:Exception/repex:ExceptionCategory\n\nThe ExceptionCategory of a Reporting exception defines whether the exception applies to the\n\nreporting of the direct parent or the ultimate parent.\n\no Relationship Records and Reporting exceptions SHALL be mutually exclusive for the same parent\nreporting (direct vs. ultimate).\n\no If a Reporting exception having ExceptionCategory\nDIRECT_ACCOUNTING_CONSOLIDATING_PARENT is present, no active Relationship Records\nhaving RelationshipType IS_DIRECTLY_CONSOLIDATED_BY SHALL be present.\n\no If a Reporting exception having ExceptionCategory\nULTIMATE_ACCOUNTING_CONSOLIDATING_PARENT is present, no active Relationship Records\nhaving RelationshipType IS_ULTIMATELY_CONSOLIDATED_BY SHALL be present.\n\n3.65 Exception Reason\n\nA single reason provided by the Legal Entity for declining to\nprovide the mandatory report of a specified type of information\n(beyond the minimum Reference Data needed purely for\nidentification of the Legal Entity).\n/repex:ReportingExceptionData/repex:ReportingExceptions\n/repex:Exception/repex:ExceptionReason\n\nThe LEI-ROC has specified scenarios where the child Legal Entity may report it does not have a parent\n\naccording to the definition used or it may decline to provide parent information.\n\nThe LEl issuer MAY also report an exception given the parent does not have an LEI yet. Different\n\nexception reasons apply in each scenario:\n\nState Transition and Validation Rules for Common Data File formats Page 90 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1825,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.812Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"1 Introduction\n\nThe State Transition and Validation Rules (STVR) describe Business Rules and their technical\n\nimplementation for the issuance, updating, management and publication of LEI Reference Data\n\naccording to the Common Data File (CDF) formats.\n\n¢ Rules enforced by the XML schema are documented in the xsd files for LEI-CDF, RR-CDF and\nREPEX-CDF in their latest version.\n\n¢ Rules required in addition to the XML schema definition (also called Business Rules, data\nmanagement rules, STVR) are documented separately here.\n\nNOTE: These Business Rules are written by GLEIF to provide specific steps for the LEl issuers to follow\n\nin producing and quality assuring the LEI data they provide to GLEIF and publish in the Global LEI\n\nSystem.\n\nNOTE: Each CDF data field is presented here with:\n\n¢ Element name\n\no Description or rationale (source) per data element\n\ne Cardinality\n\no The Xpath identifying the unique data field in its CDF XML representation\n\no General rules\n\nNOTE: During implementation and transition periods between versions of the related CDF formats,\n\nthere might be certain descriptions, listing or explanations relevant only for a specific version of the\n\nCDF formats. These could relate to the upcoming version as well as to the retiring version. In order to\n\nmake these differences more visible to the reader, in this document such elements are highlighted\n\nwith the information about the related version. Some examples, but nor limited to these are (added\n\nin LEI-CDF x.x), (updated in RR-CDF x.x), (deprecated in LEI-CDF x.x).\n\n1.1 Terms and Definitions\n\nBranch/International A lead International Branch or International Branch network outside\n\nBranch of the headquarters’ jurisdiction.\n\nBusiness Rule GLEIF’s legal, organizational and technical rules for implementation\nof the LEI-ROC’s high-level policies for LEl data beyond the technical\nrules enforced by the relevant XML schema.\n\nState Transition and Validation Rules for Common Data File formats Page 10 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2093,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.812Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"e Child Legal Entity reports it does not have a parent according to the definition used:\no NATURAL_PERSONS: the child Legal Entity is controlled by (a) natural person(s).\n© NON_CONSOLIDATING: the child Legal Entity is not subject to reporting in consolidated\nfinancial statements.\no NO_KNOWN_PERSON: there is no known person controlling the child Legal Entity (e.g.,\ndiversified shareholding).\no Child Legal Entity reports it does have a parent according to the definition used but this parent\ndoes not yet have an LEI:\n+ NO_LEI\no Child Legal Entity has an accounting consolidation parent relationship but declines to provide\nparent information due to other obstacles:\no NON_PUBLIC for all of the below use cases:\n\ne Obstacles in the laws or regulations of a jurisdiction prevent the child Legal Entity from\nproviding or publishing this information.\n\ne The child Legal Entity reports that the consent of the parent was necessary under the\napplicable legal framework and the parent did not consent or could not be contacted.\n\n¢ Binding legal commitments such as the articles governing the child Legal Entity, or a\ncontract prevent the child Legal Entity from providing or publishing this information.\nThis is distinct from laws or regulations of a jurisdiction that prevent the child Legal\nEntity from providing or publishing information on its parent.\n\no The child Legal Entity has sought to consult the parent entity about the reporting of the\nparent information to the Global LEI System but could not confirm the absence of\ndetriment in a way that can appropriately prevent liability risks for the child Legal Entity\n(or those acting on its behalf) under the applicable legal framework. The disclosure of\nthis information would be detrimental to the child Legal Entity or the relevant parent.\n\no The disclosure of this information would be detrimental to the Legal Entity or the\nrelevant parent. This will include reasons generally accepted by public authorities in\nsimilar circumstances, based on a declaration by the entity.\n\no Restrictions:\n¢ In case a Government Entity (EntityCategory RESIDENT_GOVERNMENT_ENTITY) needs to\ndeclare a reporting exception other than NO_LEI, the reason for it SHALL only be\n\nNO_KNOWN_PERSON.\n\nState Transition and Validation Rules for Common Data File formats Page 91 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2413,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.812Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.66 Exception Reference\n_ repex:ExceptionReference\nReferences of the law, regulation or other element of the legal\nframework to support reason(s) provided by the Legal Entity for\ndeclining to provide information on its parents.\n/repex:ReportingExceptionData/repex:ReportingExceptions\n/repex:Exception/repex:ExceptionReference\no ExceptionReference SHALL include the references of the law, regulation or other element of the\nlegal framework supporting the reason provided by the child Legal Entity for declining to provide\ninformation on its parents.\n3.67 Associated Entity — DEPRECATED\n_ lei:AssociatedEntity\nAnother entity associated with this entity if needed to fully identify\nthis entity or to place it in an appropriate context.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity\n/lei:AssociatedEntity\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity\n/lei:AssociatedEntity@type\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity\n/lei:AssociatedEntity/lei:AssociatedLEl\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity\n/lei:AssociatedEntity/lei:AssociatedEntityName\no The AssociatedEntity itself SHALL be used in instances in which the legal identity of a FUND\ncannot be described sufficiently well by its own LegalName alone.\n¢ The AssociatedEntity element SHALL be used to provide the LEl or name of another entity such as\nan umbrella fund, fund manager or other hierarchically relevant entity.\nThis field has been removed from the LEl Common Data Format to avoid redundancy, as the\ninformation will be consistently provided in the fund relationship related fields.\nState Transition and Validation Rules for Common Data File formats Page 92 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1767,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.812Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.68 Entity Expiration Date — DEPRECATED\n_ lei:EntityExpirationDate\nThe date that the Legal Entity ceased to operate, whether due to\ndissolution, merger or acquisition.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Entity/lei:EntityExpirationDate\nThe element EntityExpirationDate is only supplied if the Legal Entity has ceased to exist or no longer\noperates as a separate Legal Entity.\n¢ EntityExpirationDate SHALL contain the date the entity ceased to exist. If the exact date is not\nknown, the date the Managing LOU was made aware that the entity is no longer active SHALL be\nentered.\no If EntityExpirationDate is present, then EntityExpirationReason SHALL be present.\no If EntityExpirationDate is present, then EntityStatus SHALL be INACTIVE.\no If EntityExpirationDate is not present, then EntityExpirationReason SHALL NOT be present.\no EntityExpirationDate SHALL be provided only after the fact, meaning it SHALL NOT be later than\nContentDate in the header or LastUpdateDate of the record.\nThis field has been removed from the LEl Common Data Format to avoid redundancy, as the\ninformation will be consistently provided in the Legal Entity Events related fields.\n3.69 Entity Expiration Reason — DEPRECATED\n_ The reason that a Legal Entity ceased to exist and/or operate.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Entity/lei:EntityExpirationReason\nThe element EntityExpirationReason is only supplied if the Legal Entity has ceased to exist or no\nlonger operates as a separate Legal Entity.\nState Transition and Validation Rules for Common Data File formats Page 93 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1683,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.812Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o EntityExpirationReason SHALL contain the reason why the entity is no longer active.\n\no If EntityExpirationReason is present, then EntityExpirationDate SHALL be present.\n\n« If EntityExpirationReason is present, then EntityStatus SHALL be INACTIVE.\n\no If EntityExpirationReason is not present, then EntityExpirationDate SHALL NOT be present.\n\nThis field has been removed from the LEl Common Data Format to avoid redundancy, as the\n\ninformation will be consistently provided in the Legal Entity Events related fields.\nState Transition and Validation Rules for Common Data File formats Page 94 of 170\n\n@ Public Version 2.7.1 Final\n\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":702,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.813Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4 Use Cases\nThe following Use Cases provide rules and guidelines for LEI registration and renewal, updates to the\nLEI Record Set due to Legal Entity Events, and the handling of registration errors.\n4.1 Issue New LEI that is not branch, fund, sole proprietor,\ngovernment entity or international organization\nWhen a Legal Entity is requesting a new LEI code, the LEl issuer:\no SHALL check that there is not already an LEI code assigned to the entity (avoiding Exclusivity\nViolations)\ne Assign a unique LEI code (avoiding uniqueness violations)\n¢ Validate and publish at least the following:\n¢ LegalName as stated in the Registration Authority or other official source\ne OtherEntityNames and TransliteratedNames, if applicable\no LegalForm and Legallurisdiction\no Complete LegalAddress and HeadquartersAddress\n¢ TransliteratedAddresses and OtherAddresses, if applicable\no EntityCategory SHALL be GENERAL\no EntitySubCategory SHALL NOT be provided\no EntityStatus SHALL be ACTIVE (specific exceptions for NULL and in very rare cases exceptions\nMAY be granted by GLEIF after reporting explicitly the exact Use Case to GLEIF for directly\nissuing LEls for INACTIVE Legal Entities)\no RegistrationAuthority SHALL be included\n¢ ValidationSources SHALL be included\n¢ ValidationAuthority SHALL be included\no InitialRegistrationDate SHALL be the date the record is initially published\no LastUpdateDate SHALL be equal to InitialRegistrationDate\n¢ NextRenewalDate SHALL NOT be more than one year after InitialRegistrationDate\n¢ ManagingLOU SHALL be the LEI of a GLEIF Accredited LEl issuer\nG State Transition and Validation Rules for Common Data File formats Page 95 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1757,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.813Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"¢ Two Relationship Records, one for the direct and one for the ultimate accounting\nconsolidating parent, SHALL be included, following the general rules for Legal Entity\nrelationship information (see 2.1.2) and the applicable Use Case(s) from chapters 4.1.1, 4.1.2,\n4.1.3 and 4.1.4. Different Use Cases can apply for the direct and ultimate parent.\n\no Relationship Records describing a Branch or fund relationship SHALL NOT be included.\n\n4.1.1 Relationship with a parent Legal Entity with an LEI\n\ne When an LEl is initially issued for a Legal Entity and the child Legal Entity has an accounting\nconsolidating direct and/or ultimate parent relationship, a Relationship Record SHALL be\npublished for each relationship.\n\n¢ Only relationships that are ACTIVE by the time of the registration shall be considered.\n\no The RegistrationStatus SHALL be PUBLISHED and the RelationshipStatus SHALL be ACTIVE.\n\no Relationships that ended prior to the initial registration SHALL NOT be included. Relationships\nthat ended after initial registration SHALL be updated as described in the Use Cases for Legal\nEntity Events (see section 4.13).\n\nWhen the child Legal Entity states having (a) parent(s) that is identified with an LEI, the LEl issuer:\n\n« Validates and publishes (a) Relationship Record(s) with at least the following:\n\no StartNode/NodelD SHALL be the same as the newly assigned LEI of the child Legal Entity.\n\no EndNode/NodelD SHALL be the LEI code already assigned to the parent Legal Entity and\npublished in the Global LEI Repository by the time this record is published.\n\no The RelationshipStatus SHALL be ACTIVE.\n\no RelationshipPeriod with PeriodType RELATIONSHIP_PERIOD SHALL be included with\nStartDate and no EndDate.\n\no RelationshipPeriod with PeriodType ACCOUNTING_PERIOD SHALL be included with StartDate\nand EndDate.\n\no RelationshipPeriod with PeriodType DOCUMENT_FILING_PERIOD MAY be included with\nStartDate and no EndDate.\n\n4.1.2 Relationship with a parent Legal Entity without an LEI\n\nIn the case a child Legal Entity reports an accounting consolidating parent relationship with a Legal\n\nEntity that does not have an LEI, the LEl issuer:\n\no SHALL publish a Reporting Exception Record with the appropriate ExceptionCategory and an\nExceptionReason NO_LEI.\n\no SHALL remove the existing relationship exception of type NO_LEI from the upload file, in case a\npublic relationship record to another LEl is introduced.\n\nState Transition and Validation Rules for Common Data File formats Page 96 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2600,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.813Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"e SHALL not be under an obligation to verify that the provided reason is valid but SHALL respond to\nany challenges of this state.\n4.1.3 No accounting consolidation parent relationship\nIf the Legal Entity reports not having (a) parent(s) according to the definition of accounting\nconsolidation, the LEl issuer:\no SHALL publish a Reporting Exception Record with the appropriate ExceptionCategory and an\nExceptionReason NON_CONSOLIDATION, NATURAL_PERSONS or NO_KNOWN_PERSON.\ne SHALL not be under an obligation to verify that the provided reason is valid but SHALL respond to\nany challenges of this state.\nTypically, LEIs that are pointed as ultimate parent entities exhibit these exception reasons.\n4.1.4 Accounting consolidation parent relationship not reported due to legal obstacles\n(opt-out)\nIf the child Legal Entity states any legal obstacles for providing parent relationship information that\nwould otherwise be included with a Relationship Record, the LEl issuer:\no SHALL publish a Reporting Exception Record with the appropriate ExceptionCategory and an\nExceptionReason NON_PUBLIC.\ne SHALL not be under an obligation to verify that the provided reason is valid but SHALL respond to\nany challenges of this state.\n4.2 Issue New LEI - Branch\nWhen a new LEl is requested for an International Branch, the LEl issuer:\ne SHALL ensure that the entity requesting the LEl is an International Branch of the (head office)\nLegal Entity, to which it belongs\no SHALL verify that the (head office) Legal Entity has an LEI with RegistrationStatus ISSUED.\ne SHALL ensure that the Branch is located in a different country as the (head office) Legal Entity.\no SHALL ensure that no other LEI has been issued to a Branch of the (head office) Legal Entity in the\nsame host country.\no SHALL validate that the Branch is registered in the local Registration Authority.\no SHALL validate and publish at least the following:\no LegalName as stated in the Registration Authority.\no LegalAddress SHALL be the address of the Branch in its host country.\no HeadquartersAddress SHALL be the legal address of the (head office) Legal Entity.\nState Transition and Validation Rules for Common Data File formats Page 97 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2293,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.813Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o EntityCategory SHALL be BRANCH.\no EntitySubCategory SHALL NOT be provided.\no LegalForm SHALL be the LegalForm of the (head office) Legal Entity.\no Legallurisdiction SHALL be the Legallurisdiction of the (head office) Legal Entity.\no ValidationSources SHALL NOT be ENTITY_SUPPLIED_ONLY.\no SHALL publish exactly one Relationship Record with:\ne StartNode SHALL be the new LEI of the Branch.\n¢ EndNode SHALL be the LEI of the (head office) Legal Entity.\no RelationshipType SHALL be IS_INTERNATIONAL_BRANCH_OF.\no RelationshipStatus SHALL be ACTIVE.\no RelationshipPeriod with PeriodType RELATIONSHIP_PERIOD SHALL be included with\nStartDate and no EndDate.\no RelationshipPeriods with other PeriodTypes MAY be included.\ne SHALL NOT publish Reporting Exception Records.\nFigure 7 describes the reporting of Branch entities implementing the concept International Branch\nfor a (head office) Legal Entity. This means that there is only one Branch-LEl issued per host country.\nHowever, this LEI represents all locations and/or offices within the jurisdiction. The (head office of\nthe) Legal Entity decides on and provides the correct Reference Data for all its International\nBranches.\nS\nSNTERNATONALBRANCTERNATONALBRANCHOF\n@ /\nLEIC LEIC LEIC LEIB LEIB LEIB\nLocation 1 Location2 Location 3 Location 1 Location2 Location 3\nFigure 7: Example for Branch relationships\nState Transition and Validation Rules for Common Data File formats Page 98 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1537,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.813Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.3 Issue New LEIl - Fund\n\nWhen a new LEI code is requested for a FUND, in addition to or differing from section 4.1 and section\n2.1.2, the LEl issuer:\n\no SHALL validate and publish at least the following:\n\no LegalAddress is the current address provided in the business registry in which the entity was\nformed (which would generally be the case for funds that are incorporated) or (in other\ncases) the address recorded in the primary Registration Authority of the fund.\n\n¢ HeadquartersAddress is the address of the fund manager.\n\no Legallurisdiction SHALL match the LegalForm of the entity, and MAY in some cases be\ndifferent from the jurisdiction of the LegalAddress.\n\no EntityCategory SHALL be FUND.\n\no EntitySubCategory SHALL NOT be provided.\n\no If the fund entity is in scope of the LEI ROC policy on fund relationships, then it SHALL report\nall mandatory fund relationships. See chapter 2.1.2.\n\n¢ The Validation Authority of a fund SHALL always be the financial regulator registering the\nfund where applicable.\n\no If the fund prospectus is not vetted by authorities, ValidationSources SHALL be\nENTITY_SUPPLIED_ONLY.\n\n¢ In cases where the fund entity is self-managed, the fund entity MAY report a relationship of\ntype IS_FUND-MANAGED_BY, in which the end node of the relationship points to the same\nfund entity (see\n\no Figure 8, LEI F). This is an indication that a fund is self-managed, to distinguish from the\nscenario when a fund has not opted out of reporting a relationship.\n\nFigure 8 provides an example of LEl network including fund relationships. For simplicity and clean\nrepresentation, not all required Relationship Records are provided for the second (LEI D, LEI E, LEI G)\nand third level (LEI H, LEI B, LEI C, LEI | LEI J).\nState Transition and Validation Rules for Common Data File formats Page 99 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1924,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.813Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"LEI H (NOT A FUND) LEI B (NOT A FUND) LEI C (NOT A FUND) LEI I (NOT A FUND) LEIJ (NOT A FUND)\nK IS_DIRECTLY_CONSOLIDATED_BY / IS_ULTIMATELY_T(\\:ONSOLIDATED_BY /\\\nIS_FUND-MANAGED_BY y’cONSOLIDATED_BY ycws%lomeo_gy\n? LEI G (NOT A FUND) LEID - FUND (UMBRELLA) LEI E - FUND (MASTER) T\nIS_DIRECTLY_CONSOLIDATED_BY /K IS_SUBFUND_OF / FEEDER_TO IS_ULTIMATELY_CONSOLIDATED_BY\nIS_ULTIMATELY_CONSOLIDATED_BY % | IS_FEEDER_TO ‘ IS_DIRECTLY_CONSOLIDATED_BY\n/__\\ /\n¥\\O/&F”\"”@:fl/®\nLEI A - FUND LEI F - FUND\nFigure 8: Example of network including fund entities and their relationships\nState Transition and Validation Rules for Common Data File formats Page 100 of 170\nGLEIF) Public Version 2.7.1 Final\n2022-04-01_State-Transition-Validation-Rules_v2.6_final.docx 2023-03-07\n","contentLength":759,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:48:39.813Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2021-11-23_lei-cdf-3.1-and-rr-cdf-2.1-and-repex-cdf-2.1-samples-description_v1.2-final.pdf","content":"- __________0000__]\n13 | E| &\nPublic\nLEI-CDF 3.1 and RR-CDF 2.1 and REPEX-CDF 2.1 Samples -\nDescription\nVersion 1.2 Final, 2021-11-23\n(((O)) /.\n// .‘ | A h‘\nl/ @ \\\n\\ ,'\n","contentLength":169,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:49:15.929Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2021-11-23_lei-cdf-3.1-and-rr-cdf-2.1-and-repex-cdf-2.1-samples-description_v1.2-final.pdf","content":"S —\nLEI-CDF 3.1 and RR-CDF 2.1 and REPEX-CDF 2.1 Samples — Description @ LE |\nI\n\nContents\n\nAcknowledgements 4\n\nSamples Overview 5\n\nSample 1: Fund Relationships — Umbrella Structure 6\n\nSample 2: Fund Relationships — Master/Feeder 7\n\nSample 3: Legal Entity Event — Transition of a MERGED LEI 8\n\nSample 4: Legal Entity Event — Transition of a RETIRED LEI 9\n\nSample 5: Legal Entity Event — Event Group 10\n\nSample 6: Legal Entity Event — Withdrawn/Cancelled Event 11\n\nSample 7: Government Entities — Consolidated Central Government Entity 12\n\nSample 8: Government Entities — Non-Consolidated State Government Entity 13\n\nSample 9: Government Entities — Registered Local Government Entity 14\n\nSample 10: International Organization 15\n\nSample 11: New Reporting Exception Reason NON_PUBLIC 16\nPublic\nAuthor GLEIF | Version 1.2 Final | 2021-11-23 Page 2 of 16\n","contentLength":850,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:49:15.930Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2021-11-23_lei-cdf-3.1-and-rr-cdf-2.1-and-repex-cdf-2.1-samples-description_v1.2-final.pdf","content":"o\nLEI-CDF 3.1 and RR-CDF 2.1 and REPEX-CDF 2.1 Samples — Description @ LE|\n-\nSample 6: Legal Entity Event — Withdrawn/Cancelled Event\nThis sample shows a fictional Legal Entity recording a confirmed announcement of a merger that\nwas later on cancelled or withdrawn (see section 4.13.8 in the State Transition and Validation\nRules v2.4 for merger events).\nStep 1: Merger Announcement:\ne LegalEntityEvent is added:\no @group_typeis STANDALONE\no @event_statusis IN_PROGRESS\no LegalEntityEventType is MERGERS_AND_ACQUISITIONS\no LegalEntityEventEffectiveDate is a date in the future (expected date for the\ncompletion of the merger)\no LegalEntityEventRecordedDate is the current timestamp\no AffectedFields include the (expected) name of the SuccessorEntity and the xpath\nto that element\ne RegistrationStatus remains ISSUED\nThe LEI Record would be published for some time in this state, until the cancellation of the\nmerger is announced and confirmed. The LEI Issuer would then update the record by adding a\nsecond LegalEntityEvent at the end of the list of LegalEntityEvents.\nStep 2: Cancellation of the Merger:\ne The IN_PROGRESS event remains unchanged\ne Anew LegalEntityEvent is added:\no @group_typeis STANDALONE\no @event_statusis WITHDRAWN_CANCELLED\no LegalEntityEventType is MERGERS_AND_ACQUISITIONS\no LegalEntityEventEffectiveDate is omitted (the merger no longer has an effective\ndate, after it is cancelled)\no LegalEntityEventRecordedDate is the current timestamp\ne RegistrationStatus remains ISSUED\nAlthough both LegalEntityEvents are basically about the same event (same merger), they do not\nform an event group and hence are not linked by a group_id and do not have a\ngroup_sequence_no. The events are recorded as STANDALONE and the sequence is determined\nby the LegalEntityEventRecordedDates.\nPublic\nAuthor GLEIF | Version 1.2 Final | 2021-11-23 Page 11 of 16\n","contentLength":1864,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:49:15.930Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2021-11-23_lei-cdf-3.1-and-rr-cdf-2.1-and-repex-cdf-2.1-samples-description_v1.2-final.pdf","content":"o\nLEI-CDF 3.1 and RR-CDF 2.1 and REPEX-CDF 2.1 Samples — Description ’@ A LE |\n‘\\J\nSample 7: Government Entities — Consolidated Central\nGovernment Entity\nThe Canadian Air Transport Security Authority (CATSA) is a Crown corporation established on\nApril 1, 2002, and fully funded by parliamentary appropriations!. CATSA is a non-profit\ninstitution controlled by a central government unit. It is consolidated by the Government of\nCanada (https://www.tpsgc-pwgsc.gc.ca/recgen/cpc-pac/2020/pdf/2020-voll-eng.pdf, page 58).\nThe LEI Record would be updated with the following information:\ne EntityCategory is RESIDENT_GOVERNMENT_ENTITY\ne EntitySubCategory is CENTRAL_GOVERNMENT\ne LegalForm is 8888 and OtherLegalForm is Crown Corporation\ne EntityCreationDate is 2002-04-01T00:00:00-04:00\nThe Government of Canada does not have an LEI but would be the consolidating direct and\nultimate parent of CATSA. For the purpose of this sample, it is assumed that there is an LEI\npublished for the Government of Canada within the Global LEI Repository\n(GOVERNMENTOFCANADAS35).\nTwo relationship records would be created for direct and ultimate parent, both with the\nfollowing information:\ne EndNodelD is GOVERNMENTOFCANADA35\ne QualifierCategorie is GOVERNMENT_ACCOUNTING_STANDARD\ne RelationshipPeriod StartDate is 2002-04-01T00:00:00-04:00\ne AccountingPeriod is one year and ends 2020-03-31\n1 https://www.catsa-acsta.gc.ca/en/about-us\nPublic\nAuthor GLEIF | Version 1.2 Final | 2021-11-23 Page 12 of 16\n","contentLength":1483,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:49:15.930Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2021-11-23_lei-cdf-3.1-and-rr-cdf-2.1-and-repex-cdf-2.1-samples-description_v1.2-final.pdf","content":".\nLEI-CDF 3.1 and RR-CDF 2.1 and REPEX-CDF 2.1 Samples — Description @\nDy Lt\nSample 8: Government Entities — Non-Consolidated State\nGovernment Entity\nLand Hessen (State of Hessen) is a state in the Federal Republic of Germany\n(529900AQBND3S6YJLY83) and belongs to the State Government Subsector.\nThe LEI Record would be updated with the following information:\ne EntityCategory is RESIDENT_GOVERNMENT_ENTITY\ne EntitySubCategory is STATE_GOVERNMENT\ne EntityCreationDate? is 1945-09-19T00:00:00+02:00\nLand Hessen is not consolidated by the Central Government of Germany, nor does itself\nconsolidate entities on the Local Government Sector, like the city of Frankfurt am Main\n(529900CAUI4SUKXNF998). All three entities in the different sub-categories hence would declare\nNO_KNOWN_PERSON exception for direct and ultimate parent.\n2 https://english.hessen.de/visitors/hessian-history/reconstruction-period-after-world-war-ii\nPublic\nAuthor GLEIF | Version 1.2 Final | 2021-11-23 Page 13 of 16\n","contentLength":986,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:49:15.930Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2021-11-23_lei-cdf-3.1-and-rr-cdf-2.1-and-repex-cdf-2.1-samples-description_v1.2-final.pdf","content":".\nLEI-CDF 3.1 and RR-CDF 2.1 and REPEX-CDF 2.1 Samples — Description @\nDy Lt\nSample 9: Government Entities — Registered Local\nGovernment Entity\nThe city of Emmen, Netherlands, is a local government entity that is registered in the business\nregister of The Netherlands Chamber of Commerce (RA000463).\nThe LEI Record would be updated with the following information:\ne EntityCategory is RESIDENT_GOVERNMENT_ENTITY\ne EntitySubCategory is LOCAL_GOVERNMENT\nSimilar to the sample from Germany, Gemeente Emmen is not consolidated by the State\nGovernment (Provincie Drenthe, 724500W4L1XMWT67W478) or the Central Government (De\nStaat der Nederlanden, 254900G14ALGVKORFNG62). All three entities in the different sub-\ncategories hence would declare NO_KNOWN_PERSON exception for direct and ultimate parent.\nPublic\nAuthor GLEIF | Version 1.2 Final | 2021-11-23 Page 14 of 16\n","contentLength":862,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:49:15.930Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2021-11-23_lei-cdf-3.1-and-rr-cdf-2.1-and-repex-cdf-2.1-samples-description_v1.2-final.pdf","content":".\nLEI-CDF 3.1 and RR-CDF 2.1 and REPEX-CDF 2.1 Samples — Description @\nDy Lt\nSample 10: International Organization\nThe United Nations (UN) is an intergovernmental organization established after World War Il.\nThe UN currently has 193 member states and 2 observer states.\nThe LEI Record would be updated with the following information:\ne EntityCategory is INTERNATIONAL_ORGANIZATION\ne EntityCreationDate? is 1945-06-26T00:00:00-07:00\ne Legallurisdiction is UN\ne LegalForm is 9999 and OtherLegalForm is Charter of the United Nations\nThe UN is not consolidated by any of the member states or other international organization and\nwould report NO_KNOWN_PERSON exceptions for direct and ultimate parent.\n3 https://www.un.org/en/about-us/un-charter\nPublic\nAuthor GLEIF | Version 1.2 Final | 2021-11-23 Page 15 of 16\n","contentLength":808,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:49:15.930Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2021-11-23_lei-cdf-3.1-and-rr-cdf-2.1-and-repex-cdf-2.1-samples-description_v1.2-final.pdf","content":"e\nLEI-CDF 3.1 and RR-CDF 2.1 and REPEX-CDF 2.1 Samples — Description @ LE]\n\\J\n\nSample 11: New Reporting Exception Reason NON_PUBLIC\n\nThis sample includes a fictional Legal Entity with a minimal entity data and reporting exceptions\n\nwith the new reason NON_PUBLIC introduced in REPEX-CDF 2.1. The new reason consolidates\n\nthe five allowed opt-out reasons CONSENT_NOT_OBTAINED, LEGAL_OBSTACLES,\n\nBINDING_LEGAL COMMITMENTS, DETRIMENT_NOT_EXCLUDED and\n\nDISCLOSURE_DETRIMENTAL.\n\nThe five opt-out reasons remain in REPEX-CDF version 2.1 for backwards compatibility but should\n\nbe replaced by NON_PUBLIC with the implementation of this CDF version.\nPublic\nAuthor GLEIF | Version 1.2 Final | 2021-11-23 Page 16 of 16\n","contentLength":709,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:49:15.930Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2021-11-23_lei-cdf-3.1-and-rr-cdf-2.1-and-repex-cdf-2.1-samples-description_v1.2-final.pdf","content":"[\nLEI-CDF 3.1 and RR-CDF 2.1 and REPEX-CDF 2.1 Samples — Description ’@ 1 C |\nLl\nCreated by GLEIF\nApproved by Head of Data Quality Management and Data Science\nAbout this Document\nThis document is related to the introduction of the upcoming LEI-CDF format version 3.1, RR-\nCDF format version 2.1 and REPEX-CDF format version 2.1. It provides additional information\nfor the samples provided together with this document.\nChange History\nThis section records the history of all changes to this document.\n2021-11-23 Include reference to json and csv file formats GLEIF\n2021-09-30 1.1 Adding Sample 11 for new REPEX-CDF version 2.1. GLEIF\nAdding AffectedField to Legal Entity Event in\nSample 3.\n2021-05-31 Final version published on GLEIF website GLEIF\nAll changes made during creation (for clarity and reading ease as well as significant changes),\nincrease the version number by 0.1 The final version of the document gets version number 1.0.\nGLEIF Contact\nPublic\nAuthor GLEIF | Version 1.2 Final | 2021-11-23 Page 3 of 16\n","contentLength":1016,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:49:15.930Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2021-11-23_lei-cdf-3.1-and-rr-cdf-2.1-and-repex-cdf-2.1-samples-description_v1.2-final.pdf","content":"o\nLEI-CDF 3.1 and RR-CDF 2.1 and REPEX-CDF 2.1 Samples — Description @ o\no\n\nAcknowledgements\n\nThe following description and samples, together with the accompanying XML, JSON and CSV\n\nfiles, are intended to showcase LEI Record Sets compliant with the upcoming CDF versions (LEI-\n\nCDF 3.1, RR-CDF 2.1, and Reporting Exceptions format REPEX-CDF 2.1). The samples cover use\n\ncases related to the addition of Fund Relationships, Legal Entity Events and Government\n\nEntities/International Organizations to the Global LEI System and may not include all changes in\n\nthe updated CDF formats. Some samples are illustrative, others are based on real world\n\nexamples and LEls already registered in the Global LEI Repository.\n\nReal world examples have been validated using publicly available sources at the time of their\n\ncreation and great care has been taken to provide correct and useful examples. Any discrepancy\n\nor ambiguity found is noted in the sample descriptions below. However, it is not excluded that\n\nthe entities and their relationships change over time and LEl Issuers with their local knowledge\n\nand access to additional documents provided by the Legal Entity may come to a different\n\nconclusion when validating the entity and/or relationship data. While every care has been taken\n\nin the compilation of this information, the sample data is meant to be used only for testing\n\npurposes and GLEIF will not be held responsible for any loss, damage, or inconvenience caused\n\nby inaccuracy of the related example data.\n\nAll samples represent Legal Entities already having an LEI prior to the introduction of the new\n\npolicy. Unless noted otherwise, Registration Authority, Validation Authority and Legal Form\n\ncodes were not changed and taken from versions of the RA and ELF code lists that were current\n\nat the time the samples were created (RA list v1.5 and ELF code list v1.3). Future additions to\n\nboth lists may introduce new codes that more appropriately represent the registration authority\n\nand/or legal form for the entities shown in these samples.\nPublic\nAuthor GLEIF | Version 1.2 Final | 2021-11-23 Page 4 of 16\n","contentLength":2122,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:49:15.930Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2021-11-23_lei-cdf-3.1-and-rr-cdf-2.1-and-repex-cdf-2.1-samples-description_v1.2-final.pdf","content":"o\nLEI-CDF 3.1 and RR-CDF 2.1 and REPEX-CDF 2.1 Samples — Description ’@ A LE |\n\\J\nSamples Overview\nSample 1: Fund Relationships — Umbrella Structure\n= 6354000CWIKPSEDOHY65\nSample 2: Fund Relationships — Master/Feeder\n= 6354009BJOFO62XYIX17\nSample 3: Legal Entity Event — Transition of a MERGED LEI\n= 815600828BCFF72F0954\nSample 4: Legal Entity Event — Transition of a RETIRED LEI\n= 969500QK2JTHB072U056\nSample 5: Legal Entity Event — Event Group\n= TESTOOSOQMUA4ZX8UHK57\nSample 6: Legal Entity Event — Withdrawn/Cancelled Event\n= TESTOOLHE1LDN4D7RJ37\nSample 7: Government Entity — Consolidated Central Government Entity\n= 5493007BPZS3LU7J0U61\nSample 8: Government Entity — Non-Consolidated State Government Entity\n= 529900P5TADOABFTMV10\nSample 9: Government Entity — Registered Local Government Entity\n= 7245008LXZZHBNNMOPO6\nSample 10: International Organization\n= 549300HYGYJKXU2J8X74\nSample 11: New Reporting Exception Reason NON_PUBLIC\n= TESTOOAAC7FSN6913Y37\nPublic\nAuthor GLEIF | Version 1.2 Final | 2021-11-23 Page 5 of 16\n","contentLength":1030,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:49:15.930Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2021-11-23_lei-cdf-3.1-and-rr-cdf-2.1-and-repex-cdf-2.1-samples-description_v1.2-final.pdf","content":"o\nLEI-CDF 3.1 and RR-CDF 2.1 and REPEX-CDF 2.1 Samples — Description ‘@ \\ LE |\n\\J\nSample 1: Fund Relationships — Umbrella Structure\nUmbrella Fund\n(Master Fund) / Fund Manager\n63540 '?\":\"__B\" ‘ _’FOGZXY'X 1 635400VZBGQJIUZILIH1I2 635400Z5LRZZSMLTCV16\n\"““’;‘::I’I': FI'L'}:\\”T“' | (Amacore Partners 1 1IcAV) | (Abacore capital Limited)\nFeeder Fund\nIS_SUBFUND_OF )\nIS_FUND-MANAGED_BY\n|\n(AlbaCore Partners | (AlbaCore Partners | (AlbaCore Partners |\nMaster Fund) Sub-Fund A) Sub-Fund B)\nSub-Fund Sub-Fund Sub-Fund\nAlbaCore Partners | Master Fund (6354000CWIKPSEDOHY65) is registered at the Central Bank of\nIreland (CBI), a Registration Authority listed on the RA list (RA000404). Link to the entity:\nhttp://registers.centralbank.ie/FundRegisterDataPage.aspx?fundReferenceNumber=C163293&re\ngister=9.\nThe following information can be validated:\ne Name of the Sub-Fund: AlbaCore Partners | Master Fund\ne Registration Authority and Entity ID\ne Legal Form: ICAV (ELF code 2GV9)\ne Name of the Umbrella: AlbaCore Partners | ICAV\ne Name of the Fund Manager (AIFM): AlbaCore Capital Limited\ne Date of Approval (used for EntityCreationDate and also as StartDate for the\nRelationshipPeriod, but depending on the jurisdiction, that may not be the correct date\nwhen the entity became legally active)\nThe LegalAddress of the fund can be validated from the Instrument of Incorporation (I0l) of the\numbrella filed at Central Bank of Ireland:\nhttp://registers.centralbank.ie/ICAVDocuments/C156258/Instrument%200f%20Incorporation%2\n0on%20Registration.pdf.\nThe sub-fund is not consolidated by an accounting standard, so two exceptions are reported for\ndirect and ultimate parent.\nThe umbrella fund has two additional sub-funds both having an LEI (635400G90A8AFLAKAL93\nand 635400MJITHXFZKJRO41) and also registered at CBI. Hence, the entire umbrella structure\ncan be reported (not part of the provided exemplary files).\nPublic\nAuthor GLEIF | Version 1.2 Final | 2021-11-23 Page 6 of 16\n","contentLength":1962,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:49:15.930Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2021-11-23_lei-cdf-3.1-and-rr-cdf-2.1-and-repex-cdf-2.1-samples-description_v1.2-final.pdf","content":"o\nLEI-CDF 3.1 and RR-CDF 2.1 and REPEX-CDF 2.1 Samples — Description ‘@ A LE |\n\\J\nSample 2: Fund Relationships — Master/Feeder\nIS_FUND-MANAGED _BY\nMaster Fund\n(Umbrella Fund) Fund Manager\nessfius:.mrpo:zx‘flxln IS_FEEDER_TO 635400VZ8GQJUZILIHIZ | e3s400z5LRZZSMLTCV16\n( :e;:;:r I: Ac;”s (AlbaCore Partners | ICAV) (AlbaCore Capital Limited)\nFeeder Fund\n(AlbaCore Partners | (AlbaCore Partners | (AlbaCore Partners |\nMaster Fund) Sub-Fund A) Sub-Fund B)\nSub-Fund Sub-Fund Sub-Fund\nAlbaCore Partners | Feeder ICAV (6354009BJOFO62XYIX17) is registered at the Central Bank of\nIreland (CBI), a Registration Authority listed on the RA list (RA000404). Link to the entity:\nhttp://registers.centralbank.ie/FundRegisterDataPage.aspx?fundReferenceNumber=C158455&re\ngister=50.\nThe following information can be validated:\ne Name of the fund: AlbaCore Partners | Feeder ICAV\ne Registration Authority and Entity ID\ne Legal Form: ICAV (EIf code 2GV9)\ne Name of the Fund Manager (AIFM): AlbaCore Capital Limited\ne Date of Approval (used for EntityCreationDate and also as StartDate for the\nRelationshipPeriod, but depending on the jurisdiction, that may not be the correct date\nwhen the entity became legally active)\nThe LegalAddress of the fund and the Feeder/Master relationship are included in the Instrument\nof Incorporation (I0I) filed at Central Bank of Ireland:\nhttp://registers.centralbank.ie/ICAVDocuments/C158455/Instrument%200f%20Incorporation%2\n0Updated%2016.10.27.pdf.\nThe 101 declares AlbaCore Partners | ICAV (the umbrella in the first sample) as Master ICAV. It\nmay be that the feeder is not investing directly in the umbrella but in one (or more) of its sub-\nfunds in which case the EndNode of the Master/Feeder relationship as well as the\nValidationReference will be different.\nThe feeder fund is not consolidated by an accounting standard, so two exceptions are reported\nfor direct and ultimate parent.\nPublic\nAuthor GLEIF | Version 1.2 Final | 2021-11-23 Page 7 of 16\n","contentLength":1970,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:49:15.930Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2021-11-23_lei-cdf-3.1-and-rr-cdf-2.1-and-repex-cdf-2.1-samples-description_v1.2-final.pdf","content":"o\nLEI-CDF 3.1 and RR-CDF 2.1 and REPEX-CDF 2.1 Samples — Description @ LE|\ng\nSample 3: Legal Entity Event — Transition of a MERGED LEI\nThe sample describes the updates necessary for the transition of LEI Records having\nRegistrationStatus MERGED prior to the introduction of Legal Entity Events into the Global LEI\nSystem. For the sake of simplicity, parent information (Level 2 data) is not provided.\nBefore the update:\ne RegistrationStatus is MERGED\ne EntityStatus is INACTIVE\ne EntityExpirationDate is provided\ne EntityExpirationReason is CORPORATE_ACTION\ne SuccessorEntity is provided\nAfter the update:\ne RegistrationStatus is changed to RETIRED\ne EntityStatus is kept as INACTIVE\ne EntityExpirationDate is removed\ne EntityExpirationReason is removed\ne Legal Entity Event is added:\no @group_typeis STANDALONE\no @event_statusis COMPLETED\no LegalEntityEventType is MERGERS_AND_ACQUISITIONS\no LegalEntityEventEffectiveDate is the former EntityExpirationDate\no LegalEntityEventRecordedDate is the current timestamp\no AffectedFields including the xpath to and value of SuccessorEntity\ne SuccessorEntity is kept unchanged\ne lastUpdateDate is the current timestamp\nFor this transition of already inactive records, it is not expected that the LEI Issuers investigate\nthe exact event or chain of events that led to the merger; MERGERS_AND_ACQUISITIONS can be\nused as event type for all respective records.\nAfter the implementation of the Legal Entity Event policy, a distinction between merger and\nabsorption shall be made.\nPublic\nAuthor GLEIF | Version 1.2 Final | 2021-11-23 Page 8 of 16\n","contentLength":1584,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:49:15.930Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2021-11-23_lei-cdf-3.1-and-rr-cdf-2.1-and-repex-cdf-2.1-samples-description_v1.2-final.pdf","content":"o\nLEI-CDF 3.1 and RR-CDF 2.1 and REPEX-CDF 2.1 Samples — Description @ LE|\ng\nSample 4: Legal Entity Event — Transition of a RETIRED LEI\nThe sample describes the updates necessary for LEl Records having RegistrationStatus RETIRED\nprior to the introduction of Legal Entity Events into the Global LEI System. For the sake of\nsimplicity, parent information (Level 2 data) is not provided.\nBefore the update:\ne RegistrationStatus is RETIRED\ne EntityStatus is INACTIVE\ne EntityExpirationDate is provided\ne EntityExpirationReason is DISSOLVED\nAfter the update:\ne RegistrationStatus is kept as RETIRED\ne EntityStatus is kept as INACTIVE\ne EntityExpirationDate is removed\ne EntityExpirationReason is removed\ne Legal Entity Event is added:\no @group_typeis STANDALONE\no @event_statusis COMPLETED\no LegalEntityEventType is DISSOLUTION\no LegalEntityEventEffectiveDate is the former EntityExpirationDate\no LegalEntityEventRecordedDate is the current timestamp\ne lastUpdateDate is the current timestamp\nFor this transition of already inactive records, it is not expected that the LEI Issuers investigate\nthe exact event or chain of events that led to the retirement; DISSOLUTION can be used as event\ntype for all respective records.\nAfter the implementation of the Legal Entity Event policy, a distinction between liquidation and\ndissolution shall be made, and applicable and confirmed events leading to the closure (e.g.:\nbankruptcy, insolvency) shall be included.\nPublic\nAuthor GLEIF | Version 1.2 Final | 2021-11-23 Page 9 of 16\n","contentLength":1517,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:49:15.930Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2021-11-23_lei-cdf-3.1-and-rr-cdf-2.1-and-repex-cdf-2.1-samples-description_v1.2-final.pdf","content":"o\nLEI-CDF 3.1 and RR-CDF 2.1 and REPEX-CDF 2.1 Samples — Description @ LE|\ng\nSample 5: Legal Entity Event — Event Group\nThis sample shows a fictional Legal Entity recording a change in the legal form that also changes\nthe entity’s legal name (see the second Use Case in section 4.13.5 in the State Transition and\nValidation Rules v2.4).\nBefore the update (not shown in sample):\ne LegalName is “Fictional Company B Ltd.”\ne LegalFormCode is “4XP8” (Company limited by guarantee)\nAfter the update:\ne LegalName changed to “Fictional Company B, LLC”\ne PreviousLegalName added as “Fictional Company B Ltd.”\ne LegalFormCode changed to “MPUG” (Limited liability company)\ne LegalEntityEvent for change of LegalForm is added:\no @group_type is CHANGE_LEGAL_FORM_AND_NAME\no @event_statusis COMPLETED\no LegalEntityEventType is CHANGE_LEGAL_FORM\ne LegalEntityEvent for change of LegalName is added:\no @group_type is CHANGE_LEGAL_FORM_AND_NAME\no @event_statusis COMPLETED\no LegalEntityEventType is CHANGE_LEGAL_NAME\ne Both events have the same @group_id to link them\ne Both events are recorded at the same time, so LegalEntityEventRecordedDate is the\nsame\n¢ Since both events became effective at the same time, LegalEntityEffectiveDate is also the\nsame\ne There is no logical sequence for the events in this group, so @group_sequence_no is not\nincluded\nPublic\nAuthor GLEIF | Version 1.2 Final | 2021-11-23 Page 10 of 16\n","contentLength":1404,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:49:15.930Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2022-02-09_upcoming-cdf-xml-comprehensive-example-description_v1.0-final.pdf","content":"- 00000000\nXM (EGAL\n&y LE| &\nPublic\nUpcoming CDF XML Comprehensive Example — Description\nVersion 1.0 Final, 2022-02-09\n| (’ O ) § V 4 \"\n> ?\nA (@)\nr’ ‘:\\ // .‘ | | “\n( @ \\\n\\ /,\n","contentLength":176,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:49:35.732Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2022-02-09_upcoming-cdf-xml-comprehensive-example-description_v1.0-final.pdf","content":".\nUpcoming CDF XML Comprehensive Example — Description f@‘ I_E |\nN\n\nContents\n\nAcknowledgements 4\n\nFile Reference 5\n\nSample Description 6\nPublic\nAuthor GLEIF | Version 1.0 Final | 2022-02-09 Page 2 of 7\n","contentLength":202,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:49:35.732Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2022-02-09_upcoming-cdf-xml-comprehensive-example-description_v1.0-final.pdf","content":"[\nUpcoming CDF XML Comprehensive Example — Description ‘@ “1'E |\nLl\nCreated by GLEIF\nApproved by Head of Data Quality Management and Data Science\nAbout this Document\nThis document is related to the introduction of the upcoming LEI-CDF format version 3.1, RR-\nCDF format version 2.1, and REPEX-CDF format version 2.1. It provides additional information\nfor the xml samples provided together with this document.\nChange History\nThis section records the history of all changes to this document.\n2022-02-09 Final version published on GLEIF website GLEIF\nAll changes made during creation (for clarity and reading ease as well as significant changes),\nincrease the version number by 0.1 The final version of the document gets version number 1.0.\nGLEIF Contact\nPublic\nAuthor GLEIF | Version 1.0 Final | 2022-02-09 Page 3 of 7\n","contentLength":818,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:49:35.732Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2022-02-09_upcoming-cdf-xml-comprehensive-example-description_v1.0-final.pdf","content":"o\nUpcoming CDF XML Comprehensive Example — Description ‘@ Y ]_E |\n\\J\nAcknowledgements\nThe following description and samples, together with the accompanying XML files, are intended\nto showcase LEI Record Sets compliant with the upcoming CDF versions (LEI-CDF 3.1, RR-CDF 2.1,\nReporting Exceptions (Repex) CDF 2.1). The samples cover use cases related to the addition of\nFund Relationships, Legal Entity Events and Government Entities/International Organizations to\nthe Global LEI System and may not include all changes in the updated CDF formats. All samples\nare illustrative and do not represent any ‘real’ data. The set of LEI Records in the three files is\ncomplete in the sense that every LEl included as part of a relationship record, as a successor\nentity or as an LEl Issuer is present with an LEI Record.\nWhile every care has been taken in the compilation of this information, the sample data is meant\nto be used only for testing purposes and GLEIF will not be held responsible for any loss, damage,\nor inconvenience caused by inaccuracy of the related example data.\nPublic\nAuthor GLEIF | Version 1.0 Final | 2022-02-09 Page 4 of 7\n","contentLength":1138,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:49:35.732Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2022-02-09_upcoming-cdf-xml-comprehensive-example-description_v1.0-final.pdf","content":"e\nUpcoming CDF XML Comprehensive Example — Description f@‘ I_E |\n\\J\nFile Reference\nLEI-CDF 3.1: Level 1 Data (18 Records)\n= 2022-02-09_upcoming-cdf-xml-concatenated-comprehensive-example-lei.xml\nRR-CDF 2.1: Relationship Data (5 Records)\n= 2022-02-09_upcoming-cdf-xml-concatenated-comprehensive-example-rr.xml\nREPEX-CDF 2.1: Reporting Exceptions Data (34 Records)\n= 2022-02-09_upcoming-cdf-xml-concatenated-comprehensive-example-repex.xml\nPublic\nAuthor GLEIF | Version 1.0 Final | 2022-02-09 Page 5 of 7\n","contentLength":503,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:49:35.732Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2022-02-09_upcoming-cdf-xml-comprehensive-example-description_v1.0-final.pdf","content":"o\nUpcoming CDF XML Comprehensive Example — Description @ C |\nLl\nSample Description\nThe samples provided in these files showcase a state during the transition period in March 2022,\nwhen some LEI Issuers have already made the transition and provide their data in the ‘new’ CDF\nformats while others still provide data in the ‘old’ formats (including deprecated elements).\nThe sample set includes two LEI Issuers (ManagingLOUs):\ne TESTOOOMTOGX9Z6IN826 — Already using the new CDF formats\ne TESTOOHRVYC4JFTR1624 — Still using the old CDF formats\nThe LEI records for the successor entities are included in this set of samples to provide a\ncomplete set of related LEI records. These records are kept to the minimum required\ninformation, to keep complexity low.\nThe following use cases are included in the samples:\nTESTOOOTASYDG4PVGX76 — CDF 3.1 Full Sample\ne Following the new CDF formats\ne Most of the elements are populated, including several Successor Entities and Legal Entity\nEvents, OtherNames and OtherAddresses, additional ValidationAuthorities\nTESTOOCFPLINM9ZT5A04 — CDF 3.1 Sample with Multiple Successor Entities\ne Following the new CDF formats\ne Another sample with multiple Successor Entities created by different Legal Entity Events\ne Affected Fields indicate which Successor Entity is linked to which event\ne In the old CDF formats, this LEI Record would have RegistrationStatus MERGED and\nwould include an EntityExpirationDate and EntityExpirationReason as\nCORPORATE_ACTION\ne With the new formats, RegistrationStatus is RETIRED, EntityExpirationReason is included\nas Legal Entity Event Type MERGERS_AND_ACQUISITIONS, and EntityExpirationDate is\nthe EffectiveDate of that Legal Entity Event\nTEST000308Z10Q2ILT13 — Duplicate Record of LEI TESTOOCFPLINM9ZT5A04\ne Following the new CDF formats\ne This LEI Record represents a duplicate (Exclusivity Violation) of another LEI\ne The Successor Entity pointing to the surviving LElI Record is the one not included in the\nLegal Entity Event Affected Fields\nTESTOOMWUV12VP51SD83 — CDF 3.1 Sample with Extensions\ne Following the new CDF formats\ne This LElI Record includes Extensions with Geocode information added by GLEIF and\nadditional data provided by LEI Issuers\ne This LEI Record also represents an International Organization, using the new reserved\nRegistration Authority Code ‘RA777777’ as ValidationAuthorityID and ‘XX’ as\nLegallurisdiction (i.e., not governed by national laws and not part of the EU or UN)\nPublic\nAuthor GLEIF | Version 1.0 Final | 2022-02-09 Page 6 of 7\n","contentLength":2529,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:49:35.732Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2022-02-09_upcoming-cdf-xml-comprehensive-example-description_v1.0-final.pdf","content":"o\nUpcoming CDF XML Comprehensive Example — Description @ C |\noy LL\nTESTOOFX1EZXQRJDLZ25 — Sub-Fund Name Two (CDF 3.1)\n\ne Following the new CDF formats\n\ne Fund manager is TESTOOCMZ8YXZLN58Z28 (included as relationship)\n\ne Umbrella fund is TESTOOPTM582Z8F25919 (included as relationship)\n\nTESTOOKMUS5Y1N9KOLOQ9 — Umbrella Fund Name - Sub-Fund Name One (CDF 2.1)\n\ne Following the old CDF formats\n\ne Fund manager is TESTOOCMZ8YXZLN58Z728 (included as AssociatedEntity)\n\ne This represents a second sub-fund (beside TESTOOFX1EZXQRJDLZ25) of the same\numbrella fund (TESTOOPTM582Z8F25919); this is only shown in the concatenated name\nof the umbrella and name of the sub-fund\n\nTESTOOPYMIZZ9B751024 — Merged Entity Name (CDF 2.1)\n\ne Following the old CDF formats\n\ne RegistrationStatus, EntityExpirationDate, and EntityExpirationReason of this LEl Record\nwill be replaced once the LEI Issuer of this record makes the transition\n\ne TESTOOCFPLINM9ZT5A04 is the sample that shows a similar case after the transition\n\nThere are additional LEI Records included that are used in the above samples to complete the set\nof LEl Records in this repository:\nSuccessor Entities created by TESTOOOTASYDG4PVGX76:\n\ne TESTOOTMKOT49CEL2767\n\ne TESTOOR8J70TMF1AQX48\n\ne TESTOO33WLIZ5R2IE259\n\nDirect and Ultimate parent of TESTOOOTASYDG4PVGX76:\n\ne TESTOOMQAW5HO72MA343\n\nSuccessor Entities created by TESTOOCFPLINM9ZT5A04:\n\ne TESTOONLEUNOT4RLHGY91\n\ne TESTOOTRLGPML170NA17\n\ne TESTOODKTUNCASA7N881\n\nFund manager for all fund entities:\ne TESTOOCMZ8YXZLN58Z728\nUmbrella fund for the two sub-funds:\ne TESTOOPTM582Z8F25919\nPublic\nAuthor GLEIF | Version 1.0 Final | 2022-02-09 Page 7 of 7\n","contentLength":1648,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:49:35.732Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2021-09-30_xslt-documentation_v1.1-final.pdf","content":"- /]\n| E| .\nPublic\nXSLT for LEI-CDF 3.1 -> 2.1, RR-CDF 2.1 -> 1.1, Reporting\nExceptions Format 2.1 -> 1.1 Documentation\nVersion 1.1 Final, 2021-09-30\n| < ~ ( \"\n\\ \\ y / 4\nN — g\n©)\nNS §‘/\n","contentLength":186,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:49:51.568Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2021-09-30_xslt-documentation_v1.1-final.pdf","content":"e\nXSLT for LEI-CDF 3.1 -> 2.1, RR-CDF 2.1 -> 1.1, Reporting Exceptions Format 2.1 -> 1.1 ‘@ ) I_E |\nDocumentation ' 4\nContents\n\nAcknowledgements 4\n\nXSL Transformation: LEI-CDF 3.1 -> 2.1 5\n\nXSL Transformation: RR-CDF 2.1 ->1.1 6\n\nXSL Transformation: Reporting Exceptions Format 2.1 -> 1.1 7\nPublic\nAuthor GLEIF | Version 1.1 Final |2021-09-30 Page 2 of 7\n","contentLength":355,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:49:51.569Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2021-09-30_xslt-documentation_v1.1-final.pdf","content":"o\nXSLT for LEI-CDF 3.1 -> 2.1, RR-CDF 2.1 -> 1.1, Reporting Exceptions Format 2.1 -> 1.1 ‘@ ) L[I\nDocumentation '\nCreated by GLEIF\nApproved by GLEIF Head of IT Development & Operations\nAbout this Document\nThis document is related to the introduction of the upcoming LEI-CDF format version 3.1 and\nRR-CDF format version 2.1. It provides documentation of the XSLT files which can be used to\ntechnically transform XML files from the new versions to the previous versions.\nChange History\nThis section records the history of all changes to this document.\n2021-09-30 1.1 Added information about Reporting Exceptions GLEIF\nFormat transformation\n2021-05-31 Final version published on GLEIF website GLEIF\nAll changes made during creation (for clarity and reading ease as well as significant changes),\nincrease the version number by 0.1 The final version of the document gets version number 1.0.\nGLEIF Contact\nBusiness Operations GLEIF Service Desk\nPublic\nAuthor GLEIF | Version 1.1 Final |2021-09-30 Page 3 of 7\n","contentLength":1003,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:49:51.569Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2021-09-30_xslt-documentation_v1.1-final.pdf","content":"o\nXSLT for LEI-CDF 3.1 -> 2.1, RR-CDF 2.1 -> 1.1, Reporting Exceptions Format 2.1 -> 1.1 ‘@ ) LEl\nDocumentation \\J\nAcknowledgements\n\nThe XSLT files described in this document are intended to help LEI data consumers, who did not\n\nhave the opportunity to update their data consumption procedures to the new formats before\n\nMarch 1%, 2022, to transform XML files (LEI-CDF 3.1, RR-CDF 2.1 and Reporting Exceptions\n\nFormat 2.1) into the respective previous version of the XML schemas (LEI-CDF 2.1, RR-CDF 1.1\n\nand Reporting Exceptions Format 1.1). The transformation of the content is on technical basis\n\nand fully automated. Therefore, certain transformations are not possible to be performed, i.e.,\n\ninformation which cannot be represented in the previous formats gets lost during the\n\ntransformation.\n\nWhile every care has been taken in the preparation of the XSLT files, they are meant to be used\n\nat the own risk of the user and GLEIF will not be held responsible for any loss, damage, or\n\ninconvenience caused by inaccuracy of the related result file from any transformation performed\n\nwith the provided XSLT files.\nPublic\nAuthor GLEIF | Version 1.1 Final |2021-09-30 Page 4 of 7\n","contentLength":1181,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:49:51.569Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2021-09-30_xslt-documentation_v1.1-final.pdf","content":"o\nXSLT for LEI-CDF 3.1 -> 2.1, RR-CDF 2.1 -> 1.1, Reporting Exceptions Format 2.1 -> 1.1 ‘@ ) LEl\nDocumentation \\J\nXSL Transformation: LEI-CDF 3.1 -> 2.1\n\nThe XSLT file for LEI-CDF transforms LEI-CDF source files version 3.1 into LEI-CDF result files\n\nversion 2.1. Most fields remain unchanged or have only a slightly different representation in the\n\ntwo versions of the format.\n\nHowever, there are some elements in the newer version 3.1 which cannot be represented in\n\nversion 2.1. These exceptions are listed below:\n\ne The following new V3.1 enumerated values for the element “lei:EntityCategory’ have no\nequivalent in V2.1 and elements with these values must therefore be ignored (will be\nremoved during transformation):\n\no GENERAL\no RESIDENT_GOVERNMENT_ENTITY\no INTERNATIONAL_ORGANIZATION\n\ne The following new V3.1 elements have no equivalent in V2.1 and therefore cannot be\n\nmapped to any defined LEI-CDF V2.1 element (will be removed during transformation):\no EntitySubCategory\no EntityCreationDate\no LegalEntityEvents\n\ne The new V3.1 enumerated value 'NULL' for element ‘lei:EntityStatus™ has no equivalent\nin V2.1 and thus is mapped to the value 'INACTIVE'.\n\ne The cardinality of element “SuccessorEntity” was {0,1} in V2.1 and is now {0,unbounded}\nin V3.1. Therefore, any additional element \"SuccessorEntity\" other than the first\nappearance is removed during transformation.\n\ne Unnecessary and potentially problematic attributes starting with 'xsi:', like\nxsi:type=\"AddressType\" or xsi:type=\"NameType\", will be removed during\ntransformation.\n\nPublic\nAuthor GLEIF | Version 1.1 Final |2021-09-30 Page 5 of 7\n","contentLength":1616,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:49:51.569Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2021-09-30_xslt-documentation_v1.1-final.pdf","content":"o\nXSLT for LEI-CDF 3.1 -> 2.1, RR-CDF 2.1 -> 1.1, Reporting Exceptions Format 2.1 -> 1.1 ‘@ ) LEl\nDocumentation \\J\nXSL Transformation: RR-CDF 2.1 -> 1.1\n\nThe XSLT file for RR-CDF transforms RR-CDF source files version 2.1 into RR-CDF result files\n\nversion 1.1. Most fields remain unchanged or have only a slightly different representation in the\n\ntwo versions of the format.\n\nHowever, there are some elements in the newer version 2.1 which cannot be represented in\n\nversion 1.1. These exceptions are listed below:\n\ne The following new V2.1 enumerated values for element “rr:RelationshipType™ have no\nequivalent in V1.1 and ancestor elements ‘rr:RelationshipRecord” with these values are\ntherefore removed during transition:\n\no IS_FUND-MANAGED_BY\no IS_SUBFUND_OF\no IS_FEEDER_TO\n\ne The new V2.1 enumerated value 'NULL' for element “rr:RelationshipStatus™ has no\nequivalent in V1.1 and is mapped to the value 'INACTIVE' during transformation.\n\ne The new V2.1 enumerated value 'GOVERNMENT_ACCOUNTING_STANDARD' for\nelement ‘rr:QualifierCategory has no equivalent in V1.1, thus the (optional) element is\nremoved during transformation.\n\nPublic\nAuthor GLEIF | Version 1.1 Final |2021-09-30 Page 6 of 7\n","contentLength":1194,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:49:51.569Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2021-09-30_xslt-documentation_v1.1-final.pdf","content":"e\nXSLT for LEI-CDF 3.1 -> 2.1, RR-CDF 2.1 -> 1.1, Reporting Exceptions Format 2.1 -> 1.1 ‘@ ) LEl\nDocumentation ' 4\nXSL Transformation: Reporting Exceptions Format 2.1 -> 1.1\nThe XSLT file for Reporting Exceptions Format transforms Reporting Exceptions Format source\nfiles version 2.1 into Reporting Exceptions Format result files version 1.1. Most fields remain\nunchanged or have only a slightly different representation in the two versions of the format.\nHowever, there is one value in the newer version 2.1 which cannot be precisely represented in\nversion 1.1. This exception is listed below:\ne The new V2.1 enumerated value 'NON_PUBLIC' for element ‘repex:ExceptionReason’\nhas no precise equivalent in V1.1 and is mapped to the value\n'CONSENT_NOT_OBTAINED' during transformation.\nPublic\nAuthor GLEIF | Version 1.1 Final |2021-09-30 Page 7 of 7\n","contentLength":848,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:49:51.569Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2021-09-30_guiding_document_for_the_transition_period_v1.1-final.pdf","content":"Guiding Document for the Transition Period\nOverview of transition timeline and action items\nTransition Overview\n","contentLength":112,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:50:22.273Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2021-09-30_guiding_document_for_the_transition_period_v1.1-final.pdf","content":"Phase 1 (before March 2022)\nFrom May to December 2021, GLEIF will publish updates to all code lists to accommodate the ROC policy\nimplementations. This includes the Registration Authorities List, Entity Legal Form Code List, and the GLEIF Accepted\nJurisdictions Code list.\nPhase 2 Transition period (March 1, 2022 to March 31, 2022)\nNewly added/updated fields and values\nDuring Phase 2, users will need to create new scripts for processing LEI and LEI reference data if these data elements are\nused for monitoring or reporting. Importantly, LEI Issuers will deliver to GLEIF LEI reference data in either LEI-CDF 2.1,\nRR-CDF 1.1, Reporting Exceptions format 1.1 or LEI-CDF 3.1, RR-CDF 2.1 and corresponding Reporting Exceptions\nformat 2.1. Users of the Global LEI Repository will only receive information in LEI-CDF 3.1, RR-CDF 2.1 and Reporting\nExceptions format 2.1 formats. Therefore, it is important that users convert fully to the new XML format as of March 1,\n2022.\nThe remainder of this section describes how users will need to adjust their consumption of the Global LEI Repository to\naccommodate this Phase 2.\nData Field\nds/lei:LEIRecord RESIDENT GOVERNM | INTERNATIONAL ORGANIZATION and GENERAL in\n/lei:Entity/lei:EntityCatego | ENT _ENTITY, Entity Category field.\nry INTERNATIONAL ORG\nANIZATION and Two aspects need to be considered:\nGENERAL would affect\nusers who have not 1. Government entities and international organizations\nadopted the new CDF are currently not identified. During Phase 2, some\nformat. entities may be categorized with the new values, but\nthere is no guarantee for all of them.\n","contentLength":1609,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:50:22.273Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2021-09-30_guiding_document_for_the_transition_period_v1.1-final.pdf","content":"/lei:LEIData/lei:\nLEIRecords/\nlei:LEIRecor\nd\n/lei:Entity/le\ni:SuccessorE\nntity/lei:Suc\ncessorLEI\n/lei:LEIData/le\ni:LEIRecords/]\nei:LEIRecord\n/lei:Entity/lei:S\nuccessorEntity/\nlei:SuccessorE\nntityName\nRelationship Type /rr:Relationshi | The newly added fund Allow IS FUND-MANAGED BY, IS SUBFUND_OF and\npData/rr:Relati | relationship types could affect | IS FEEDER TO in Relationship Type field.\nonshipRecords | users who only track direct\n/rr:Relationshi | and ultimate parent\npRecord information, international\n/rr:Relationshi | branch information or derive\np/rr:Relationsh | relationship statistics from the\nipType RR file. The deprecated field\nAssociated Entity could affect\nusers who previously track\nfund relationships with this\nfield.\nRelationship /rr:Relationshi | The new value Allow GOVERNMENT ACCOUNTING STANDARD in\nQualifier Category pData/rr:Relati | GOVERNMENT ACCOUN | Relationship Qualifier Category field.\nonshipRecords | TING_STANDARD could\n/rr:Relationshi | affect some users.\npRecord\n/rr:Relationshi\n","contentLength":1018,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:50:22.273Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2021-09-30_guiding_document_for_the_transition_period_v1.1-final.pdf","content":"-] N R\nipQualifiers\nException Reason /repex:Reporti | Five exception reasons, Allow NON_PUBLIC in Exception Reason field.\nngExceptionD | “BINDING LEGAL COM\nata/repex:Repo | MITMENTS”, “LEGAL_ OB\nrtingException | STACLES”,\nS “DISCLOSURE DETRIME\n/repex:Excepti | NTAL”,\non/repex:Exce | “DETRIMENT NOT EXCL\nptionReason UDED” and\n“CONSENT _NOT_OBTAIN\nED”, are consolidated into\none exception reason\n“NON_PUBLIC”.\nThe new value\n“NON_PUBLIC” would\naffect users who have not\nadopted the new CDF format.\nTransition Complete (April 1, 2023)\nFrom this date onward, all existing LEIs having a last renewal date greater than 1 April 2022 and all LEIs issued after this\ndate will have complete government entity, fund relationships, and legal entity events data collected (as applicable)'.\n! GLEIF is expecting to receive more information from the ROC regarding the required data collection for medium and low priority legal entity\nevents.\n","contentLength":927,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:50:22.273Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2021-09-30_guiding_document_for_the_transition_period_v1.1-final.pdf","content":"Appendix : Deprecated fields?\nAssociated Entity /let:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity | The information will be consistently provided in the fund\n/lei: AssociatedEntity relationship related fields.\n/lei:LEIData/lei:LEIRecords/lei: LEIRecord/lei: Entity\n/lei: Associated Entity@type\n/lei:LEIData/lei:LEIRecords/lei: LEIRecord/lei: Entity\n/lei: AssociatedEntity/lei: Associated LEI\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity\n/lei: AssociatedEntity/lei: AssociatedEntityName\n/lei:Entity/lei:EntityExpirationDate Entity Events related fields.\n/lei:Entity/lei:EntityExpirationReason Entity Events related fields.\n2 The deprecated fields will be blank only after the completion of Phase 3. During the transition, they are still available in the data. Data quality\nchecks will be enforced to avoid discrepancies.\n","contentLength":831,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:50:22.273Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2021-09-30_guiding_document_for_the_transition_period_v1.1-final.pdf","content":"Data Field\n2. During Phase 2, LEIs with empty entity category field\nand the ones exhibiting the value GENERAL shall be\ntreated equally.\nEntity Status /lei:LEIData/lei:LEIRecor | The new status NULL Allow NULL in Entity Status field\nds/lei:LEIRecord could affect some users as\n/lei:Entity/lei:EntityStatus | the NULL value will be During Phase 2, ANNULLED and DUPLICATE LEIs will\napplied to LEIs with a start exhibiting Entity Status NULL. The process lasts until all\nstatus of ANNULLED or | ANNULLED and DUPLICATE records have transferred their\nDUPLICATE, or for LEIs | Entity Status (from ACTIVE/INACTIVE to NULL).\nissued for a FUND entity\nin a jurisdiction (e.g.,\nSpain), where the\nexistence of an LEI is a\nprerequisite to be able to\nregister the fund entity\nitself.\nLegal Entity /lei:LEIData/lei:LEIRecor | The newly added field Add Legal Entity Events Type field in database structure.\nEvents Type ds/lei:LEIRecord/lei:Entity | would affect users who are | Value could be CHANGE LEGAL NAME,\n/ tracking legal entity status | CHANGE OTHER NAMES,\nlei:LegalEntityEvents/lei:L | and entity expiration CHANGE LEGAL ADDRESS, CHANGE HQ ADDRESS,\negalEntityEvent/ date/reason change and CHANGE LEGAL FORM, ACQUISITION BRANCH,\nlei:LegalEntityEventType | successor entities. TRANSFORMATION BRANCH TO SUBSIDIARY,\nTRANSFORMATION SUBSIDIARY TO BRANCH,\nTRANSFORMATION UMBRELLA TO STANDALONE,\nDISSOLUTION, BREAKUP,\nMERGERS AND ACQUISITIONS, DEMERGER,\nSPINOFF, BANKRUPTCY,\nVOLUNTARY_ ARRANGEMENT, INSOLVENCY,\nABSORPTION or REVERSE TAKEOVER.\n","contentLength":1527,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:50:22.273Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2021-09-30_guiding_document_for_the_transition_period_v1.1-final.pdf","content":"Data Field\nPlease note that the legal entity events are grouped into three\npriority groups, and only events that are regarded as high\npriority by the Regulatory Oversight Committee (ROC) and\ndata collection is expected to begin for the high priority events\nby March 31, 2022.\nThe following events are considered as high priority events:\nCHANGE LEGAL NAME, CHANGE OTHER NAMES,\nCHANGE LEGAL ADDRESS, CHANGE HQ ADDRESS,\nCHANGE LEGAL FORM, ACQUISITION BRANCH,\nTRANSFORMATION BRANCH TO SUBSIDIARY,\nTRANSFORMATION SUBSIDIARY TO BRANCH,\nTRANSFORMATION UMBRELLA TO STANDALONE,\nDISSOLUTION.\nMedium priority legal entity events include: BREAKUP,\nMERGERS AND ACQUISITIONS, DEMERGER,\nSPINOFF.\nLow priority legal entity events include: BANKRUPTCY,\nVOLUNTARY_ ARRANGEMENT, INSOLVENCY,\nABSORPTION, REVERSE TAKEOVER.\nLOUs can begin data collection for medium priority and low\npriority events before required by the ROC.\n","contentLength":904,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:50:22.273Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2021-09-30_guiding_document_for_the_transition_period_v1.1-final.pdf","content":"Data Field\nDuring Phase 2, users should consider entities that ceased to\noperate in Legal Entity Event Container as well as Entity\nExpiration Date and Entity Expiration Reason fields.\nRegistration Status | /lei:LEIData/lei:LEIRecor | The deprecation of the Remove MERGED from the Registration Status field. Please\nds/lei:LEIRecord “MERGED” status could | note the use of the Merger event in the deprecation of the\n/lei:Registration/lei:Registr | affect some users who Registration Status MERGED and the usage of the\nationStatus track legal entity event DISSOLUTION event in the deprecation of Entity Expiration\nwith this value which Date and Entity Expiration Reason.\ngoing forward will be\nrepresented by the During Phase 2, users should consider LEIs with MERGED\nRETIRED status. status to be equivalent to LEIs with Legal Entity Events Type\nbeing MERGERS AND ACQUISITIONS and Registration\nStatus being RETIRED.\nRelationship Type | /rr:RelationshipData/rr:Rel | The newly added fund Allow IS FUND-MANAGED BY, IS SUBFUND_OF and\nationshipRecords/rr:Relati | relationship types could IS FEEDER TO in Relationship Type field.\nonshipRecord affect users who only track\n/rr:Relationship/rr:Relation | direct and ultimate parent | During Phase 2, LEIs with Relationship Type IS FUND-\nshipType information, international | MANAGED BY should be treated equally as LEIs with\nbranch information or Associated Entity Type being FUND FAMILY.\nderive relationship\nstatistics from the RR file.\nThe deprecated field\nAssociated Entity could\naffect users who\npreviously track fund\nrelationships with this\nfield.\nationshipRecords/rr:Relati | could affect some users as\n","contentLength":1648,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:50:22.274Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2021-09-30_guiding_document_for_the_transition_period_v1.1-final.pdf","content":"Data Field\nonshipRecord the NULL value will be During Phase 2, LEIs with Entity Status NULL should be\n/rr:Relationship/rr:Relation | applied to LEIs with a treated equally as LEIs with Registration Status ANNULLED\nshipStatus status of ANNULLED or | or DUPLICATE in RR.\nDUPLICATE, or for LEIs\nissued for a FUND entity\nin a jurisdiction (e.g.,\nSpain), where the\nexistence of an LEI is a\nprerequisite to be able to\nregister the fund entity\nitself.\nException Reason | /repex:ReportingException | Five exception reasons, Allow NON_PUBLIC in Exception Reason field.\nData/repex:ReportingExce | “BINDING LEGAL CO\nptions MMITMENTS”, “LEGAL\n/repex:Exception/repex:Ex | OBSTACLES”, Exception reasons\nceptionReason “DISCLOSURE DETRI | “BINDING LEGAL COMMITMENTS”, “LEGAL OBSTA\nMENTAL”, CLES”, “DISCLOSURE_DETRIMENTAL”,\n“DETRIMENT NOT EX | “DETRIMENT NOT EXCLUDED” and\nCLUDED” and “CONSENT_NOT_OBTAINED” will be deprecated by 1*\n“CONSENT NOT OBTA | April 2022.\nINED”, are consolidated\ninto one exception reason\n“NON_PUBLIC”.\nThe new value\n“NON_PUBLIC” would\naffect users who have not\nadopted the new CDF\nformat.\n","contentLength":1099,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:50:22.274Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2021-09-30_guiding_document_for_the_transition_period_v1.1-final.pdf","content":"Phase 3 (March 1, 2022 to March 31, 2023)\n\nReconciliation for existing data means that data will only become available at time of new LEI issuance or renewal of\nexisting LEIs. Since the renewal cycle in the Global LEI System is one year, users cannot be sure that queries of the active\nand verified LEI population yield full information until end of March 2023.\n\nField\n\nEntity Category /let:LEIData/le | The new values Allow RESIDENT GOVERNMENT ENTITY,\ni:.LEIRecords/l | RESIDENT GOVERNMEN | INTERNATIONAL ORGANIZATION and GENERAL in Entity\nei:LEIRecord | T ENTITY, Category field.\n\n/lei:Entity/lei:E | INTERNATIONAL ORGA\n\nntityCategory | NIZATION and GENERAL\nwould affect users who have\nnot adopted the new CDF\nformat.\n\nEntity Sub Category | /lei:.LEIData/le | The newly added field would | Add Entity Sub Category field in database structure. It applies to\ni:.LEIRecords/l | affect users who do not EntityCategory being RESIDENT GOVERNMENT ENTITY, and\nei:LEIRecord | migrate to the new CDFs who | values could be STATE. GOVERNMENT,\n\n/lei:Entity/lei:E | are taking in LEI data for LOCAL_ GOVERNMENT, or SOCIAL SECURITY.\nntitySubCateg | Government Entities.\nory\n\nEntity Creation Date | /lei:LEIData/le | This newly added field could | Add Entity Creation Date field in database structure.\ni:.LEIRecords/l | affect users as this date will\nei:LEIRecord/l | be included for each new LEI\nei:Entity/ assigned as of the\nlei:EntityCreati | implementation of the new\nonDate CDFs.\n","contentLength":1472,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:50:22.274Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2021-09-30_guiding_document_for_the_transition_period_v1.1-final.pdf","content":"Legal Entity Events | /lei:LEIData/le | The newly added field would | Add Legal Entity Events Type field in database structure. Value could\nType i:.LEIRecords/l | affect users who are tracking | be CHANGE LEGAL NAME, CHANGE OTHER NAMES,\nei.LEIRecord/l | legal entity status and entity | CHANGE LEGAL ADDRESS, CHANGE HQ ADDRESS,\nei:Entity/ expiration date/reason change | CHANGE LEGAL FORM, ACQUISITION BRANCH,\nlei:LegalEntity | and successor entities. TRANSFORMATION BRANCH _TO_SUBSIDIARY,\nEvents/lei:Leg TRANSFORMATION SUBSIDIARY TO BRANCH,\nalEntityEvent/ TRANSFORMATION UMBRELLA TO STANDALONE,\nlei:Legal Entity DISSOLUTION, BREAKUP, MERGERS AND ACQUISITIONS,\nEventType DEMERGER, SPINOFF, BANKRUPTCY,\nVOLUNTARY_ ARRANGEMENT, INSOLVENCY, ABSORPTION\nor REVERSE TAKEOVER.\nPlease note that the legal entity events are grouped into three priority\ngroups, and only events that are regarded as high priority by the\nRegulatory Oversight Committee (ROC) and data collection is\nexpected to begin for the high priority events by March 31, 2022.\nThe following events are considered as high priority events:\nCHANGE LEGAL NAME, CHANGE OTHER NAMES,\nCHANGE LEGAL ADDRESS, CHANGE HQ ADDRESS,\nCHANGE LEGAL FORM, ACQUISITION BRANCH,\nTRANSFORMATION BRANCH TO SUBSIDIARY,\nTRANSFORMATION SUBSIDIARY TO BRANCH,\nTRANSFORMATION UMBRELLA TO STANDALONE,\nDISSOLUTION.\nMedium priority legal entity events include: BREAKUP,\nMERGERS AND ACQUISITIONS, DEMERGER, SPINOFF.\n","contentLength":1440,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:50:22.274Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2021-09-30_guiding_document_for_the_transition_period_v1.1-final.pdf","content":"Low priority legal entity events include: BANKRUPTCY,\nVOLUNTARY_ ARRANGEMENT, INSOLVENCY, ABSORPTION,\nREVERSE TAKEOVER.\nLOUs can begin data collection for medium priority and low priority\nevents before required by the ROC.\nLegal Entity Event | /lei:LEIData/le | See above. Add Legal Entity Event Effective Date field in database structure.\nEffective Date i:LEIRecords/]\nei:LEIRecord/l\nei:Entity/\nlei:Legal Entity\nEvents/lei:Leg\nalEntityEvent/]\nei:/\nlei:Legal Entity\nEventEffective\nDate\nLegal Entity Event | /lei:LEIData/le | See above. Add Legal Entity Event Recorded Date field in database structure.\nRecorded Date i:LEIRecords/]\nei:LEIRecord/l\nei:Entity/\nlei:Legal Entity\nEvents/lei:Leg\nalEntityEvent/\nlei:Legal Entity\nEventRecorded\nDate\nValidation /lei:LEIData/le | Newly added values to this Add Validation Documents field in database structure.\nDocuments i:.LEIRecords/l | field could affect some users. | Value could be ACCOUNTS FILING, REGULATORY FILING,\nei:LEIRecord/l SUPPORTING DOCUMENTS, CONTRACTS or OTHERS.\nei:Entity/\n","contentLength":1031,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:50:22.274Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2021-09-30_guiding_document_for_the_transition_period_v1.1-final.pdf","content":"lei:Legal Entity\nEvents/lei:Leg\nalEntityEvent/\nlei:Validation\nDocuments\nValidation Reference | lei:LEIData/lei | Newly added values to this Add Validation Reference values.\n‘LEIRecords/le | field could affect some users.\ni:.LEIRecord/le\ni:Entity/\nlei:Legal Entity\nEvents/lei:Leg\nalEntityEvent/\nlei:ValidationR\neference\nAffected Field lei:LEIData/lei | The newly added field could | Add Affected Field field in database structure.\n‘LEIRecords/le | affect some users if they do\ni:.LEIRecord/le | not have this field in system.\ni:Entity/\nlei:Legal Entity\nEvents/lei:Leg\nalEntityEvent/\nlei: AffectedFie\nlds/lei: Affecte\ndField\nSuccessor Entity /lei:LEIData/le | Cardinality changed from Handle multiple successor (due to different Legal Entity Events, which\ni:.LEIRecor | having max one successor could lead to split, demerger, etc.)\nds/lei:LEIR | entity to unbounded number\necord of successor entities.\n/lei:Entity/1\nei:Successo\nrEntity\n","contentLength":934,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:50:22.274Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/gleif-data-consumers-quick-guide.pdf","content":"GLEIF Data Consumer's Quick Guide\nThis guide serves as a summary of the data and interfaces that GLEIF provides and how they were affected by\nthe new CDF versions introduced on March 1st 2022. It includes concrete technical instructions and examples to\nhelp you make your automated systems compatible with the new CDF formats.\nBe sure to read the \"How To Use This Guide\" section before delving into the details.\nThis document focuses on technical changes to the data formats published by GLEIF relevant for automated\ndata processing to be capable of processing the new CDF formats. We omit details about deprecated\nfields/values, new Enum values and state transition rules relevant for interpreting the data correctly. Be sure to\ncheck the extensive information about the latest CDF formats published on the GLEIF website: Current Versions.\nContents\n¢ How To Use This Guide\n¢ XML: Golden Copy & Concatenated Files\no LEICDF 31\no RRCDF 2.1\no REPEX CDF 2.1\n¢ Concatenated Files\no Website\no XML Files\no Download API\n¢ Golden Copy\no Website\no XML Files\no Download API\no Export Formats\n= JSON\n= CSV\ne GLEIF API\n","contentLength":1105,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:50:52.045Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/gleif-data-consumers-quick-guide.pdf","content":"How To Use This Guide\ne Be sure to check the section \"XML: Golden Copy & Concatenated Files\" to get an overview of relevant\ntechnical changes introduced by the new formats\ne Check the table of contents and read the sections corresponding to the GLEIF data sources you use\n¢ Pay special attention to the “@ Instructions\" provided at the beginning of most sections to understand the\nminimal adjustments you should make to your systems to be able to consume the latest CDF files\n","contentLength":476,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:50:52.045Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/gleif-data-consumers-quick-guide.pdf","content":"Only the lei-records API resource structure changed. While existing attributes remained unchanged, new\nattributes, relationships and filters were added.\n@ Instructions:\n¢ Ignore unexpected JSON fields and values or add support for them\n¢ In case you rely on successor entity information\no use the new successorEntities attribute (plural; array) instead of the deprecated\nsuccessorEntity attribute (singluar). The old attribute remains but only contains the first\noccurrence, in case multiple successors were reported.\no usethe new successor-entities relationship (plural; one-to-many) instead of the deprecated\nsuccessor—-entity relationship (singluar; one-to-one). The old relationship remains but only links\nthe first successor entity occurrence, in case multiple successors were reported.\nFor details, see the documentation on GLEIF API Changes here or find it on the GLEIF web page for Supporting\nDocuments.\nExample files:\n¢ Download LEI 3.1 JSON:API response example\n¢ See the \"Example Files - GLEIF APl Response\" on the GLEIF web page about Supporting Documents\n¢ Visit the official download page for the Golden Copy files, which are published in the new formats since\nMarch 1st 2022.\n","contentLength":1191,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:50:52.045Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/gleif-data-consumers-quick-guide.pdf","content":"XML: Golden Copy & Concatenated Files\nThe new formats only introduced new optional fields and Enum values. This means the new XML schemas also\nvalidate historical files published prior to March 1st 2022. But validation could fail if you attempt to validate a file\nin the new version with an old XML schema. Furthermore, your automated data processing tools need to be able\nto deal with the new fields and Enum values introduced.\nInstructions:\n¢ Use the new XML Schemas (they also work on the historical files), in case you run XML schema\nvalidators against any published XML files\ne Ignore unexpected fields and values or add support for them\nNew XML schemas:\nCDF Version XML Schema\nLEI CDF 31 2021-03-04_lei-cdf-v3-1.xsd\nRR CDF 21 2021-03-04_rr-cdf-v2-1.xsd\nReporting Exceptions format 2.1 =~ 2021-07-20_reporting-exceptions-format-v2-1.xsd\nThe GLEIF Concatenated files and Golden Copy files are both be published in the new formats and all information\nabout the XML changes apply to both and took effect on March 1st 2022.\nLEI CDF 3.1\nThe LEI CDF 3.1 format introduced new (optional) fields and additional Enum values for the fields\nEntityCategory, EntityStatus, RegistrationStatus .\nInstructions:\ne Use the new XML Schemas (they also work on the historical files), in case you run XML schema\nvalidators against any published XML files\n¢ Ignore unexpected new fields or add support for them\ne |n case you use any of previously existing XML fields with new enums, ignore unexpected Enums or add\nsupport for them\nIn the following, we show all new (optional) XML elements introduced in LEI CDF 3.1. Additional details on\ndeprecations and new Enum fields are omitted and can be found on the website:\n¢ Release Notes / Change Log\n¢ Diagram with highlighted changes\nNew XML Elements:\n¢ The concatenated file now contains the GLEIF LEI code in the LEIData header:\nlei:LEIData/lei:LEIHeader/lei:Originator\ne New optional EntitySubCategory element\n¢ New optional LegalEntityEvents container element\ne New optional EntityCreationDate element\ne Existing SuccessorEntity container element can now occur multiple times\n","contentLength":2108,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:50:52.045Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/gleif-data-consumers-quick-guide.pdf","content":"Below snippet highlights the new (optional) fields that the new LEI CDF 3.1 format introduced. Check the\nSupporting Documents page for example files for GLEIF Concatenated files and Golden Copy files. Or go directly\nto the official download pages for the Concatenated files and Golden Copy files, which are published in the new\nformats since March 1st 2022.\n? ml ers on @ encod ng U 87\nle Data mlns gle f http gle f org concatenated f le header e tens on 2 @ mlns le\nle eader\nle ContentDate 2022 03 0 09 00 00 00 00 1le ContentDate\nle Or g nator 506 00G G29325Q 363 1le Or g nator\nle leContent G u PUB S D Lle leContent\nle RecordCount le RecordCount\nle tens on\ngle f Sources\ngle f Sources\nle tens on\nle eader\nle Records\nle Record mlns le http gle f org data schema le data 20 6\nle 506 900G G29325Q 363 le\nle nt ty\nle egaldur sd ct on D le egalJur sd ct on\nle nt tyCategory G R le nt tyCategory\nle nt tySubCategory C R GO R le nt tySubCategory\nle nt tyCreat onDate 2020 06 30 00 00 00 000 02 00 le nt tyCreat onDate\nle Successor nt ty le Successor nt ty\nle Successor nt ty le Successor nt ty\nle Successor nt ty le Successor nt ty\nle egal nt ty ents\nle egal nt ty ents\nle nt ty\nle Record\nle Records\nle Data\n. ________________________________________________________________________________________________J\nRR CDF 2.1\nThe RR CDF 2.1 format does only include additional Enum values for the fields RelationshipType ,\nRelationshipStatus , QualifierCategory .\n@ Instructions:\ne Use the new XML Schemas (they also work on the historical files), in case you run XML schema\nvalidators against any published XML files\n¢ |n case you use any of the affected fields, ignore unexpected Enums or add support for them\nAdditional details on deprecations and new Enum fields can be found on the website:\n¢ Release Notes / Change Log\n¢ Diagram with highlighted changes\nCheck the Supporting Documents page for example files for GLEIF Concatenated files and Golden Copy files. Or\ngo directly to the official download pages for the Concatenated files and Golden Copy files, which are published\nin the new formats since March 1st 2022.\n","contentLength":2113,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:50:52.045Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/gleif-data-consumers-quick-guide.pdf","content":"REPEX CDF 2.1\nThe Reporting Excepions format 2.1 format does only include additional Enum values for the ExceptionReason\nfield.\nInstructions:\ne Use the new XML Schemas (they also work on the historical files), in case you run XML schema\nvalidators against any published XML files\ne |n case you use any of the affected fields, ignore unexpected Enums or add support for them\nAdditional details on deprecations and new Enum fields can be found on the website:\n¢ Release Notes / Change Log\n¢ Diagram with highlighted changes\nCheck the Supporting Documents page for example files for GLEIF Concatenated files and Golden Copy files. Or\ngo directly to the official download pages for the Concatenated files and Golden Copy files, which are published\nin the new formats since March 1st 2022.\n","contentLength":785,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:50:52.046Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/gleif-data-consumers-quick-guide.pdf","content":"Concatenated Files\nThe concatenated files are still published via the GLEIF website and the API without any changes, except for the\nnew XML formats that need to be expected after March 1st 2022.\nWebsite\nOther than the displayed CDF version labels, the Concatenated file download pages remained unchanged.\nIn case you are processing the files automatically, see the main section \"XML: Golden Copy & Concatenated\nFiles\" and corresponding XML CDF type sections for instructions.\nXML Files\nInstructions:\n¢ Use the new XML Schemas (they also work on the historical files), in case you run XML schema\nvalidators against any published XML files\ne Ignore unexpected fields and values or add support for them\nSee the main section \"XML: Golden Copy & Concatenated Files\" for a technical summary of the changes\nintroduced in the new version.\nSee \"Example Files - Concatenated Files (XML)\" on Supporting Documents for example files. Or go directly to\nthe official download page for the Concatenated files, which are published in the new formats since March 1st\n2022.\nDownload API\nEverything stayed the same and all processes that were using the API before can expect the same URLs and\nJSON attributes.\nInstructions:\n* No need to change any API requests or the processing of the JSON responses\ne If you use the XML file downloads, ensure to prepare your system by checking the corresponding XML\nsections above.\nTo ensure backwards-compatibility of the API with consuming systems, the lei2 keyword used in the APl URLs\nand JSON response attributes remained; there was no 1lei3 introduced. To indicate the CDF version, the API\nrecently introduced a new cdf_version field that contains the new version identifiers since March 1st 2022:\nLEI_3_1, RR_2_1, REPEX_2_ 1\nThe following API request still looks identical since March 1st 2022, with the exception of the cdf_version :\nhttps://leidata.gleif.org/api/v1/concatenated-files/lei2/latest\n","contentLength":1922,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:50:52.046Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/gleif-data-consumers-quick-guide.pdf","content":"{ /\n\"data\": {\n\"id\": 12,\n\"type\": \"lei2\", I VLD Ouain M “cdf_wversion® will change, according to the “type’:\n\"content_date”: \"2822-82-0L 89:08:01\", leiz : LEI.3.1\n\"necond_count: 2064215, / - 1 RR_Z_1\n\"edg_venaion™: \"LEI_2.1\", repex : REPEX_2_1 XML file downloads\n\"§ile\": \"https://leidata,gle:i_f.orgapi\\.r1ccncatenated-filesleiZ/get/HBlZ/zip\",z«‘f_’;‘fLW\" will be in the new\n\"gilesize\": | 4 formats\n\"signatune\": \"https://leidata.gleif.org/api/vl/concatenated-files/leil/get/27012/signature\",\n\"sources”: [\noy o ;\n\"i4_galfback\": s,\n\"Pou_gife\": {\n\"id\" : ¢\n\"type™: \"lei2\",\n\"upfoaded_at\": \"2822-82-0L 88:33:85\",\n\"oniginaton\": \"©29280067ATKECHAHEES\",\n\"content_date\": \"2022-02-04L ©8:11:28\",\n\"necond_count\": 5\n\"edf_wvendion\": \"LEI_2.1\",\n\"file\": \"https://leidata.gleif.org/api/vi/source-files/leid/get/2202518/zip\",\n\"gilesize\": 7\n\"signatune\": \"https://leidata.gleif.org/api/vl/source-files/lei2/get/2262518/signature\"”\n3\nJ\n}\n","contentLength":915,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:50:52.046Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/gleif-data-consumers-quick-guide.pdf","content":"Golden Copy\nExcept for the new (optional) elements and enum values, the Golden Copy files remained the same. The XML and\nJSON files continue to have the GeoCoding data.\nWebsite\nOther than the displayed CDF version labels, the Golden Copy download page will remained unchanged.\nIn case you are processing the files automatically, see the main section \"XML: Golden Copy & Concatenated\nFiles\" and corresponding XML CDF type sections for instructions.\nXML Files\nSee the main section \"XML: Golden Copy & Concatenated Files\" for further instructions and technical summary\nof the changes introduced in the new version.\nSee \"Example Files - Golden Copy (XML,JSON, CSV)\" on Supporting Documents for example files. Or go\ndirectly to the official download page for the Golden Copy files, which are published in the new formats since\nMarch 1st 2022.\nInstructions:\n¢ Use the new XML Schemas (they also work on the historical files), in case you run XML schema\nvalidators against any published XML files\ne Ignore unexpected fields and values or add support for them\nDownload API\nEverything stayed the same and all processes that use the API can expect the same URLs and JSON attributes.\nInstructions:\n* No need to change any API requests or the processing of the JSON responses\ne If you use the XML file downloads, ensure system can handle the new formats by checking the\ncorresponding XML sections above.\n* If you use the CSV/JSON file downloads, ensure to your system can handle the new fromats by\nchecking the corresponding Golden Copy CSV/JSON export sections below.\nTo ensure backwards-compatibility of the API with consuming systems, the lei2 keyword used in the APl URLs\nand JSON response attributes remained; there was be no 1lei3 introduced. To indicate the CDF version, the API\nrecently introduced a new cdf_version field that will contain the new version identifiers starting March 1st\n2022: LEI_3_1, RR_2_1, REPEX_2 1\nThe following API request still looks identical after March 1st 2022, with the exception of the cdf_version :\nhttps://goldencopy.gleif.org/api/v2/golden-copies/publishes/lei2/latest\n","contentLength":2098,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:50:52.046Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/gleif-data-consumers-quick-guide.pdf","content":"L f\n\"data”s {\n\"type\": \"leid\", *—'—— Type remains “lei2\n\"pub@ish_date\": \"2022-82-8L 88:00708\",\n\"Guel_gite\":\nYtype\": \"lei2\",\n\"gonmat™: “ecsv\",\n“necond_count\": 5\n\"size\": f €SV downloads will be i\n\"size_human_neadab@e”: “214.57 MB\", Afi,/ the new format\n\"delta_type”: \"GoldenCopy\", £\n\"une\": \"https://leidata-preview.gleif.org/storage/golden-copy-files/2822/082/04/595266/208226284-0808-gleif-goldencopy-lei2-golden-copy.csv.zip\",\nYedf_vension”: \"LEI_2.1\"\n}f & cdf_version® will change, according to the “type :\nTaonT: £ lei2 : LEI_3.1\n\"type\": \"lei2\", rr D RR_Z_1\n\"gonmat\": \"json\", repex : REPEX_Z_1\n\"necond_count\": 4 » JSON downloads will be in\n\"size\": f the new format\n\"size_human_neadabfe™”: \"386.L6 MB\", 4 ;,:’\n\"defta_type”: \"GoldenCopy\", fi\n\"ung\": \"https://leidata-preview.gleif.org/storage/golden-copy-files/2022/02/04/595257/2022020L-0800-gleif-goldencopy-lei2-golden-copy.json.zip\",\n\"cd§_vension”: \"LEI_2.1\"\n1\nTxme\": {\n\"type\": \"lei2\",\n\"gonmat\": “xml\",\n::fl%\\ia:d,count\": = XML downloads will be i\n\";i:‘c,r.mmfl;i,1r_’c1dq£'£'e”: \"415.63 NB\", ,:_.;-fr\" o\n\"defta_type”: \"GoldenCopy\", o\n\"un€\": \"https://leidata-preview.gleif.org/storage/golden-copy-files/2022/02/04/595254/20220204-0800-gleif-goldencopy-lei2-golden-copy.xml.zip\",\n\"cd§_vension”: \"LEI_2.1\"\n3\n\":feum,gwf;”:\n\"IntnaDay™: § e\n\"Lastbay\": { 3,\n“LastMonth\": § i\n\"Lastheek”: { 3\n;\nNote that the Golden Copy APl is available via two domains goldencopy.gleif.org and leidata-\npreview.gleif.org (legacy). This could lead to differing download URLs, but does not pose any problems as the\nbehavior did not change.\nExport Formats\nJSON\nThe JSON exports was be extended with the additionally introduced fields, where present. Additionally, the\nEntity.SuccessorEntity field now holds an array of potentially multiple successor entity entries and certain\nfields are ensured to always be returned as an array.\n@ Instructions:\nLEI:\ne If you use the Entity.SuccessorEntity field, your system must expect an array of object s (the\nSuccessor Entity is now a repeatable field)\ne If you use the AdditionalAddressLine in any of the addresses, your system must expect an array of\nstring s. Since March 1st 2022 this field is always an array, even if only one additional address line is\npresent.\ne If you use the OtherValidationAuthority field, your system must expect either an array of\nobjects . Since March 1st 2022 this field is always an array.\nRR:\ne |f you use the RelationshipQualifier or RelationshipQuantifier field, your system must expect an\narray of object s. Since March 1st 2022 this field is always be an array.\nREPEX:\ne |If you use the ExceptionReason or ExceptionReference field, your system must expect an array of\nstring s. Since March 1st 2022 this field is always be an array.\n","contentLength":2732,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:50:52.046Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/gleif-data-consumers-quick-guide.pdf","content":"For details, see the JSON Export section of the document \"(Breaking) Changes in Golden Copy Exports\"\npublished on the GLEIF website under Supporting Documents.\nExample Files:\n¢ Download LEI 3.1, RR 2.1, REPEX 2.1 JSON Export Example\n¢ See \"Example Files - Golden Copy (XML, JSON, CSV)\" on Supporting Documents\n¢ Visit the official download page for the Golden Copy files, which are published in the new formats since\nMarch 1st 2022.\nCsv\nOnly the CSV export for LEI data changed in structure, due to additional columns that were added and the now-\nrepeating SuccessorEntity field.\n@ Instructions:\ne Ensure your system does not rely on the exact order of the columns (e.g. by parsing the CSV into an\nunordered mapping of column names to values, instead of ordered listes of values)\ne If yourely onany Entity.SuccessorEntity.x* field, ensure to support the indexed 1-5 column names\n(Entity.SuccessorEntity.1.x )\nFor details, see the CSV Export section of the document \"(Breaking) Changes in Golden Copy Exports\"\npublished on the GLEIF website under Supporting Documents.\nExample files:\n¢ Download LEI 3.1, RR 2.1, REPEX 2.1 CSV Export Example\n¢ See \"Example Files - Golden Copy (XML, JSON, CSV)\" on Supporting Documents\n¢ Visit the official download page for the Golden Copy files, which are published in the new formats since\nMarch 1st 2022.\n","contentLength":1340,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:50:52.046Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"]\nP LEl =\no\nPublic\nLEI Common Data File format V2.1\nFINALV2.1 2017-03-21\n; ‘ ©)) « 1\no R W ’\n~ (@\nl‘ .. ] p\n| \" |\n‘-\\\\\\\\2‘:~://///\n","contentLength":131,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.943Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"]\nLEI Common Data File format V2.1 @ LEl\nContents\nLo INEFOTUCTION ittt et et e st sttt e st ee e et ee s sbbe e ambee s subeesseeesneeesssseesnnsensssseesanses ]\n\n1.1. Audience for this dOCUMENT......cciii it ettt e s e s sreee e &\n1.2. Status Of this dOCUMENT ....coouiiiiiie e ettt et st e st s e e sreee e &\n1.3. Terminology and Typographical CONVENTIONS........cciiceiieii ittt serae e srree e seee O\nO o 11 1 L1 4 [T U T O PSP P OO PSP PPPPOPUPTPRTOPIRS -\n1.5, BUSINESS RUIES .....ieiiiie ettt ettt ettt e et s sh e e et esatbe e s sbeee st e e e sbsaeenteessubeesanseesnnneesssneess O\n1.6 XIMIL SYNTAX i iiieie ittt e e e e e e e e e e e e e eeeeeeeteteeae bt ae e st st st st s sss s s sesneneesaseseaeeesesnenenessenenennsns O\n1.6.1. XML DESIZN RUIES..cciiiieiet ittt ettt ettt te et ee s e ee s ste e s s s saanae s assasneeesssssnneeassssnneesassnneeees O\n1.6.2. XML SCREMIA ettt ettt ettt st e st ee st e s s tee st e s sbteeenneeessubeassnseesnnseesssssesnneeeesseeees L0\n1.7. REIEASE NOLES .eeiieiiiiie ettt ettt ettt et e s sabe e e s tee st e e sbbtesnneeesabaeannseessnneessnseesnnneessnnes 2\nO I =T YT o T TP PP PP\n1.7.2.VErSION 2.0 iciiiiiiiiieiteecie ettt s e e rrreaeseese e s e e sennnas 2\n1.7.3.VErSion 1.0 ittt e arae s aeesee s s snnnns 20\n1.8. Change ManagemENt.......cceiicciiiiieieiiieeeeeetieeeeeecttteessettaeeesestteeaesseteessanssteessssnsseesssnsseesesssssssesssnsss 20\nR T B g =) = Y A= €] o o I PP TP PPPOPPPPPPY. o\n1.8.2. MIINOT VEISION 1.ttt ettt et e e s et earae e te e s s s snssnneaesaeesenssnsnsnnns 27\n1.8.3. MJOT VEISION ceetetiiiiiiiitititce e e e e e e e e e e eeeeeeetetetetettrbeeeenesessss s s s sasesasesaseseseeeesenenensesesenns 27\n1.8.4. Minor Version Changes to the XML SChema ........ccovvuiiiiiiiiiiieiniseeie e cssieee s seee e esseenn 27\n1.8.5. Major Version Changes to the XML SChema........ccoiiiiiiiiiiiiiie et seens 28\n2. ADSEract Data CONTENT......eieiciie ettt ettt ettt et st e s et et e e sbbe e sree s sabeessnseesnnbeessssaesnneeeessneees 2O\n2.0, LEI File HEAUET ettt ettt ettt ettt ettt st te et e s sabe e s st e snbeesssaesmneeesnseesnnneessuseesnns 20\n2.2, LEI DAta RECOIA ... uiiiiiiieeieee ettt ettt ettt ettt te ettt sab e eseeeesabeesssaesnbeesssseesnseeesssessnnseessuseessns SO\n2.2.3. REGISTIAtiON .. e e e e e e e e e e eeee et ee e tetete e bt bt e nn it e e seeesanenees 32\nB =4 = o £ o o PP PP PP OPRRPPPPPIR: 7.\n2.3. Data Element REFEIENCE «....uei ittt ettt sttt sbb e e eeeesabeeennseeees 33\n2.3.1. Element |@QLEIDATa.....ccccieeeieiee ettt ettt ettt et ee s sabe e st ee e e e s nee e sneeessnneenneeesnnes S\n2.3.2. Element lei:LEIData / [€i:LEIHEAEN ..cccceeeeeeeeeee ettt ettt te e ee e e sessssasesseeeeeees 35\n2.3.3. Element lei:LEIHeaderType / 1ei:ContentDate........cccuveeceeeeiieerciee e e ssvveeeee e e stte s sree e eveeeens 30\n2.3.4. Element lei:LEIHeaderType / 1ei:0riginator ......ccccvevieecceeescieecceee e e esvvee e e stte s ssvaeesveeeeees 37\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 2 of 152\n","contentLength":3012,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.943Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"- ]\nLEI Common Data File format V2.1 @ LEl\n\n\n\n\n\n \n\n\n\n\n\n \n \n\n\n \n\n\n\n\n\n\n\n\n\n\n\n \n \n\n{1,1}\n{0,1}\n{0,1}\n\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 105 of 152\n","contentLength":628,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.943Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"=\"\nLEI Common Data File format V2.1\n9 LE\n\n2.3.71. Element lei:ValidationAuthorityType / lei:ValidationAuthoritylD\n\nThe reference code of the registration authority, taken from the Registration Authorities List\n\n(RAL) maintained by GLEIF.\n\nlei:RegistrationAuthorityEnum\n\ncontent simple\n\npattern RA\\d{6}\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 106 of 152\n","contentLength":369,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.943Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1\n,LE|\n2.3.72. Element lei:ValidationAuthorityType / lei:OtherValidationAuthoritylD\nA legacy / historical reference code of a registration authority which is not yet entered in the\nRegistration Authorities List (RAL) maintained by GLEIF, or the designation of an interim\nregister until such time as an entry from RAL can be delivered.\nlei:Tokenized500Type\ncontent simple\nminOccurs 0\nminLength 1\nmaxLength 500\npattern \\S+( \\S+)*\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 107 of 152\n","contentLength":527,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.943Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1\n3, LE|\n\n2.3.73. Element lei:ValidationAuthorityType / lei:ValidationAuthorityEntitylD\nThe identifier of the entity at the indicated registration authority. Typically, the identifier of\nthe legal entity as maintained by a business registry in the jurisdiction of legal registration,\nor if the entity is one that is not recorded in a business registry (e.g. one of the varieties of\nfunds registered instead with financial regulators), the identifier of the entity in the\nappropriate registration authority.\nlei:Tokenized500Type\ncontent simple\nminOccurs 0\nminLength 1\nmaxLength 500\npattern \\S+( \\S+)*\n\nPublic\n\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 108 of 152\n","contentLength":701,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.943Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1 ‘; 3 LEl\nN’\n2.3.74. Element lei:RegistrationType / lei:OtherValidationAuthorities\nAn optional list of additional registration authorities used by the LEI Issuer to validate the\nentity data.\nlei:OtherValidationAuthoritiesType\ncontent complex\nminOccurs 0\n\n{1l,unbounded}\n\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 109 of 152\n","contentLength":555,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.943Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1 ‘3 LE|\n4\n2.3.75. Element lei:OtherValidationAuthoritiesType /\nlei:OtherValidationAuthority\nAn additional registration authority used by the LOU to validate the entity data.\nlei:ValidationAuthorityType\ncontent complex\nminOccurs 0\nmaxOccurs unbounded\n\n{1,1}\n{0,1}\n{0,1}\n\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 110 of 152\n","contentLength":678,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.943Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1 %, LE|\ntype=\"lei:TransliteratedOtherEntityNamesType\" minOccurs=\"0\">\n\n \n\n\n \n \n \n \n \n\n\n \n\n\n \n \n \n \n\n\n\n\n\n\n\n\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 12 of 152\n","contentLength":1763,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.943Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1 ‘3 LEl\nN’\n\n2.3.76. Element lei:RegistrationType / lei:NextVersion\nA structure for adding further elements in to the Registration section of the LElI Data\nRecord in anticipation of a new version, by nesting a series of XML elements with this\ncontent model within the Nextversion element, one for each new minor version of the\nschema, postpending a serial number (1,2,3...) to the element name upon each iteration.\nlei:RegistrationNextVersionType\ncontent complex\nminOccurs 0\n\nPublic\n\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 111 of 152\n","contentLength":575,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.943Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1 ‘3 LEl\nP\n2.3.77. Element lei:LEIRecordType / lei:NextVersion\nA structure for adding further elements in to the LEI Data Record in anticipation of a new\nversion, by nesting a series of XML elements with this content model within the\nNextVersion element, one for each new minor version of the schema, postpending a serial\nnumber (1,2,3...) to the element name upon each iteration.\nlei:LEIRecordNextVersionType\ncontent complex\nminOccurs 0\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 112 of 152\n","contentLength":536,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.943Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1\nS LE\n2.3.78. Element lei:LEIRecordType / lei:Extension\nThis lei:Extension element may contain any additional elements required to extend the\nLEIRecord.\nlei:ExtensionType\ncontent complex\nminOccurs 0\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 113 of 152\n","contentLength":298,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.943Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"- 00000000000\nLEI Common Data File format V2.1 ‘3' LEl\n2.3.79. Simple Type lei:LEIDateTimeProfile\n\nrestriction of xs:dateTime\n(IA\\T* AT\\ ((\\d){2,31){0,1})) (2| \\+([01][O-\npattern 9]12[0-3]):([0-5][0-9]) | -([01][0-9] | 2[0-3]):([O-\n5][0-9]))\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 114 of 152\n","contentLength":309,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.943Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"=\"\nLEI Common Data File format V2.1\nS LEI\n2.3.80. Simple Type lei:LEIType\nrestriction of xs:string\nminLength 20\nmaxLength 20\npattern ([0-9A-Z]{18}{0-9]{2})\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 115 of 152\n","contentLength":223,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.943Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1 ‘% LEl\n\\l\n2.3.81. Simple Type lei:FileContentEnum\nrestriction of xs:string\nThe file contains all LEl Data Records published by\n. an LOU (all LEI Data Records for which the LOU is\nenumeration LOU_FULL_PUBLISHED the ManagingLou) as of the date/time the file is\ncreated.\nThe file contains those LEI Data Records published\nby an LOU (all LEI Data Records for which the LOU\nenumeration LOU_DELTA_PUBLISHED s the ManagingLou) which are new or changed\nsince the peltastart date specified in the\nheader, as of the date/time the file is created.\nThe file contains all LEl Data Records published by\nenumeration GLEIF_FULL_PUBLISHED GLEIF (including all LEI Data Records from all\nLOUs) as of the date/time the file is created.\nThe file contains those LEI Data Records published\nby GLEIF (including all LEI Data Records from all\nenumeration GLEIF_DELTA_PUBLISHED LOUs) which are new or changed since the\nDeltastart specified in the header, as of the\ndate/time the file is created.\nenumeration QUERY_RESPONSE The fll.e cgntams records matching criteria\nspecified in a query.\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 116 of 152\n","contentLength":1163,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.943Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1\n3, LE|\n2.3.82. Complex Type lei:NameType\nextension of lei:Tokenized500Type\nAttempting to install the relevant ISO 2- and 3-letter\nunion codes as the enumerated possible values is probably\nof(xs:language never going to be a realistic possibility. See RFC 3066 at\nxml:lang restri.ctiogn ofg ’ optional http://www.ietf.org/rfc/rfc3066.txt and the IANA\nxs:string) registry at http://www.iana.org/assignments/lang-tag-\n) g apps.htm for further information. The union allows for\nthe 'un-declaration' of xml:lang with the empty string.\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 117 of 152\n","contentLength":629,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.944Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1\n3y LEI\n2.3.83. Simple Type lei:Tokenized500Type\nAn element of this type has minimum length of one character and may not contain any of:\nthe carriage return (#xD), line feed (#xA) nor tab (#x9) characters, shall not begin or end with\na space (#x20) character, or a sequence of two or more adjacent space characters.\nrestriction of xs:string\nminLength 1\nmaxLength 500\npattern \\S+( \\S+)*\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 118 of 152\n","contentLength":485,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.944Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1\n3, LE|\n2.3.84. Complex Type lei:OtherEntityNameType\nextension of lei:NameType\nAttribute Type Use Annotation\ni I\ntype lei:EntityNameTypeEnum required Typ.e of alternative name for the lega\nentity.\nAttempting to install the relevant ISO 2- and\n3-letter codes as the enumerated possible\nvalues is probably never going to be a\nrealistic possibility. See RFC 3066 at\ni : http: .ietf. fc/rf . h\nxml:lang unlor\\ of(xs Ianguage, optional ttp //WYVW ietf.org/rfc/rfc3066.txt and the\nrestriction of xs:string) IANA registry at\nhttp://www.iana.org/assignments/lang-tag-\napps.htm for further information. The union\nallows for the 'un-declaration' of xml:lang\nwith the empty string.\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 119 of 152\n","contentLength":770,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.944Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1 ‘3 LE|\nP\n2.3.85. Simple Type lei:EntityNameTypeEnum\nrestriction of xs:string\nRegistered name of the entity in an\nenumeration ALTERNATIVE_LANGUAGE_LEGAL_NAME 2 /te\"native language in the egal\njurisdiction in which the entity is\nregistered.\nenumeration PREVIOUS_LEGAL_NAME A primary legal name previously\n- used by this entity.\nA \"trading as\", \"brand name\" or\n\"operating under\" name currently\nenumeration TRADING_OR_OPERATING_NAME used by this entity in addition to,\nbut not replacing, the (primary)\nlegal, official registered name.\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 120 of 152\n","contentLength":631,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.944Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"- ]\nLEI Common Data File format V2.1 @ LEl\n\n \n\n\n \n\n\n \n \n \n \n \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 13 of 152\n","contentLength":1477,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.944Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1\n‘3, LE|\n2.3.86. Complex Type lei:TransliteratedOtherEntityNameType\nextension of lei:TransliteratedNameType\nAttr;but Type Use Annotation\ntvpe lei:TransliteratedEntityNameTypeE require Type of alternative name for the\nP num d legal entity.\nAttempting to install the relevant\nISO 2- and 3-letter codes as the\nenumerated possible values is\nprobably never going to be a\nrealistic possibility. See RFC 3066 at\nxml:lan union of(xs:language, restriction of optiona http://www.ietf.org/rfc/rfc3066.txt\ng xs:string) I and the IANA registry at\nhttp://www.iana.org/assignments/I\nang-tag-apps.htm for further\ninformation. The union allows for\nthe 'un-declaration' of xml:lang with\nthe empty string.\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 121 of 152\n","contentLength":786,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.944Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1\n3, LE|\n2.3.87. Complex Type lei:TransliteratedNameType\nextension of lei:TransliteratedStringType\nAttribute Type Use Annotation\nAttempting to install the relevant ISO 2- and 3-letter\n. codes as the enumerated possible values is probably\nunion . . -\nof(xs:language never going to be a realistic possibility. See RFC 3066 at\nxml:lang restri.ction of \" optional http://www.ietf.org/rfc/rfc3066.txt and the IANA\n. registry at http://www.iana.org/assignments/lang-tag-\nXs:string) . . .\napps.htm for further information. The union allows for\nthe 'un-declaration' of xml:lang with the empty string.\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 122 of 152\n","contentLength":691,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.944Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1 ‘@ LEl\n~?\n2.3.88. Simple Type lei:TransliteratedStringType\nCharacter Codes Allowed in ASCII Transliterated Names\nA TransliteratedotherEntityName instance of type\nPREFERRED ASCII TRANSLITERATED LEGAL NAME Or\nAUTO ASCII TRANSLITERATED LEGAL_NAME, can only contain non-control characters drawn\nfrom the “invariant subset” of ISO 646. These characters are enumerated below. The “Hex\nValue” column indicates the code point value (expressed in hexadecimal) for each character\nin both ISO 646 and ISO 10646. This is enforced by the XML schema.\nGraphic Hex Graphic Hex\nSymbol Value Symbol Value\nExclamation 21 Capital Letter | 4D\nMark M\n- o . o\nN\n% Percent Sign 25 Capital Letter | 4F\n@)\n-- e\nP\nApostrophe 27 Capital Letter |51\nQ\no . S\nR\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 123 of 152\n","contentLength":830,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.944Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1 ‘@ LE|\nN\n) Right 29 S Capital Letter |53\nParenthesis S\n+ 2B U Capital Letter |55\nU\nComma 2C \\Y Capital Letter |56\n\\\nHyphen/ Minus 2D w Capital Letter | 57\nW\nFull Stop 2E X Capital Letter | 58\nX\n/ Solidus 2F Y Capital Letter |59\nY\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 124 of 152\n","contentLength":330,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.944Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"]\nLEI Common Data File format V2.1 @ I_E|\nS S O\nT e T =\nS o O T e\nS o O e\nI O T =\nI e O O =\nS e O ey\nS o O T =y\nR\n\nSign\nR e O e\nS ey O T e\nS ey O et\nS e O T e\nSR e O T =\nS e o T ey\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 125 of 152\n","contentLength":248,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.944Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1 ‘@ LE|\nP\nrestriction of lei:-Tokenized500Type\nminLength 1\nmaxLength 500\n(\\S+(\\S+)*) & (\" [% | &I\"INUIN) IN*[\\+], -\npattern I\\.-17101212[3]4|5]|6]|7|8]91:|;|1<|=]>|\\?|A[B|CIDI|E|FIG|H[I[J|K]L]|\nIMIN|O|P|QIR|SITIUIVIWIX]|Y|Z| _|albl|cld]|e|f|glhliljlk]I[m]|n\nlolplalr|sitiulviw]x]y|z)+)\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 126 of 152\n","contentLength":385,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.944Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1\n3, LE|\n2.3.89. Simple Type lei:TransliteratedEntityNameTypeEnum\nrestriction of xs:token\nLegal name of the entity\ntransliterated to ASCII\nenumeration PREFERRED_ASCII_TRANSLITERATED_LEGAL_NAME characters, provided by\nthe entity for this\npurpose.\nLegal name of the entity\ntransliterated to ASCII\nenumeration AUTO_ASCII_TRANSLITERATED_LEGAL_NAME characters, auto-\ntransliterated by the\nmanaging LOU.\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 127 of 152\n","contentLength":496,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.944Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1\n3, LE|\n2.3.90. Complex Type lei:AddressType\nAttempting to install the relevant ISO 2- and 3-letter\n. codes as the enumerated possible values is probably\nunion . . -\nof(xs:language never going to be a realistic possibility. See RFC 3066 at\nxml:lang restri.ction of \"’ optional http://www.ietf.org/rfc/rfc3066.txt and the IANA\n. registry at http://www.iana.org/assignments/lang-tag-\nXs:string) . . .\napps.htm for further information. The union allows for\nthe 'un-declaration' of xml:lang with the empty string.\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 128 of 152\n","contentLength":609,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.944Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEl Common Data File format V2.1 ;\n,LE|\n2.3.91. Simple Type lei:RegionCodeType\nA 4- to 6-character ISO 3166-2 region code of the region. Please note that the XML schema\nvalidates for all countrycode values consisting of 2 upper-case Latin letters; some possible\ncombinations may not be valid ISO 3166 entries.\nrestriction of xs:string\nminLength 4\nmaxLength 6\npattern ([A-Z]{2}-[A-Z0-9]{1,3})\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 129 of 152\n","contentLength":459,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.944Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1\n3, LE|\n\n2.3.92. Simple Type lei:CountryCodeType\nA 2-character country code conforming to ISO 3166-1 alpha-2. Please note that the XML\nschema validates for all countrycode values consisting of 2 upper-case Latin letters; some\npossible combinations may not be valid ISO 3166 entries. A current code from the ISO-\napproved list must be used used. See\nhttp://www.iso.org/iso/home/standards/country_codes.htm for more details.\nrestriction of xs:string\nminLength 2\nmaxLength 2\npattern ([A-Z]{2})\n\nPublic\n\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 130 of 152\n","contentLength":592,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.944Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1 %, LEI\n \n \n \n \n \n\n\n \n \n\n \n\n\n\n \n \n \n \n \n\n\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 14 of 152\n","contentLength":1553,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.944Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1\n‘3, LEI\n2.3.93. Complex Type lei:OtherAddressType\nextension of lei:AddressType\nAttribute Type Use Annotation\nTh f hi\ntype lei:AddressTypeEnum required etype o add.ress represented by this\nOtherAddress Instance.\nAttempting to install the relevant ISO 2- and 3-\nletter codes as the enumerated possible values\nis probably never going to be a realistic\nnion of(xs:language possibility. See RFC 3066 at\nunion omxs: guage, . http://www.ietf.org/rfc/rfc3066.txt and the\nxml:lang restriction of optional .\nxs:string) IANA registry at\n) g http://www.iana.org/assignments/lang-tag-\napps.htm for further information. The union\nallows for the 'un-declaration' of xml:lang with\nthe empty string.\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 131 of 152\n","contentLength":783,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.944Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1\n3, LE|\n2.3.94. Simple Type lei:AddressTypeEnum\nrestriction of xs:string\nRegistered address of\nthe entity in the legal\nenumeration ALTERNATIVE_LANGUAGE_LEGAL_ADDRESS Jurisdiction, in an\n= alternative language\nused in the legal\njurisdiction.\nAddress of the\nheadquarters of the\n. entity, in an\nenumeration ALTERNATIVE_LANGUAGE_HEADQUARTERS_ADDRESS .\nalternative language\nused in the legal\njurisdiction.\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 132 of 152\n","contentLength":500,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.944Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1 ‘3 LE|\nN’\n2.3.95. Complex Type lei:TransliteratedOtherAddressType\nextension of lei:TransliteratedAddressType\nAttr;but Type Use Annotation\ntvpe lei:TransliteratedAddressTypeEnu require Type of alternative name for the legal\nP m d entity.\nAttempting to install the relevant ISO\n2- and 3-letter codes as the\nenumerated possible values is\nprobably never going to be a realistic\npossibility. See RFC 3066 at\n«ml:lan union of(xs:language, restriction optiona http://www.ietf.org/rfc/rfc3066.txt\nHang of xs:string) I and the IANA registry at\nhttp://www.iana.org/assignments/la\nng-tag-apps.htm for further\ninformation. The union allows for the\n'un-declaration’ of xml:lang with the\nempty string.\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 133 of 152\n","contentLength":788,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.944Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1\n3, LE|\n2.3.96. Complex Type lei:TransliteratedAddressType\nAttribute Type Use Annotation\nAttempting to install the relevant ISO 2- and 3-letter\nunion codes as the enumerated possible values is probably\nof(xs:language never going to be a realistic possibility. See RFC 3066 at\nxml:lang restri.ctiogn ofg \" optional http://www.ietf.org/rfc/rfc3066.txt and the IANA\nxs:string) registry at http://www.iana.org/assignments/lang-tag-\n) g apps.htm for further information. The union allows for\nthe 'un-declaration' of xml:lang with the empty string.\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 134 of 152\n","contentLength":642,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.944Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1\n‘%, LEI\n2.3.97. Simple Type lei:TransliteratedAddressTypeEnum\nrestriction of xs:string\nRegistered address of\nthe entity in the legal\njurisdiction,\nenumeration AUTO_ASCII_TRANSLITERATED_LEGAL_ADDRESS transliterated to ASCII\ncharacters, auto-\ntransliterated by the\nmanaging LOU.\nAddress of the\nheadquarters of the\nenumeration AUTO_ASCII_TRANSLITERATED_HEADQUARTERS_ADDRESS entity, transliterated to\nASCII characters, auto-\ntransliterated by the\nmanaging LOU.\nRegistered address of\nthe entity in the legal\njurisdiction,\nenumeration PREFERRED_ASCII_TRANSLITERATED_LEGAL_ADDRESS transliterated to ASCII\ncharacters, provided by\nthe entity for this\npurpose.\nAddress of the\nheadquarters of the\n. i\nenumeration PREFERRED_ASCIl_TRANSLITERATED_HEADQUARTERS_ADDREss i/t transliterated to\nASCII characters,\nprovided by the entity\nfor this purpose.\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 135 of 152\n","contentLength":935,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.944Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LElI Common Data File format V2.1\n3y LEI\n2.3.98. Simple Type lei:RegistrationAuthorityEnum\nrestriction of xs:string\npattern RA\\d{6}\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 136 of 152\n","contentLength":199,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.944Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"=\"\nLEI Common Data File format V2.1\nB LE\n2.3.99. Simple Type lei:JurisdictionCodeType\nunion of(lei:CountryCodeType, lei:RegionCodeType)\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 137 of 152\n","contentLength":203,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.944Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1\n3y LEI\n2.3.100. Simple Type lei:EntityCategoryTypeEnum\nrestriction of xs:token\nenumeration BRANCH The legal entity is a branch of another legal entity.\nenumeration EUND The Iegal. entity is a fund managed by another\nlegal entity.\nenumeration SOLE_PROPRIETOR The.legal entltY is an individual acting in a\nbusiness capacity.\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 138 of 152\n","contentLength":423,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.944Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1\n3, LE|\n2.3.101. Simple Type lei:LegalFormEnum\nPlease note that the XML schema validates for all LegalForm values conforming to the ISO\n20275 standard (section \"Code Structure\"); four uppercase alphanumeric characters in any\ncombination except for purely numeric codes. Some possible combinations may not be valid\nEntity Legal Form (ELF) entries.\nrestriction of xs:string\n((IA-z][A-Z0-9]{3}| [A-ZO-\n9][A-Z][A-20-9){2}| [A-ZO-\ntt\npattem 91{2}[A-Z][A-20-9] | [A-ZO-\n91{3}[A-Z]))[(9999) | (8888)\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 139 of 152\n","contentLength":592,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.944Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1\nS LE\n\n2.3.102. Complex Type lei:AssociatedEntityType\n\nAttribute Type Use Annotation\n\n. . . . The type of association represented\n\ntype lei:AssociatedEntityTypeEnum required by this AssociatedEntity instance.\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 140 of 152\n","contentLength":308,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.944Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"- ]\nLEI Common Data File format V2.1 @ LEl\n\n\n \n \n\n \n\n\n\n \n\n\n\n \n\n\n\n \n \n \n\n\n\n\n \n\n\n\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 15 of 152\n","contentLength":1461,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.944Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1\nB LE\n\n2.3.103. Simple Type lei:AssociatedEntityTypeEnum\n\nrestriction of xs:string\n\nenumeration FUND_FAMILY Thg Iegal entity is a fund, and the associated\n\nentity is the manager of the fund.\n\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 141 of 152\n","contentLength":291,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.944Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1 ‘3 LE|\nN’\n2.3.104. Simple Type lei:EntityStatusEnum\nrestriction of xs:string\nAs of the last report or update, the legal entity\nenumeration ACTIVE reported that it was legally registered and\noperating.\nIt has been determined that the entity that was\nassigned the LEl is no longer legally registered\nenumeration INACTIVE and/or operating, whether as a result of business\nclosure, acquisition by or merger with another (or\nnew) entity, or determination of illegitimacy.\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 142 of 152\n","contentLength":567,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.944Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1\n,LE|\n2.3.105. Simple Type lei:EntityExpirationReasonEnum\nrestriction of xs:string\nenumeration DISSOLVED The entity ceased to operate.\nenumeration CORPORATE ACTION Thg entity was acquired or merged with another\n- entity.\n. The reason for expiry is neither of bT1ssoLvED nor\nenumeration OTHER CORPORATE_ACTTON\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 143 of 152\n","contentLength":408,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.944Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1 @ LEl\n\\I\n2.3.106. Simple Type lei:RegistrationStatusEnum\nType restriction of xs:string\nAn application for an LEI that has been\nenumeration PENDING_VALIDATION submitted and which is being processed and\nvalidated.\nAn LEI Registration that has been validated\n. e ifi .\nenumeration ISSUED and issued, and Wh'ICh identi |e§ an entity\nthat was an operating legal entity as of the\nlast update.\nAn LEI Registration that has been determined\nto be a duplicate registration of the same\n. legal entity as another LEI Registration; the\nenumeration DUPLICATE DUPLICATE status is assigned to the non-\nsurviving registration (i.e. the LEI that should\nno longer be used).\nAn LEl registration that has not been\nFacets enumeration LAPSED renewed by tht.a NextRenewalDate and is not\nknown by public sources to have ceased\noperation.\nAn LEIl registration for an entity that has been\nenumeration MERGED mt.arged into ?nother legal er'\\tlty, such that\nthis legal entity no longer exists as an\noperating entity.\nAn LEIl registration for an entity that has\nenumeration RETIRED ceased operation, without having been\nmerged into another entity.\nenumeration ANNULLED An LEI reglstrgtlon'that wa's marlfed as\nerroneous or invalid after it was issued\n. ion th .\nenumeration CANCELLED An'LEI registration that was abandoned prior\nto issuance of an LEI\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 144 of 152\n","contentLength":1421,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.944Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1 ‘3 LE|\nN’\n. An LEl registration that has been transferred\nenumeration TRANSFERRED\n\" on to a different LOU as the managing LOU.\nAn LEI registration that has been requested\nenumeration PENDING TRANSFER to be tra.nsfe.rred to another LOU. The.\n- request is being processed at the sending\nLOU\nAn LEIl registration is about to be transferred\nenumeration PENDING_ARCHIvAL '° @ different LOU, after which its\n- registration status will revert to a non-\npending status.\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 145 of 152\n","contentLength":563,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.944Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEl Common Data File format V2.1 ‘@ LE|\n\\I\n2.3.107. Simple Type lei:ValidationSourcesEnum\nType restriction of xs:string\nThe validation of the reference data\nenumeration PENDING provided by the registrant has not yet\noccurred.\nBased on the validation procedures in\nuse by the LOU responsible for the\nrecord, the information associated with\nenumeration ENTITY_SUPPLIED_ONLY this record has significant reliance on the\ninformation that a submitter provided\ndue to the unavailability of\ncorroborating information.\nBased on the validation procedures in\nuse by the LOU responsible for the\nFacets record, the information supplied by the\nregistrant can be partially corroborated\nenumeration PARTIALLY_CORROBORATED CY Public authoritative sources, while\n- some of the record is dependent upon\nthe information that the registrant\nsubmitted, either due to conflicts with\nauthoritative information, or due to data\nunavailability.\nBased on the validation procedures in\nuse by the LOU responsible for the\nenumeration FULLY_CORROBORATED ~ccord: there is sufficient information\n- contained in authoritative public sources\nto corroborate the information that the\nsubmitter has provided for the record.\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 146 of 152\n","contentLength":1252,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.944Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1\n3, LE|\n2.3.108. Attribute lei:OtherEntityNameType / @type\nType of alternative name for the legal entity.\nlei:EntityNameTypeEnum\nuse required\nRegistered name of the entity in an\nenumeration ALTERNATIVE_LANGUAGE_LEGAL_NAME >/ 1e\"native language in the legal\njurisdiction in which the entity is\nregistered.\nenumeration PREVIOUS_LEGAL_NAME A primary legal name previously\n- used by this entity.\nA \"trading as\", \"brand name\" or\n\"operating under\" name currently\nenumeration TRADING_OR_OPERATING_NAME used by this entity in addition to,\nbut not replacing, the (primary)\nlegal, official registered name.\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 147 of 152\n","contentLength":696,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.944Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1\n3, LE|\n2.3.109. Attribute lei:TransliteratedOtherEntityNameType / @type\nType of alternative name for the legal entity.\nlei:TransliteratedEntityNameTypeEnum\nuse required\nLegal name of the entity\ntransliterated to ASCII\nenumeration PREFERRED_ASCII_TRANSLITERATED_LEGAL_NAME characters, provided by\nthe entity for this\npurpose.\nLegal name of the entity\ntransliterated to ASCII\nenumeration AUTO_ASCII_TRANSLITERATED_LEGAL_NAME characters, auto-\ntransliterated by the\nmanaging LOU.\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 148 of 152\n","contentLength":577,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.945Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1\nS LE\n2.3.110. Attribute lei:OtherAddressType / @type\nThe type of address represented by this otheraddress instance.\nlei:AddressTypeEnum\nuse required\nRegistered address of\nthe entity in the legal\nenumeration ALTERNATIVE_LANGUAGE_LEGAL_ADDRESS Jurisdiction, in an\n- alternative language\nused in the legal\njurisdiction.\nAddress of the\nheadquarters of the\n. entity, in an\nenumeration ALTERNATIVE_LANGUAGE_HEADQUARTERS_ADDRESS .\nalternative language\nused in the legal\njurisdiction.\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 149 of 152\n","contentLength":577,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.946Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"- 000_00000]\nLElI Common Data File format V2.1 @ LEl\n2.3.111. Attribute lei:TransliteratedOtherAddressType / @type\n\nType of alternative name for the legal entity.\n\nlei:TransliteratedAddressTypeEnum\n\nuse required\nRegistered\naddress of\nthe entity in\nthe legal\njurisdiction,\n\nenumeratio transliterate\n\nN AUTO_ASCII_TRANSLITERATED_LEGAL_ADDRESS d to ASCII\ncharacters,\nauto-\ntransliterate\nd by the\nmanaging\nLOU.\nAddress of\nthe\nheadquarter\ns of the\nentity,\n\nenumeratio transliterate\n\nN AUTO_ASCII_TRANSLITERATED_HEADQUARTERS_ADDRESS d to ASCII\ncharacters,\nauto-\ntransliterate\nd by the\nmanaging\nLOU.\n\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 150 of 152\n","contentLength":661,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.946Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"- ]\nLEI Common Data File format V2.1 @ LEl\n\n \n \n \n\n\n\n\n\n\n\n\n \n\n\n\n\n\n \n\n\n\n\n \n\n\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 16 of 152\n","contentLength":1247,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.947Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"- 000_00000]\n. =\"\n\nLElI Common Data File format V2.1 3 LEl\nRegistered\naddress of\nthe entity in\nthe legal\n\nenumeratio jurisdiction,\n\nN PREFERRED_ASCII_TRANSLITERATED_LEGAL_ADDRESS transliterate\nd to ASCII\ncharacters,\nprovided by\nthe entity for\nthis purpose.\nAddress of\nthe\nheadquarter\ns of the\n\nenumeratio PREFERRED_ASCII_TRANSLITERATED_HEADQUARTERS_ADDRE entlty.,\n\nN ss transliterate\nd to ASCII\ncharacters,\nprovided by\nthe entity for\nthis purpose.\n\nPublic\n\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 151 of 152\n","contentLength":517,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.947Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1\n,LE|\n2.3.112. Attribute lei:AssociatedEntityType / @type\nThe type of association represented by this AssociatedEntity instance.\nlei:AssociatedEntityTypeEnum\nuse required\nenumeration EUND EAMILY Thg Iegal entity is a fund, and the associated\n- entity is the manager of the fund.\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 152 of 152\n","contentLength":378,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.947Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"- ]\nLEI Common Data File format V2.1 @ LEl\n\n\n\n \n\n\n\n\n\n \n\n\n\n\n\n\n\n\n\n\n \n\n\n\n\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 17 of 152\n","contentLength":1101,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.947Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"]\nLEI Common Data File format V2.1 @ LEl\n\n \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 18 of 152\n","contentLength":1054,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.947Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1 3' LEl\n\n\n\n\n \n \n \n \n \n\n\n\n\n\n\n\n\n\n \n \n \n\n\n\n\n\n\n \n\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 19 of 152\n","contentLength":1220,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.947Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1 3' LE|\n\n\n\n\n\n\n\n\n\n\n\n\n \n \n\n\n\n\n\n\n\n\n\n\n\n\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 20 of 152\n","contentLength":1092,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.947Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"]\n\nLEI Common Data File format V2.1 @ I_E|\n2.3.5. Element lei:LEIHeaderType / 1ei:FileCONTENT......c..eevviieecciie ettt se e eree e eeee s 38\n2.3.6. Element lei:LEIHeaderType / lei:DeltaStart ........ccccevieeeceeeesieerceee e eecesivie e eeste s seree e eeeeeeee 39\n2.3.7. Element lei:LEIHeaderType / lei:RecordCount .........ccceeecveeeiiiieiccieeecieccsivieeeeeesvneessnee e eeneennn 40\n2.3.8. Element lei:LEIHeaderType / Iei:NeXtVersion........cccccceeeceeeiciieeeceee e eceeeeeieeessine e seeesneneanen 41\n2.3.9. Element lei:LEIHeaderType / Iei:EXtENSION .....ccccviieciie et sie e rae e sve e nnne e 82\n2.3.10. Element lei:LEIData / |€i:LEIRECOIS .....vvveveeiiieiiiiiieeiietiee e eeevierveee e e ee e e s ssnnenneneeee 43\n2.3.11. Element lei:LEIRecordsType / 1€i:LEIRECOId .......oeeceeeeviiiceeie et 84\n2.3.12. Element lei:LEIRecordsType / 1ei:EXtENSION.......ueeiciee et ettt rvee e eeeeesene e 45\n2.3.13. Element lei:LEIRECOrdTYPE / I€I:LEl ...cccvvieeie ettt stte s srae e eene e B0\n2.3.14. Element lei:LEIRecordType / [€1:ENtity.....cccceeeceeiiiie ettt e sree e eene e B\n2.3.15. Element lei:EntityType / lei:LegalName.......ccccccuviieiiee et eree e 48\n2.3.16. Element lei:EntityType / lei:OtherEntityNames.......ccccccveeevieercceee e eevee e 49\n2.3.17. Element lei:OtherEntityNamesType / lei:OtherEntityName..........cccceevvveecceeeesiieeeeceeeeenenn 50\n2.3.18. Element lei:EntityType / lei:TransliteratedOtherEntityNames ........ccccccecevveeeeeccveeeceeceeneeenn 51\n2.3.19. Element lei:TransliteratedOtherEntityNamesType / lei:TransliteratedOtherEntityName ....52\n2.3.20. Element lei:EntityType / 1ei:LegalAddress ........ccceevieeceeieiciecceeeestieecreeeeeeesstae e eeeesseaeaeees D3\n2.3.21. Element lei:AddressType / lei:FirstAddressLing ........cccccveeecveeeciireiiieeeceieeesieeeeeessvveasveeenns D4\n2.3.22. Element lei:AddressType / lei:AddressNUMbBETr.........cccccveiiiieeeieiescieeccreee e esstee e eeeessiae e DD\n2.3.23. Element lei:AddressType / lei:AddressNumberWithinBuilding ...........cccccooeeeeeeeiieeeecciinen.n.. 56\n2.3.24. Element lei:AddressType / 1€i:MailROUTING ......c..ceevieeeciieiiieeceee e esivee e e svte e ssvaeeseeeaeees D7\n2.3.25. Element lei:AddressType / lei:Additional AddressLing.........cccceeeeeeevieeececcieeeeccciieeeeeeciiieee e 38\n2.3.26. Element lei:AddressType / 1€1:City ... .cciviiiiiciee ettt ee s s stv e eveeestte s sraeesvneaenes DO\n2.3.27. Element lei:AddressType / 18i1:REZION ......cccuveeecieeiicie et svvee e e srte e srae e eeeeeenns B0\n2.3.28. Element lei:AddressType / 1€1:COUNTIY .....cccvieiiieeciie et eeeectie e sve e e s srae s eeeeesseaeenns O\n2.3.29. Element lei:AddressType / 1€i:POStalCode .......ccuuiiivieecciieiiie e rtae e ee e seae s B2\n2.3.30. Element lei:EntityType / lei:HeadquartersAddress........cccceeeveeeeeeeceveeeeeecceieeeeeceeeeeeeeeeneeeennn 63\n2.3.31. Element lei:EntityType / 1€i:0therAddresses......cccvvieiiieecceieceieessree e e esite e eeeeestveaseeeeenns B4\n2.3.32. Element lei:OtherAddressesType / |ei:0therAddress.........ccceeecceeesiieecciveeeceeessieeeeeeessiee e 65\n2.3.33. Element lei:EntityType / lei:TransliteratedOtherAddresses .......ccccoveeeeeecveeeeccciveeeececvvveeen... 66\n2.3.34. Element lei:TransliteratedOtherAddressesType / lei:TransliteratedOtherAddress...............67\n2.3.35. Element lei:TransliteratedAddressType / lei:FirstAddressLine........cccccccvveeeveeeiiieeccceeeeeenenn.. 69\n2.3.36. Element lei:TransliteratedAddressType / lei:AddressNumber ..........cccccveeeceveeviieecccveeeennnn. 70\n2.3.37. Element lei:TransliteratedAddressType / lei:AddressNumberWithinBuilding ...................... 71\n\nPublic\n\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 3 of 152\n","contentLength":3704,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.947Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1 3' LE|\n\n\n \n\n\n\n\n\n\n\n\n \n\n\n\n\n \n \n\n\n\n\n \n \n \nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 21 of 152\n","contentLength":1137,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.947Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"]\nLEI Common Data File format V2.1 @ LEl\n\n\n\n\n \n \n \n \n \n \n \n \n \n \n \n\n\n\n\n \n \n \n \n\n\n\n\n\n \n\n\n\n\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 22 of 152\n","contentLength":1470,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.947Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"]\nLEI Common Data File format V2.1 @ LEl\n\n\n\n\n\n\n\n \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n \n\n\n\n\n\n\n\n\n\n1.7. Release Notes\n1.7.1. Version 2.1\n® Cardinality changes:\nOtherValidationAuthority was {0,1} andisnow {1,1}.\n* Corrections / Bug fixes:\n= Missing Extension added (back) to LETHeader.\n= New or changed elements:\n= Additional optional Extension added to LEIRecords.\n= Documentation notes:\n* Replaced \"RACL\" by \"RAL\" in documentation.\n* Replaced \"Registration Authorities Code List\" by \"Registration Authorities List\" in\ndocumentation.\nVersion 2.0\n® Cardinality changes:\n\" Header wWas {0,1} andisnow {1,1}.\n\" ContentDate was {0,1} andisnow {1,1}.\n\" FileContent was {0,1} andisnow {1,1}.\n\" RecordCount wWas {0,1} andisnow {1,1}.\n= New or changed elements:\n= Added otherRegistrationAuthorityID element to capture interim free-text\nregistration authority information in the process of transition to a RAL entry.\n* Added otherLegalForm element to capture interim free-text legal form information\nin the process of transition to an ELF standard code.\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 24 of 152\n","contentLength":1235,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.947Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"]\nLEI Common Data File format V2.1 @ I_E|\n= Added TransliteratedotherEntityNames and TransliteratedOtherAddresses.\nThese contain the name and address types dealing with transliteration, and their\ncharacter content is now validated by the XML schema.\n\n= Added EntityCategory.\n\n= AddedvalidationAuthority\n\n= Added othervalidationAuthorities.\n\nu BusinessRegisterEntityIDrepbcedbyRegistrationAuthority\n\n\" Token500Type replaced by Tokenized500Type, has minimum length of one\ncharacter and may not contain any of: the carriage return (#xD), line feed (#xA) nor\ntab (#x9) characters, shall not begin or end with a space (#x20) character, or a\nsequence of two or more adjacent space characters.\n\n= All elements in the 1ei: namespace with base datatype xs:dateTime now strictly\nvalidate according to the LEIDateTimeProfile datatype. This enforces the\nrestrictions specified in the LEI-CDF V1.0 documentation.\n\n= Added optional addressNumber.\n\n* Added optional rddressNumberWithinBuilding.\n\n= Added optional MailRouting address field; an optional free text address line to hold\ncontent from other address lines containing explicit routing information (presence\nindicates that this address is a routing / \"care of\" address).\n\n\" Replaced Linel by FirstAaddressLine and Line2 etc. by AdditionalAddressLine.\nThe order of the content of these elements follows the order specified by the XML\nrepresentation.\n\n= The value of Recordcount can now only be equal to or greater than zero.\n\n= New or changed attributes:\n\n® Updated xm1:1ang to specify use of the latest RFC from IETF BCP 47 (previously RFC\n\n4646; now RFC 5646 at last schema update).\n* New or changed enumerated values:\n\n* Following enumerations now validate strongly (only the specified values are allowed\nat a schema validation level; one element with a non-standard value cause the whole\nLEI data to fail validation):\n® FileContentEnum.\n\n\" EntityStatusEnum.\n\" EntityExpirationReasonEnum.\n® RegistrationStatusEnum.\n¥ EntityNameTypeEnumn.\n\" AddressTypeEnum.\n\" AssocilatedEntityTypeEnumn.\n® vValidationSourcesEnum.\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 25 of 152\n","contentLength":2127,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.947Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1 ‘@, LE|\n* Following enumeration elements now validate by format (only values with the\ncorrect pattern of characters are accepted; conversely, however, some schema-valid\ncharacter combinations may not be registered allowed values):\n\" RegistrationAuthority.\n\" LegalForm.\n\" BusinessRegisterEnum replaced by RegistrationAuthorityEnum.\n\" COU DELTA PUBLISHED replaced by GLEIF DELTA PUBLISHED.\n\" COU_FULL PUBLISHED replaced by GLEIF FULL PUBLISHED.\n* OTHER_LEGAL replaced by ALTERNATIVE LANGUAGE LEGAL NAME.\n* Added PREVIOUS LEGAL NAME OtherEntityName type.\n* Added TRADING OR OPERATING NAME OtherEntityName type.\n= Added TransliteratedOtherEntityNames types:\nPREFERRED ASCII TRANSLITERATED LEGAL NAME,\nAUTO ASCII TRANSLITERATED LEGAL NAME.\n= Added TransliteratedotherAddress types:\nAUTO ASCII TRANSLITERATED LEGAL ADDRESS,\nAUTO ASCII TRANSLITERATED HEADQUARTERS ADDRESS,\nPREFERRED ASCII TRANSLITERATED LEGAIL ADDRESS,\nPREFERRED ASCII TRANSLITERATED HEADQUARTERS ADDRESS.\n= Documentation notes:\n= Replaced \"pre-LOU\" by \"LOU\" in documentation.\n= Renamed all enumeration elements, updating suffix \"Enum1. 0\" to \"Enum\", indicating\nthat these are the definitive enumerated values.\n1.7.3. Version 1.0\nThe first release. Please find the published specification of LEI-CDF V1.0 at\nhttps://www.gleif.org/content/2-about-lei/5-common-data-file-format/lou-20140620.pdf\n1.8. Change Management\nChanges to this standard that affect the data schema SHALL be made by approval and\npublication of a new version of this document. A new version SHALL be one of the following:\n1.8.1. Errata Version\nAn errata version makes corrections to the normative content of the standard (excluding\ncorrections which would change the data schema) and/or makes changes to non-normative\ncontent such as explanatory material. An errata version does not change the XML schema\ndefinitions, only the documentation parts, and so does not affect the interoperability of\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 26 of 152\n","contentLength":2026,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.948Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1 ‘@ LE|\n~?\n\nsystems implementing the standard. An errata version is indicated by incrementing the third\nversion number; e.g., 1.0t0 1.0.1, or 1.0.1 to 1.0.2.\n1.8.2. Minor Version\nA minor version may include all changes permitted in an errata version, and in addition adds\none or more data elements and/or adds one or more codes to a code list (“enum” data\ntype). A minor version changes the XML schema. Minor version changes to schema MUST\nprovide for forward and backward compatibility. This allows existing implementations to\ncontinue to interoperate even if they are using different minor versions. A minor version is\nindicated by incrementing the second version number; e.g., 1.0to 1.1 or 1.1.3 to 1.2.\n1.8.3. Major Version\nA major version may make any change at all, including incompatible changes to the XML\nschema. Major version changes to schema require that the new version uses a different XML\nnamespace. This requires existing implementations to separately understand both the old\nand new versions during a period of transition. A major version is indicated by incrementing\nthe first version number; e.g., 1.1 to 2.0.\nThe release of a new minor or major version shall always be accompanied by a transition\nplan for LOUs and GLEIF, to ensure a smooth and time-bounded migration to the new\nversion.\n1.8.4. Minor Version Changes to the XML Schema\nA minor version may introduce new XML elements and/or adds one or more codes to a code\nlist (“enum” data type). Minor version changes to schema SHALL be made as specified\nbelow, in order to achieve forward and backward compatibility.\nForward compatibility means that an LEI Data File which is valid according to the older\nversion’s schema is also valid according to the newer version’s schema.\nBackward compatibility means that an LEI Data File which is valid according to the newer\nversion’s schema is also valid according to the older version’s schema.\nNew data elements may be added at pre-defined extension points within the schema, each\nwith an optional XML element NextVersion. New data elements are always added within a\n\nPublic\n\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 27 of 152\n","contentLength":2183,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.948Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"]\nLEI Common Data File format V2.1 @ LEl\n\nNextVersion element. When a minor version adds a new data element to a Nextversion\n\nelement, a new Nextversion element is also added inside the previously added\n\nNextVersion element, to accommodate additional data elements in subsequent minor\n\nversions. Each successive NextVersion element set is contained directly within the previous\n\nminor version's NextVersion set.\n\nAs can be seen from the full XML schema presented here, the following rules SHALL be\n\nobserved to ensure forward and backward compatibility:\n\n= The initial XSD declaration for a Nextversion element SHALL use the element name\n\"NextVersion\", XML data type \"lei:NextVersion1Type\" and cardinality optional, unique\n{0,1}. The XML data type allows a sequence of any elements, each of cardinality optional,\nrepeatable (unbounded) and with lax content processing, but in the target namespace.\n\n= The minOccurs declaration on the Nextversion element allows it to be omitted in files\nconforming to the first minor version. The schema wildcard xsd:any allows for forward\ncompatibility: a file conforming to a new minor version still validates in the old version\nbecause the wildcard matches any new elements introduced in the new minor version.\n\n* New elements SHALL be introduced in a subsequent minor version by modifying the\ndeclaration for the above type declaration as follows:\n\n* Asequence of the new elements introduced in the previous version.\n\n\" Asubsequent NextversionN element where N is an index number starting at 1 and\nincremented by 1 with each minor version.\n\n* Each new element SHALL be declared minOccurs=\"0\", to ensure backward compatibility:\na file conforming to the old version still validates in the new version because the new\nschema does not require the presence of elements not defined in the old version. If a\nnew element is mandatory for conformance to the new version, this MUST be enforced\noutside schema validation.\n\n= The new definition of the Nextversion element SHALL include a declaration of an inner\nNextVersion element, as illustrated above, to provide for additional elements in\nsubsequent minor versions. The nesting of Nextversion elements is required to satisfy\nthe “unique particle attribution” constraint of XSD 1.0.\n\n* Each code list (Enum types) is implemented in the XML schema simply as the XSD string\ndata type. This provides for forward compatibility because the schema for an older\nminor version will validate any string, including codes defined in newer minor versions.\nThe schema for each minor version includes the list of valid codes for that minor version\nas a documentation annotation to the type declaration for each Enum type.\n\n1.8.5. Major Version Changes to the XML Schema\n\nA major version may make any change to the XML schema whatsoever, including\n\nincompatible changes.\n\nA schema introduced in a new major version SHALL use an XML namespace URI that is\n\ndifferent from the XML namespace URI defined in any other major version of this standard.\n\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 28 of 152\n","contentLength":3075,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.948Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1 ‘@ LE|\n\\I\nThe namespace URI for a new major version SHOULD be the same as the namespace URI\nspecified in this standard, with the year at the end changed to the year in which the new\nmajor version is introduced. If more than one major version is introduced in the same year, a\nletter “a”, “b”, “c”, etc., may be appended to the year as needed.\nA new major version MUST be accompanied by an implementation plan which explains how\nimplementations will make the transition from the old major version to the new major\nversion. Generally speaking, such a plan typically provides for a period of transition in which\nan implementation capable of receiving the new major version is required to also receive\nthe old major version.\n2. Abstract Data Content\nThis section specifies the abstract data content of a data file conforming to this standard. A\ndata file conforming to this standard SHALL consist of:\n= An LEIHeader.\n= Zero or more LElI Data Records.\n© [] lei:LEIData\no\n. .\n@ o\n2.1. LEI File Header\nThe LEI File Header describes the context for the LEI Data Records contained in the main\nbody of the file. The header exists to answer such questions as where the data came from,\nwhen it was collected into this file, etc. The content of the header SHALL NOT be required to\ninterpret the data content of any LEI Data Record; each LEI Data Record is self-contained.\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 29 of 152\n","contentLength":1458,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.948Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1 ‘3 LE|\nN’\n(Contemwate )\n(Type [ leitEateTmeprofie )\nOriginator ®\nType | lei:LEIType\nFileContent |\n(Type [1eiFieConentenum )\nDeltaStart\no Type | lei:LEIDateTimeProfile ©\n(Type [ xs monNegativeinteger )\nNextVersion ®\nType | lei:LEIHeaderNextVersionType\nExtension @\nType | lei:ExtensionType\n2.2. LEI Data Record\nAn LEI Data Record describes a single LEI registration. Each LEI Data record in a file\nconforming to this standard SHALL include data elements as described below:\n® [ ] lei:LEIRecordType\nR S\n(Type | lei-LEType\n©\n©\n& ©\nNextVersion ®\nType | lei:LEIRecordNextVersionType\nExtension ®\nType | lei:ExtensionType\n2.2.1. LEI\nThe I1SO 17442-compliant LEI of the legal entity described by this LElI Data Record. The LEl is\nassigned by the LOU.\nA value of type LEIType in a file conforming to this standard SHALL be a 20-character Legal\nEntity Identifier conforming to ISO 17422. Conformance to 1SO17442 includes having correct\ncheck digits.\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 30 of 152\n","contentLength":1038,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.948Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"]\n\nLEI Common Data File format V2.1 @ I_E|\n2.3.38. Element lei:TransliteratedAddressType / lei:MailRoUting........ccccevcvveevciveeccereicie e eiie e 72\n2.3.39. Element lei:TransliteratedAddressType / lei:AdditionalAddressLine .........cccccevveeecveeennnnn. 73\n2.3.40. Element lei:TransliteratedAddressType / 1€i:City ..cceevviieecceiecieeeeee e e, 74\n2.3.41. Element lei:TransliteratedAddressType / I€i:REgION ......ccoevvveeeeeeciieeiieieceeecvie e eeee e 75\n2.3.42. Element lei:TransliteratedAddressType / 1ei:CouNtry ........ccceeeeveeeciieisiieeceee e eereeeeieenn 70\n2.3.43. Element lei:TransliteratedAddressType / lei:PostalCode .......cccceeecuveeevivieeceeeesieececeeeeeennnnn 77\n2.3.44. Element lei:EntityType / lei:RegistrationAuthority.........ccccevveeeeiciiiieee e 78\n2.3.45. Element lei:RegistrationAuthorityType / lei:RegistrationAuthorityID ........cc.cccccvveeecrveeenen. 79\n2.3.46. Element lei:RegistrationAuthorityType / lei:OtherRegistrationAuthorityID.......................... 80\n2.3.47. Element lei:RegistrationAuthorityType / lei:RegistrationAuthorityEntityID.......................... 81\n2.3.48. Element lei:EntityType / lei:LegalJurisdiCtion .........ccccecceieiiiieecceee e 82\n2.3.49. Element lei:EntityType / 1ei:EntityCategOry....cccuiiivie e cctie et sste et rrae e e seee e 83\n2.3.50. Element lei:EntityType / 1€i:LegalFOrm .......cccoovvieeceie et s O\n2.3.51. Element lei:LegalFormType / lei:EntityLegalFormCode.......cc.c..cceecvvreieecicieeeeccciieeceeceeee e 85\n2.3.52. Element lei:LegalFormType / lei:OtherLegalForm ........cccceeviieecciieccieeeccrie et e, 80\n2.3.53. Element lei:EntityType / lei:AssoCiatedENtity.......ccccvveecieeiiiiciceie e eree e 87\n2.3.54. Element lei:AssociatedEntityType / lei:AssociatedLEl .........cccccceveeeeiiiiiiieeceeesieeeceee e, 88\n2.3.55. Element lei:AssociatedEntityType / lei:AssociatedEntityName.........ccccceeveeeeeecineeeececiinee.n.. 89\n2.3.56. Element lei:EntityType / 1ei:EntityStatus ...ccceeeevieieiieeciee e eeeeesite e enee e eeeeeee 90\n2.3.57. Element lei:EntityType / lei:EntityExpirationDate .......c.ccccececvveeeeecivieeeeeceie e eeeeeee e 91\n2.3.58. Element lei:EntityType / lei:EntityEXpiratioNREASON ........coeevveiieeciiieeeceie e eeeee e 92\n2.3.59. Element lei:EntityType / 1€i:SUCCESSOrENLILY ..occccvviieiiiiie e eeeee e 93\n2.3.60. Element lei:SuccessorEntityType / 1€i:SUCCeSSOILEl ........cccovveecuriiiiivieeceececie e eceeeeciie e ennn. 94\n2.3.61. Element lei:SuccessorEntityType / lei:SuccessorEntityName.......ccccceeeeeccvveeeeecceeeececccieee e 95\n2.3.62. Element lei:EntityType / 1ei:NeXTVErsioN .......ccccviiiiieeceie et e stvee e stte s srae e eene e 90\n2.3.63. Element lei:LEIRecordType / [ei:Registration .........cccceeceeeeeiiieicciee e csirie e eevee e eneeeen 97\n2.3.64. Element lei:RegistrationType / lei:InitialRegistrationDate ........c.ccccovvrevveeecceeeesiieeeccree e, 98\n2.3.65. Element lei:RegistrationType / lei:LastUpdateDate ........cccccvvevceeeeciieensiiie e e eeeee e 99\n2.3.66. Element lei:RegistrationType / lei:RegistrationStatus........cccceeeeeecivreeecccciieeeeecciieeeeceeee.... 100\n2.3.67. Element lei:RegistrationType / lei:NextRenewalDate ........cccccccveeviieercrreescieecsieeeeeee e 102\n2.3.68. Element lei:RegistrationType / lei:ManagingLOU.........ccccevvveeeceeesciieeciceeeeieeecsieeeeeeee e 103\n2.3.69. Element lei:RegistrationType / lei:ValidationSources.........c.cccccovevvveeccceeessieeecceeeesieaneen... 104\n2.3.70. Element lei:RegistrationType / lei:ValidationAuthority.........ccccocevviieiiiiecciiiciie e 105\n\nPublic\n\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 4 of 152\n","contentLength":3634,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.948Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1 ‘%' LEl\n2.2.2. Entity\nAttributes describing the legal entity itself. The Entity data is supplied by the legal entity,\nand recorded and published by the LOU.\n© [] lei:EntityType\n©\nOtherEntityNames ®\nType | lei:OtherEntityNamesType\nTransliteratedOtherEntityNames ®\nType | lei:TransliteratedOtherEntityNamesType\no\no\nOtherAddresses ® .\nType | lei:OtherAddressesType © [] lei:AddressType\nTransliteratedOtherAddresses ® ® @ Attributes\nType | lei:TransliteratedOtherAddressesType\nR, . (Frdgresstine )\nType [ leiRegistrationAuthorityType |\n@ 5 Legaljurisdiction ® AddressNumber ®\nType | leijJurisdictionCodeType Type | lei:Tokenized500Type\nEntityCategory ® AddressNumberWithinBuilding\nB Cemie TType [ leiTokenizeds00Type |\nLegalForm ®\nType | lei:LegalFormType MailRouting ®\nType | lei:Tokenized500Type\nAssociatedEntity ®\nType | lei:AssociatedEntity Type o 0..3 | AdditionalAddressLine ®\nType | lei:Tokenized500Type\n(Evsaws o |\n(ciy ]\n®\nEnivraiondme |\nType | lei:LEIDateTimeProfile\nRegion ®\nEntityExpirationReason ® Type | lei:RegionCodeType\nType | lei:EntityExpirationReasonEnum\no\ney (Type | lei:CountryCodeType )\nSl wSocsssortntiyiyss) O Type | leizCountryCodeType\nNextVersion ® PostalCode ®\nType | lei:EntityNextVersionType Type | lei:Tokenized500Type\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 31 of 152\n","contentLength":1345,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.948Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1 ‘3 LEl\nN’\n2.2.3. Registration\nAttributes describing the registration of this LEI with an LOU. The Registration datais\nmaintained by the LOU.\n© [ ] lei:RegistrationType\no\no\no\no\n© ®\n&) aype [eitermype\nValidationSources ®\nType | lei:ValidationSourcesEnum\nValidationAuthority ®\nType | lei:ValidationAuthorityType\nOtherValidationAuthorities ®\nType | lei:OtherValidationAuthoritiesType\nNextVersion ®\nType | lei:RegistrationNextVersionType\n2.2.4. Extension\nThe optional Extension section of an LEI record may be used to include additional data not\ndefined in this standard. This may include data specific to an LOU, data specific to a\npublisher of LE|l data, and so on.\nFor example, an LOU may use Extension to publish additional data elements it collects as\npart of registration.\nThe following rules MUST be observed:\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 32 of 152\n","contentLength":911,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.948Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"]\nLEI Common Data File format V2.1 @ LEl\n\ne Each XML element included in the content of the Extension element SHALL be in\nan XML namespace that is not null and not equal to the XML namespace of the LEI\nData File as specified in this standard.\n\ne The XML namespace for an Extension element SHALL be a namespace which the\ncreator of the extension element exclusively or jointly controls, or from which the\ncreator re-uses existing elements and their definitions, e.g. a namespace derived\nfrom the Internet Domain Name of the creator, a namespace agreed upon by a group\nof trading partners, etc.\n\ne AnExtension element SHALL NOT be defined in such a way as to require the\nrecipient of the file to recognize the Extension element in order to interpret the\ndata elements specified in this standard. A recipient of the file MUST be able to\nignore all Extension elements and still interpret the standard content correctly.\n\ne Arecipient of a data file conforming to this standard SHALL NOT reject a file solely\nbecause it contains extensions not understood by the recipient. A recipient MUST be\nprepared to accept a file containing extensions and ignore any it does not\nunderstand, provided that the file complies to this standard.\n\n2.3. Data Element Reference\n\nOn the following pages, the data elements, attributes and datatypes are listed, one per page.\nPublic\n\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 33 of 152\n","contentLength":1416,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.948Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1 ‘% LE|\nN\n2.3.1. Element lei:LEIData\nContains the file structure for the whole LEI data records file as specified in the XML\ndatatypes below.\nlei:LEIData\ncontent complex\n\n{1l,1}\n{1,1}\n\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 34 of 152\n","contentLength":432,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.948Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1 ‘; 3' LEl\n2.3.2. Element lei:LEIData / lei:LEIHeader\nContains the file upload information for this LEI data file.\nlei:LEIHeaderType\ncontent complex\n\n{1,1}\n{0,1}\n{1,1}\n{0,1}\n{1,1}\n{0,1}\n{0,1}\n\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 35 of 152\n","contentLength":617,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.948Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEl Common Data File format V2.1 ‘; 3' LEl\n2.3.3. Element lei:LEIHeaderType / lei:ContentDate\nThe date and time as of which the data contained in the file is valid.\nlei:LEIDateTimeProfile\ncontent simple\n(AM\\T* HIANT*(\\((\\d){1,31){0,1}))(Z] \\+([01][O-\npattern 9]|2[0-3]):([0-5][0-9]) | -([01][0-9] | 2[0-3]):([O-\n5][(0-9]))\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 36 of 152\n","contentLength":389,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.949Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"]\n: 2y\nLEI Common Data File format V2.1 @ LEl\n2.3.4. Element lei:LEIHeaderType / lei:Originator\nThe LEI of the entity that created the content of this file.\nlei:LEIType\ncontent simple\nminOccurs 0\nminLength 20\nmaxLength 20\npattern ([0-9A-Z]{18}[0-9]{2})\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 37 of 152\n","contentLength":320,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.949Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1 ‘@ LEl\n\\I\n2.3.5. Element lei:LEIHeaderType / lei:FileContent\nA code describing the content of this LEI data file.\nlei:FileContentEnum\ncontent simple\nThe file contains all LEl Data Records published by\n. an LOU (all LEI Data Records for which the LOU is\nED\nenumeration LOU_FULL_PUBLISH the ManagingLou) as of the date/time the file is\ncreated.\nThe file contains those LEI Data Records published\nby an LOU (all LEI Data Records for which the LOU\nenumeration LOU_DELTA_PUBLISHED s the ManagingLou) which are new or changed\nsince the peltastart date specified in the\nheader, as of the date/time the file is created.\nThe file contains all LEl Data Records published by\nenumeration GLEIF_FULL_PUBLISHED GLEIF (including all LEI Data Records from all\nLOUs) as of the date/time the file is created.\nThe file contains those LEI Data Records published\nby GLEIF (including all LEI Data Records from all\nenumeration GLEIF_DELTA_PUBLISHED LOUs) which are new or changed since the\nDeltastart specified in the header, as of the\ndate/time the file is created.\nenumeration QUERY_RESPONSE The fll.e cgntams records matching criteria\nspecified in a query.\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 38 of 152\n","contentLength":1237,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.949Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"=\"\nLEI Common Data File format V2.1\n9 LE\n2.3.6. Element lei:LEIHeaderType / lei:DeltaStart\nThe date and time of the baseline relative to which this file contains new or changed LEI\ndata records.\nlei:LEIDateTimeProfile\ncontent simple\nminOccurs 0\n(IA\\T* AT\\ ((\\d){2,31){0,1})) (2| \\+([01][O-\npattern 9]]2[0-3]):([0-5][0-9]) | -([01][0-9] | 2[0-3]):([O-\n5][0-9]))\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 39 of 152\n","contentLength":428,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.949Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1\nS LE\n2.3.7. Element lei:LEIHeaderType / lei:RecordCount\nThe number of LEI data records in the file. Can be a positive whole (integer) number, or zero\n(0).\nxs:nonNegativelnteger\ncontent simple\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 40 of 152\n","contentLength":291,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.949Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"]\n\nLEI Common Data File format V2.1 @ I_E|\n2.3.71. Element lei:ValidationAuthorityType / lei:ValidationAuthorityID ...........cccccceeevireennenn... 106\n2.3.72. Element lei:ValidationAuthorityType / lei:OtherValidationAuthorityID.............................. 107\n2.3.73. Element lei:ValidationAuthorityType / lei:ValidationAuthorityEntityID.............................. 108\n2.3.74. Element lei:RegistrationType / lei:OtherValidationAuthorities...........cccccoeeeeeecrieeeecnneee..... 109\n2.3.75. Element lei:OtherValidationAuthoritiesType / lei:OtherValidationAuthority ..................... 110\n2.3.76. Element lei:RegistrationType / lei:NexXtVersion.........cccccceeevieeecceeesciieessieeeseeessineeseeeesnnean 111\n2.3.77. Element lei:LEIRecordType / [ei:NeXtVersion .........cccceecceeeiiieeecceeessieeeseeeesieeessveeeseeeesnenean 112\n2.3.78. Element lei:LEIRecordType / [€i:EXLENSION .....cccuvveiivieeciiiecciieceeeesstieeeeeeeeieeessvee e seeeeeneneen 113\n2.3.79. Simple Type lei:LEIDateTimeProfile ........ccciuiirieiiieieeiiieeeecesiieeeeccsriieeessssiieee s ssseveeeesnsvnneeeens 114\n2.3.80. SIMple TYPE IQI:LEITYPE wovriiieeiieie ettt ettt e e ette e e etee e e s setee e s sseeaessnneesssssneeseassss 11D\n2.3.81. Simple Type lei:FileContentENUM .......cccoveiiiiii et eseieeeeeseeeeeeessveeeee e L 16\n2.3.82. Complex TYPe [€I:NAMETYPE . .uuiii et ettt s eetieee s eestieeeesesveteeesssseeeessssseessssssnneeesss L 17\n2.3.83. Simple Type 1ei:ToKenized500TYPE ...ueveiecciirieeieciiieeeeeciieeeesectieeeesesvneeesseesseeeessesseeeessssseneeeens 118\n2.3.84. Complex Type lei:OtherEntityNameTYPe .....cceecccieeriecciieeeeeeciiieeesecviieesseesveeeessesveeesssssseneneees 119\n2.3.85. Simple Type lei:EntityNameTypPeENUM ......c..uiiiiceciiie et cctvie e ceivieeeseieeee s seeeeesseeeneneees 120\n2.3.86. Complex Type lei:TransliteratedOtherEntityNameType......ccccvevvccivieieccccieeeeeeiee e 1211\n2.3.87. Complex Type lei:TransliteratedNameTyPe .....ccccveveeiciiieieeiiee e cctie e etee e e seee e e s seeeeaeees 122\n2.3.88. Simple Type lei:TransliteratedStringTyYPe ....uuiv e ccieie e ceiie e civie e eree e e eeee e e e seeeeeeees 123\n2.3.89. Simple Type lei:TransliteratedEntityNameTypeEnumM ........cccovvvevvcciieiricccieeen e ceiinenn. 127\n2.3.90. Complex TYPe |ei: AdAreSSTYPE .uii i ciieeeeccrieeeeecctiieee s eetieeeesesteeeeesesteteessessaeeessssseeesssnsssseeeens L 28\n2.3.91. Simple Type [ei:RegioNCOUETYPE......uuiiiieeciiiiieecciiieeeectieeeesestieeeesetreeeseesteeeessesseeeessssseseeeens 129\n2.3.92. Simple Type [ei:CountryCoOdETYPE .....uiiiiicciiieeeeciiieeeeeiieeeesestreeeesereeeessessseessessssseesssssseneesens 130\n2.3.93. Complex Type lei:OtherAddreSSTYPE ...cccccvvieieieciiieeeeeiiie e e e eetrieesseeeeeeeeeeeaessseeessesneenesenes 131\n2.3.94. Simple Type lei:AddressTYPEENUM ........ccccviiiiiiciiieie et cteie e eree e e s seee e e s seeeeaeees 132\n2.3.95. Complex Type lei:TransliteratedOtherAddressTYPe.....ccocvveeeeeeeeeeeeicciiiiieieeeeeeeeeeeeesesnenenn. 133\n2.3.96. Complex Type lei:TransliteratedAddressTYPE ......coccevcivvieeieeeeeeeecccccieieeie e e e e eeeescsvinneeneeeen. 134\n2.3.97. Simple Type lei:TransliteratedAddressTYPEENUM .........ccevveeeeeeeeeeeiiciciieieeeeeeeeeeeeesiivsnenens. 135\n2.3.98. Simple Type lei:RegistrationAuthorityENUM ......ccveeiiiciiiiei e eieeeee . 136\n2.3.99. Simple Type lei:JurisdictioNCOdETYPE ..ccccvirieeicciiieie ettt ee e ccctiie e settieeeeeeeeeee s ssveeeessnvaneeeees 137\n2.3.100. Simple Type lei:EntityCategoryTYPEENUM ..cciiccciiieeeccciieee s cctiee e sectieeeeeiieee s seveeeeeseeeeeeeees 138\n2.3.101. Simple Type lei:LegalFOrmMENUM .......cccoicciiiiereiciiieeeeciieeeesestieeeesetreeeesssieeeessssseeesssssseseeeees 139\n2.3.102. Complex Type lei:AssociatedENtity TYPE ....ueeveeecieericcciieee e cciiieeesciiieeeseeiieeesseeneeeeseveneeeees D40\n2.3.103. Simple Type lei:AssociatedEntity TYPEENUM .......cceviviciiiiiiciieeeecciie e ceie e seee e e seeee e 141\n\nPublic\n\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 5 of 152\n","contentLength":4028,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.949Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1 ‘3 LEl\nP\n2.3.8. Element lei:LEIHeaderType / lei:NextVersion\nA structure for adding further elements in to the LEI data file header in anticipation of a new\nversion, by nesting a series of XML elements with this content model within the\nNextVersion element, one for each new minor version of the schema, postpending a serial\nnumber (1,2,3...) to the element name upon each iteration.\nlei:HeaderNextVersionType\ncontent complex\nminOccurs 0\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 41 of 152\n","contentLength":536,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.949Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1\nS LE\n\n2.3.9. Element lei:LEIHeaderType / lei:Extension\n\nThis lei:Extension element may contain any additional elements required to extend the\n\nHeader.\n\nlei:ExtensionType\n\ncontent complex\n\nminOccurs 0\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 42 of 152\n","contentLength":299,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.950Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1 ‘% LE|\nN\n2.3.10. Element lei:LEIData / lei:LEIRecords\nContainer for all of the LEIRecord elements submitted with this file.\nlei:LEIRecordsType\ncontent complex\n\n{0,unbounded}\n{0,1}\n\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 43 of 152\n","contentLength":433,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.950Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1 ‘; 3 LEl\n4\n2.3.11. Element lei:LEIRecordsType / lei:LEIRecord\nContains all LEI reference data including details of the LEI's registration with the\nManagingLOU.\nlei:LEIRecordType\ncontent complex\nminOccurs 0\nmaxOccurs unbounded\n\n{1,1}\n{1,1}\n{1,1}\n{0,1}\n{0,1}\n\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 44 of 152\n","contentLength":594,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.950Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1\nS LE\n\n2.3.12. Element lei:LEIRecordsType / lei:Extension\n\nThis lei:Extension element may contain any additional elements required to extend the\nLEIRecords container.\n\nlei:ExtensionType\n\ncontent complex\n\nminOccurs 0\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 45 of 152\n","contentLength":314,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.950Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"]\n: 2y\nLEI Common Data File format V2.1 @ LEl\n2.3.13. Element lei:LEIRecordType / lei:LEIl\nThe I1SO 17442 compatible identifier for the legal entity described in the Entity section.\nlei:LEIType\ncontent simple\nminLength 20\nmaxLength 20\npattern ([0-9A-Z]{18}[0-9]{2})\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 46 of 152\n","contentLength":332,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.950Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1 3' LE|\n2.3.14. Element lei:LEIRecordType / lei:Entity\nThe Entity container element contains the legal entity's reference data, enabling\nidentification.\nlei:EntityType\ncontent complex\n\n{1,1}\n{0,1}\n{0,1}\n{1,1}\n{1,1}\n{0,1}\n{0,1}\n{0,1}\n{0,1}\n{0,1}\n{0,1}\n{0,1}\n{1,1}\n{0,1}\n{0,1}\n{0,1}\n{0,1}\n\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 47 of 152\n","contentLength":1306,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.950Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1\nS LE\n2.3.15. Element lei:EntityType / lei:LegalName\nThe legal name of the entity.\nlei:NameType\ncontent complex\nAttribute Type Use Annotation\nAttempting to install the relevant ISO 2- and 3-letter\nunion codes as the enumerated possible values is probably\nof(xs:language never going to be a realistic possibility. See RFC 3066 at\nxml:lang restri.ctiogn ofg \" optional http://www.ietf.org/rfc/rfc3066.txt and the IANA\n. registry at http://www.iana.org/assignments/lang-tag-\nXs:string) . . .\napps.htm for further information. The union allows for\nthe 'un-declaration' of xml:lang with the empty string.\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 48 of 152\n","contentLength":698,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.950Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1 ‘a LE|\nN\n2.3.16. Element lei:EntityType / lei:OtherEntityNames\nAn optional list of other names (excluding transliterations) for the legal entity.\nlei:OtherEntityNamesType\ncontent complex\nminOccurs 0\n\n{1,unbounded}\n\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 49 of 152\n","contentLength":480,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.950Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1\n‘%, LE|\n2.3.17. Element lei:OtherEntityNamesType / lei:OtherEntityName\nAn alternative name or representation of a name for the legal entity, excluding\ntransliterations.\nlei:OtherEntityNameType\ncontent complex\nmaxOccurs unbounded\nAttribute Type Use Annotation\ni legal\ntype lei:EntityNameTypeEnum required Typ.e of alternative name for the lega\nentity.\nAttempting to install the relevant ISO 2- and\n3-letter codes as the enumerated possible\nvalues is probably never going to be a\nrealistic possibility. See RFC 3066 at\ni : : .ietf. . h\nxml:lang unlor\\ of(xs Ianguage, optional http //WYVW ietf.org/rfc/rfc3066.txt and the\nrestriction of xs:string) IANA registry at\nhttp://www.iana.org/assignments/lang-tag-\napps.htm for further information. The union\nallows for the 'un-declaration' of xml:lang\nwith the empty string.\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 50 of 152\n","contentLength":916,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.950Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"]\n\nLEI Common Data File format V2.1 @ LEl\n2.3.104. Simple Type lei:EntityStatuUSENUM ......oocciviiii et etie e eeee e seeee e L2\n2.3.105. Simple Type lei:EntityExpirationReasonENUM .........ccccveeiiiciiiiirciiiie e e eiee e e seeee e 143\n2.3.106. Simple Type lei:RegistrationStatUSENUM ......ccccviieeiiiiieeeeccsiiecee e ssssiieee s sseveeeesssvnneeeens 144\n2.3.107. Simple Type lei:ValidationSOUrceSENUM ........ccciuieiiicciieieiicciieeeecccciie e ccciieee s seieeeeeseveeeee e 146\n2.3.108. Attribute lei:OtherEntityNameType / @TYPE ....ceevveeeceeeeiieerrieciieeestvieeeeeesineessveeesennans 147\n2.3.109. Attribute lei:TransliteratedOtherEntityNameType / @type......cccccceevvveeecveeesieesccveeenne... 148\n2.3.110. Attribute lei:OtherAddressType / @TYPE ....eeccveeevieeecieeeciieerecreeeeieeesvvaeeieeeesseeesnseeesenenns 149\n2.3.111. Attribute lei:TransliteratedOtherAddressType / @type......cccceveeecveersivieeceeeesieeseceeeeeenenn. 150\n2.3.112. Attribute lei:AssociatedEntityTYpe / @TYPEe .....ueeevvveeeceeeiiiieeeieeeestieescreeesveeessvaeeseneeesnsneans 152\n\nPublic\n\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 6 of 152\n","contentLength":1141,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.950Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1 ‘3 LE|\nN\n2.3.18. Element lei:EntityType / lei:TransliteratedOtherEntityNames\nAn optional list of ASClI-transliterated (i.e. Latin- or Romanized) representations of names\nfor the legal entity.\nlei:TransliteratedOtherEntityNamesType\ncontent complex\nminOccurs 0\n\n{1,unbounded}\n\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 51 of 152\n","contentLength":596,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.951Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1 ‘% LE|\nP\n2.3.19. Element lei:TransliteratedOtherEntityNamesType /\nlei:TransliteratedOtherEntityName\nlei:TransliteratedOtherEntityNameType\ncontent complex\nmaxOccurs unbounded\nAttr;but Type Use Annotation\ntvoe lei:TransliteratedEntityNameTypeE require Type of alternative name for the\nP num d legal entity.\nAttempting to install the relevant\nISO 2- and 3-letter codes as the\nenumerated possible values is\nprobably never going to be a\nrealistic possibility. See RFC 3066 at\nxml:lan union of(xs:language, restriction of optiona http://www.ietf.org/rfc/rfc3066.txt\ng xs:string) I and the IANA registry at\nhttp://www.iana.org/assignments/I\nang-tag-apps.htm for further\ninformation. The union allows for\nthe 'un-declaration' of xml:lang with\nthe empty string.\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 52 of 152\n","contentLength":853,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.951Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1 ‘@ LEI\n\\l\n2.3.20. Element lei:EntityType / lei:LegalAddress\nThe address of the entity as recorded in the registration of the entity in its legal jurisdiction.\nlei:AddressType\ncontent complex\n\n{1l,1}\n{0,1}\n{0,1}\n{0,1}\n{0,3}\n{1l,1}\n{0,1}\n{1l,1}\n{0,1}\n\nAttribute Type Use Annotation\nAttempting to install the relevant ISO 2- and 3-letter\nunion codes as the enumerated possible values is probably\nof(xs:language never going to be a realistic possibility. See RFC 3066 at\nxml:lang restri.ctiogn ofg \" optional http://www.ietf.org/rfc/rfc3066.txt and the IANA\n. registry at http://www.iana.org/assignments/lang-tag-\nxs:string) . . .\napps.htm for further information. The union allows for\nthe 'un-declaration' of xml:lang with the empty string.\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 53 of 152\n","contentLength":1291,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.951Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"]\n: F 28\nLEI Common Data File format V2.1 3 LEl\n2.3.21. Element lei:AddressType / lei:FirstAddressLine\nThe mandatory first address line element.\nlei:Tokenized500Type\ncontent simple\nminLength 1\nmaxLength 500\npattern \\S+( \\S+)*\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 54 of 152\n","contentLength":292,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.951Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEl Common Data File format V2.1 ;\n‘3, LE|\n2.3.22. Element lei:AddressType / lei:AddressNumber\nOptional, additional structured version of an external house number, or range of numbers,\ncontained in one of the address line elements. This could be a numeral, a letter or code\nmade up of mixed characters (e.g. 221B).\nlei:Tokenized500Type\ncontent simple\nminOccurs 0\nminLength 1\nmaxLength 500\npattern \\S+( \\S+)*\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 55 of 152\n","contentLength":475,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.951Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEl Common Data File format V2.1\n‘3, LE|\n2.3.23. Element lei:AddressType / lei:AddressNumberWithinBuilding\nOptional, additional structured version of an internal location number, or range of numbers,\ncontained in one of the address line elements.This could be a numeral, a letter or code\nmade up of mixed characters (e.g. 13) of a floor, suite or apartment within a building\nidentified e.g. by an AddressNumber element.\nlei:Tokenized500Type\ncontent simple\nminOccurs 0\nminLength 1\nmaxLength 500\npattern \\S+( \\S+)*\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 56 of 152\n","contentLength":580,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.951Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1\n,LE|\n2.3.24. Element lei:AddressType / lei:MailRouting\nOptional free text address line to hold content from other address lines containing explicit\nrouting information (this element's presence indicates that this address is a routing / \"care\nof\" address.\nlei:Tokenized500Type\ncontent simple\nminOccurs 0\nminLength 1\nmaxLength 500\npattern \\S+( \\S+)*\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 57 of 152\n","contentLength":448,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.951Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"]\n: F 28\nLEI Common Data File format V2.1 3 LEl\n2.3.25. Element lei:AddressType / lei:AdditionalAddressLine\nOne to three optional additional address line elements.\nlei:Tokenized500Type\ncontent simple\nminOccurs 0\nmaxOccurs 3\nminLength 1\nmaxLength 500\npattern \\S+( \\S+)*\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 58 of 152\n","contentLength":336,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.951Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"]\n: F 28\nLEI Common Data File format V2.1 3 LE'\n2.3.26. Element lei:AddressType / lei:City\nThe mandatory name of the city.\nlei:Tokenized500Type\ncontent simple\nminLength 1\nmaxLength 500\npattern \\S+( \\S+)*\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 59 of 152\n","contentLength":270,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.951Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"]\n: F 28\nLEI Common Data File format V2.1 3 LEl\n2.3.27. Element lei:AddressType / lei:Region\nThe (optional) 4- to 6-character ISO 3166-2 region code of the region.\nlei:RegionCodeType\ncontent simple\nminOccurs 0\nminLength 4\nmaxLength 6\npattern ([A-z]{2}-[A-20-9]{1,3})\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 60 of 152\n","contentLength":334,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.951Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1 ‘@ LE|\n~?\nLEI-CDF Version 2.1\nDocumentation last updated: 2017-03-21\n1. Introduction\nAs the Global LEI System (GLEIS) High Level Principles stipulate, the GLEIS should uniquely\nand unambiguously identify participants to financial transactions. The ISO 17442 Legal Entity\nIdentifier (LEI) standard defines the following set of attributes as the most essential\nelements of identification:\n= The official name of the legal entity as recorded in the business registry, or with the fund\nmanager for collective investment vehicles, or otherwise in the entity’s constituting\ndocuments.\n= Where applicable, the name of the business registry in which the entity was formed.\n= The identifier of the entity in the business registry.\n= The address of the headquarters of the legal entity or the address of the fund manager.\n= The address and the country of legal formation as represented in ISO 3166.\n= The date of the first LEl assignment.\n= The date of last update of the LEl set of information.\n= The date of expiry, where applicable.\n= The reason for expiry, if applicable.\n= For entities with a date of expiry, where applicable, the LEI of the entity or entities that\nacquired the expired entity.\nThe LEI Common Data File format (LEI-CDF) was proposed by the Legal Entity Identifier\nRegulatory Oversight Committee (LEI ROC) as the additional standard necessary to support\nthe GLEIS in maintaining exclusive assignment of LEls (one LEI per entity) and identifying,\nremediating data quality issues, and supporting use of the data. It is maintained and\ndeveloped as a technical standard by the Global LEI Foundation (GLEIF) with the\ncollaboration and oversight of the LEI ROC. The LEI-CDF specifies in more detail:\n= The semantic content (definitions) of the ISO 17442 attributes.\n= Some additional elements, such an indication of the status of the information, necessary\nfor effective use of the data.\n= The form the information takes at any given LOU, such that it can be made to conform to\na common standard.\nAll LOUs use this file format to publish LEls and their reference data.\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 7 of 152\n","contentLength":2174,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.951Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"]\n: 2y\nLEI Common Data File format V2.1 3 LEl\n2.3.28. Element lei:AddressType / lei:Country\nThe 2-character ISO 3166-1 country code of the country.\nlei:CountryCodeType\ncontent simple\nminLength 2\nmaxLength 2\npattern ([A-Z]{2})\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 61 of 152\n","contentLength":292,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.951Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"]\n: F 28\nLEI Common Data File format V2.1 3 LEl\n2.3.29. Element lei:AddressType / lei:PostalCode\nThe (optional) postal code of this address as specified by the local postal service.\nlei:Tokenized500Type\ncontent simple\nminOccurs 0\nminLength 1\nmaxLength 500\npattern \\S+( \\S+)*\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 62 of 152\n","contentLength":342,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.951Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1 ‘@ LEI\n\\l\n2.3.30. Element lei:EntityType / lei:HeadquartersAddress\nThe address of the headquarters of the Entity.\nlei:AddressType\ncontent complex\n\n{1l,1}\n{0,1}\n{0,1}\n{0,1}\n{0,3}\n{1l,1}\n{0,1}\n{1l,1}\n{0,1}\n\nAttribute Type Use Annotation\nAttempting to install the relevant ISO 2- and 3-letter\nunion codes as the enumerated possible values is probably\nof(xs:language never going to be a realistic possibility. See RFC 3066 at\nxml:lang restri.ctiogn ofg \" optional http://www.ietf.org/rfc/rfc3066.txt and the IANA\n. registry at http://www.iana.org/assignments/lang-tag-\nxs:string) . . .\napps.htm for further information. The union allows for\nthe 'un-declaration' of xml:lang with the empty string.\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 63 of 152\n","contentLength":1260,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.951Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1 ‘3 LE|\nN\n2.3.31. Element lei:EntityType / lei:OtherAddresses\nAn optional list of other addresses for the legal entity, excluding transliterations.\nlei:OtherAddressesType\ncontent complex\nminOccurs 0\n\n{1,unbounded}\n\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 64 of 152\n","contentLength":469,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.952Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1 ‘@ LE|\n\\l\n2.3.32. Element lei:OtherAddressesType / lei:OtherAddress\nAn alternative address for the legal entity excluding transliterations.\nlei:OtherAddressType\ncontent complex\nmaxOccurs unbounded\n\n{1l,1}\n{0,1}\n{0,1}\n{0,1}\n{0,3}\n{1l,1}\n{0,1}\n{1l,1}\n{0,1}\n\nAttribute Type Use Annotation\n. . The type of address represented by this\ntype lei:AddressTypeEnum required yp . P y\nOtherAddress Instance.\nAttempting to install the relevant ISO 2- and 3-\nletter codes as the enumerated possible values\nis probably never going to be a realistic\nunion of(xs:language possibility. See RFC 3066 at\n1 OnXstianguage, . http://www.ietf.org/rfc/rfc3066.txt and the\nxml:lang restriction of optional .\n. IANA registry at\nXs:string) . .\nhttp://www.iana.org/assignments/lang-tag-\napps.htm for further information. The union\nallows for the 'un-declaration' of xml:lang with\nthe empty string.\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 65 of 152\n","contentLength":1431,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.952Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1 ‘; 3 LEl\n4\n2.3.33. Element lei:EntityType / lei:TransliteratedOtherAddresses\nAn optional list of transliterated addresses for the legal entity.\nBusiness rules: N/A.\nlei:TransliteratedOtherAddressesType\ncontent complex\nminOccurs 0\n\n{1,unbounded}\n\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 66 of 152\n","contentLength":557,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.952Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1 ‘3' LEl\n2.3.34. Element lei:TransliteratedOtherAddressesType /\nlei:TransliteratedOtherAddress\nA transliterated version of one of the addresses for the legal entity.\nlei:TransliteratedOtherAddressType\ncontent complex\nmaxOccurs unbounded\n\n{1l,1}\n{0,1}\n{0,1}\n{0,1}\n{0,3}\n{1l,1}\n{0,1}\n{1l,1}\n{0,1}\n\nAttribut .\no Type Use Annotation\ntvoe lei:TransliteratedAddressTypeEnu require Type of alternative name for the legal\nP m d entity.\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 67 of 152\n","contentLength":1017,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.953Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"]\n. =\"\nLEI Common Data File format V2.1 3 LEl\nAttempting to install the relevant ISO\n2- and 3-letter codes as the\nenumerated possible values is\nprobably never going to be a realistic\npossibility. See RFC 3066 at\nunion of(xs:language, restriction optiona http://www.ietf.org/rfc/rfc3066.txt\nxml:lang . .\nof xs:string) I and the IANA registry at\nhttp://www.iana.org/assignments/la\nng-tag-apps.htm for further\ninformation. The union allows for the\n'un-declaration’ of xml:lang with the\nempty string.\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 68 of 152\n","contentLength":563,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.953Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1\n3, LE|\n2.3.35. Element lei:TransliteratedAddressType / lei:FirstAddressLine\nThe mandatory first address line element.\nlei:TransliteratedStringType\ncontent simple\nminLength 1\nmaxLength 500\n(\\S+O\\S+)*) & (\" 1% 1 &' INCIN) I\\N*I\\+1,1-\npattern I\\.-17101212[3]4|5]|6]|7|8]91:|;|1<|=]>|\\?|A[B|CIDI|E|FIG|H[I[J|K]L]|\nIMIN|O|P|QIR|SITIUIVIWIX]|Y|Z| _|alb]|cld|elf|g|hliljlk]IIm]|n\nlolplalrisitiulviw]x]y|z)+)\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 69 of 152\n","contentLength":500,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.953Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEl Common Data File format V2.1\n‘3, LE|\n2.3.36. Element lei:TransliteratedAddressType / lei:AddressNumber\nOptional, additional structured version of an external house number, or range of numbers,\ncontained in one of the address line elements.\nlei:TransliteratedStringType\ncontent simple\nminOccurs 0\nminLength 1\nmaxLength 500\n(\\S+(\\S+)*) & (\"% I &' IN(IN) I\\N*\\+1, ]\npattern I\\.1/1011]2]3[4]|5]6]|718]9]:1;||\\?|A|B|C|D|E|F|G|H[I]J[K|L]\nIMIN|OIP|Q|RIS|TIU[VIWIX]|Y|Z|_|alb]|c|d]|elflg|h]iljlk[IIm]|n\nlolplalris|tlulv|w]x]y]|z)+)\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 70 of 152\n","contentLength":600,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.953Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1 ‘@ LEl\n~?\n1.1. Audience for this document\nThe target audience for this standard includes:\n= All Local Operating Units (as well as candidate LOUs) of the GLEIS.\n= All users or potential users of LEI data.\n= All financial regulators who consume LEI data.\n1.2. Status of this document\nThis section describes the status of this document at the time of its publication. Later\nversions may supersede this document. The most up to date version will always be available\nfrom www.gleif.org.\nThe file format references and honors previous completed work published by the LEI ROC in\na document entitled \"LEI Data File Format 1.0” (19 June 2014; available from\nwww.leiroc.org).\n1.3. Terminology and Typographical Conventions\nThe following typographical conventions are used throughout the document:\n= ALL CAPS type is used for the special terms enumerated above.\n\" Monospace type iS used to denote programming language, UML, and XML identifiers, as\nwell as for the text of XML documents.\n1.4. Cardinalities\n* The cardinality of each element (the number of times it MUST or MAY appear in an XML\ndata file conforming to this schema) is expressed as a number range in the format\n{minimum occurrences, maximum occurrences} in the XML examples shown below the\nnotes of its containing element. This notation is equivalent to the following explanations\nin words:\n= Mandatory, unique: {1, 1} - the element MUST appear, exactly once.\n* Mandatory, repeatable: {1, unbounded} - the element MUST appear at least once. It\nmay be repeated any number of times.\n= QOptional, unique: {0, 1} - the element NEED NOT appear; it MAY appear once at\nmost.\n= QOptional, repeatable: {0, unbounded} - the element NEED NOT appear. It MAY be\nrepeated any number of times.\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 8 of 152\n","contentLength":1831,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.954Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEl Common Data File format V2.1\n‘3, LE|\n2.3.37. Element lei:TransliteratedAddressType /\nlei:AddressNumberWithinBuilding\nOptional, additional structured version of an internal location number, or range of numbers,\ncontained in one of the address line elements.\nlei:TransliteratedStringType\ncontent simple\nminOccurs 0\nminLength 1\nmaxLength 500\n(\\S+(\\S+)*) & (\"% I &' IN(IN) I\\N*\\+1, ]\npattern I\\.1/1011]2]3[4]|5]6]|718]9]:1;||\\?|A|B|C|D|E|F|G|H[I]J[K|L]\nIMINJOIP|Q|RIS|TIU[VIWIX]|Y|Z|_|albl|c|d]|elflg|h[iljlk[Im]|n]\nolplalr|sitiulv|w]x]|y]z)+)\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 71 of 152\n","contentLength":616,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.954Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1\n3, LE|\n2.3.38. Element lei:TransliteratedAddressType / lei:MailRouting\nOptional free text address line to hold content from other address lines containing explicit\nrouting information (this element's presence indicates that this address is a routing / \"care\nof\" address.\nlei:TransliteratedStringType\ncontent simple\nminOccurs 0\nminLength 1\nmaxLength 500\n(\\S+(\\S+)*) & (\" [% | &I\"INUIN) IN*[\\+], -\npattern I\\.-17101212[3]4|5]|6]|7|8]91:|;|1<|=]>|\\?|A[B|CIDI|E|FIG|H[I[J|K]L]|\nIMIN|O|P|QIR|SITIUIVIWIX]|Y|Z| _|albl|cld]|e|f|glhliljlk]I[m]|n\nlolplalrisitiulviw]x]y|z)+)\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 72 of 152\n","contentLength":666,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.954Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1\n3, LE|\n2.3.39. Element lei:TransliteratedAddressType / lei:AdditionalAddressLine\nOptional additional address line elements.\nlei:TransliteratedStringType\ncontent simple\nminOccurs 0\nmaxOccurs 3\nminLength 1\nmaxLength 500\n(\\S+(\\S+)*) & (\" [% | &I\"INUIN) IN*[\\+], -\npattern I\\.-17101212[3]4|5]|6]|7|8]91:|;|1<|=]>|\\?|A[B|CIDI|E|FIG|H[I[J|K]L]|\nIMIN|O|P|QIR|SITIUIVIWIX]|Y|Z| _|alb]|cld|e|f|g|hliljlk]IIm]|n\nlolplalrisitiulviw]x]y|z)+)\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 73 of 152\n","contentLength":530,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.954Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1\n3, LE|\n2.3.40. Element lei:TransliteratedAddressType / lei:City\nThe mandatory name of the city.\nlei:TransliteratedStringType\ncontent simple\nminLength 1\nmaxLength 500\n(\\S+(\\S+)*) & (\" [% | &I\"INUIN) IN*[\\+], -\npattern I\\.-17101212[3]4|5]|6]|7|8]91:|;|1<|=]>|\\?|A[B|CIDI|E|FIG|H[I[J|K]L]|\nIMIN|O|P|QIR|SITIUIVIWIX]|Y|Z| _|albl|cld]|e|f|glhliljlk]I[m]|n\nlolplalrisitiulviw]x]y|z)+)\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 74 of 152\n","contentLength":478,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.954Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"]\n: F 28\nLEI Common Data File format V2.1 3 LEl\n2.3.41. Element lei:TransliteratedAddressType / lei:Region\nThe (optional) 4- to 6-character ISO 3166-2 region code of the region.\nlei:RegionCodeType\ncontent simple\nminOccurs 0\nminLength 4\nmaxLength 6\npattern ([A-z]{2}-[A-20-9]{1,3})\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 75 of 152\n","contentLength":348,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.954Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"]\n: F 28\nLEI Common Data File format V2.1 3 LEl\n2.3.42. Element lei:TransliteratedAddressType / lei:Country\nThe 2-character I1SO 3166-1 country code of the country.\nlei:CountryCodeType\ncontent simple\nminLength 2\nmaxLength 2\npattern ([A-Z]{2})\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 76 of 152\n","contentLength":309,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.954Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1\n3, LE|\n2.3.43. Element lei:TransliteratedAddressType / lei:PostalCode\nThe (optional) postal code of this address as specified by the local postal service.\nlei:TransliteratedStringType\ncontent simple\nminOccurs 0\nminLength 1\nmaxLength 500\n(\\S+(\\S+)*) & (\" [% | &I\"INUIN) IN*[\\+], -\npattern I\\-1/1011]2]3]4151617]8]9]:|;|1<|=1>|\\?|AIB|CIDIE[F|G[H]I[JIK|L]\nIMIN[O[PIQIR|SIT[U|VIWIX]|Y|Z]|_ lalb|cld|e|flglhliljlk]lIm|n\nlolplalr|sitiulviw]x]y|z)+)\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 77 of 152\n","contentLength":543,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.954Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1 ‘3 LE|\nN\n2.3.44. Element lei:EntityType / lei:RegistrationAuthority\nAn identifier for the legal entity in a business registry in the jurisdiction of legal registration,\nor in the appropriate registration authority.\nlei:RegistrationAuthorityType\ncontent complex\nminOccurs 0\n\n{1,1}\n{0,1}\n{0,1}\n\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 78 of 152\n","contentLength":706,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.954Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"=\"\nLEI Common Data File format V2.1\n9 LE\n2.3.45. Element lei:RegistrationAuthorityType / lei:RegistrationAuthoritylD\nThe reference code of the registration authority, taken from the Registration Authorities List\nmaintained by GLEIF.\nlei:RegistrationAuthorityEnum\ncontent simple\npattern RA\\d{6}\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 79 of 152\n","contentLength":360,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.954Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1\n,LE|\n2.3.46. Element lei:RegistrationAuthorityType /\nlei:OtherRegistrationAuthoritylD\nA legacy / historical reference code of a registration authority which is not yet entered in the\nRegistration Authorities List (RAL) maintained by GLEIF, or the designation of an interim\nregister until such time as an entry from RAL can be delivered.\nlei:Tokenized500Type\ncontent simple\nminOccurs 0\nminLength 1\nmaxLength 500\npattern \\S+( \\S+)*\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 80 of 152\n","contentLength":530,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.954Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1 ‘@ I_E|\n~?\n\nPlease note:\n\n* The default cardinality is {1,1} (mandatory, unique). This document highlights when an\nelement differs from this either by its minoccurs (minimum occurrences) or maxoccurs\n(maximum occurrences) value, or both.\n\n= XML cardinalities apply in the context of any containing elements. This means that a\ncontained element may have a cardinality of one or more even if its containing element\nmay be omitted, because the contained element is mandatory given the presence of the\ncontainer.\n\n= XML cardinalities enforce a minimum data quality and standards conformance. Other\nbusiness rules (as explained below) and data quality checks applied by GLEIF may\nencourage stricter cardinalities in live implementations.\n\n1.5. Business Rules\n\nThe accompanying documentation in addition to this Technical Specification specifies\n\nbusiness rules where applicable for each element. These are rules that are not enforced by\n\nvalidating against the XML schema, but are still mandatory for all Common Data File (CDF)\nformat files.\n\n1.6. XML Syntax\n\nThis section specifies the XML schema for an LEI data file conforming to this standard.\n\n1.6.1. XML Design Rules\n\n= The XSD schema conforms to W3C's XML Schema specification, version 1.0.\n\n* The XML namespace is \"http://www.gleif.org/data/schema/leidata/2016\".\n\n= Allinterior XML elements are namespace-qualified (element form = qualified).\n\n= All XML attributes are in the null namespace (attribute form = unqualified), with the\nexception of xml:1lang.\n\n* Element names are upper camel case.\n\n= Attribute name are lower camel case.\n\n= XSD type names are upper camel case.\n\n= Enumeration code list values are all caps with underscores.\n\n= Elements are used in preference to attributes except for language and type qualifiers.\n\n\" For a data element specified as having unbounded cardinality, the XML includes a single\ncontainer element whose subelements are one or more instances of the data element\nwhose cardinality is unbounded. The name of the container element is formed as the\nplural of the name of the contained elements.\n\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 9 of 152\n","contentLength":2183,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.955Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1\n3, LE|\n2.3.47. Element lei:RegistrationAuthorityType /\nlei:RegistrationAuthorityEntityID\nThe identifier of the entity at the indicated registration authority. Typically, the identifier of\nthe legal entity as maintained by a business registry in the jurisdiction of legal registration,\nor if the entity is one that is not recorded in a business registry (e.g. one of the varieties of\nfunds registered instead with financial regulators), the identifier of the entity in the\nappropriate registration authority.\nlei:Tokenized500Type\ncontent simple\nminOccurs 0\nminLength 1\nmaxLength 500\npattern \\S+( \\S+)*\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 81 of 152\n","contentLength":701,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.955Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1\nB LE\n2.3.48. Element lei:EntityType / lei:Legallurisdiction\nThe jurisdiction of legal formation and registration of the entity (and upon which the\nLegalForm data element is also dependent). Please note that the XML schema validates the\nformat of LegalJurisdiction codes but not the specific codes conforming to the ISO\nstandards it reequires.\nlei:JurisdictionCodeType\ncontent simple\nminOccurs 0\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 82 of 152\n","contentLength":495,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.955Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1\n3, LE|\n2.3.49. Element lei:EntityType / lei:EntityCategory\nIndicates (where applicable) the category of entity identified by this LEl data record, as a\nmore specific category within the broad definition given in ISO 17442. These categories are\nbased on use cases specified in LEI-ROC policies, found at\nhttp://www.leiroc.org/list/leiroc_gls/index.htm\nlei:EntityCategoryTypeEnum\ncontent simple\nminOccurs 0\nenumeration BRANCH The legal entity is a branch of another legal entity.\nenumeration FUND The Iegal. entity is a fund managed by another\nlegal entity.\nenumeration SOLE_PROPRIETOR The.legal entltY is an individual acting in a\nbusiness capacity.\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 83 of 152\n","contentLength":749,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.955Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1 ‘3 LEl\nN’\n2.3.50. Element lei:EntityType / lei:LegalForm\nThe legal form of the entity, taken from the ISO Entity Legal Form (ELF) code list maintained\nby GLEIF. Please note that the XML schema validates the format of LegalForm codes but not\nthe specific codes conforming to the ISO standard it reequires.\nlei:LegalFormType\ncontent complex\nminOccurs 0\n\n{1l,1}\n{0,1}\n\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 84 of 152\n","contentLength":646,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.955Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1\n3, LE|\n2.3.51. Element lei:LegalFormType / lei:EntityLegalFormCode\nA current code from the GLEIF-maintained list MUST be used. Values of the LegalFormEnum\ncode list are maintained by I1SO / GLEIF through the Entity Legal Form (ELF), available from\nhttp://www.gleif.org.\nlei:LegalFormEnum\ncontent simple\n(([A-Z][A-z0-9]{3}| [A-ZO-\n9][A-Z][A-Z0-9]{2}| [A-ZO-\npattern 9J{2}[A-Z][A-Z0-9] | [A-ZO-\n91{3}[A-Z]))[(9999) | (8888)\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 85 of 152\n","contentLength":521,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.957Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1\n,LE|\n2.3.52. Element lei:LegalFormType / lei:OtherLegalForm\nA legacy code or textual description for the legal entity's legal form, used until a current\ncode from the GLEIF-maintained list can be used.\nlei:Tokenized500Type\ncontent simple\nminOccurs 0\nminLength 1\nmaxLength 500\npattern \\S+( \\S+)*\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 86 of 152\n","contentLength":395,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.957Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1 ‘3 LE|\nN’\n2.3.53. Element lei:EntityType / lei:AssociatedEntity\nAnother entity associated with this entity if needed to fully identify this entity or to place it\nin an appropriate context.\nlei:AssociatedEntityType\ncontent complex\nminOccurs 0\n\n{1,1}\n{1,1}\n\nAttribute Type Use Annotation\n. . . . The type of association represented\ntype lei:AssociatedEntityTypeEnum required ) . o\nP yiyp 9 by this AssociatedEntity instance.\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 87 of 152\n","contentLength":737,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.957Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"]\n: F 28\nLEI Common Data File format V2.1 @ LEl\n2.3.54. Element lei:AssociatedEntityType / lei:AssociatedLEl\nThe LEI of an entity associated with the LEI of this registration.\nlei:LEIType\ncontent simple\nminLength 20\nmaxLength 20\npattern ([0-9A-Z]{18}[0-9]{2})\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 88 of 152\n","contentLength":326,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.957Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1\n3, LEI\n2.3.55. Element lei:AssociatedEntityType / lei:AssociatedEntityName\nThe name of an entity associated with the LEI of this registration.\nlei:NameType\ncontent complex\nAttribute Type Use Annotation\nAttempting to install the relevant ISO 2- and 3-letter\nunion codes as the enumerated possible values is probably\nof(xs:language never going to be a realistic possibility. See RFC 3066 at\nxml:lang restri.ctiogn ofg \" optional http://www.ietf.org/rfc/rfc3066.txt and the IANA\nxs:string) registry at http://www.iana.org/assignments/lang-tag-\n) g apps.htm for further information. The union allows for\nthe 'un-declaration' of xml:lang with the empty string.\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 89 of 152\n","contentLength":755,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.957Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1 ‘3 LE|\nN’\n2.3.56. Element lei:EntityType / lei:EntityStatus\nThe operational and/or legal registration status of the entity (may be AcTIVE or INACTIVE).\nlei:EntityStatusEnum\ncontent simple\nAs of the last report or update, the legal entity\nenumeration ACTIVE reported that it was legally registered and\noperating.\nIt has been determined that the entity that was\nassigned the LEl is no longer legally registered\nenumeration INACTIVE and/or operating, whether as a result of business\nclosure, acquisition by or merger with another (or\nnew) entity, or determination of illegitimacy.\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 90 of 152\n","contentLength":677,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.957Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"- ]\nLEI Common Data File format V2.1 @ LEl\n1.6.2. XML Schema\nAn XML file conforming to this standard SHALL be valid according to the following XSD 1.0\nschema.\n\n\n\n \n\n\n \n\n\n\n\n\n\n\n\n\n\n\n\n \n\n\n \n\n\n\n\n\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 10 of 152\n","contentLength":1578,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.957Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":". =\"\nLEI Common Data File format V2.1\n9 LE\n2.3.57. Element lei:EntityType / lei:EntityExpirationDate\nThe date that the legal entity ceased to operate, whether due to dissolution, merger or\nacquisition.\nlei:LEIDateTimeProfile\ncontent simple\nminOccurs 0\n([T HINT*(\\((\\d){1,31)){0,2}))(Z| \\+([01][O-\npattern 9]]2[0-3]):([0-5][0-9]) | -([01][0-9] | 2[0-3]):([O-\n5][0-9]))\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 91 of 152\n","contentLength":435,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.957Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1 ‘3 LE|\nP\n2.3.58. Element lei:EntityType / lei:EntityExpirationReason\nThe reason that a legal entity ceased to exist and/or operate.\nlei:EntityExpirationReasonEnum\ncontent simple\nminOccurs 0\nenumeration DISSOLVED The entity ceased to operate.\nenumeration CORPORATE_ACTION Thg entity was acquired or merged with another\nentity.\n. The reason for expiry is neither of bT1ssoLvED nor\nenumeration OTHER CORPORATE_ACTION\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 92 of 152\n","contentLength":514,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.958Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1 ‘a LE|\nN 4\n2.3.59. Element lei:EntityType / lei:SuccessorEntity\nThe surviving/new legal entity which continues/replaces this registration.\nlei:SuccessorEntityType\ncontent complex\nminOccurs 0\n\n{1,1}\n{1,1}\n\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 93 of 152\n","contentLength":505,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.958Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"]\n: 2y\nLEI Common Data File format V2.1 3 LEl\n2.3.60. Element lei:SuccessorEntityType / lei:SuccessorLEl\nThe LEI of the successor entity.\nlei:LEIType\ncontent simple\nminLength 20\nmaxLength 20\npattern ([0-9A-Z]{18}[0-9]{2})\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 94 of 152\n","contentLength":288,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.958Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1\n3, LEI\n2.3.61. Element lei:SuccessorEntityType / lei:SuccessorEntityName\nThe name of the successor entity.\nlei:NameType\ncontent complex\nAttribute Type Use Annotation\nAttempting to install the relevant ISO 2- and 3-letter\nunion codes as the enumerated possible values is probably\nof(xs:language never going to be a realistic possibility. See RFC 3066 at\nxml:lang restri.ctiogn ofg \" optional http://www.ietf.org/rfc/rfc3066.txt and the IANA\nxs:string) registry at http://www.iana.org/assignments/lang-tag-\n) g apps.htm for further information. The union allows for\nthe 'un-declaration' of xml:lang with the empty string.\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 95 of 152\n","contentLength":719,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.958Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1 ‘3 LEl\nN’\n\n2.3.62. Element lei:EntityType / lei:NextVersion\nA structure for adding further elements in to the entity section of the LEl data record in\nanticipation of a new version, by nesting a series of XML elements with this content model\nwithin the Nextversion element, one for each new minor version of the schema,\npostpending a serial number (1,2,3...) to the element name upon each iteration.\nlei:EntityNextVersionType\ncontent complex\nminOccurs 0\n\nPublic\n\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 96 of 152\n","contentLength":555,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.958Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1 3' LE|\n2.3.63. Element lei:LEIRecordType / lei:Registration\nThe Registration container element contains all information on the legal entity's LEI\nregistration with the ManagingLou.\nlei:RegistrationType\ncontent complex\n\n{1,1}\n{1,1}\n{1,1}\n{1l,1}\n{1,1}\n{0,1}\n{0,1}\n{0,1}\n{0,1}\n\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 97 of 152\n","contentLength":895,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.958Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"- 00000000000\nLEI Common Data File format V2.1 3' LEl\n2.3.64. Element lei:RegistrationType / lei:InitialRegistrationDate\n\nDate/time the LEI record was created.\nlei:LEIDateTimeProfile\ncontent simple\n(IA\\T* HIMNT*(\\((\\){2,31)){0,2}))(Z | \\+([01][0-\npattern 9]12[0-3]):([0-5][0-9]) | -([01][0-9] | 2[0-3]):([O-\n5][0-9]))\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 98 of 152\n","contentLength":384,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.958Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"- ________0____000___]\nLEI Common Data File format V2.1 3' LEl\n2.3.65. Element lei:RegistrationType / lei:LastUpdateDate\n\nDate/time the LEI record was most recently updated.\nlei:LEIDateTimeProfile\ncontent simple\n(IA\\T* AT\\ ((\\d){2,31){0,1})) (2| \\+([01][O-\npattern 9]]2[0-3]):([0-5][0-9]) | -([01][0-9] | 2[0-3]):([O-\n5][0-9]))\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 99 of 152\n","contentLength":394,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.958Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf","content":"LEI Common Data File format V2.1 ‘@ LEl\n\\I\n2.3.66. Element lei:RegistrationType / lei:RegistrationStatus\nThe status of the legal entity's LEl registration with the ManagingroU.\nlei:RegistrationStatusEnum\ncontent simple\nenumeration PENDING VALIDATION An appl'lcat.lon for an LEl that has begn submitted\n- and which is being processed and validated.\nAn LEI Registration that has been validated and\nenumeration ISSUED issued, and which identifies an entity that was an\noperating legal entity as of the last update.\nAn LEI Registration that has been determined to\nbe a duplicate registration of the same legal entity\nenumeration DUPLICATE as another LEI Registration; the DUPLICATE status\nis assigned to the non-surviving registration (i.e.\nthe LEI that should no longer be used).\nAn LEI registration that has not been renewed by\nenumeration LAPSED the NextRenewalDate and is not known by public\nsources to have ceased operation.\nAn LEI registration for an entity that has been\nenumeration MERGED merged into another legal entity, such that this\nlegal entity no longer exists as an operating entity.\nAn LEl registration for an entity that has ceased\nenumeration RETIRED operation, without having been merged into\nanother entity.\n. . K\nenumeration ANNULLED An'LEI r'eglstratl'on tha.t was marked as erroneous\nor invalid after it was issued\nenumeration CANCELLED An LEl registration that was abandoned prior to\nissuance of an LEI\nPublic\nAuthor: GLEIF | Version: FINAL | 2017-03-21 Page 100 of 152\n","contentLength":1491,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:54:51.958Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"[\nd,|E| .\nPublic\nRelationship Record Common Data File\nformat V1.1\nFinal V1.1 2017-03-16\n(@)X (( y\no — g\n|‘ |\n°©\n","contentLength":112,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.543Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"]\nRelationship Record Common Data File format V1.1 @ LE|\nContents\nLo INEFOTUCTION ittt ettt et sab e e st e e sabe e e st te et e e s abae e abeeesubeeessaessaneeesseesnanees D\n\n1.1. Status Of this dOCUMENT ....ccoiiii ettt st ee s st e e st ee et e sabbeeneeee e D\n1.2. Terminology and Typographical CoONVENTIONS........ccccccviiiiiiicie et etree e ette e eree e e seeee e e siaees D\n1.3, CardiN@liti®s ..ueeeeiieiiiiie ettt ettt ettt st e st st e e bt aeeantee s sbbeesaseesnbeessseeees ©\n1.4, BUSINESS RUIES ... .eieiiiie ettt ettt ettt et s sh e e et eesabbe e s bt eesneeeesbsaeenteessubeesanseesnseesssseees ©\n1.5, XIMIL SYNTAX i ii ittt e e e e e e e e e e e e e eeeeeeetetetae et ae e seae st st s sssa s s aesnsnsesesaseseeseeeneneeessesenennsns O\n1.5.2. XML DESIZN RUIES...ceiiieieeeiiietieceiieeee ettt ee et ee s es st ee s s staeee s sssaseeesassasnaeesssnsnneeassssnneesssssnnenees ]\n1.5.2. XIMIL SCREMIA ettt ettt ettt st s st ee et e s st ee st e s sbte e et ee s sabeassnseesnbeessssaesnneeeessneasnns\n1.6. REIEASE NOLES ...neeiiiiiie ettt et ettt ettt s e e et e e st te e et eesabbeesateeesubeeenseeesaneeesseeenneessusseanssees LD\nI ST O =T YT o e O PP PP PPPPPPTPPPPPR A1\nI ST A =T YT o e O PO PPPPPPOPPPPUPR I o\n1.7. Change ManagemMENTt.......ceuiicciiieeeieetieee ettt eeseesttaeessettteeessstteeesssnseeeessanssseessssssseesssnsssesssssssssesssnass LO\nO B g =) = Y =T €1 o I PP PUPPPPOPPPPUPR I o\nA Y 1 g Yo T gV A =T €1 o o PP PTPPPPOPPPPPR I o\n1.7.3. MAJOT VEISION ceeeitiiitiiiitititicee e ee e e e e e e e e eeeeeeetetetetettrteee e st st s ssas s s sesasesasesaseseaeeeesesesesseseresns LO\n1.7.4. Minor Version Changes to the XML SChema ........ccooviiiiiiiiiiiieiiisecie e cssieee s seeesesseens 17\n1.7.5. Major Version Changes to the XML SChema.........ccoivuiiiiiiiiiiieiiisecie e seee e snee e e seens 18\n2. ADSEract Data CONTENT......iieiiie ettt ettt ettt e et ee et e st ee et e e st te e etee s subeesanseesnbeesssseesnneeeesseeees LO\n2.1. Relationship Data File HEAUEr.........cciiiiiiiiiiiiieie et ccsiieee st ee s seeee e s seieeeeassssseeessssnnneessssnnees 1O\n2.2. Relationship RECOIT .....iiiiiiiiie ittt ee e st ee s e ee s s s ssseee s sssaneeaesssssneeesssssneeesssssnnees 20\n2.2, ReltIONSIP .eviiee ettt e e s st te e s s sraeaessnnaeeessnnsnneessnnns 20\n2.2.2. REGISTIAtiON .. e e e e e e e e e e eeeeeeeeeeeteae e bt e ne s nnn s e e s e ananenaes 22\n2.2.3 EXEENSTION 1.ttt et e e e e s s re s reaeeeees 23\n2.3. Data Element REFErENCE .. .coi ittt ettt et et savte e see e sneeessnneesneee e 280\n2.3.1. Element rr:RelationshipData ......cccccecciiiii ettt etree e eree e s eeee e s sreee e eee 2D\n2.3.2. Element rr:RelationshipDataType / HEAAEN .....cccvviiiieicciie ettt eine0000 20\n2.3.3. Element rr:RRHeaderType / ContentDate .......ccecuveiiiiieeceee et srte e svae e seneaeens 27\n2.3.4. Element rr:RRHeaderType / OrigiNator .....icceeeeeeieciie et eree e stvae e srte s srae e erneeees 28\n2.3.5. Element rr:RRHeaderType / FIleCONTENT ....cccuveeeiiiiiciie ettt s sree e eene e 29\n2.3.6. Element rr:RRHeaderType / DeaSTart .....ccccceecieeeecie e ceeesitie e eeeestiteesreeesveesssaae s sveeessenesnees 31\n2.3.7. Element rr:RRHeaderType / RECOrdCOUNT.......ccccuiieiiiieeciieesitieeereesttteesveeeseeeeesseaessneeesssseenens 32\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 2 0of 90\n","contentLength":3347,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.543Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"]\nRelationship Record Common Data File format V1.1 @ LE|\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 11 of 90\n","contentLength":1269,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.543Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"]\nRelationship Record Common Data File format V1.1 @ LEI\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 12 of 90\n","contentLength":1381,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.543Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"]\nRelationship Record Common Data File format V1.1 @ LEI\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 13 of 90\n","contentLength":1490,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.543Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"]\nRelationship Record Common Data File format V1.1 @ LE|\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 14 of 90\n","contentLength":1361,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.543Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"]\nRelationship Record Common Data File format V1.1 @ LE|\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n1.6. Release Notes\n1.6.1. Version 1.1\nCorrections:\n= Corrected elementFormDefault=\"unqualified\" to\nelementFormDefault=\"qualified\".\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 15 of 90\n","contentLength":899,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.543Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘@ LE|\n~?\n\n1.6.2. Version 1.0\nThe first release.\n1.7. Change Management\nChanges to this standard that affect the data schema SHALL be made by approval and\npublication of a new version of this document. A new version SHALL be one of the following:\n1.7.1. Errata Version\nAn errata version makes corrections to the normative content of the standard (excluding\ncorrections which would change the data schema) and/or makes changes to non-normative\ncontent such as explanatory material. An errata version does not change the XML schema\ndefinitions, only the documentation parts, and so does not affect the interoperability of\nsystems implementing the standard. An errata version is indicated by incrementing the third\nversion number; e.g., 1.0t0 1.0.1, or 1.0.1 to 1.0.2.\n1.7.2. Minor Version\nA minor version may include all changes permitted in an errata version, and in addition adds\none or more data elements and/or adds one or more codes to a code list (“enum” data\ntype). A minor version changes the XML schema. Minor version changes to schema MUST\nprovide for forward and backward compatibility. This allows existing implementations to\ncontinue to interoperate even if they are using different minor versions. A minor version is\nindicated by incrementing the second version number; e.g., 1.0to 1.1 or 1.1.3to 1.2.\n1.7.3. Major Version\nA major version may make any change at all, including incompatible changes to the XML\nschema. Major version changes to schema require that the new version uses a different XML\nnamespace. This requires existing implementations to separately understand both the old\nand new versions during a period of transition. A major version is indicated by incrementing\nthe first version number; e.g., 1.1 to 2.0.\nThe release of a new minor or major version shall always be accompanied by a transition\nplan for LOUs and GLEIF, to ensure a smooth and time-bounded migration to the new\n\nPublic\n\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 16 of 90\n","contentLength":2022,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.543Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘@, LE|\nversion.\n1.7.4. Minor Version Changes to the XML Schema\nA minor version may introduce new XML elements and/or adds one or more codes to a code\nlist (“enum” data type). Minor version changes to schema SHALL be made as specified\nbelow, in order to achieve forward and backward compatibility.\nForward compatibility means that an LEI Data File which is valid according to the older\nversion’s schema is also valid according to the newer version’s schema.\nBackward compatibility means that an LEI Data File which is valid according to the newer\nversion’s schema is also valid according to the older version’s schema.\nNew data elements may be added at pre-defined extension points within the schema, each\nwith an optional XML element NextVersion. New data elements are always added within a\nNextVersion element. When a minor version adds a new data element to a Nextversion\nelement, a new Nextversion element is also added inside the previously added\nNextVersion element, to accommodate additional data elements in subsequent minor\nversions. Each successive NextVersion element set is contained directly within the previous\nminor version's NextVersion set.\nAs can be seen from the full XML schema presented here, the following rules SHALL be\nobserved to ensure forward and backward compatibility:\n\ne The initial XSD declaration for a Nextversion element SHALL use the element name\n\"NextVersion\", XML data type \"lei:NextVersion1Type\" and cardinality optional,\nunique {0,1}. The XML data type allows a sequence of any elements, each of\ncardinality optional, repeatable (unbounded) and with lax content processing, but in\nthe target namespace.\n\ne The minOccurs declaration on the Nextversion element allows it to be omitted in\nfiles conforming to the first minor version. The schema wildcard xsd:any allows for\nforward compatibility: a file conforming to a new minor version still validates in the\nold version because the wildcard matches any new elements introduced in the new\nminor version.\n\n¢ New elements SHALL be introduced in a subsequent minor version by modifying the\ndeclaration for the above type declaration as follows:\n\no Asequence of the new elements introduced in the previous version.\no Asubsequent NextversionN element where N is an index number starting at\n1 and incremented by 1 with each minor version.\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 17 of 90\n","contentLength":2434,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.543Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘@ LE|\n\\I\n\ne Each new element SHALL be declared minOccurs=\"0\", to ensure backward\ncompatibility: a file conforming to the old version still validates in the new version\nbecause the new schema does not require the presence of elements not defined in\nthe old version. If a new element is mandatory for conformance to the new version,\nthis MUST be enforced outside schema validation.\n\n¢ The new definition of the Nextversion element SHALL include a declaration of an\ninner Nextversion element, as illustrated above, to provide for additional elements\nin subsequent minor versions. The nesting of Nextversion elements is required to\nsatisfy the “unique particle attribution” constraint of XSD 1.0.\n\ne Each code list (Enum types) is implemented in the XML schema simply as the XSD\nstring data type. This provides for forward compatibility because the schema for an\nolder minor version will validate any string, including codes defined in newer minor\nversions. The schema for each minor version includes the list of valid codes for that\nminor version as a documentation annotation to the type declaration for each Enum\ntype.\n\n1.7.5. Major Version Changes to the XML Schema\n\nA major version may make any change to the XML schema whatsoever, including\nincompatible changes.\n\nA schema introduced in a new major version SHALL use an XML namespace URI that is\ndifferent from the XML namespace URI defined in any other major version of this standard.\nThe namespace URI for a new major version SHOULD be the same as the namespace URI\nspecified in this standard, with the year at the end changed to the year in which the new\nmajor version is introduced. If more than one major version is introduced in the same year, a\nletter “a”, “b”, “c”, etc., may be appended to the year as needed.\n\nA new major version MUST be accompanied by an implementation plan which explains how\nimplementations will make the transition from the old major version to the new major\nversion. Generally speaking, such a plan typically provides for a period of transition in which\nan implementation capable of receiving the new major version is required to also receive\nthe old major version.\n\n2. Abstract Data Content\n\nThis section specifies the abstract data content of a data file conforming to this standard. A\ndata file conforming to this standard SHALL consist of:\n\ne AHeader.\n\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 18 of 90\n","contentLength":2456,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.543Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘3 LEl\nN’\ne Zero or more Relationship Records.\n® [ ] rrRelationshipDataType\n5\n———rr— L @e\nrrRelationshipDataType RelationshipRecords G\n+\nrr:RelationshipRecordsType\n2.1. Relationship Data File Header\nThe Relationship Data File Header describes the context for the Relationship Records\ncontained in the main body of the file. The header exists to answer such questions as where\nthe data came from, when it was collected into this file, etc. The content of the header\nSHALL NOT be required to interpret the data content of any Relationship Record; each\nRelationship Record is self-contained.\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 19 of 90\n","contentLength":703,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.543Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘% LEl\nN\n® [ ] rr:RRHeaderType\no\nrr:LEIDateTimeProfile\nOriginator ®\nType | rr:LEIType\n(FileContent ] o\n(Jype | rr:FileContentEnum )\nDeltaStart\nR —\nType | rr:LEIDateTimeProfile\n5\nxs:nonNegativelnteger\nNextVersion ®\nType | rr:HeaderNextVersionType\nExtension ®\nType | rr:ExtensionType\n2.2. Relationship Record\nAn Relationship Record describes a single LEI registration. Each Relationship Record in a file\nconforming to this standard SHALL include data elements as described below:\n2.2.1. Relationship\nThe Relationship container element identifies the two related entities and their relationship.\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 20 of 90\n","contentLength":707,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.543Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"]\n\nRelationship Record Common Data File format V1.1 @ LE|\n2.3.8. Element rr:RRHeaderType / NeXtVErsiON ......cccccuiieciieeciieesctieeeceeesiteessveeesveesssaae e seeeesssneenens 33\n2.3.9. Element rr:RRHeaderType / EXTENSION ......cccviieiieecceiecciie ettt e srree e e s svae s eineessvveannneeeenns 3\n2.3.10. Element rr:RelationshipDataType / RelationshipRecords .........c.cccccvevviveesceriiiieeecceeesiieen. 35\n2.3.11. Element rr:RelationshipRecordsType / RelationshipRecord...........cccccevvveeccveiinieeccciie e 36\n2.3.12. Element rr:RelationshipRecordType / Relationship ........cccccceevecieecciiiisiiecceeeesieeeeveeeeienennn 37\n2.3.13. Element rr:RelationshipContainerType / StartNOde.........ccccvvevecveecciieesiie e sie e eree e eieees 38\n2.3.14. Element rr:NodeType / NOUEID ...c.cueeeiiie ettt et e e ste e s e stte e s staaesneeeesreeasnnnaeessseasnes 39\n2.3.15. Element rr:NodeType / NOdeIDTYPE ..cccvieeereeeeeiectieeeeeeestie e eveesvieessrvaeenneeesnnessnnneessnneannns 40\n2.3.16. Element rr:RelationshipContainerType / ENANOAE ......c.cevvvvivecceeeciieecieee e 41\n2.3.17. Element rr:RelationshipContainerType / RelationshipType .....cccccccvvevcvveeccereccie e e 42\n2.3.18. Element rr:RelationshipContainerType / RelationshipPeriods...........cccccvveecereivieecceeecnnnenn 43\n2.3.19. Element rr:RelationshipPeriodsType / RelationshipPeriod .........cccccceeecvveeviesccceee e 44\n2.3.20. Element rr:RelationshipPeriodType / StartDate.......cccccceeeeviveeeceeesiieeccree e essine e eveeessene e 45\n2.3.21. Element rr:RelationshipPeriodType / ENdDate.......cccceeccveeiviieiieieciieccsivie e svie e enee e 46\n2.3.22. Element rr:RelationshipPeriodType / PEriodTyPe .....cccccveeevieeiireecieescvie e svieeevee e eneann 47\n2.3.23. Element rr:RelationshipContainerType / RelationshipStatus..........ccccoevvveecceveeiiieeccciee e 48\n2.3.24. Element rr:RelationshipContainerType / RelationshipQualifiers...........cccceecvvvevinicccreeeenen. 49\n2.3.25. Element rr:RelationshipQualifiersType / RelationshipQualifier ...........cccccecevveiiiiiccvie ... 50\n2.3.26. Element rr:RelationshipQualifierType / QualifierDimension..........ccccccevvveeeereiviieeecceeesinna 51\n2.3.27. Element rr:RelationshipQualifierType / QualifierCategory.......cccccecvvevveveeecereiiieeeeeeesiieanen 52\n2.3.28. Element rr:RelationshipContainerType / RelationshipQuantifiers.............cccceevveeeevenennnenn. 53\n2.3.29. Element rr:RelationshipQuantifiersType / RelationshipQuantifier ............cccccceveevvveennneen.nn. 54\n2.3.30. Element rr:RelationshipQuantifierType / MeasurementMethod...............ccceevvveeeceeeeiinenn. 55\n2.3.31. Element rr:RelationshipQuantifierType / QuantifierAmount..........cccccccvveecceieiiieeccciie e el 56\n2.3.32. Element rr:RelationshipQuantifierType / QuantifierUnits.........cccccceveeivieecceeeiiiieececieeescennnns 57\n2.3.33. Element rr:RelationshipContainerType / NeXtVEersion ........cccccceceeecieeiivieecceeesieesssreeeseeenens D8\n2.3.34. Element rr:RelationshipContainerType / EXtENSION .....ccceevviiieveeciieeesivieeceeeesieeeereeeseeeeeees D9\n2.3.35. Element rr:RelationshipRecordType / Registration .........cccccceeveeeeecieeiiiieeceeeesieeeeveeeeeneennn, 60\n2.3.36. Element rr:RegistrationContainerType / InitialRegistrationDate .........cccceeeceveevveeeceeesiinnnnn 61\n2.3.37. Element rr:RegistrationContainerType / LastUpdateDate .......cccccccvvercvveeecieriisiieecceeessineennn. 62\n2.3.38. Element rr:RegistrationContainerType / RegistrationStatus..........cccceevvveeecereiiieecceeesiineennn. 63\n2.3.39. Element rr:RegistrationContainerType / NextRenewalDate ..........ccccceevveeecereiiieeeceeesiineennn. 65\n2.3.40. Element rr:RegistrationContainerType / ManagingLOU..........ccccceeevviivvieeceeeesieeecieeeeeeenn.. 66\n\nPublic\n\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 3 0of 90\n","contentLength":3844,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.543Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘3 LE|\nN\n® [] rr:RelationshipContainerType\no\no\no\nRelationshipPeriods ®\nType | rr:RelationshipPeriodsType\n. . o\n0..0 | RelationshipQualifiers ®\nType | rr:RelationshipQualifiersType\n0..00 | RelationshipQuantifiers ®\nType | rr:RelationshipQuantifiersType\nNextVersion ¢\nType | rr:RelationshipNextVersionType\nExtension ®\nType | rr:ExtensionType\n2.2.1.1. Related Entities\nThe I1SO 17442-compliant identifiers of the legal entities related by this Relationship Record.\n®\n(Type | rr:LEMype )\nc\n2.2.1.2. Relationship Attributes\nAttributes describing the dates, type, qualitative and quantitative aspects of the relationship\nitself, as required. The data is supplied by the legal entity, and recorded and published by\nthe LOU.\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 21 of 90\n","contentLength":831,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.543Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘% LE|\nN\n® [ ] rr:RelationshipPeriodsType\n® [] rr:RelationshipPeriodType\nStartDate ®\nType | rr:LEIDateTimeProfile\n7 N L N AR .\nType [ rLEDaeTmeprofie\n.\n® [ rrRelationshipQualifiersType\n® [] rrRelationshipQualifierType\no\no 0.. | RelationshipQualifier o G o\nType | rr:RelationshipQualifierType | QualifierCategory e\n( Type | rr:QualifierCategoryTypeEnum\n® [] rr:RelationshipQuantifiersType\n® [] rr:RelationshipQuantifierType\n.\no 0..0 | RelationshipQuantifier o ®\n' Type | rr:RelationshipQuantifierType m\nQuantifierUnits ®\nType | rr:QuantifierUnitsTypeEnum\n2.2.2. Registration\nAttributes describing the registration of this relationship information with an LOU. The\nRegistration datais maintained by the LOU.\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 22 of 90\n","contentLength":820,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.543Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘3 LE|\nN’\n[©] [] rr:RegistrationContainerType\no\n5\no\nNextRenewalDate ®\nType | rr:LEIDateTimeProfile\no\nSimm— O e\n(Valgatonsources )\n(Valdaiombocsmens ).\nValidationReference ®\nType | rr:-Tokenized500Type\nNextVersion ®\nType | rr:RegistrationNextVersionType\nExtension ®\nType | rr:ExtensionType\n2.2.3. Extension\nThe optional Extension section of a Relationship Record may be used to include additional\ndata not defined in this standard. This may include data specific to an LOU, data specific to a\npublisher of LE|l data, and so on.\nFor example, an LOU may use Extension to publish additional data elements it collects as\npart of registration.\nThe following rules MUST be observed:\ne Each XML element included in the content of the Extension element SHALL be in\nan XML namespace that is not null and not equal to the XML namespace of the LEI\nData File as specified in this standard.\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 23 of 90\n","contentLength":991,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.543Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘@ LEI\n\\l\n\ne The XML namespace for an Extension element SHALL be a namespace which the\ncreator of the extension element exclusively or jointly controls, or from which the\ncreator re-uses existing elements and their definitions, e.g. a namespace derived\nfrom the Internet Domain Name of the creator, a namespace agreed upon by a group\nof trading partners, etc.\n\ne AnExtension element SHALL NOT be defined in such a way as to require the\nrecipient of the file to recognize the Extension element in order to interpret the\ndata elements specified in this standard. A recipient of the file MUST be able to\nignore all Extension elements and still interpret the standard content correctly.\n\ne Arecipient of a data file conforming to this standard SHALL NOT reject a file solely\nbecause it contains extensions not understood by the recipient. A recipient MUST be\nprepared to accept a file containing extensions and ignore any it does not\nunderstand, provided that the file complies to this standard.\n\n2.3. Data Element Reference\n\nThe following pages describe all individual data elements, attributes and datatypes, one per\npage.\n\nPublic\n\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 24 of 90\n","contentLength":1237,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.543Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘3 LE|\nN\n2.3.1. Element rr:RelationshipData\nContains the file structure for the whole relationship records file as specified in the XML\ndatatypes below.\nrr:RelationshipDataType\ncontent complex\n\n
{1l,1}
\n{1l,1}\n\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 25 of 90\n","contentLength":478,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.543Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘% LE|\nN\n2.3.2. Element rr:RelationshipDataType / Header\nContains the file upload information for this RelationshipData file.\nrr:RRHeaderType\ncontent complex\n
\n{1l,1}\n{0,1}\n{1l,1}\n{0,1l}\n{1, 1}\n{0,1}\n{0,1l}\n
\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 26 of 90\n","contentLength":519,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.543Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘; 3' LEl\n2.3.3. Element rr:RRHeaderType / ContentDate\nThe date and time as of which the data contained in the file is valid.\nrr:LEIDateTimeProfile\ncontent simple\n(IA\\T* AT\\ ((\\d){2,31){0,1})) (2| \\+([01][O-\npattern 9]12[0-3]):([0-5][0-9]) | -([01][0-9] | 2[0-3]):([O-\n5][0-9]))\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 27 of 90\n","contentLength":393,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.543Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘3 LE|\nN\n2.3.4. Element rr:RRHeaderType / Originator\nThe LEI of the entity that created the content of this file.\nrr:LEIType\ncontent simple\nminOccurs 0\nminLength 20\nmaxLength 20\npattern ([0-9A-Z]{18}[0-9]{2})\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 28 of 90\n","contentLength":324,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.543Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘@ LE|\n~?\n2.3.5. Element rr:RRHeaderType / FileContent\nA code describing the content of this relationship record file.\nrr:FileContentEnum\ncontent simple\nThe file contains all relationship records created\nfor internal use by an LOU (all internal\nenumeration LOU_FULL_INTERNAL relationship records for which the LOU is the\nManagingLoU) as of the date/time the file is\ncreated.\nThe file contains those relationship records\ncreated by an LOU for internal use (all internal\nenumeration LOU DELTA INTERNAL relationship recor.ds for which the LOU is the\n- - ManagingLou) which are new or changed since\nthe Deltastart specified in the Header, as of the\ndate/time the file is created.\nThe file contains all relationship records published\n. by an LOU (all relationship records for which the\nenumeration LOU_FULL_PUBLISHED LOU is the ManagingLou) as of the date/time the\nfile is created.\nThe file contains those relationship records\npublished by an LOU (all relationship records for\nenumeration LOU_DELTA_PUBLISHED which the LOU is the ManagingLou) which are\nnew or changed since the peltastart specified in\nthe Header, as of the date/time the file is created\nThe file contains all relationship records GLEIF\nenumeration GLEIE FULL INTERNAL manages mtgrnallY to the GLEIS (including all\n- - internal relationship records from all LOUs) as of\nthe date/time the file is created.\nenumeration GLEIF DELTA INTERNAL The file contains those relationship records GLEIF\n- - manages internally to the GLEIS (including all\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 29 of 90\n","contentLength":1615,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.543Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘6 LE|\nP\ninternal relationship records from all LOUs) which\nare new or changed since the peltastart date\nspecified in the Header, as of the date/time the\nfile is created.\nThe file contains all relationship records published\nenumeration GLEIF_FULL_PUBLISHED by GLEIF (including all relationship records from\nall LOUs) as of the date/time the file is created.\nThe file contains those relationship records\npublished by GLEIF (including all relationship\nenumeration GLEIF_DELTA_PUBLISHED records from all LOUs) which are new or changed\nsince the peltastart date specified in the\nHeader, as of the date/time the file is created.\nenumeration QUERY_RESPONSE The fll.e cgntams records matching criteria\nspecified in a query.\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 30 of 90\n","contentLength":831,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.543Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"]\n\nRelationship Record Common Data File format V1.1 @ LE|\n2.3.41. Element rr:RegistrationContainerType / ValidationSources..........cccccevvvieeceeeesieesecveessnnnnnn 67\n2.3.42. Element rr:RegistrationContainerType / ValidationDocuments...........cccceeeveeerveeeicveeeennennn.. 68\n2.3.43. Element rr:RegistrationContainerType / ValidationReference........cccccccvveevvveiieiccciee ... 69\n2.3.44. Element rr:RegistrationContainerType / NeXtVersion.........cccceeevveeeveeesvieeccneeesieesssveessnnannn 70\n2.3.45. Element rr:RegistrationContainerType / EXtENSION ......ceeevvvieerceeesiieecreie e ecsiie e eeeessineanenn 71\n2.3.46. Element rr:RelationshipRecordType / NeXtVersion........ccccueeeceeeesvieeicreeesieeesseneeseneeesssneanens 72\n2.3.47. Element rr:RelationshipRecordType / EXLENSION .......ccccveeiiiieecceeeciie e eieeesrvee e eeeessiae e 73\n2.3.48. Simple Type rr:LEIDateTimeEProfile .....ccciicciiiie et ee s sseveeeessvnneeeanens 1D\n2.3.49. SIMPIE TYPE ITiLEITYPE wevriiiieiieie ettt ette e ertte e e ette e e s stee e e stee e e e sanreeaassnsenessssens 7D\n2.3.50. Simple Type rr:FileContentENUM ......c.coiii ittt eette e eesreeeeessaneeeeeens 0\n2.3.51. Simple Type rr:NOdelDTYPEENUM.......ciii ittt ceiie e eerie e eeerrae e s ssraeeeessaeeeeessaneeeenns 1O\n2.3.52. Simple Type rr:RelationshipTYPEENUM .....c.uviii ittt seiee e sveeeesseaneeeeeees 7D\n2.3.53. Simple Type rr:PeriodTYPEENUM ....cc.viiii ittt eeree e e sreeeeesraeeee e SO\n2.3.54. Simple Type rr:RelationshipStatUSENUM .........cccciiiiiiiiiiie et seeee e S\n2.3.55. Simple Type rr:QualifierDimenSioNENUM .......ccccciiiiriiiiie et eree e eree e seeee e eeee 82\n2.3.56. Simple Type rr:QualifierCategoryTYPEENUM .. ...oviiiiiiieie ettt 83\n2.3.57. Simple Type rr:MeasurementMethodTypPeENUM .......ccvieiiiiiiiiiriiiiieee et sviieee e 88\n2.3.58. Simple Type rr:QuantifierUnitSTYPEENUM ....cciiciieie ettt eree et sreee e eeee 8D\n2.3.59. Simple Type rr:RegistrationStatUSENUM ......uiiiiiiiiiir ettt e srre e staae e s SO\n2.3.60. Simple Type rr:ValidationSourcesTYPEENUM ....c..uviieiicciieie et ctie et srre e e sraae e e 88\n2.3.61. Simple Type rr:ValidationDocumentsTYPEENUM .......cccveeeiiciiieieeeciiieee e ceiieee e seieeeeeseeeeeee e 89\n2.3.62. Simple Type rr:ToKenized500TYPE ...uuvveiicciiiieeeeciiieeeeeiieeeesestieeeeserneeesessseeeessssseeeesssssssesesnees 90\n\nPublic\n\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 4 of 90\n","contentLength":2417,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.543Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘3 LEl\nN’\n2.3.6. Element rr:RRHeaderType / DeltaStart\nThe date and time of the baseline relative to which this file contains new or changed\nRelationship Records.\nrr:LEIDateTimeProfile\ncontent simple\nminOccurs 0\n([T HINT*(\\((\\d){1,31)){0,2}))(Z| \\+([01][O-\npattern 9]]2[0-3]):([0-5][0-9]) | -([01][0-9] | 2[0-3]):([O-\n5][0-9]))\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 31 of 90\n","contentLength":442,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.543Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘% LE|\nN\n2.3.7. Element rr:RRHeaderType / RecordCount\nThe number of relationship records in the file.\nxs:nonNegativelnteger\ncontent simple\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 32 of 90\n","contentLength":253,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.543Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘3 LE|\nP\n2.3.8. Element rr:RRHeaderType / NextVersion\nA structure for adding further elements in to the LEI data file header in anticipation of a new\nversion, by nesting a series of XML elements with this content model within the\nNextVersion element, one for each new minor version of the schema, postpending a serial\nnumber (1,2,3...) to the element name upon each iteration.\nrr:HeaderNextVersionType\ncontent complex\nminOccurs 0\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 33 of 90\n","contentLength":544,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.543Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘3 LE|\nN\n2.3.9. Element rr:RRHeaderType / Extension\nThis Extension element may contain any additional elements required to extend the\nHeader container element.\nrr:ExtensionType\ncontent complex\nminOccurs 0\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 34 of 90\n","contentLength":319,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.543Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘% LE|\nN\n2.3.10. Element rr:RelationshipDataType / RelationshipRecords\nContainer for all of the RelationshipRecord container elements submitted with this file.\nrr:RelationshipRecordsType\ncontent complex\n\n{0,unbounded}\n\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 35 of 90\n","contentLength":417,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.543Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘3 LE|\nN’\n2.3.11. Element rr:RelationshipRecordsType / RelationshipRecord\nContains all relationship information including identifiers referring to the related entities,\nthe specific type and other attributes of the relationship itself, and details of the\nrelationship's registration with the ManagingLou.\nrr:RelationshipRecordType\ncontent complex\nminOccurs 0\nmaxOccurs unbounded\n\n{1l,1}\n{1l,1}\n{0,1}\n{0,1l}\n\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 36 of 90\n","contentLength":672,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.543Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘3' LE|\n2.3.12. Element rr:RelationshipRecordType / Relationship\nThe rRelationship container element contains the identifiers of the two entities related by\nthe reported relationship, as well as the type of relationship, dates related to the\nrelationship and other relationship quantifiers and qualifiers.\nrr:RelationshipContainerType\ncontent complex\n\n{1l,1}\n{1, 1}\n{1l,1}\n{0,1}\n{1,1}\n{0,unbounded}\n{0,unbounded}\n{0,1}\n{0,1l}\n\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 37 of 90\n","contentLength":883,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.543Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘3 LE|\nN\n2.3.13. Element rr:RelationshipContainerType / StartNode\nAn LEl or ISO 17442-compatible ID for the entity at the \"start\" of a directional relationship.\nrr:NodeType\ncontent complex\n\n{1l,1}\n{1l, 1}\n\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 38 of 90\n","contentLength":385,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.543Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘3 LE|\nN\n2.3.14. Element rr:NodeType / NodelD\nThe identifier for the entity designated by this node.\nrr:LEIType\ncontent simple\nminLength 20\nmaxLength 20\npattern ([0-9A-Z]{18}[0-9]{2})\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 39 of 90\n","contentLength":298,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.543Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘% LE|\nP\n2.3.15. Element rr:NodeType / NodelDType\nThe type of identifier used to designate this node's entity.\nrr:NodelDTypeEnum\ncontent simple\nenumeration LEI An LEI code taken from the LEl issuing prefix\nnamespace of a GLEIS LOU.\n. An ISO 17442-compatible code, not taken from\nenumeration IS0_17442_COMPATIBLE the LEl issuing prefix namespace of a GLEIS LOU.\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 40 of 90\n","contentLength":475,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.543Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘@ LE|\n\\I\n1. Introduction\nDocumentation updated: 2017-03-16\nThis XML schema defines a reporting format for relationship records for Global Legal Entity\nIdentifier System (GLEIS) Local Operating Units (LOUs) to report relationships between two\nlegal entities (one relationship per relationship record).\nTypes of relationship supported:\ne LEl to LEl relationships.\ne LEI to (GLEIS-internal) Provisional Node Identifier (PNI) for reporting parent entities\nwhich do not yet have an LEI.\n1.1. Status of this document\nThis section describes the status of this document at the time of its publication. Later\nversions may supersede this document. The most up to date version will always be\navailable from www.gleif.org.\nThe file format references and honors the policy document published by the LEI ROC\nentitled \"Collecting data on direct and ultimate parents of legal entities in the Global\nLEI System — Phase 1” (10 March 2016; available from www.leiroc.org).\n1.2. Terminology and Typographical Conventions\nThe following typographical conventions are used throughout the document:\no ALL CAPS type is used for the special terms enumerated above.\no Monospace type is used to denote programming language, UML, and XML\nidentifiers, as well as for the text of XML documents.\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 5 of 90\n","contentLength":1377,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.543Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘3 LE|\nN\n2.3.16. Element rr:RelationshipContainerType / EndNode\nAn LEl or ISO 17442-compatible ID for the entity at the \"end\" of a directional relationship.\nrr:NodeType\ncontent complex\n\n{1l,1}\n{1l, 1}\n\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 41 of 90\n","contentLength":377,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.543Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘@ LEI\n\\I\n2.3.17. Element rr:RelationshipContainerType / RelationshipType\nA unique code designating the specific category of a directional relationship between two\nlegal entities.\nrr:RelationshipTypeEnum\ncontent simple\nStartNode is directly consolidated by\nEndNode. The startNode \"child\" entity\nhas its accounts fully consolidated by\nthe EndNode \"parent\" entity, in the\nsense given by the accounting\nenumeration IS_DIRECTLY_CONSOLIDATED_BY standard(s) specified in\nRelationshipQualifiers; the EndNode\nentity is the closest fully consolidating\nparent to the startNode entity in any\napplicable hierarchical ownership\nstructure.\nStartNode is ultimately consolidated by\nEndNode. The startNode \"child\" entity\nhas its accounts fully consolidated by\nthe EndNode \"parent\" entity, in the\nsense given by the accounting\nenumeration IS_ULTIMATELY_CONSOLIDATED_BY standard(s) specified in\nRelationshipQualifiers; the EndNode\nentity is the most distant fully\nconsolidating parent from the\nStartNode entity in any applicable\nhierarchical ownership structure.\nStartNode is an international branch of\nthe legal entity designated by EndNode\nenumeration IS_INTERNATIONAL_BRANCH_OF (in jurisdiction country of startNode).\nThe EndNode is the Head Office and\nMUST be an LEI.\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 42 of 90\n","contentLength":1368,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.543Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘3 LE|\nN’\n2.3.18. Element rr:RelationshipContainerType / RelationshipPeriods\nA collection of paired beginning and end dates relating to: the relationship itself, periods\n(e.g. accounting cycles) covered by documents demonstrating the relationship, or the filing\ndate(s) of those documents.\nrr:RelationshipPeriodsType\ncontent complex\nminOccurs 0\n\n{1,unbounded}\n\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 43 of 90\n","contentLength":559,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.543Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘3 LE|\nN’\n2.3.19. Element rr:RelationshipPeriodsType / RelationshipPeriod\nContains one set of start and end dates for a particular type of period, for example, the\nduration of the relationship itself, the filing or validity period of any documents\ndemonstrating the relationship, or the accounting period they refer to.\nrr:RelationshipPeriodType\ncontent complex\nmaxOccurs unbounded\n\n{0,1}\n{0,1}\n{1l,1}\n\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 44 of 90\n","contentLength":626,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.544Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘; 3' LEl\n2.3.20. Element rr:RelationshipPeriodType / StartDate\nThe start date for a particular period relevant to the relationship.\nrr:LEIDateTimeProfile\ncontent simple\nminOccurs 0\n(IA\\T* AT\\ ((\\d){2,31){0,1})) (2| \\+([01][O-\npattern 9]]2[0-3]):([0-5][0-9]) | -([01][0-9] | 2[0-3]):([O-\n5][0-9]))\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 45 of 90\n","contentLength":413,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.544Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘; 3' LEl\n2.3.21. Element rr:RelationshipPeriodType / EndDate\nThe end date for a particular period relevant to the relationship.\nrr:LEIDateTimeProfile\ncontent simple\nminOccurs 0\n([T HINT*(\\((\\d){1,31)){0,2}))(Z| \\+([01][O-\npattern 9]]2[0-3]):([0-5][0-9]) | -([01][0-9] | 2[0-3]):([O-\n5][0-9]))\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 46 of 90\n","contentLength":409,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.544Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘@ LEI\n\\l\n2.3.22. Element rr:RelationshipPeriodType / PeriodType\nThe particular type of period, for example, the duration of the relationship itself, the filing or\nvalidity period of any documents demonstrating the relationship, or the accounting period\nthey refer to.\nrr:PeriodTypeEnum\ncontent simple\nThe dates in this instance of\nenumeration ACCOUNTING PERIOD Rel'ationshipPeriod indicate the acc'oun.tlng\n- period covered by the most recent validation\ndocuments for this relationship.\nThe dates in this instance of\nenumeration RELATIONSHIP PERIOD Rel'a'tionshipPeri'od |n.cI|<.:ate the dl.,lra'tlon of\n- validity of the relationship itself, as distinct from\nany administrative or reporting aspects.\nThe dates in this instance of\nRelationshipPeriod indicate the validity\nenumeration DOCUMENT_FILING_PERIOD period of a regulatory filing, accounting\ndocument, or other document demonstrating\nthe relationship's validity.\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 47 of 90\n","contentLength":1035,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.544Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘3 LE|\nN’\n2.3.23. Element rr:RelationshipContainerType / RelationshipStatus\nThe status of the legal entities' relationship itself: AcTIVE or INACTIVE.\nrr:RelationshipStatusEnum\ncontent simple\nAs of the last report or update, the reporting legal\nenumeration ACTIVE entity reported thatitis Iegal!y reg.lstered.and./or\noperating, AND that the relationship detailed in\nthis RelationshipRecord is still valid.\nIt has been determined that the relationship\nended, e.g. because entity that reported this\nenumeration INACTIVE relationship is no longer legally registered and/or\noperating; or the relationship is no longer valid for\nother reasons.\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 48 of 90\n","contentLength":753,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.544Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘3 LE|\nN\n2.3.24. Element rr:RelationshipContainerType / RelationshipQualifiers\nAny additional qualitative attributes that help to categorize the relationship.\nrr:RelationshipQualifiersType\ncontent complex\nminOccurs 0\nmaxOccurs unbounded\n\n{1, unbounded}\n\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 49 of 90\n","contentLength":465,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.544Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘3 LE|\nN\n2.3.25. Element rr:RelationshipQualifiersType / RelationshipQualifier\nContainer for all sets of relationship qualifier information.\nrr:RelationshipQualifierType\ncontent complex\nminOccurs 1\nmaxOccurs unbounded\n\n{1l,1}\n{0,1}\n\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 50 of 90\n","contentLength":475,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.544Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘@ LE|\n~?\n1.3. Cardinalities\n\no The cardinality of each element (the number of times it MUST or MAY appear\nin an XML data file conforming to this schema) is expressed as a number\nrange in the format {minimum occurrences, maximum occurrences} in the\nXML examples shown below the notes of its containing element. This\nnotation is equivalent to the following explanations in words:\n\n= Mandatory, unique: {1, 1} - the element MUST appear, exactly once.\n\n= Mandatory, repeatable: {1, unbounded} - the element MUST appear\nat least once. It may be repeated any number of times.\n\n= QOptional, unique: {0, 1} - the element NEED NOT appear; it MAY\nappear once at most.\n\n= QOptional, repeatable: {0, unbounded} - the element NEED NOT\nappear. It MAY be repeated any number of times.\n\nPlease note:\n\no The default cardinality is {1,1} (mandatory, unique). This document highlights\nwhen an element differs from this either by its minoccurs (minimum\noccurrences) or maxoccurs (maximum occurrences) value, or both.\n\no XML cardinalities apply in the context of any containing elements. This means\nthat a contained element may have a cardinality of one or more even if its\ncontaining element may be omitted, because the contained element is\nmandatory given the presence of the container.\n\no XML cardinalities enforce a minimum data quality and standards\nconformance. Other business rules (as explained below) and data quality\nchecks applied by GLEIF may encourage stricter cardinalities in live\nimplementations.\n\n1.4. Business Rules\nThe accompanying documentation in addition to this Technical Specification specifies\nbusiness rules where applicable for each element. These are rules that are not\nenforced by validating against the XML schema, but are still mandatory for all\nCommon Data File (CDF) format files.\n1.5. XML Syntax\nThis section specifies the XML schema for an LEI data file conforming to this\nstandard.\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 6 of 90\n","contentLength":2011,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.544Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘3 LE|\nN’\n2.3.26. Element rr:RelationshipQualifierType / QualifierDimension\nDesignates the optional list of additional qualitative attributes that help to categorize the\nrelationship.\nrr:QualifierDimensionEnum\ncontent simple\nThe accounting standard applied to determine the\ndefinition of e.g. ultimate or direct accounting\nenumeration ACCOUNTING STANDARD f:ons.olldatmg parent for the relationship detailed\n- in this RelationshipRecord. The relevant\naccounting standard is that applicable to the\nEndNode (the \"parent\" entity).\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 51 of 90\n","contentLength":641,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.545Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘3' LE|\n2.3.27. Element rr:RelationshipQualifierType / QualifierCategory\nSpecifies the additional qualitative attributes that help to categorize the relationship.\nrr:QualifierCategoryTypeEnum\ncontent simple\nminOccurs 0\ni - ly A\nenumeration US_GAAP United S.tates .Ge.nera y Accepted\nAccounting Principles.\nInternational Financial Reporting Standard\n. (developed by the International\nIFR\nenumeration IFRS Accounting Standards Board — IASB see\nhttp://www.ifrs.org).\nA financial reporting (accounting)\nenumeration OTHER_ACCOUNTING_STANDARD °t2\"dard not otherwise listed in the latest\n- version of the relationship data file\nformat.\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 52 of 90\n","contentLength":744,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.545Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘; e LEl\nN’\n2.3.28. Element rr:RelationshipContainerType / RelationshipQuantifiers\nAny additional quantitative attributes that help to categorize the relationship.\nrr:RelationshipQuantifiersType\ncontent complex\nminOccurs 0\nmaxOccurs unbounded\n\n{1,unbounded}\n\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 53 of 90\n","contentLength":474,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.545Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘% LE|\nN’\n2.3.29. Element rr:RelationshipQuantifiersType / RelationshipQuantifier\nSpecifies one additional quantitative attribute of the relationship, according to a particular\nmeasurement method.\nrr:RelationshipQuantifierType\ncontent complex\nminOccurs 1\nmaxOccurs unbounded\n\n{1, 1}\n{1, 1}\n{0,1}\n\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 54 of 90\n","contentLength":572,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.545Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘3 LE|\nN’\n2.3.30. Element rr:RelationshipQuantifierType / MeasurementMethod\nSpecifies the method of measurement (or set of rules) used to quantitatively categorize the\nrelationship.\nrr:MeasurementMethodTypeEnum\ncontent simple\nAccounting consolidation holds when \"[in the]\nfinancial statements of a group [...] the assets,\nliabilities, equity, income, expenses and cash\nenumeratio ACCOUNTING_CONSOLIDATIO flows of the parent and its subsidiaries are\nn N presented as those of a single economic entity\n(please see\nhttp://www.iasplus.com/en/standards/ias/ias\n27-2011).\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 55 of 90\n","contentLength":680,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.545Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘% LE|\nN\n2.3.31. Element rr:RelationshipQuantifierType / QuantifierAmount\nSpecifies the quantity measured as a decimal (positive or negative) number, using a . as the\ndecimal point, with no spaces, and without thousand delimiters (e.g. , ).\nxs:decimal\ncontent simple\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 56 of 90\n","contentLength":381,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.546Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘% LE|\nN\n2.3.32. Element rr:RelationshipQuantifierType / QuantifierUnits\nSpecifies the units, where applicable, of a measurement made on a relationship.\nrr:QuantifierUnitsTypeEnum\ncontent simple\nminOccurs 0\nenumeration PERCENTAGE\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 57 of 90\n","contentLength":345,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.546Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘3 LE|\nN’\n\n2.3.33. Element rr:RelationshipContainerType / NextVersion\nA structure for adding further elements in to the rRegistration section of the Relationship\nRecord in anticipation of a new version, by nesting a series of XML elements with this\ncontent model within the Nextversion element, one for each new minor version of the\nschema, postpending a serial number (1,2,3...) to the element name upon each iteration.\nrr:RelationshipNextVersionType\ncontent complex\nminOccurs 0\n\nPublic\n\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 58 of 90\n","contentLength":596,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.546Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘3 LEl\nN\n2.3.34. Element rr:RelationshipContainerType / Extension\nThis Extension element may contain any additional elements required to extend the\nRelationship container element.\nrr:ExtensionType\ncontent complex\nminOccurs 0\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 59 of 90\n","contentLength":339,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.546Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 3' LE|\n2.3.35. Element rr:RelationshipRecordType / Registration\nThe rRegistration container element contains information specifying the LOU's\nadministration of the relationship report.\nrr:RegistrationContainerType\ncontent complex\n\n{1l,1}\n{1,1}\n{1,1}\n{0,1}\n{1,1}\n{1l,1}\n{1l,1}\n{0,1}\n{0,1}\n{0,1l}\n\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 60 of 90\n","contentLength":801,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.546Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"]\nRelationship Record Common Data File format V1.1 @ LE|\n1.5.1. XML Design Rules\n\no The XSD schema conforms to W3C's XML Schema specification, version 1.0.\n\no The XML namespace is \"http://www.gleif.org/data/schema/rr/2016\".\n\no Allinterior XML elements are namespace-qualified (element form =\nqualified).\n\no Al XML attributes are in the null namespace (attribute form = unqualified),\nwith the exception of xm1:1ang.\n\no Element names are upper camel case.\n\no Attribute name are lower camel case.\n\no XSD type names are upper camel case.\n\no Enumeration code list values are all caps with underscores.\n\no Elements are used in preference to attributes except for language and type\nqualifiers.\n\no For a data element specified as having unbounded cardinality, the XML\nincludes a single container element whose subelements are one or more\ninstances of the data element whose cardinality is unbounded. The name of\nthe container element is formed as the plural of the name of the contained\nelements.\n\n1.5.2. XML Schema\nAn XML file conforming to this standard is valid according to the following XSD 1.0\nschema.\n\n\n\n\n\n\n\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 7 of 90\n","contentLength":1727,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.546Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘3 LE|\nP\n2.3.36. Element rr:RegistrationContainerType / InitialRegistrationDate\nThe date at which the relationship information was first collected by the ManagingLou.\nrr:LEIDateTimeProfile\ncontent simple\n(IA\\T* AT\\ ((\\d){2,31){0,1})) (2| \\+([01][O-\npattern 9] 2[0-3]):([0-5][0-9]) | -([01][0-9] | 2[0-3]):([O-\n5][0-9]))\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 61 of 90\n","contentLength":434,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.546Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘3 LE|\nP\n2.3.37. Element rr:RegistrationContainerType / LastUpdateDate\nThe date at which the information was most recently updated by the ManagingLou.\nrr:LEIDateTimeProfile\ncontent simple\n(IA\\T* AT\\ ((\\d){2,31){0,1})) (2| \\+([01][O-\npattern 9] 2[0-3]):([0-5][0-9]) | -([01][0-9] | 2[0-3]):([O-\n5][0-9]))\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 62 of 90\n","contentLength":418,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.547Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘@ LE|\n\\I\n2.3.38. Element rr:RegistrationContainerType / RegistrationStatus\nThe status of the legal entity's relationship record registration with the ManagingLou.\nrr:RegistrationStatusEnum\ncontent simple\nA relationship data report that has been\nenumeration PENDING_VALIDATION submitted to the LOU and which is being\nprocessed and validated, prior to publication.\nA relationship data report that has been validated\nenumeration PUBLISHED and published, and'whlch is reported by an entity\nthat was an operating legal entity as of the last\nupdate.\nA relationship data report that has been\ndetermined to be a duplicate registration of the\nsame relationship. In many cases this will mean\ni .8. 2 i\nenumeration DUPLICATE more than one repprt w!th e.g. the sa.me entity\nIDs, the same relationship type, certain status\nvalues and the same relationship date(s), but this\ndetermination will depend on the relationship\ntype in question.\nenumeration LAPSED A relationship data report that has not been\nrenewed by the NextRenewalDate.\nThe relationship is considered to have ended, but\nenumeration RETIRED the relationship report is kept in publication for\nhistorical audit trail purposes.\nA relationship data report that was marked as\nerroneous or invalid after it was published. The\nenumeration ANNULLED relationship report is kept in publication for\nhistorical audit trail purposes only (so that data\nrecipients can correct their local data).\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 63 of 90\n","contentLength":1546,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.547Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘@, LEI\nA relationship data report that has been\ntransferred to a different LOU as the\n\nenumeration TRANSFERRED ManagingLoU. A record in this state is not\npublished, but may be used internally by the prior\nLOU for audit trail purposes.\nA relationship data report for which a transfer to\nanother LOU has been requested. The request is\n. being processed at the sending LOU. When the\nPENDING_TRANSFER\nenumeration G- S receiving LOU is ready, the status will be changed\nto PENDING ARCHIVAL by the sending LOU prior\nto completion of the transfer.\nThis relationship data report is about to be\ntransferred to a different LOU, after which its\nregistration status will revert to a non-pending\nenumeration PENDING_ARCHIVAL status. The PENDING ARCHIVAL status serves to\ninform recipients of LOU-provided data files that a\nrelationship record will be removed from that\nLOU’s published file after the transfer is complete\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 64 of 90\n","contentLength":1023,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.547Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘3 LEl\nP\n2.3.39. Element rr:RegistrationContainerType / NextRenewalDate\nThe next date by which the relationship information must be renewed and re-certified by\nthe legal entity.\nrr:LEIDateTimeProfile\ncontent simple\nminOccurs 0\n(IA\\T* AT\\ ((\\d){2,31){0,1})) (2| \\+([01][O-\npattern 9]]2[0-3]):([0-5][0-9]) | -([01][0-9] | 2[0-3]):([O-\n5][0-9]))\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 65 of 90\n","contentLength":458,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.547Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘% LEl\nN\n2.3.40. Element rr:RegistrationContainerType / ManagingLOU\nThe LEI of the LOU that is responsible for administering this relationship record.\nrr:LEIType\ncontent simple\nminLength 20\nmaxLength 20\npattern ([0-9A-Z]{18}[0-9]{2})\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 66 of 90\n","contentLength":348,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.547Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘@, LE|\n2.3.41. Element rr:RegistrationContainerType / ValidationSources\nLevel of relationship validation.\nrr:ValidationSourcesTypeEnum\ncontent simple\nThe validation of the relationship data provided\n. by the registrant has not yet occurred. Records\nenumeration PENDING with this validationSources value MUST not\nbe published.\nBased on the validation procedures in use by\nthe LOU responsible for the record, the\nenumeration ENTITY_SUPPLIED_ONLY |r.\\fo.rr'nat|on a'ssoaated Wlt'h this resord has\nsignificant reliance on the information that a\nsubmitter provided due to the unavailability of\ncorroborating information.\nBased on the validation procedures in use by\nthe LOU responsible for the record, the\ninformation supplied by the submitter can be\npartially corroborated by supporting sources\nenumeration PARTIALLY_CORROBORATED (e.g. financial statements with other definitions\nof the relevant relationship type; quarterly or\nannual regulatory filings, contracts and other\ndocuments used in preparing financial\nstatements).\nThe relationship data provided by the registrant\n. . lici\nenumeration FULLY_CORROBORATED 1'2s been validated against an explicit\n- relationship statement found in key sources\n(e.g. consolidated financial statements).\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 67 of 90\n","contentLength":1355,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.547Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘% LEI\nP\n2.3.42. Element rr:RegistrationContainerType / ValidationDocuments\nType of source document(s) used for validating the relationship.\nrr:ValidationDocumentsTypeEnum\ncontent simple\nA consolidated financial (accounting)\nenumeration ACCOUNTS_FILING statement, prepared and submitted to the\nrelevant authority.\nenumeration REGULATORY_FILING An annual regulatory filing providing public\n- information on parent relationships.\nenumeration SUPPORTING_DOCUMENTs OLne\" documents supporting the preparation\nof consolidated financial statements.\nenumeration CONTRACTS Cont.ract(s') attesting to the validity of the\nrelationship.\nenumeration OTHER_OFFICIAL_DOCUMENTs Other official document(s) attesting to the\n- - validity of the relationship.\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 68 of 90\n","contentLength":855,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.547Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘3 LE|\nN\n2.3.43. Element rr:RegistrationContainerType / ValidationReference\nA reference to a specfic document or other source used as the basis of relationship\nvalidation for this relationship record.\nrr:Tokenized500Type\ncontent simple\nminOccurs 0\nminLength 1\nmaxLength 500\npattern \\S+( \\S+)*\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 69 of 90\n","contentLength":408,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.547Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘3 LE|\nN’\n\n2.3.44. Element rr:RegistrationContainerType / NextVersion\nA structure for adding further elements in to the Registration section of the Relationship\nRecord in anticipation of a new version, by nesting a series of XML elements with this\ncontent model within the Nextversion element, one for each new minor version of the\nschema, postpending a serial number (1,2,3...) to the element name upon each iteration.\nrr:RegistrationNextVersionType\ncontent complex\nminOccurs 0\n\nPublic\n\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 70 of 90\n","contentLength":595,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.547Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"- ]\nRelationship Record Common Data File format V1.1 @ LE|\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 8 0of 90\n","contentLength":1303,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.547Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘3 LEl\nN\n2.3.45. Element rr:RegistrationContainerType / Extension\nThis Extension element may contain any additional elements required to extend the\nRegistration container element.\nrr:ExtensionType\ncontent complex\nminOccurs 0\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 71 of 90\n","contentLength":339,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.548Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘3 LE|\nN’\n\n2.3.46. Element rr:RelationshipRecordType / NextVersion\nA structure for adding further elements in to the rRegistration section of the Relationship\nRecord in anticipation of a new version, by nesting a series of XML elements with this\ncontent model within the Nextversion element, one for each new minor version of the\nschema, postpending a serial number (1,2,3...) to the element name upon each iteration.\nrr:RelationshipRecordNextVersionType\ncontent complex\nminOccurs 0\n\nPublic\n\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 72 of 90\n","contentLength":599,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.548Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘3 LE|\nN\n2.3.47. Element rr:RelationshipRecordType / Extension\nThis Extension element may contain any additional elements required to extend the\nRelationshipRecord.\nrr:ExtensionType\ncontent complex\nminOccurs 0\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 73 of 90\n","contentLength":324,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.548Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"- ________0____000___]\nRelationship Record Common Data File format V1.1 ‘% LE|\nN\n2.3.48. Simple Type rr:LEIDateTimeProfile\nType restriction of xs:dateTime\n(IA\\T* AT\\ ((\\d){2,31){0,1})) (2| \\+([01][O-\nFacets pattern 9] 2[0-3]):([0-5][0-9]) | -([01][0-9] | 2[0-3]):([O-\n5][0-9]))\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 74 of 90\n","contentLength":343,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.548Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘% LEl\nN\n2.3.49. Simple Type rr:LEIType\nType restriction of xs:string\nminLength 20\nFacets maxLength 20\npattern ([0-9A-Z]{18}{0-9]{2})\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 75 of 90\n","contentLength":248,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.548Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘@ LE|\n~?\n2.3.50. Simple Type rr:FileContentEnum\nrestriction of xs:string\nThe file contains all relationship records created\nfor internal use by an LOU (all internal\nenumeration LOU_FULL_INTERNAL relationship records for which the LOU is the\nManagingLoU) as of the date/time the file is\ncreated.\nThe file contains those relationship records\ncreated by an LOU for internal use (all internal\nenumeration LOU DELTA INTERNAL relationship recor.ds for which the LOU is the\n- - ManagingLou) which are new or changed since\nthe Deltastart specified in the Header, as of the\ndate/time the file is created.\nThe file contains all relationship records published\n. by an LOU (all relationship records for which the\nenumeration LOU_FULL_PUBLISHED LOU is the ManagingLou) as of the date/time the\nfile is created.\nThe file contains those relationship records\npublished by an LOU (all relationship records for\nenumeration LOU_DELTA_PUBLISHED which the LOU is the ManagingLou) which are\nnew or changed since the peltastart specified in\nthe Header, as of the date/time the file is created\nThe file contains all relationship records GLEIF\nenumeration GLEIE FULL INTERNAL manages mtgrnallY to the GLEIS (including all\n- - internal relationship records from all LOUs) as of\nthe date/time the file is created.\nThe file contains those relationship records GLEIF\nmanages internally to the GLEIS (including all\nenumeration GLEIE DELTA INTERNAL internal relationship r.ecords from all LOUs) which\n- - are new or changed since the peltastart date\nspecified in the Header, as of the date/time the\nfile is created.\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 76 of 90\n","contentLength":1699,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.549Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘3 LE|\nP\nThe file contains all relationship records published\nenumeration GLEIF_FULL_PUBLISHED by GLEIF (including all relationship records from\nall LOUs) as of the date/time the file is created.\nThe file contains those relationship records\npublished by GLEIF (including all relationship\nenumeration GLEIF_DELTA_PUBLISHED records from all LOUs) which are new or changed\nsince the peltastart date specified in the\nHeader, as of the date/time the file is created.\n. . hi o\nenumeration QUERY_RESPONSE The fll.e cc?ntalns records matching criteria\nspecified in a query.\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 77 of 90\n","contentLength":680,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.549Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘3 LE|\nN\n2.3.51. Simple Type rr:NodelDTypeEnum\nrestriction of xs:string\nenumeration LEI An LEI code taken from the LEl issuing prefix\nnamespace of a GLEIS LOU.\n. An ISO 17442-compatible code, not taken from\nenumeration 1S0_17442_COMPATIBLE the LEl issuing prefix namespace of a GLEIS LOU.\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 78 of 90\n","contentLength":403,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.549Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"]\nRelationship Record Common Data File format V1.1 @ LE|\n2.3.52. Simple Type rr:RelationshipTypeEnum\n\nrestriction of xs:string\nStartNode is directly consolidated by\nEndNode. The startNode \"child\" entity\nhas its accounts fully consolidated by\nthe EndNode \"parent\" entity, in the\nsense given by the accounting\n\nenumeration IS_DIRECTLY_CONSOLIDATED_BY standard(s) specified in\nRelationshipQualifiers; the EndNode\nentity is the closest fully consolidating\nparent to the startNode entity in any\napplicable hierarchical ownership\nstructure.\nStartNode is ultimately consolidated by\nEndNode. The startNode \"child\" entity\nhas its accounts fully consolidated by\nthe EndNode \"parent\" entity, in the\nsense given by the accounting\n\nenumeration IS_ULTIMATELY_CONSOLIDATED_BY standard(s) specified in\nRelationshipQualifiers; the EndNode\nentity is the most distant fully\nconsolidating parent from the\nStartNode entity in any applicable\nhierarchical ownership structure.\nStartNode is an international branch of\nthe legal entity designated by EndNode\n\nenumeration IS_INTERNATIONAL_BRANCH_OF (in jurisdiction country of startNode).\nThe EndNode is the Head Office and\nMUST be an LEI.\n\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 79 of 90\n","contentLength":1231,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.549Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘@ LE|\nN’\n2.3.53. Simple Type rr:PeriodTypeEnum\nrestriction of xs:string\nThe dates in this instance of\nenumeration ACCOUNTING PERIOD Rel'ationshipPeriod indicate the acc'oun.tlng\n- period covered by the most recent validation\ndocuments for this relationship.\nThe dates in this instance of\nenumeration RELATIONSHIP PERIOD Rel'a'tionshipPeri'od |n.cI|<.:ate the dl.,lra'tlon of\n- validity of the relationship itself, as distinct from\nany administrative or reporting aspects.\nThe dates in this instance of\nRelationshipPeriod indicate the validity\nenumeration DOCUMENT_FILING_PERIOD period of a regulatory filing, accounting\ndocument, or other document demonstrating\nthe relationship's validity.\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 80 of 90\n","contentLength":806,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.549Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"- ]\nRelationship Record Common Data File format V1.1 @ LE|\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 9 of 90\n","contentLength":1366,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.549Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘3 LE|\nN’\n2.3.54. Simple Type rr:RelationshipStatusEnum\nrestriction of xs:string\nAs of the last report or update, the reporting legal\n. entity reported that it is legally registered and/or\nACTIVE\nenumeration AC operating, AND that the relationship detailed in\nthis RelationshipRecord is still valid.\nIt has been determined that the relationship\nended, e.g. because entity that reported this\nenumeration INACTIVE relationship is no longer legally registered and/or\noperating; or the relationship is no longer valid for\nother reasons.\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 81 of 90\n","contentLength":647,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.549Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘3 LE|\nN’\n2.3.55. Simple Type rr:QualifierDimensionEnum\nrestriction of xs:string\nThe accounting standard applied to determine the\ndefinition of e.g. ultimate or direct accounting\nenumeration ACCOUNTING_STANDARD f:ons.olldatmg parenf for the relationship detailed\nin this RelationshipRecord. The relevant\naccounting standard is that applicable to the\nEndNode (the \"parent\" entity).\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 82 of 90\n","contentLength":495,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.549Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘3' LE|\n2.3.56. Simple Type rr:QualifierCategoryTypeEnum\nrestriction of xs:string\nenumeration US_GAAP United S.tates—.Ge.neraIIy Accepted\nAccounting Principles.\nInternational Financial Reporting Standard\n. (developed by the International\nIFR\nenumeration IFRS Accounting Standards Board — IASB see\nhttp://www.ifrs.org).\nA financial reporting (accounting)\nenumeration OTHER_ACCOUNTING_STANDARD °tandard not otherwise listed in the latest\n= - version of the relationship data file\nformat.\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 83 of 90\n","contentLength":600,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.549Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘3 LEl\nN’\n2.3.57. Simple Type rr:MeasurementMethodTypeEnum\nrestriction of xs:string\nAccounting consolidation holds when \"[in the]\nfinancial statements of a group [...] the assets,\nliabilities, equity, income, expenses and cash\nenumeratio ACCOUNTING_CONSOLIDATIO flows of the parent and its subsidiaries are\nn N presented as those of a single economic entity\n(please see\nhttp://www.iasplus.com/en/standards/ias/ias\n27-2011).\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 84 of 90\n","contentLength":538,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.549Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘% LE|\nN\n2.3.58. Simple Type rr:QuantifierUnitsTypeEnum\nrestriction of xs:string\nenumeration PERCENTAGE\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 85 of 90\n","contentLength":218,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.549Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘@ LE|\n~?\n2.3.59. Simple Type rr:RegistrationStatusEnum\nrestriction of xs:string\nA relationship data report that has been\nenumeration PENDING_VALIDATION submitted to the LOU and which is being\nprocessed and validated, prior to publication.\nA relationship data report that has been validated\nenumeration PUBLISHED and published, and'whlch is reported by an entity\nthat was an operating legal entity as of the last\nupdate.\nA relationship data report that has been\ndetermined to be a duplicate registration of the\nsame relationship. In many cases this will mean\nenumeration DUPLICATE more than one repprt w!th e.g. the sa.me 2 entity\nIDs, the same relationship type, certain status\nvalues and the same relationship date(s), but this\ndetermination will depend on the relationship\ntype in question.\ni i hat h\nenumeration LAPSED A relationship data report that has not been\nrenewed by the NextRenewalDate.\nThe relationship is considered to have ended, but\nenumeration RETIRED the relationship report is kept in publication for\nhistorical audit trail purposes.\nA relationship data report that was marked as\nerroneous or invalid after it was published. The\nenumeration ANNULLED relationship report is kept in publication for\nhistorical audit trail purposes only (so that data\nrecipients can correct their local data).\nA relationship data report that has been\nenumeration TRANSFERRED transferred to a different LOU as the\nManagingLoU. A record in this state is not\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 86 of 90\n","contentLength":1570,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.549Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘3' LEI\npublished, but may be used internally by the prior\nLOU for audit trail purposes.\nA relationship data report for which a transfer to\nanother LOU has been requested. The request is\n. being processed at the sending LOU. When the\nenumeration PENDING_TRANSFER receiving LOU is ready, the status will be changed\nto PENDING ARCHIVAL by the sending LOU prior\nto completion of the transfer.\nThis relationship data report is about to be\ntransferred to a different LOU, after which its\nregistration status will revert to a non-pending\nenumeration PENDING_ARCHIVAL status. The PENDING ARCHIVAL status serves to\ninform recipients of LOU-provided data files that a\nrelationship record will be removed from that\nLOU’s published file after the transfer is complete\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 87 of 90\n","contentLength":871,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.549Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘@ LE|\n\\I\n2.3.60. Simple Type rr:ValidationSourcesTypeEnum\nrestriction of xs:string\nThe validation of the relationship data provided\n. by the registrant has not yet occurred. Records\nenumeration PENDING with this validationSources value MUST not\nbe published.\nBased on the validation procedures in use by\nthe LOU responsible for the record, the\nenumeration ENTITY SUPPLIED ONLY |r.\\fo.rr'nat|on a'ssoaated Wlt'h this resord has\n- - significant reliance on the information that a\nsubmitter provided due to the unavailability of\ncorroborating information.\nBased on the validation procedures in use by\nthe LOU responsible for the record, the\ninformation supplied by the submitter can be\npartially corroborated by supporting sources\nenumeration PARTIALLY_CORROBORATED (e.g. financial statements with other definitions\nof the relevant relationship type; quarterly or\nannual regulatory filings, contracts and other\ndocuments used in preparing financial\nstatements).\nThe relationship data provided by the registrant\nenumeration FULLY_CORROBORATED 1'2s been validated against an explicit\nrelationship statement found in key sources\n(e.g. consolidated financial statements).\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 88 of 90\n","contentLength":1281,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.549Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘@ LE|\nP\n2.3.61. Simple Type rr:ValidationDocumentsTypeEnum\nrestriction of xs:string\nA consolidated financial (accounting)\nenumeration ACCOUNTS_FILING statement, prepared and submitted to the\nrelevant authority.\nenumeration REGULATORY FILING An annua?l regulatory filing Prowc!mg public\n- information on parent relationships.\nenumeration SUPPORTING_DOCUMENTs OLne\" documents supporting the preparation\n- of consolidated financial statements.\nenumeration CONTRACTS Cont.ract(s') attesting to the validity of the\nrelationship.\nenumeration OTHER_OFFICIAL_DOCUMENTs Other official document(s) attesting to the\n- - validity of the relationship.\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 89 of 90\n","contentLength":755,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.550Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"Relationship Record Common Data File format V1.1 ‘3 LE|\nN’\n2.3.62. Simple Type rr:Tokenized500Type\nAn element of this type has minimum length of one character and may not contain any of:\nthe carriage return (#xD), line feed (#xA) nor tab (#x9) characters, shall not begin or end with\na space (#x20) character, or a sequence of two or more adjacent space characters.\nrestriction of xs:string\nminLength 1\nmaxLength 500\npattern \\S+( \\S+)*\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 90 of 90\n","contentLength":501,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.550Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf","content":"- ]\nRelationship Record Common Data File format V1.1 @ LEI\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nPublic\nAuthor: GLEIF | Version: Final | 2017-03-16 Page 10 of 90\n","contentLength":1487,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:57:15.550Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_reporting-exceptions-format-v1-1.pdf","content":"T\nd,|E| .\n\nPublic\nReporting Exceptions Format V1.1\nFinal V1.1\n\n///\"/::—# o\na (, @D/ /’ s\n\no — g\n~ (@)\n© .\n| () |\n","contentLength":113,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:58:39.800Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_reporting-exceptions-format-v1-1.pdf","content":"]\nReporting Exceptions Format V1.1 @ LEl\nContents\n1. Reporting Exceptions FOrmat Version 1.0........coooiiiiiiiiiiiiiiieii e e e e ee e eeeeeeeeeeeeeeneeeeeenenenennenn &\n\n1.2, INTFOAUCTION 1.ttt ettt ettt ettt e ettt e sabe e e s eeesnbeeessseeenseeesubaeasnseessnneessnseeenaneessneees &b\n1.2. Audience for this dOCUMENT......ccciiiiiiiie et s esree s sve e s s seeeeneeesanne e B\n1.3. Status of this dOCUMENT .....coiuiiiiiiiei et ettt s e e e s sne e s s sneeenneeesanne e B\n1.4. Terminology and Typographical CoONVENTIONS........c.ccccviiiiiiiiiei e ctiie e cree s etee e e eree e e seeee e e saees D\n1.5, CardiN@lItI®S ..eeeeeeiieieeeie ettt ettt e et st ettt st e et e ee st e e s tbe et e sabteanreee e D\n1.6. BUSINESS RUIES .....ieiiiie ettt ettt ettt et s sb e e et eesatbe e s bt ee st e e e sbbaeenteessubeesanseesnnseesssseess ©\n1.7. REIEASE NOLES ...eueteiiiiie ettt ettt ettt et et s st te e et ee s sbbe e et eesabbeessbbeesaneeeesbsaeeanteessubeesanseesnnseesssseees ©\nI I =T YT o T O PP PP PPPOPTPPUPRPY o\n1.7.2.VErSION 1.0 iiiiiiiiiiiiiitie ettt e s st aeae s teeses s s snnnees O\n1.8. Change ManagemMENT.......ceiiicciiieieieeiieee ettt e eeeeettteessettteee s tteeaestteeessantsteessannsteeessnsssesesssssssesssnanses O\nR T I AV 1 g Yo T YA =T £ o o PP TP PP OPTPPTPRRPY o\n1.8.2. MAJOT VEISION eeetitiiiititititie e ee e ee e e e e e eeeeeeetetetetetteeeeeesesessss s s sesesesesesaneseseeeesesesensenesennens ]\n1.8.3. Minor Version Changes to the XML SChema ........ccoiviiiiiiiiiiiie e ceseceeessieee s seee s e s seeeees 7\n1.8.4. Major Version Changes to the XML SChemMa.......ccciiiiiiiiiiiiiiiie et seeee e O\n1.9, XIMIL SYNTAX . iiiiieeieieietitit ittt s e e e e e e e e e e e e eeeeeeeteteeae et ae e sent st st s sss s e snaeeesasaseaeeeeesneneeesserenennsns O\n1.9.1. XML DESIZN RUIES..cciiciiiie ettt ettt ettt te ettt ee s et eess st ee s s s saaeee s essasseeeassnsnneeassssnneesessnnneeees O\n1.9.2. XIMIL SCREMIA ettt ettt ettt st e s bt st e s st ee et e s sbbe e et ee s sabeassnseesanbeesnssaesnneeeessneeenne O\n1.9.3. EXTENSION ceiiiiiiiiiciitttt ettt ee e e ee e s s e s sesseaeteseeessessennnnene L3\n2. AbStract Data CONTENT.....uiiiiiie ettt ettt ettt ettt ee et e s sbee et eesabeeesneeesubeessnsaeennneessusseensseeesnneees LD\n2.1. Data Element REFEIENCE .....cei ittt ettt e e s bt testeeesabe e enneessuveennns 1O\n2.1.1. Element repex:ReportingEXceptionData ......ccceeeeeviieerieciiieie e e cetrie e seieeee s seveeeeessvnneeeeeens L7\n2.1.2. Element repex:ReportingExceptionDataType / repex:Header .........ccccevveeeceveeiiieeccceee e 18\n2.1.3. Element repex:ExceptionHeaderType / repex:ContentDate .........cccccveevvveeeceeeesieescceeeesennnnnnn 19\n2.1.4. Element repex:ExceptionHeaderType / repex:0riginator .......cccccceeeveeeivieeceeeesieeeecneeeenennnn 20\n2.1.5. Element repex:ExceptionHeaderType / repex:FileContent........cccceecvvvevvrveecceeeevieeceeeesnneannn 21\n2.1.6. Element repex:ExceptionHeaderType / repex:DeltaStart .......ccccocevviivevceveecceeecciieeeeee e 22\n2.1.7. Element repex:ExceptionHeaderType / repex:RecordCount.........ccccvvevcrveeeiereiiieecceeesnneenenn 23\n2.1.8. Element repex:ExceptionHeaderType / repex:NexXtVersion.......ccccveeecceeeevieeecceeessivesncnenennnn 24\n2.1.9. Element repex:ExceptionHeaderType / repexX:EXteNSION .....ccecccveeeiiieecsieeeciee e e eeee e 25\n2.1.10. Element repex:ReportingExceptionDataType / repex:ReportingExceptions........................ 26\nPublic\nAuthor: GLEIF | Version: Final V1.1 | Page 2 of 45\n","contentLength":3516,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:58:39.800Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_reporting-exceptions-format-v1-1.pdf","content":"- ]\nReporting Exceptions Format V1.1 @ LEl\n \n \n \n\n\n \n\n\n\n\n\n\n\n\n\n \n \n \n \n\n \n\n\n\n\n \n\n\n\n\n\n\n\n \n\n\n\n\n \n \n \n \n \n \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n1.9.3. Extension\nThe optional Extension section of a Reporting Exception Item may be used to include\nadditional data not defined in this standard. This may include data specific to an LOU, data\nspecific to a publisher of LEI data, and so on.\nFor example, an LOU may use Extension to publish additional data elements it collects as\npart of registration.\nThe following rules MUST be observed:\nPublic\nAuthor: GLEIF | Version: Final V1.1 | Page 13 of 45\n","contentLength":1278,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:58:39.800Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_reporting-exceptions-format-v1-1.pdf","content":"Reporting Exceptions Format V1.1 ‘% LE|\n\\l\n\n¢ Each XML element included in the content of the Extension element SHALL be in an\nXML namespace that is not null and not equal to the XML namespace of the LElI Data\nFile as specified in this standard.\n\ne The XML namespace for an extension element SHALL be a namespace to which the\ncreator of the extension element is entitled to use; e.g., a namespace derived from\nthe Internet Domain Name of the creator, a namespace agreed upon by a group of\ntrading partners, etc.\n\n¢ An extension element SHALL NOT be defined in such a way as to require the recipient\nof the file to recognize the extension element in order to interpret the data elements\nspecified in this standard. A recipient of the file MUST be able to ignore all extension\nelements and still interpret the standard content correctly.\n\ne Arecipient of a data file conforming to this standard SHALL NOT reject a file solely\nbecause it contains extensions not understood by the recipient. A recipient MUST be\nprepared to accept a file containing extensions and ignore any it does not\nunderstand, provided that the file complies to this standard.\n\n2. Abstract Data Content\nThis section specifies the abstract data content of a data file conforming to this standard.\no\nrepex:ExceptionHeaderType\n[ ] ReportingExceptionDataType e\nA data file conforming to this standard SHALL consist of:\ne AHeader:\nPublic\nAuthor: GLEIF | Version: Final V1.1 | Page 14 of 45\n","contentLength":1453,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:58:39.800Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_reporting-exceptions-format-v1-1.pdf","content":"Reporting Exceptions Format V1.1 e' LE'\n® [ ] repex:ExceptionHeaderType\no\nrepex:LEIDateTimeProfile\n‘Originator | ®\n( 'l'ype | repex:LEIType |\n(FileContent | o\nrepex:FileContentEnum\n\" DeltaStart\n@)oo o ©\nType repex:LEIDateTimeProfile\n5\nxs:nonNegativelnteger\n‘NextVersion ®\n| Type | repex:HeaderNextVersionType\n(Extension o\nrepex:ExtensionType\ne Zero or more Reporting Exception Items:\nPublic\nAuthor: GLEIF | Version: Final V1.1 | Page 15 of 45\n","contentLength":443,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:58:39.800Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_reporting-exceptions-format-v1-1.pdf","content":"Reporting Exceptions Format V1.1 ‘% LEl\nN\n© [] repex:ReportingExceptionsType\n© [] repex:ExceptionType\nI PS\n(Type [ repex:LEMMype )\no\nLo (Bcepiommesson )\nN @\n= e e\nJype l repexExceptionType | 0. ExceptionReference ®\nType | repex:Tokenized500Type\n_ NextVersion €\no) Type | repex:ReportingExceptionNextVersionType\nExtension ®\nType | repex:ExtensionType\nNextVersion ®\nType | repex:ReportingExceptionsContainerNe ...\n2.1. Data Element Reference\nAll elements, attributes and datatypes in the format are listed below, one per page.\nPublic\nAuthor: GLEIF | Version: Final V1.1 | Page 16 of 45\n","contentLength":584,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:58:39.800Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_reporting-exceptions-format-v1-1.pdf","content":"Reporting Exceptions Format V1.1 ‘e' LEl\n2.1.1. Element repex:ReportingExceptionData\nrepex:ReportingExceptionDataType\ncontent complex\n\n{1l,1}\n{1,1}\n\nPublic\nAuthor: GLEIF | Version: Final V1.1 | Page 17 of 45\n","contentLength":412,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:58:39.800Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_reporting-exceptions-format-v1-1.pdf","content":"Reporting Exceptions Format V1.1 ‘3' LEl\n2.1.2. Element repex:ReportingExceptionDataType / repex:Header\nContains the file upload information for this Reporting Exceptions file\nrepex:ExceptionHeaderType\ncontent complex\n\n{1l,1}\n{0,1}\n{1l,1}\n{0,1}\n{1l,1}\n{0,1}\n{0, 1}\n\nPublic\nAuthor: GLEIF | Version: Final V1.1 | Page 18 of 45\n","contentLength":678,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:58:39.800Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_reporting-exceptions-format-v1-1.pdf","content":"Reporting Exceptions Format V1.1 ‘; a' LEl\n2.1.3. Element repex:ExceptionHeaderType / repex:ContentDate\nThe date and time as of which the data contained in the file is valid.\nrepex:LEIDateTimeProfile\ncontent simple\n(IA\\T* AT\\ ((\\d){2,31){0,1})) (2| \\+([01][O-\npattern 9]12[0-3]):([0-5][0-9]) | -([01][0-9] | 2[0-3]):([O-\n5][0-9]))\nPublic\nAuthor: GLEIF | Version: Final V1.1 | Page 19 of 45\n","contentLength":390,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:58:39.800Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_reporting-exceptions-format-v1-1.pdf","content":"]\nReporting Exceptions Format V1.1 @ LEl\n2.1.4. Element repex:ExceptionHeaderType / repex:Originator\n\nThe LEI of the entity that created the content of this file.\nrepex:LEIType\ncontent simple\nminOccurs 0\nminLength 20\nmaxLength 20\npattern ([0-9A-Z]{18}[0-9]{2})\nPublic\nAuthor: GLEIF | Version: Final V1.1 | Page 20 of 45\n","contentLength":321,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:58:39.800Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_reporting-exceptions-format-v1-1.pdf","content":"]\n\nReporting Exceptions Format V1.1 @ LEl\n2.1.11. Element repex:ReportingExceptionsType / repex:EXCeption .......cccccvvvveeecceeeesiieecccveeeecnnnnnn 27\n2.1.12. Element repex:EXceptionTyPe / rePEX:LEl......cccuiiiiiee ettt e erae e eeneeee0 28\n2.1.13. Element repex:ExceptionType / repex:EXceptionCategory ......ccoceeeveervrveeeceressieesscveeesennnnnnn 29\n2.1.14. Element repex:ExceptionType / repex:EXceptionREasON ........cccceeecvveeesivieeceeeesieesecreessnennnn 30\n2.1.15. Element repex:ExceptionType / repex:ExceptionReference ..........cccceeeveeeceeicvieeccceeesinnnn 33\n2.1.16. Element repex:ExceptionType / repex:NeXtVersion.........cccceecveeiviveeeceeessieeesveeessvvesssneeeenns 34\n2.1.17. Element repex:ExceptionType / repex:EXTENSION.......cccceeiviieeecceeesiieeccteesieeesstaeeeieeesseaeaeee 35\n2.1.18. Element repex:ReportingExceptionsType / repex:NextVersion ..........cccceeeeeeeevveeeecveessnennn. 36\n2.1.19. Simple Type repex:LEIDateTimeProfile........cccoecccieiiiccciiie et seiiieee e 37\n2.1.20. SimpPle TYPe rEPEX:LEITY PO o iieie ettt ettt ettt ee e e tte e e e st te e e s setae e e s seteeeeesnsaeeeeennns 3O\n2.1.21. Simple Type repex:FileContentENUM .....cccviiiiiiciiieee et cctrie e eereieeseeraeee s seeeeeessseneeeeeees 39\n2.1.22. Simple Type repex:ExceptionCategoryENUM ........ccceeeecvieeeiicviiiien e ccciieee s sciieeeeseveeeee e 40\n2.1.23. Simple Type repex:EXceptionREaSONENUM.......cccviiriiiiirieieiieeeeceie e eree e sree e e seeee e 41\n2.1.24. Simple Type repex:Tokenized500TYPE ......vuuieiiecvieieeiiiieeeeeerie e e sieie e e sreeeeeseeeesssneeeeseenens 45\n\nPublic\n\nAuthor: GLEIF | Version: Final V1.1 | Page 3 of 45\n","contentLength":1667,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:58:39.800Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_reporting-exceptions-format-v1-1.pdf","content":"Reporting Exceptions Format V1.1 ‘@, LEl\n2.1.5. Element repex:ExceptionHeaderType / repex:FileContent\nA code describing the content of this RelationshipRecords file.\nrepex:FileContentEnum\ncontent simple\nThe file contains all Reporting Exceptions\nenumeration LOU_FULL_PUBLISHED pul?llshed by an. LOU (all Reporting Exceptions for\n- which the LOU is the ManagingLou) as of the\ndate/time the file is created.\nThe file contains those Reporting Exceptions\npublished by an LOU (all Reporting Exceptions for\nenumeration LOU_DELTA_PUBLISHED which the LOU is the ManagingLou) which are\nnew or changed since the peltastart specified in\nthe header, as of the date/time the file is created.\nThe file contains all Reporting Exceptions\n. published by GLEIF (including all Reporting\nLEIF_FULL_PUBLISHED\nenumeration GLEIF_FULL_PUBLIS Exceptions from all LOUs) as of the date/time the\nfile is created.\nThe file contains those Reporting Exceptions\npublished by GLEIF (including all Reporting\nenumeration GLEIF_DELTA_PUBLISHED Exceptions from all LOUs) which are new or\nchanged since the peltastart date specified in\nthe Header, as of the date/time the file is created.\nenumeration QUERY_RESPONSE The fll.e cgntams records matching criteria\nspecified in a query.\nPublic\nAuthor: GLEIF | Version: Final V1.1 | Page 21 of 45\n","contentLength":1303,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:58:39.800Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_reporting-exceptions-format-v1-1.pdf","content":"Reporting Exceptions Format V1.1 ‘3' LEl\n2.1.6. Element repex:ExceptionHeaderType / repex:DeltaStart\nThe date and time of the baseline relative to which this file contains new or changed\nReporting Exceptions.\nrepex:LEIDateTimeProfile\ncontent simple\nminOccurs 0\n(IA\\T* AT\\ ((\\d){2,31){0,1})) (2| \\+([01][O-\npattern 9]]2[0-3]):([0-5][0-9]) | -([01][0-9] | 2[0-3]):([O-\n5][0-9]))\nPublic\nAuthor: GLEIF | Version: Final V1.1 | Page 22 of 45\n","contentLength":437,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:58:39.800Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_reporting-exceptions-format-v1-1.pdf","content":"Reporting Exceptions Format V1.1 %' LEl\n2.1.7. Element repex:ExceptionHeaderType / repex:RecordCount\nThe number of Reporting Exceptions (RepEx) in the file. Must be a positive whole (integer)\nnumber, or zero (0).\nxs:nonNegativelnteger\ncontent simple\nPublic\nAuthor: GLEIF | Version: Final V1.1 | Page 23 of 45\n","contentLength":309,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:58:39.800Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_reporting-exceptions-format-v1-1.pdf","content":"Reporting Exceptions Format V1.1 ‘a' LEl\n2.1.8. Element repex:ExceptionHeaderType / repex:NextVersion\nrepex:HeaderNextVersionType\ncontent complex\nminOccurs 0\nPublic\nAuthor: GLEIF | Version: Final V1.1 | Page 24 of 45\n","contentLength":217,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:58:39.800Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_reporting-exceptions-format-v1-1.pdf","content":"Reporting Exceptions Format V1.1 ‘a' LEl\n2.1.9. Element repex:ExceptionHeaderType / repex:Extension\nThis Extension element contains any additional elements required to extend the Header\ncontainer element.\nrepex:ExtensionType\ncontent complex\nminOccurs 0\nPublic\nAuthor: GLEIF | Version: Final V1.1 | Page 25 of 45\n","contentLength":312,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:58:39.800Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_reporting-exceptions-format-v1-1.pdf","content":"Reporting Exceptions Format V1.1 ‘3' LEl\n2.1.10. Element repex:ReportingExceptionDataType / repex:ReportingExceptions\nA list of reporting exceptions, with reason(s) for each exception, provided by legal entities,\nfor declining to provide specified classes of relationship information\nrepex:ReportingExceptionsType\ncontent complex\n\n{0, unbounded}\n{0,1}\n\nPublic\nAuthor: GLEIF | Version: Final V1.1 | Page 26 of 45\n","contentLength":600,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:58:39.800Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_reporting-exceptions-format-v1-1.pdf","content":"Reporting Exceptions Format V1.1 3' LEl\n2.1.11. Element repex:ReportingExceptionsType / repex:Exception\nA single exception to a specified reporting requirement, giving reasons and references\nwhere applicable.\nrepex:ExceptionType\ncontent complex\nminOccurs 0\nmaxOccurs unbounded\n\n{1,1}\n{1l,1}\n{1, unbounded}\n{0,unbounded}\n{0,1}\n{0, 1}\n\nPublic\nAuthor: GLEIF | Version: Final V1.1 | Page 27 of 45\n","contentLength":736,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:58:39.800Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_reporting-exceptions-format-v1-1.pdf","content":"]\nReporting Exceptions Format V1.1 @ LEl\n2.1.12. Element repex:ExceptionType / repex:LEl\n\nThe I1SO 17442 compatible identifier for the legal entity which raised this exception.\nrepex:LEIType\ncontent simple\nminLength 20\nmaxLength 20\npattern ([0-9A-Z]{18}[0-9]{2})\nPublic\nAuthor: GLEIF | Version: Final V1.1 | Page 28 of 45\n","contentLength":322,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:58:39.800Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_reporting-exceptions-format-v1-1.pdf","content":"Reporting Exceptions Format V1.1 ‘3' LEl\n2.1.13. Element repex:ExceptionType / repex:ExceptionCategory\nA category of mandatory information reporting, beyond the minimum required for legal\nentity identification, which the legal entity declines, giving reasons and references where\napplicable.\nrepex:ExceptionCategoryEnum\ncontent simple\nThe legal entity has\ndeclined to report a\nenumeration DIRECT_ACCOUNTING_CONSOLIDATION_PARENT O/rect accounting\nconsolidation parent,\nbased on applicable\naccounting standards.\nThe legal entity has\ndeclined to report an\nenumeration ULTIMATE_ACCOUNTING_CONSOLIDATION_PARENT U/timate accounting\nconsolidation parent,\nbased on applicable\naccounting standards.\nPublic\nAuthor: GLEIF | Version: Final V1.1 | Page 29 of 45\n","contentLength":750,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:58:39.800Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_reporting-exceptions-format-v1-1.pdf","content":"Reporting Exceptions Format V1.1 ‘@ LE|\n\\I\n2.1.14. Element repex:ExceptionType / repex:ExceptionReason\nA single reason provided by the legal entity for declining to provide the mandatory report of\na specified type of information (beyond the minimum reference data needed purely for\nidentification of the legal entity).\nrepex:ExceptionReasonEnum\ncontent simple\nmaxOccurs unbounded\nTh h\nenumeration NO_LEI |_E|e parent does not consent to have an\nThere is no parent according to the\ndefinition used, because the entity is\nI I ith\nenumeration NATURAL_PERSONS controlled by natural person(s) without\nany intermediate legal entity meeting the\ndefinition of accounting consolidating\nparent.\nThere is no parent according to the\ndefinition used, because the entity is\nenumeration NON_CONSOLIDATING controlled by legal entities not subject to\npreparing consolidated financial\nstatements.\nThere is no parent according to the\n. definition used, because there is no known\nenumeration NO_KNOWN_PERSON . .\nperson controlling the entity (e.g..,\ndiversified shareholding).\nObstacles in the laws or regulations of a\njurisdiction prevent providing or publishing\nenumeration LEGAL OBSTACLES this information. This does not include\n- cases where, under the applicable legal\nframework disclosing the parent\nrelationship would require the consent of\nPublic\nAuthor: GLEIF | Version: Final V1.1 | Page 30 of 45\n","contentLength":1388,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:58:39.800Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_reporting-exceptions-format-v1-1.pdf","content":"Reporting Exceptions Format V1.1 ‘@, LE|\n1. Reporting Exceptions Format Version 1.0\nDocumentation last updated: 2016-11-26\n1.1. Introduction\nFollowing the LEI-ROC policy document, \"Collecting data on direct and ultimate parents of\nlegal entities in the Global LEI System — Phase 1\" (10 March 2016), the Global Legal Identifier\nSystem (GLEIS) requires that legal entities with an LEI provide information on their ultimate\nand direct accounting consolidating parents.\n\ne Relationship reporting according to the Relationship Record Common Data File (RR-\nCDF) format V1.0 is mandatory. The only opt-out reasons allowed are taken from the\nLEI-ROC policy document, pages 16-17. A further general exception case, also based\non the LEI-ROC policy document (p. 18) is provided to cover situations where the\nmain opt-out reasons may not precisely applicable:\n\no No LEI - \"the parent does not consent to have an LEI\" (LEI-ROC policy, p. 18).\n\ne This format provides a simple record structure linking, per record:\n\no One LEl from the LOU's current LEI data file;\n\no One relationship type (reporting category) that must be reported;\n\no One reason for declining to report that relationship type for the legal entity\nreferenced by this LEI, plus an optional reference e.g. to a legal or regulatory\nprovision.\n\nAll LOUs use this file format to record and submit Reporting Exceptions to GLEIF.\n1.2. Audience for this document\nThe target audience for this standard includes:\n\ne All Local Operating Units (as well as candidate LOUs) of the GLEIS\n\ne All users or potential users of LEl data\n\n¢ Allfinancial regulators who consume LEI data\n\n1.3. Status of this document\nThis section describes the status of this document at the time of its publication. Later\nversions may supersede this document. The most up to date version will always be available\nfrom www.gleif.org\nThe file format references the LEI ROC's published document entitled \"LEI ROC Report on\nPublic\nAuthor: GLEIF | Version: Final V1.1 | Page 4 of 45\n","contentLength":1994,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:58:39.800Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_reporting-exceptions-format-v1-1.pdf","content":"]\nReporting Exceptions Format V1.1 @ I_E|\none of the entities in the relationship, or\nboth, and such consent could not be\nobtained (in these cases\n\"CONSENT_NOT_OBTAINED\" is the\napplicable code). The LOU is not expected\nto verify or analyze whether the legal\nframework constitutes a legal obstacle.\nObstacles in the laws or regulations of a\njurisdiction prevent providing or publishing\nthis information: “the consent of the\nparent was necessary under the applicable\nlegal framework and the parent did not\nconsent or could not be contacted”. Note\nenumeration CONSENT NOT OBTAINED that it is a responsibility of a child entity to\n- - seek parent consent when necessary for\ndisclosing the parent relationship, for\ninstance by inviting in writing the parent\nentity to provide consent. The LOU is not\nexpected to verify or analyze whether the\nlegal framework constitutes a legal\nobstacle.\nBinding legal commitments (other than the\nlaws or regulations of a jurisdiction), such\nas articles governing the legal entity or a\nenumeration BINDING_LEGAL_COMMITMENTS contract, prevent providing or publishing\nthis information. The LOU is not expected\nto verify or analyze whether the legal\nframework constitutes a legal obstacle.\nThe child entity has sought to consult the\nparent entity about the reporting of the\nparent information to the GLEIS but could\nnot confirm the absence of detriment in a\nway that can appropriately prevent liability\nenumeration DETRIMENT_NOT_EXCLUDED risks for the child entity (or those acting on\nits behalf) under the applicable legal\nframework. The disclosure of this\ninformation would be detrimental to the\nlegal entity or the relevant parent. This will\ninclude reasons generally accepted by\nPublic\nAuthor: GLEIF | Version: Final V1.1 | Page 31 of 45\n","contentLength":1767,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:58:39.800Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_reporting-exceptions-format-v1-1.pdf","content":"- ________0____000___]\nReporting Exceptions Format V1.1 @ LEl\npublic authorities in similar circumstances,\nbased on a declaration by the entity.\nThis reason may be used only when all\nfollowing cumulative circumstances apply:\n[i) the parent could not be informed via\nthe GLEIS and have the possibility to\ncorrect the relationship information before\npublication (including raising a cause for\nopt out, either because the parent does\nnot have an LEl, or it has an LEIl but the\nGLEIS has not yet implemented such\nsystem;] ii) the relationship is not already\nin the public domain (information being in\nthe public domain assumes here that the\nway the information came into the public\ndomain did not infringe the applicable\nlegal framework); iii) the child entity has\nreasons to believe that the parent may\nconsider disclosure to be detrimental; (iv)\nthe child entity has sought to consult the\nparent entity of the reporting of the parent\ninformation to the GLEIS but could not\nconfirm the absence of detriment in a way\nthat can appropriately prevent liability\nrisks for the child entity (or those acting on\nits behalf) under the applicable legal\nframework.\nThe disclosure of this information would\nbe detrimental to the legal entity or the\nenumeration DISCLOSURE_DETRIMENTAL relevant parent. This will include reasons\n- generally accepted by public authorities in\nsimilar circumstances, based on a\ndeclaration by the entity.\nPublic\nAuthor: GLEIF | Version: Final V1.1 | Page 32 of 45\n","contentLength":1478,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:58:39.800Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_reporting-exceptions-format-v1-1.pdf","content":"]\nReporting Exceptions Format V1.1 @ LEl\n2.1.15. Element repex:ExceptionType / repex:ExceptionReference\n\nReferences of the law, regulation or other element of the legal framework to support\nreason(s) provided by the legal entity for declining to provide information on its parents.\nrepex:Tokenized500Type\ncontent simple\nminOccurs 0\nmaxOccurs unbounded\nminLength 1\nmaxLength 500\npattern \\S+( \\S+)*\nPublic\nAuthor: GLEIF | Version: Final V1.1 | Page 33 of 45\n","contentLength":457,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:58:39.801Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_reporting-exceptions-format-v1-1.pdf","content":"Reporting Exceptions Format V1.1 ‘%' LEl\n2.1.16. Element repex:ExceptionType / repex:NextVersion\nrepex:ReportingExceptionNextVersionType\ncontent complex\nminOccurs 0\nPublic\nAuthor: GLEIF | Version: Final V1.1 | Page 34 of 45\n","contentLength":224,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:58:39.801Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_reporting-exceptions-format-v1-1.pdf","content":"Reporting Exceptions Format V1.1 %' LEl\n2.1.17. Element repex:ExceptionType / repex:Extension\nThis repex:Extension element may contain any additional elements required to extend the\nReporting Exception.\nrepex:ExtensionType\ncontent complex\nminOccurs 0\nPublic\nAuthor: GLEIF | Version: Final V1.1 | Page 35 of 45\n","contentLength":310,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:58:39.801Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_reporting-exceptions-format-v1-1.pdf","content":"Reporting Exceptions Format V1.1 ‘%' LE'\n2.1.18. Element repex:ReportingExceptionsType / repex:NextVersion\nrepex:ReportingExceptionsContainerNextVersionType\ncontent complex\nminOccurs 0\nPublic\nAuthor: GLEIF | Version: Final V1.1 | Page 36 of 45\n","contentLength":244,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:58:39.801Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_reporting-exceptions-format-v1-1.pdf","content":"- ________0____000___]\nReporting Exceptions Format V1.1 ‘e' LEl\n2.1.19. Simple Type repex:LEIDateTimeProfile\n\nrestriction of xs:dateTime\n(IA\\T* AT\\ ((\\d){2,31){0,1})) (2| \\+([01][O-\npattern 9]12[0-3]):([0-5][0-9]) | -([01][0-9] | 2[0-3]):([O-\n5][0-9]))\nPublic\nAuthor: GLEIF | Version: Final V1.1 | Page 37 of 45\n","contentLength":312,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:58:39.801Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_reporting-exceptions-format-v1-1.pdf","content":"Reporting Exceptions Format V1.1 a' LEl\n2.1.20. Simple Type repex:LEIType\nrestriction of xs:string\nminLength 20\nmaxLength 20\npattern ([0-9A-Z]{18}{0-9]{2})\nPublic\nAuthor: GLEIF | Version: Final V1.1 | Page 38 of 45\n","contentLength":215,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:58:39.801Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_reporting-exceptions-format-v1-1.pdf","content":"Reporting Exceptions Format V1.1 ‘@, LEl\n2.1.21. Simple Type repex:FileContentEnum\nrestriction of xs:string\nThe file contains all Reporting Exceptions\n. published by an LOU (all Reporting Exceptions for\nenumeration LOU_FULL_PUBLISHED which the LOU is the ManagingLou) as of the\ndate/time the file is created.\nThe file contains those Reporting Exceptions\npublished by an LOU (all Reporting Exceptions for\nenumeration LOU_DELTA_PUBLISHED which the LOU is the ManagingLou) which are\nnew or changed since the peltastart specified in\nthe header, as of the date/time the file is created.\nThe file contains all Reporting Exceptions\n. published by GLEIF (including all Reporting\nLEIF_FULL_PUBLISHED\nenumeration GLEIF_FULL_PUBLIS Exceptions from all LOUs) as of the date/time the\nfile is created.\nThe file contains those Reporting Exceptions\npublished by GLEIF (including all Reporting\nenumeration GLEIF_DELTA_PUBLISHED Exceptions from all LOUs) which are new or\nchanged since the peltastart date specified in\nthe Header, as of the date/time the file is created.\nenumeration QUERY_RESPONSE The fll.e cgntams records matching criteria\nspecified in a query.\nPublic\nAuthor: GLEIF | Version: Final V1.1 | Page 39 of 45\n","contentLength":1206,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:58:39.801Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_reporting-exceptions-format-v1-1.pdf","content":"Reporting Exceptions Format V1.1 ‘3' LEl\n2.1.22. Simple Type repex:ExceptionCategoryEnum\nrestriction of xs:string\nThe legal entity has\ndeclined to report a\nenumeration DIRECT_ACCOUNTING_CONSOLIDATION_PARENT J/\"éCt accounting\n- consolidation parent,\nbased on applicable\naccounting standards.\nThe legal entity has\ndeclined to report an\nenumeration ULTIMATE_ACCOUNTING_CONSOLIDATION_PARENT U/timate accounting\nconsolidation parent,\nbased on applicable\naccounting standards.\nPublic\nAuthor: GLEIF | Version: Final V1.1 | Page 40 of 45\n","contentLength":531,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:58:39.801Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_reporting-exceptions-format-v1-1.pdf","content":"Reporting Exceptions Format V1.1 ‘@, I_E|\ncollecting data on direct and ultimate parents of legal entities in the Global LEI System\" (10\nMarch 2016; available from www.leiroc.org).\n\n1.4. Terminology and Typographical Conventions\nThe following typographical conventions are used throughout the document:\n\ne ALL CAPS type is used for the special terms enumerated above.\n\ne Monospace type is used to denote programming language, UML, and XML\nidentifiers, as well as for the text of XML documents.\n\n1.5. Cardinalities\n\ne The cardinality of each element (the number of times it MUST or may appear in an\nXML data file conforming to this schema) is expressed as a number range in the\nformat {minimum occurrences, maximum occurrences} in the XML examples shown\nbelow the notes of its containing element. This notation is equivalent to the\nfollowing explanations in words:\n\no Mandatory, unique: {1, 1} - the element MUST appear, exactly once.\n\no Mandatory, repeatable: {1, unbounded} - the element MUST appear at least\nonce. It may be repeated any number of times.\n\no Optional, unique: {0, 1} - the element NEED NOT appear; it MAY appear once\nat most.\n\no Optional, repeatable: {0, unbounded} - the element NEED NOT appear. It\nMAY be repeated any number of times.\n\nPlease note:\n\ne The default cardinality is {1,1} (mandatory, unique). This document highlights when\nan element differs from this either by its minoccurs (minimum occurrences) or\nmaxOccurs (Mmaximum occurrences) value, or both.\n\ne XML cardinalities apply in the context of any containing elements. This means that a\ncontained element may have a cardinality of one or more even if its containing\nelement may be omitted, because the contained element is mandatory given the\npresence of the container.\n\ne XML cardinalities enforce a minimum data quality and standards conformance. Other\nbusiness rules (as explained below) and data quality checks applied by GLEIF may\nencourage stricter cardinalities in live implementations.\n\nPublic\n\nAuthor: GLEIF | Version: Final V1.1 | Page 5 of 45\n","contentLength":2037,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:58:39.801Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_reporting-exceptions-format-v1-1.pdf","content":"Reporting Exceptions Format V1.1 ‘@, LEl\n2.1.23. Simple Type repex:ExceptionReasonEnum\nType restriction of xs:string\nenumeration NO LEI The parent does not consent to\n- have an LEI.\nThere is no parent according to the\ndefinition used, because the entity\nenumeration NATURAL PERSONS |s'controlled 'by naturayl person(s)\n\n- without any intermediate legal\nentity meeting the definition of\naccounting consolidating parent.\nThere is no parent according to the\ndefinition used, because the entity\n\nenumeration NON_CONSOLIDATING is controlled by legal entities not\nsubject to preparing consolidated\nfinancial statements.\nThere is no parent according to the\nFacets it ;\nenumeration NO KNOWN PERSON definition used, becaus',e there is r'\\o\n- - known person controlling the entity\n(e.g.., diversified shareholding).\nObstacles in the laws or regulations\nof a jurisdiction prevent providing\nor publishing this information. This\ndoes not include cases where,\nunder the applicable legal\nframework disclosing the parent\nenumeration LEGAL_OBSTACLES relationship would require the\nconsent of one of the entities in the\nrelationship, or both, and such\nconsent could not be obtained (in\nthese cases\n\"CONSENT_NOT_OBTAINED\" is the\napplicable code). The LOU is not\nexpected to verify or analyze\nPublic\nAuthor: GLEIF | Version: Final V1.1 | Page 41 of 45\n","contentLength":1332,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:58:39.801Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_reporting-exceptions-format-v1-1.pdf","content":"]\nReporting Exceptions Format V1.1 @ LEI\nwhether the legal framework\nconstitutes a legal obstacle.\nObstacles in the laws or regulations\nof a jurisdiction prevent providing\nor publishing this information: “the\nconsent of the parent was\nnecessary under the applicable\nlegal framework and the parent did\nnot consent or could not be\ncontacted”. Note that itis a\nenumeration CONSENT_NOT_OBTAINED responsibility of a child entity to\nseek parent consent when\nnecessary for disclosing the parent\nrelationship, for instance by inviting\nin writing the parent entity to\nprovide consent. The LOU is not\nexpected to verify or analyze\nwhether the legal framework\nconstitutes a legal obstacle.\nBinding legal commitments (other\nthan the laws or regulations of a\njurisdiction), such as articles\ngoverning the legal entity or a\nenumeration BINDING_LEGAL_COMMITMENTS °\"tract prevent providing or\n- publishing this information. The\nLOU is not expected to verify or\nanalyze whether the legal\nframework constitutes a legal\nobstacle.\nThe child entity has sought to\nconsult the parent entity about the\nreporting of the parent information\nto the GLEIS but could not confirm\nenumeration DETRIMENT_NOT_EXCLUDED the absence of detriment in a way\nthat can appropriately prevent\nliability risks for the child entity (or\nthose acting on its behalf) under\nthe applicable legal framework. The\ndisclosure of this information would\nPublic\nAuthor: GLEIF | Version: Final V1.1 | Page 42 of 45\n","contentLength":1456,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:58:39.801Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_reporting-exceptions-format-v1-1.pdf","content":"]\n\nReporting Exceptions Format V1.1 @ LEl\nbe detrimental to the legal entity or\nthe relevant parent. This will\ninclude reasons generally accepted\nby public authorities in similar\ncircumstances, based on a\ndeclaration by the entity.\nThis reason may be used only when\nall following cumulative\ncircumstances apply: [i) the parent\ncould not be informed via the GLEIS\nand have the possibility to correct\nthe relationship information before\npublication (including raising a\ncause for opt out, either because\nthe parent does not have an LEI, or\nit has an LEI but the GLEIS has not\nyet implemented such system;] ii)\nthe relationship is not already in the\npublic domain (information being in\nthe public domain assumes here\nthat the way the information came\ninto the public domain did not\ninfringe the applicable legal\nframework); iii) the child entity has\nreasons to believe that the parent\nmay consider disclosure to be\ndetrimental; (iv) the child entity has\nsought to consult the parent entity\nof the reporting of the parent\ninformation to the GLEIS but could\nnot confirm the absence of\ndetriment in a way that can\nappropriately prevent liability risks\nfor the child entity (or those acting\non its behalf) under the applicable\nlegal framework.\nThe disclosure of this information\n\nenumeration DISCLOSURE_DETRIMENTAL ~ Would be detrimental to the legal\n\nentity or the relevant parent. This\nwill include reasons generally\n\nPublic\n\nAuthor: GLEIF | Version: Final V1.1 | Page 43 of 45\n","contentLength":1473,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:58:39.801Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_reporting-exceptions-format-v1-1.pdf","content":"Reporting Exceptions Format V1.1 ‘%' LEl\naccepted by public authorities in\nsimilar circumstances, based on a\ndeclaration by the entity.\n\nPublic\n\nAuthor: GLEIF | Version: Final V1.1 | Page 44 of 45\n","contentLength":197,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:58:39.801Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_reporting-exceptions-format-v1-1.pdf","content":"Reporting Exceptions Format V1.1 ‘; 3' LEl\n2.1.24. Simple Type repex:Tokenized500Type\nAn element of this type has minimum length of one character and may not contain any of:\nthe carriage return (#xD), line feed (#xA) nor tab (#x9) characters, shall not begin or end with\na space (#x20) character, or a sequence of two or more adjacent space characters.\nrestriction of xs:string\nminLength 1\nmaxLength 500\npattern \\S+( \\S+)*\nPublic\nAuthor: GLEIF | Version: Final V1.1 | Page 45 of 45\n","contentLength":482,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:58:39.801Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_reporting-exceptions-format-v1-1.pdf","content":"Reporting Exceptions Format V1.1 ‘@ LE|\n\\I\n1.6. Business Rules\nThe accompanying documentation in addition to this Technical Specification specifies\nbusiness rules where applicable for each element. These are rules that are not enforced by\nvalidating against the XML schema, but are still mandatory for all Common Data File (CDF)\nformat files.\n1.7. Release Notes\n1.7.1. Version 1.1\n= Corrections:\n\" Extension elementin Header corrected to minOccurs=\"0\".\n\n1.7.2. Version 1.0\nThe first release.\n1.8. Change Management\nChanges to this standard that affect the data schema SHALL be made by approval and\npublication of a new version of this document. A new version SHALL be one of the following:\nErrata Version An errata version makes corrections to the normative content of the standard\n(excluding corrections which would change the data schema) and/or makes changes to non-\nnormative content such as explanatory material. An errata version does not change the XML\nschema definitions, only the documentation parts, and so does not affect the\ninteroperability of systems implementing the standard. An errata version is indicated by\nincrementing the third version number; e.g., 1.0t0 1.0.1, or 1.0.1 to 1.0.2.\n1.8.1. Minor Version\nA minor version may include all changes permitted in an errata version, and in addition adds\none or more data elements and/or adds one or more codes to a code list (“enum” data\ntype). A minor version changes the XML schema. Minor version changes to schema MUST\nprovide for forward and backward compatibility. This allows existing implementations to\ncontinue to interoperate even if they are using different minor versions. A minor version is\nindicated by incrementing the second version number; e.g., 1.0to 1.1 or 1.1.3 to 1.2.\n\nPublic\n\nAuthor: GLEIF | Version: Final V1.1 | Page 6 of 45\n","contentLength":1812,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:58:39.801Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_reporting-exceptions-format-v1-1.pdf","content":"Reporting Exceptions Format V1.1 ‘@, I_E|\n1.8.2. Major Version\nA major version may make any change at all, including incompatible changes to the XML\nschema. Major version changes to schema require that the new version uses a different XML\nnamespace. This requires existing implementations to separately understand both the old\nand new versions during a period of transition. A major version is indicated by incrementing\nthe first version number; e.g., 1.1 to 2.0.\nThe release of a new minor or major version shall always be accompanied by a transition\nplan for LOUs and GLEIF, to ensure a smooth and time-bounded migration to the new\nversion.\n1.8.3. Minor Version Changes to the XML Schema\nA minor version may introduce new XML elements and/or adds one or more codes to a code\nlist (“enum” data type). Minor version changes to schema SHALL be made as specified\nbelow, in order to achieve forward and backward compatibility.\nForward compatibility means that an LEI Data File which is valid according to the older\nversion’s schema is also valid according to the newer version’s schema.\nBackward compatibility means that an LEI Data File which is valid according to the newer\nversion’s schema is also valid according to the older version’s schema.\nNew data elements may be added at pre-defined extension points within the schema, each\nwith an optional XML element NextVersion. New data elements are always added within a\nNextVersion element. When a minor version adds a new data element to a NextVersion\nelement, a new NextVersion element is also added inside the previously added NextVersion\nelement, to accommodate additional data elements in subsequent minor versions. Each\nsuccessive NextVersion element set is contained directly within the previous minor version's\nNextVersion set.\nAs can be seen from the full XML schema presented here, the following rules SHALL be\nobserved to ensure forward and backward compatibility:\n\ne The initial XSD declaration for a NextVersion element SHALL use the element name\n\"NextVersion\", XML data type \"lei:NextVersion1Type\" and cardinality optional,\nunique {0,1}. The XML data type allows a sequence of any elements, each of\n\nPublic\nAuthor: GLEIF | Version: Final V1.1 | Page 7 of 45\n","contentLength":2220,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:58:39.801Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_reporting-exceptions-format-v1-1.pdf","content":"]\nReporting Exceptions Format V1.1 @ LE|\ncardinality optional, repeatable (unbounded) and with lax content processing, but in\nthe target namespace.\n\ne The minOccurs declaration on the NextVersion element allows it to be omitted in\nfiles conforming to the first minor version. The schema wildcard xsd:any allows for\nforward compatibility: a file conforming to a new minor version still validates in the\nold version because the wildcard matches any new elements introduced in the new\nminor version.\n\n¢ New elements SHALL be introduced in a subsequent minor version by modifying the\ndeclaration for the above type declaration as follows:\n\no Asequence of the new elements introduced in the previous version\no Asubsequent NextVersionN element where N is an index number starting at\n1 and incremented by 1 with each minor version\n\ne Each new element SHALL be declared minOccurs=\"0\", to ensure backward\ncompatibility: a file conforming to the old version still validates in the new version\nbecause the new schema does not require the presence of elements not defined in\nthe old version. If a new element is mandatory for conformance to the new version,\nthis MUST be enforced outside schema validation.\n\ne The new definition of the NextVersion element SHALL include a declaration of an\ninner NextVersion element, as illustrated above, to provide for additional elements\nin subsequent minor versions. The nesting of NextVersion elements is required to\nsatisfy the “unique particle attribution” constraint of XSD 1.0.\n\ne Each code list (Enum types) is implemented in the XML schema simply as the XSD\nstring data type. This provides for forward compatibility because the schema for an\nolder minor version will validate any string, including codes defined in newer minor\nversions. The schema for each minor version includes the list of valid codes for that\nminor version as a documentation annotation to the type declaration for each Enum\ntype.\n\n1.8.4. Major Version Changes to the XML Schema\nA major version may make any change to the XML schema whatsoever, including\nincompatible changes.\nA schema introduced in a new major version SHALL use an XML namespace URI that is\ndifferent from the XML namespace URI defined in any other major version of this standard.\nThe namespace URI for a new major version SHOULD be the same as the namespace URI\nspecified in this standard, with the year at the end changed to the year in which the new\nmajor version is introduced. If more than one major version is introduced in the same year, a\nletter “a”, “b”, “c”, etc., may be appended to the year as needed.\nA new major version MUST be accompanied by an implementation plan which explains how\nimplementations will make the transition from the old major version to the new major\nPublic\nAuthor: GLEIF | Version: Final V1.1 | Page 8 of 45\n","contentLength":2812,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:58:39.801Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_reporting-exceptions-format-v1-1.pdf","content":"Reporting Exceptions Format V1.1 ‘@, LEl\nversion. Generally speaking, such a plan typically provides for a period of transition in which\nan implementation capable of receiving the new major version is required to also receive\nthe old major version.\n\n1.9. XML Syntax\nThis section specifies the XML schema for an LEI data file conforming to this standard.\n1.9.1. XML Design Rules\ne The XSD schema conforms to W3C's XML Schema specification, version 1.0.\ne The XML namespace is \"http://www.gleif.org/data/schema/repex/2016\".\ne Allinterior XML elements are namespace-qualified (element form = qualified).\ne All XML attributes are in the null namespace (attribute form = unqualified), with the\nexception of xml:1lang.\ne Element names are upper camel case.\ne Attribute name are lower camel case.\ne XSD type names are upper camel case.\n¢ Enumeration code list values are all caps with underscores.\ne Elements are used in preference to attributes except for language and type\nqualifiers.\n¢ For a data element specified as having unbounded cardinality, the XML includes a\nsingle container element whose subelements are one or more instances of the data\nelement whose cardinality is unbounded. The name of the container element is\nformed as the plural of the name of the contained elements.\n1.9.2. XML Schema\nAn XML file conforming to this standard SHALL be valid according to the following XSD 1.0\nschema.\n\n\n\n\n\n\n\n\n \n\n\n\n\n\n\n \n\n\n \n\n\n\n \n\n\n\n\n\n\n\n\n\n\n\nPublic\nAuthor: GLEIF | Version: Final V1.1 | Page 10 of 45\n","contentLength":1435,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:58:39.801Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/gleif-registration-authorities-list/2022-03-23_ra_list_v1.7.pdf","content":"GLEIF Registration Authorities List\nVersion 1.7\nMarch 2022\n","contentLength":59,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:59:53.692Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/gleif-registration-authorities-list/2022-03-23_ra_list_v1.7.pdf","content":"to be used for Public Legal Documents' for General\nRAT77777 Government Eniities and International\nOrganizations for which no information is available\nin any regular RA source\nTemporary code; new registration authorty code\ni - r - o |\nrA020%99 . o r . - { {0000 |G\nentity\n- - Afghanistan Central Business Regist Afghanistan Central Business Registry (Ministry of -\nRA000001 Afghanistan AF Afghanistan fgaisian Coniral Business Regiely _ Afghanistan Cental Busine hitp:/www.acbr.gov.af/\nPypm— Aghanisan e prT—— Register of Licensed Fnancial Da Afghanisian Bank Tiiips 7/ab. gov.aindex php/LIcensed-Finacial |10 be Used for banks and some other Tcensed\nInstitutions Institutions financial institutions\nCentre National du\nRA000003 Algeria 0z Ageria Trade Register Registre du Commerce National Center of the Trade Register Regisire du Commerce | https://sidjilcom.cnrc.dz/weblonrc/accueil\n(CNRC)\nPRT—— ; Tasqamut n Usuddes d\nRA000795 [Aera oz JAgea 0000000000 00000000000 0 [BankofAera Banque d'Algérie hitps://www.bank of-algeria.dz/ o be used as a Validation Authority for funds\nRA000004 Register of Commerce Regisire de Societats Mercantlls r | [ntipdwww.comercadla-unitatcomerc r 1\nFho007e7 poe o fwee b |l [apiemean e o ne fobe wedas aVaidaion uhory for s\nRA000006 Anguila Anguilla Commercial Registry Commercial Registry Anguilla Commercial Registry Qg‘sifi Commercial b /ww.commercialregistry.aif _\nRA000799 Anguila Anguilla __ Anguilla Financial Services Commission Angulla Financial | hutpirwww. fsc.org.ai to be used as a Validation Authority for funds\nRA000007 Antigua and Barbuda | AG Antigua and Barbuda Intellectual Property and Commerce Office Intellectual Property and [http:/www.legalaffairs gov.ag/detail_page.php?\nCommerce Office page=coming. soon.php\n“Administracion Federal\nRA000009 Argentina AR Argentina Federal Adminisaion o Publo Revenies (AIP) [ e Ingresos Publcos. | i gob arsitolextemos\nMinisterio d6 JUstor y\nDerechos Humanos ; ; usticialreqistio-\nRAC00010 Argentina AR Argentina Registro Nacional de Sociedades (Direcon ol Registo hitps //uwww.argentina gob.ar/usicia/registro\nSociedades)\nComision Nacional de\nRA000800 Argentina AR Argentina Valores; Minsterio de | itps:/w.argentina gob.arenv to be used as a Validation Authority for funds\nconomia\nT WUR Ll puEnnp\n: ! . \" WANWNWAWNRLRIWY duhiup WAL i ' ' : ; e\nRA000011 Ammenia AV Armenia State Register of Legal Entities LR niplu bufuunwniei Ministry of Justice of the Republic of Amenia hitps://www.e-register.am/\nntighuwnph\n—— - - AUstalan BUsess\nRA000013 Australia AU Australia Australian Business Register Australian Business Register Australian Business Register of the Australian Register of the http://abr.business.gov.au/\nTaxation Office Australian Taxation\nOffice\n- — The Australan\nRA000014 Australia AU Australia Register of Companies Register of Companies The Australian Securities and Investment Securiiesand | agic.gov.au\nCommission Ingestment Commission\n- — The Austraian\nRA000015 Australia AU Australia Register of Financial Services Licensees | Register of Financial Services Licensees The Australian Securities and Investment Securiiesand |y asic.gov.au\nCommission Investment Commission\n(ASIC)\n- - - - Office of the Registrar of\n- — “Australan Prudential p o Entll\nRAC00714 f&gggg;j;yem\"\"“fl\"‘m Entities | Re gistrable Superannuation Enties (RSE) Register | Australian Prudential Regulation Authority (APRA) Reguiaon Autrory { npsivapragov.auegiser-superannuation (b used for Regisirable Supernnuation Eniies\nRA000762 Super Fund Lookup Super Fund Lookup Australian Taxation Office Auelralian Taxaton https:/superfundiookup.gov.au/ to be used for super funds\n- - P— - - - Bundesmnisterum far | Nips//www.Justz gv.aweb201 3/Hml/deTaul/2c048\nRA000017 Austria AT Austiia Commercial Register Firmenbuch Federal Ministry of Justice Bunde Fps o Utz o aUueb20 3 himiider\nRA000T8 [Austia —— JAT w1 Financial Market Authority Finanzmarkiaufsicht [ htips:/www.fma gv.at/en/ 1\n— — - Bundesministerum far | hips://www. wien.gv.atenglish/e-\nRAC00687 Austria AT Austria Trade Information System Austria GewerbelnformationsSystem Austria (GISA) Federal Ministry for Digitization and Business Digitalisierung und governmenthusiness/register/public-query-\nWitschaftsstandort | gisa.html\nP——— Piips 77w brmaw.gv.aUDignasierungundEGovern - - -\nRA000707 Austria AT Austria Supplementary Register Ergénzungsregister fiir sonstige Betroffene (ErSB) | Federal Ministry Digital and Economic Affairs Digitalisierung und ment/Stammzahlenregisterbehoerde/Ergaenzungsr at least temporarily not available for public\nDighalisierung und | egister/Seiten/Ergaenzungsregister-fuer-sonstige- - | consuliation\nBetroffene-aspx\nRA000710 Austria AT Austria Register of Associations. Zentralen Vereinsregister (ZVR) Ministry of the Interior Bundesministerium fir [ https://citizen.bmi.gv.at/at gv.bmi.insweb- To be used for associations\nInneres plzvn/public/Registerauszig\nRA000734 Funds register Bundes-Fondsregister Federal Ministry of the Interior Bundesministerium hitps://www.bmi.gv.at/409/start.aspx to be used for funds\nRA000TS State Register of Commercial Entites | Kommersiya qurumlarinin dovIst reyestri Ministry of Taxes of the Republic of Azerbajan | wwwiaesgovaz [ 1|\nAzorbaycan\noo e e N el ] (0o eed e eon Aoty o e\nanki\nRegistrar General\nRA000020 Bahamas 8BS Bahamas Companies Register Companies Register Regitrar General Department of the Bahamas | Deparimentof the www.bahamas gov.bs\nahamas\n2/23\n","contentLength":5467,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:59:53.692Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/gleif-registration-authorities-list/2022-03-23_ra_list_v1.7.pdf","content":"RA000297 Commercial Register Handelsregister Local Court Marburg Amisgericht Marburg _[www.handelsregister.de r 1\nTustzministerum — - — g\nRA000743 Mecklenburg-Western Pomerania Foundations Directory Stiftungsverzeichnis Ministry of Justice vgfi,flfl‘:g'fl E?‘m”f(é\"j&%&é?&fl%fiifi% enpl ;grgz ;ffi: for foundations in Mecklenburg-Western\nRA000298 [Germany ~ JDE IMeiingen ~~ [CommercialRegister Handelsregister Local Court Meiningen Amisgericht Meiningen | www.handelsregister.de r 1\nRA000299 [Germany ~ JDE IMemmingen ~~ [CommercialRegister Handelsregister Local Court Memmingen Amisgericht Memmingen| www.handelsregister.de r 1\nRA000300 Commercial Register Handelsregister Local Court Merzig Amisgericht Merzig __www.handelsregister.de r 1\nRA000302 Commercial Register Handelsregister Local Court Montabaur Amisgericht Montabaur_|www.handelsregister.de r 1\nRAQ003T1 Commercial Register Handelsregister Local Court Narmberg Amisgericht Namberg _[www.handelsregister.de r 1\nRAC00306 Germany DE Neubrandenburg Commercial Register Handelsregister Local Court Neubrandenburg Amtsgericht www.handelsregister.de\nNeubrandenburg\nFAo00%7 Commercal Fegiser Hendelsroiser Loca Gourt Reurkicen Rarscren i andolrogiserdo -\nRA000308 Commercial Register Handelsregister Local Court Neuruppin Amisgericht Neuruppin _[www.handelsregister.de r 1\nRA000309 Commercial Register Handelsregister Local Court Neuss Amisgericht Neuss www handelsregister.de r 1\nRA000310 Commercial Register Handelsregister Local Court Nordhausen Amisgericht Nordhausen [ www.handelsregister.de r 1\nMinisterium des Innern T - p—— y — .\nRAC00711 North Rhine-Westphalia Foundations Directory Stiftungsverzeichnis Ministry of the Interior of North Rhine-Westphalia | des Landes Norcrhein- | TUS/wwwim.nrwisiitungsverzeichnis/stiftungen Twzg?pfi:fig for foundations in North Rhine:\nWestfalen\nRA000313 Offebach am Main Commercial Register Handelsregister Local Court Offenbach am Main Amisgericht Oflenbach - [ handelsregister.de _\nRAGO03T Oidenburg Commercial Fegister Tandelsregister Tooal Court Oldenburg “Amisgerioht Oldenburg | www handelsregister.de ]\nRA0003T5 Commercial Register Handelsregister Local Court Osnabriick Amisgericht Osnabrick | www.handelsregister.de 1\nRA0003T6 Commercial Register Handelsregister Local Court Ottweiler Amisgericht Ottweller | www.handelsregister.de 1\nRA000321 Commercial Register Handelsregister Local Court P6Bneck Amisgericht PeBneck [ www.handelsregister.de 1\nT ool g Py To G Pt e P [ e 0 I\nRA003TS [Germany [DE fPassaw ~ [CommercialRegister Handelsregister Local Court Passau Amisgericht Passau [ www.handelsregister.de 1\nRA000320 Commercial Register Handelsregister Local Court Pinneberg Amisgericht Pinneberg | www.handelsregister.de @ 1\nRA000322 Commercial Register Handelsregister Local Court Potsdam Amisgericht Potsdam __[www.handelsregister.de r 1\nRA000324 Germany DE Recklinghausen Commercial Register Handelsregister Local Court Recklinghausen Amtsgericht www.handelsregister.de\nRecklinghausen\nRAGD0325 Fegensburg Commercial Register Tandelsregiser Tooal Court Regensburg “Amisgerioht Fegensburg | www handelsregisterde ]\n\" P - AUTsihts- und o - —\nRA000737 Rhineland-Palatinate Foundations Directory Stiftungsverzeichnis Supervision and Services Directorate of Rhineland- Diensteitungedirkion B o - o-delogibin To be used for foundations in Rhineland-Palatinate\nRA000328 Commercial Register Handelsregister Local Court Rostock Amisgericht Rostock _[www.handelsregister.de 1\nRA000329 Rudolstadt Commercial Register Tandelsregister Tooal Court Rudolstadt “Amisgeriohl RUdoISdl | www handelsregisterde ]\nRA000342 Commercial Register Handelsregister Local Court Smmerda Amisgericht Sommerda_|www.handelsregister.de 1\nFAo00331 Commercal Fegiser Hendelsroioer Loca Qo Saatrcen Seaorion s andolregiserdo ]\nRA000741 Foundations Directory Stiftungsverzeichnis Ministry for Internal Affairs, Gonstruction and Sport ’é”;’:jgt‘eflfia\"sfié[)'r’t‘“efesv https:/www.saarland.de/4402.htm To be used for foundations in Saarland\nRA000332 Commercial Register Handelsregister Local Court Saarlouis Amisgericht Saarlouis _[www.handelsregister.de 1\nRA000333 Sankt Ingbert Commercial Register Handelsregister Local Court Sankt Ingbert fi]’g;segne”cm Sarkt www.handelsregister.de _\nRA000334 Sankt Wendel Commercial Register Handelsregister Local Court Sankt Wendel {imisgericht Sankt www.handelsregister.de _\nRAG00740 Saxony-Anhall Foundations Directory Sifungsverzeichns St Administraton Tandesverwaliungsami | htips//siungen. sachser- anhalt de/ 75 be used for foundations in Saxony-Anhalt\n— - - - Tandesdirerion Fiips /7www 1ds. sachsen de/Kommunal2i/7 —\nRA000739 Foundations Directory Stiftungsverzeichnis State Directorate of Saxony Tk To be used for foundations in Saxony\nRifpe T scbwi:\nRA000723 Germany DE Schleswig-Holstein Foundations Directory Stiftungsdatenbank State Government Landesregierung holstein.de/DE /Fachinhalte/S/stiftungen/stiftungsdat | To be used for foundations in Schleswig-Holstein\nenbank html\nRAGO0336 Schwerfut Commercal Fegster Fandelsregiser Tocal Gourl Sohwemiurt Amisgerichl Schweriurt [ www handelsregisier e ]\nRA000337 Commercial Register Handelsregister Local Court Schwerin Amisgericht Schwerin__[www.handelsregister.de r 1\nRAG00338 Segburg Commercial Register Fandelsregiser Tocal Gourl Segburg Amisgerichl Segburg__[www handelsregister de ]\nRA000339 Commercial Register Handelsregister Local Court Siegen Amisgerich Siegen _[www.handelsregister.de r 1\nP—— - Amtsgericht -\nFAO00949 Commersal Fegiser Hendelsroiser Loca Qo Sondersen i hndolrogiserdo ]\nRA000344 Commercial Register Handelsregister Local Court Sonneberg Amisgericht Sonneberg | www.handelsregister.de 1\nRA000345 Sadhagen Commercial Register Tandelsregister Tooal Court Stadthagen “Amisgeriohl Stadihagen | www handelsregister.de ]\nRAG00346 Stadioda Commercial Register Tandelsregister Tooal Court Stadroda “Amisgeriohl Stadiroda | www.handelsregister.de ]\nRA000347 Commercial Register Handelsregister Local Court Steinfurt Amisgericht Steinfurt__|www.handelsregister.de 1\nRA000348 Commercial Register Handelsregister Local Court Stendal Amisgericht Stendal __[www.handelsregister.de 1\nRA000349 Commercial Register Handelsregister Local Court Stralsund Amisgericht Stralsund__[www.handelsregister.de 1\nRA000350 Commercial Register Handelsregister Local Court Siraubing Amisgericht Straubing | www.handelsregister.de @ 1\nRAO00G5T Sttigan Commercial Register Fandelsregiser Tocal Gourt Sutgart Amisgerichl Stuigan [ www handelsregister de ]\n—— \" P p— Regierungsprasidium | Wtip://www 1p landbw.de/stvz/apex/i? - -\nRA000768 Germany DE Stutigart Foundations Directory Stiftungsverzeichnis Administrative Region Stuttgart Segerr D B A deTeS to be used for foundations in that region\nRA000352 Commercial Register Handelsregister Local Court Suhf Amisgericht Suhf www handelsregister.de 1\ne — - —_— ——————— Regierungsprasdium | Fip://www 1p landbw. de/svz/apexir? — -\nRA00771 Germany DE Tabingen Foundations Directory Stiftungsverzeichnis Administrative Region Ttbingen Reglorun o e to be used for foundations in that region\nRA000736 Germany DE Thuringia Foundations Directory Stiftungsverzeichnis Thuringia State Administration Tharinger https://www.thueringen. de/th3/tivwa/anwendungen/ [ 16 he used for foundations in Thuringia\nLandesverwaltungsamt | stiftungsverzeichnis/index.aspx\nRAG00353 Tostedt Commercial Register Tandelsregiser Tooal Court Tostedt Amisgerioht Tostedl | www handelsregister.de ]\nRA000354 Commercial Register Handelsregister Local Court Traunstein Amisgericht Traunstein _[www.handelsregister.de 1\nRA000355 Commercial Register Handelsregister Local Court Ulm Amisgericht Ulm www handelsregister.de 1\nRA000356 Voingen Commercial Register Tandelsregister Tooal Court Volkingen “Amisgerioht VOKingen | www handelsregister de ]\nRA000370 Commercial Register Handelsregister Local Court Warzburg Amisgericht Wirzburg_[www.handelsregister.de 1\nRA00358 Commercial Register Handelsregister Local Court Walsrode Amisgericht Walsrode _www.handelsregister.de 1\nRA000362 Weiden i.d. OPY. Commercial Register Handelsregister Local Court Weiden i.d. OPY. Amtsgericht Weiden id. |y handelsregister.de _\nRA000363 Commercial Register Handelsregister Local Court Weimar Amisgericht Weimar__[www.handelsregister.de r 1\n“Amt fir regionale Fitps /www.arl-\nRA000775 Germany DE Weser-Ems Foundations Directory Stiftungsverzsichnis Regional Development Office Weser-Ems Landesentwicklung | weniedersachsen.de/startseite/grundbesitz_und_st | to be used for foundations in that region\nWeser-Ems iftungerstiftungen/\nRA000364 Commercial Register Handelsregister Local Court Wetzlar Amisgericht Weizlar___[www.handelsregister.de r 1\nRA000365 Commercial Register Handelsregister Local Court Wiesbaden Amisgericht Wiesbaden [www.handelsregister.de r 1\nRAGO0368 Witich Commercial Register Fandelsregisier Tocal Court Witlich Amisgeriohl Witlich [ handelsregister de ]\nRAGO0369 Wapporta Commercial Register Fandelsregisier Tocal Gour Wappertal Amisgerioht Wupperal _[vww handelsregister de ]\npcsT! Commersal Pgier Hendelregier Loeel Cour Zuepricen Bueiicn e ]\n1/23\n","contentLength":9124,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:59:53.692Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/gleif-registration-authorities-list/2022-03-23_ra_list_v1.7.pdf","content":"\" ; iips //egovoniine. gegov.gov- gh/RGDPortaWeb/po\nSecuriies and\nRA000882 Ghana GH Ghana Securities and Exchange Commission Ghana Exchange Commission | htps:sec.gov o/ tobe used as a Validation Authority for funds\nna\nRA000883 Gibraltar Gibraltar __ Gibraltar Financial Services Commission Shraltar Fnandal, hitps://www. fsc.gi/ to be used as a Validation Authority for funds\nervices Commission\nENopIKG Kat\nAthens Chamber of Commerce and Industry + Blounyaviké | nttpusaww.protodikeio-\nRA000376 Greece GR Greece > ErujieAnTip1o ABnvay !\nOffcial Gazette FoueTTpto Ao ath.gr/opencms._protiopencms/ProtSite/\nTYNOIPAGEIO\nRAD0GES General CommerdialRegisty GEMI) | [Union of Hellenic Chambers [ [Pitips7mww.businessregistry.gr ]\nRAG00378 Coniral Business Register Genirale Viksomhedsiegisier Banish Business Authorly Erfvervesiyrersen itps JiGanTshbusinessauthority k7 ]\nhiip/aka. glida/Nirksomhed/GER/Fnd-\nRegistrar of Companies\nRAC00379 Grenada s Grenada Registrar of Companies and Intellectual Property |and Intellectual Property | http://www.gov.gd/departments/supreme_court_reg\n(Supreme Courty Registry) (Supreme Courty istry.html\nRegistry)\nGrenada Authoriy for the Reguiation of Financial | 1h Racuiaton o\nrenada Authority for the Regulation of Financial |the Regulafion o . dati .\nRA000884 Grenada ) Grenada e oY ror the Regulation of | ntipss/awww.garfin.go/ tobe used as a Validation Authority for funds\n(GARFIN)\n- - — - Trsitut Natonal de T o \" \" \"\nRAC00189 Guadeloupe Gp Guadeloupe Register of Companies (Sirene) Sirene National Insiitute of Statistics and Economic Stisiaue ot des hitp:/isirene.r/sirene/public/acoueil?\nludes Economiques -\nRAGGOTS2 Guadeioupe Guadelops Register of Commerce and Companies | Regisire du Commercs e des Socéies Tiogree Togrefte [Wwogeieson ]\nRA00038T Company Registry IPeparimentofRevenue and Taxafion [ [Pitips7www.guamiaxcom/ ]\nRegistry of federally insured credit National Credit Union | https://mapping.ncua.gov/ResearchCreditUnion.asp | {0 Pe used for federally insured credit unions, which\nRA000745 Guam cu Guam Regisl Registry of federally insured credit unions National Credit Union Administration National Crodi hitps: noua 2P [ are not in the regular business registers in the\nUSA; also to be Used for such enities in Guam\nRegistro Mercantl\nRA000382 Guatemala \nAlternative Investment Fund Sub Schemes\nDirectorate General of To be Used for for Sole Propristorships, Parnership\nDatabase of Importer Exporter Code Directorate General of Foreign Trade (DGFT) of | Foreign Trade (DGFT) ; firms, Trusts, Cooperative societies or multistate\nRA000709 N (EQ) Database of Importer Expotter Code (IEC) the Ministry of Commerce and Industry of the Ministry of www.dgft.gov.in cooperative stale Societies, which are not be found\nCommerce and Industry in the regular business register.\n- - - - Central Board of Excise\nICEGATE (Indian Customs Electronic | ICEGATE (Indian Customs Electronic .\nRA000713 N Commerce/Electronic Data interchange | Commerce/Electronic Data interchange (EC/EDI) | Sentral Board of Excise and Customs (CBEC), and Customs (CBEC), [ tips:/ww.icegate.gov.in/Enamod/\n(ECIED) Gateway) Gatoway) epartment of Revenue, Ministry of Finance epartment of Revenlie,\nMinistry of Finance\n- — — National Tnsiiuton for\nRAC00717 _ N _ NGO Directory (NGO-DARPAN) NGO Directory (NGO-DARPAN) Q;;gg;\" Insfitution for Transforming India (NIT! |t torming India (NITI | https:/ingodarpan.gov.infindex phpisearch/ to be used for ngo's\nAayog)\n- - Goods and Services\nRA000754 N GST Portal GST Portal gflfiz;\"d Services Tax Network (Ministry of Tax Network (Ministry of | https:/www.gst.gov.in/\nFinance)\nAroome __ Frener gens Francathoents Fosene Bankoftnae Fsene Bancefind 's‘/tg:r;/lgl\\:\\lm;il::grs%:(n/commonperson/EnghShlscnm _\np— pr— - - - - WMinisty of Nicro, Smal - o : \"\nRA000900 __ Udyam Registration Udyam Registration Ministry of Micro, Small Medium Enterprises Miniety f Micto: STal | hups:fiudyamregistration gov.in/Ucyam Veriy.aspx _\nRA00S0T odc N~ fwda | internafionalFinancial Services CentresAuthority | [hfip7/www.ifscagov.in/ 10 be used as a Validation Authority for funds\n- - — Registrar, Firms and - \" - pr——\"\nRA000902 N Madhya Pradesh List of Registered Firms and Society | List of Registered Firms and Society e, s and Sociefies, Governmentof | Societies, Government | SR/ meonio goy infPortaliServices/FirmsAnd\nof Machya Pradesh\nRA000400 _ Company Directory Direktori Perusahaan Ministry of Trade gg:g:ggga\"n https://www.kemendag.go.id/en new website address and name information added\nDireKiorat Jenderal\n; nistrative Affairs, | Administrasi Hukum\nRAC00763 Indonesia Indonesia Company Registry ,\\Dfl'i’r;\";{‘r’y“gfel_gfi“:fi' {?Jrhfiag{;‘f‘gm's\"a\"ve AMairS, | jmum, Kementerian [ ttps://ahu.go.id/profi-pt\nHukum Dan Hak Asasi\nManusia\nsS4\nRA0S05 an W —— —— fen I Securiies and Exchange Organizaiion [ |htp7enseolr 10 be used as a Validation Authoriy for funds\nRA0040T g @ g I |Regsirar of Companies [ |\"hiip7asjeelmotgov.ig/enindex himl 1\nRAD0S06 g @ —fwqg I Tiraq Securifles Commission (50) [ |hiips7wwwiscgovig/index php?lang=en 10 be used as a Validation Authoriy for funds\nRA00S07 v |@ g | CeniralBankofaq [ |hiips7www.cbirag.org/ 10 be used as a Validation Authoriy for funds\nRA000404 Ireland E reland Registers for financial service providers Gentral Bank of Ireland registers.centralbank ie\nand collective investment schemes\nRA000700 Ireland E Ireland Charities Register Charities Register Charities Regulator Charities Regulalor/An | hitps//www.charitiesregulator.ie/\nRialalai Garthanas\nRA000405 Isle of Man _ Isle of Man Companies Registry Companies Registry Companies Registry Companies Registry ;‘_‘;lr’r:‘/I/WWW-QOV-im/ded/cOf\"Paflies/cOmPanieSfegiS\" _\nRA000908 Isle of Man Isle of Man Isle of Man Financial Services Authority Isle of Man Financial | pios./mww.iomfsa.im/ to be used as a Validation Authority for funds\nServices Authority\nHAG0000 p— m \" Tsrasht Corporations AuThorily [Department of R v Filce gov ERUn TS BraelComporaton\nJustice) s/Pages/default aspx\nRA001045 DateGov [ [GovernmentICT Authority | [htps7/datagovilorganizatio/ministry of jusfie | ]\nTocamere (La Sooet\n. . f i Informatica delle o .\nRA000407 Haly ™ aly Business Register Registro Delle Imprese Infocamere diinformatica delle . |y registroimprese.it\nltaliana)\nTisTof collectve Tvesiment schemes | Elenco degll organismi df mvestmento coletive deT — —\nRA000408 Italy m ltaly (UCITS) risparmio (OICR) Bank of Italy Banca d'ltalia www.bancaditalia.it\nCommissione df\nRA000409 Haly ™ aly viglanza su fondi htp:/Awww. covip.it/\npensione\n- - Commissione Nazionale |, : p\nThe Halian Companies and Stock Exchange one hitp:/Awww.consob. itWeb/consob-and-its-\nRA000410 ttaly u taly Commission per le Societa e la Borsa |5 cijyities/investment-firms\n(CONSOB)\nPyy— - - P — — “Agenzia per IMala T—— - To be Used for ltalian PUblic AUThorilies\nRA000699 Italy Index of Public Administrations (IPA) | Indice delle Pubbliche Amministrazioni (IPA) ‘Agency for Digital Italy (AgiD) Aenzia perlh hitp://www.indicepa.gov. it/ T o e B A oo erators\nBanque Contral des\nRA000814 ory Coast cl ory Coast Central Bank of West African States (BCEAO) Etats de [Afrique de | https://www.bceao int/index.phplen tobe used as a Validation Authority for funds\n['Ouest (BCEAO)\nRAOOATT Comparies Register - TCSompanies Office of Jamaica [ [Piips/mwww.orclamaica.com/ - ]\nRA000910 - — BarkofJamaia Bank of Jamaica hitps:77boj org.Jm/ 10 be used as a Validation Authority for funds\n- - ———— — Financal Servioes - Po— =\" \"\nRAD00412 Companies Regisiration Legal Afiairs Bureaus hitp7Twww 1.touki.or jp7 - 0 0000\n13/23\n","contentLength":7140,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:59:53.692Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/gleif-registration-authorities-list/2022-03-23_ra_list_v1.7.pdf","content":"[RAccoot2 fdapan [P fepan 1 Securilies and Exchange Surveillance Commission | Thifp/www.fsa.go.jp/sesclenglish/ o be used as a Validation Authority for funds\n— - — — [Jorsey Financial\nRAC00414 Jersey JE Jersey Company Registry Company Registry ‘F\"ee’gsi’;‘{; inancial Services Commission Gompanies Services,Commission | ptpvwww frseyfsc.orggistry/\nompanies Regisiry\nJerey Financl Sovoes Gamissn T e | ey sorgnausiectsinds | 0be s 2. Valdsion Adhory for s\n- o be used for organizations I the Greater Amman\nRAC00G8 Jordan 0 Amman Business Directory Amman Ghamber of Gomrmerce http//vww ammanchamber.org joidefault_en.aspx? | Municipality registered at the Chamber of ;\nlang=en Commerce; given the amourt of available data this\nsource can be used for partial corroboration\n[RACCO4TS dodan [0 fordan | | ICompanies Control Depariment [ [ntp/www.cod.govjof 1\nr 1 ]Jordan Securiies Commission [ [htesvAscgoviol o be used as a Validation Authority for funds\nRA000416 Kazakhstan Kz Kazakhstan National Register of Business BitaHec-coKecTeHAIpy HeMIpNEpiHiH YATTLIK Ministry of Justice of the Republic of Kazakhstan hitp://www.adilet.gov.kz/en/base\ndentification Codes Tiginivi\nWHdopmaumoHHo-\n. . o YUETHbII LIEHTP,\nRA000915 Kazakhstan Kz Kazakhstan Depository of Financial Statements FENOSUTAPUI OUHAHCOBON OTHETHOCT | Information and Accounting Genter, Ministry of gm}v\\l%ficmo https:/opi.dfo.kz/p/en/dfo-search/opi-search to be used as a Validation Authority for funds\nPECMYB/IKM\nKASAXCTAH\nMGMNEKSTTIK KIpICTEp\n! B KomuTeTi, Komurer\nRA000916 Kazakhstan Kz Kazakhstan State Revenue Committee of the Ministry of roCyRapCTBeHHbIX https://kgd.gov.kz/en to be used as a Validation Authority for funds\nFinance noxozios MyHucTepcTea\nduHarcos Pecny6nuiit\nKasaxcran\nRAC00917 pa—— P pE—— The Agency of The Republic of Kazakhstan for Titps /www.gov kz/memiekeventiies/ardim? 1o bo tsed as a Valdation Authorty for fands\nRegulation and Development of Financial Market lang-en\ny Astana Financial Services Authorily, Astana ; - o -\nN Sukn (Adane) I N e e e I fobe tsedas a Valdaon Auhoryfor unds\nRegistrar General Office of the Aliorney General -\nA S o o N -t I ]\n- - ]CeniralBankofKenya [ [Mitpsv/mwww.centralbank goke/ o be used as a Validation Authority for funds\nr ]Capital Markeis Authoriy [ [hipsv/www.omaorke/ o be used as a Validation Authority for funds\n— —— — o Business and Companies Heguiatory Dvision - -\nRA000418 Kiribati KI Kiribati Comparies Office _ B e e e tves) www.meic.gov.ki\nRA000922 Kiribati KI Kiribati Ministry of Finance & Economic Development Ministry of Finance & f iy nww. mfed.gov.kif to be used as a Validation Authority for funds\nEconomic Development\n- - p— Agiencia 6 Reglstimil &\nRAC00519 Kosovo XK Kosovo Registry of Business Organizations and Kosovo Business Registration Agency (KBRA) Bineseve & Rosoves - | nttps:rarbk rks-gov.net\nTrade Names i\nBanka Qendrore &\nRA000925 Kosovo XK Kosovo Central Bank of the Republic of Kosovo (CBK) Republikés sé Kosovés | https://bqk-kos.org/lang=en to be used as a Validation Authority for funds\n(BQK)\n1 [ewrcwmedcomemadnwenwon| [RENGEecceestReewened] |\n- [CeniralBankofKuwal [ [nhitpsv/mwww.cbkgovkwren o be used as a Validation Authority for funds\n1 Capital Market Authoiy (CMA) [ [htpsv/www.cmagovkw/en/webloma/home o be used as a Validation Authority for funds\nUnited State Register of Legal Entities [ KOpuankanbik »xakTapabiH, thunmanaapabiH\nRA000421 Kyrgyzstan KG Kyrgyzstan and Branches (Ministry of Justice of | (ekynuynyKTepayH) GMPAVKTYY MamnekeTTik hitp://minjust.gov.kg/?page._id=10098lang=kg\nKyrgyz Republic) peecTpyt\nuHaRGH! pLIHOTyR\nState Service for Regulation and Supervision of the |xerre canyy ara ; dati ;\nRA000928 Kyrgyzstan Ka Kyrgyzstan State Service for xorro sanyy hitps:/fsa.gov.kgi#home to be used as a Validation Authority for funds\nMaMNEKETTUK KblaMaTb!\nKopres\nRA000929 Kyrgyzstan KG Kyrgyzstan National Bank of the Kyrgyz Republic Pecny6nvikackbiH | https://www.nbkr.kg/index jsp?lang=ENG to be used as a Validation Authority for funds\nVRYTTYK 6aHKbIHbIH\nEnterprise Registration . [Minisiry of Industry and Commerce [ [hitps/www.moicgovla/ r 1\n[RAOCOSS0 ftees ~ JtA s 00000 [IBankofthelaoPDR | [hitpsv/www.bolgovla/enindex o be used as a Validation Authority for funds\nr ] [ [hiips/wwwlsc.govlaEN/ o be used as a Validation Authority for funds\nRA000423 Latvia Lv Latvia Commerce Register Register of Enterprises of the Republic of Latvia | Latviias Republikas .y, ur.gov.v\nUznsmumu Regstrs\nDatabases of enterprises 1 [ [hips/wwwlursoilV7l=en 1\nooz e v ee ] [ | enduiaimeiercommiom [iiionee e [Mesikkiveninatey fobe tsedas a Valdaon Auhoryfor unds\nMinisiry of Justice hiip:/cr justice gov Ib/searchies Tist.aspx r 1\n- Office of the Minister of State for Admimistiaive | ol 558 Tl 5 = |, : :\nRA000729 Lebanon 8 Lebanon Directory s e A o htp://www. dawlati.gov. Ib/directory\nr = [Capiial Markels Authoriy [ [Mhips/www.omagovlb/ o be used as a Validation Authority for funds\n- One Slop Business Faciliation Centre, Ministry of - -\nRA000426 Lesotho Ls Lesotho Company Register _ P S usiness hitp://www. obfc.org. Is/registry/default. php\nLiberia Business Registry Liberia Business Regisiry r @@ [ntiodAmwwibrgovlv r 1\nT T e N (T (G TEr e |osiubiecolors lobe e as a Valdaon Auhoryfor nds\nr O ]CeniralBankoflibya [ [nitpsvicblgoviyens o be used as a Validation Authority for funds\n[RAGCOSS7 tbya Jtv — qdobya 1 tibyan Capial Market Authoriy [ [nhtpsvomagoviyer/ o be used as a Validation Authority for funds\nCommercial Register Handelsregister Office of Justice hitp://www.cera hrweb/ger/irmensuche afihtm | ]\n0 0 [Financial MarketAuthorily Finanzmarklaufsicht | itps 7/www.fma-fi [ven/ 1\nTn Frenoh: Office 1&deral\n- Regi . . UID-Register: de la statistique; in esinLi ; ster in this\nRAC00548 Liechtenstein u Liechtenstein UID-Register In Prench: Registre IDE; in German: UID-Register; | oo o) staistical Office German: Bundesamt fir [ https://www.id.admin.ch/ Companies in Liechtenstein may also register in this\nin ltalian: Registro IDI man: Bundesamt fdr Swiss UID register\nStatistik; in talian: Ufficio\nfederale di statistica\nRegister of Legal Entiies Juridiniy asmeny registras State Enterprise Centre of Registers hitp://www. regisirucentras. jarfindex_en. php 1\n- - [CeniralBankofihe Republicof Lihuania hitp://www.b. Umarkets in_financial instruments | ]\nTraceand Cempery Fgiser Regisredo Qommerc ot oo Socétes Luvembour Bushess Regier Regors 0o oo\nCommission de - - P\nFinancier\nTegilux - Journal Offciel\nRA000434 Luxembourg ] Luxembourg Legilux - Official Journal duGrand-Duché de | http://www.legilux.public.lu/\nLuxembourg\nFundsquare Market Infrastructure [ [tuxembourg SiockExchange [ [Mitpsv//www.fundsquare.net/search 1]\n4/23\n","contentLength":6724,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:59:53.692Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/gleif-registration-authorities-list/2022-03-23_ra_list_v1.7.pdf","content":"RA000436 Macao Macao Directorate of Justice Affairs Services Direcgao dos Servicos | hiins:/mww.dsaj.gov.mofindex_tc.aspx\nde Assuntos Justica\nRegistration of BUsinesses and Non - - - Tiew name of organisalion and new Websie\nRAGO0ET0 o ——— | mewsmomw oo Bt o VAT s s o ! To b Ueed 55 5 VaTdaTon Aoty or o\nRAGO0ET2 1 A s ) T = T SURharaya SoRUT e T =2 Gom 7 To B 0o 55 VaTdaTion Aoty or o\nAR [Wevee W [Wawes | vmhy o Eoromic Doveloorow [oTwwasegonw ]\nRAGO0ETS [ W Ve | [Gau Ve v Aol I L Y To B 5o 55 VaTdaTon Aoy or s\nRROO0GTT [P W [Wagee | 7\" VanvesWoemy Aoy [T s To B Ueed o5 VaTdaton Aoty or o\nAgence pour y — ; —y\nRA000442 ML Investment Promotion Agency Promotion des hitp://wwwapimali gov.mifindex. php?page=api\nInvestissements. 9 ™\nBanque Contral des\nRA000814 ML Conial Bariof Wost Afican Siatos (BOEAD) [ Slaisdo TAliqua de | poiunk.booao itincox phplen tobe used as a Validation Authority for funds\n'‘Ouest\nARG oty o Compares e BT K R WAl AT Busivees Rty TWoR) I /A ]\nRAOO0545 Financial Services Register [ |Wala Fnancal Sorvices Authoriy [ [\"ps/wwwmisa mifnanciaservicesregiter |1 be Used as a Valdation Auhortty Tor funds\n~ WViarshall Sands\nRAC00444 Marshall Islands MH Marshall Islands Marshall Islands Maritme and Corporale Maritime and Corporate | https://www.register-iri.com/corporate/\nAdministrators tim\nAdministrators\nRADO055 Warshall [Sands Warsrall ands | N [ T N [T ) 06 Used a5 a Valdalion Aorty for Tands\n\" \" - - Tnsitut Natonal de Ta e \" - \"\nRAC00189 Martinique Martinique Register of Companies (Sirene) Sirene National Insfitute of Statisiies and Economic Statistique et des hitp:/sivenefrisirene/public/acoueil?\nEtudes Economiques —\nRA000192 [Variique ~—— JMQ ~ [Wartiniquue JRegisterof Commerce and Companies [Regisire du Commerce et des Sociétés Infogreffe Infogrefe (wwwinfogreflecom [ ]\nComara and Bsness Fegreralion Deparment\nRA000447 MU Mauritius Corporate and Business Registration I(gévei) \"\\)flr;‘ne'fi{)v of Finance and Economic https://companies.govmu.org/Pages/defaultaspx | new website address\nTo b6 Used for Naurius domestic eniies\nrancial Senvi ; \" sion/reaister | icensed/approvediauthorisediregistered by the\nRA000757 MU Mauritius Register of Licensees Register of Licensees Financial Services Commission Financial Services hitps:/Awvww.fscmauritius.org/en/supenvision/register | 50501 BRI\nCommission of-icensees - ) ' )\nlicensed/approved/authorisediregistered to provide\nfinancial services or to conduct financial business\n- - — - Trsitut Natonal de 1 o - - ;\nRAC00189 Mayotte YT Mayotte Register of Companies (Sirene) Sirene National Insiitute of Statistics and Economic Stisiaue ot des hitp:/isirene.r/sirene/public/acoueil?\nludes Economiques -\nARG Figeer of Commercs and Cormparies | Regiare d Cormmerce o1 s Sooeee Tregrete Trogree e\nServicio do ' \"\nRAG049 Taxpayer Register Registro Federal ce Contrbuyentes Tax Administration Agency N _\n- - Catdlogo del Sistema Financiero Mexicano — - — Secretaria o Hacienda | hips /i gob mx/shop/documentosicataingo-der\nRA000652 Mexico MX Mexico _ s Ministry of Finance and Public Credit ot Nitps 77w, gob.myshop/dox\nRAGO0T03 Fubic Regiser of Commerce Registo PUbioo 4o Comercio Wiristy of Ecoromy Sooretaria de EcononTa | tps:/imo. sconoma.gob.mx ]\nComision Nacional\nBancaria y de Valores\nRA000949 Mexico X Mexico (CNBV); Secretariade | https:/Awww.gob.mx/cnby tobe used as a Validation Authority for funds\nHacienda y Credito\nPiblico\nm—— - Banking Board of the\nRA000948 Vicronesia, Federated Micronesia, Federated States of _— Banking Board of the Federated States of Federaled States of | https://bankingboard.gov.fm/index html to be used as a Validation Authority for funds\nMicronesia\nComisa Nafionala a\nRA000950 Moldova Moldova National Commission for Financial Markets Ficll Fnarciaro http//old.cnpf. mdlen/stary tobe used as a Validation Authority for funds\nRéperiore du\nRA000452 Monaco MC Monaco Registry of Commerce and Industry | Répertoite du Commerce et de Industrie Registry of Commerce and Industry Gommerce ol de hitp:/Awww. . gouv.me/rc/\nlindustrie\nRA000453 Monaco MC Monaco Financial Activities Supervisory Commission Commission de Controle [y, /ww ccaf.mcren/\ndes Activités Financieres\nRA00454 [Mongola —— JMN_ Momgoh [ |Mongolian Siale Registrafion Office [ [wwwburigelmn ]\n30XVLLyyNaXx XOpoo\n- - - ITSUr———— Contral Regiry of Business Entities of The Tax\nRA000455 Montenegro VE Montenegro Central Registry of Business Entities | Centralni Registar Privrednih Subjekata e O s www.crps.me\nSecurilies and Exchangs Commission of Romisia za 1Z7e - =\" -\nRA000953 Montenegro VE Montenegro __ Soues g X oniel hitps:/Awww. somn. melen/ 1o be used as a Validation Authority for funds\nRA000456 Montserrat [ Montserrat Financial Services Commission Montserrat Financial Services http://www.fscmontserrat.org/\nCommission Montserrat\n- - ifice Marocain de 1a\nRA000457 Morocco MA Moracco Central Trade Register Registre Central du Commerce Moroccan Industrial and Commercial Property Propriété Industielle et | http://www.ompic.org.malen/content/about-rcc\nCommerciale (OMPIC)\nAU Marocaine du\nRA000955 Morocco MA Morocco Moroccan Capital Market Authority Marche dos Gapieux | podfu.amme malen tobe used as a Validation Authority for funds\n- - — - - Tiip 7w porTaldogoverno. gov mz/porEmpresasy\nRA000956 [Mozambique Mz [Mozambiqwe [ [ [BankofMozambique Banco de Mogambique | https://www bancomoo. mz/ 10 be used as a Validation Authority for funds\nDirectorate of Investment and Company T\n15/23\n","contentLength":5481,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:59:53.692Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/gleif-registration-authorities-list/2022-03-23_ra_list_v1.7.pdf","content":"o[ oc s ogst\nSl admbendhe\nRA000957 Myanmar Myanmar Securilis and Exchange Commission of Myanmar | X6 000565 00 https://secm.gov.mm/en/home/ to be used as a Validation Authority for funds\ncooudSeqiddnto\nb\nFAo00959 e fwn e [ceeeneimema s chm govmmimy fobe tsedas Vldaion Auhoryfor s\nRAC00460 [Namibia INA 000 [Namba 00000 [BusinessRegister . [Businessandintellectual Property Authority | [http//www.bipana/business-registration/ |\nRA000959 [Namibia INA 00 [Namb@ 000000000 00009 0000000000000 [BankofNamibia Bank of Namibia hittps://www.bon.com.na/ tobe used as a Validation Authority for funds\nP E—— - —Nambia Financal\nRA000960 NA Namiia (e Fanancial Insitutions Supervisory Authorty | ngiifions Supervisory | htps:/www.namfisa com.nal o be used as a Validation Authority for funds\nAuthority (NAMFISA)\nRAC0046T [Naurs N fNeww 0000000 0000000000000 00 []Office ofthe Registrar of Corporations -+ 1\nRACO061 [Naurs N fNaw 000000000 00000000 0000000000 [DepartmentofFinance | [httpsi/naurufinance.info/ fobe used as a Validation Authority for funds\nRAC00462 [Nepal NP [Nepal 000000 [CompanyRegister __ []Office of Company Registrar | [nttv//www.ocr.gov.npfindex.php/np/ 1\nRAC00962 [Nepat [N fNepat 0000000000000 000000000l 0 [Securities Boardof Nepal [T A Sle [ httpsi//www.sebon.gov.np/ fobe used as a Validation Authority for funds\nRAG00463 Netherlands Netherlands Business Register Handelsregister The Netherlands Chamber of Commercs Kamer van Koophandel | www Kvk.nienglish |\nRA000464 Netherlands NL Netherlands The Netherlands Authority for the Financial Autoriteit Financisle https://www.afm.nl/en/professionals/registers\nMarkets Markten\nSrily 1o be used for dhurcheseligious organizalions\nRA000664 Netherlands NL Netherlands Public Benefit Organisation Register | ANBl-register Tax and Customs Administration Belastingdienst www.belastingdienst.nl which are ot registered in the business register of\nKvK (RAO00463)\n\" \" - - Tnstiut National de 1a e \" : \"\nRA000189 New Caledonia NC New Caledonia Register of Companies (Sirene) Sirene National Insitute of Statistics and Economic N atonalJ hitp:/sirene.fr/sirene/publiciaccue?\nStudies ) sirene_locale=en\nEtudes Economiques\nRAGO0T9 Neow Caledonia New Caledona Fegster of Commerce and Companios | Fegiaiie du Commerce of des Socisiés Triogrerie Tiogrefie wiogrefooom | |\n— - — Thsiitut de 1a statisique\nRA000963 New Caledonia NC New Caledonia Répertoire des entreprises et des établissements etdes études htps://www.isee.nc/ridet#liste-d-entreprises\n(Ridet) &conomiques Nouvell-\nCalédonie (ISEE)\nP . [ Companies Office\nRA000466 New Zealand NZ New Zealand Companies Register Companies Register Companies Office (Ministry of Business Innovation | (Ministry of Business |y business.govt.nz/companies\nand Employment) Innovation and\nEmployment)\nI } ——[Companies Offics ) }\nRA000749 New Zealand NZ New Zealand New Zealand Business Number Register | New Zealand Business Number Register Comparies Office (Ministry of Business, Innovaton { (Ministry of Business, [ ips:/www.nzbn.govt.nz/ to be used mainly for other entity types than\nand Employment) Innovation and companies\nEmployment)\n— \" Fnancial Markels - o \"\nRA000964 New Zealand New Zealand __ Financial Markets Authority New Zealand R Nkl fang | MPS/miwima govinz/ to be used as a Validation Authority for funds\nRA000467 Nicaragua Nicaragua Registro Publico de la Propiedad Inmueble y Direccion Nacional de [ . /mww. registropublico.gob.ni/\nMercantil Registros\nSuperintendecia de\nRA000965 Nicaragua Nicaragua Bancos y ofras hitps://www.superintendencia.gob.ni to be used as a Validation Authority for funds\nInsituciones Financieras\n- P Registre du Commerce\nRA000468 NE Registre du Commerce et du Creédit Mobilier otdu Cradit Mobiier http:/www.justice.gouv.ne/?q=node/103\n(RCCM) (RCCM)\nBanque Central des\nRAC00814 NE Central Bank of West African States (BCEAO) Elats de [Afrique de | https://www.bceao.int/index.php/en to be used as a Validation Authority for funds\nIuest (BCEAO)\nFAo00169 Moern M fNe [commnfesn Compary Fegisty Corport At Commission Commegon ™\" [mwowgors | |\nRAC00966 [Nigeia NG INgela [CapitalMarkefOperalorSearch(CMOS)] [Securilies and Exchange Commission [ [Nitpsi/sec.gov.nglomos# to be used as a Validation Authority for funds\nRAC00967 [Nigeia NG INgel [ 0000000000 000000000 [CentralBankofNigeria Central Bank of Nigeria_|https://www.cbn.gov.ng/ tobe used as a Validation Authority for funds\nRA000470 Nwe N0 JNwe [CompaniesRegisier r @@ CompamesOffce [ [htip//www.companies.gov.nufems r 1\nEpHowanTepcku\nRA000437 North Macedonia MK North Macedonia Central Register (Trade Register) Central Register of the Republic of Macedonia cuctem Pe-akTus www.crm.com.mk\nLerTpanes Peructap\nMakegoHuja\nRA000968 North Macedonia MK North Macedonia Registry of Investment Funds, Fund Peructap Ha UHBECTULCKI (hOHAOBM, CYOJeKTU [ 5o rities and Exchange Commission Kouvcjata saxaptii | hiyos//sec gov.mk/ to be used as a Validation Authority for funds\nlanagement Entities 3a ynpasyBarbe O (hOHA0BU 0/l BpeAHOCT\nHapopHa 6aHka Ha\nRA000969 North Macedonia MK North Macedonia National Bank of the Republic of North Macedonia | Peny6nuka CesepHa | hitps:/ww.nbrm.midpocetna-en.nspx to be used as a Validation Authority for funds\nMaxegnoHuja\nFho00:71 Norten Varre sando| P |Nortern berina sancs b [Tt [ [oeevcomermgomaregs ]\nRAG00970 Northern Mariana 19ands |MP | Northern Mariana lslands | |Depanmenioirmanes Depariment of Finance | Rips//www.finance. gov.mp/ 1o be Used as a Validalion Authorly Tor funds\nRA000472 [Noway N0 [Noway 0 [TheRegisterof Business Enterprises | Foretaksregisteret The Bronnoysund Register Centre | [httos/Awww.brreg.nof 1\nFAo00179 My M0 e |aEmes o Jenhetsntet The Sromosund Fgistr Cente I (T ]\nRA000971 [Norway N0 [Norway —[Finanstilsynet's registry Virksomhetsregister Financial Supervisory Authority Finanstilsynet https://www.finanstilsynet.no/ to be used as a Validation Authority for funds\nRA000474 Joman Jom 00 fOman 00000 [NatonalBusinessRegister 0 [Ministryof Commerce and Industry https://www.business.gov.omiwpsiportaliecrihome | |\nRA000972 Joman Jom 0 foman 000000 0000 0000000000 [CapialMarket Authority | [nhttesvemagovom/ tobe used as a Validation Authority for funds\nRA000475 Corporate Registry @ [Securitiesand Exchange Commission | [www.secp.govpk 0 |\nRA00075 pes e e} [GREeTeoseeoieotiemony | [osaesovonticootteatomeygeess | |\nRA000973 [Palw [pPw fPalw 0000 [Financial Insiiufions Commission [ [hitp/www.ropficorg/ tobe used as a Validation Authority for funds\n: \" - - - P— Vllp:/ . iNG GOV.pS/COmPTeg aspx?\nRA000477 Palestine PS Palestine Comparies Registry _ Comparies Registration Department _ e 2o\nRA000974 [Palestine |PS [Palesre 0000000l 0000000000000 0000000000000 [Palestine Capital Market Authority | [htps//www.pmapsien/ tobe used as a Validation Authority for funds\nSuperniendencia del ’ I -\nRAG00977 Papua New Gunea Papua New Gunea | |BakoiPapuaNew Gunea [ [Fps/wwwbankong.govpg/ T b6 Used as a Valdalion Authorly Tor funds\nFAo00:80 e e (2 e e i Comrgo = \"= | Mo i ooy e -\nSistema Unificado de\nRA000481 Paraguay PY Paraguay Unified Business Opening System Apertura y Cierre de | www.suace.gov.py\nEmpresas\nFho0097S ooy e L [eenelSeoes conmision Vares” \"o | s cnvgorpy fobe tsedas a Valdaion Aoty for nds\nSuperinendencia\nRA000482 PE Public Register of Commerce National Public Registry Nacional de Regstros | itps:/w.sunarp.gob.po/index.asp\ntblicos\n16/23\n","contentLength":7420,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:59:53.692Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/gleif-registration-authorities-list/2022-03-23_ra_list_v1.7.pdf","content":"Rebonal do At htp:/i I b.pe/cl\n. ) jacional de Aduanasy | http:/e-consultaruc. sunat gob.pe/cl-ti-\nRA000689 Peru PE Peru Registro Unico de Contribuyentes (RUC) Nacional de Adua R o\nTributaria (SUNAT)\nSuperniendencia del - — -\nSuperntendencia de - =\" -\nRA000483 Philippines Philippines Companies Register - [Securities and Exchange Commission | Jwwwsecgovph 1\nBusness Name\noo iooi ; strati ; strati Business Name Registration Service (Department | Registration Service ; : ; ’\nRA000760 Phiippines PH Philippines Business Name Registration Business Name Registration Business Name fegis Regitration Service, | tps:/bnrs.dtigov.phv to be used for businesses (not comparies)\nand Industry)\np— pr— \" \" Cooperative - \"\nRA00761 Phiippines Philippines __ Cooperative Development Authority Sooperaive puthorty | MtPs/eda.gov.ph/ to be used for cooperatives\n- - - - — - Minsterstwo itps /7eKrs ms. gov. pIweblwy szUKwarka-\nRA000484 Poland PL Poland National Court Register Krajowy Rejestr Sadowy (KRS) Ministry of Justice s ok e\nInvestment Fund Management Towarzystwa Funduszy Inwestycyjnych, Fundusze |, o - . Komisja Nadzoru .\nRA000485 Poland PL Poland ggrrg?::ugzhg\\;estmem Funds and ,nwesty‘éyjne iy Al E‘}’“ngyécln'e Polish Financial Supervision Authority Fimns‘gwego htps:/www.knf.gov.pl/podmioty\np— - PE— P Ministerstwo - - -\nCentral Registration and Information on | Gentralna Ewidencia i Informacia o Dziatalnosci - . rstwo s iprod.ceidg gov.pl/CEIDG/CEIDG. Public.UIS\nRA00486 Poland PL Poland Sentral A B e e Ministry of Enterprise and Technology Prscsebioczogei i | oIS K\nNafional Official Business Register Rrajowy Telestr Urzedowy podmiotow gospodarki = Giowny Urzad Titps //wyszuKwarkaregon. stat. gov. plappBIRAndex\nRA000654 Poland PL Poland Natonal € rajowy rolesir ures Central Statistical Office of Poland Slouny Urza ipe:\ne - - ThSHiUTe of Regisiies and Notary (Vinstry of ThSTTUT0 oS Fegistos & g o —_—\nRA000487 Portugal PT Portugal Commercial Register Registo Comercial et Instfiuto dos hitp://www. irn. mj. pt/IRN/sections/inicio\nComissao do mercado\nRA000488 Portugal PT Portugal Securities Market Commission de valores mobiliarios | http://www.cmvm.pten\n(CMVM)\nAutoridade de\n' s 4 | supervisao de seguros e | http:/www.asf.com.pt/NR/exeres/3DCB6032-0C4A-\nRA000489 Portugal PT Portugal Insurance and pension funds supenvisison autoriy | SUPervisao do sequ itpi i ast corm. pliNRlexeres\n(ASF)\nDrocao Geral da ©be used or it paricilaros de\nRA000784 Portugal PT Portugal Social Security Seguranca Social Directorate-General for Social Security anese ot hitp://www. seg-social.ptfnicio solidariedade social’ and “Associagdes mutualistas\nregistadas”\nRA000981 Portugal Portugal List of Institutions Lista de entidades Gentral Bank of Portugal Banco de Portugal 's‘gl:iss:{immgggetgal-D'/enlvage/\"Sl'instim“O\"S' to be used as a Validation Authority for funds\n- - - - m - - - - Departamento & Titps //proorpfiing TThst com/CorporaionSearch as\nRA000493 Puerto Rico _ Puerto Rico Registry of Corporations and Entities | Registro de Gorporaciones y Entidades Puerto Rico Department of State B e Rico |y\nRA000665 Puerto Rico Puerto Rico EDGAR EDGAR Securities and Exchange Commission Securiiesand https://www.sec.govledgar/searchedgar/webusers.\nExchange Commission | htm\nT be Used for Tederally nsured credTt Unions, which\nRA0745 Puerio Rico Puero Rico Registry of federally insured credit Redistry of federally insured oredit unions National Credit Union Administration National Credit Union | https://mapping.ncua.gov/ResearchCreditUnion.asp | are not in the regular business registers in the\nunions gistry y Administration X USA; also to be used for such entities in Puerto\nRico\nOficina del Comsionado\nRA000982 Puerto Rico Puerto Rico Office of the Commissioner of Financial Institutions | de Insfituciones hitps:/ocit.pr.gov to be used as a Validation Authority for funds\nFinancieras (OCIF)\n— Companies Registration Office (Qatar Fmancial . Tiips //6S6TVices.af qa/qicpUBTGTegiSterpUBGTegTs\nRA00419 Republic ofKorea Republic of Korea Corporafion registration Supreme Court Regisiry el Jwwwiosgoke 000 0000000000\nRA00657 Republic ofKorea Republic of Korea Business registraion National Tax Service = waownisgoke 0000000000000\nRAQ00658 Republic ofKorea Republic of Korea Funds Registration Korea Securities Depository SEOErEAE wowksdorke 0]\nRAG00523 Repubic o Korea Repubic of Korea [ [Fiancil Sewices Commeson Rilps /o156 g KTengindex Tobe Used as a Valdation Aulorl for funds\n- - - - - \" - - Oficiul National al\ninanci Auloriatea de - ————\n} . Financial Instruments and Investments o . . hitp:/asfromania.ro/en/supervisionregistries/financi\nRA000498 Romaria Romania Registry Financial Supervisory Authority Supraveghere et ivestments Y\nFinanciara (ASF)\nRAGOO7TE [Fomama —_|[F0 ____ |fomama ______________ |NGOregser Fegisirul Nafional ONG. Minisiry of Justice Ministerul Justiier Fitp:/Www JUst ro/enVregistrulnational-ong/ Tobe Used for ngo’s\nRA000719 Romania Romania Tax Payer Register Registrul contribuabililor/platitorilor Ministry of Public Finance Ministerul Finantelor | http://www.mfinante.rofagentinume. htmi?\nPublice pagina=domenii\nM I Fi I Dloarare o/D R %20National\n; ' ' ) - i ' - ! - - inisterul Finantelor | guvernare.ro/Documente/Registrul%20National%2\nRA000720 Romaria Romania National Register of Public Insfitutions | Registrul National al Institutiilor Publice Ministry of Public Finance Minister guvernare ro/Documente/egietrul%20National®%2\npf\nRA000985 [Russia [RU JRwssa [ [ [IBankofRussa hitps//www.cbr.ru/eng’ o be used as a Validation Authority for funds\nRA000500 Business Register - [office ofthe Registrar General [ [hipsorgrdbrws r 1\nRA000986 r = [NaionalBankofRwanda [ [Pitpss/mwww.bnrrwihome/ o be used as a Validation Authority for funds\nRA000987 [Rwanda [RWw JAwanda [ 00000 [Capital Market Authoriy [ [hip/www.omamw o be used as a Validation Authority for funds\n\" \" = - Tnstiut National de 1a o \" - \"\nRAC00189 Réunion RE Réunion Register of Companies (Sirene) Sirene National Insfitute of Statisiies and Economic Statistique et des Plipdiitone. isiene/pubiciaccueil?\nEtudes Economiques\nRA000192 Register of Commerce and Companies | Regisire du Commerce et des Sociétés Infogreffe Infogreffe [www.infogreffecom 00000000\n\" \" = - Tnstitut National de 1a i \" - \"\nRAC00189 Saint Barthélemy BL Saint Barthélemy Register of Companies (Sirene) Sirene National Insfitute of Statisiies and Economic Statistique et des Plipdiitone. isiene/pubiciaccueil?\nEtudes Economiques\nRAGO0T9Z Sant Barelemy SniBarhelemy Regisier of Commerce and Companies | Regisire du Commerce e des Socéies Tiogrete Tiogrefte e\nSaint Helena, Ascension . , ) o - Financial Services. - — -\nRA000988 Saint Helena, Ascension | sh Saint Helena, Ascension and Tristan da Cunha Financial Services Regulatory Authority (FSRA) | Regulatory Authority | hitps://www.fsra-sthelena.com/ to be used as a Validation Authority for funds\n(FSRA)\n——— o Novie | Financial Services\nRAC00990 Saint Kitts and Nevis Trust information Trustinformation Financial Services Regulatory Comission Nevis | gequiatory Comission | hitps:/mww.nevisfsrc.com/ to be used as a Validation Authority for funds\nNevis branch\ns - s - - - Registrar of Companies (Financial Sevices -\nRA000502 Saint Kittsand Nevis | KN Saint Kitts and Nevis Companies Registry _ R A e hitp:/Awww.fsrc.kn/\nI — — [ Fnancal Services\nRA000989 Saint Kitts and Nevis Saint Kitts Trust information Trustinformation Financial Services Regulatory Comission St Kitts Regulalory Gomission ntpsdww s/ to be used as a Validation Authority for funds\nt. Kitts brancl\nRAG00503 Regisity of Companies | [RegistryofCompaniesandintellectualProperty | [hitpuiwww rocipgovlo/stucial 000000000 1\n17/23\n","contentLength":7726,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:59:53.692Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/gleif-registration-authorities-list/2022-03-23_ra_list_v1.7.pdf","content":"RA000504 Saint Lucia o Saint Lucia Registry of International Business Regisiry of Infemational Business Companes and | imermational Financial Contro RN ETC (Rme——\nCompanies and Inernational Trusts | International Trusts Centre\nFinancal Services\nRA000991 Saint Lucia Lc Saint Lucia Financia Sevices Regulatory Auhory (FSRA) | quletory Authory | npsisrasuciaorg! tobe used as a Validation Authority for funds\n- - — - st Natonal de 1 — - - -\nles Economiques\nRAGO0TO2 Saint Wartn Saint Marin Register of Commerce and Companies | Regisire du Commercs ol oS Socieies TiogreTie Tiogreie [Wwogrefeoom | ]\n— - - — - Trsitut Natonal de — - - -\nRAC00189 a?a’fie%fi\"e and Saint Pierre and Miquelon Register of Companies (Sirene) Sirene National Insiitute of Statistics and Economic Stisiaue ot des hitpdlsiene frisiene/publiciaccueil?\ntudes Economiques\nRA000192 o ere and _ Saint Pierre and Miquelon Register of Commerce and Companies | Registre du Commerce et des Sociétés Infogrefe Infogreffe _\nRA000992 Saint Vincent and The Saint Vincent and The Grenadines Mutual Funds Administration Mutual Funds Administration Financial Services Authority imgcrg' Services https:/svgfsa.com/ to be used as a Validation Authority for funds\nST Vincent & e\nSaint Vincent and the itV : St. Vincent & the Grenadines Commerce & Grenadines Commerce o, ;\nOfiice\nRA000509 r o ]Samoa infernafional Finance Authorly [ Jwewsfaws ]\nRA000510 Samoa Company Registry - [wnisiry of Commerce, Indusiry and Labour [ [Piips7/www.Businessregistries gov.ws/ ]\nCamera i Commerdio\nRA00051 1 San Marino M San Marino Registry of Companies Registro imprese Chamber of Commerce San Marino della Repubblica di San | https:/iregistroimprese.cc.sm/\nMarino\nCentral Bank of the Republic of San Marino Banca Centrale della\nRA000993 San Marino M San Marino (CBSM) Repubbiica di San hitps:/Awww.besm. smisitelen/home. htmi tobe used as a Validation Authority for funds\nMarino\nEmorosat G e https://publi Joud\ne . mpresas (do Ministério | https://publicmanager-guenet dloud-\nRA000512 Sao Tome and Principe | ST Sao Tome and Principe da Justica e Direitos | stp.netipublicmanager-guenet/pages/index.php5\nHumanos)\nRA000994 Sao Tome and Principe Sao Tome and Principe __ Gentral Bank of Sao Tomé and Principe .?ggcé\"ecg;}figi'pf Sao |hitps:ibostp.st/ to be used as a Validation Authority for funds\nRA000702 Saudi Arabia Saudi Arabia - o SaudiCapitaMarkefAuthoriy hitps //www.cma.org sa Tobe used forfunds\nObservalorre do\nUlindusrie du Senegal | http://www.obs-\nRA000514 Senegal SN Senegal Observation Postof Industial Acivites in Senegal | (nstre d Commerce | indusirie snimenuangfiste%200f%20cnteprise im\ne I'Industrie et du #\nSecteur Informel)\nRegistre du Commerce et du Crédit Mobiier \" iip /W SoTvice pUBITG. goUY sn/index php/demarc\nFAo00sts S o S I 5 I (i (e e\nTrade Point Senegal\nRA000516 Senegal SN Senegal Trade Point Senegal (Ministry of Commerce) (Ministére du hitps://www.tpsnet.org/\nCommerce)\nBureau dappUi & - - - -\nRA000779 Senegal SN Senegal database of legal notices base de données dannonces légales Business Creation Support Bureau (BCE) cresion donioprio hitps:/iwww.crealiondentreprise. snirechercher-une\nBanque Contral des\nRA000814 Senegal SN Senegal Central Bank of West African States (BCEAO) Elatsde TAinquado | ntpodfumnkbooao itincox phplen tobe used as a Validation Authority for funds\n'‘Ouest\nCentralni registar, depo T\nRA000518 Serbia RS Serbia Central Securities Depository and Clearing House | Kiiring hartiia od hitp/Amww.crhov.rs/\nvrednosti\nPypem— St s St Rogister of Invesment Funds PorioTap ApyliTasa 58 ynpasare Seourtios Commission Kowvicija 32 XapTvije Of | NLp: /iS50 gov.r/ndex php/en/public-1egisters-\nVHBECTULIORYM (hOHA0BMMA BpEAHOCTI of-informalion/égister-of-invesiment-funds.\nRA00520 Seychelles Seychelles - Seyohells Financial Services Authorily [ |\"hiip7www.fsaseychelles.so/ 1\nRA0521 Seychelles Seychelles Seychelles Business Regisiry Seychelles Business Registry - I |hitp7www.egov.sc/Business/icensesaspx 1\nRA000995 [Serrateone JSL — [Semateoe 1 [ [BarkofSeraleone Bank of Sierra Leone [ ttp://bankofsierraleone-centralbank.org/ 10 be used as a Validation Authority for funds\nRA000669 Register of Sociefies [ [Regisiryof Socieies | |wwwrosmhagovsg [ ]\nRA000781 Charity Portal Charity Portal Commissioner of Charities Commissioner of https:/www.charities.gov.sg to be used for charities\n\" \" Oifers and Prospectuses Eleclionic o y— =\" \"\nCentrale Bank van - - -\nRAC00855 Sint Maarten sX Sint Maarten Central Bank of Guragao and Sint Maarten Curacao en Sint hitps://www.centralbank.cw/functions/supervision/s {4, ¢ ,c64 a5 a Validation Authority for funds\nuragao upervised-institutions\nRA0670 Trade Register ivnostensky register Ministry of Tnterior Ministerstvo vniira hitp7/www. 2rsr. sk/zr_om.aspx 1\nRA000671 Slovakia SK Slovakia The Statistical Office Statisticky drad hiips:/islovak.stalistics.skwps/portaliext/Databases\nregister_organizacii/\n- - - — - - Nerodr banka Titip /s 1bs. SK/envstalisTonancial- -\nRA000706 Slovakia sK Slovakia Listof Investment Funds Zoznam podielovjch fondov National Bank of Slovakia Narodna b institutionsimoney-market-funds-and-investment- | To be used for investment funds\nfunds/list-of-investment-funds\n8/23\n","contentLength":5233,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T20:59:53.693Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/gleif-registration-authorities-list/2022-03-23_ra_list_v1.7.pdf","content":"\" - p—— - — \"Agency of the Repubiic of Slovenia for Public Legal - p— w—\nRA000529 Slovenia si Slovenia Slovenian Business Register Poslovni register Ageney of the Republc of Slovenia or http/Awww.ajpes si/?language=english\nRA000997 Sloveni i Register of Management Companies f 3 anie i A . - AgencjazaTrg https://www.a-tvp.sileng/lists-of-issued-licences- - .\nvenia sl Slovenia Register of Manageme Register Druzb za Upravianje in Investicijski Skladi | Securities Market Agency Viednosini Papitey (1SS e tobe used as a Validation Authority for funds\niips 77w SolomonbUSINe SSegTSlry gov.Sbicomp\nRA000530 Solomon Islands s8 Solomon Islands Companies Register The Company Haus of Solomon Islands aneshowo-search companiesisearching-for-a-\ncompany\nRA000998 Solomon Islands Solomon Islands. __ Gentral Bank of Solomon Islands Central Bark of https://www.cbsi.com.sb/ to be used as a Validation Authority for funds\nRAO00S3T South Africa South Affica Corporate Registers - ICompaniesandintellectualProperty Commission | wewepoooza [ ]\n- - — \" Financial Sector ; Tobe Used for reguialed financial entifes which are\nWVaster of the Figh\n. . . Court; Department of\nRAC00999 South Africa zA South Africa Administration of Trusts Administration of Trusts Masir of the High gg\\fg}égggfl[\"“em of Justice dustcoand hitps:/icmsweb justioes.gov. za/mastersinformation | to be used to verify information on trusts\nDevelopment\nRAGOTO00 South Africa South Afrca | [Prdental Authorly, Soul Aican Reseve Bank | |\"ips7www resbank o e/ Tobe Used as a Valdalion AUThorly for funds\n- - Winistry of Justice Directorale of Registration of\nRA000532 South Sudan ss South Sudan Business Registry _ B O e O aeg\nRAQ0100T South Sudan South Sudan - o BankofSouh Sudan [ [Piips7wmww.bossgovss/ 10 be used as a Validation Authority for funds\nRA000728 Inventory of Regional Institutions Cercador dlorganismes Government of Catalonia Generaltat de Catalunya 's“jlgi;//sac-gencatca‘/sacgencaVADDJaValofga\"iSf\"e to be used for regional institutes in Catalonia\n- - - Plips 77www.comunidad madrid/serviclos/asocacion\nRAC01003 Spain ES Foundations Registry Registro de Fundaciones de la Comunidad de Community of Madrid Comuridad de Madid [ es-undacionos-colegos prolesionales/agisro- | o be used for foundations i th oy of Madid\nfundaciones-comunidad-madrid\nRegistadoros &\nEspana (Colegio de\n. . ! . . ' ) ; egistradores de la .\nRA000533 Spain Es Spain Commercial Registry Registro Mercantil Registrars of Spain B e s y | WY egistradores.org\nde Bien Muebles de\nEspara)\nComision Nacional deT\nRA000534 Spain Es Spain National Securities Market Commission Verac do Valores [ crmv.cs\n- - - - - - - - pe—— —[lips /www.mjustcia gob es/os/Satelie /Portales/cl\nRA00536 Spain ) Spain Register of Foundations Registro de Fundaciones Ministry of Justice Ministoro de Justoia | FUPS A mjustic gob.esiosiSatelte!\nRAOO0537 Natonal Associalions Register Fegistro Nacional de ASOCRCIones Minisiry for Home ATairs Winsterio del Inerior | ips7/sede mir gob esnfiontalwebasoca bl ||\n- - - - Ministerio o Trabalo,\ni ReciterofCooparave Seites | B 5 BUnGLBEna TRt 507 iy ofLabour, Wiratons & S ety | Mgraions y Seqnidad v empleogobes -\nDireccion General do\nf f Directorate General for Insurances and Pension | Seguros y Fondos de | http:/Awww.dgsfp.mineco.es/en/Paginas/iniciocarrou\nRA000539 Spain ES Spain Funds Pensionce (Mnisterio de | selasp\nEconomia y Empresa)\ns /v ST gob o\nKLBO Belgium BE ommandite par actone French r ommandite par actoms SCSCA 2017-11-30 [INAC e 20181101 and automatically\nansformed into\nlegal form U2PN\nper 1 Nov 2018\nilrechtii ; ilrechili ; slati legal form abolished\n, Zivilrechtiche Gesellschattin der Rechtsform Zivilrechtliche Gesellschattin der Rechtsform legislation 9 ]\nKLBO Belgium BE einer Kommanditgeselischaft auf Akien German einer Kommanditgeselischaft auf Aktien ZRG KGaA 20171130 |INAC change 2018-11-01 and automatically\nlegal form U2PN\nS T I I 2 I O L [ mew v [ [ ]\nT L N I e 2[5 A A S\n- Gifentiich-rechiliche Gesellschaft mit Gifentiich-rechliche Gesellschaft mit 5 y new legal form per\nwhr Belgium o Cotperatieve vennootschap metonbeperkie | puan Cobperalieve vennootschap met onbeperkie | cyon 2171130 |AcTV\naansprakelijkheid aansprakelijkheid\nA T S Y I - e o sooprae & g ee [S0 e v ]\nT Jogm e || [eromomiumsovaneraiung [German oo [ Goressonrat i wesaanertarng Jeonmpn [ Twwrw v [ [ ]\nO T S O e N 120 LA A I\nR T S I I = oo commandie S e | mww ov [ ]\nR T S I I 1 o e [Gorman oo [ Rormanitgesoienat e i ov [ ]\nafter 1 May 2019,\ni egal fom is no\n- nger used for new\nNSNT Belgium BE ;'j:';;f;k;fijflpg?gschap met beperkle Dutch ;'j,?'s‘:}fa“k;,eij’;\",g‘ifischap met beperkle BVBA 20171130 |ACTV 'f,%fi'g锓 20190705 | entities; it still exists\nfor entities\nestablished before\nthat date\nafter 1 May 2019,\nthis legal form is no\nlegislation longer used for new\nNSNT Belgium BE Société privée a responsabilté limitée French r Société privée a responsabilité limitée SPRL 2017-11-80 [ACTV range 20190705 |entities; it still exists\nfor entities\nestablished before\nthat date\n5/83\n","contentLength":4005,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:05:17.008Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-20275-entity-legal-forms-code-list/2021-10-21-elf-code-list-v1.4.1.pdf","content":"NHBK Mesico MX Sociedad anénima de capital variable, fondo | g Sociedad anénima de capital variable, ©ondo |5 A de G. V.. F. 1. de G 202006-10 | ACTV\nde inversion de capitales P de inversion de capitales - A deC. V. F 1 de G\nNI [Wetwo [ || |Uoedsgicommamvedelmer __[Spensh o |Uncedsgieo mousreideamuer___[UAW [ meew v [ ]\n015R Mexico MX Sociedad anonima de capital variable, casa | spanish Sociedad anonima de capital variable, casa 20200610 |ACTV\nde cambio P de cambio\n0230 Mexico MX Sociedad anénima promotora de inversion | oo Sociedad anonima promotora de inversion | g A b1 b 20200610 | ACTV\nbursatil P bursatil AL\nSociedad anénima de capital variable, Sociedad anénima de capital variable,\nP28E Mexico MX sociedad financiera de objeto mitiple, Spanish sociedad financiera de objeto mdlltiple, S.A. de C.V,, SOFOMER. 202006-10 |ACTV\nentidad regulada entidad regulada\nP Mot [ || [Socssdaboumamouchroetames _[speneh o [Sooededenoomembueonaeterss | | Jmweew fow | | | ]\nP8D7 Mexico MX Sociedad annima institucion de banca Spanish Sociedad anénima insitucion de banca 20200610 |ACTV\nmlltiple P: mltiple\nSociedad anénima de capital variable, Sociedad anénima de capital variable,\nQ7wy Mexico MX almacén general de deposito, organizacién | Spanish almacén general de deposito, organizacién 2020-06-10 [ACTV\nauxiliar del crédito auxiliar del crédito\n- Sociedad de produccion rural de - Sociedad de produccion rural de 3\nQAUY Mexico MX -- responsabilidad limitada Spanish _ responsabilidad limitada SPR 20200610 | ACTV\nw7z Mexico MX Sociedad anonima de capital variable, casa | spanish Sociedad anonima de capital variable, casa 20200610 |ACTV\nde bolsa P de bolsa\nzB4 Mexico MX Sociedad anénima bursatil de capital variable, | oo o Sociedad anénima bursatil de capital variable, 20200610 | ACTV change of name | 0201119 change of name of\nbolsa de valores P: bolsa de valores of legal form legal form\nREPY Mexico MX Sociedad anonima de capital variable, bolsa | goanish Sociedad anonima de capital variable, bolsa 20200610 |ACTV\nde valores P de valores.\nRCEO Mexico MX Sociedad anénima de capital variable, fondo | Spanish Sociedad anénima de capital variable, fondo |S. A. de C. V., F. . de R. V. 2020-06-10 |ACTV\nde inversion de renta variable de inversion de renta variable\nRCJS Vexico ™ Corporaciones de caracter publico Spanish Corporaciones de caracter publico 20200610 | ACTV\nreconocidos por la legislacion mexicana P reconocidos por la legislacion mexicana\nRKLL Mexico MX Sociedad anonima, sociedad de informacion | goarich Sociedad anonima, sociedad de informacion 20200610 |ACTV\ncrediticia P crediticia\nSociedad anonima bursatil, sociedad Sociedad anénima bursati, sociedad\nRQDD Mexico MX financiera de objeto multiple, entidad Spanish financiera de objeto multiple, entidad S.AB. SOFOME.R. 202006-10 |ACTV\nregulada regulada\n- Sociedad anénima promotora de inversion - Sociedad annima promotora de inversion 3 Change of name 1 change of name of\nRRASL Mexico MX -- bursatil de capital variable Spanish _ bursatil de capital variable S.AP.1B.de C.V. 20200610 | ACTV oflegal form | 20201119 [0 form\ni Sociedad nacional de crédito institucion de : Sociedad nacional de crédito institucion de .\nSO ewo [ | [ [Swiesamoain [Spansh—Jes [ Socecaamunaie \" mmew pov [ |\nSociedad anonima bursatil de capital variable, Sociedad anénima bursatil de capital variable,\nTTF Mexico MX sociedad financiera de objeto mitiple, Spanish sociedad financiera de objeto mdlltiple, S.AB. DE C.V., SOFOME.NR. 2020-11-19 | ACTV\nentidad no regulada entidad no regulada\n- Sociedad anonima bursatil de capital variable, - Sociedad anénima bursatil de capital variable, 3 Change of name 1 change of name of\nTYWo Mexico MX -- sociedad controladora Spanish _ sociedad controladora 20200610 | ACTV oflegal form | 20201119 [0 form\nP Mexico MX Sociedad anénima de capital variable, Spanish Sociedad anénima de capital variable, 20200610 |ACTV\ninstitucion de fianzas P institucion de fianzas\n- Sociedad anonima de capital variable, fondo - Sociedad anénima de capital variable, fondo 3\nUBVO Mexico MX -- de inversion en instrumentos de deuda Spanish _ de inversion en instrumentos de deuda §.A.deC.V,F.lenlD. 2020-06-10 | ACTV\nVATV Mexico MX Sociedad anonima promotora de inversion de | goarich Sociedad anonima promotora e inversion de | g A p.|. de G.v. 20200610 |ACTV change of name | ,020-11-19 change of name of\ncapital variable P capital variable A Pl de GV of legal form legal form\nvioa IWeico fwx T Jesaw [spansh fes Gt Jee ] [x00060 [ I I B\nVNGF Mexico MX Sociedad cooperativa de productores de Spanish Sociedad cooperativa de productores de 20200610 | ACTV\nbienes y/o servicios P: bienes y/o servicios\nWS [Wewo W | | |Empesspodwiedeiosan [Spa[os [ Emwesa poductue dalsdo I A - I o A I I B\nek [Wosco [ ||| coomobn garedom ocalcoperliade__[Spaieh _[os | Rooooongeredera oo espeealimde | | Jmawoew v | [ | ]\nR N LS I R [Sparn[os [ Socedaduooperatva tace sor | fmwrw fov [ | ]\nT R S I T [Sparn[os [ Sociedaden comardia e foc | fmmeew fow | | | ]\nXLVZ Mexico MX Sociedad de responsabilidad limitada de Spanish Sociedad de responsabilidad fimitada de S deR.LdeC.V 20200610 |ACTV\ncapital variable capital variable - Lde by\nX [Wewo [ || [Socimdubumaimarempolr __[Speneh o [Soommedmntnmamardenpopuler | | Jmweew fow | [ | ]\nYRIO Mesxico MX Fideicomiso publico de fomento econémico | Spanish Fideicomiso publico de fomento economico 202006-10 [ACTV change of name | 2950.11-19 change of name of\nof legal form legal form\nZA1S Mexico MX Sociedad en nombre colectivo de capital Spanish Sociedad en nombre colecivo de capital 20200610 | ACTV\nvariable P variable\nZXVG Mexico MX Sociedad en comandita por acciones de Spanish Sociedad en comandita por acciones de S. on C. por A do C. V. 20200610 |ACTV\ncapital variable P: capital variable - en ©. porA. de ©. V.\nSavo Netrerlands _ |nL besloten vennootschap met beperkie Dutch besloten vennootschap met beperkle BVOVB.Y. by 20171130 | ACTV\naansprakelijkheid aansprakelijkheid DVBV-bv.\nEuropees Economisch Europees Economisch - \"y\nTR e PV T e o |1 |t EeveE S FRETE prey\n41/83\n","contentLength":6090,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:05:17.008Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-20275-entity-legal-forms-code-list/2021-10-21-elf-code-list-v1.4.1.pdf","content":"e (N I B il () GO il i A EICTE S I N\nGO et [ [ | Jommmawswemoonte fous |7 Jommemmemee oveover [ Twmrw pev [\nT L S B o e 23 L A N I S\nT N S Y I . B T 2 20 L A IS I S\nN L S Y B S N L0 210 L A I I SN\nT L S Y B e N . B 23 L A S I B\nS T S Y O . (N . 23 L AN A I B\nL L S O e e L 17230 L AN I I B\ne e W[ | Joweme fowe [T Temewe Temeweey [ Twmrw pev [ T\nR S D . (. 12 L AN A I B\nN L S . (N . 12 L AN A I B\nVo [Weterres [N || [soolms Gooabuomes Jous [ SoomecCovpomBuopes JsESCE [ Twmrw pev [ [\nS T Y O . S (12 L AN A I B\nN L A I I L o 1 (S 23 L A I I B\nN L O L T 23 L A I I B\nT [enzedd | | [Gwwetomy e o ooty Joop [ Tmmrw pev [ [\nN 2 N I B T (e O e R O R I S I O\ne e e I N e (O O (e - A ICTE T I 0 =i\nN N I B ) (N N e R I S I 0\nCE S A I B e O e Y S o I I il\nN N I B el (el L et e e A T S I 0\ne || e o | e | [ Lo | e ]\nR =7 N I B T (N O T R I T I O\nN e I I N e N R O N I S I 0\nA L . O L S L L 12 LA A IS BN\nFo oy N0 | | s feweow o fewew | [ mwmw pev [\nN L . O . S 123 LA I I SN\nN L . O L L L 123 LA A I BN\nE0 oy N0 | | fswoew fWeweow o fswewwx __ Jo [ mwmw pev [\nN L . O L L S L 123 LA A I SN\nESH oy N0 | | |Gensposmowbay [Noweow o |Gomoporsmgeuey | [ mwmw pov [\n@n Ny N0 | | Jooouss fWeweow o ooy fm [ mwmwm pev [ | ]\ne L . . . . 2 LA c 2 2 e\nR L . O . S . 12 LA A I SN\no oy N0 | | iawesm s [Nowomn o | rswlowBwpstaew o [ mwmw pev [\nDR Moy N0 | | |Coumskokoomsk oot [Noweomn oo | Evoporskovemomskomsonppe__JePG [ wwmw pov [\nN L . O . L L S 12 LA A I SN\nFSB Moy N0 | | {Founomymering oo b g [Noregmn oo | Fonghagimmeng @hrbam o | [ wwrw pov [\nT L . O L L L 123 LA A I SN\ne L . O L L S L 12 LA I I S\nT L . O - . S . 12 L1/ I I SN\nN L . O . . S . 12 LA I I SN\nT L . O . L S L 12 LA I I BN\n(OO Moy N0 | | Joowwg fWeweow o feowwwy few [ mww pev [\nT L - O S L e 23 1 AN I I S\nT L O . . L 2 L AN A I S\ne B - L e L 2 L AN I I S\nN O - . S 2 L A A I SN\nT O . . 2 L A A I SN\nN L O . . 12 L AN A I S\nN O L . L2 L A A I S\ne L O e L L 2 L A IS I BN\n[0 [Paisin [P || [Prva Lied Conparytruh mombon) [Evgh_on | Frvae Uit Comparlimerbey [Pt [ Twmrw pev [ |\nT N O B i G GO b o R T S I R\nGEOx[paan [P || [ e ompary gt _[Evoror | Pt it Comparngemenen oo [ wwnw pov [\no0 [rawn [ | | Jowmwdtomay feow o fUnmwedComoay [owelUmes [ mwmw pev [\nN O I B = ] CEE N GO = I CICTE R I I\nN N I B i G O i i e R I S I\nFOF[pan [P | | | oo Compay e [Evohor | Pble Ui Compayoe latatoes [ mwnw pov [\nVove [easan [P | | v oo Compan (e JEvohor | Pblc Ui Compamy G laatmies [ wwrw pov [\npo[pawn [Pk | | iUt ewreaw fEvom or o Labab Py [ULPALLp e bty prrshp e by Py | wew pov [\nT T S O - S S LA S I SN\nA T S D . - 1 I 5 LA A I SN\nG framms fn | | Jwoemsow fsww fw Jowwsow o | fmmew pev | | ]\n42/83\n","contentLength":2655,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:05:17.009Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-20275-entity-legal-forms-code-list/2021-10-21-elf-code-list-v1.4.1.pdf","content":"5% [Pwms [Pn [ | [Soobimadeorponstbiowiliies _[Spwsn oo |Soomamadoovponabndbimtods _[SRL [ Tmweew pov [ [ [\n[PVs7[Famme A || [socmdon Commdlaporacaores [Spansn oo [ Sockendon Comndiperamones | [ Twwoew pov___[ [ [\nT T S Y O e S T L2 = 0 1 AN Y I B\nD T S Y IO - e S S 0 1 AN Y I B\nS e S O L e B e L L . 3 L AN Y I B\nT o D e O ] N I I I\nO A O B e I .8 L I\ne o o T T e e e, [ e e [ [\nR T e I I e e el (N AN EN B\nimitada Limitada\n7088 [P [ [ | [scemiErcomausige [Sww oo [SoomamEnComdisme 6 [ Twwew pov__[ [ [\n7556 [Pamn [PV [ | [EwwUmmww TS o EwewUmesw 0 [ Twweew pov__[ [ [\nL T A I I - S o . S S = 0 1 AN Y I B\nKooV [Farmny [PV || [soclmabe ResrbitedUmias[Spmsn oo [ SoveamaDoReporsbled Ui [SRL__————————————————— [ Twwoew pov___[ [\n[0 [Faryy [PV || [SoclndE Commdn Por Acoores[Spansn oo [ SockandEn CommndinPorAiores__[SGA [ Twwoew ov [ [ [\n[Wioe—[Few [P || [socaden CommiaporAcoones _[Spansn oo [ Sockendon GomdiprAcsores [Senporn [ Twwoew ov [ [ [\n76 [Pew [P || [Socndvor Accres Corade Spliade [Spansn oo [ Socemdpor Aodores Comada St [SAGS [ Twwoew ov [ [ [\nv [ [ | [soemioowe [Sww o [oodclma 6 [ Twweew pov__[ [ [\n[AoC[rew [ [ | [Emewdtwworbo [Sww o Emesmsdbosoorlbio [ [ Twweew pov__[ [ [\nB [rew [FE [ | [sockmaGuice Fosporabihaimiats [Spansn oo [ Sookanamt doRemporsaied Ui [SGWIGeRT [ Twwoew ov___[ [ [\nN N O I i B N e O A o A N\nimitada Limitada\nT N S O O L S o L S = 0 1 AN Y I B\nR I S I I o e e e S 0 L AN Y I B\ne e e I I e e e e L i (T AN H I\ns row e [ | [wemmgom fmew Je [Seelmana __ fsx | Jmwoew few__[ | | ]\nP rou e [ | oo fsmmehn Jeo fowpmwe | | Jamwoew oW _[ | | ]\nPR Pou e [ | [Sweamtombem [smeh Jeo [Soocdembmmemen ___ fow | Jmmwoew few__[ | | ]\n[ooWe Pow e [ | [Swemsow ____ Jsmmeh _Jeo [seemsow ______ fsow | Jamwoew few__[ | | ]\nP rou e [ | [SwemdonconaimSme [Spmeh Jes [SoomssdenCommdmSme _fserc | Jamoew few__[ | | ]\nWee Pou [P [ | [Swemdegw _ [spmeh Jeo [Sooesedwd | | Jmmwoew few__[ | | ]\n[FoEpmippres PR || [romsbokcopmaior __Jegin __Jer Jromskooporon || Jsroem ow__[ | | ]\nObMPippies PR || [cducatondcopomior____[Evain e Jodwtomiooporton | | Jsroem pow__[ | | ]\nkoW pippres PR || [oomroooporsion __JEvain__Jer _Jorepermempomion oo | Jsroem fpow__[ | | ]\n[S% pmigres PR || [dosoooporn e Jer Joemcopomon | | Jmsreem ow_[ | | ]\n[WHGH [Pippies PR || [sockooportn __Jeaien __Jer sedempomon e | Jmsreem low_[ | | ]\nS (TN I A T = . Y - L A Y I I\nS I N i S = AN AN ) S e =l\nchange name of\nS N e o ) S ) il\nI (L 2SI N 17 e e O e N -2 . A Y I I\nN O N e S e I I ) U I A\n60BG Poland PL kontroli panstwowej i ochrony prawa oraz Polish kontroli paristwowej i ochrony prawa oraz 2017-1130 |ACTV\nsady i trybunaly sady i trybunaly\nchange name of\nS S N R o ) B ) o =il\nR R N I I i O s I i N AN E\nreasekuracji reasekuracji\nchange name of\nN S S S S = N I ) o e =il\n[ N (N I I 7 S O 7 e E - T I N R\nchange name of\nS S S S A A ) o e =il\nchange name of\ne N N e A I ) o ) il\ne N S I e e S N 230 . AN S I B\nnew legal form in\ni N N o N o N I ey N I I =\nchange name of\ne e oS e S A ) o e il\nT R S I L e 2 e N 230 . AN Y I B\nchange name of\nS O e o O e I I Sy [ o) ol il\nN N S O - . (2. L 1230 1 AN I I B\nL R S I . 2 .. 230 L AN I I B\nchange name of\nS N R N S I Sy O o) ol il\nR R S I IO T 2 e N W 230 ., AN N I B\n43/83\n","contentLength":3223,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:05:17.009Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-20275-entity-legal-forms-code-list/2021-10-21-elf-code-list-v1.4.1.pdf","content":"change name of\nGZE5 Poland PL wspélnota mieszkaniowa Polish wspélnota mieszkaniowa 2017-11-30 | ACTV textcorrected | 2020-06-10 legal {orm to\nsingular\no J— o J— change name of\ne e I B e O s A N i e e\nsingular\nT R 2 Y N [T I I T T e ew [ T ]\nL I I [ S e A N 1211 . A I S I\nN R S N N [T Poh o Johubecwese Y 1212 A I I I\nchange name of\nLToU Poland PL Zwigzek zawodowy Polish Zwigzek zawodowy 20171130 | ACTV textcorrected | 2020-06-10 legalform to\nsingular\nchange name of\n07x8 Poland PL spolka z ograniczong odpowiedzialnoscia | Polish spolka z ograniczong odpowiedzialnoscia 20171130 | ACTV textcorrected | 2020-06-10 legalform to\nsingular\nchange name of\nOMX0 Poland PL spolka komandytowo-akeyjna Polish spolka komandytowo-akcyjna SKA. 2017-11-30 |ACTV textcorrected [2020-06-10 legalform to\nsingular\nST oland oL glowny oddziat zagranicznego zakladu olich glowny oddziat zagranicznego zakladu 20171130 |AcTV\nUbezpieczen Ubezpieczen\nChang%e name of\nQuxi Poland PL otwarty fundusz emerytalny Polish otwarty fundusz emerytalny OFE 2017-11-30 |ACTV textcorrected [2020-06-10 legal form to\nsingular\no Jres L[| [mecowsenoay I I [ T ) -2 [ A I I I\nChang%e name of\nRBHP Poland PL fundusz inwestycyjny Polish fundusz inwestycyjny 20171130 | ACTV textcorrected | 2020-06-10 legal form to\nsingular\nchange name of\nSMIS Poland PL przedsigbiorstwo paristwowe Polish przedsigbiorstwo paristwowe 20171130 | ACTV textcorrected | 2020-06-10 legalform to\nsingular\nchange name of\nSP4s Poland PL kosciot i zwigzki wyznaniowe Polish kosciot i zwigzki wyznaniowe 2017-11-30 | ACTV textcorrected | 2020-06-10 legal {orm to\nsingular\nSVA3 Poland PL fundusze inne niz inwestycyjne iinne niz Polish fundusze inne niz inwestycyjne i inne niz 2017-11-30 |ACTV\notwarte fundusze emerytalne otwarte fundusze emerytalne\nTree [romd L[ [ [wrio sanomaiowe [Fois [ [vertinoy samorzaione ) -2 [ A Y I I\nChang%e name of\nWNX1 Poland PL towarzystwo ubezpieczeri wzajemnych Polish towarzystwo ubezpieczeri wzajemnych TUW 2017-11-30 | ACTV textcorrected | 2020-06-10 legal form to\nsingular\nA 2 S 2 O I L e I L N A 21200 - A Y I B\nChang%e name of\nwuJ2 Poland PL Polish 20171180 [ACTV textcorrected [2020-06-10 |legalform to\nsingular\nChang%e name of\nyLzL Poland PL spotka cywilna Polish spotka cywilna sc. 20171130 | ACTV textcorrected | 2020-06-10 legal form to\nsingular\n2V Poland L osoby fizyczne prowadzace dzialainose Polish osoby fizyczne prowadzace dzialalnose 20171130 |ACTV\ngospodarcza gospodarcza\nchange name of\nZZKE Poland PL stowarzyszenie i zwiazki stowarzyszer Polish stowarzyszenie i zwiazki stowarzyszer 20171130 | ACTV textcorrected | 2020-06-10 legalform to\nsingular\n9900 ortugal = Agrupamento Europeu de Interesse Portuguese N Agrupamento Europeu de Interesse AEE 20171130 |AcTV abbreviation | 2021-0925 addition of\n9 Economico 9 P Econbmico added abbreviation\nPogd[PT || [erudade rua v Eniade P Emprara ) -2 [ A I A I\nI T o 1 S (S 3 S 1210 LA A I\ny . : y L : abbreviation addition of\nPt [ | [somammomomm SooRiads om Nome Coetvo ) A -2 [ A I I I\nWov_JPorgal __[PT || [Eriado Erpocaral eiopolia Enidade Emposaraiowopotana | [ Jowrw v [ [ T ]\noXUs_JPorgal [T || [Soomdadoon conanaa Socedads om Conandia ) A -2 [ A Y A I\nFouga [P || [rewm cobmmdoommruie Y A 122 [ AN I I I\nI N A A I [ Enpross Woricpa ) A -2 [ A Y A I\nGP©_JPorgal _[PT ||| Fovooa o ioragom Possoa Coleva oragorsl ) A -2 [ A Y A I\nU508 Jrorgal [P || Sooedadoporcuwoes Socedads por Qolas ) -2 [ A Y I I\nVo Jrorgal [T || [Soomlas Conpmraa Evon Sociels Gonperatva Evopeee [ A - [ A I I I\nVereJPorgal _[PT || [Soomdade Unpessalpor ouoie S A 122 [ A I A I\nWows[Poruga [P || [Sooodado Avtrima besporivs Socdads Arrima Bosportva ) -2 [ A Y I I\nXoteJrorgal __[PT || [Enposs oropoamm Enprosa Vopotara ) -2 [ A Y I I\nthis legal form was\ndouble entry of on the list twice,\nXMXM Portugal PT Fundo Portuguese |pt Fundo 20171130 |INAC legal form 2019-07-05 also as ELF Code\nremoved 6L6P; and XMXM is\nless used than 6L6P\nW5 Jrog [P || [oumer Corploreria doEmmess Rgpamerto Comperr o mprosss || Jwonw v [ | ]\n44583\n","contentLength":4038,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:05:17.009Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-20275-entity-legal-forms-code-list/2021-10-21-elf-code-list-v1.4.1.pdf","content":"Estabelecimento Individual de Estabelecimento Individual de\nT powg [T [ | [Enesneoom Enprosa Rogora I Fwmw ov___ ]\ncorrection correction of\nIKBN Portugal PT Madeira PT-30 Trust Portuguese pt Trust 20171130 |ACTV country . 2019-07-05 country subdivision\nsubdivision P\ncode\ncorrection correction of\n272X Portugal PT Madeira PT-30 Sucursal Financeira Exterior Portuguese pt Sucursal Financeira Exterior 2017-11-30 |ACTV gflggi\\?{sb n 2019-07-05 country subdivision\ncode code\nall existing ELF\nSodes for Puerto\nELF code Rico replaced with\n1941 Puerto Rico Professional Corporation English Professional Corporation 2020.06-10 | INAC inactivated and |5050.11.1g [ new codes o solve\nreplaced by new situation with\ncode incorrect pairing of\nthe same legal form\nin 2 languages\nall existing ELF\ncodes for Puerto\nELF code Rico replaced with\n1941 Puerto Rico Corporacion Especial para el Desarrollo Spanish Corporacion Especial para el Desarrollo 20200610 | INAC inactivated and [ 000.11-19 new codes to solve\nMunicipal P Municipal replaced by new situation with\ncode inconect pairing of\nthe same legal form\nin 2 languages\nall existing ELF\nSodes for Puerto\nnew ELF code Rico replaced with\n1TG4 Puerto Rico Low Profit LLC English Low Profit LLC 2020-11-19 |ACTV to replace ’f‘” 50 es.n? solve\ninactivated code situation with.\ninconect pairing of\nthe same legal form\nin 2 languages\nall existing ELF\nSodes for Puerto\no [ o A new ELF code Rico replaced with\n1Tes Puerto Rico Compaiia de Responsabilidad Limitada con | goanish Compafiia de Responsabilidad Limitada con 2020-11-19 | ACTV 1o repiace new codes to solve\nFin Social Fin Social ! situation with\ninactivated code s h.\nincorrect pairing of\nthe same legal form\nin 2 languages\nall existing ELF\ncodes for Puerto\nnew ELF code Rico replaced with\n35RF Puerto Rico Limited Liability Company English Limited Liability Company 2020-11-19 | ACTV o replace new codes to solve\ninactivated code situation with.\ninconect pairing of\nthe same legal form\nin 2 languages\nall existing ELF\nSodes for Puerto\nnew ELF code Rico replaced with\n35RF Puerto Rico Compariia de Responsabilidad Limitada Spanish Compafiia de Responsabilidad Limitada 2020-11-19 | ACTV to replace ’f‘” 50 es.n? solve\ninactivated code situation with.\nincorrect pairing of\nthe same legal form\nin 2 languages\nall existing ELF\ncodes for Puerto\nELF code Rico replaced with\ni imited Liabili i imited Liabili . inactivated and 11 new codes to solve\n3QX8 Puerto Rico Limited Liability Company English Limited Liability Company 202006-10 | INAC oo ata By o | 2020-11-19 new codes to\ncode inconect pairing of\nthe same legal form\nin 2 languages\nall existing ELF\nSodes for Puerto\nElFoode Rico replaced with\n;. \" \" . \" \" inactivated al new codes to solve\n3QX8 Puerto Rico Cooperative de Juvenil Spanish Cooperative de Juvenil 2020-06-10 INAC replaced by new 2020-11-19 situation with\ncode incorrect pairing of\nthe same legal form\nin 2 languages\nall existing ELF\ncodes for Puerto\nELF code Rico replaced with\n4xvo Puerto Rico Trust English Trust 2020.06-10 | INAC inactivated and |5050.11.1g [ new codes o solve\nreplaced by new situation with\ncode incorrect pairing of\nthe same legal form\nin 2 languages\nall existing ELF\ncodes for Puerto\nELF code Rico replaced with\n4XY9 Puerto Rico Entidad Financiera Internacional Spanish Entidad Financiera Internacional 20200610 | INAC inactivated and [ 000.11-19 new codes to solve\n(Corporacion) P (Corporacion) replaced by new situation with\ncode inconect pairing of\nthe same legal form\nin 2 languages\nall existing ELF\nSodes for Puerto\nELF code Rico replaced with\n6DE6 Puerto Rico Close Corporation English Close Corporation 2020.06-10 | INAC inactivated and |5050.11.1g [ new codes o solve\nreplaced by new situation with\ncode incorrect pairing of\nthe same legal form\nin 2 languages\nall existing ELF\ncodes for Puerto\nELF code Rico replaced with\n6DE6 Puerto Rico Centro Bancario Internacional (Corporacion) | Spanish Centro Bancario Internacional (Corporacion) 20200610 [INAC inactivated and 15020.11.19 ~ |new codes to solve\nreplaced by new situation with\ncode inconect pairing of\nthe same legal form\nin 2 languages\n45/83\n","contentLength":4140,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:05:17.009Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-20275-entity-legal-forms-code-list/2021-10-21-elf-code-list-v1.4.1.pdf","content":"all existing ELF\ncodes for Puerto\nELF code Rico replaced with\n! \" \" i \" \" . inactivated and 11 new codes to solve\n70Al Puerto Rico Special Employee Owned Corporation English Special Employee Owned Corporation 20200610 | INAC el an [2020-11-19 [new codes to\ncode incorrec pairng of\nthe same legal form\nin 2 languages\nall existing ELF\nGodes for Puerto\nELF code Rico replaced with\n70l Puerto Rico Empressa Municipal Spanish Empressa Municipal 20200610 |INAC inactivated and |5050.11.1g [ new codes o solve\nreplaced by new situation with\ncode incorrect pairing of\nthe same legal form\nin 2 languages\nall existing ELF\ncodes for Puerto\nELF code Rico replaced with\n81vI Puerto Rico International Financial Entity (LLC) English Intemational Financial Entity (LLC) 20200610 [INAC inactivated and 15020.11.19 ~ |new codes to solve\nreplaced by new situation with\ncode incorrec pairng of\nthe same legal form\nin 2 languages\nall existing ELF\nGodes for Puerto\nELF code Rico replaced with\n81vI Puerto Rico Cooperative de Trabajadores Spanish Cooperative de Trabajadores 20200610 |INAC inactivated and |5050.11.1g [ new codes o solve\nreplaced by new situation with\ncode incorrect pairing of\nthe same legal form\nin 2 languages\nall existing ELF\ncodes for Puerto\nnew ELF code Rico replaced wilh\nto replace “.‘i‘” :,:o es.n? solve\n87N3 Puerto Rico Cooperativa de Consumo Spanish Cooperativa de Consumo 2020-11-19 | ACTV inactivated stuationwith\ncode: typo incomect pairing of\ne e the same legal form\nin 2 languages; for\nthis legal form also\ntypo corrected\nall existing ELF\ncodes for Puerto\nnew ELF code Rico eplaced il\n87N3 Puerto Rico Consumer Cooperative English Consumer Cooperative 2020-11-19 | ACTV o replace new codes to solve\np i situation with\ninactivated code : h\nincorrec pairng of\nthe same legal form\nin 2 languages\nI e R A S ) T O ) | Tmwwo o [ ]\no Jrwrorm R || [ewoow [Soonsh—Jes[eawo o0 | Tmwwwo ov | ]\nall existing ELF\nGodes for Puerto\nELF code Rico replaced with\n! ! _ ! _ ! ) ! inactivated and new codes to solve\nA4MM Puerto Rico International Banking Center (Corporation) | English Intemational Banking Center (Corporation) 20200610 | INAC replaced by new [2020-11-19 | situation with\ncode incorrect pairing of\nthe same legal form\nin 2 languages\nall existing ELF\ncodes for Puerto\nELF code Rico replaced with\n! i ! i . inactivated and 11 new codes to solve\nA4MM Puerto Rico Compania de Seguros Spanish Compania de Seguros 2020-06-10 INAC replaced by new 2020-11-19 situation with\ncode incorrec pairng of\nthe same legal form\nin 2 languages\nall existing ELF\nGodes for Puerto\nElFoods Rico replaced wilh\n. . . : . N inactivated al new codes to solve\nBQ6L Puerto Rico Sponsored By Municipal Corporation English Sponsored By Municipal Corporation 20200610 | INAC e o [2020-11-19 [ o Bodee o\ncode incorrect pairing of\nthe same legal form\nin 2 languages\nall existing ELF\ncodes for Puerto\nELF code Rico replaced with\nBQ6L Puerto Rico Entidad Financiera Internacional (CRL) Spanish Entidad Financiera Internacional (CRL) 20200610 |INAC inactivated and |5050.11.1g [ new codes o solve\nreplaced by new situation with\ncode incorrect pairing of\nthe same legal form\nin 2 languages\nall existing ELF\ncodes for Puerto\nELF code Rico replaced with\nCco07 Puerto Rico Youth Cooperative English Youth Cooperative 20200610 [ INAC inactivated and 15020.11.19 ~ |new codes to solve\nreplaced by new situation with\ncode incorrec pairng of\nthe same legal form\nin 2 languages\nall existing ELF\nGodes for Puerto\nELF code Rico replaced with\nc907 Puerto Rico Sociedad de Responsabilidad Limitada Spanish Sociedad de Responsabilidad Limitada 202006-10 | INAC inactivated and 15450.11.19 new codes to solve\nreplaced by new situation with\ncode incorrect pairing of\nthe same legal form\nin 2 languages\nall existing ELF\ncodes for Puerto\nELF code Rico replaced with\nD5L6 Puerto Rico Consumer Cooperative English Consumer Cooperative 20200610 [ INAC inactivated and 15020.11.19 ~ |new codes to solve\nreplaced by new situation with\ncode incorrec pairng of\nthe same legal form\nin 2 languages\n46/83\n","contentLength":4049,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:05:17.009Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-20275-entity-legal-forms-code-list/2021-10-21-elf-code-list-v1.4.1.pdf","content":"all existing ELF\ncodes for Puerto\nELF code Rico replaced with\nD5L6 Puerto Rico Centro Bancario Internacional (CRL) Spanish Centro Bancario Internacional (CRL) 20200610 [INAC inactivated and 15020.11.19 ~ |new codes to solve\nreplaced by new situation with\ncode inconect pairing of\nthe same legal form\nin 2 languages\nall existing ELF\ncodes| for:gPuerlq\nnew ELF code Rico replaced with\nD8xQ Puerto Rico Municipal Enterprise English Municipal Enterprise 2020-11-19 | ACTV to replace ’f‘” 50 es.n? solve\ninactivated code situation with.\nincorrect pairing of\nthe same legal form\nin 2 languages\nall existing ELF\ncodes for Puerto\nnew ELF code Rico replaced with\nD8XQ Puerto Rico Empressa Municipal Spanish Empressa Municipal 2020-11-19 |ACTV to replace oot Sove\ninactivated code situation with,\ninconect pairing of\nthe same legal form\nin 2 languages\nall existing ELF\ncodes| for:gPuerlq\nnew ELF code Rico replaced with\nDE7H Puerto Rico Professional Corporation English Professional Corporation 2020-11-19 |ACTV to replace ’f‘” 50 es.n? solve\ninactivated code situation with.\nincorrect pairing of\nthe same legal form\nin 2 languages\nall existing ELF\ncodes for Puerto\nnew ELF code Rico replaced with\nDE7H Puerto Rico Corporacién Professional Spanish Corporacién Professional 2020-11-19 | ACTV to replace ’f‘” 50 es.n? solve\ninactivated code situation with.\nincorrect pairing of\nthe same legal form\nin 2 languages\nall existing ELF\ncodes for Puerto\nELF code Rico replaced with\nE85L Puerto Rico Limited Liability Partnership English Limited Liability Partnership 20200610 | INAC inactivated and | 5450.11.19 new codes to solve\nreplaced by new situation with\ncode inconect pairing of\nthe same legal form\nin 2 languages\nall existing ELF\nSodes for Puerto\nELF code Rico replaced with\nE85L Puerto Rico Corporacion Spanish Corporacion 20200610 |INAC inactivated and |5050.11.1g [ new codes o solve\nreplaced by new situation with\ncode incorrect pairing of\nthe same legal form\nin 2 languages\nall existing ELF\ncodes for Puerto\nnew ELF code Rico replaced with\nEQQP Puerto Rico Special Employee Owned Corporation English Special Employee Owned Corporation 2020-11-19 | ACTV to replace new codes to solve\nh o situation with\ninactivated code inconect pairng of\nthe same legal form\nin 2 languages\nall existing ELF\nSodes for Puerto\nRico replaced with\n» . ’ - . ’ ELF code P\n! Corporacion Especial Propiedad de ' Corporacion Especial Propiedad de e new codes to solve\nEQQP Puerto Rico Trabajadores Spanish Trabajadores 2020-11-19 [ACTV to replace s\ninactivated code incorrect pairing of\nthe same legal form\nin 2 languages\nall existing ELF\nSodes for Puerto\nELF code Rico replaced with\nERUM Puerto Rico Public Benefit Corporation English Public Benefit Corporation 202006-10 | INAC inactivated and 15450.11.19 new codes to solve\nreplaced by new situation with\ncode incorrect pairing of\nthe same legal form\nin 2 languages\nall existing ELF\nSodes for Puerto\nELF code Rico replaced with\nERUM Puerto Rico Corporacion Especial Propiedad de Spanish Corporacion Especial Propiedad de 20200610 | INAC inactivated and | 5000.11-19 new codes to solve\nTrabajadores Trabajadores replaced by new situation with\ncode incorrect pairing of\nthe same legal form\nin 2 languages\nall existing ELF\ncodes for Puerto\nnew ELF code Rico replaced with\nGCP3 Puerto Rico International Financial Entity (LLC) English Intemational Financial Entity (LLC) 2020-11-19 | ACTV to replace new codes to solve\ninactivated code situation with,\ninconect pairing of\nthe same legal form\nin 2 languages\nall existing ELF\ncodes| for:gPuerlq\nnew ELF code Rico replaced with\nGCP3 Puerto Rico Entidad Financiera Internacional (CRL) Spanish Entidad Financiera Internacional (CRL) 2020-11-19 | ACTV to replace ’f‘” 50 es.n? solve\ninactivated code situation with.\nincorrect pairing of\nthe same legal form\nin 2 languages\nlanguage labels\nlanguage label were swiched\nGL33 Puerto Rico Centro Bancario Internacional (Corporacion) | Spanish Centro Bancario Internacional (Corporacion) 2020-11-19 | ACTV podinr:] 2021-09-23 between the 2\nlanguages for this\nlegal form\n47/83\n","contentLength":4084,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:05:17.009Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-20275-entity-legal-forms-code-list/2021-10-21-elf-code-list-v1.4.1.pdf","content":"language labels\noLss o ! ' ) ! i ! ) ! language label were swiched\nuerto Rico International Banking Center (Corporation) | English Intemational Banking Center (Corporation) 2020-11-19 |ACTV cormatod 2021-09-23 between the 2\nlanguages for this\nlegal form\nall existing ELF\ncodes for Puerto\nnew ELF code Rico replaced with\nGRH5 Puerto Rico Workers Cooperative English Workers Cooperative 2020-11-19 | ACTV to replace new codes to solve\nh o situation with\ninactivated code : h,\ninconect pairing of\nthe same legal form\nin 2 languages\nall existing ELF\nSodes for Puerto\nnew ELF code Rico replaced with\nto replace new codes fo solve\nGRH5 Puerto Rico Cooperativa de Trabajadores Spanish Cooperativa de Trabajadores 2020-11-19 | ACTV inactivated suationwith,\ncode: typo nconect pairng o\nposnci the same legal form\nin 2 languages; for\nthis legal form also\ntypo corrected\nall existing ELF\ncodes for Puerto\nELF code Rico replaced with\n1wa Puerto Rico Municipal Enterprise English Municipal Enterprise 2020-06-10 | INAC inactivated and |2020.11.19 new codes to solve\nreplaced by new situation with\ncode inconect pairing of\nthe same legal form\nin 2 languages\nall existing ELF\nSodes for Puerto\nELF code Rico replaced with\ni 6 icio Soci i \" idio Sodi . inactivated and 11 new codes to solve\ne Puerto Rico Corporacion de Beneficio Social Spanish Corporacién de Beneficio Social 202006-10 | INAC oo ata By o | 2020-11-19 new codes to\ncode inconect pairing of\nthe same legal form\nin 2 languages\nall existing ELF\nSodes for Puerto\nnew ELF code Rico replaced with\n16FV Puerto Rico Savings & Credit Cooperative English Savings & Credit Cooperative 2020-11-19 | ACTV to replace ’f‘” 50 es.n? solve\ninactivated code situation with.\nincorrect pairing of\nthe same legal form\nin 2 languages\nall existing ELF\ncodes for Puerto\nnew ELF code Rico replaced with\n1o replace new codes 10 solve\n16FV Puerto Rico Cooperativa de Ahorro y Crédito Spanish Cooperativa de Ahorro y Crédito 2020-11-19 [ACTV inactivated .5\"“3“0“[‘”\". g of\nCode: typo incorrect pairing o\nthis legal form also\ntypo corrected\nall existing ELF\nSodes for Puerto\nELF code Rico replaced with\nINDH Puerto Rico Corporation English Corporation 2020.06-10 | INAC inactivated and |5050.11.1g [ new codes o solve\nreplaced by new situation with\ncode incorrect pairing of\nthe same legal form\nin 2 languages\nall existing ELF\ncodes for Puerto\nELF code Rico replaced with\nINDH Puerto Rico Compatiia de Responsabilidad Limitada Spanish Compafiia de Responsabilidad Limitada 20200610 | INAC inactivated and | 5450.11.19 new codes to solve\nreplaced by new situation with\ncode inconect pairing of\nthe same legal form\nin 2 languages\nall existing ELF\nSodes for Puerto\nrew ELF code Rl spacedyt,\nAV Puerto Rico Trust English Trust 2020-11-19 | ACTV to replace situation with\ninactivated code incorrect pairing of\nthe same legal form\nin 2 languages\nall existing ELF\ncodes for Puerto\nnew ELF code Rico replaced with\nJav Puerto Rico Fideicomiso Spanish Fideicomiso 2020-11-19 |ACTV to replace oot Sove\ninactivated code situation with,\ninconect pairing of\nthe same legal form\nin 2 languages\nall existing ELF\nSodes for Puerto\nnew ELF code Rico replaced with\nME4Y Puerto Rico Public Benefit Corporation English Public Benefit Corporation 2020-11-19 |ACTV to replace ’f‘” 50 es.n? solve\ninactivated code situation with.\nincorrect pairing of\nthe same legal form\nin 2 languages\nall existing ELF\ncodes for Puerto\nnew ELF code Rico replaced with\nME4Y Puerto Rico Corporacion de Beneficio Social Spanish Corporacién de Beneficio Social 2020-11-19 | ACTV to replace new codes lo solve\ninactivated code situation with,\ninconect pairing of\nthe same legal form\nin 2 languages\n48/83\n","contentLength":3683,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:05:17.010Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-20275-entity-legal-forms-code-list/2021-10-21-elf-code-list-v1.4.1.pdf","content":"all existing ELF\ncodes for Puerto\nnew ELF code Rico replaced with\n02JM Puerto Rico Youth Cooperative English Youth Cooperative 2020-11-19 | ACTV to replace new codes lo solve\ninactivated code inconect pairng of\nthe same legal form\nin 2 languages\nall existing ELF\nSodes for Puerto\nnew ELF code Rico replaced with\n1o repiace new codes to solve\n02JM Puerto Rico Cooperativa de Juvenil Spanish Cooperativa de Juvenil 2020-11-19 |ACTV inactivated situation with. ”\ncode; typo incorrect pairing of\nposnci the same legal form\nin 2 languages; for\nthis legal form also\ntypo corrected\nall existing ELF\ncodes for Puerto\nnew ELF code Rico replaced with\n040G Puerto Rico Limited Liability Partnership English Limited Liability Partnership 20204119 |ACTV to replace new codes to solve\ninactivated code situation with.\ninconect pairing of\nthe same legal form\nin 2 languages\nall existing ELF\nSodes for Puerto\nnew ELF code Rico replaced with\n040G Puerto Rico Sociedad de Responsabilidad Limitada Spanish Sociedad de Responsabilidad Limitada 2020-11-19 |ACTV to replace new codes to solve\ninactivated code situation with.\nincorrect pairing of\nthe same legal form\nin 2 languages\no [Pwtomeo [PR || [commomasn B Jon [Commersattanc I mes pow [ [ ]\nall existing ELF\nSodes for Puerto\nnew ELF code Rico replaced with\nRASB Puerto Rico International Banking Center (LLC) English Intemnational Banking Center (LLC) 20204119 |ACTV to replace new codes to solve\ninactivated code situation with.\nincorrect pairing of\nthe same legal form\nin 2 languages\nall existing ELF\ncodes for Puerto\nnew ELF code Rico replaced with\nRASB Puerto Rico Centro Bancario Internacional (CRL) Spanish Centro Bancario Internacional (CRL) 20204119 |ACTV to replace new codes to solve\ninactivated code situation with.\ninconect pairing of\nthe same legal form\nin 2 languages\nall existing ELF\nSodes for Puerto\nElFoode Rico replaced with\ni iy i i inactivated al new codes to solve\nsoQ1 Puerto Rico Workers Cooperative English Workers Cooperative 2020-06-10 INAC replaced by new 2020-11-19 situation with\ncode incorrect pairing of\nthe same legal form\nin 2 languages\nall existing ELF\ncodes for Puerto\nELF code Rico replaced with\ni deicomi i ideicomi . inactivated and 11 new codes to solve\nsoQ1 Puerto Rico Fideicomiso Spanish Fideicomiso 2020-06-10 INAC replaced by new 2020-11-19 situation with\ncode inconect pairing of\nthe same legal form\nin 2 languages\nall existing ELF\nSodes for Puerto\nElFoode Rico replaced with\ni i inactivated al new codes to solve\nSQXC Puerto Rico Insurance Company English Insurance Company 202006-10 | INAC ropiated by new |2020-11-19 new codes io\ncode incorrect pairing of\nthe same legal form\nin 2 languages\nall existing ELF\ncodes for Puerto\nELF code Rico replaced with\nsaxc Puerto Rico Compaiia de Responsabilidad Limitada con | goanish Compafiia de Responsabilidad Limitada con 20200610 | INAC inactivated and | 5000.11-19 new codes to solve\nFin Social Fin Social replaced by new situation with\ncode incorrect pairing of\nthe same legal form\nin 2 languages\nall existing ELF\ncodes for Puerto\nnew ELF code Rico replaced with\nT2Us Puerto Rico Close Corporation English Close Corporation 2020-11-19 | ACTV loreplace new codes lo solve\ninconect pairing of\nthe same legal form\nin 2 languages\nall existing ELF\ncodes for Puerto\nnew ELF code Rico replaced with\nT2JS Puerto Rico Corporacién Intima Spanish Corporacion Intima 2020-11-19 | ACTV to replace new codes lo solve\ninactivated code inconect pairng of\nthe same legal form\nin 2 languages\nall existing ELF\nSodes for Puerto\nRico replaced with\nTEGY Puerto Rico Special Corporation for Muricipal Endlish Special Corporation for Municipal 20201119 | ATV new ELF code new codes to solve\nDevelopment 9 Development o repIace | code situation with\nincorrect pairing of\nthe same legal form\nin 2 languages\n49/83\n","contentLength":3816,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:05:17.010Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-20275-entity-legal-forms-code-list/2021-10-21-elf-code-list-v1.4.1.pdf","content":"TEGV Puerto Rico i6\nCorporacion Especial para el Desarroll\nMunicipal ° Spanish Corporacién Especi all existing ELF\np: Murfl(c)ipal special para el Desarrollo e %q des f°|r buerto\nnew code ico replaced with\n2020-11-19 |ACTV to replace new codes to solve\nTR reeme e [ [ Jenc EEC. et ooty\n: - e e o\ne e I B L e C— e ] P o\np—— [Sparion [os [Banco Gomporaciany [ [000610 [acTv I Lo\nI N A L _—\nuLeC Puerto Rico\nSavings & Credit Cooperative i ! st\npe English Savings & Credit Cooperative ELF code o\nELFC Rico replaced with\n2020-06-10 | INAC inactivated and\n2020-1119 new codes to solve\n{;lé':ced by new situation with\nincorrect pairing of\nthe same legal form\nuLeC Puerto Rico o in 2 languages\nrporacion Intima Spanish I all existing ELF\nP Corporacion Intima ELF code %qdes for Puerto\nB : ico replaced with\n2020-06-10 | INAC inactivated and\n2020-11-19 new codes to solve\nZlélgced by new situation with\nincorrect pairing of\nthe same: Togalform\nVKSV Puerto Rico \\ D\nnsurance Company Enich all existing ELF\ng Insurance Company - g‘Odes for Puerto\nnew ELF code ico replaced with\n2020-11-19 | ACTV to replace new codes to solve\ninactivated code situation with\nincorrect pairing of\nthe same legal form\nVKsV Puerto Rico o in 2 languages\nmpaiiia de Seguros . st\ng Spanish Compaiiia de Seguros g‘ljlde::'t‘l‘?gpilér“’\nnew ELF code Rico replaced with\n2020-11-19 | ACTV to replace new codes to solve\ninactivated code situation with\nincorrect pairing of\nthe same legal form\nWeNI Puerto Rico \\ e\ninternational Financial Entity (Corporation) | Engli et\n\" o all existing ELF\ng Intemational Financial Entity (Corporation) L godes for Puerto\nnew code ico replaced with\n2020-11-19 |ACTV to replace new codes to solve\ninactivated code situation with\ninconect pairing of\nthe same legalTorm\nWENI Puerto Rico Enti A in 2 languages\nntidad Financiera Internacional isti\n(Corporacion) ne Spanish Entidad Financiera Internacional all e>\nT922 Belgium BE commandite simple French fr commandite simple SCSCs 2017-11-30 INAC change 2018-11-01 znd automat[(;ally\nansformed into\nlegal form LWV6\nper 1 Nov 2018\nvilrechti ; vilrechti ; slati legal form abolished\n. Zivilrechtiiche Gessllschaftin der Rechtsform Ziviltechtiche Gessllschaftin der Rechtsform legislation o >\nTo22 Belgium BE einer einfachen Kommanditgesellschaft German einer einfachen Kommanditgesellschaft ZRGEKG 20171130 |INAC change 2018-11-01 and automatically\nlegal form LWV6\nper 1 Nov 2018\n\" \" slati legal form abolished\n. Burgerlijke vennootschap onder vorm van Burgerlijke vennootschap onder vorm van legislation o >\nUSKF Belgium BE bt A ch Dutch o o g b BV VOF 20171130 |INAC o 20181101 |and automaically\nansformed into\nlegal form UW1Y\nper 1 Nov 2018\no s e s slati legal form abolished\nUSKF Belgium BE Sociéte civile sous forme de société ennom ooy, ir Sociéte civile sous forme de société ennom | 56 g 2017-11-30 | INAC legidation 2018-11-01 | and automatically\n9 transformed into\nlegal form UW1Y\n6/83\n","contentLength":5041,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:05:17.010Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-20275-entity-legal-forms-code-list/2021-10-21-elf-code-list-v1.4.1.pdf","content":"all existing ELF\ncodes for Puerto\nELF code Rico replaced with\nvaT2 Puerto Rico Special Corporation for Municipal English Spedial Corporation for Municipal 2020.06-10 | INAG inactivated and | 50201119 | new codes to solve\nDevelopment 9 Development replaced by new situation with\ncode incorrec pairng of\nthe same legal form\nin 2 languages\nall existing ELF\nSodes for Puerto\nELF code Rico replaced with\nY312 Puerto Rico Corporacién Professional Spanish Corporacién Professional 202006-10 | INAC inactivated and 15450.11.19 new codes to solve\nreplaced by new situation with\ncode incorrect pairing of\nthe same legal form\nin 2 languages\nall existing ELF\ncodes for Puerto\nELF code Rico replaced with\nY7LW Puerto Rico Low Profit LLC English Low Profit LLC 2020-06-10 | INAC inactivated and |2020.11.19 new codes to solve\nreplaced by new situation with\ncode incorrec pairng of\nthe same legal form\nin 2 languages\nall existing ELF\nSodes for Puerto\nELF code Rico replaced with\nY7Lw Puerto Rico Corporacién Auspiciada Por Municipios Spanish Corporacién Auspiciada Por Municipios 202006-10 | INAC inactivated and 15450.11.19 new codes to solve\nreplaced by new situation with\ncode incorrect pairing of\nthe same legal form\nin 2 languages\nall existing ELF\ncodes for Puerto\nnew ELF code Rico replaced wilh\nYS16 Puerto Rico Corporation English Corporation 2020-11-19 | ACTV to replace ’f‘” 50 es.n? solve\ninactivated code situation with_\nincorrect pairing of\nthe same legal form\nin 2 languages\nall existing ELF\ncodes for Puerto\nnew ELF code Rico eplaced il\nYS16 Puerto Rico Corporacion Spanish Corporacion 2020-11-19 | ACTV to replace \"%‘” ?0 es.n? solve\ninactivated code situation with.\nincorrec pairng of\nthe same legal form\nin 2 languages\nA (S Y I [ A P 2 (L AN N SN R\nfio Jow Jea [ Jemes e o [wmenaen - Tmws ov__ | ]\nT (AN S I Y S SN N L Y | Tmws ov__ | [ ]\nT (AN S I A P S LS CAN ) | Tmws ov | | | ]\nI A S I N [ AN Y | Tmws ov ] [ ]\nR Jow e || ewemss e o [Swwemmasishon @ ov | ]\nA S I Y . SN A L I | Tmws v | ]\noo Jromae [0 || [sweueoumen [Fomarian[ro[Sooemeeuropema | mww ov ]\nI I S N I (22 o [Fomarian —[ro [ Cooporaa nosiepvgreas I mww ev ]\nWorJronana [0 || [Gunicvoremdememseconomec __[romanan o |G svopemn oo meressconome |G i ev ]\noKk [Fomans 70 || [ounae oroweramena [Fomarian —[ro [z novgwerramenas e wwo ov ]\nB Jronane R0 || [soiows oo [Fomanan 1o [Soommecomperana I mwmw mv _ ]\nwon Fomania Organizafii cooperaliste de credit si casele | momanian Organizalii cooperaliste de credit si casele 2171130 |AcTV\ncenirale ale acestora centrale ale acestora\nAo Jromana—[ro || [rorcama o ribpordor [Fomanian—[ro [ Foroana e mpondori Y S 112130 L. A I I\nErorJronane o || oupisemesswonone [Fomarian—Jro [ Grupademeresseonome e o ov ]\nFopkromana R0 || [swieuwon [Fomaian—Jro——[soommageo ww v ]\n[FonJrone o || [swesenwmewean [Fomarian —Jro——[Sovewen nume s o fwww ov ]\n[FieJronane o || [reromiacasvoream [Fomarian—[ro [ Prsoun e airiza P T ov ]\nG ronane Jro || [owpmmadaen [Fomarian 1o [Gooporeiv 6 oot I ww v ]\nTS S T I A 2 [Fomarian—Jro [ cooperanva sk — ww v ]\nI S Y I O - S - O 210 L A I I\n[fFrJronane o || [repeenani [Fomarian—Jro [ Fepmzonantioct — ww v ]\nSk ronana R0 || [swewenconmmpsin [Fomarian—Jro [ Soomee m comnt pe s o o ov ]\nN T S A I [ I R | Tmwwo ov [ ]\nGweEromana R0 || [swie Covporaa Evopeus [Fomarian 1o [Sovewe Gompraiv Europeas e o ov ]\nVo romana _Jo || [sweecnconmimsmm [Fomarian 1o [Sooewe n sz s fos o ov ]\nXN Jronane R0 || [swiewe s mspereima [Fomarian—Jro——[Sovemecu epree s o ov ]\nTon2 U OB beAvHeHMA (accoLyaLii 1 Coroas!) Ob'yedineniya (assotsiaisii | soyizy) 2171130 |AcTv\n6narOTBOPUTENbHEIX OpraHM3aLtA blagotvoritelfykh organizatsiy\nP U O6WeCTBa G OTpaHVIeHHOM Obshchesiva s ogranichennoy 0171130 | ACTY\nOTBETCTBEHHOCTbIO otvetstvennost'yu\nL e O e e e L 122 0 A A A\ne I O L L 1212 0 A A A\ne || [owowoorewmeyvoue [ v [Gupvoreiye uiveaenys I mww mv _ ]\n21U ) Cot03b1 (000LMALIAM) OBUECTBEHHBIX Soyuzy assoisiatsi) obshchesivennyki 2171130 |AcTV\nGobeavHeHMt ob'yedineniy\n183\n","contentLength":3987,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:05:17.011Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-20275-entity-legal-forms-code-list/2021-10-21-elf-code-list-v1.4.1.pdf","content":"2H36 Russia [ [ ] [Cowas (accounaw) kooneparveon [Russion | |Soyuey (assotsiatsi) kooperativov 0000000000000 [t |acw I N\noW [Rusia JRUu [ [ [Mywewmaneeastonowdseypexaenn [Russian Ju [Wunispalnyyeavionomnyyeuchrezhdenya [ 00000000000 [ a7 Jacwv 1\n2R46 Russia [RU [ ] [TosepmuecmacoSomommoawwnn [Russan [ [Tovarishchesiva sobstvennikov zhilya 000 [eotrit [acw 1\n37V Russia [ | [ [encpancweecaserwienpeanpuaun [Russian Ju [Federalinyye kazennyye predpriyaliya 0000 [eotritw [acWw 1\nA \"0 ConboKoX0aRACTEOHHEIE SeTskokhozyaysivennyye proizvodstvennyye 171130 |acTy\nMPOM3BOACTBEHHbIE KoonepaTuebl kooperativy\nTIpOVSBOACTBEHHbIE KOOMEPATIB ! (KPOME Proizvodsivennyye kooperalivy (Krome\n3EAX RU CONIbCKOXOSANCTBRHHbIX MPON3BOACTE SHHLIX sel'skokhozyaysivennykh proizvodstvennykh 2017-11:30 | ACTV\nKoonepaTHEos) kooperativov)\no8 fAusa JRU | [ [vwoxaewn 0 [Rusian Ju [Uchrezhdeniya o eot7iao JacTv I N\n3TV [Rusia JRU | | [Mpodwowamsie opranmsam [Russian |u [Profsoyuznyye organizatsi o Jeot7iao JacTv I N\nProchiye yuridicheskiye fitsa\n[Mpoume 1opuAMHEcKIe LA, ABNAIOWMECA lye yurid lye 3 -\no M \" -- KOPMMSP%EK‘:W Oprama:&”flw ) M- Sanatsyam i\norganizatsiyami\n\" \"0 VaPOKAGHUR, COSAAHHEIE Gy HeKTOM Uehezhdeniya, sozdanmyye sub'yekiom 171130 Aoty\nPocowiicko denepaLi Rossiyskoy Federatsii\nA O I 27 R = O [T e lov ]\n- \"0 ConboKOX0amIACTBOHHEIE NOTPEGHTenboK/E Sel'skokhozyaysivennyye potiebilel'skiye 171130 Aoty\nXMBOTHOBORUECKIE KOONepaTHBbI Zhivotnovodchéskiye Kooperativy\nPR \"0 SKATALHGIS WAV KA -GTPONT EMHEIS Zhishhnyye i Zhilishehno-strofteTnyye 171130 |acTy\nKooneparvissl kooperativy\nGosudarsivennyye byudzhetnyye\nFocynapcTBeHHbIe GIoIKeTHbIE yupexXaeHnA . 0 i\nRU e A S uchrezhdeniya sub'yektov Rossiyskoy 2017-11:30 | ACTV\nFederatsi\nP \"0 DeRepanobIE oGy AGPCTEEHHHS Federalnyye gosudarsivennyye 171130 |acTy\nGlomXeTHbI® yUpEKACHIA byudzhetnyye uchrezhdeniya\naNZE U CanoBOmIEoKYIS, OTOPOTHIIECKNG WA Sadovodhosiiye. agarodnchestye i 0171130 Aoty\nRalHIE MOTPEGMTEnBOKIe KOONepaTHBb! dachnyye potrebitel'skiye kooperativy\nCoBeTH! MyRMLINANEHEIX 0GpasoBanwi Sovely munitsipalnykh obrazovaniy v\n8XDD M RU -- GybbexToB Poccwiickoli DegepaLim sub'yektov Rossiyskoy Federatsii 201741-30 | ACTV\n9IMi5 Russia JAu | 1 [Uewrpamemwwibax Rusian fu [Cenralnyjbank o Jeozodi-t9 fAcTV I N\n\"0 ooy AR ToGHI e YT aple TpoREwTR Gosudarsivennyye unitarnyye predpriyatya 0171130 Aoty\ncyGhexTos Poccuickolt Genepatim subyekiov Rosslyskoy Federatsi\nKasauon OGUISCTEa, BHECEHHHIE & Kazaoh' obshehestva, vhesennyye v\nBSGH RU FocynapCTB GG PoocTp Kaaonx gosudarsivennyy reyestr kazachikh 2017-11:30 | ACTV\noblilecrs & Poconiickon DenepaLin Gbshchestv v Hossiyskoy Federatsii\nSaoA \"0 TapaXHoIe M [apaXHo-CTpONTENoHbS Garazhnyye | garazhno-stroteinyye 171130 |acTy\nKooneparysl kooperativy\nOpranaallionHo-npasoBLIe hopuel AN Organizatsionno-pravovyye formy diva vy\nBZaL M RU -- AGATENBHOCTI TPaAaH ((PUANHECKVIX ML) Goyateinost grazdan (ichoskikn 1e) 2017-11-30 | ACTV\nOpramallioHonpasosLIe hoph! Organizatsionno-pravovyyy formy\ncara RU JOPUAVUECKYIX 1AL, ABNAIOWIAXCA yurdcheskikn s, yavyayushorikhsya 0174130 | AcTv\nHEKOMMEpUECKWII! KOpNOpaTUEHLMM mmercheskimi korporativnyrmi\nopratvaaLAMY organizatsiyami\nAGCOLMaLIM (GO03b1) CAAOBOAYETKIX, ResaisaiT (soyuzy) sadowdcneskih,\ncrm RU OrOPOAHUIECKIAX 1 AaNHbIX HEKOMMEDHECKHX ogorodnicheskikh i dachnykh 2017-11:30 | ACTV\no6venvHeHMit nekommercheskikh obyedineniy\nCKTA [Rusia JRU | | ~ [Hexoumepucouenaprueporaa [Russan |u [Nekommercheskiye parinersiva o eot7iao JacTv I N\nN7l [Rusia [ | | ~ [®owspocara [Rusian fu [Fondyprokata o eot7iao JacTv I N\nDos4 [Rusia [ | | ~ [ocoromweowegonas [Russian . [Ekologicheskye fondy o eot7iao JacTv I N\nDe4) JAusa JRU | [ [Ocuwccrsemweoprammcaum [Russian [u [Obshohesivennyye organizalsi o eot7iao JacTv I N\nDO25 [Rusia [ | | ~ [rocyasmporscwmiokownawws [Aussian i | Gosudarsivennyye kompani o Jeot7iao JacTv I N\nD75v \"0 KaseHHbIe NPOANPIATIR GyGLEKTOB Kazennyye predpriyaliya sub'yekiov 171130 Aoty\nPocowiickoii beaepaLin Rossiyskoy Federatsii\nEovi [Rusia JRU | | [Focyaaporackubicopnopaunm [Russian __ |u |Gosudarstvennyye korporatsi o Jeot7iso facTv I N\nEH3M Russia JRU | | ~ [Oowcorsewwsepouss Ausian [ [Obshchestvennyye fondy o eot7iso facTv I N\nTwar \"0 OpramaLioNHo-NpaBoBLIE hopHEl AN Orgarizatsiomo-pravovyye formy diya 0171130 Aoty\nKOMMEPUECKOT f1EATENBHOCTH paXaan Kommercheskoy deyatelnosti grazhdan\nN O I - e GO 7 e I N CITE R I I\ncamoynpasneHun samoupravieniya\ne \"0 ConboKOX0amACTEOHHEIE NOTPEGHTenboK/G Sel'skokhozyaysivennyye potiebilel'skiye 0171130 Aoty\nGrOPORHUHECKIe KOOepaTHBbI ogorodnicheskiye kooperativy\npry \"0 VapEKAGHIR, COSAAHHEIE POCCMAGKOT Ushrezhdeniya, sozdannyye Rosslyskoy 171130 |acTy\n®denepauveit Federatsiyey\nGWHK \"0 OBLIHb! KOPOHHEIX Ao WICTIGRHBIX Obeheriny Koronnyify raloghieenmyih 0171130 Aoty\nHapoos Pocouiickoi DeaepaLiim rarodov Rossiyskoy Federatsii\nCTpyKTypHble noapasaeneHna Strukturt .\n} ye podrazdeleniya obosoblennykh\nazro M AU -- P S Siuktumyye pocradeoniya b w10 |acty\n1OPMANHECKUX LY\nHEeABMXUMOCTU\nH2P4 [Rusia JRU | | ~ [Keoaumuiokooneparsssisroporoyposrn [Russan i [Kredinyye koopemtivyvoogouwrovya | | [017113%0 [ACTV I N\nHaNY Rusia [ | | ~ [Awsocaowwemanarss [Rusian [ Advokaiskye palaly o Jeot7iao JacTv I N\nTR \"0 DeRepanoHbIE oGy AGPCTBEHHbS Federalnyye gosudarstvennyye 171130 Aoty\naBTOHOMHbIE ypexaeHHA avionomnyye uchrezhdeniya\n52/83\n","contentLength":5383,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:05:17.011Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-20275-entity-legal-forms-code-list/2021-10-21-elf-code-list-v1.4.1.pdf","content":"CerbCKOXOBRICTEGHHEIE NOTPEGMT enboKk/e Sel'skokhozyaysivennyye potrebilel'skiye\n\"0 ConboKOX0amACTBOHHEIE NOTPEGHTenboK/E o Sel'skokhozyaysivennyye poliebilel'skiye 0171130 Aoty\nNepepaGATLIBAIOWLME KOONEpaT B! pererabalyvaylishchiyé kooperafivy\nOpramaallionHonpasoBLie hopul Organizatsionno-pravovyye formy\nov2 RU 10PUAMYECKMX ML, RBNAIOLIAXCA \" yuridicheskikh lits, yavlyayushchikhsya 0174130 | AcTv\nHEKOMMEpUECKWIY! YHUT apHLIMIA hekommercheskimi unfarnymi\nopranugaLAMM organizatsiyami\nBss \"0 ConboKOX0MICTBOHHEIE NOTPEGHTenboK/G o Selskahozyaytvermyye potebiesKye 0171130 Aoty\nGHaBHeHHecKMe KoonepaTMebl snabzhencheskiye kooperativy\nen \"0 ToRapLIECTEa Ha BOPE (KOVMAHAWTHE \" Tovarishchestva na vers (Kommandinyye 171130 |acTy\nToBapHILECTEa) tovarishchestva)\nT T I T T 2 I T ———— PFww v [\nOprar3alioNHo-NpasoBLIe hopu! Orgarizatsiomo pravovyye ormy\nJPMQ RU GpraHUaLIMi, COSAGHHEIX 523 Npas u organizatsiy, sozdannykh bez prav 2017-11:30 | ACTV\n10pMAUEcKOro Niflia yuridicheskogo ltsa\nI T I I T e L S 120\" L A I S S\ne I T S T ) S 21 LA S S I\nOV \"0 THaBb! KpeoTEAHGKIX (chepMEpoKI) o Glavy krestyanskikh (fermerskikh) 171130 Aoty\nX03RACTS Khozyaystv\ns \"0 O AeRGHAR VHOGT paHHLX HEKOMMEPUECKIX \" Otdeleniya inostrannykh nekommercheskikh 171130 |acTy\nHeNpaBITENCTBEHHbIX OpraH3aLMii nepravitel'stvennykh organizatsiy\nGosudarsivennyye avionomnyye\noGy 18CTEEHHbIE BBTOHOMHBIE YpEXACHUA ennyye e\noo \"0 ConbKOX0amIACTBGHHEIE NOTPEGHTenboK/ G \" SeTskokhozyaysivennyye potiebileTskiye 171130 |acTy\nGBbITOBIE (TOproBbie) KoonepaTus! sbytovyye (torgovyye) kooperativy\npys \"0 DenepanbHbIE roCyABpOTBEHHHIS o Federalnyye gosudarstvennyye unitarnyye 0171130 Aoty\nVHUITapHbIE NpEANpAATIA predpriyatya\nVAT apHbIE NPEATPHATR, OGHOBAHHHIG Ha Unitarnyye predpriyaliya, osnovannyye na\nOVLN RU PpaBe OnepaTUBHOTo ynpasneHAR u prave operativnogo upravleniya (kazennyye 2017-11:30 | ACTV\n(KasenHble NpennpyATIR) predpriyatya)\n“AGGOLMALI (Go103b1) SKOHOMAIECKOTo “Assolsialsi (soyUzy) ekonomicheskogo\nPASX RU B3AUMORE/iCTBINA CyGBEKTOB PoCCHACKOI u vzaimodeystviya sub'yektov Rossiyskoy 2017-11:30 | ACTV\nDenepauun Federatsii\noYW \"0 ConbKOX0amICTBOHHEIE NOTPEGHTenboK/ G \" SeTskokhozyaysivennyye potiebileTskiye 171130 |acTy\nCanosoneckHe Koonepatus.! sadovodcheskiye kooperativy\n(P T I I S T S I [V ———— PFww v [\nP, \"0 oKD ABHTETIbCTEEHHbIE MEXAYHapOAHHIS o Mezhpravitel'stvennyye mezhdunarodnyye 171130 Aoty\nopranisaLin organizatsi\nVpOKAGHIAR, COSAANHEIS MyHALTGRbHE Ushrezhdeniya, sozdannyye munitsipalnym\nQKFU RU 06pasOBaHMEN (MyHULIMNANLHbIE u obrazovaniyem (munitsipalnyye 2017-11:30 | ACTV\nyepexaeHiA) Uchrezhdeniya)\nOpramallioNHoNpasoBLIe opH! Organizatsionno-pravovyye formy\nMeX/lyHapOAHbIX OpraH13aumii, mezhdunarodnykh organizatsiy, 11\nQast RU OCYILECTBAAIOLLVX JERTENBHOCTS Ha u osushchestvlyayushchikh deyatel'nost' na 201741-30 | ACTV\nTeppHTOpA POCCUTACKOH chenepaLi ferritorii rossiyskoy federatsi\nv \"0 FloTapiyGbl, SaHAMAIOINECR TaCTHOR \" Notariusy, zanmayushchiyesya chasinoy 171130 |acTy\nnpaKTUKoi prakiikoy\nQU U VRIATapHbI® NPGANPARTIR, OCHOBAHHHIG Ha o Unitarmyye predpryaliya, osnovarinyye ria 0171130 Aoty\nPpaBe XO3AACTEEHHOTO BEAeHIA prave khozyaystvennogo vedeniya\nSadovodcheskiye, ogorodnicheskiye i\nCanoBoyeckme, OropoiHNyeckme nnm !\nRIUK RU o o e u dachnyye nekomrmercheskiye 2017-11:30 | ACTV\nfovarishchestva\nOpranallioNHoNpaBoBLIe hopMel AN Organizatsionno-pravovyye formy diya\nSIPP RU AGATENLHOCTU FPaKIaH, HE OTHECEHHON K u deyaloinost grazhdan, e olnosermoy k 2017-11:30 | ACTV\nNpeAnpUHIMaTenLCTY predprinimatel stvu\ne \"0 DEREPATIoHHIE FOCyAAPCTBEHHEIE KaSEHHbIE \" Federalnyye gosudarstvennyye kazennyye 171130 |acTy\nyipexaeHn Uchrezhdeniya\nO T T I S Y S T I [T | PFwmw v [\nUvas \"0 PalloHHbIE Gy/ibl, FOPORCKYE Gy, o Rayonnyye sudy, gorodskiye sudy, 0171130 Aoty\nMEXPAViOHHbIE Cy/ib (PAOHHLIE Cyibl) mezhrayonnyye Sudy (rayonnyye sudy)\nVABo \"0 060006 EHHbIS NOTpAsAIeNEHAR \" Obosoblennyye podrazdeleniya 171130 |acTy\n10pMAUEcKAX MWLt yuridicheskikh lits\nOprarallioNHo-NpasoBLIe hopu! Orgarizatsiomno pravovyye fory\nVETP /U 10PMAMNECKWX L, RBNAIOLIXCA u yuridicheskikh lits, yavlyayushchikhsya so17-1130 | AcTv\nHEKOMMepHECKWMI! KopropaTUEHLMM Pekommercheskimi korporativymi\nOpranugaLAMM organizatsiyami\n53/83\n","contentLength":4216,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:05:17.011Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-20275-entity-legal-forms-code-list/2021-10-21-elf-code-list-v1.4.1.pdf","content":"OPraHSaLIOHHO-TPaBOBLIE hOpMET Organizatsiomma-pravavyye formy\n1OPUAIECKIX NWALL ABNIAIOLIMXCA yuridicheskikh lits, yavlyayushchikhsya 11\nvouu RU KOMMEDNECKIMY YHUTEDHBIMA u kommercheskimi unitamymi organizatsiyami 201741-30 | ACTV\nopraHuaaLnAmMm\ne e O O e N N e I A TN T I B\nKoONepaTHEOB\nor ) HenpasuT enbCTBEHHbIE MEXlyHapOAHEIS o Nepravitel 'stvennyye mezhdunarodnyye 2171130 |AcTV\nopraHuaaLum organizatsii\nR RU Cotose! (acoouvaLim) o6 o Soyuzy (assotsiatsi) obshohin 0171130 | ACTY\nMaOUMCNEHHbIX HAPOOB malochislennykh narodov\nrpaxaaH grazhdan\nZ3v0 RU Ca/0BOAMECKHE, OTOPOARVMECKE WA o Sadovodcheskiye, ogorodnicheskiye i 0171130 | ACTY\nAAUHbIE HEKOMMEPUECK/E NapTHEpCTBa dachnyye nekommercheskiye partnerstva\nT Jrwe [ ]| |Coomcmomonmmewms e [u—[Koomysempepuiva I S 112130 L. A I I\nNHE U T0CyABPCTEEHHbIE Ka3EHHEIE Y pEXACHIR o Gosudarstvennyye kazennyye uchrezhdeniya 0171130 | ACTY\ncy6BexToB Pocawiickoii Denepauyii sub'yekiov Rossiyskoy Federatsii\nentities on both St\no Kitis and Nevis can\n2908 SantKitsand foundation English foundation 2021-09-28 | ACTV use the legal forme\nlevis mentioned here for\nthe country Saint\nKitts and Nevis\nentities on both St\nSaint Kit and Kitis.and Novs can\naint Kitts a . . . - . y use the legal forms.\nAHRM Saint KN limited partnership English limited partnership 20210923 [ACTV use he legal forms\nthe country Saint\nKitts and Nevis\nentities on both St\nKitis and Nevis can\nSaint Kitts and ! . ! § use the legal forms\n1930 Saint KN public company English public company 20210923 [ACTV use the legal forms\nthe country Saint\nKitts and Nevis\nentities on both St\nSaint Kit and Kitis.and Novs can\naint Kitts a - . . . . y use the legal forms.\nKYol Saint KN exempt limited partnership English exempt limited partnership 20210923 [ACTV use he legal forms\nthe country Saint\nKitts and Nevis\nentities on both St\nKitis and Nevis can\nSaint Kitts and \\ . \\ § use the legal forms\nWFYL Saint KN private company English private company 20210923 [ACTV use the legal forms\nthe country Saint\nKitts and Nevis\nentities on both St\nSaint Kit and Kitis.and Novs can\naint Kitts a R . - y use the legal forms.\n2478 Saint KN exempt private company English exempt private company 20210923 [ACTV use he legal forms\nthe country Saint\nKitts and Nevis\nentities on the\nisland of Nevis have\nthe choice o use\nthe legal forms\nSaint Kitts and mentioned here for\n2FOA Sant KN Nevis KN-N limited liability company English limited liability company LLeiLe 20210923 [ACTV the country Saint\nKitis and Nevis or\nuse e legal orms\nmentioned here for\nthe jurisdiction\nNevis\nentities on the\nisland of Nevis have\nthe choice o use\nthe legal forms\nSaint Kitts and mentioned here for\n4EP1 Sant KN Nevis KN-N multiform foundation English multiform foundation 20210923 [ACTV the country Saint\nKitis and Nevis or\nuse e legal orms\nmentioned here for\nthe jurisdiction\nNevis\nentities on the\nisland of Nevis have\nthe choice o use\nthe legal forms\nSaint Kitts and mentioned here for\n723M Sant KN Nevis KN-N public company English public company 20210923 [ACTV the country Saint\nKitis and Nevis or\nuse e legal orms\nmentioned here for\nthe jurisdiction\nNevis\n54/83\n","contentLength":3145,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:05:17.011Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-20275-entity-legal-forms-code-list/2021-10-21-elf-code-list-v1.4.1.pdf","content":"entities on the\nistand of Nevis have\nSaint Kitts and ) the choice to use\nBXZH S KN Nevis KN-N limited partnership English limited partnershi the legal forms\np p 202100 mentioned here for\n23 [acTv the country Saint\nKitts and Nevis or\nuse the legal forms\nmentioned here for\nthe Juisdition\nVis\nentities on the\nistand of Nevis have\nSaint Kitt ) the choice to use\nEF4Y Saint Kitis and ey Nevis KN-N foundation Engi ) the legal forms\nnglish foundation\n202100 mentioned here for\n23 [acTv the country Saint\nKitts and Nevis or\nuse the legal forms\nmentioned here for\nthe Juisdition\nVis\nenities on the\nistand of Nevis have\nSaint Kitts and ) the choice to use\nHE4R N KN Nevis KN-N private company English private compan the legal forms\npany 20210023 | ATV mentioned here for\n- the country Saint\nKitts and Nevis or\nuse the legal forms\nmentioned here for\nthe Junsdiction\nVis\nentities on the\nistand of Nevis have\nSaint Kitts and the choice to use\nHW77 ! i ' _\nNevis KN Nevis KN-N International Business Company English Intemational Business Compan: IBC the legal forms\npany 202100 mentioned here for\n23 [acTv the country Saint\nKitts and Nevis or\nuse the legal forms\nmentioned here for\nthe Juisdition\nVis\nentities on the\nistand of Nevis have\nSaint Kitts and the choice to use\n1038 ; ; . '\nNevis KN Nevis KN-N international exempt trust English international exempt trust the legal forms\np 202100 mentioned here for\n23 [acTv the country Saint\nKitts and Nevis or\nuse the legal forms\nmentioned here for\nthe Juisdition\nVis\nentities on the\nistand of Nevis have\nSaint Kitts and ) the choice to use\n18G4 Navis KN Nevis KN-N exempt private company English exempt private com the legal forms\npt pi pany 202101 mentioned here for\n9-23 [ACTV the country Saint\nKitts and Nevis or\nuse the legal forms\nmentioned here for\nthe Juisdition\nVis\nentities on the\nistand of Nevis have\nSaint Kitts and the choice to use\nOTE3 ! i - '\nNevis KN Nevis KN-N exempt limited partnership English exempt limited partnershi the legal forms\np p 202100 mentioned here for\n23 [acTv the country Saint\nKitts and Nevis or\nuse the legal forms\nmenioned hers for\nSaint Vincent the Jurisdiction\n10ST . vis\n210923 |ACTV\nPuE Saint Vincent\nand the ve ! '\nSronades e o _ puote comeary _ o2\n10923 |ACTV\n306 Sa‘ijnthvincent - international busi ;\nedthe ve international business company - limited ' international busi jmi\n: inters English . usiness company - limited ] .\naint Vincent : :\ne - e o] asiness company - COMPANY | gngjgh international business company - compary\ne it mieabysheres e _ e ---\naint Vincen\nABII and the Ve international business company - unlimited . i . . —\nf s p English international business company - unlimited\nGrenadines company not authorised to issue shares nglis! company not authorised to issue shares Unltd 202109-23 |ACTV ---\nSaint Vincent\nFGaL and the Ve '\nGrenadines company English company Ltd;Corp;inc 20010025 | AcTv\no6 Saint Vincent\nand the ve i '\nSrenadhes e Froe _ prershie _ e\n9-23 [ACTV\nLova g:‘ijn:h\\éimenl vo -- :nleréglional business company - company international business company - company\n: imited by guarantee not authorised to issue | English imi ised 10 i\nGrenadi glist limited by guarantee not authorised to Corp\nS v.mes . shares fimited by g ised toissue | Ltd;Corp;inc 2021-09-23 [ACTV -\naint Vincen\nQvzp and the Ve etorshi _\nGrenadines sole proprietorship English sole proprietorship 10 A\n9-23 [ACTV\nSaint Vincent international busi\nREVE Saint vi ve - - international business company - company - nternational business company - company\ne y guarantee authorised to issue English limited by guarantee authorised to i K ;\nS v_mes 0 shares it 0 Issue LtdCorp;inc 2021-09-28 | ACTV -\naint Vincen\nRYSB and the Ve international business company - unlimited . i . . —\n' 3 _ Enal international business company - unlimited\nGrenadines company authorised to issue shares nglish company authorised to issue hares Unltd 202109-23 |ACTV ---\n55/83\n","contentLength":3928,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:05:17.011Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-20275-entity-legal-forms-code-list/2021-10-21-elf-code-list-v1.4.1.pdf","content":"Rl N I I N N S R R I T S I\nS10K and the ve non-profit company English non-profit company inc.;corp. 202109-23 |ACTV\nGrenadines\nS N I I R N S EEE R I I N S I\nUSAR and the Ve statutory company English statutory company 202109-23 |ACTV\nGrenadines\nA N I B N S R I I N S I\nXY6R and the Ve co-operative society English co-operative society 202109-23 |ACTV\nGrenadines\no O O = e O i o N ) co I N\n[P foamn w5 [ [ Jowwew e o o [ fmeww pev [\nT S L I L e - L S 121530 L= A I I I\nT L O (s i s ) A ol G I N B\nA S L I (Y - T S 121530 LA I I\nN S L I (- L (T S 121530 L A I I\n5% foamon w5 | Trcommmiwooy —eweor —Jroovomedsmey [ Jawnw ev [\nS L I (. - L T S 121530 L A I I\nN N I S L L S - 30 L A A I\nT N N I e A L S - 30 L A AN I\nI N I = T L A L S - 3 L A I I\nI N I o L A Y A S - 30 L A A I\nR N I S A - S - 30 L A I I\nS S I L L L S - 3 L= A I I I\nN S I e L S - 0 L= A I I I\nN S I e L S - 3 L= A I I I\nN S I L L S - 3 L= A I I I\nN S I S L L S - 3 L= A I I I\nT e I B - S S 121530 L= A I I I\nN S I Y - LT - 121330 L= A I I I\nB fsoba s [ | Thoumeoweste Jemw [ oweepess e fmeww pev [ T\nA S I L - S . 121330 L= A I I I\nN S I L - T 1 121330 L= A I I I\nT S I - - S 121330 L= A I I I\nR S L e L Y. S 12130 L= A I I\nWew fseba o [ | wowwmww Jemw [ [Hoowsesww Jaaw haw —— fmemw pev [ T\nPOV fseba s [ | Jommwomumo Jeww [ Jowdcame foa —— Tegw —— f@erw pev [ T\nR S I - S - 3 L= A I I I\nI e e I L S T S - 0 L= A I I I\nR R N I B il G GO = il A R 2 S I I\nR S - I I T - L 1 (S S - 30 L A I I\nA S - A I L - L S - 3 L A I I\nA S - I (T e S A S - 3 L /A I I\n[ES._[Sowroles [56 || [Company Umiod'y S oo [engish —on oo Ly ShresangGamraree | TJamoew fov [\ni G N I N 7l G GO il A R 5 S I R\nI e I 1 - 1 S - 0 L A I I I\nA e e I 1 T S - 0 L= A A I I\nT G i I N (Sl G GO v Sl A R N T I\nT R O I N 7l G GO il A A N R I I\nN S e I (L . L S - 0 L A I I I\n(GO TSowroles[s6 T | [roiceacoloomay — TeweJor — [romescstompmy e T fameew pev [ T\nS S - I (1 (2 S - 3 LA I I I\ne e o I B e G GO it A R 5 S I R\nmpany Company\nN L e O L - L L L N 12130 - A I I\nR L I S . S 121230 L= A I I I\ne L O L S L L L I 121530 L= A I I I\nI L e I (2 S ) S 121530 L= A I I I\nOO fSngoe S8 [ [ Jompntow ——— Jeww oo Joomn@om) — Jretomlows [ fmemw pev [\nS L S I . - L S - 3 L= A I I I\ne L S I - L A - 3 L= A I I I\nPR [Smibamrin [SC [ | [ommandure erooutupopaanasn o[ oonmanatar vemoosehmpopaarader | ] fmmsw pev [ T\nR L S I L T B T 2 2 - 0 L= A I I I\nR L S I . - S S - 3 L= A I I I\nL S I B S - 3 L= A I I I\nBi0 T[St [SC [ | Johvoo wabogmasobp——oum [ Towdotrgs vawbopmatap —Joww ————————————————— Jow —— Jmmsw pov [ [ T\nN L S I . - A - 3 L= A I I I\nN L S I - . S - 3 L= A I I I\nD L S . - - S - 3 L= A I I I\nN L S I L - (A - 0 L= A I I I\nN L S I L L (A (A - 3 L= A I I\n56/83\n","contentLength":2691,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:05:17.011Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-20275-entity-legal-forms-code-list/2021-10-21-elf-code-list-v1.4.1.pdf","content":"e S O Y I 230 - A I I\n[0 fSoam s | | [Sechomaopnatresorats [Soak o Sl ogmmtrt eaoba 80 _[Spogpaeato [ wewrw ov |||\n[foSW S s | | Jowowpuk JSom o Jowowpw [ [ wewrw ov___| | |\ne S O I L S L2530 - A I I R\n[ fSom s | | [Rosoaopmmn [Som [ [Rosodogmmes [ [ wwrw ov___ ||| ]\nS S O R I - o O e e (N A i A A\nW8 [Soaie o< [ [ Tmhmemoow Sow [ [mwmeow [ [ ewrw ew | | | ]\nT S I I [ S S L A L S I 1230 . A I A R\nS S I I 7 - S I 1230 . A A I\ne [Souie o< [ [ owmwabm — [Som o [owdwbw [ [ Towrw oW ]\n[P0 [ [SC || ousiony poonk o eirymaaadason) Sk [ [oussiony poonkleimmasagason) | [ Twwrw oW [ ]\ne S I I T - S I 1230 A A I N\ne S I e S S T I 1230 - A A I R\ne S O 7 S S 1 1230 A A A\nI S I . S S 2 1230 . A I I\ne S I [ S L L N 230 - A I A R\nA S N IO L e S L e L ) N 230 - A I I R\nVe [Soee < | | [Seocomsoe poesitoms [Sowk [o[SewRogmmme poestones [ [ Towrw oW [ ]\nN e G I 1 e O 1 Sl S i A\ne e e I Bl O 1l L A TN (T I D\nA S O . . S . 2230 < A I I\nI S I e e o i A N (Cn i A S\ne S 1 S S I 1230 A I I N\nN R e O I e e e A N oo i == s\nT S O [ L e S L2530 - A I I R\nKD Sl S ||| oo o ooboesjehvany ez [Siomk ok | ool sons omropray vy oeanie [Jedsbonoshamy i [ werw ov |||\nRE [Som s || Ousswy poonkpohoborpodisy Sk ok [Dussty poankpohosposirsy __[oasemyeanipd [ werw v ||\n(N S o R O - e oo O 1 et N i A A\nO S I I T S e e N 1230 L A I N R\nR i G M I = i O o e L R R i A R\ne fowe e [ | RS pe o [EEEERESE Jewwew ] eeler [ | ]|\n95MS Slovakia SK podnikajica na zaklade iného ako Slovak sk podnikajica na zaklade iného ako FO-slob.povolanie 2017-11-30 |ACTV\n\nZivnostenského zakona Zivnostenského zakona\ne S O T e T S 2530 - A I N N\nS S s | | enewbyed JSom ok mewtwow [ [ wewmw ov___ |||\npose foown | | [ |emetmEeeemndd Jsoa [« [momroeeneremss Jeesasees [ e pev | ] [\n\ninspekcie ingpekcie\nB& [soaie [k [ | [ovmsmwsrose [Sow [0 [ovmemsmesose [owsmemeone [ Twwrw oW [ | ]\nN S N O e O e 2 N oo i == s\nN e G R I A S O A e S (N 5 i A A\n\nobchodnom registri obchodnom registri\nN S G I O £ S O = e i v R A i A I\ne S I I e L N 230 - A I I R\nDRC S s | | Jwwwon fSow & fmwwwes [ [ wewrw ov___ | || ]\nEWK S s || [vesmons oguiiom amien[Sowk [ [Weduniroons oguzion azaters [Wemmirop ez [ werw ov ||\nB0 fSowm s | | [ouwesww Jsom [k [mwweewwe [ [ mwww ov___ | | |\nS e N ] O N i o A . N A\n\nmimo Uzemia SR mimo Uzemia SR\nEob fSowm s | | [rosbmwok fSow o Jesbmepow [ [ wewww ov___| | |\nT S I O (Y S e L S 1230 - A I I R\nI S O - e e S 2530 - A I R R\nT S G N I e S O L7 il R N A i A A\n[FiS[Soaie [sc || mouomoucomtoymay__[Somc [0 [ pwconsoweomiBobiy__[mpmewesesioy [ Twwrw ew [ ]\n[FoRE[Sowtia S ||| Utolus i obohoord ogarace [Siowk _[o [t s bohooni oganeaz [Uesovtzamotghog [ Tawrw ew [ ]\n[Glor oS¢ || [rostore doogoteor w9 [rostore doovmotte __[eosomeas [ Towrw ow [ ]\n[V [Soe s« | | Jonomogmmon _ [Sowc o [omemeogmaen [ [ Towrw ow [ ]\nWi fsouie ¢ | | Twodvon — Sow o wedwee [ [ Towrw v [ ]\ne S I L S S L L S 1230 - A I S N\n73 foouie s [ Towsw o o fowwe [ [ Tewrw ow [ ]\nez [Souia s« | | [owncadoooapson [Sowc o [ownoadondoapoons [ooneadeges [ Twwrw ow [ ]\nWez [Souie ok | [ Twowowse [Som o wemwewwe [ [ Towrw ow [ | | ]\nT i G I I = e O = e e R R i A R\nS e O I R e S O e (toceiissc N N N i A A\nI S N I L S e L S I 230 A I A R\nRG0S [sC || [Zauioro mocroamochoross _[Sowk [ [Zanoro modaroamrochoross __[eangmeddraboross [ Twwrw oW [ ]\n[KWFE S [sK || [Vomon Gujnmos polesyontons) Sk [ [fomom bummeowpotesentoney [ [ Towrw ow [ ]\nKZ3R Slovakia SK Poistovria - Statny podnik Slovak sk Poistovria - $tatny podnik Poistovna - §. p. 2017-11-30 |ACTV\n\n/83\n","contentLength":3505,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:05:17.011Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-20275-entity-legal-forms-code-list/2021-10-21-elf-code-list-v1.4.1.pdf","content":"S R S I I L . S S 2 1230 1 AN I I B\noW [Sowtn S || [Obec oy o0, mesoroaay ) _[Slowlt ok [ O ooy a0, o mesly 9 [Obeomesiolomtmy [ Twmrw pov [ [\n\nSlobodné povolanie-fyzicka osoba Slobodné povolanie-fyzicka osoba\nERCEONENEN- - SNSEN e I S N N\n\nobchodnom registri obchodnom registri\ne L I G U N A\nMY1S Slovakia SK Zlozka podniku zapisujica sa do obchodného | Slovak sk Zlozka podniku zapisujica sa do obchodného | Odstepny zavod v OR 2017-1130 |ACTV\n\nregistra registra\nNeWX Somka K || [Samosumo oo vasdomtn _[Sowk [ Semosabe poomkalie haokiowbe_[Samosanepoimiaizpo | Jwwne ew [ | ]\n(I G N I I il N N il et A I oo o A I\nT e S I IO 2 e e S T 230 1 AN S I B\nWos [Sowtn [sC | | [Woaommma kot [Souk o |Uohummmpota ) Useaogeant [ Twmrw pev [ [\nWS [Sowt [SC || [Sobrypmaikvemymiatadaom)[Sowk [ [Soobenjpodmkloveoymizaadmgy | [ Twmrw pev [\nM7 o s [ [ Jvomm — foom & o | [ Twwmw pev___[ [ [\nI e S I I 2 S S . 230 L AN I I B\nR e S I I L S S L 230 L AN Y I B\no7 [Sowi s [ | [ocbmak — fSow koo T [ Twmmw pev___[ [\n[0z [Sowin sk [ [ Jowmjme oo & Toemyow T [ mmmw pev [ [ [\ne e O I e O e I 2 O AN I\nI S I O (Y . S (. .22 A A A\nRSy Soka K [ | [Soweawsw __ JSew J% _[Sewbeeww | | Jowne v __[ | | ]\nok [somka _[sK [ | [Soostonmammdge [Sowk [%|Socbwsitommdmmace [Seonmawe | Jwwne v [ | ]\ne e e e I e e e et N HNN I T A N\nI R S I I . R e S e 230 1 A Y I B\n[SSET[Sowtn S || [V oo b el stobloot_[Slowt ok [ Voo otz pwergpeablon | [ Twmrw pev [ [\nN e S O I e e S e W 230 L A S I B\nWS [Sowtn s [ | [umoemwee fSom [k wmewwe T [ mwmw pev [ [ [\nR N O I I = o O = N I (T AN N\n- Ol e I ) U I A\nsQ4l Slovakia SK podnikajca siéasne ako osoba so Slovak sk podnikajica suéasne ako osoba so Ziv.a sl.povolanie 2017-1130 |ACTV\n\nslobodnym povolanim slobodnym povolanim\nSoW_somia [ [ | fwawsme fSew [&x Jwewwwe | | Jownw few__[ | | ]\n[P [Sowka K [ | [NomowiaSoewa [Sew [% |NeohabweSoewa s | Jwwnw few [ | | ]\n[S0F [somka K [ | [Gumdoemeduser [Sow |% |Zundognmmeawse [Bumoaogdwse | Jowne few [ | | ]\nTG [Sowka K | | [Scpomomé pohuopodise e[Sk ___[sk___|Svopomooné poohospodarsle drsie _[Svapomoepelndngsie | TJaowneo oW [ | ]\nA% [Sowka K [ | [ommcaweraway __[Sowk [% |rhogensicavesesan __ [mogwomegay | Jwwne v [ | ]\nI G N I I = e N e ] e e N I Gl U I R R\nU500 [Sow s [ | (e dooawoobed [Som o B ddodwoeod Emeas [ Twmrw pev [ [ [\nW [Sow s [ [ Jwemeesn fSom & Peemess T [ Tmmrw pev___[ [\nU [Sow S [ [ ewm — foom & Teww T [ Twmrw pev___[ [ [\nUoT0[Sowt —[s¢ || [ovemonmiupoiats [Soek o |Obhsmoguiipdoiate oWogeamiegsy [ Twmrw pov [ [\nVAN [Sowtn s || [Eutrlosodupen G sroopice [Sowtt ok [ Evpo oouperie ol wotaris [Ewbpanduptzenn [ Twmrw pov [ [\nN N O I I =5 e O = e A I SN (TR I R\nI G O I I 3 R N N ot e I oo R A E\n\nrozhlasova, tlagova a televizna agentira rozhlasova, tlagova a televizna agentira g\nVS5 [Sow [ [ | [Socwawmnndmdmyn [Soak [ [Sobmtsdenmobmedenm oo [ Tmmrw pev [ [ [\npon_foee e | ] EEEERSES Jew | ERERMEES e | el ] ]\nWQCR Slovakia SK podnikajiica siéasne ako osoba so Slovak sk podnikajica si¢asne ako osoba so Ziv.a sl.povolanie v OR 2017-1130 |ACTV\n\nslobodnym povolanim slobodnym povolanim\nU [somta K [ | [roncasmmpoiommie [Sow [% [Polasmmpomeemie | | Jowne few [ | | ]\nVo6 somka o< [ | [Sampow fSew J& [Sawpaw | | Jownw few__[ | | ]\nVe [Sowka K[ | [ronwsdvaneocbood [Sowk [ [Foakaamamewseon ___Jer0 | Jowne few [ | | ]\nYo% [Sowka _[SC || [Podniso sahvanGrou majeiovou o[ Sovak |5k Poak sosavaninoumapetiowou Gastou_[Podmk oz e | Jaowneo Jew [ | ]\nVe [Somka K [ | |Voopopmwamdiuos ___[Sowk [ |Vomropmmemsioen ___ Vewnopvieies | Jawne few [ | | ]\nVoNe [Somka K [ | [oestmdotlapitu [Sewk _[% [Ogmmmddepoima | | Jowne v [ | | ]\nViU [Somka K [ | [Weododopmmn _ [Sow [% |Nemlodogmges | | Jowne v [ | | ]\nI R I I 7 N = e N i s S S £\n\nzaujmov zaujmov added abbreviation\nN e O I I = e O e e R N i (T I N\ne e e I I et e e -l e S NN i T A N\nN S O . . . 1720 1 A I I B\n[(OR [Sowna 51— [ [ Jommaoww fSoew [0 fewGegww g [ Twmmw pev [ [\nFoTE [Sewnn S [ [ fwawn fSoww [0 fwewe T [ Twees pov___[ [ [\nFR [Sowin s [ [ Jondmbie fSoew [0 Joewembwa [ [ Twees pov__[ [ [\nN S I I I e L O = 230 1 AN I I B\nN N O I I e e O e I o (T IR I I\n\norganizacije organizacije\noY Sowms S [ [ o fSeew [§ fUdwes | | Jwwos ew__[ | | ]\nR S O - S . I 172200 L AN S I B\n\n58/83\n","contentLength":4226,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:05:17.011Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-20275-entity-legal-forms-code-list/2021-10-21-elf-code-list-v1.4.1.pdf","content":"O [Sowa [s | [ [owohsedonn [Soew [0 Jewwwesew [ T mees pev [T T\nN ) I T - L S 23 L= A I I I\ne ) I - Y S 23 L= A I I I\nI ) I T - T S -2 L= A I I I\nN L I L S S -3 L= A I I\n0e [Sowa s [ | Toowewaws Seww [0 Tewmemeee [ P fmwes pev [ T\n[0 [Sowra s [ | [oubcommmaoon [Soww [doubcomsrostgomte Jaes | fmeww pev [ T\n@0 [Soora s [ | [Supwsthumkovsway [Soww [0 Sty [ mwes pev [ T\nL ) S S 23 L A I I I\nS ) I - S 3 L= A I I I\nN ) I L - L . S 121530 L= A I I I\nN e I e L e I N -3 L= A I I I\nS ) I . YT S -3 L= A I I I\nT ) I T O L L S -3 L= A I I I\nv [Sowra s T[T Toubewpoe — Soww o [oubewpes [ ———————————————— fmwes pev [ T\nN ) I T O 2 S N -3 L= A I I\nRz [Sowa S | [Soosus Conmratauopaon ——[Sowne [ [SooolsCoobaburopmen s | fmwa pev [ T\nS ) O (T - L S -3 L= A I I I\nI ) I L O T L S 121230 L= A I I I\ne ) O L O 2 S S 023 L= A I I I\ne ) I (= O (2 S 3 L= A I I I\ne foowme o T T Tewew Toeew [ Tenew [ 1 fwwew pev [ T\nT e I (L S T S 123 L A A I I\nN I I . S T L 121230 L A A I I\noz fsomia o T | TrowbraSowos — Soow [0 TrweSowne [ 1 fwwew pev [ T\nN 7 N I B s G GO s R R N S I\n(S S N I I (T R GO G I N N O I\nS N I B s N O = R R N S I\nR S N O O (T G e I A N N I\nN N L I (- L T (S S 12130 LA I I I\nR L I (e L T S 121230 L A A I I\nT L I (T L T (T S 121230 L A I I I\noo [ | ThorrorGomay ———— Tewe o oovpomGampay e 1 fawnrw pev [T\nA N L I (e T e S 12130 L A I I I\ni [souamen [ || [SawowndComay e or —[Sewowedtomny _—Jsoc | Jawrw ev [\nT N S I (= - 1 S 121530 L A I I\nI N L A I (2L e L . L S 121530 L /A I I\nA L L I 1 - L . (1 A 121530 L A I I\nI L S I (s N T S 121230 LA I I I\nN G O I e S e e R I S I R\nN S I o L L 1 O 121330 L= A I I I\nN S I = L L S 121230 L= A A I I\nT G SO I N = il i SO o el R R I R I\nregular colectiva profesional) regular colectiva profesional)\nA R - A I (.. - [ . S 121530 LA I I\nR R S I T e T S A - 30 L /A I I R\ne R S I . - [ - S S 121530 L A A I\nN L I T e L S 121330 L= A I I I\nR S I e e e e S - 3 L= A I I I\nN S O Y e T Y S 121530 L= A I I I\nN S O L e Y S S 121330 L= A I I I\nok fean s T [ Dems Jeew o fmewss ] —————————— fmwes pev [ T\nI S I L L L S 121230 L= A A I I\nS O L e Y S S 121330 L= A I I I\ne S I L o L S 121230 L= A I I I\nR S O T e T I S 121330 L= A I I I\nT S O e e L e S 121330 L= A I I I\nB8 S es | [Soumcen Ewopesda o oo S oo | Aupaion o do s Erories hErE | fmeww pev [ T\ne ) I L L S 121230 L A I I I\nT S I e e e . S 121530 L= A I I\nN L O L e T Y S 12130 L A e i U\n(i N S I B (il G S -l e A I (i I I\nI R - I . L T S 121530 LA I I\nN R S I e T e e e S 121530 LA I I R\nN CE O N N s G G i s B I R I\nror oo e [ | |ovesecwwmsemwome s oo [womescopemverwns [ooeesce | [meew pov [ s [SEL |\nT L I e e L L S 17130 L= A I I I\n59/83\n","contentLength":2638,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:05:17.011Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-20275-entity-legal-forms-code-list/2021-10-21-elf-code-list-v1.4.1.pdf","content":"This legal form was\ndouble entry of on the list twice,\nK6Lo Spain ES Sociedad Civil Profesional Spanish Sociedad Civil Profesional 2017-11-30 [INAC legal form 20190705 alsoas ELF Code\nremoved ARDP; and K6LO is\nless used\nS [on 5 || [cowmmacmn [Soris——[e=——[Cooporave o odio 1 S 112130 L A I I\n2N T R N N T e [i[coorraievevererirs e v | ]\nKJzZ3 Suriname SR Filiaal of Bijkantoor Dutch Filiaal of Bijkantoor 20190705 |INAC deletion 2020-06-10 this is nota\nSurinam legal form\n’ Commanditaire vennootschap (op aandelen) Commanditaire vennootschap (op aandelen) | ov-cy-G.v.« g\nO oo Commarsas veroas e Y pry\ne o [ eeww o v weww [ [ Jmuew oW [ | | ]\naWWY Surname sh Commanditaire vennootschap (op aandelen) | putan Commanditaite vennootschap (op aandelen) | cy-ov:G.v ov. 0190705 |ACTV\nmet meer dan een beherende vennoot met meer dan een beherende vennoot\nTovs Surname R Naamioze Vennootschap / Limited Company | putcn Naamloze Vennootschap / Limited Company | v.mvv v, 0190705 | ACTY\nby Shares by Shares\nWowe [swmne [ || [vemoossmoneeenima B |7 [vemoomrepondereenima VRV OF v eee v ]\nldeell forening (som bedriver : Ideel forening (som bedriver - language code y language code\n1TNo Sweden SE -- néringsverksamhet) Swedish sv néringsverksamhet) 2017-11:30 | ACTV adiustedtosv | 20190705 |agjisted to sv\nTrossamiund (som bedriver - Trossamiund (som bedriver y Tanguage code y Tanguage code\n2uAX Sweden SE -- naringsverksamhet) Swedish s naringsverksamhet) TSF 201741-30 | ACTV adiustedto sv | 20190705 | licted to sv\n: - language code y language code\nA s R N B T swoasn [ e N AT (T = G\n: - y Tanguage code y Tanguage code\nN N == ST p— ey N I T A S\n’ : ’ - - language code y language code\nN O P r—— ScEsor N S A T\nrort - ron y Tanguage code y Tanguage code\no Jeem ||| ST Pm—— = N I T A S\n: - language code y language code\nI P r——— m N S A T\n- - - y Tanguage code y Tanguage code\nN e | F—— o N I T A S\n— - — \" Y language code y language code\nA O P vme——— e N S A T\n: - : y Tanguage code y Tanguage code\nI N ST p——— ™ N I T A S\n: - language code y language code\nS e Fv— = N S A T e\nR N R oy language code y language code\nN | rm— For N O e R\nP - — \"y Tanguage code y Tanguage code\nI O | F———— ors N S O A\nI - I - language code y language code\nT P r——— s N R I A T\n- P - - P \"y Tanguage code y Tanguage code\nI N S po———— - N S O A\n: i ; : : i ; - language code y language code\nI I R e o Erorerak oo ey |EE0 N R I A T\nEuropeisk gruppering for teritoriellt - Europeisk gruppering for territoriellt y Tanguage code y Tanguage code\nN O = S oot s e [ [ awaras [l\nP - P - language code y language code\nS e T Fo—— o N R I A T\n— - — \"y Tanguage code y Tanguage code\n[ G N I N Svesrn [ Sesedrnh I A TN (T = CR i\n’ : ’ - language code y language code\ne P poreo m N R I A T\nSwiss branch of an enterprise domicied Swiss branch of an enterprise domidled\n1BL5 Switzerland | CH abroad not registered in the commercial English abroad not registered in the commercial Foreign Coop. & Ltd.Co. 2017-11-80 [ACTV\nregister register\nSuccursale suisse d'une entreprise domiciliée Succursale suisse dune entreprise domiciiée\n1BL5 Switzerland | CH alétranger non inscrite au registre de French r alétranger non inscrite au registre de Coop & Sarl étranger 2017-11-80 [ACTV\ncommerce commerce\n55 Swizeriand | oH \"Auslandische Niederlassung nicht im Gorman \"Auslandische Niederlassung nicht im “Aus.. Gon. & GVBH 0171130 | ACTY\nHandelsregister eingetragen Handelsregister eingelragen\n60/83\n","contentLength":3452,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:05:17.012Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-20275-entity-legal-forms-code-list/2021-10-21-elf-code-list-v1.4.1.pdf","content":"per 1 Nov 2018\nilrechtii ; ilrechili ; slati legal form abolished\n. Zivilrechtiche Gesellschaftin der Rechtsform Zivilrechtliche Gesellschaftin der Rechtsform legislation o >\nUskF Belgium BE einer offenen Handelsgeselischaft German einer offenen Handelsgesellschaft ZRG OHG 20171130 | INAG change 20181101 and automatically\nlegal form UW1Y\nper 1 Nov 2018\n\" \" slati legal form abolished\n. Burgerlijke Vennootschap onder vorm van Burgerlijke Vennootschap onder vorm van legislation o >\nucTe Belgium BE Cardboumennootachas (8Y L) Dutch Croboumenootachan (8Y L) BVLV 2017-11-30 [INAC e 20181101 and automatically\nansformed into\nlegal form ZOK2\nper 1 Nov 2018\nlegislation legal form abolished\nucTe Belgium BE Société civile sous forme de société agricole | French r Société civile sous forme de société agricole | SC SAGR 2017-11-30 [INAC egislati 20181101 and automatically\n9 transformed into\nlegal form ZOK2\nper 1 Nov 2018\nilrechtii ; ilrechili ; slati legal form abolished\n. Zivilrechtiche Gesellschaftin der Rechtsform Zivilrechtliche Gesellschaftin der Rechtsform legislation o >\nucm Belgium BE einer landwirtschaftichen Gesellschatt German einer landwirlschaftichen Gesellschaft ZRGLG 20171130 | INAG change 20181101 and automatically\nlegal form ZOK2\nVo3 Belgium . Internationale vereniging zonder Dutch Intemationale vereniging zonder vzw 0171130 | ACTY\nwinstoogmerk winstoogmerk\nI T S O L e e e v ]\nVo3 Belgium o Internationale Vereinigung ohne German Intemationale Vereinigung ohne Voo 2171130 |AcTV\nGewinnerzielungsabsicht Gewinnerzielungsabsicht\nfy— Belgium . Naamioze vennootschap met een sociaal | putcn Naamloze vennootschap met een sociaal | gy 50 0190705 | ACTY new legal form per\noogmerk oogmerk 1 May 2019\nper 1 Nov 2018\nBurgeiiko vernoolschap onder varm van Burgeriike vennoolschap ander varm van legislation legal form abolished\nvaL? Belgium BE besloten vennootschap met beperkle Dutch besloten vennootschap met beperkle BV BVBA 2017-11-30 [INAC egislati 20181101 and automatically\naansprakelijkheid aansprakelijkheid g transformed into\nlegal form NSNT\nper 1 Nov 2018\no s e I i legal form abolished\n, Société civile sous forme de société privée a Société divile sous forme de société privée & legislation o >\nvaL? Belgium BE monbatis e French r monbabilts imide SC SPRL 2017-11-30 [INAC e 20181101 and automatically\nansformed into\nlegal form NSNT\nper 1 Nov 2018\nZivilrechtliche Gesellschaftin der Rechtsform Zivilrechtliche Gesellschaftin der Rechtsform legislation legal form abolished\nvaL? Belgium BE einer Privaigeselischaft mit beschrankter | German einer Privalgesellschaft mit beschrankler | ZvGPgbH 2017-11-30 [INAC egislati 20181101 and automatically\nHaftung Haftung ng transformed into\nlegal form NSNT\nper 1 Nov 2018\nBurgerlijke vennootschap onder vorm van Burgerlijke vennootschap onder vorm van legislation legal form abolished\nWTLP Belgium BE cobperatieve vennootschap met onbeperkte [ Dutch cobperatieve vennootschap met onbeperkie | BV CVOA 2017-11-30 [INAC egislati 20181101 and automatically\naansprakelijkheid aansprakelijkheid g transformed into\nlegal form LWHF\nper 1 Nov 2018\no s e - i legal form abolished\n, Société civile sous forme de société Société civile sous forme de société legislation o >\nWTLP Belgium BE coopérative a responsabilité illimitée French fr cooperative a responsabilité illimitée SCSCRI 20171130 |INAC change 2018-11-01 and automatically\nansformed into\nlegal form LWHF\nper 1 Nov 2018\nZivilrechtiche Gesellschaftin der Rechtsform Zivilrechtliche Gesellschaftin der Rechtsform legislation legal form abolished\nWTLP Belgium BE einer Genossenschaft mit unbeschrankter | German einer Genossenschaft mit unbeschrankler | ZvGGugeH 2017-11-30 [INAC egislati 20181101 and automatically\nHaftung Haftung ng transformed into\nlegal form LWHF\nafter 1 May 2019,\ni egal fom is no\n. \" . - ot for new\n; Cobperatieve vennootschap met beperkte Cobperatieve vennootschap met beperkte legislation nger useC o\nX8zZK Belgium BE aansprakelijkheid van publiek recht Dutch aansprakelijkheid van publiek recht CVBA PR 2017-11-30 |ACTV change 2019-07-05 gntilies; # stil exists\nestablished before\nthat date\nafter 1 May 2019,\nthis legal form is ho\ne e i longer used for new\n, Société coopérative a responsabilité limitée Société coopérative a responsabilité limitée legislation ger used for\nX8ZK Belgium BE it oo French r oot pooie SCRL DPU 2017-11-80 [ACTV e 20190705 [enilles; i il exisis\nestablished before\nthat date\nafter 1 May 2019,\nthis legal form is ho\nSttentl ! f Sttentl ! f slati longer used for new\n, Offentlich-rechtliche Genossenschaft mit Offentlich-rechtliche Genossenschaft mit 4 legislation ger used for\nX8ZK Belgium BE beschrankter Haftung German beschrankter Haftung OfrtGmbH 2017-11-30 ACTV change 2019-07-05 z‘rtgfi(?{ien:““ exists\nestablished before\nthat date\nafter 1 May 2019,\nthis legal form is ho\nitai itai slati longer used for new\nN Gewone commanditaire vennootschap met Gewone commanditaire vennootschap met legislation ger used for\nXLEO Belgium BE o ol oogmerk Dutch o ol bogmr GCW SO 2017-11-80 [ACTV e 20190705 [enilles; i il exisis\nestablished before\nthat date\nafter 1 May 2019,\nthis legal form is ho\nL L i longer used for new\nXLEO Belgium BE Sociélé en commandite simple & finalité French fr Société en commandite simple & finalité SCSFs 201741-30 |ACTV 'Cergsn'g锓 20190705 |entios: 1 stil exicts\nfor entities\nestablished before\nthat date\n7/83\n","contentLength":5415,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:05:17.012Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-20275-entity-legal-forms-code-list/2021-10-21-elf-code-list-v1.4.1.pdf","content":"T e R N S R\n1BL5 Switzerland CH domiciliata all'estero non iscritta al registro di | ltalian it domiciliata all'estero non iscritta al registro di | Coop. & SAGL estero 2017-11-30 |ACTV\n[ (s [on | | {owon sblcsammmssaton (g embuy) [Evoior | Foron ptc s e ety [Emony [ mwmw pov [\nS N O I N e e GO = G R A EICTE (R I R\nAmbassade) Ambassade)\nT L B e < S I 230 1 VA I I S\nN G O I e e O i L R A I S I R\nambasciata) ambasciata)\nB0 (e [on | | Jswepweww oo o fswpepay feweee [ mwmw pev [\nBo [ [on | | Jwomeswe frew v ooomwe | [ mwmw pev [ |\nB0 [ [on | | Jevwwedwen feama o |eowmeGewbowt G [ mww pov [\nBo o [on | | Jsomwmae e [t e | [ mwmw pev [\ne [ Jon | | e feow o e [ mwmw pev [\n[ Jon | | e frew o e, [ mww pev [\ne [ Jon | | fwme e e feww, [ mww pev [\ns fowwa Jon | | s e [ eewwe [ mwmw pev [\nT T I I T T o T T A AT (R i i\npore fsweiws Jou [ ] |ewwiemsesrmare frewn o [ewesepsiecomee fewewes | [menw wo feee Jaeeso [BGeSn |\npore fswerws Jon [ | |weeederecommaovnenamen fooman oo [weewrsotontorsunonomen s vensen | [meneo mo fees Jweeoso [REeen |\nN T N I e e O R (e N I [ N i\nN L O e [ . 2 1 A I I BN\nB0 (s [on | | {romooistonce s ovediraon [Frowh [ | romcton dol CotedbeionGodoion [ Twmrw pov [\nN L . O e T (. S T 2 L AN A I SN\n[BX0h (s [on || wrminsiudons el Comdorons [Walar 1| Anibions ®he Gt Goredomie [ Twmrw pov [\nR L . I L 21 L A I I S\nR L . Y B o B e e I 210 1 A N A S\ni G C I N i i SO i o A I S I R\n(GmbH) (GmbH)\ne [oma Jon | | om0 [t Jsomommmmeee) foa [ mwew pev [\nR G N A N G N s I A il T I I\nR G O I I e () CO i I N CICTE S I\nR G R I e o O il IR I X S I I\nN T O O s O i AN A I (T I\nA L I I 1 S L 123 1 A A I B\nT L I I Y Y 210 L AN A I BN\nA L I L (. . 23 L AN A I B\nA L I I L T L L Y 2 L A AN I B\nL . O o s I 12 L A AN I B\nL . A I L . T L 230 1 A N I B\nL O L (. S L 230 1 AN I I B\nL O T L [ L 230 1 AN I I B\nI L . I I T S L 230 L A Y I B\nI L . I Y . L 230 L A I I R\nI L . O (= S 20 L A S I BN\nI L O . L L . 23 L AN A I B\nI L . O L s 230 L AN I I B\nI L . I I L (= L S 123 LA I I B\nBN (s [on | | [orereencestres fGman oo [ Ureremendostunder JorUmws [ wwrw pov [\nI L . I L L L L L S 123 LA S I SR\no (s Jon | | gy oo or Jimeopesy lwgeny [ mwmw pov [\no (s [on | | Jscomeoncommate Jrewn 1 JSoomeencommmob Sovencomnwae [ wwrw pov [\no (s Jon | | Jommmaesteowt G oo | ommmgearat o [ wwrw pov [\n[Co (s Jon | | Jscomanmoonitn i [t Jsoomammcoonman Soomwoonaras [ wwrw pov [\noree (s _[on | | |viorotogmsior Jevos or [ reratonaogenion oy [ wwrw pov [\nPz (s _[on | | Joomsorlormowe Jrewn [r oo Plomatorde O Wowboraes [ mwrw pov [\noPee (S _[on || |vioratome Ogmmaion e oo | reratonle Oton [ Ogmaaton [ wwrw pov [\nN L o I I L L LI (S 123 LA I I S\nEoe [ [on | | Jrwweopomon oo o Jrbccoporr _—ewbeopomon [ wwrw pov [\nR I R I IO . T (. S 1253 LA S A S\nN G O I R e i O i G R CICTE R I\n(Verwaltung) (Verwaltung)\nN G O I il R O e il el R I S I R\nFN (s o | | Jctnawonmemior Jeom or | Conoralammior Gt [ mwew pov [\nR L . O L L 12 LA A I SN\nR L . O L Y (. S L 123 LA A I SN\nR L e O LT L L L . S 123 LA S I SN\nFio e Jon | | e e e fw [ wewwe pov___ [ |\nFio o Jon | | e eow e fow | weee pov___| | ]\n61/83\n","contentLength":3092,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:05:17.012Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-20275-entity-legal-forms-code-list/2021-10-21-elf-code-list-v1.4.1.pdf","content":"Fior [swows o [ [ o — feew [ s o r meee oy [T T\nI ) I L S 23 L A I I I\nR T ) I 2 S 23 L= A I I I\nN ) I . S 2 L= A I I I\nN T ) I S S S 23 L= A I I I\nFe [oweows Jon [ [ Jow T fw 7 ————————————— mwes pev [ T\nN e I . - L L S 121230 L= A I I I\nN e I L L (L S 121330 L= A I I I\nN e I T 2 L T (L S 121230 L= A I I I\nN e I L L L L S 121230 L= A A I I\nN L e I L - L S 121230 L= A I I I\no fowerws Jon [ | [aeeeeleedoeesseen free o [aeeeedeessessese o b fpeeper [ ]\nN L e I . . L S 121230 LA I I\no foweies Jou [ ] [leeemerwwmchense Jew o [Eeewesieseesede | @ fwewepen [ ] ]|\nA L e I (= . L L S 12130 L= A I I I\nA T e I = e L T e N 121530 L= A I I\nA L e I L 2 L . S 121230 L A I I I\nA T e I Y L L L L S 121230 L= A I I\ne T O I I = G N AT U CE N T\nabroad registered in the commercial registrer abroad registered in the commercial registrer legal form\nSR I O I B v e GO e e I I (R CE N N\n2 llétranger inscrite au registre de commerce 4 llétranger inscrite au registre de commerce legal form\ni G G I B - N N GO = N L B T (R N O\nHandelsregister eingetragen Handelsregister eingetragen legal form\nSR R O I B = P e GO T e A T (R CE N N\nallestero iscritta al registro di commercio allestero iscritta al registro di commercio legal form\ne e I e e L 2 S 12130 L A A I I\n5% [waorrg Jo# | [Foowmtowroncommagaes e - rowreions o mmmorotbes ——JPoowaion T Jawrw pev [T\ne T I L S L S 121230 L A A I I\ne T e I L L [ e (. S 121230 L A A I I\n50 [owaortrg Jon T Tlowaimbooomoy e Jor — Joooamiboomy ———— Jloopwio T fawnrw pev [T\nI T I (. e T S S 121230 L A I A I\n(50 [Swaorrg [o# | [UnionohmondorGomende ———Goman oo [UrtonshmendorGomonds ————Jof UniGomange T Jawrw ev [T\n50 [owaorrg Jon | Tios pobbbwcomnsk il - ioooa itioacomae ———— Tmpplboomnae T Jawrw ev [T\nN T e I (Y T L T Y S 121230 LA A I\nT e R I (e e T N 121230 LA I I\nN G O I I e N GO T e R B I S I\n(Unternehmen) (Unternehmen)\nN L o I e L L L L N 12130 L= A I I\nA L e I (T - 2 . S 121530 L= A I I I\nA L e O T s L o N 121530 L= A I I\nA T e O L 2 L L S 121530 L= A I I I\nA T e I L L L T o S 121530 L= A I I I\nI T e I (L S L - S 121530 L= A I I I\nI e I L . - S S 121230 L= A I I I\nL ) I L 2 L S 121330 L= A I A I\nI e I L L - S S 121230 L= A I I I\nR i N N N et Y GO vl i R N I (T I I\nares shares\nL e e I (L e T L A 121530 L A I I\nL e e I T e S 121530 L A I I\nT T e I T L L T L S 121330 L= A I I I\nG52 [owmowa Jon T [ Joowae —— eww o Jowwe 7 ———————————p fmeww pev [\ne T e I T L - S 121330 L= A I I I\ne L e I (= 2 T S 121330 L= A I I I\nR L e O T L L - S 121230 L= AN I I I\ne e T N O (e T G o R N T (I N st\nN e I I I e e O e N N T (R N O\nN T N I L e e e e N TN (N C N st\noo fsweiws fou | ] feeesswwen e fo eeeswen feess | [wwnw wo fueee Jaeeso [RRGReSe |\nN L e I e e L o N 121230 L AN I I I\nA G O I N e e GO i i A I R I I\ncollectifs. collectifs.\nN CEEET GO I e I G i e R T S I\npitalaniagen Kapitalanlagen\nI G O I N i e O = i e R I O I\ncollettivi di capitale collettivi di capitale\nthis is nota\ngal form of the.\nmain company itself\n62/83\n","contentLength":2959,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:05:17.012Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-20275-entity-legal-forms-code-list/2021-10-21-elf-code-list-v1.4.1.pdf","content":"This is nota\n» stré . i st . separate legal form;\nUNA9 Swizerland [ CH Sucoursale suisse enregistrée auregistre e f¢yo oy ir Succursale suisse enregistrée au registre de. g o0 g 2017-11-30 | INAC deletion 20200610 |a branch has the\nlegal form of the\nmain company tself\nThisis nota\n. - , . - , legal form:\n. Schweizerische Zweigniederlassung im Schweizerische Zweigniederlassung im . . separate leg ;\nUNA9 Switzerland | CH Handeloregrcter mocmaen German Handeloragrcter emoShaen Zweig. HR 2017-11-30 [INAC deletion 2200610 a g:?grnmngfs e\nmain company tself\nThis is nota\n; . stro di ; . stro di separate legal form;\nUNA9 Swizerland [ CH Sucoursale svizzera regisirata nel registro di ;i it Succursale svizzera regisirata nel registro di (g o0 g 2017-11-30 | INAC deletion 20200610 |a branch has the\nlegal form of the\nmain company tself\n- Sociélé dinveslissement a capital variable Sociélé dinveslissement a capital variable y\nT R P Sz YR P\n- Tnvesimenigeselischaft mit variablem Kapital Tnvesimenigeselischaft mit variablem Kapital y\nN R N p— s pryERTo P\np Societa di investimento a capilale variabile ! ; Societa di investimento a capilale variabile -\nxJot Switzerland | CH -- et S Italian it e 2017-11-80 [ACTV\nN T L I I . T Erveors ravRTe | mws v [ | ]\nW s W [ | [weeesmwiemes o & esporsaoTE e S mes ov [ ]\nWa e W [ [ Jeemememe Jrew [ [eemmewe o [ Tmws v [\no e m [ ew e v Jew [ | Tawoe v [ | ]\nT TR R I I [ o 37 (D e ov ]\nIS T L N S, [ Fomanat s S 12 A Y I I\nG AT R N N T D) D I A (LS I S\nMv4s United Arab {5 Sole Proprietor English Sole Proprietor 202006-10 | ACTV\nEmirates\nonly 1o be used for\n! entlties incorporated\n4VPM United Arab | op Abu Dhabi AE-AZ Incorporated Cell English Incorporated Cell 202006-10 | ACTV under the\nEmirates regulations of the\nAbu Dhabi Global\nMarket (ADGM)\nonly (o be Used for\nentlties incorporated\nUnited Arab . ; . . under the\n6HOF gnited Ar AE Abu Dhabi AE-AZ Open Ended Investment Company English Open Ended Investment Company 20200610 [ACTV e s ofthe\nAbu Dhabi Global\nMarket (ADGM)\nonly 1o be Used for\n! entlties incorporated\n9158 United Arab | op Abu Dhabi AE-AZ Private Company Unlimited without Shares | English Private Company Unlimited without Shares 202006-10 | ACTV under the\nEmirates regulations of the\nAbu Dhabi Global\nMarket (ADGM)\nonly (o be Used for\n! entlties incorporated\n9UeF United Arab | o Abu Dhabi AE-AZ Limited Liability Partnership English Limited Liability Partnership 2020-06-10 | ACTV under the\nEmirates regulations of the\nAbu Dhabi Global\nMarket (ADGM)\nonly 1o be used for\nUniod Arab et incorporated\nnited Aral \" N i N under the\nB13W gnited Ar AE Abu Dhabi AE-AZ Restricted Scope Company English Restricted Scope Company 20200610 [ACTV s of the\nAbu Dhabi Global\nMarket (ADGM)\n63/83\n","contentLength":2748,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:05:17.012Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-20275-entity-legal-forms-code-list/2021-10-21-elf-code-list-v1.4.1.pdf","content":"only to be Used for\n! entlties incorporated\nFE4G United Arab | 5 Abu Dhabi AE-AZ Protected Cell Company English Protected Cell Company 2020.06-10 |ACTV under the\nEmirates regulations of the\nAbu Dhabi Global\nMarket (ADGM)\nonly o bo used for\nentities incorporat\nUnited Arab . | ' i : i i g under the\nGUSE United Ar AE Abu Dhabi AE-AZ Public Company Limited by Shares English Public Company Limited by Shares 2020.06-10 |ACTV under e of tho\nAbu Dhabi Global\nMarket (ADGM)\nonly 1o be Used for\n! entlties incorporated\nH8MU United Arab | op Abu Dhabi AE-AZ Limited Partnership English Limited Partnership 202006-10 | ACTV under the\nEmirates regulations of the\nAbu Dhabi Global\nMarket (ADGM)\nonly 1o be Used for\n! entlties incorporated\nHECG United Arab | Ap Abu Dhabi AE-AZ General Partnership English General Partnership 20200610 [ACTV under the\nEmirates regulations of the\nAbu Dhabi Global\nMarket (ADGM)\nonly 1o be Used for\n! entlties incorporated\nKAEM United Arab | 5 Abu Dhabi AE-AZ Private Company Unlimited with Shares English Private Company Unlimited with Shares 2020.06-10 |ACTV under the\nEmirates regulations of the\nAbu Dhabi Global\nMarket (ADGM)\nonly 1o be Used for\n! entlties incorporated\nLz3H United Arab | 5 Abu Dhabi AE-AZ Close Ended Investment Company English Close Ended Investment Company 2020.06-10 |ACTV under the\nEmirates regulations of the\nAbu Dhabi Global\nMarket (ADGM)\nonly o bo used for\nentities incorporat\nUnited Arab . | \\ i : \\ i g under the\nosE2 United Ar AE Abu Dhabi AE-AZ Private Company Limited by Shares English Private Company Limited by Shares 2020.06-10 |ACTV under e of tho\nAbu Dhabi Global\nMarket (ADGM)\nonly 1o be Used for\nentlties incorporated\nUnited Arab . . (nder the\nPNX6 United Ar AE Abu Dhabi AE-AZ Incorporated Cell Company English Incorporated Cell Company 2020.06-10 |ACTV e s of tho\nAbu Dhabi Global\nMarket (ADGM)\nonly o bo used for\nentities incorporat\nUnited Arab . | \\ i : \\ i g under the\nR2YL United Ar AE Abu Dhabi AE-AZ Private Company Limited by Guarantee English Private Company Limited by Guarantee 2020.06-10 |ACTV under e of tho\nAbu Dhabi Global\nMarket (ADGM)\nonly 1o be Used for\n! entlties incorporated\nVKzD United Arab | 5 Abu Dhabi AE-AZ Foundation English Foundation 2020.06-10 |ACTV under the\nEmirates regulations of the\nAbu Dhabi Global\nMarket (ADGM)\nonly 1o be Used for\nentlties incorporated\n: under the\n375p gnited Arab - pg AE-DU Foundation English Foundation 20200610 |ACTV regulations of the\nDubai International\nFinancial Centre\n(©IFC)\nonly 1o be Used for\nentlties incorporated\n' under the\n3P03 United Arab | op AE-DU Open Ended Investment Company English Open Ended Investment Company 202006-10 | ACTV regulations of the\nEmirates Dubai International\nFinancial Centre\n©IFC)\nonly 1o be Used for\nentlties incorporated\n: under the\n4600 gnited Arab - pg AE-DU Public Company Limited by Shares English Public Company Limited by Shares 202006-10 [ACTV regulations of the\nDubai International\nFinancial Centre\n(©IFC)\nonly 1o be Used for\nentlties incorporated\n: under the\n70E0 gnited Arab - pg AE-DU Private Company Limited by Shares English Private Gompany Limited by Shares 202006-10 [ACTV regulations of the\nDubai International\nFinancial Centre\n(©IFC)\nonly 1o be Used for\nentlties incorporated\n: under the\nAIRO gnited Arab - pg AE-DU Limited Partnership English Limited Partnership 20200610 |ACTV regulations of the\nDubai International\nFinancial Centre\n(©IFC)\nonly 1o be Used for\nentlties incorporated\n: under the\nF3UE gnited Arab - pg AE-DU General Partnership English General Partnership 20200610 |ACTV regulations of the\nDubai International\nFinancial Centre\n(©IFC)\nonly 1o be Used for\nentlties incorporated\n: under the\nRWX4 gnited Arab - pg AE-DU Protected Cell Company English Protected Cell Company 20200610 |ACTV regulations of the\nDubai International\nFinancial Centre\n©IFC)\n64/83\n","contentLength":3848,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:05:17.012Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-20275-entity-legal-forms-code-list/2021-10-21-elf-code-list-v1.4.1.pdf","content":"only 1o be used for\nentities incorporated\nUnited Arab e Labil ' ! e Liabil ' under the\nV2PA Bt AE AE-DU Limited Liability Partnership English Limited Liabilty Partnership 20200610 | ACTV requlations of the\nDubai International\nFinancial Centre\n(DIFC)\nonly 10 be sed for\nentities incorporated\nUnited Arab ' under the\nVTP Bt AE AE-DU Close Ended Investment Company English Close Ended Investment Company 20200610 | ACTV requlations of the\nDubai International\nFinancial Centre\n(DIFC)\nonly 10 be sed for\nentities incorporated\nUnited Arab ; : i i ! . under the\nFHRL gnited Ar AE Ras Al Khaimah | AE-RK Segregated Portfolio Company English Segregated Portiolio Company 20200610 | ACTV e s fthe\nRAK International\nCorporate Centre\nonly 10 be sed for\nUniod Arab et incorporated\nnited Aral i imit i imi under the\nGosF gnited Ar AE Ras Al Khaimah | AE-RK Company Limited By Guarantee English Company Limited By Guarantee 20200610 | ACTV Eothions ol he\nK International\nCorporate Centre\nonly 10 be sed for\nentities incorporated\nUnited Arab f \" : ’ under the\nHNPH gnited Ar AE Ras Al Khaimah | AE-RK Restiicted Purposes Company English Restricted Purposes Company 20200610 | ACTV Eothions ol he\nK International\nCorporate Centre\nonly 10 be sed for\nentities incorporated\nUnited Arab ; : mi i mil . under the\nQIVN gnited Ar AE Ras Al Khaimah | AE-RK Company Limited By Shares English Company Limited By Shares 20200610 | ACTV e s fthe\nRAK International\nCorporate Centre\nonly 10 be sed for\n! entities incorporated\nUAES gnited Arab - f pg Ras Al Khaimah [AE-RK RAK Economic Zone Company English RAK Economic Zone Company FZLLC 20210928 |ACTV under the\nmirates feguitions ofthe\nK Economic\nZone\nonly 10 be sed for\nentities incorporated\nUnited Arab ; : imil i imil . under the\nz3P8 gnited Ar AE Ras Al Khaimah | AE-RK Unlimited Company English Unlimited Company 20200610 | ACTV e s fthe\nRAK International\nCorporate Centre\nUniedKingdom[GB | [ [Communiyineres Gompany Englsh [on [ Communily Intorest Gompany cc 000000000000 [emwor®s Jaowv 1 ]\nincluded by mistake;\nthis Is a company\n1We2 United Kingdom | GB Oversea Company English Oversea Company 201907-05 |INAC deletion 20200610 |formed outside of\nthe UK, witha\nforeign'legal form\nnew legal form per\n1 JanuarK92021 to\n468Q United Kingdom | GB United Kingdom Societas English United Kingdom Societas UKS 202109-28 | ACTV replace i\nEuropean legal form\nSocietas Europaea\napplies only 1o\nentities of the form\nconcerned whose\njurisdiction of registered office is\nformation and situated in Northem\n4A3) United Kingdom | GB Northern Ireland Company English Northern Ireland Company 201907-05 | ACTV country sub- |202006-10 [ reland. SO has\ndivision code removed the\nremoved Country sub-division\noodesrz/ISO 3166-2)\nfor the diflerent\nparts of the UK\ncode replaced by\nBEES. ISO has\nremoved the\n55MA United Kingdom | GB Cwmni Cyfyngedig Cyhoeddus Welsh oy Cwmni Cyfyngedig Cyhoeddus cceiec.c. 2017-11-30 | INAC deletion 20190705 | Country sub-division\ncodes (ISO 3166-2)\nfor the diflerent\nparts of the UK\nGreroon|G5 | [ [reac s I O R | e lev 1 ]\napplies only 10\nchbtos of the form\nconcerned whose\njurisdiction of registered offce is\nformation and situated in Northem\nSFRT United Kingdom | GB Other Type of Company (in Northern reland) | English Other Type of Company (in Northern Ireland) 201907-05 | ACTV country sub- |202006-10 [ reland. ISO has\ndivision code removed the\nremoved Country sub-division\ncodes (ISO 3166-2)\nfor the diflerent\nparts of the UK\n) S O A e Y A A 1173 . A N A B\n65/83\n","contentLength":3510,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:05:17.012Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-20275-entity-legal-forms-code-list/2021-10-21-elf-code-list-v1.4.1.pdf","content":"applies only to\nentities of the form\nconcerned whose\nregistered office is\nsituated in Northem\njurisdiction of reland. 150 has\nformation and '&’“O‘l’e : divisi\n7vvz United Kingdom | GB Co-operative Society (Northern Ireland) English Co-operative Society (Northern Ireland) Co-op 20190705 |ACTV country sub- 2020-06-10 un ’{ Sub-division\ndivision code codes (ISO 3166-2)\ns for the different\nparts of the UKISO\nhas removed the\nCountry sub-division\ncodes (SO 3166-2)\nfor the difierent\nparts of the UK\nUrisdRnggon [68 || [reummocomany B Jon [ Aosurarcs Gompary | ewew pew_[ [ T |\nUniedKngdom [68 || [FoyaCrarer Gompay Evgisr _Jen | Foya Ot Gormpary | ewow pow_[ [ [ ]\nThis is a duplication\nA2X8 United Kingdom | GB Unregistered Company English Unregistered Company 20190705 |INAC deletion 2020-06-10 ‘éf.}r':‘%;’n“’e(gfi:e’ed\ncode QONS)\napplies only 1o\nentities of the form\ncortection of cancarned whase\nB6ES United Kingdom | GB Cwmni Cyfyngedig Cyhoeddus Welsh oy Cwmni Cyfyngedig Cyhoeddus cceccec. 201741-30 [ACTV code forlegal |2019-07-05 registered effice is\nform and choose to use\nthe Welsh language\nversion\nuniedKngdomfGB T [ [Frendly Society English fen [Friendly Society 0 [Jeoworos Jacow I N B\nhis is a duplication\nwvate Limi ’ wvate Limi i of the Private\nC605 United Kingdom | GB Private Limited by Shares (Section 30 English Private Limited by Shares (Section 30 201907-05 | INAC deletion 20200610 | Limited by\nExemption) Exemption) u\nuarantee company\n(ELF ot 4GU)\nincluded by mistake;\nthis is a branch in\nthe UK of a foreign\nCDOT United Kingdom | GB UK Establishment English UK Establishment 2017-11-30 | INAC deletion 2020-06-10 company; such a\nbranch should have\nthe ELF code of the\nforeign company\nitself\nUiedkgeon[68 || [eubm oo T O | mwew pew__[ [ [ ]\ns ey is now\ne ) ) . ' ) ) ’ ' nown ada\nFVGZ United Kingdom | GB Industrial and Provident Society English Industrial and Provident Society 2019-07-05 | INAC deletion 2020-06-10 Fegtord Sorety\n(ELF code XLZV)\npp United Kingdom | GB Private Limited by Guarantee/No Share Engiish Private Limited by Guarantee/No Share 0190705 |ACTV\nCapital Capital\nUredrgeom [G8 || Prte Lovea Gompary B Jon | Pt e Gy Tt Limked mwmw ew [\napplies only o\nanitios of the form\ncorrection of concerned whose\nHOPO United Kingdom | GB cyfyngedig Welsh cy cyfyngedig cyfeyf. 2017-11-30 | ACTV code forlegal |2019-07-05 registered office is\ngoce situated in Wales\nand choose to use\nthe Welsh language\nversion\nChange in UK\ne Limited-Liabili i Limited-Liabili legisiation; replaced\nA European Public Limited-Liability Company ' European Public Limited-Liability Company ) ' 9| ; repl\nHHYT United Kingdom | GB (Sochtas Europaca) English (Socitas Europaca) SES.E. 2017-11-30 |INAC deletion 2021-01-01 by the new legal\nKingdom Societas\nhis is a duplication\nHX6D United Kingdom | GB Private Limited English Private Limited 20190705 |INAC deletion 2020-06-10 of the Private\nLimted Company\n(ELF code HOPO)\n0% [Umedkmgeon (G | | [io e I CON (I I LF i e Lited Parers mwmw ew T\n. 1SO has removed\njurisdiction of the Couniry sub-\nformation and division codes (ISO\nIYXU United Kingdom | GB Community Benefit Society English Commurity Benefit Society BenCom 2019-07-05 ACTV country sub- |2020-06-10 3166-2) for the\ndivision code different parts of the\nremoved UK\napplies only 1o\nentities of the form\nconcerned whose\njurisdiction of registered office is\nformation and situated in Northem\nJTCO United Kingdom | GB Credit Union (Northern Ireland) English Credit Union (Northern Ireland) 2019-07-05 ACTV country sub- |2020-06-10 reland. ISO has\ndivision code removed the\nremoved Country sub-division\noodesrz/ISO 3166-2)\nfor the different\nparts of the UK\napplies only to\nanitios of the form\nconcerned whose\njurisdiction of registered office is\nformation and situated in Scotland.\nNBTW United Kingdom | GB Scottish Partnership English Scottish Partnership 2019-07-05 ACTV country sub- |2020-06-10 1SO has removed\ndivision code the Country sub-\nremoved division codes (ISO\n3166-2) for the\ndifferent parts of the\nUK\n66/83\n","contentLength":4042,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:05:17.018Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-20275-entity-legal-forms-code-list/2021-10-21-elf-code-list-v1.4.1.pdf","content":"applies only to\nentities of the form\nconcerned whose\njurisdiction of registered office is\nformation and situated in Scotland.\nSTX7 United Kingdom | GB Scottish Charitable Incorporated Organisation | English Scottish Charitable Incorporated Organisation 2019-07-05 ACTV country sub- |2020-06-10 1SO has removed\ndivision code the Country sub-\nremoved division codes (ISO\n3166-2) for the\ndifferent parts of the\nUK\nGode replaced by\nHOPO. ISO has\nremoved the\nTo1R United Kingdom | GB cyfyngedig Welsh oy cyfyngedig cyfieyt. 2017-11-30 |INAC deletion 20190705 | Country sub-division\noodesrz/ISO 3166-2)\nfor the different\nparts of the UK\nUniedKingdom[GE [ | [ProieciedGell Gompany Englsh e [Protecied Gell Gompary 0 [Jeoworos Jaow I I B\nThis is a duplication\nPrivate Limited by G /No Sh Private Limited by G /No Sha fnhegg;ate\nod Ki rivate Limited by Guarantee/No Share : rivate Limited by Guarantee/ re y ; 06 imite\nTYXK United Kingdom | GB Capital (Use of Limited Exemption) English Capital (Use of Limited Exemption) 201907-05 [ INAC deletion 2020-06-10 Guarantee / No\nShare Capital (ELF\ncode G12F)\nchange in UK\nlegisiation; replaced\nUBR9 United Kingdom | GB European Economic Interest Grouping English European Economic Interest Grouping EEIG 20171130 |INAC deletion 2021-01-01 Dy the new legal\nKingdom Economic\nInterest Grouping\napplies only 1o\nentities of the form\nconcerned whose\njurisdiction of registered office is\nformation and situated in Northem\nuTYe United Kingdom | GB Community Benefit Society (Northern Ireland) | English Commurity Benefit Society (Northem Ireland) BenCom 2019-07-05 ACTV country sub- |2020-06-10 reland. ISO has\ndivision code removed the\nremoved Country sub-division\ncodes (SO 3166-2)\nfor the difierent\nparts of the UK\nU Finggom| 68— ||| oot Compury i Varbe Gapl_[Engish—[on [ wosiment Gompay wh Verbo G | [mwom ov [ [ 1 |\nnew legal form per\n1 January 2021 to\nVYF8 United Kingdom | GB United Kingdom Economic Interest Grouping | English United Kingdom Economic Interest Grouping | UKEIG 2021-09-23 [ACTV replace the\nEuropean legal form\nEuropean Economic\nInterest Grouping\n— 1SO has removed\njurisdiction of\nformation and the Country Subl's o\nwBQuU United Kingdom | GB Credit Union English Credit Union 20190705 |ACTV country sub- 2020-06-10 3'1\"('55&’2“ codes (\ndivision code 166-2) for the\ni different parts of the\nUK\nCode replaced by\nZ0Ev. 180 has\nremoved the\nWJOA United Kingdom | GB Partneriaeth Atebolrwydd Cyfyngedig Welsh oy Partneriaeth Atebolrwydd Cyfyngedig PAC 2017-11-30 |INAC deletion 20190705 | Country sub-division\ncodes (SO 3166-2)\nfor the difierent\nparts of the UK\nT ) I N L T B [or —[Regentsoony 1 e v [ T T ]\nGnod Kngdo[G6 || Ui Cabiy Parivorsty Engish oG iy Pt T Tty paiersnp L Liied iy Parersy I 2 1200 o I I R\napplies only o\nanitios of the form\ncorrection of concerned whose\nZO0EY United Kingdom | GB Partneriaeth Atebolrwydd Cyfyngedig Welsh cy Partneriaeth Atebolrwydd Cyfyngedig PAC 20171130 |ACTV code forlegal |2019-07-05 ;?J'a[g\"fin “’N;gs's\nform and choose to use\nthe Welsh language\nversion\n— 1SO has removed\njurisdiction of\nformation and the Counry sub\n726G United Kingdom | GB Co-operative Society English Co-operative Society Co-op 2019-07-05 | ACTV country sub- | 2020-06-10 division codes (IS0\ndivision code 166-2) for the\ns different parts of the\nUK\n! enity legal forms\n3800 United States of | g Federal Savings Association English Federal Savings Association FSA 2021-09-28 | ACTV incorporated on\nAmerica federal US level\nUnited States of entity legal forms\n3MM4 roiiy us Edge Act Corporation English Edge Act Corporation 2021-09-23 [ACTV incorporated on\nfederal US level\n: enity legal forms\n62vJ Ynited States of | yg National Bank English National Bank NA 202109-23 | ACTV incoporated on\nfederal US level\n: enity legal forms\n27ER Ynited States of | yg Mutual Savings and Loan Holding Company | English Mutual Savings and Loan Holding Company 202109-23 | ACTV incoporated on\nfederal US level\n67/83\n","contentLength":3968,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:05:17.018Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-20275-entity-legal-forms-code-list/2021-10-21-elf-code-list-v1.4.1.pdf","content":"N i O e e B e < i A A R\nT O e e O O e S . B S E I\nO i O e e e ez S A - A A R\nO o e N O 22 B I\nN - O o o B e 2 A A R\nN O o o i O A A . B S O B\nR i O e B N A i -l i\ni B e N O S 2 i S R I\nG - O o B o - A N\nS O B e N O o A 2 B R I\nI i O o O e B o ccc A R\nO D e O O e 2 A . B B I\nS O o L e O e S - I I\nT i O e B e e A - -l S\nO e e N O A A . s o\nR i O e B N 7 A A A N\nT O O e N O o S 2 B B I\nN i O e e B O . i A R\nN O e e o O e B S S R I\nN - O e e B N . i A A R\nO e e s e 1 R I\nG i O e e e e . i A A I\nT O e e o O e A R A\ne 5 O e o B N . i A A\nT O e e i O o A S R I\no i O O e B o . A A\nT O e N O A R I\no i O e O o e e . A A R\nN O O e N O S B R I\nN -5 O e e B N . A R\nT O O 55t O O s A 2 i N R N\nS O e L e O e 1) A I\nN - O B 5 P B O =5 oo A . A A A\nN O e e N O ) S 2 s S E I\ni O e e B e A i I R\nR O e s O e A .2 B I\nUnited States of , ' . correction of correction of\nS il O el el e ol R e I R e S\nR i O N O e e O e N O e G - S\nJREU Wnited $ us Arkansas US-AR Commercial Bank English Commercial Bank 20210923 |ACTV country 2021-1021 | country subdivison\nsubdivison code code\nG i O e e e e . i S A S\nI O e e o O e e A . B N R I\nN i O e e B e e N N N\nN i L B O o .2 S B I\nN i O O O e B o 2 S A R\nN T O e N O D 2 A . i RO N\n68/83\n","contentLength":1219,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:05:17.018Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-20275-entity-legal-forms-code-list/2021-10-21-elf-code-list-v1.4.1.pdf","content":"gm‘;figfiawsof US-CA For-Profit Corporation Close English For-ProfilCorporationClose Corporation;Company; Incorporated;incorporation;Limited CorpiCosinciLd _ ACTV --_\n\nBADE United States of | ;5 California USCA Nonprofit Common Interest Development English Nonprofit Common Interest Development 20200610 | ACTV\nAmerica Association Association\n\ngg‘;fif‘a‘esof us-ca For-Profit Corporation General Stock Engiish For-ProfilCorporalionGeneralSlock Corporation;Company; Incorporated;incorporation;Limited:CorpiCosinciLd _ ACTV --_\nUnited States of iforni - i \"\n\nsQ7B America us California US-CA General Partnership English General Partnership 2020-06-10 |ACTV\n\nUnited States of Us-co For-Profit Public Benefit Corporation Engiish _ For-Profit Public Benefit Corporation Gorporation;Company;Incorporated;Limited:CorpCoinciLid _ ACTV --_\nUnited States of g - ted Liabili : ted Liabili limited liability company;ltd. liability company limited liability co-jtd. liability ]\n\nLioT Wnited $ us Colorado Us-co Limited Liability Company English _ Limited Liability Company e e, o 202006-10 |ACTV\n\nUrited States of us-co Limited Liabilty Limited Partnership English _ Limited Liabilty Limited Partnership Limited;Company,L.P.iLpiCo. L L.L.P.iLIpLTD.R.LLLP.ALLLP _ ACTV --_\nUnited States of y i i i -Co.\n\nJKOT America us Connecticut us-CT Stock Corporation English Stock Corporation Inc.;Co.;Corp. 2020-06-10 |ACTV\nUnited States of i ¥ imi iabili i imi iabilit LLCL.L.C;, Limited Liability Co.;Ltd. Liability Company;Ltd. Liabili .\nUnited States of\n\n. Fro ___ e ---\n\n69/83\n","contentLength":1556,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:05:17.018Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-20275-entity-legal-forms-code-list/2021-10-21-elf-code-list-v1.4.1.pdf","content":"United States of District of y Limited Partnership (including Limited Liability | ¢ Limited Partnership (including Limited Liability e - y Jurisdiction oy Use correct name of\n74l America us Columbia usbe Limited Partnership) English Limited Partnership) LLLPLLLPRLLLPALLLP 201741-30 | ACTV corrected 2021:0928 5 icdiotion\nNS United States of | g District of US00 Business Corporation (icluding professional | gngiish Business Corporation (ncluding Professional | Gor -inc.1Co.Ld7.C..Chtd 0171130 | ACTY Jurisdiction 20210923 | Use correct name of\nAmerica Columbia corporation) corporation) corrected jurisdiction\nPGV United States of | g District of us-DC Limited Cooperative Association English Limited Cooperative Association L.C.A.;LCA:Co-0p.;Coop.:Co-0p;Coop:Assoc. Assoc;Assn. ;Assn 2017-1130 |ACTV jurisdiction 2021-09-23 use correct name of\nAmerica Columbia corrected jurisdiction\nUnited States of District of g : - Jurisdiction oy Use correct name of\nTJev United States of | ;g District of us-DC Limited Liability Partnership English Limited Liability Partnership LLP.RLLP.LLPRLLP 2017-11-30 |ACTV jurisdiction 2021-09-23 use correct name of\nAmerica Columbia corrected jurisdiction\nUnited States of District of g Limited Liability Company (including : Limited Liabilty Company (including LoLc.oH . - Jurisdiction oy Use correct name of\nVNU America us Columbia usbe profoasionm LG e e English protoasionm LY S ey s LLGLLGLCLGP.LLCPLLC 201741-30 | ACTV corrected 2021:0928 {5 ciotion\nUnited States of District of y \" - - \" - y Jurisdiction o0, Use correct name of\nUnited States of - - - - - -\nS7VR Ynited § us Georgia US-GA Nonprofit Corporation English Nonprofit Corporation 20200610 [ACTV\n9827 United States of | | Hawaii US-HI Service Mark English Senvice Mark 2019-07-05 | INAC deletion 2021-09-23 not a separate legal\nAmerica 9 entity form\nUnited States of \" g ; : ; gy\n9G80 Ynited § us Hawaii USHI Savings Bank English Savings Bank 20210923 [ACTV\nUnited States of \" \" - \"\n838Q Ynited § us Hawaii USHI General Partnership English General Partnership 201907-05 [ACTV\nDX2N United States of | g Hawaii US-HI Nonprofit Corporation English Nonprofit Corporation Corp.Ltd.;lnc. 2019-07-05 | ACTV textadjusted |2021-09-23 adjusiment of name\nAmerica of legal form\nUnited States of \" \" - \"\nFTNW Ynited § us Hawaii USHI Cooperative English Cooperative Co-op 201907-05 [ACTV\nUnited States of \" y \" - \" T g ’ oy adjusiment of name\nL5B0 United States of | ys Hawaii US-HI Trade Name English Trade Name 20190705 |INAC deletion 2021-09-23 not a separate legal\nmerica entity form\nmerica\nWMTY United States of | ys Hawaii US-HI Publicity Rights Name Registration English Publicity Rights Name Registration 20190705 |INAC deletion 2021-09-23 not a separate legal\nmerica entity form\n70/83\n","contentLength":2785,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:05:17.018Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-20275-entity-legal-forms-code-list/2021-10-21-elf-code-list-v1.4.1.pdf","content":"after 1 May 2019,\nthis legal form is no\n. Einfache Kommanditgesellschaft mit sozialer Einfache Kommanditgesellschaft mit sozialer legislation nger usec for new\nXLEO Belgium BE Ziolsetzing German Ziolsetzung EKGmsZ 20171130 | ACTV hange 2019-07-05 entiies: i sil exists\nestablished before\nthat date\nper 1 Nov 2018\nil il dati legal form abolished\n) Burgerlijke vennootschap onder vorm van Burgerlijke vennootschap onder vorm van legislation g )\nXQzX Belgium BE naamiozs vennootsohan Dutch naamioze vennootschap BVNV 20171130 |INAC ohange 2018-11-01 ;:fi;g:?“rggnfigy\nlegal form R85P\nper 1 Nov 2018\negistation legal form abolished\nXQzX Belgium BE Société civile sous forme de société anonyme | French fr Société civile sous forme de société anonyme [ SC SA 20171130 |INAC ohange 2018-11-01 and automatically\ntransformed into\nlegal form R85P\nper 1 Nov 2018\nwilkechti ; wilkech ; dati legal form abolished\n) Zivilrechtliche Gesellschatt in der Rechtsform Zivilrechtliche Gesellschatt in der Rechtsform legislation g )\nXQzX Belgium BE Giner Aktiengesellschaft German Giner Akliengesellschaft ZRG AG 20171130 |INAC ohange 2018-11-01 ;:fi;g:?“rggnfigy\nlegal form R85P\n- - — - — ] 1 abbreviation ) abbreviation\nViGi [eegun [ | | [Fonwonpmee Foncaton priee FONDPAIY [ e ow ]\nYiGi [eegun [ | | [Pmammn [Goman oo [Prvarsiung s Tmwww fow [ [ ]\nVerW_[Begum [ | | [Europess Cotperateve Vermoohorm __[Duoh [ [ Europese CotpermieweVemooerp__[SC2 [ [wwmw pov | [ | ]\nVW [Begum _[BE | | [Sooeb cooperamecumpaene Socet cooperatve europeenne e | mww fow [ [ ]\nafter 1 May 2019,\nthis legal form is no\n\\egisiation longer used for new\nZOK2 Belgium BE Landbouwvennootschap Dutch Landbouwvennootschap Lv 2017-11-30 |ACTV hange 2019-07-05 entiies: i sil exists\nr entities\nestablished before\nthat date\nafter 1 May 2019,\nthis legal form is no\n\\egisiation longer used for new\nZOK2 Belgium BE Société agricole French fr Société agricole S. Agr. 20171130 | ACTV hange 2019-07-05 entites; til exists\nr entities\nestablished before\nthat date\nafter 1 May 2019,\nthis legal form is no\n\\egisiation longer used for new\nZOK2 Belgium BE Landwirtschaftiiche Gesellschaft German Landwirtschaftiiche Gesellschatt LG 2017-11-30 |ACTV hange 2019-07-05 entiies: i sil exists\nr entities\nestablished before\nthat date\nafter 1 May 2019,\nthis legal form is no\n. Naamloze vennootschap met een sociaal Naamloze vennootschap met een sociaal legislation nger usec for new\nZSFX Belgium BE cogmerk Dutch cogmerk NV SO 20171130 | ACTV ohinge 2019-07-05 entites; til exists\nestablished before\nthat date\nafter 1 May 2019,\nthis legal form is no\n\\egisiation longer used for new\nZSFX Belgium BE Société anonyme & finalité sociale French fr Société anonyme & finalité sociale SAFS 20171130 | ACTV hange 2019-07-05 entites; til exists\nr entities\nestablished before\nthat date\nafter 1 May 2019,\nthis legal form is no\nlegislation longer used for new\nZSFX Belgium BE Aktiengesellschaft mit sozialer Zielsetzung | German Aktiengesellschaft mit sozialer Zielsetzung | AGmsZ 2017-11-30 |ACTV hange 2019-07-05 entiies: i sil exists\nr entities\nestablished before\nthat date\nBD [meme ez || [viommtonaiusress Gompany Engisn __[on | PlomatonalBusress Compary OO mmeew foow [ ]\nAW [meme ez || [UnmieaComay Egidn _[on [ Unimiea Campary 0O mmeew foow [ ]\nCIEN IR - I R EEE R C 0O mmeew foow [ ]\n00 [eeme [z [ | [CompryLmieaby e Engidn _[on [ Company Limteaty Shares 0O mmeew foow [ ]\nGRF feeme [z | | Theoower fege e fRmwr [ | Tfmmoew pov__| [ [ ]\nZ feeme ez | | [Company Limieaty Guraree Engisn ___[on [ Compary Limieaby Guaramee 0O mmeew foow [ ]\nRS [eermia _[aW | | [GempuaComenesimeabySes [egh e [ompedCommnesbmedySes [ [ Tmmoew pov | [ [ ]\nCE_ [eemn W | | [Sempeatc B o [Swnpealic 0O mmeew foow [ ]\n[WGT [eemua oW | [ [Semealmiaramenp B [on [ CwempteaLimieaparnerap 0O mmeew foow [ ]\nOV [memus oW [ | [Vt Company anxi) Engidn _[on [ Watum Company Part ) 0O mmeew foow [ ]\nA5 [eemus [ow | | [Gomdramew B [on [Gempeaparerp 0O mmeew foow [ ]\n[Cvoe [mermun oW || [Coca Compary Limeaby Guarariee___[Evgien __Jon Lol Company Lmteaby Gumrmee [ Tawoen v [ | [ ]\nEUmM_[Berma _[W | | [Tooa Unimiea Company Engisn __[on [ Loca Unimied Compary 0O mmeew foow [ ]\n[ [eermwa __[W | | [Cuorptea Compary Limieaty Gummee _[Egish _[en [ Eompted Company UmteabyGumramee | [ Tmeeew pov | [ [ ]\nWEVS [Berma [ | | [CeerpieaUnimis Company Engish __[on [ Evemptea Unimied Gompary 0 0000 mmeew fow [ [ ]\nWAGS [Bermia __[W | | [Tooa Compary Livieaty Shares Engish __[on [ Looa Compary Limieaby Shares 0 0000 mmeew fow [ [ ]\nUZWe [eemun W | | [Geauc EEE CO 0 0000 mmeew fow [ [ ]\nVPO [eemun W | | [Wouarua Comny Engidn _[on [ Wt Funa Compary 0 0000 mmeew fow [ [ ]\nWRQ [Remuds oW | | [P Oversean Compary Engidn _[on [ Permt Overseas) Compary 0 0000 mmeew fow [ [ ]\nA0 feemun [ew | | [oeremCempamenn Ergish [en | Oveseas (e Parnersie 1 mmww pov_[ | | ]\n8/83\n","contentLength":4853,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:05:17.018Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-20275-entity-legal-forms-code-list/2021-10-21-elf-code-list-v1.4.1.pdf","content":"N 5 D o O o B O e I 28 5l\nN ] B e e B I 2.8 (o i 5l\nN 5 D O e B 2 .8 L S N\nN 5 D o e o B O o IS 8 S N\nN 5] D O o B o I 228 LA S N\nT ] D o e e B O e I 28 A S N\nN 5 D O e e B 2 I .8 L I\nN ] o e e B O e IS 8 B S A\nT 5 D O O Gt B e s I .8 L I\nN 5 O o O e B O e I 8 A S N\nN 5 D e B 1222 I .8 LR S N\nT O L e e B O e I 28 A S A\nR 5 D e e B I .8 LA N\nN ] D e B O e I .8 L S I\nG ] L S e B O IS 28 A S N\nN ] D e e B e S I .8 L A\nN 5 e e o B O o IS 8 S N\nN ] D o B e S 228 L S A\nI O L e o B O o IS 8 S I\nT 5] O O e e B o I 228 L N\nN O S e e B O e e I 2.8 B I N\nCo 5] O o e et B O e I 228 L S I\nN 5 O o e e S B S e I 2.8 A S N\nN 5 D R e e B O e e I 728 L N\ne i S e o B O o I 28 A S N\nN 5 D R e e B e o I 128 LA N\no O S e o B O e I 2.8 B S I\nN 5 D o e e B D I 28 LA N\nN O S e e B O e S I 2.8 R S I\nR 5 D o e B e IS 2.8 L N\nO 5 o e e B O e I 28 A S N\n] D S o e B O e IS 2.8 B N I\nR 5] D o e o B e I 228 L S N\no 5 O S e o B O IS 028 o I\nN 5] D R e e B et T I 28 L A\nN O e e e O e o I 208 B S R\nN 5 D o e e B O e e T I 28 L A\nN ] S e o B O 7 IS 2.8 B N\nN 5 D R e e B O s e I 28 L I\nN O o e o B O o IS 8 o S I\nN 5 D o e e B I .8 L S N\nI O o e B O e I 028 S A\nR S N e O . S - R I I\nG 5 D o e e B O I 8 A S A\n] R O O e B O 2 IS 8 B S N\n71/83\n","contentLength":1223,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:05:17.019Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-20275-entity-legal-forms-code-list/2021-10-21-elf-code-list-v1.4.1.pdf","content":"N ] o e e B O S .8 L S A\nN 5 D O e B O e IS 8 S N\nN 5 D O e o B o I 228 A A\nN ] D O e O 2 IS 8 S N\nN 5] D O e o B e I 228 LA N\nI 5 D o e e B O e 2 I 028 o S N\nR 5 D e e B s I 228 LA S N\no 5 O e e S B O o I 328 A S N\nR 5 D o e e B S 2. I 228 LA N\nT O e L e B O e I 028 S N\nN 5 D e e e B e 3 IS 228 LA I\ne 5 D o O o B O I 228 A S N\nR ] D e e e B e L I 228 LA N\nN ] D e e e B O I 328 A S A\nC ] O o e N O Lo S 2% B N S N\nN ] D e e e B e I 228 LA A\nN ] O o O o B O o S 028 o S N\nN 5] D e e o B e 228 L S A\nT O o L o B O I 028 S N\nN 5] D e e e B e e S 28 L A\nG 5 O e e e B O e e IS 2.8 B S I\no 5 D e e B e e I 28 L I\nG 5 D B e B S S Y IS 2.8 B S\nN 5 D O et B Ot il O 28 T N I\nN O e e T B O e I 2.8 B I\nR 5 D B e e B . I 28 LA N\ne O e e e B O e e I 2.8 B I\nN 5 D e e B I 28 LA N\nT i B e e O e e I 2.8 A N\nN 5 D e e o B e I 228 L N\nN O e e e O e IS 2.8 R N\nN ] R o e o B S o IS 2% B N I\nG 5 D e e e B e e S 128 L A\nN ] D B e o B S o IS 2.8 B S I\nN ] O B e o B O e S 128 L A\nT O e e o B O e O IS 2.8 B S N\nT 5 O e e B e I 28 LA A\nN O e S o B O o IS 2.8 B S N\nR ] D e S e B e I 28 LR A\ne O e S o B O o IS 2.8 B S I\nN 5 O e e e B e 28 L S A\nG 5 D e S e B O e I 2.8 S I\nO 5] D e S e B e e IS 2.8 LB N\nST 5 e S o B O o IS 2.8 S I\nS R O S o B O o o S 208 R I N B\n72/83\n","contentLength":1255,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:05:17.019Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-20275-entity-legal-forms-code-list/2021-10-21-elf-code-list-v1.4.1.pdf","content":"LTKC United States of | ;g Louisiana US-LA Home Service Contract Provider English Home Service Contract Provider inc.jincorporated co. company corp. corporation;itd. limited;limited liability 20190705 | ACTV\nAmerica company:L.L.C..LC.\nUnited States of = y Domestic Low-Profit Limited Liability - Domestic Low-Profit Limited Liability ot lmited fabil ; y\nONJ1 Ynited § us Louisiana USLA Comeste English Company low-profit limited liability company:L3C 201907-05 [ACTV\nTDBW United States of | g Louisiana US-LA Domestic Registered Limited Liability English Domestic Registered Limited Liability registered limited liability partnership;L.L.P. 2019-07-05 | ACTV\nAmerica Partnership Partnership\nUnited States of - — - - —\n5KRB Ynited § us US-ME Savings and Loan Association English Savings and Loan Association 20210923 [ACTV\nUnited States of — \" - — \"\nMoA1 Ynited § us US-ME Limited Liability Partnership English Limited Liabilty Partnership 201907-05 [ACTV\nUnited States of - - -\nEWsU Ynited § us Maryland Us-MD Commercial Bank English Commercial Bank 20210923 [ACTV\nUnited States of g ; : ; gy\nGMFE Ynited § us Maryland Us-MD Savings Bank English Savings Bank 20210923 [ACTV\nUnited States of - : ’ o\nHLR4 Ynited § us Maryland Us-MD Stock Corporation English Stock Corporation Inc.;Corp.;Lid. 20210923 [ACTV\nUnited States of \" : ’ o\nLKDS Ynited § us Maryland Us-MD Close Corporation English Close Corporation Inc.;Corp.;Lid. 20210923 [ACTV\nUnited States of - - \"\n2vs9 Ynited § us Maryland Us-MD Nonstock Corporation English Nonstock Corporation 20210923 [ACTV\nmerica corporation or p.c.\nBYFU Ynited States of UsMA Limited Liability Company Engiish _ Limited Liabilty Company Limited Liability CompanyLLGLL GiLimited Gompany:LG,L.C. _ ACTV --_\nCAGH Urited States of US-MA Limited Liabilty Partnership English _ Limited Liabilty Partnership Registered Limited Liabilty Partnership:Limited Liabilty Partnership;L L.P;LLP _ ACTV --_\nUnited States of - - -\nG761 Ynited § us Massachusetts | US-MA Savings Bank English Savings Bank 20210923 [ACTV\n7383\n","contentLength":2051,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:05:17.019Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-20275-entity-legal-forms-code-list/2021-10-21-elf-code-list-v1.4.1.pdf","content":"I o e S O s IS 123 I I\nT O L B O e N I . I I\nR 5 O Lt O et e S 3 I I I\nO L e G O 55 sl N I o N I\nN 5 L e O s o S 3 I I I\nT 5 O L o O ) I . I IS\nN oL e O e N S 3 I N I\nR e L e O o O e S I T I I\nN 5 O L o B O IS 23 N I IS\nT 5 O L o O S 1 S IS . N I\nT 5 O L e O e e o S 3 N N I\nG 5 O L o O ) IS . I IS\nR 5 O L e O o N S 3 I I IS\n5 L O e s S 3 I I N\nN 5 O L e O e et e IS N I I\nN 5 O L e O s e IS 23 I I I\nT L L e O e e S 2 N I\nI 5 O L e I e N S 23 I I\ne O L I e IS 2 N I\nN 5 L e I ) I 3 N I I\nS 5 O L e O e e S I I I\nR 5 O L e O . N IS 3 I I\nO L e - ) I 1 I I\nT 5 L e O o I N I IS\nN L e O o IS . I I\nI 5 O L O e I N I IS\nI L e O . I 7 IS I\nT 5 O L o O e I 3 N I I\nT L e O e IS 7 S I\nR 5 O L S I ] I N I I\ne O L e O e IS . I I\nT - O L e O T IS 7 IS I\nR 5 O L e O s IS N I IS\nT O L o O ) IS N IS I\n5 L e O e N I O il Uil\nI O L e O B IS N N IS\nG 5 L o O s NI . N N IS\nN O L e O o IS 7 I I\nN 5 e L S ] I 3 N I IS\nT 5 L e O e IS . I I\nN 5 O L o O ot IS N I I\nN L e O e N IS 7 I I\nI 5 e L e I ] I 3 N N I\nN O L ot B O B IS 7 I I\nI O L e G O e S . A I I\n74/83\n","contentLength":1050,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:05:17.019Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-20275-entity-legal-forms-code-list/2021-10-21-elf-code-list-v1.4.1.pdf","content":"N 5 O e e o B e .28 L S N\nN ] R e e e B O e I 8 A S I\nN ] O e e e B e 28 L S A\nN O e L e B O e IS 28 A S I\ne 5 O e T e B S 2 IS 8 B S N\nN 5 D e e o B O s IS .8 L I\nN ] e e o B O e I 8 o S I\nN 5 D e e e B I .8 L I\ne O e L o B O o I 8 A S A\nT 5 D e e e B 2 IS .8 L S I\nT O e T o B O I 8 S N\nN 5 D e e e B IS .28 L A\nR O e T e B O e I 228 A S N\nN ] O o T o B O 2 IS 8 B N I\nN 5 D e e o B e S .22 L S A\nT 5 O o T e B O IS 8 A S N\nN 5 D e e o B e S 228 L S A\nN 5 D o T e B O o IS 8 S N\nN ] D e e e B O e S I .8 L S A\nN ] O o T O B O I 28 B I\nT 5 D e e e B e e I .8 L A\nN O e e B O e I 2.8 B S I\nR 5 D e e e B B I .8 L S I\nN 5 D o et B O I 8 A A\nN 5 D e e e B O . I .8 L S I\nN i e T B O o I 8 S N\nN 5 D e e o B ot I .8 A S AN\nN O e e B O o I 8 A S N\nN 5 D e e e B e I 128 LA S I\nI O e o B O e I 2.8 A S A\nN 5 D e e o B . S 28 L S N\nN 5 O o e e B O e I 8 A S A\ni ] S o e o B S o IS .28 N S\nN 5] D e e e B O s I 28 L A\nN 5 O o e o B O I 8 S N\nN 5] D e e B e I 128 LA S A\nN 5 O o B B O e IS 8 S N\nSN 5 O e e 55 B 5 I .8 L S A\nI i L o B O I .28 S I\nN 5 D e e B e S 228 L S A\nN 5 O e e B O 2 IS 8 o I\nI 5 D e e e B T I .8 L S N\nN O e e B O o I 8 A S A\nN ] D e e o B O e I 228 L N\ne i O o e o B o A . A S A\n75/83\n","contentLength":1201,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:05:17.019Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-20275-entity-legal-forms-code-list/2021-10-21-elf-code-list-v1.4.1.pdf","content":"pov [neaneselus Juvesa Juse Jsanin s maevenen onvi g o s s imrowment o I R TN T I D\nUnited States of - - — ) . - —\n4TMV Amenes us Nebraska US-NE Domestic Limited Cooperative Association | English Dormestic Limited Cooperative Association 20190705 |ACTV\nUnited States of - - - - -\n8HNT Ynied § us Nebraska US-NE Foreign Corporation English Foreign Corporation 20190705 |ACTV\noy United States of | yg Nobraska USNE Domestic Professional Limiled Liabilty Engish Domestic Professional Limited Liabity 190705 | ATV\nAmerica Company Company\nB2y United States of | g O USNE Foreign Professional Limited Liability Engish Foreign Professional Limited Liabiliy 190705 |acTy\nAmerica Company Company\nUnited States of y Domesticated Foreign Corporation : Domesticated Foreign Corporation y\ncxio America us Nebraska USNE Professional Corporation English Professional Corporation 201907-05 | ACTV\not United States of | g O USNE Domestic Corporation Professional Engish Domestic Corporation Professional 190705 |acTy\nAmerica Corporation Corporation\nown United States of | yg Nobraska USNE Non Profil Foreign Limfted Cooperaive Engish Non Proft Foreign Limited Cooperative 190705 | ATV\nAmerica Association Association\nUnited States of y ; - ; -\nQ17 Urited S us Nebraska US-NE Savings Bank English Savings Bank 20210923 |ACTV\ney el [reonss Juswe Joomewcowosn s o [oeeesecopomer [ @ fmeeepew [ | | |\nP [eiereeclus e Jusne Jruarescomay rain Jon [ vouercocompar I I N U R D\nI~ United States of | g O USNE Non Profft Dom Limited Cooperative Engish Non Proft Dom Limited Gooperative 190705 |acTy\nAmerica Association Association\nvl L (e o R G O N E e I T S I D\nUnited States of - - - - -\nY78G Unied § us Nebraska US-NE Hospital Authority English Hospital Authority 20190705 |ACTV\n76/83\n","contentLength":1766,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:05:17.019Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-20275-entity-legal-forms-code-list/2021-10-21-elf-code-list-v1.4.1.pdf","content":"e 5 O o e e B e .28 o S A\ne 5 D o T o B O o IS 8 S I\nN ] o e e B e S 28 L I\nN O e T o B O IS 8 S I\nN 5 D o e e B e . I .8 L S I\nN O e e o B O L I 228 A S N\nN 5 O o e e B D I 228 LA S I\nR O o o B O o I .28 S I\nG 5] O il O O e O G A\nN i O e o B O o I 8 S N\nN ] D o e e B o I .8 L I\ne O e o B O I 8 A S A\nR O o e B O e IS 8 B I\nN ] O e e e B O s S .8 L AN\ne O e L e B O L IS 8 S N\nR 5 O o e o B e I .8 L S A\nN O e o B O o I 28 S N\nN 5 D e e e B 2 I .8 L S A\ne O e O o B O e IS 8 S I\nT ] D e e e B o I 228 L S A\nN O e O e B O o I 28 A S N\nN 5 O e e e B e .8 L S A\nI O e O o B O I 8 S N\nN ] D o e e B S 228 LA S N\nT O e O o B O o I 8 S A\nN 5 D o e e B . I .8 L S I\nN O e o e B O B I 8 S N\nR 5] D o e o B e I 228 LA S N\ne ] L e e B O I 028 A S I\nN ] O o e T B . IS .8 L S I\nN O e e o B O o I 8 S N\nN ] O o I e B O o IS 2% B I\nR 5 D e e B e I 228 L S A\nN i o e e B O B IS 8 A S I\nN 5 O e B S S .8 L S A\no i o T e B O o IS 028 S N\nN ] e e e B I 28 L S AN\nN ] o T o B O o IS 8 A S N\nR 5 D e e B o I .8 L S AN\nN O o T o B O e IS 8 S I\nN 5 D O e o B o I 228 LA N\nN O e e o B O o e S I 28 R N\nN 5 D e e o B O e e S IS 28 LB I\nN O e O e B O e I 28 A S A\n(R ] O e O o B O o o I 2108 B I S B\n77/83\n","contentLength":1183,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:05:17.019Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-20275-entity-legal-forms-code-list/2021-10-21-elf-code-list-v1.4.1.pdf","content":"Urited States of North Carolina | US-NC Insurance Company English _ Insurance Company Gorp. incco.td.jincorporatedicompanyjimited;corporation _ ACTV --_\n6NIB United States of | | North Carolina ~ |US-NC Railroad i i i jmi i\nTriedS . - o s S ——— R e N\nsauN United States of | , North arofh y ’ ' - - \" e oot - i ’\nYnited § s jorth Carolina | US-NC Professional Corporation English Professional Corporation corp.jinc.;co.ltd.;Incorporated company;limited;corporation;PC 2017-11-80 [ACTV _\nARON Urited States of North Carolina | US-NC limited partnership English _ limited partnership LPLtd. Partnership. Ltd. Partnership _ ACTV --_\nCJs8 United States of | | North Carolina ~ |US-NC Cooperat fati i i fati i jmi i i\nTS . po———— o F——— S PR —T R e e\nUnited States of : - : ’ : - : ’ -inc. co-jtd, ted; imited; tion:emc:electri\nF99D C U North Carol US-NC corp.;inc.;co.;ltd.;Incorporated,company;limited;corporation;emc electric 11-\nP T S Gaoira 0SNG [Savnge s oo ion N o0 1. o pomearompany g caperaton S T O I e\nUried Saesar OSSR TPSV-S vy —— N P ————pS—— A\nUnited States of - -, -\north Carolina_ JUSNG Fnoten _ Hutual Assodiation corpne. 0. ncorporatedcompanyiimiedicorporation _ e ---\n1o longer available\nUnited States of ' i icati to be created;\nQ6EM America us North Carolina | US-NC L3C English L3C L3c 2017-11-30 | ACTV expication 2021-09-23 existing entities with\nthis legal form still\nsurvive\nsisT Ynited Siales of North Garolina | US-NG Public Transportation Authority Engiish _ Public Transportation Authority corp.jinc.ico. td. Incorporated;companyimited;corporation _ ACTV --_\nU910 United States of | , N ’ y \" - \" e oo - i ’\nYnited § s jorth Carolina | US-NC Captive Insurance Company English Captive Insurance Company corp.jinc.;co.ltd. Incorporated company;limited:corporation 2017-11-80 [ACTV -_\nUKX4 United States of | | North Carolina ~ |US-NC State Savings Bank i i jinc.ico.; jmi i\nT o oy Pw—— P —————— pevTPe =y ]\nUrited States of North Carolina | US-NC limited liability parinership English _ limited liability partnership LLPtdLiabilty partnership;rlipregistered limited liabilty partnership _ ACTV --_\nUnited States of North Garolina | US-NG Limited Liability Company English _ Limited Liabilty Company LLGlimited liabilty company:fciability company _ ACTV --_\nVsto Uniled States of | yg North Garof UenG - ot : - . e oot - imited: ’\nYnited & jorth Carolina | US: Mutual Burial Association English Mutual Burial Association corp.jinc.;co. ltd.;Incorporated company;limited:corporation 2017-11-80 [ACTV _\nUnited States of ’ y Regisiered Limited Liability Limited - Registered Limited Liability Limited P fioa bl L ’\n4usv United States of | | North Dakota ~ |US-ND Professional Limited Liabi i i ional Limited Liabi i\nT e Y ST TR —— rmskost L ity Py [P AP L e e e\nSaHG United States of | g onal Limited Liabil : onal Limited Liabil LLO.PLLC:\nYnited § s North Dakota | US-ND Professional Limited Liability Company English Professional Limited Liability Company LLGLLCPLLGP.LLC. 201907-05 [ACTV --_\n6JCE United States of | | North Dakota ~ |US-ND Gel i i i\nT e Y m—r— oy P—— . e e e\nCPK1 United States of | | North Dakota ~ |US-ND Mutual Aid C i i i i\nTS . YRy p— o TPy — pr— e G e\nLF4E United States of | | North Dakota ~ |US-ND F i i i i\nT e Y Se—— oy P——— s I\nMTDW Urited States of North Dakota | US-ND Limited Liabilty Limited Partnership English _ Limited Liabilty Limited Partnership LPLLLP _ ACTV --_\nNHGN United States of | | North Dakota ~ |US-ND Limi i i imi i\nT e Y pre— oy rera— ar e e e\nOGHV United States of | | North Dakota ~ |US-ND Professi i i i i i\nTriedS . S—rs— o pSr—T— pr—— e G e\noveL United States of { 5 North Dakota | US-ND Commercial Bank English i\nUrieds e p——r— prosyyeyy prey ]\nS745 United States of | | North Dakota ~ |US-ND Busi i i i i i\nTS P [PV P p—— o ppE—— pr—— I\nus7xX United States of { 5 North Dakota | US-ND Nonprofit C i i i i i\nGrieds mops— o re—— prem e\n78/83\n","contentLength":3922,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:05:17.019Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-20275-entity-legal-forms-code-list/2021-10-21-elf-code-list-v1.4.1.pdf","content":"N ] e e e B e 728 LA S N\nG 5 R o e B O I 028 S N\nN 5 D O e et B O e I 228 A S A\nN D o e o B O i N I8 B I I\nN 5 D O e o B . I 1218 L S N\nN 5 D o O e B O e I 28 A S I\nN ] D O e e B s o IS 28 R N\nN 5 D o e o B O o oo IS 228 B S N\nR 5 D O e e B o IS 28 L S A\nG 5 O O o B O 7 e I 208 B I N\nN 5 D O e o B o I 228 LA S N\nN 5 D o e o B O e I 028 A S A\ni O O e O o S e S I R N I\nN 5 O T e e B O e I 28 L S A\nT O O e o B O et IS 8 B S N\nN 5 O e e e B s I .8 L S A\nN i N e o B O o I 28 A S I\nT ] O e e e B S 228 L S A\nI i e o B O e e IS 8 o S N\nN ] O N e B L2 .8 L S AN\nN i O e e B O IS 8 B S N\nN 5 O O O e B O e e I 128 LA A\ne O O e o B O e I 2.8 A I\nN 5] O o e e B O e I 228 L N\nN i D O e e B O e e I 2.8 A S I\nN 5] D e e ot B e e IS 128 LB N\nN 5 D O o B O o I 2.8 A S N\nR ] D o e e B e B I 2.8 LB N\nN ] O e o B S o I 020 A S N\nN 5 D e e o B O o I 2.8 L N\nN O e o B O o I 2.8 S I\nN ] D O T B O e o IS 2.8 B I S B\nN ] O O e e B e e I 2.8 L A\nN 5 O O O e B O o I o8 A S N\nN ] O e e o B e I 228 L S A\nN ] O e e e B O o IS 8 B S I\nN 5 O e e e B e S 228 LA S A\nI O e e e B O e I 28 S N\nN 5] O e e B . I .8 L S A\ne O e e o B O o I 8 S I\nN 5 O e e e B e I .8 L S N\nN O e e o B O . I 8 S N\nN 5] O e o B e I 228 A N\nN 5 O e e e B O I 328 A A\nI e O o N e B O e IS 8 B S B\n79/83\n","contentLength":1259,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:05:17.020Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-20275-entity-legal-forms-code-list/2021-10-21-elf-code-list-v1.4.1.pdf","content":"T 5 e e e B O e 2 .8 L S I\nN 5 O o e e B O L IS 8 A S I\nN ] O e e e B O e I 228 A S A\nT O e e e B O e I 8 A S N\nN 5] O e e B 12 I .8 L S N\nN O e e o B O e I 228 A S N\nT 5 D e e e B O I .8 L S I\nN O e e e B O I 8 S N\nN 5 O e e e B O I .8 LA S I\nN ] e e e B O e I 8 A S I\nN 5 D e e e B O e s IS .8 LB N\no ] O G e e B O o I 8 A S I\nN 5 O G o o B O s I .8 L I\nN 5 O G e e B e S 28 L S A\nN i e e o B O o IS 8 S S\nN 5] O G o o B e 228 L S A\ne O o e e B O e IS 8 B S N\no ] O G e e e B O e I .8 L S A\nN i o o B O IS 8 o S N\nN 5] O G e e B e 202 I .8 L I\nN ] O e e e B O e IS 8 B S I\nN ] O G e e B e 2 .8 L S I\nT i o e B O e I o8 A S N\nN 5 D G e B 2 I .8 L N\nN i L e o B O o I 028 A S N\nN 5 D G e o B o I 228 L N\nN O o e o B O et I 8 A S I\nN 5 D G e e B O e s I .8 LA N\nN O o o e B O I 328 A ) A\nR 5 D G e e B e 2 I .8 L N\nI O L e o B O e IS 8 R S N\nN ] O G O o B O e IS 8 B I\nN 5] O e e B e 2 I .28 L A\nR O e o e O e IS 28 B S N\nN 5 O e e e B D S 28 L S A\nN O e e o B O IS 8 A S I\nN 5 O e O e B I .28 L S A\nN ] O e o B O I 28 S I\nT ] O e O e B S I .8 L S A\nN 5 O e e o B O o IS 8 B S N\nU 5 D R e e B s I .8 L S A\nG 5 O G e B O I 8 o S N\nN 5 O N e B D IS .8 L S N\nT 5 O G e o B O T I 228 A ) A\nT ] R B e B O S IS 8 B N S N\n80/83\n","contentLength":1220,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:05:17.020Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-20275-entity-legal-forms-code-list/2021-10-21-elf-code-list-v1.4.1.pdf","content":"o8 [oowe [0 [ [ [Evwtou St oo [Enova v Y - L A I I I\nMGou eoia fBO [ [ JEmpesaWida [Spansh fes [EmpesaMba [ ] [x00060 [AcV I I B\nRN fBowa —[io [ | [eveutumwn [Soarh o [Enprow Esaa e ————© mmewpev | T T\nXco [Boba —eo [ T Jcoomam Conwamsm [Soarih e [Soomaadon Gmare Sl ges 1 mmewpev | T T\nBonaire, Sint\n1A0A Eustatius and Besloten vennootschap Dutch Besloten vennootschap 201741-30 [ACTV\nal\nBonaire, Sint\nal\nBonaire, Sint o @\ne Commanditaire vennootschap met meerdere Commanditaire vennootschap met meerdere\nBonaire, Sint\n4ZBE Eustatius and Maatschap Dutch Maatschap 201741-30 [ACTV\nSaba\nBonaire, Sint\n51WZ Eustatius and Vereniging met beperkie rechtsbevoegdheid | Dutch Vereniging met beperkte rechtsbevoegdheid 201741-30 [ACTV\nSaba\nBonaire, Sint Aandeelhouder bestuurde Besloten Aandeelhouder bestuurde Besloten\nBonaire, Sint\n92Jz Eustatius and Stichting Dutch Stichting 201741-30 [ACTV\nSaba\nBonaire, Sint\nASAW Eustatius and Stichting particulier fonds Dutch Stichting particulier fonds 201741-30 [ACTV\nSaba\nEgz{filssal% _-- fir\\:aei?;emging e _ fir\\:aei?;emgiw e __ e ---\nSaba\nBonaire, Sint\nDaMJ Eustatius and Naamloze vennootschap Dutch Naamloze vennootschap 201741-30 [ACTV\nSaba\nBonaire, Sint\nFCPM Eustatius and Vereniging met volledige rechtsbevoegdheid | Dutch Vereniging met volledige rechtsbevoegdheid 201741-30 [ACTV\nSaba\nBonaire, Sint\nIPTQ Eustatius and Eenmanszaak met meerdere eigenaren Dutch Eenmanszaak met meerdere eigenaren 201741-30 [ACTV\nSaba\nQs Bonaire, Sint, Buitenlandse rechtsvorm hoofdvestiging op | Buitenlandse rechtsvorm hoofdvestiging op 20174130 | A deleti 20200640 |tisisnota\nS:ba lus an Bonaire utet Bonaire 1= eletion -06- Bonairian legal form\nBonaire, Sint\nKSHL Eustatius and Commanditaire vennootschap op aandelen | Dutch Commanditaire vennootschap op aandelen 201741-30 [ACTV\nSaba\nBonaire, Sint\nNPFB Eustatius and Eenmanszaak Dutch Eenmanszaak 201741-30 [ACTV\nSaba\nBonaire, Sint\nSNRI Eustatius and Vennootschap onder Firma Dutch Vennootschap onder Firma 201741-30 [ACTV\nSaba\nBonaire, Sint\nVHIY Eustatius and Cooperatie Dutch Cooperatie 201741-30 [ACTV\nSaba\nBonaire, Sint\nX088 Eustatius and Vereniging zonder rechtsbevoegdheid Dutch Vereniging zonder rechtsbevoegdheid 201741-30 [ACTV\nal\nBonaire, Sint — ” — \"\ne Commanditaire vennootschap met één Commanditaire vennootschap met één\nFGE o [ [ [ [scemmsme Sosedads Sl I - L A I N R\nN I R I R o Socedads Conporava 1 mwew v | [ | ]\n[ Joma_Jsr || [SooedadoLiiaca Sociedads L o Jmmwo oW [ ]\nWeES [eea R | | [sosaioon Condaraasimpes Sooedads om ComdandiaSimpes___[s6s | Tawmeno v [ | ]\nI R O I R 22 Y Socedads Arorim SR Jmmwo oW [ ]\noo o R [ [ Jomwte Jrouww [ Jomemn sasn [ [wew ov [ [ |\n9/83\n","contentLength":2686,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:05:17.020Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-20275-entity-legal-forms-code-list/2021-10-21-elf-code-list-v1.4.1.pdf","content":"N ] e o e B O e I 28 o S N\nN ] e o o B O o IS 8 S I\nI ] e e e B D S 28 L S A\nN ] G e e B O e I 8 S I\nN ] D B e o B o I 228 LA S N\nN D O e e B S o I 8 S N\nN 5 D o e T B D I .8 A S I\nT O e o B O e e IS 8 A S N\nG 5 D o e o B e I 228 L A\nG ] D N e e B O I 228 A S N\nN 5 D o e o B o I 320 LA N\nN O e o B O e IS 8 S A\nN ] D o e B D I .8 L S A\nN ] D o e e B O 1 I .8 L ) A\nN D O e e B O e IS 8 S N\nN ] D o e o B o S .8 L S A\nT e e o B O 2 I 8 B S I\nN ] D e o B S 228 L S A\nN ] O O e e B O S IS 8 A S N\nU 5 D e B O . .8 L A\nN D o e e B O e IS 8 S N\nR 5 O e e e B e 2 I .8 L S A\nN 5 O T e o B O I 228 o S I\nG 5 D o e o B e I 228 L N\nR O T e e B O e I 8 A S I\nN 5 O O e e B e I 228 L N\nN 5 D T e e B O e I 8 A S N\nR ] O e e o B S s I .8 L S A\nN 5 O T e B s I 8 A S N\nT 5] O e e e B e I .8 L I\nN 5 D o e e B O L I 8 S I\nN ] R T B S IS 8 B N I\nT ] D e e e B O . L .8 L A\no 5 O I e o B O 2 IS 8 S N\nN 5] O O e B 3 S 128 LA S A\nN 5 O e e B O e IS 2.8 S N\nN 5 D e e B o I 128 LA S A\no 5 O e o B O o I 2.8 S N\nN ] D R e B e S 2.8 L A\nN 5 O O e B B O B I 2.8 B S N\nN ] D U e o B o I 228 L I\nR 5 O o T o B O e I 2.8 A S I\nR ] D U e o B e S 228 LA N\nR 5 e o B S I 028 A S N\nN ] O (O T e 7B O o IS 2% B S B\n81/83\n","contentLength":1193,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:05:17.020Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-20275-entity-legal-forms-code-list/2021-10-21-elf-code-list-v1.4.1.pdf","content":"N L e O e IS 2 N N IS\nR O L e I ) I . I I\nN 5 L S O [ I . N N I\nN 5 L e O e . S IS . I IS\nT 5 U o N e I 3 N I I\nO L e S O ] N IS . I IS\nR 5 L e e O 2 IS 2 N I I\nI L e O e IS . S I\nT L e I ] I 3 I AN\nN e L e O ] N IS . IS I\nN 5 O e B O N IS . N I\nT 5 O L o O ) IS . IS I\nI - O L o G O o IS . I I\nS O L e O s N IS . N I I\nN L e O B IS . I IS\nI 5 O L e O s S . I I I\nR L e O e I . I I\nN 5 O L e O s [ I . N I I\nN O L e O e S . I I\nR O e L e S O B S N I AN\nT O L e O s S IS . N I\nR 5 L e O e N IS . I I\nN 5 O L ot O e S . N I I\nT e L e O e N I . I I\nR 5 O LB e O e I 3 N IS I\nI 5 L e G O e IS . I I\nT 5 L o O ] I 3 N I I\nR L B O . I . I I\nO 5 L e O e N IS 7 N I I\nN L e G O e IS . I I\nI 5 L e O N S 2 N I I\nI 5 O L e e O s 2 IS 2 N I IS\nT L e O o I N I I\nI 5 O L T O e I . N I IS\nO 5 O L o I ) IS . I I\nR 5 O L e O s [ IS 2 N N I\nI 5 L e O ) IS . I A\nI 5 O L e S O s S 2 I IS\ne 5 L O e IS . I I\nT 5 O Uz o N e N I 7 I IS\npsst fvawaw Jw ] 0000 ] [OverasCompany |Engish fen [OverseasCompary [ 0000000000 0000000 Jwewosw jacv [ 000 000 0000|\nO [vamau [ | [oecomen _ fewer Jer Joedoomen | | Jamwoew ew__[ | | ]\ne Y O . = L Y -2 0 L A Y I I\nR O I o O e IS . N I I\ne @ e || e e | e e [ fwesfen [\ni o I e O o S .. N I I\n82/83\n","contentLength":1222,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:05:17.020Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-20275-entity-legal-forms-code-list/2021-10-21-elf-code-list-v1.4.1.pdf","content":"56 Virgin Idands, |yg unlimited company thatis not authorised 0 | gnaiiah unlimited company that is not authorised 0 | g 20200610 | ACTY\nBritish issue shares 9 issue shares\n\nN250 Virgin 1sands, | va Testrcled purpoSes Company segregaed | engion Tesifoled purposes company segregaled | (spv) SPC 70200610 |AcTv\nBrilish portiolio company portiolio company\n\nQo Virgn I9ands, | vg uniiited company that s authorised to 1556 | Eparcn unlimited company thal is authorised (o 558 | grg 20200610 | Aoty\nBrilish shares shares\nVirgin I9ands, Gompany imited by guarantes that is - Gompany limited by guarantes that is P g\n\nZHED Brilish ve -- authorised to issué shares English authorised to issue shares LidiCorp;inc;S. A 2020-06-10 | ACTV\nVirgin ISands, Foreign Limited Partnership / Limited Liabily | g Foreign Limited Partnership / Limited Liability y\n\nANz Us vi -- Limited Partnership English Limited Partnership 20200610 | ACTV\nVirgin I9ands, Domestic Limited Partnership / Limited - Domestic Limited Parnership / Limited g\n\nMGUM us vi -- Liability Limited Partnership English Liability Limited Partnership 20200610 | ACTV\n\n83/83\n","contentLength":1124,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:05:17.020Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-20275-entity-legal-forms-code-list/2021-10-21-elf-code-list-v1.4.1.pdf","content":"(ot fowa sm [ | [Soomiaioom ComanaiprAwoo Sovedsdoon Comndtapdees oA | Tawoew v [ [\nYo [Bea R | [Soomdudom CormdoPaiepecao Sogedads om Gota o Patopegio S0P Jamoen o [ [ ]\nEULU Brunei Private Limited Company English Private Limited Company \"Sdn Bhd\" \"Bhd\" 20200610 [ACTV\nDarussalam\nU Bulgaria 5G EBPONGVIOKO KOOMIEDATHEO APYXECTBO C | gicarian Evropeysko kooperativio druznestvo s 0190705 | ACTY\nOrpaHmueHa OTTOBOPHOCT ogranichena otgovornost\nnew information\nfrom Bulgaria has\nSHL Bulgaria 8 Mlopenekute Ha eBponelicko o6eanHeHe Mo |gyjgarian Podelenie na evropeysko obedinenie po 0190705 | INAC deletion 2020.06-10 | made clear that this\nUKOHOMMUECK UHTEpEC ikonomicheski interesi is not a separate\nlegal form in\nBulgaria\nTR Jon [es ||[cwroweosumenmns [odwer [ [Siawievobsiesenpom I @wew v | [\nnew information\nfrom Bulgaria has\n45D7 Bulgaria BG KNIOH Ha Uy)aecTpareH Thprosel Bulgarian Kion na chuzhdestranen targovets 20190705 |INAC deletion 2020-06-10 {;‘?\\‘;f:':;;’:{e‘“'s\nlegal form in\nBulgaria\np fouee [ | | |wowerwem [ [w [Ewocerawes AT A I I B\nnew information\nfrom Bulgaria has_\n9F78 Bulgaria BG UyKneCTPaHHO APYXECTEO - HUIMIECKO | gyigarian Chuzhdestranno druzhestvo - fizichesko litse 20190705 |INAC deletion 2020-06-10 made clear that this\nnvue is not a separate\nlegal form in\nBulgaria\nB Jouwa [ | | Ewowswaucwmompe [oumm [ |Enochmossommodueds AT L I I R\n; abbrovaton\n’ ’ ! ! v eSDS- 1 correction of y removed from legal\nFPP2 Bulgaria BG Cubuparento apyxecrso (CH)/Coapyxue | Bulgarian Sabiratelno druzhestvo (SD)/Sadruzhie C-veCAC-ME SD/S-ie;SD;S-IE 2017-11-80 [ACTV s [2010:0705 | emoved fromiega)\nadded\nnew information\nfrom Bulgaria has\no15N Bulgaria BG UyX@eCTpaHHO APYECTED - IOPUANECKD | igarian Chuzhdestranno druzhestvo - yuridichesko 201907-05 | nac deletion 2020.0610 | made ciear that this\no e o litse is not a separate\nlegal form in\nBulgaria\nS Bulgaria S AKLIAOHEDHO APYXECTBO Go0 CeLManta | puigarian \"Aklsionemo druzhestvo sas spelsiaina AnCHL ADSIC 2171130 |AcTv\nWHBECTULIMOHHA Lien investitsionna tsel\nQzAU Bulgaria 5G ELHONAUHO GKLIOHEPHO APYKESTBO CC | gyigarian Ednolichno akisionerno druznesivo sas 0190705 | ACTY\ncneumanHa MHBECTULIMOHHA Lien spetsialna investitsionna tsel\nWHTEpect interesi\ntypo corrected\n’ P ’ 11 and ' typo corrected and\nszWo Bulgaria BG Esponelicko ApyXecTeo Bulgarian Evropeysko druzhestvo EQ ED 2017-11-80 [ACTV and viaion |2019:07:05 | ypocorrected and,\nadded\n- TIpyXecTe0 y4peReHo N0 3aKona 3a - Druzhestvo uchredeno po Zakona za -\ntypo corrected\n’ P ’ ! 11 and ' typo corrected and\nUsLM Bulgaria BG EBPONEHiCKo KOOMEPATHIBHO APYKECTBO Bulgarian Evropeysko kooperativno druzhestvo EKA EKD 2017-11-80 [ACTV and viaion |2019:07:05 | ypocorrected and,\nadded\ne fouee 6 | [ feowawn few w Jewes [ | Twweoe v | | | ]\nVe Jeumia [s6 || |Aoecmocoveweaoroomer [ousran [ [oudeswsogmemaogonet oo TJooo ———wwnw v | [ [ ]\nWik [ougra [5e [ | [mwnwromyeons [Bugaian oo [ Asonomo duarosvo AT L I I R\n- EAHONMHO APYKECTBO C Orpandena - Ednolichno druzhestvo s ogranichena -\nWVIN Bulgaria BG -- Enrono Bulgarian e £004 EOOD 201741-30 [ACTV\n: A 5 lromhoun ekachn tiuokhosatrauv\n: \" 5 Jromhoun mhachn ttuolkhosatrauv\nA T R I S [ 122 B or ———[Umied Py I - < A Y S R\nA N IR A I I e A I 2% [ AN I I I\nKostJoamboda _[RH || [sooPuopimontp Egshor_[SobPopeion 1 Tweew v _[ [ | ]\nKoot Joamoga [ || Tovpwgw [ [ [eraescona 1 Tweew v _[ [ | ]\nZieJoamboss [ [ [ [corourewawm B or [GorealPariray 1 Tweew v _[ [ | ]\n2 S I I I . L O e Y A0 A Y A B\n260 [oamboss [ || [Fouion Company Engishor | Foion Company 1 Tweew v _[ [ | ]\n2o Jomboss [0 [ [ Tpewmmew me [ [comoummams 1 Tweew v [ | ]\nTEac Ao [oAA6[iade mameloce poprersp Engish o [vado namolook prretoay ) A -2 [ A Y A I\nAbora[oA#6 [ Abora vt rporaon Engish o Abora et comparaton ) A -2 [ A Y A I\n2 Ao [oA#6 [ Abora Busiess Goparaton Engish _on [ Abora Susirs Corporaton ) - [ A Y I I\n50 Ao [oA#6 [ pblcemeaton compary Engish o[ piblo eceaton cmpary ) -2 [ A I I I\nAot [oAA6 [ Abora prvte o proftcompary B or [Abomapmvab romprotoompary [ Jowrw v [ ]\nAot [oA#6 [ Abora cooperaive Engish o[ Aboracooperais ) -2 [ A I I I\nB R R T Engish o [wrarutly coopoatve ) -2 [ A I I I\nAo [oA#6 [ Aborta pojessona coporaon Engish _on | Abora poesionalcoporston ) -2 [ A I I I\n10/83\n","contentLength":4250,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:05:17.020Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Official Organizational Roles\nVersion 1.0.0\nJune 2023\n","contentLength":54,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.718Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"33LI0X Australia AU Public Company limited | gy Shareholder English Shareholder 2023-06-28 |ACTV Corporations Act 2001 -\nby shares S.256C\n. Public Company limited I e Corporations Act 2001 -\n3WNV8Z Australia AU -- by shares R4KK Company secretary English Company secretary Co.Sec. Co.Sec. 2023-06-28 ACTV S5.188, 204A\n. Public Company limited ) e Corporations Act 2001 -\n7HLOLM Australia AU -- by shares R4KK Member English Member 2023-06-28 ACTV Ss.114, 117, 120\nA532DM Australia AU Limited Proprietary TXVC Managing director English Managing director 2023-06-28 |ACTV Corporations Act 2001 -\nCompany S.201)\n. Public Company limited ) e Corporations Act 2001 -\nDAGOEM Australia AU -- by shares R4KK Officer English Officer 2023-06-28 ACTV Ss.9(defn), 199A\nDYTPNW Australia AU Limited Proprietary TXVC Administrator English Administrator 2023-06-28 |ACTV Corporations Act 2001 -\nCompany Ss.12, 198G\n. Limited Proprietary ) e Corporations Act 2001 -\nESEKSK Australia AU -- Company TXVC Company secretary English Company secretary Co.Sec. Co.Sec. 2023-06-28 ACTV 55.188, 204A\nFOOX7C Australia AU Public Company limited g4y Trustee English Trustee 2023-06-28 |ACTV Corporations Act 2001 -\nby shares S.283AC\nFDYQIB Australia AU Public Company limited | gy Administrator English Administrator 2023-06-28 |ACTV Corporations Act 2001 -\nby shares Ss.12, 198G\nG7Y07S Australia AU Limited Proprietary TXVC Debenture holder English Debenture holder 2023-06-28 |ACTV Corporations Act 2001 -\nCompany S.283AB\nGIDXNF Australia AU Limited Proprietary TXVC Director English Director 2023-06-28 |ACTV Corporations Act 2001 -\nCompany S.201A\nHAFDYQ Australia AU Limited Proprietary TXVC Auditor English Auditor 2023-06-28 |ACTV Corporations Act 2001 -\nCompany S.199A\n. Limited Proprietary I Corporations Act 2001 -\nHP8CKI Austral AU ™@C off English offi 2023-0628 | ACTV\nvt -- Company e \"o e Ss.9(def'n), 199A\n. Limited Proprietary . ) . e Corporations Act 2001 -\nHQKRJO Australia AU -- Company TXVC Alternate director English Alternate director 2023-06-28 ACTV 5.198C, 201K\nIH5NZG Australia AU Public Company limited gy Liquidator English Liquidator 20230628 |ACTV Corporations Act 2001 -\nby shares S.12\n. Public Company limited o ) o e Corporations Act 2001 -\nJOHRSI Australia AU -- by shares R4KK Managing director English Managing director 2023-06-28 ACTV 5.198C, 201\nJQ51TP Australia AU Public Company limited g4y Debenture holder English Debenture holder 2023-06-28 |ACTV Corporations Act 2001 -\nby shares S.283AB\nTrusts (Hague\nKR8NGL Australia AU Trust 7TPC Beneficiary English Beneficiary 2023-06-28 ACTV Convention) Act 1991 -\nArt.8\nLYTsPB Australia AU Limited Proprietary TXVC Trustee English Trustee 2023-06-28 |ACTV Corporations Act 2001 -\nCompany S.283AC\nMTLVXK Australia AU Public Company limited g4y Alternate director English Alternate director 2023-06-28 |ACTV Corporations Act 2001 -\nby shares S.198C, 201K\nNLZLDC Australia AU Limited Proprietary ™>VC Liquidator English Liquidator 20230628 |ACTV Corporations Act 2001 -\nCompany S.12\nNPYQB) Australia AU Public Company limited gy Receiver English Receiver 2023-06-28 |ACTV Corporations Act 2001 -\nby shares S.12\nTrusts (Hague\nOLUMDL Australia AU Trust 7TPC Trustee English Trustee 2023-06-28 ACTV Convention) Act 1991 -\nArt.2\nORL3QI Australia AU Limited Proprietary TXVC Receiver English Receiver 2023-06-28 |ACTV Corporations Act 2001 -\nCompany S.12\nPF2B70 Australia AU Public Company limited g4y Auditor English Auditor 2023-06-28 |ACTV Corporations Act 2001 -\nby shares S.199A\nQBW3P Australia AU Limited Proprietary TXVC Shareholder English Shareholder 2023-06-28 |ACTV Corporations Act 2001 -\nCompany S.198E\nTrusts (Hague\nUVAD6V Australia AU Trust 7TPC Settlor English Settlor 2023-06-28 ACTV Convention) Act 1991 -\nArt.2\n. Public Company limited ! ) ! e Corporations Act 2001 -\nYBK29T Australia AU -- by shares R4KK Director English Director 2023-06-28 ACTV 5.180, 201A\n. Limited Proprietary I Corporations Act 2001 -\nZEBPIG Austral AU ™@C Memb; English Memb; 2023-0628 | ACTV\nvt -- Company emher \"o emner Ss.114, 117, 120\n3IC75H Austria AT Gesellschaft mit AXSB Revisor German Revisor 2023-06-28 |ACTV GmbH-Gesetz 46\nbeschrankter Haftung\n9SXBAY Austria AT Gesellschaft mit AXSB Abschlusspriifer German Abschlusspriifer 2023-06-28 |ACTV GmbH-Gesetz 30g\nbeschrankter Haftung\nFBN18D Austria AT Gesellschaft mit AXSB Aufsichtsratsmitglied German Aufsichtsratsmitglied 2023-06-28 |ACTV GmbH-Gesetz 28a/30c\nbeschrankter Haftung\n2119\n","contentLength":4481,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.718Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"23 MARS 2019. — Loi\nintroduisant le Code des\nAP o sociétés et des\nWOYWOR Belgium fi;cl'tzt: aresponsabilité |, .0 Associé French fr Associé 2023-0628 |ACTV assodiations et portant\ndes dispositions diverses -\nPARTIE 1re: LIVRE ler:\nTITRE ler: Art. 1:1\n23 MARZ 2019. —\n\" Gesetzbuch der\n. Gesellschaft mit\nWOYWOR Belgium beschrankter Haftung 3W7E Gesellschafter German Gesellschafter 2023-06-28 ACTV Gese_llgchaften und_\nVereinigungen - Teil 1:\nBuch 1: Title 1 - Art.1:1\n23 MARS 2019. — Loi\nintroduisant le Code des\n. P : F— iétés et des\n\" o Titulaire d’obligations Titulaire d’obligations societes\nXEVXDQ Belgium Société anonyme R85P convertibles French fr convertibles 2023-06-28 ACTV assoc.latlor.\\s. et portant\ndes dispositions diverses -\nLivre 7: Titre 4: CHAPITRE\n2: Art. 7:135\n23 MAART 2019. — Wet\ntot invoering van het\nWetboek van\nHoud rteerb. Houd teerb vennootschappen en\nXEVXDQ Belgium Naamloze vennootschap | R85P puCCr Van CONVErteerdare I putch oucer van converteerbare 2023-06-28 |AcTv verenigingen en\nobligaties obligaties y\nhoudende diverse\nbepalingen - BOEK 7:\nTITEL 4: HOOFDSTUK 2:\nArt.7:135\n23 MARZ 2019. —\n\" \" Inhaber von Inhaber von Gesetzbuch der\nXEVXDQ Belgium Aktiengesellschaft R85P Wandelschuldverschreibungen German Wandelschuldverschreibungen 2023-06-28 ACTV Gesellschaften und\nVereinigungen\n1C6E6K Canada cA Alberta CA-AB Alberta Business 8ZH8 officer English officer 2023-06-28 | ACTV Business Corporations Act\nCorporation 1981 -18\n47%0XM Canada cA Alberta CA-AB Aberta Business 8ZH8 liquidator English liquidator Liq. 2023-0628 | ACTV Business Corporations Act\nCorporation 1981 - 210\n5MHKOF Canada cA Alberta CA-AB Alberta Business 8ZH8 debenture holder English debenture holder 2023-06-28 | ACTV Business Corporations Act\nCorporation 1981 - 88.2\n60FLDM Canada cA Alberta CA-AB Aberta Business 8ZH8 security holder English security holder 2023-0628 | ACTV Business Corporations Act\nCorporation 1981 -45.1\n6331vQ Canada cA Alberta CA-AB Alberta Business 8ZH8 trustee English trustee 2023-06-28 | ACTV Business Corporations Act\nCorporation 1981 - 77\n7LUPKY Canada cA Alberta CA-AB Aberta Business 8ZH8 incorporator English incorporator 2023-0628 | ACTV Business Corporations Act\nCorporation 1981-1,5\n824JT5 Canada cA Alberta CA-AB Alberta Business 8ZH8 shareholder English shareholder 2023-06-28 | ACTV Business Corporations Act\nCorporation 1981 -21\nAAPYHQ Canada cA Alberta CA-AB Aberta Business 8ZH8 managing director English managing director 2023-0628 | ACTV Business Corporations Act\nCorporation 1981 - 110\nAMVRCB Canada cA Alberta CA-AB Alberta Business 8ZH8 receiver English receiver 2023-06-28 | ACTV Business Corporations Act\nCorporation 1981 - 89\nBCHLVO Canada cA Alberta CA-AB Aberta Business 8ZH8 guarantor English guarantor 2023-0628 | ACTV Business Corporations Act\nCorporation 1981 -18\nFARD2X Canada cA Alberta CA-AB Alberta Business 8ZH8 director English director Dir. 2023-06-28 | ACTV Business Corporations Act\nCorporation 1981-1,6\nHSN5XM Canada cA Alberta CA-AB Alberta limited RN4K general partner English general partner GP, G.P. 2023-0628 | ACTV Partnership Act 2021 -\npartnership 51.2\nHUZL4U Canada CA Alberta CA-AB Alberta B.usiness 8ZH8 receiver manager English receiver manager 2023-06-28 |ACTV Business Corporations Act\nCorporation 1981 - 90\nOTHS2Z Canada ca Alberta CA-AB Alberta limited RN4K limited partner English limited partner LP, LP. 2023-0628 | ACTV Partnership Act 2021 -\npartnership 51.2\nZ127IK Canada cA Alberta CA-AB Alberta Business 8ZH8 auditor English auditor 2023-06-28 |ACTV Business Corporations Act\nCorporation 1981 -1, 156\nCompany (includes\n0Q520W Canada cA British Columbia | CA-BC Eg::;‘:\";t:ncé’z:'l'ikr’;::g YG5M Incorporator English Incorporator 2023-06-28 |ACTV (E’S“;'cnigzzc)\"f’:’{g:';’)”s Act\nliability company)\nCompany (includes\ne \" \" community contribution \" \" \" 06 Business Corporations Act\n410MQL Canada CA British Columbia | CA-BC company and unlimited YG5M Auditor English Auditor 2023-06-28 ACTV (SBC 2002) - 5.204\nliability company)\nCompany (includes\nDKUCKP Canada cA British Columbia | CA-BC community contribution YG5M Bearer of a bearer share English Bearer of a bearer share 2023-0628 |AcTv Business Corporations Act\ncompany and unlimited certificate certificate (SBC 2002) -5.58.1\nliability company)\nCompany (includes\ne \" \" community contribution \" \" \" 06 Business Corporations Act\nHLV72D Canada CA British Columbia | CA-BC company and unlimited YG5M Applicant agent English Applicant agent 2023-06-28 ACTV (SBC 2002) - 5.30\nliability company)\n11/119\n","contentLength":4548,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.718Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"North Dakota Century\nUnited States Code: Title 10: Ch. 19.1 -\nWXG5VN . us North Dakota US-ND (Business) Corporation |S745 incorporator English incorporator 2023-06-28 ACTV North Dakota Business\nof America :\nCorporation Act 10-19.1-\n09\nNorth Dakota Century\nUnited States Code: Title 10: Ch. 19.1 -\nWYL00S . us North Dakota US-ND (Business) Corporation |S745 director English director Dir. 2023-06-28 ACTV North Dakota Business\nof America :\nCorporation Act 10-19.1-\n01\nNorth Dakota Century\nUnited States Code: Title 10: Ch. 19.1 -\nXHCHB7 . us North Dakota US-ND (Business) Corporation |S745 receiver English receiver 2023-06-28 ACTV North Dakota Business\nof America :\nCorporation Act 10-19.1-\n117\nNorth Dakota Century\n\" . P Code: Title 10: Ch. 10-\nUnited Stat Bi Limited\nYVPINM nited states ;5 North Dakota |US-ND (Business) Limite GHB2 organizer English organizer 2023-06-28 |ACTV 32.1 - North Dakota\nof America Liability Company ; o PR\nUniform Limited Liability\nCompany Act 10-32.1-05\nNorth Dakota Century\n\" . P Code: Title 10: Ch. 10-\nUnited Stat Bi Limited\nZM3X1G nited states ;5 North Dakota |US-ND (Business) Limite GHB2 chief manager English chief manager 2023-06-28 |ACTV 32.1 - North Dakota\nof America Liability Company ; . PR\nUniform Limited Liability\nCompany Act 10-32.1-41\nOhio Revised Code: Title\nUnited States \" Limited Liability \" \" \" 17: Ch. 1706 - Ohio\n1J4HSN of America us Ohio US-OH Company EZNQ organizer English organizer 2023-06-28 ACTV Revised Limited Liability\nCompany Act 1706.01\nUnited States Ohio Revised Code: Title\n2WCDR9 of America us Ohio US-OH Corporation (For-Profit) | BTQ1 vice president English vice president 2023-06-28 ACTV 17: General Corporation\nLaw - Section 1701.64\nted Ohio Revised Code: Title\n7VQXSV Uf”:e States ;g Ohio US-OH Corporation (For-Profit) | BTQ1 secretary English secretary 2023-06-28 |ACTV 17: General Corporation\nof America Law - Section 1701.64\nUnited States Ohio Revised Code: Title\n96LRAU : us Ohio US-OH Corporation (For-Profit) | BTQ1 incorporator English incorporator 2023-06-28 ACTV 17: General Corporation\nof America :\nLaw - Section 1701.01\nUnited States Ohio Revised Code: Title\nAMTZ26 : us Ohio US-OH Corporation (For-Profit) | BTQ1 assistant officer English assistant officer 2023-06-28 ACTV 17: General Corporation\nof America :\nLaw - Section 1701.64\nUnited States Ohio Revised Code: Title\nDWJTEE . us Ohio US-OH Corporation (For-Profit) | BTQ1 director English director 2023-06-28 ACTV 17: General Corporation\nof America :\nLaw - Section 1701.10\nUnited States Ohio Revised Code: Title\nEPNKC9 - us Ohio US-OH Corporation (For-Profit) | BTQ1 subscriber English subscriber 2023-06-28 |ACTV 17: General Corporation\nof America :\nLaw - Section 1701.14\nUnited States Ohio Revised Code: Title\nEUSNRV . us Ohio US-OH Corporation (For-Profit) | BTQ1 officer English officer 2023-06-28 ACTV 17: General Corporation\nof America :\nLaw - Section 1701.64\nUnited States Ohio Revised Code: Title\nEXDOAW N us Ohio US-OH Corporation (For-Profit) |BTQ1 statutory agent English statutory agent 2023-06-28 ACTV 17: General Corporation\nof America :\nLaw - Section 1701.07\nOhio Revised Code: Title\nUnited States \" Limited Liability \" 17: Ch. 1706 - Ohio\nFSRSZ7 of America us Ohio US-OH Company EZNQ manager English manager Magr. 2023-06-28 ACTV Revised Limited Liability\nCompany Act 1706.01\nOhio Revised Code: Title\nUnited States \" Limited Liability \" \" \" 17: Ch. 1706 - Ohio\nGNPR98 of America us Ohio US-OH Company EZNQ agent (for service of process) |English agent (for service of process) 2023-06-28 ACTV Revised Limited Liability\nCompany Act 1706.09\nOhio Revised Code: Title\nLNMHAL United States | ;g Ohio US-OH Limited Liability EZNQ member English member 2023-06-28 |ACTV 17: Ch. 1706 - Ohio\nof America Company Revised Limited Liability\nCompany Act 1706.01\nUnited States Ohio Revised Code: Title\nPIQDTM : us Ohio US-OH Corporation (For-Profit) | BTQ1 transfer agent English transfer agent 2023-06-28 |ACTV 17: General Corporation\nof America :\nLaw - Section 1701.26\nUnited States Ohio Revised Code: Title\nR35T3U . us Ohio US-OH Corporation (For-Profit) | BTQ1 president English president 2023-06-28 ACTV 17: General Corporation\nof America :\nLaw - Section 1701.64\nUnited States Ohio Revised Code: Title\nSIX1Y8 . us Ohio US-OH Corporation (For-Profit) | BTQ1 fiduciary English fiduciary 2023-06-28 ACTV 17: General Corporation\nof America :\nLaw - Section 1701.46\nUnited States Ohio Revised Code: Title\nTBBN6Z N us Ohio US-OH Corporation (For-Profit) |BTQ1 receiver English receiver 2023-06-28 ACTV 17: General Corporation\nof America :\nLaw - Section 1701.90\nUnited States Ohio Revised Code: Title\nTP3BNW . us Ohio US-OH Corporation (For-Profit) |BTQ1 shareholder English shareholder 2023-06-28 ACTV 17: General Corporation\nof America :\nLaw - Section 1701.01\n101/119\n","contentLength":4811,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.718Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"United States Ohio Revised Code: Title\nUPGW2N of America us Ohio US-OH Corporation (For-Profit) |BTQ1 voting trustee English voting trustee 2023-06-28 ACTV 17: General Corporation\nLaw - Section 1701.49\nUnited States Ohio Revised Code: Title\nXVU7M7 of America us Ohio US-OH Corporation (For-Profit) |BTQ1 treasurer English treasurer 2023-06-28 ACTV 17: General Corporation\nLaw - Section 1701.64\nOklahoma Statutes: Title\n062UW9 United States ;g Oklahoma Us-0K Profit Corporation BGH4 vice-president English vice-president VP 2023-0628 |ACTV 18: 55.1000ff - Oklahoma\nof America General Corporation Act\n18-1007\nOklahoma Statutes: Title\n1R24K1 United States | ;¢ Oklahoma Us-0K Limited Liability BBXC member English member 2023-06-28 | ACTV 18: 55.2000ff - Oklahoma\nof America Company Limited Liability Company\nAct 18-2001\nOklahoma Statutes: Title\n2QJMs2 United States ;g Oklahoma Us-0K Profit Corporation BGH4 custodian English custodian 2023-0628 |ACTV 18: 55.1000ff - Oklahoma\nof America General Corporation Act\n18-1071\nOklahoma Statutes: Title\nBPPZVU United S_tates us Oklahoma US-OK Profit Corporation BGH4 assistant secretary English assistant secretary Asst.Sec. 2023-06-28 |ACTV 18: 55.1000ff - Ok_lahoma\nof America General Corporation Act\n18-1007\nOklahoma Statutes: Title\nDOYV39 United States ;g Oklahoma Us-0K Profit Corporation BGH4 vice-chair English vice-chair 2023-06-28 | ACTV 18: 55.1000ff - Oklahoma\nof America General Corporation Act\n18-1007\nOklahoma Statutes: Title\nFWQITA United States ;g Oklahoma Us-0K Profit Corporation BGH4 holder of record (stock) English holder of record (stock) 2023-0628 |ACTV 18: 55.1000ff - Oklahoma\nof America General Corporation Act\n18-1007\nOklahoma Statutes: Title\nGTWYDS United States | ;g Oklahoma US-0K Profit Corporation BGH4 incorporator English incorporator 2023-0628 | ACTV 18: 55.1000ff - Oklahoma\nof America General Corporation Act\n18-1005\nOklahoma Statutes: Title\n1Qzv7z United States ;g Oklahoma Us-0K Profit Corporation BGH4 shareholder English shareholder 2023-0628 |ACTV 18: 55.1000ff - Oklahoma\nof America General Corporation Act\n18-1064\nOklahoma Statutes: Title\nUnited States Limited Liability \" 18: 55.2000ff - Oklahoma\nJJOC4H of America us Oklahoma US-OK Company B8XC manager English manager Mar. 2023-06-28 ACTV Limited Liability Company\nAct 18-2001\nOklahoma Statutes: Title\nLALQOI United States ;¢ Oklahoma US-0K Limited Liability B8XC registered agent English registered agent 2023-06-28 |ACTV 18: 55.2000ff - Oklahoma\nof America Company Limited Liability Company\nAct 18-2010\nOklahoma Statutes: Title\nMOKV3B United States | ;g Oklahoma US-0K Profit Corporation BGH4 president English president Pres. 2023-0628 | ACTV 18: 55.1000ff - Oklahoma\nof America General Corporation Act\n18-1007\nOklahoma Statutes: Title\nNYL5PA United States | ;g Oklahoma US-0K Profit Corporation BGH4 secretary English secretary Sec. 2023-06-28 | ACTV 18: 55.1000ff - Oklahoma\nof America General Corporation Act\n18-1007\nOklahoma Statutes: Title\nOPXFOD United States | ;g Oklahoma US-0K Profit Corporation BGH4 officer English officer 2023-06-28 | ACTV 18: 55.1000ff - Oklahoma\nof America General Corporation Act\n18-1028\nOklahoma Statutes: Title\nRBDFIR United States ;g Oklahoma Us-0K Profit Corporation BGH4 trustee English trustee 2023-06-28 | ACTV 18: 55.1000ff - Oklahoma\nof America General Corporation Act\n18-1100\nOklahoma Statutes: Title\nU2RUBO United States | ;g Oklahoma US-0K Profit Corporation BGH4 chair English chair ch. 2023-06-28 | ACTV 18: 55.1000ff - Oklahoma\nof America General Corporation Act\n18-1007\nOklahoma Statutes: Title\nZNYYCP United States | ;g Oklahoma US-0K Profit Corporation BGH4 registered agent English registered agent 2023-06-28 |ACTV 18: 55.1000ff - Oklahoma\nof America General Corporation Act\n18-1022\nOklahoma Statutes: Title\nZWQZMO United States | ;g Oklahoma US-0K Profit Corporation BGH4 receiver English receiver 2023-06-28 | ACTV 18: 55.1000ff - Oklahoma\nof America General Corporation Act\n18-1071\nUnited States Oregon Revised Statutes:\n1SUZFI . us Oregon US-OR Business Corporation T5ZE subscriber English subscriber 2023-06-28 ACTV Title 7: Ch.60 Private\nof America .\nCorporations - 60.001\nUnited States Oregon Revised Statutes:\n4WG6BM . us Oregon US-OR Business Corporation T5ZE officer English officer 2023-06-28 ACTV Title 7: Ch.60 Private\nof America .\nCorporations - 60.004\n102/119\n","contentLength":4367,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.718Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Oregon Revised Statutes:\nUnited States Limited Liability \" \" \" Vol.2: Title 7: Ch.63\nB6AMYOO us O US-OR K2, English 2023-06-28 ACTV\nof America regon Company QK2 organizer nglls organizer Limited Liabiity\nCompanies 63.001\nUnited States Oregon Revised Statutes:\nBMQLO) . us Oregon US-OR Business Corporation T5ZE director English director 2023-06-28 ACTV Title 7: Ch.60 Private\nof America .\nCorporations - 60.004\nOregon Revised Statutes:\nUnited States Limited Liability \" \" \" Vol.2: Title 7: Ch.63\nEPLPIR of America us Oregon US-OR Company QK2) custodian English custodian 2023-06-28 ACTV Limited Liabiity\nCompanies 63.664\nUnited States Oregon Revised Statutes:\nEXHBUQ of America us Oregon US-OR Business Corporation T5ZE president English president 2023-06-28 ACTV Title 7: Ch.60 Private\nCorporations - 60.004\nUnited States Oregon Revised Statutes:\nFVERPF of America us Oregon US-OR Business Corporation T5ZE custodian English custodian 2023-06-28 ACTV Title 7: Ch.60 Private\nCorporations - 60.667\nOregon Revised Statutes:\nH30CSD United States ) Oregon US-OR Limited Liability QKk2) member English member 2023-0628 | ACTV Vol.2: Title 7: Ch.63\nof America Company Limited Liabiity\nCompanies 63.001\nUnited States Oregon Revised Statutes:\nHRD7F6 of America us Oregon US-OR Business Corporation T5ZE chairperson English chairperson 2023-06-28 ACTV Title 7: Ch.60 Private\nCorporations - 60.004\nOregon Revised Statutes:\nJBQSOK United States ) Oregon US-OR Limited Liability QKk2) receiver English receiver 2023-0628 | ACTV Vol.2: Title 7: Ch.63\nof America Company Limited Liabiity\nCompanies 63.004\nUnited States Oregon Revised Statutes:\nJVCvi2 . us Oregon US-OR Business Corporation T5ZE receiver English receiver 2023-06-28 ACTV Title 7: Ch.60 Private\nof America .\nCorporations - 60.667\nOregon Revised Statutes:\nUnited States Limited Liability \" \" \" Vol.2: Title 7: Ch.63\nMK6CMT of America us Oregon US-OR Company QK2) registered agent English registered agent 2023-06-28 ACTV Limited Liabiity\nCompanies 63.111\nUnited States Oregon Revised Statutes:\nOHAQQO of America us Oregon US-OR Business Corporation T5ZE incorporator English incorporator 2023-06-28 ACTV Title 7: Ch.60 Private\nCorporations - 60.004\nOregon Revised Statutes:\nUnited States Limited Liability \" Vol.2: Title 7: Ch.63\n0Y59X7 us O US-OR K2, English Mgr. 2023-06-28 ACTV\nof America regon Company QK2 manager nglls manager or Limited Liabiity\nCompanies 63.001\nOregon Revised Statutes:\nQ63RKL United States ;g Oregon US-OR Business Corporation [T5ZE shareholder English shareholder 2023-06-28 |ACTV Title 7: Ch.60 Private\nof America Corporations - 60.001\nUnited States Oregon Revised Statutes:\nQGDHMT of America us Oregon US-OR Business Corporation T5ZE secretary English secretary 2023-06-28 ACTV Title 7: Ch.60 Private\nCorporations - 60.371\nUnited States Oregon Revised Statutes:\nSE5SEOR of America us Oregon US-OR Business Corporation T5ZE registered agent English registered agent 2023-06-28 ACTV Title 7: Ch.60 Private\nCorporations - 60.111\nUnited States Oregon Revised Statutes:\nUN2JBI of America us Oregon US-OR Business Corporation T5ZE assistant officer English assistant officer 2023-06-28 ACTV Title 7: Ch.60 Private\nCorporations - 60.371\nUnited States Oregon Revised Statutes:\nYOOOEN . us Oregon US-OR Business Corporation T5ZE voting trustee English voting trustee 2023-06-28 ACTV Title 7: Ch.60 Private\nof America .\nCorporations - 60.254\nPennsylvania\nUnited States Consolidated Statutes:\n3RZXOR of America us Pennsylvania US-PA Business Corporation 3JTE liquidating receiver English liquidating receiver 2023-06-28 ACTV Title 15: Part Ill: Ch.19\nFundamental Changes §\n1985\nPennsylvania\nUnited States Consolidated Statutes:\n4ASFAX of America us Pennsylvania US-PA Business Corporation 3JTE receiver English receiver 2023-06-28 ACTV Title 15: Part Ill: Ch.19\nFundamental Changes §\n1984\nPennsylvania\nConsolidated Statutes:\n6UIVYM United States ) Pennsylvania |US-PA Limited Liability oc19 receiver English receiver 2023-0628 | ACTV Title 15: Part lll: Ch.88 -\nof America Company Pennsylvania Uniform\nLimited Liability Company\nAct of 2016 § 8853\nPennsylvania Code: Title\n19 Corporations and\nUnited States \" \" . : \" \" : \" Business Associations:\nAHQ9PN of America us Pennsylvania US-PA Business Corporation 3JTE vice president English vice president VP 2023-06-28 ACTV Ch.23 Business\nCorporations Generally\n23.51\n103/119\n","contentLength":4389,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.718Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Pennsylvania Code: Title\n19 Corporations and\nDUX22Z United States | ;g Pennsylvania |US-PA Business Corporation | 3JTE shareholder English shareholder 2023-06-28 |ACTV Business Assoclations:\nof America Ch.23 Business\nCorporations Generally\n23.13\nPennsylvania\nConsolidated Statutes:\nGCIMAE United States ) Pennsylvania |US-PA Limited Liability oc19 member English member 2023-0628 | ACTV Title 15: Part lll: Ch.88 -\nof America Company Pennsylvania Uniform\nLimited Liability Company\nAct of 2016 § 8812\nPennsylvania Code: Title\n19 Corporations and\nKO5)VC United States ;g Pennsylvania |US-PA Business Corporation | 3TE director English director Dir. 2023-06-28 | ACTV Business Associations:\nof America Ch.23 Business\nCorporations Generally\n23.8\nPennsylvania Code: Title\n19 Corporations and\nLSSPo1 United States | ;g Pennsylvania |US-PA Business Corporation | 3JTE treasurer English treasurer Treas. 2023-06-28 |ACTV Business Associations:\nof America Ch.23 Business\nCorporations Generally\n23.51\nPennsylvania Code: Title\n19 Corporations and\nM30ISP United States | ;¢ Pennsylvania |US-PA Business Corporation | 3JTE incorporator English incorporator 20230628 |ACTV Business Assoclations:\nof America Ch.23 Business\nCorporations Generally\n23.2\nPennsylvania Code: Title\n19 Corporations and\nMVHKLI United States | ;g Pennsylvania |US-PA Business Corporation | 3JTE president English president Pres. 2023-0628 | ACTV Business Associations:\nof America Ch.23 Business\nCorporations Generally\n23.51\nPennsylvania\nConsolidated Statutes:\n06FVIY United States ;g Pennsylvania [US-PA Limited Partnership HSEV limited partner English limited partner LP.LP. 2023-0628 |ACTV Title 15: Part ll: Ch.86 -\nof America Pennsylvania Uniform\nLimited Partnership Act of\n2016 § 8612\nPennsylvania\nConsolidated Statutes:\nPDAWLC United States | ;¢ Pennsylvania |US-PA Limited Partnership HSEV general partner English general partner GP, G.P. 2023-06-28 | ACTV Title 15: Part Il Ch.86 -\nof America Pennsylvania Uniform\nLimited Partnership Act of\n2016 § 8612\nPennsylvania\nConsolidated Statutes:\nUEYCCO United States ) Pennsylvania |US-PA Limited Liability oc19 manager English manager Mar. 2023-0628 | ACTV Title 15: Part lll: Ch.88 -\nof America Company Pennsylvania Uniform\nLimited Liability Company\nAct of 2016 § 8812\nPennsylvania\nConsolidated Statutes:\nUnited States . Limited Liability . . . Title 15: Part Ill: Ch.88 -\nVSP4AL of America us Pennsylvania US-PA Company 9C19 organizer English organizer 2023-06-28 ACTV Pennsylvania Uniform\nLimited Liability Company\nAct of 2016 § 8812\nPennsylvania Code: Title\n19 Corporations and\nZN38B5 United States | ;g Pennsylvania |US-PA Business Corporation | 3JTE secretary English secretary Sec. 2023-06-28 |ACTV Business Associations:\nof America Ch.23 Business\nCorporations Generally\n23.51\n2013 Rhode Island\nGeneral Laws: Title 7 -\nCorporations,\nUnited States \" . ot \" \" A \" Associations and\n1RLTWZ of America us Rhode Island US-RI Business Corporation Z54A liquidating receiver English liquidating receiver 2023-06-28 ACTV Partnerships: Ch. 7-1.2\nRhode Island Business\nCorporation Act - Section\n7-1.2-1316\n2013 Rhode Island\nGeneral Laws: Title 7 -\nCorporations,\nUnited States \" . \" \" \" Associations and\nBVAGBG of America us Rhode Island US-RI Business Corporation Z54A registered agent English registered agent 2023-06-28 ACTV Partnerships: Ch, 7-1.2\nRhode Island Business\nCorporation Act - Section\n7-1.2-501\n104/119\n","contentLength":3434,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.718Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"2013 Rhode Island\nGeneral Laws: Title 7 -\nCorporations,\nCHMwaz ~ |United States | ;g Rhode Island [US-RI Business Corporation | Z54A officer English officer 2023-0628 |ACTV Assodlations and\nof America Partnerships: Ch. 7-1.2\nRhode Island Business\nCorporation Act - Section\n7-1.2-105\n2005 Rhode Island Code:\n\" P PR Title 7: Ch. 16 — The\nCNTZJS United States |, Rhode Island | US-RI umited Liability DRSE member English member 2023-0628 |ACTV Rhode Island Limited\nof America Company P\nLiability Company Act § 7-\n16-2\n2013 Rhode Island\nGeneral Laws: Title 7 -\nCorporations,\nCP8NPS United States | ;¢ Rhode Island ~ |US-RI Business Corporation | Z54A voting trustee English voting trustee 2023-0628 | ACTV Assodiations and\nof America Partnerships: Ch. 7-1.2\nRhode Island Business\nCorporation Act - Section\n7-1.2-709\n2013 Rhode Island\nGeneral Laws: Title 7 -\nCorporations,\nD7YHEO United States ;g Rhode Island [US-RI Business Corporation | Z54A treasurer English treasurer 2023-0628 |ACTV Associations and\nof America Partnerships: Ch. 7-1.2\nRhode Island Business\nCorporation Act - Section\n7-1.2-812\n2013 Rhode Island\nGeneral Laws: Title 7 -\nCorporations,\nDGSI1H United States ;g Rhode Island [US-RI Business Corporation | Z54A shareholder English shareholder 2023-0628 |ACTV Assodlations and\nof America Partnerships: Ch. 7-1.2\nRhode Island Business\nCorporation Act - Section\n7-1.2-501\n2005 Rhode Island Code:\n\" P PR Title 7: Ch. 16 — The\nGGSFWD United States |, Rhode Island | US-RI umited Liability DRSE manager English manager Mar. 2023-0628 |ACTV Rhode Island Limited\nof America Company o\nLiability Company Act § 7-\n16-2\n2006 Rhode Island Code:\n\" P PR Title 7: Ch.16 — The\nKKN1LM United States |, Rhode Island | US-RI umited Liability DRSE resident agent English resident agent 2023-06-28 | ACTV Rhode Island Limited\nof America Company o\nLiability Company Act § 7-\n16-11\n2013 Rhode Island\nGeneral Laws: Title 7 -\nCorporations,\nORSBBF United States | ;g Rhode Island | US-RI Business Corporation | Z54A receiver English receiver 2023-06-28 | ACTV Associations and\nof America Partnerships: Ch. 7-1.2\nRhode Island Business\nCorporation Act - Section\n7-1.2-1316\n2013 Rhode Island\nGeneral Laws: Title 7 -\nCorporations,\nPWPKXK United States ;g Rhode Island [US-RI Business Corporation | Z54A secretary English secretary 2023-0628 |ACTV Assodlations and\nof America Partnerships: Ch. 7-1.2\nRhode Island Business\nCorporation Act - Section\n7-1.2-812\n2013 Rhode Island\nGeneral Laws: Title 7 -\nCorporations,\nUnited States Associations and\nRCWMTR of America us Rhode Island US-RI Business Corporation Z54A incorporator English incorporator 2023-06-28 ACTV Partnerships: Ch. 7-1.2\nRhode Island Business\nCorporation Act - Section\n7-1.2-105\n2013 Rhode Island\nGeneral Laws: Title 7 -\nCorporations,\nSJNONF United States | ;g Rhode Island | US-RI Business Corporation | Z54A president English president 20230628 |ACTV Associations and\nof America Partnerships: Ch. 7-1.2\nRhode Island Business\nCorporation Act - Section\n7-1.2-812\n105/119\n","contentLength":3018,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.718Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"2013 Rhode Island\nGeneral Laws: Title 7 -\nCorporations,\nUHDVJL United States ;g Rhode Island [US-RI Business Corporation | Z54A assistant officer English assistant officer 2023-0628 |ACTV Assodlations and\nof America Partnerships: Ch. 7-1.2\nRhode Island Business\nCorporation Act - Section\n7-1.2-812\n2013 Rhode Island\nGeneral Laws: Title 7 -\nCorporations,\nY3CNFC United States ;g Rhode Island [US-RI Business Corporation | Z54A subscriber English subscriber 2023-0628 |ACTV Associations and\nof America Partnerships: Ch. 7-1.2\nRhode Island Business\nCorporation Act - Section\n7-1.2-106\n2013 Rhode Island\nGeneral Laws: Title 7 -\nCorporations,\nYWPOPP United States | ;g Rhode Island | US-RI Business Corporation | Z54A director English director 2023-06-28 | ACTV Assodations and\nof America Partnerships: Ch. 7-1.2\nRhode Island Business\nCorporation Act - Section\n7-1.2-105\nSouth Carolina Code of\nLaws: Title 33: Ch. 18 -\nSouth Carolina Statutory\n\" Close Corporation\nUnited Stat: Statutory CI\n0EQOYY nited States ;g South Carolina |US-SC atutory Close GOHE director English director Dir. 20230628 |ACTV Supplement Note that\nof America Corporation\nChapters 1 through 17 of\nthe Business Corporation\nAct also apply S. 33-18-\n210\nSouth Carolina Code of\n\" P PR Laws: Title 33: Ch. 44 -\nUnited Stat Limited Liabilit:\n10LXMH nited states ;5 South Carolina |Us-sc mited Liability DBGD member English member 2023-06-28 |ACTV Uniform Limited Liability\nof America Company\nCompany Act of 1996 S.\n33-44-103\nSouth Carolina Code of\nLaws: Title 33: Ch. 18 -\nSouth Carolina Statutory\n\" Close Corporation\nUnited Stat: Statutory CI\n4PROAN e States fys South Carolina | US-SC atutory tlose GOHE officer English officer 2023-06-28 |AcTv Supplement Note that\nof America Corporation\nChapters 1 through 17 of\nthe Business Corporation\nAct also apply S. 33-18-\n410\nSouth Carolina Code of\n\" P PR Laws: Title 33: Ch. 44 -\nUnited Stat Limited Liabilit:\n80KGZM nited states ;5 South Carolina |Us-sc mited Liability DBGD manager English manager Mar. 2023-06-28 |ACTV Uniform Limited Liability\nof America Company\nCompany Act of 1996 S.\n33-44-101\nSouth Carolina Code of\n\" P PR Laws: Title 33: Ch. 44 -\nUnited Stat Limited Liabilit:\nAAZCZA nited states ;5 South Carolina |Us-sc mited Liability DBGD organizer English organizer 2023-06-28 |ACTV Uniform Limited Liability\nof America Company\nCompany Act of 1996 S.\n33-44-202\nSouth Carolina Code of\n\" P PR Laws: Title 33: Ch. 44 -\nUnited Stat Limited Liabilit:\nAJH3IP nited states ;5 South Carolina |Us-sc mited Liability DBGD receiver English receiver 2023-06-28 |ACTV Uniform Limited Liability\nof America Company\nCompany Act of 1996 S.\n33-44-504\nSouth Carolina Code of\nLaws: Title 33: Ch. 1 -\nSouth Carolina Business\n\" Corporation Act of 1988\nARUYNP United States | South Carolina [US-SC Statutory Close GOHE subscriber English subscriber 2023-06-28 | ACTV Note that Chapters 1\nof America Corporation\nthrough 17 of the\nBusiness Corporation Act\napply to close\ncorporations S. 33-1-401\nSouth Carolina Code of\nLaws: Title 33: Ch. 1 -\nSouth Carolina Business\n) Corporation Act of 1988\nCYTVWK United States | ;¢ South Carolina |Us-sC Statutory Close GOHE registered agent English registered agent 2023-0628 |ACTV Note that Chapters 1\nof America Corporation through 17 of the\nBusiness Corporation Act\napply to close\ncorporations S. 33-5-101\n106/119\n","contentLength":3353,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.718Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"South Carolina Code of\nLaws: Title 33: Ch. 1 -\nSouth Carolina Business\n\" Corporation Act of 1988\nG1wFoY United States )¢ South Carolina | US-SC Statutory Close GOHE custodian English custodian 2023-06-28 |AcTv Note that Chapters 1\nof America Corporation\nthrough 17 of the\nBusiness Corporation Act\napply to close\ncorporations S. 33-14-320\nSouth Carolina Code of\nLaws: Title 33: Ch. 1 -\nSouth Carolina Business\n\" Corporation Act of 1988\nGeILZW United States )¢ South Carolina | US-SC Statutory Close GOHE chairman English chairman ch. 2023-06-28 |AcTv Note that Chapters 1\nof America Corporation\nthrough 17 of the\nBusiness Corporation Act\napply to close\ncorporations S. 33-1-200\nSouth Carolina Code of\nLaws: Title 33: Ch. 18 -\nSouth Carolina Statutory\n\" Close Corporation\n1GCI2K United States )¢ South Carolina | US-SC Statutory Close GOHE designated director English designated director 2023-06-28 |AcTv Supplement Note that\nof America Corporation\nChapters 1 through 17 of\nthe Business Corporation\nAct also apply S. 33-18-\n210\nSouth Carolina Code of\nLaws: Title 33: Ch. 18 -\nSouth Carolina Statutory\n\" Close Corporation\nIL8MVX United States |, South Carolina |US-SC Statutory Close GOHE shareholder English shareholder 2023-06-28 |ACTV Supplemepnt Note that\nof America Corporation\nChapters 1 through 17 of\nthe Business Corporation\nAct also apply S. 33-18-\n109\nSouth Carolina Code of\nLaws: Title 33: Ch. 1 -\nSouth Carolina Business\n\" Corporation Act of 1988\nLN4ZGO United States |, South Carolina |US-SC Statutory Close GOHE receiver English receiver 2023-0628 |ACTV Note that Chapters 1\nof America Corporation\nthrough 17 of the\nBusiness Corporation Act\napply to close\ncorporations S. 33-14-320\nSouth Carolina Code of\nLaws: Title 33: Ch. 1 -\nSouth Carolina Business\n\" Corporation Act of 1988\nNBJ7M8 United States |, South Carolina |US-SC Statutory Close GOHE incorporator English incorporator 2023-06-28 |ACTV Note that Chapters 1\nof America Corporation\nthrough 17 of the\nBusiness Corporation Act\napply to close\ncorporations S. 33-2-101\nSouth Carolina Code of\nLaws: Title 33: Ch. 18 -\nSouth Carolina Statutory\n\" Close Corporation\nTEKWEB United States |, South Carolina |US-SC Statutory Close GOHE custodian English custodian 2023-06-28 |ACTV Supplemepnt Note that\nof America Corporation\nChapters 1 through 17 of\nthe Business Corporation\nAct also apply S. 33-18-\n410\nSouth Carolina Code of\nLaws: Title 33: Ch. 1 -\nSouth Carolina Business\n\" Corporation Act of 1988\nUHASC6 United States |, South Carolina |Us-sc Statutory Close GOHE trustee English trustee 2023-06-28 |ACTV Note that Chapters 1\nof America Corporation\nthrough 17 of the\nBusiness Corporation Act\napply to close\ncorporations S. 33-1-200\nSouth Carolina Code of\n\" P PR Laws: Title 33: Ch. 44 -\nV15GQD United States |, South Carolina |Us-sc Limited Liability DBGD agent (for service of process) | English agent (for service of process) 2023-06-28 |ACTV Uniform Limited Liability\nof America Company\nCompany Act of 1996 S.\n33-44-108\nSouth Carolina Code of\nLaws: Title 33: Ch. 1 -\nSouth Carolina Business\n\" Corporation Act of 1988\nWLSBIT United States |, South Carolina |Us-sc Statutory Close GOHE secretary English secretary Sec. 2023-06-28 |ACTV Note that Chapters 1\nof America Corporation\nthrough 17 of the\nBusiness Corporation Act\napply to close\ncorporations S. 33-1-400\n107/119\n","contentLength":3339,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.718Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"South Carolina Code of\nLaws: Title 33: Ch. 1 -\nSouth Carolina Business\n\" Corporation Act of 1988\nUnited Stat Statut Cl\nYX0ALZ nited states ;5 South Carolina |Us-sc atutory Close GOHE assistant officer English assistant officer 2023-06-28 |ACTV Note that Chapters 1\nof America Corporation\nthrough 17 of the\nBusiness Corporation Act\napply to close\ncorporations S. 33-8-400\nSouth Dakota Codified\nUnited States Laws: Title 47: Ch.1 -\n04GQOF . us South Dakota Us-sD Business Corporation JZWN director English director Dir. 2023-06-28 ACTV South Dakota Business\nof America :\nCorporation Act 47-1A-\n120\nSouth Dakota Codified\nUnited States Laws: Title 47: Ch.1 -\n3CXv7Q : us South Dakota US-SD Business Corporation JzZwWN chair English chair Ch. 2023-06-28 ACTV South Dakota Business\nof America :\nCorporation Act 47-1A-\n120\nSouth Dakota Codified\n\" P PR Laws: Title 47: Ch.34A -\nUnited Stat Limited Liabilit:\n3x3IC4 oplArenericaa e us South Dakota |US-SD c;”ff'\\ eany'a ity 276 registered agent English registered agent 2023-06-28 |ACTV UNIFORM LIMITED\nP LIABILITY COMPANY ACT\n47-34A-704\nSouth Dakota Codified\nUnited States Laws: Title 47: Ch.1 -\n4HXMFB of America us South Dakota US-SD Business Corporation JzZwWN voting trustee English voting trustee 2023-06-28 ACTV South Dakota Business\nCorporation Act 47-1A-\n730\nSouth Dakota Codified\nUnited States Laws: Title 47: Ch.1 -\n54)GWU of America us South Dakota US-SD Business Corporation JzZwWN officer English officer 2023-06-28 ACTV South Dakota Business\nCorporation Act 47-1A-\n120\nSouth Dakota Codified\nUnited States Laws: Title 47: Ch.1 -\n5PHBRC of America us South Dakota US-SD Business Corporation JzZwWN shareholder English shareholder 2023-06-28 ACTV South Dakota Business\nCorporation Act 47-1A-\n142\nSouth Dakota Codified\nUnited States Laws: Title 47: Ch.1 -\n6YIH7B of America us South Dakota us-sD Business Corporation JZWN president English president Pres. 2023-06-28 ACTV South Dakota Business\nCorporation Act 47-1A-\n120\nSouth Dakota Codified\n\" P PR Laws: Title 47: Ch.34A -\nEJZOHQ gf”:i‘iitcztes us South Dakota |US-SD é'g‘r:e:n';ab'\"ty C276 officer English officer 2023-0628 |ACTV UNIFORM LIMITED\nP LIABILITY COMPANY ACT\n47-34A-411\nSouth Dakota Codified\nUnited States Laws: Title 47: Ch.1 -\nJ4YSDX of America us South Dakota US-SD Business Corporation JzZwWN record shareholder English record shareholder 2023-06-28 ACTV South Dakota Business\nCorporation Act 47-1A-\n1301\nSouth Dakota Codified\nUnited States Laws: Title 47: Ch.1 -\nKJHX45 of America us South Dakota US-SD Business Corporation JzZwWN custodian English custodian 2023-06-28 ACTV South Dakota Business\nCorporation Act 47-1A-\n1432\nSouth Dakota Codified\n\" P PR Laws: Title 47: Ch.34A -\nUnited Stat Limited Liabilit:\nOWU7BK oplArenericaa e us South Dakota |US-SD c;”ff'\\ eany'a ity 276 manager English manager Mar. 2023-06-28 |ACTV UNIFORM LIMITED\nP LIABILITY COMPANY ACT\n47-34A-101\nSouth Dakota Codified\n\" P PR Laws: Title 47: Ch.34A -\nUnited Stat Limited Liabilit:\nPYKWIN oplArenericaa e us South Dakota |US-SD c;”ff'\\ eany'a ity 276 member English member 2023-06-28 |ACTV UNIFORM LIMITED\nP LIABILITY COMPANY ACT\n47-34A-101\nSouth Dakota Codified\nUnited States Laws: Title 47: Ch.1 -\nQ5TDRH of America us South Dakota Us-sD Business Corporation JZWN beneficial shareholder English beneficial shareholder 2023-06-28 ACTV South Dakota Business\nCorporation Act 47-1A-\n1301\nSouth Dakota Codified\n\" P PR Laws: Title 47: Ch.34A -\nUnited Stat Limited Liabilit:\nQGDTDG oplArenericaa e us South Dakota |US-SD c;”ff'\\ eany'a ity 276 receiver English receiver 2023-06-28 |ACTV UNIFORM LIMITED\nP LIABILITY COMPANY ACT\n47-34A-205\nSouth Dakota Codified\nUnited States Laws: Title 47: Ch.1 -\nRTBTKS . us South Dakota Us-sD Business Corporation JZWN incorporator English incorporator 2023-06-28 ACTV South Dakota Business\nof America :\nCorporation Act 47-1A-\n120\n108/119\n","contentLength":3872,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.718Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"South Dakota Codified\nUnited States Laws: Title 47: Ch.1 -\nURSULR . us South Dakota Us-sD Business Corporation JZWN receiver English receiver 2023-06-28 ACTV South Dakota Business\nof America :\nCorporation Act 47-1A-\n120\nSouth Dakota Codified\nUnited States Laws: Title 47: Ch.1 -\nVANRZC . us South Dakota Us-sD Business Corporation JZWN trustee English trustee 2023-06-28 ACTV South Dakota Business\nof America :\nCorporation Act 47-1A-\n120\nSouth Dakota Codified\n) Laws: Title 47: Ch.1 -\nXN8MDP United States | ;g South Dakota |US-SD Business Corporation JZWN senior executive English senior executive snr.Exec. 2023-06-28 |ACTV South Dakota Business\nof America Corporation Act 47-1A-\n1301\nTennessee Code: Title 48\n0YBAXX United States | ;¢ Tennessee US-TN Limited Liability 12XB custodian English custodian 2023-06-28 | ACTV - Tennessee Limited\nof America Company Liability Company Act 48-\n245-904\nTennessee Code: Title 48\n9R63VE United States ;g Tennessee US-TN For-Profit Corporation | QJ9F custodian English custodian 2023-0628 |ACTV - Tennessee Business\nof America Corporation Act 48-24-\n303\nTennessee Code: Title 48\nUnited States Limited Liability \" \" \" - Tennessee Limited\nAQDTK( us T US-TN 12XB tered it English tered t 2023-06-28 ACTV\nQ Q of America ennessee Company registerec agen nglls registerec agen Liability Company Act 48-\n208-101\nTennessee Code: Title 48\nAXDFCR United States | ;¢ Tennessee US-TN Limited Liability 12XB owner English owner 2023-06-28 | ACTV - Tennessee Limited\nof America Company Liability Company Act 48-\n202-103\nTennessee Code: Title 48\nBUJ9DC United States ;g Tennessee US-TN For-Profit Corporation | QJ9F trustee English trustee 2023-0628 |ACTV - Tennessee Business\nof America Corporation Act 48-11-\n301\nTennessee Code: Title 48\nUnited States Limited Liability \" - Tennessee Limited\nBzZ1zQM of America us Tennessee US-TN Company 12XB manager English manager Mar. 2023-06-28 ACTV Liability Company Act 48-\n202-101\nTennessee Code: Title 48\nCLNYIM United States | ;g Tennessee US-TN For-Profit Corporation | QJ9F chair English chair ch. 2023-06-28 |ACTV - Tennessee Business\nof America Corporation Act 48-11-\n301\nTennessee Code: Title 48\nCUBFXB United States ;o Tennessee US-TN Limited Liability 12XB holder of financial rights English holder of financial rights 2023-06-28 |ACTV - Ch.249 - Tennessee\nof America Company Revised Limited Liability\nCompany Act 48-249-102\nTennessee Code: Title 48\nEYDICQ gp:s\\deitca;es us Tennessee US-TN For-Profit Corporation QJ9F incorporator English incorporator 2023-06-28 |ACTV EZ?::;?::AB;S:‘;S]SL\n301\nTennessee Code: Title 48\nUnited States . . \" \" \" - Tennessee Business\nF5NOVM of America us Tennessee US-TN For-Profit Corporation QJOF registered agent English registered agent 2023-06-28 ACTV Corporation Act 48-15-\n101\nTennessee Code: Title 48\nUnited States . . \" \" \" \" - Tennessee Business\nFQXSF6 of America us Tennessee US-TN For-Profit Corporation QJOF director English director Dir. 2023-06-28 ACTV Corporation Act 48-11-\n301\nTennessee Code: Title 48\nGQDVEM United States ;g Tennessee US-TN For-Profit Corporation | QJ9F shareholder English shareholder 2023-0628 |ACTV - Tennessee Business\nof America Corporation Act 48-11-\n201\nTennessee Code: Title 48\nUnited States . . \" \" \" - Tennessee Business\nIEBKPM of America us Tennessee US-TN For-Profit Corporation QJOF president English president Pres. 2023-06-28 ACTV Corporation Act 48-11-\n301\nTennessee Code: Title 48\nIFLNKG United States ) Tennessee US-TN Limited Liability 12XB chief manager English chief manager 2023-0628 | ACTV - Tennessee Limited\nof America Company Liability Company Act 48-\n241-101\nTennessee Code: Title 48\nUnited States . . \" \" . \" - Tennessee Business\nMKNVKE of America us Tennessee US-TN For-Profit Corporation QJOF assistant officer English assistant officer 2023-06-28 ACTV Corporation Act 48-18-\n401\nTennessee Code: Title 48\nOHI356 United States ) Tennessee US-TN Limited Liability 12XB secretary English secretary Sec. 2023-0628 | ACTV - Tennessee Limited\nof America Company Liability Company Act 48-\n241-102\n109/119\n","contentLength":4074,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.718Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Tennessee Code: Title 48\nPTBIYB United States ) Tennessee US-TN Limited Liability 12XB director English director Dir. 2023-0628 | ACTV - €h.249 - Tennessee\nof America Company Revised Limited Liability\nCompany Act 48-249-102\nTennessee Code: Title 48\nUnited States . . \" - Tennessee Business\nToYJow of America us Tennessee US-TN For-Profit Corporation QJOF officer English officer 2023-06-28 ACTV Corporation Act 48-11-\n301\nTennessee Code: Title 48\nT4PNPY United States ) Tennessee US-TN Limited Liability 12XB organizer English organizer 2023-0628 | ACTV - Tennessee Limited\nof America Company Liability Company Act 48-\n203-102\nTennessee Code: Title 48\nUnited States Limited Liability \" \" \" - Ch.249 - Tennessee\nT52274 of America us Tennessee US-TN Company 12XB president English president Pres. 2023-06-28 ACTV Revised Limited Liability\nCompany Act 48-249-401\nTennessee Code: Title 48\nweo7cR |United States ;g Tennessee US-TN Limited Liability 12XB governor English governor Gov. 2023-0628 | ACTV - Tennessee Limited\nof America Company Liability Company Act 48-\n239-101\nTennessee Code: Title 48\n\" . it - Tennessee Limited\nWRIWX9 United States ;g Tennessee US-TN Limited Liability 12XB receiver English receiver 2023-0628 | ACTV Liability Company Act 48-\nof America Company\n245-904\nTennessee Code: Title 48\nUnited States . . \" - Tennessee Business\nWYCNSB of America us Tennessee US-TN For-Profit Corporation QJOF secretary English secretary Sec. 2023-06-28 ACTV Corporation Act 48-11-\n201\nTennessee Code: Title 48\nUnited States ' . . f . - Tennessee Business\nYTQ6AX of America us Tennessee US-TN For-Profit Corporation QJOF receiver English receiver 2023-06-28 ACTV Corporation Act 48-11-\n301\nTennessee Code: Title 48\nZFFS0S United States ;o Tennessee US-TN Limited Liability 12XB member English member 2023-06-28 |ACTV - Tennessee Limited\nof America Company Liability Company Act 48-\n202-102\nTexas Statutes BUSINESS\nORGANIZATIONS CODE\nUnited States . . \" \" \" TITLE 2. CORPORATIONS\n1CAYLK of America us Texas US-TX For-Profit Corporation C5K7 Director English Director 2023-06-28 ACTV CHAPTER 21. FOR-PROFIT\nCORPORATIONS -\n5.21.002\nTexas Statutes BUSINESS\nORGANIZATIONS CODE\nUnited States . . \" TITLE 2. CORPORATIONS\n5C880G of America us Texas US-TX For-Profit Corporation C5K7 Secretary English Secretary 2023-06-28 ACTV CHAPTER 21, FOR-PROFIT\nCORPORATIONS -\n5.21411\nTexas Statutes BUSINESS\nORGANIZATIONS CODE\nUnited States . . \" TITLE 2. CORPORATIONS\n8GYZHT of America us Texas US-TX For-Profit Corporation C5K7 Shareholder English Shareholder 2023-06-28 ACTV CHAPTER 21. FOR-PROFIT\nCORPORATIONS -\n5.21.002\nTexas Statutes BUSINESS\nORGANIZATIONS CODE\nUnited States Limited Liability \" TITLE 3. LIMITED LIABILITY\n9GAXNN of America us Texas US-TX Company WYG5 Manager English Manager 2023-06-28 ACTV COMPANIES CHAPTER\n101. LIMITED LIABILITY\nCOMPANIES - 5.101.0515\nTexas Statutes BUSINESS\nORGANIZATIONS CODE\nUnited States . . \" \" \" TITLE 2. CORPORATIONS\n90BUWO of America us Texas USs-TX For-Profit Corporation C5K7 Assistant secretary English Assistant secretary 2023-06-28 ACTV CHAPTER 21, FOR-PROFIT\nCORPORATIONS -\n5.21411\nTexas Statutes Business\nOrganizations Code TITLE\nUnited States . \" o \" . 4. PARTNERSHIPS\nFOZWPX of America us Texas USs-TX Limited Partnership FEIL Limited partner English Limited partner LP LP 2023-06-28 ACTV CHAPTER 153, LIMITED\nPARTNERSHIPS -\n5.153.003\nTexas Statutes BUSINESS\nORGANIZATIONS CODE\nUnited States . . \" TITLE 2. CORPORATIONS\nHISLG) of America us Texas US-TX For-Profit Corporation C5K7 Officer English Officer 2023-06-28 ACTV CHAPTER 21, FOR-PROFIT\nCORPORATIONS -\n5.21.101\n110/119\n","contentLength":3621,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.718Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Company (includes\nMMCHSF Canada cA British Columbia | CA-BC Egm:;‘:\";t;’nfi’zz'im?gg YG5M Significant individual English Significant individual 2023-0628 |ACTV (Bsué\"cnggzzc)o\"zofi;ol\"f Act\nliability company)\nCompan)./t(inclutd.ebs ti Business Corporations Act\nPJAONC Canada CA British Columbia | CA-BC community contribution 1y gy Director English Director 2023-06-28 |ACTV (SBC 2002) - 55.51.93 &\ncompany and unlimited 120\nliability company)\nCompany (includes\nQ13JFX Canada cA British Columbia | CA-BC community contribution fyc 5y Shareholder English Shareholder 2023-06-28 |ACTV Business Corporations Act\ncompany and unlimited (SBC 2002) -s.17\nliability company)\nCompany (includes\nRYPDAQ Canada cA British Columbia | CA-BC Egm:“a‘:;t;’nf;’::l'i?‘:’itt'gg YG5M Debenture holder English Debenture holder 2023-0628 |ACTV (E’S“;'cnggzzc)\"fz\";g“om‘ Act\nliability company)\nCompany (includes\nTQ7IE Canad. cA British Columbia | CA-BC community contribution YG5M Offi English Offi 2023-0628 |AcTv Business Corporations Act\nQ7y anada ritish Columbia company and unlimited icer nglls icer (SBC 2002) - 5.51.993\nliability company)\nCompany (includes\nUocyza Canad A British Columbial ca-Bc community contribution [ ey Liquidat English Liquidat 2023-0628 | acTv Business Corporations Act\nanada ritish Columbia company and unlimited lquidator nglls quidator (SBC 2002) - 55.319, 334\nliability company)\nCompany (includes\n. \" \" community contribution i 06 Business Corporations Act\nVvo3vzs Canada CA British Columbia | CA-BC company and unlimited YG5M Officer English Officer 2023-06-28 ACTV (SBC 2002) - 5.141\nliability company)\nCompany (includes\nVWHHOY Canad A British Columbial ca-Bc community contribution [ycoy Recei English Recei 2023-0628 | acTv Business Corporations Act\nQ anada ritish Columbia company and unlimited eceiver nglis eceiver (SBC 2002) - £.105\nliability company)\nCompany (includes\n. Nea community contribution - ' - o6 Business Corporations Act\nY8PQTP Canada CA British Columbia | CA-BC company and unlimited YG5M Facilitator English Facilitator 2023-06-28 ACTV (SBC 2002) - 5.20\nliability company)\nCompany (includes\nZGUAW Canada cA British Columbia | CA-BC community contribution fyc 5y Trustee (of a trust indenture) | English Trustee (of a trust indenture) 2023-06-28 |ACTV Business Corporations Act\ncompany and unlimited (SBC 2002) -5.92\nliability company)\nP 5 4 4 4 Loi canadienne sur les\noseen - MoEo -- 20230628 --- coopératives 1998 - 5279\nOXAEMN Canada ca Canada coopérative MGEO détenteur de valeurs French fr détenteur de valeurs 2023-0628 | ACTV Loi canadienne sur les\nmobilieres mobilieres coopératives 1998 - s179\n. . Canada Not-for-profit\nt ithout\no - Esgfizrr?a;?:a\\lm i > o --- e --- i oA\n5116\norganisation sans Loi canadienne sur les\n20L65L Canada CA Canada . \" D90) séquestre French fr séquestre 2023-06-28 ACTV organisations & but non\ncapital-actions .\nlucratif 2009 - s116\n3EASTL Canada cA Canada société de caissede |y administrateur French fr administrateur 2023-0628 |ACTV Loi sur les sociétés de\nretraite caisse de retraite - s8(1)\n32YM90 Canada cA Canada coopérative MGEO liquidateur French fr liquidateur 2023-06-28 |ACTV Loi canadienne sur les\ncoopératives 1998 - s316\n41KEOB Canada cA Canada société de caisse de M4IF administrateur provisoire French fr administrateur provisoire 2023-06-28 |ACTV Loi sur les sociétés de\nretraite caisse de retraite - s4(3)\nCanada Business\n5HVIFX Canada CA Canada business corporation UDLA sequestrator English sequestrator 2023-06-28 ACTV Corporations Act 1985 -\n594\n5NU39X Canada CA Canada chambre de commerce |59T2 président French fr président Pres. 2023-06-28 ACTV Loi sur les chambres de\ncommerce 1985 - s9\nCanada Business\n5YAUSI Canada CA Canada business corporation UDLA shareholder English shareholder 2023-06-28 |ACTV Corporations Act 1985 -\n$6(3)\n12/119\n","contentLength":3834,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.718Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Texas Statutes BUSINESS\nORGANIZATIONS CODE\nUnited States Limited Liability \" TITLE 3. LIMITED LIABILITY\nHXJKGK of America us Texas US-TX Company WYG5 Member English Member 2023-06-28 ACTV COMPANIES CHAPTER\n101. LIMITED LIABILITY\nCOMPANIES - 5.101.0515\nTexas Statutes BUSINESS\nORGANIZATIONS CODE\nUnited States . . \" \" \" TITLE 2. CORPORATIONS\n1QSK2H of America us Texas USs-TX For-Profit Corporation C5K7 Registered agent English Registered agent 2023-06-28 |ACTV CHAPTER 21. FOR-PROFIT\nCORPORATIONS -\n5.21.916\nTexas Statutes BUSINESS\nORGANIZATIONS CODE\nUnited States . . \" \" \" TITLE 2. CORPORATIONS\nIUH9RK of America us Texas US-TX For-Profit Corporation C5K7 Custodian English Custodian 2023-06-28 ACTV CHAPTER 21. FOR-PROFIT\nCORPORATIONS -\n5.21.757\nTexas Statutes BUSINESS\nORGANIZATIONS CODE\nUnited States Limited Liability \" TITLE 3. LIMITED LIABILITY\nKZCOLH of America us Texas US-TX Company WYG5 Officer English Officer 2023-06-28 ACTV COMPANIES CHAPTER\n101. LIMITED LIABILITY\nCOMPANIES - 5.101.052\nTexas Statutes BUSINESS\nORGANIZATIONS CODE\nUnited States Limited Liability \" \" \" TITLE 3. LIMITED LIABILITY\nLOJLLI us T US-TX WYG5 C it b English C it b 2023-06-28 ACTV\n) of America exas Company ommittee member nglls ommittee member COMPANIES CHAPTER\n101. LIMITED LIABILITY\nCOMPANIES -5.101.253\nTexas Statutes BUSINESS\nORGANIZATIONS CODE\nUnited States TITLE 2. CORPORATIONS\nLB46ZC of America us Texas US-TX For-Profit Corporation C5K7 Provisional director English Provisional director 2023-06-28 ACTV CHAPTER 21. FOR-PROFIT\nCORPORATIONS -\n5.21.758\nTexas Statutes BUSINESS\nORGANIZATIONS CODE\nUnited States . . \" \" \" TITLE 2. CORPORATIONS\nLPXO1C of America us Texas US-TX For-Profit Corporation C5K7 Subscriber English Subscriber 2023-06-28 |ACTV CHAPTER 21. FOR-PROFIT\nCORPORATIONS -\n5.21.108\nTexas Statutes BUSINESS\nORGANIZATIONS CODE\nUnited States . . \" TITLE 2. CORPORATIONS\nMSKL5Z of America us Texas US-TX For-Profit Corporation C5K7 Transfer agent English Transfer agent 2023-06-28 ACTV CHAPTER 21, FOR-PROFIT\nCORPORATIONS -\n5.21411\nTexas Statutes BUSINESS\nORGANIZATIONS CODE\nUnited States . . . \" \" TITLE 2. CORPORATIONS\nNPLBRM of America us Texas US-TX For-Profit Corporation C5K7 Beneficial holder English Beneficial holder 2023-06-28 ACTV CHAPTER 21. FOR-PROFIT\nCORPORATIONS -\n5.21.218\nTexas Statutes BUSINESS\nORGANIZATIONS CODE\nUnited States . . \" \" . TITLE 2. CORPORATIONS\nOBI9RHF of America us Texas US-TX For-Profit Corporation C5K7 Organizer English Organizer 2023-06-28 ACTV CHAPTER 21, FOR-PROFIT\nCORPORATIONS -\n5.21.056\nTexas Statutes BUSINESS\nORGANIZATIONS CODE\nUnited States . . \" \" \" TITLE 2. CORPORATIONS\nOM6TXA of America us Texas USs-TX For-Profit Corporation C5K7 President English President 2023-06-28 ACTV CHAPTER 21, FOR-PROFIT\nCORPORATIONS -\n5.21.352\nTexas Statutes BUSINESS\nORGANIZATIONS CODE\nUnited States Limited Liability \" \" \" TITLE 3. LIMITED LIABILITY\nOMUB2X of America us Texas US-TX Company WYG5 Governing person English Governing person 2023-06-28 ACTV COMPANIES CHAPTER\n101. LIMITED LIABILITY\nCOMPANIES -5.101.253\nTexas Statutes Business\nOrganizations Code TITLE\nUnited States . \" \" 4. PARTNERSHIPS\nOSCXEM of America us Texas US-TX Limited Partnership FE1L General partner English General partner GP GP 2023-06-28 ACTV CHAPTER 153. LIMITED\nPARTNERSHIPS -\n5.153.003\nTexas Statutes BUSINESS\nORGANIZATIONS CODE\nUnited States Limited Liability . \" \" TITLE 3. LIMITED LIABILITY\nQPTTV9 of America us Texas US-TX Company WYG5 Authorized officer English Authorized officer 2023-06-28 ACTV COMPANIES CHAPTER\n101. LIMITED LIABILITY\nCOMPANIES - 5.101.0515\n111/119\n","contentLength":3595,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.718Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Texas Statutes BUSINESS\nORGANIZATIONS CODE\nUnited States . . \" \" \" TITLE 2. CORPORATIONS\nRF7MOE of America us Texas US-TX For-Profit Corporation C5K7 Receiver English Receiver 2023-06-28 ACTV CHAPTER 21. FOR-PROFIT\nCORPORATIONS -\n5.21.757\nTexas Statutes Business\nOrganizations Code TITLE\nUnited States . \" \" \" \" 4. PARTNERSHIPS\nWEOSPB of America us Texas US-TX Limited Partnership FE1L Registered agent English Registered agent 2023-06-28 ACTV CHAPTER 153. LIMITED\nPARTNERSHIPS -\n5.153.051\nTexas Statutes Business\nOrganizations Code TITLE\nUnited States . \" \" 4. PARTNERSHIPS\nWZSVM1 of America us Texas US-TX Limited Partnership FE1L Officer English Officer 2023-06-28 ACTV CHAPTER 153, LIMITED\nPARTNERSHIPS -\n5.153.413\nUtah Revised Business\nUnited States . \" Corporation Act - 16-10a-\n2CzCcTw of America us Utah us-ut Profit Corporation 214P Shareholder English Shareholder 2023-06-28 ACTV 102; Utah Code: Title 16\nCorporations: Chapter 10a\nUnited States Utah Code: Title 7\n3AIH4I . us Utah us-ut Commercial Bank 65B6 Vice president English Vice president VP VP 2023-06-28 ACTV Financial Insitutions Act,\nof America\nChapter 1 - 7-1-318\nUnited States Utah Code: Title 7\n82v6MZ . us Utah us-ut Commercial Bank 65B6 Director English Director 2023-06-28 ACTV Financial Insitutions Act,\nof America\nChapter 3 - 7-3-30\nUnited States Utah Code: Title 7\n8MOMKH . us Utah us-ut Commercial Bank 65B6 Officer English Officer 2023-06-28 ACTV Financial Insitutions Act,\nof America\nChapter 3 - 7-3-32\nUtah Revised Business\nUnited States . \" Corporation Act - 16-10a-\nDE2YWR of America us Utah us-ut Profit Corporation 214P Officer English Officer 2023-06-28 ACTV 830; Utah Code: Title 16\nCorporations: Chapter 10a\nUnited States Utah Code: Title 7\nDE6YWG of America us Utah us-ut Commercial Bank 65B6 Shareholder English Shareholder 2023-06-28 ACTV Financial Insitutions Act,\nChapter 3 - 7-3-32\nUtah Revised Business\nUnited States . \" Corporation Act - 16-10a-\nFIPYRZ of America us Utah us-ut Profit Corporation 214P Secretary English Secretary 2023-06-28 ACTV 102; Utah Code: Title 16\nCorporations: Chapter 10a\nUtah Revised Uniform\nLimited Liability Company\nUnited States Limited Liability \" \" \" Act - 48-3a-102; Utah\nFQOINK of America us Utah us-ut Company (LLC) 3ZXC Registered agent English Registered agent 2023-06-28 ACTV Code: Title 48\nUnincorporated Business\nEntity Act, Chapter 3a\nUtah Revised Uniform\nLimited Liability Company\nUnited States Limited Liability \" Act - 48-3a-102; Utah\nISHYEG us Utah us-ut 3zXc Memb: English Memb: 2023-06-28 ACTV .\nof America a Company (LLC) ember nglls ember Code: Title 48\nUnincorporated Business\nEntity Act, Chapter 3a\nUnited States Utah Code: Title 7\nLRCAUR of America us Utah us-ut Commercial Bank 65B6 President English President 2023-06-28 ACTV Financial Insitutions Act,\nChapter 1 - 7-1-318\nUnited States Utah Code: Title 7\nP8HPJX . us Utah us-ut Commercial Bank 65B6 Receiver English Receiver 2023-06-28 ACTV Financial Insitutions Act,\nof America\nChapter 2 - 7-2-9\nUtah Revised Uniform\nLimited Liability Company\nUnited States Limited Liability \" \" . Act - 48-3a-102; Utah\nR4F5T8 us Utah us-ut 3zXc O English Or 2023-06-28 ACTV .\nof America a Company (LLC) rganizer nglls rganizer Code: Title 48\nUnincorporated Business\nEntity Act, Chapter 3a\nUtah Revised Business\nUnited States . \" Corporation Act - 16-10a-\nR7LBYP of America us Utah us-ut Profit Corporation 214P Incorporator English Incorporator 2023-06-28 ACTV 201; Utah Code: Title 16\nCorporations: Chapter 10a\nUtah Revised Uniform\nLimited Liability Company\nUnited States Limited Liability \" Act - 48-3a-102; Utah\nSLT2LU us Utah us-ut 3zXc M English M 2023-06-28 ACTV .\nof America a Company (LLC) anager nglls anager Code: Title 48\nUnincorporated Business\nEntity Act, Chapter 3a\nUtah Revised Business\nUnited States . \" \" \" Corporation Act - 16-10a-\nVZUYEA of America us Utah us-ut Profit Corporation 214P Director English Director 2023-06-28 ACTV 202; Utah Code: Title 16\nCorporations: Chapter 10a\nUnited States Utah Code: Title 7\nW5RQZR . us Utah us-ut Commercial Bank 65B6 Principal shareholder English Principal shareholder 2023-06-28 ACTV Financial Insitutions Act,\nof America\nChapter 3 - 7-3-32\n112/119\n","contentLength":4197,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.718Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"United States Utah Code: Title 7\nXRIOBD of America us Utah us-ut Commercial Bank 65B6 Liquidator English Liquidator 2023-06-28 ACTV Financial Insitutions Act,\nChapter 2 - 7-2-9\nUtah Revised Uniform\nLimited Liability Company\nUnited States Limited Liability \" \" \" Act - 48-3a-102; Utah\nXVEPPK of America us Utah us-ut Company (LLC) 3ZXC Governing person English Governing person 2023-06-28 ACTV Code: Title 48\nUnincorporated Business\nEntity Act, Chapter 3a\nUtah Revised Business\nUnited States . \" \" \" Corporation Act - 16-10a-\nZNBGG9 of America us Utah us-ut Profit Corporation 214P Subscriber English Subscriber 2023-06-28 ACTV 102; Utah Code: Title 16\nCorporations: Chapter 10a\nVermont Statutes: Title\nUnited States 11A: Vermont Business\n8P1TNA of America us Vermont us-vT Profit Corporation NYUD incorporator English incorporator 2023-06-28 ACTV Corporations - Vermont\nBusiness Corporation Act\n§1.20\nVermont Statutes: Title\nUnited States 11A: Vermont Business\nFAH1FV of America us Vermont Us-vT Profit Corporation NYUD subscriber English subscriber 2023-06-28 ACTV Corporations - Vermont\nBusiness Corporation Act\n§1.40\nVermont Statutes: Title\nUnited States 11A: Vermont Business\nFEXVVU of America us Vermont us-vT Profit Corporation NYUD trustee English trustee 2023-06-28 ACTV Corporations - Vermont\nBusiness Corporation Act\n§1.20\nVermont Statutes: Title\nUnited States 11A: Vermont Business\nGLRHKR of America us Vermont us-vT Profit Corporation NYUD officer English officer 2023-06-28 ACTV Corporations - Vermont\nBusiness Corporation Act\n§1.20\nVermont Statutes: Title\nUnited States Limited Liability \" 11: Ch.25 - Limited\nKEUXLE of America us Vermont usS-vT Company (LLC) OE6T manager English manager Mar. 2023-06-28 ACTV Liability Companies §\n4001\nVermont Statutes: Title\nUnited States 11A: Vermont Business\nLBADQR of America us Vermont us-vT Profit Corporation NYUD director English director Dir. 2023-06-28 ACTV Corporations - Vermont\nBusiness Corporation Act\n§1.20\nVermont Statutes: Title\nUnited States Limited Liability \" \" \" 11: Ch.25 - Limited\nNY8POL of America us Vermont usS-vT Company (LLC) OE6T organizer English organizer 2023-06-28 ACTV Liability Companies §\n4022\nVermont Statutes: Title\nOFPMTN gp:s\\deitca;es us Vermont usS-vT gg‘r:::nl;?fll_lg;’ OE6T agent (for service of process) |English agent (for service of process) 2023-06-28 ACTV iila:bfi:;;/zgt;rl;\\l;;r;:iee(is 5\n4007\nVermont Statutes: Title\nUnited States 11A: Vermont Business\nSAFZF) of America us Vermont us-vT Profit Corporation NYUD shareholder English shareholder 2023-06-28 ACTV Corporations - Vermont\nBusiness Corporation Act\n§1.40\nVermont Statutes: Title\nUnited States 11A: Vermont Business\nTBINYV of America us Vermont us-vT Profit Corporation NYUD receiver English receiver 2023-06-28 ACTV Corporations - Vermont\nBusiness Corporation Act\n§1.20\nVermont Statutes: Title\nUnited States 11A: Vermont Business\nU4QEGF of America us Vermont us-vT Profit Corporation NYUD registered agent English registered agent 2023-06-28 ACTV Corporations - Vermont\nBusiness Corporation Act\n§5.01\nVermont Statutes: Title\nUnited States 11A: Vermont Business\nUAVZWY of America us Vermont usS-vT Profit Corporation NYUD secretary English secretary Sec. 2023-06-28 ACTV Corporations - Vermont\nBusiness Corporation Act\n§1.40\nVermont Statutes: Title\nWB7APL United States | ;g Vermont Us-vT Umited Liability OE6T member English member 2023-06-28 |ACTV 11: Ch.25 - Limited\nof America Company (LLC) Liability Companies §\n4001\nVermont Statutes: Title\nUnited States 11A: Vermont Business\nXM2X4U of America us Vermont us-vT Profit Corporation NYUD custodian English custodian 2023-06-28 ACTV Corporations - Vermont\nBusiness Corporation Act\n§14.32\n113/119\n","contentLength":3707,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.719Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Vermont Statutes: Title\nUnited States 11A: Vermont Business\nZOZXV0 of America us Vermont us-vT Profit Corporation NYUD chair English chair Ch. 2023-06-28 ACTV Corporations - Vermont\nBusiness Corporation Act\n§1.20\n\" P PR Code of Virginia: Ch.13 -\nof America Company\nCompany Act § 13.1-1010\n\" P PR Code of Virginia: Ch.13 -\nof America Company\nCompany Act § 13.1-1003\nCode of Virginia: Title\nUnited States 13.1. Corporations: Ch. 9.\n5PHOVX . us Virginia US-VA Stock Corporation HOv4 receiver English receiver 2023-06-28 ACTV Virginia Stock\nof America .\nCorporation Act - § 13.1-\n748\nCode of Virginia: Title\nUnited States 13.1. Corporations: Ch. 9.\n90WMUF . us Virginia US-VA Stock Corporation HOv4 assistant officer English assistant officer 2023-06-28 ACTV Virginia Stock\nof America .\nCorporation Act - § 13.1-\n693\nCode of Virginia: Title\nUnited States 13.1. Corporations: Ch. 9.\nBDKRIQ of America us Virginia US-VA Stock Corporation HOva voting trustee English voting trustee 2023-06-28 ACTV Virginia Stock\nCorporation Act - § 13.1-\n670\nCode of Virginia: Title\nUnited States 13.1. Corporations: Ch. 9.\nBFXG70 of America us Virginia US-VA Stock Corporation HOv4 disinterested director English disinterested director 2023-06-28 ACTV Virginia Stock\nCorporation Act - § 13.1-\n603\nCode of Virginia: Title\nUnited States 13.1. Corporations: Ch. 9.\nBYHPXT of America us Virginia US-VA Stock Corporation HOV4 vice chairman English vice chairman 2023-06-28 ACTV Virginia Stock\nCorporation Act - § 13.1-\n604\nCode of Virginia: Title\nUnited States 13.1. Corporations: Ch. 9.\nCOWAHI of America us Virginia US-VA Stock Corporation HOV4 interest holder English interest holder 2023-06-28 ACTV Virginia Stock\nCorporation Act - § 13.1-\n603\nCode of Virginia: Title\nUnited States 13.1. Corporations: Ch. 9.\nCTOYSK of America us Virginia US-VA Stock Corporation HOv4 subscriber English subscriber 2023-06-28 ACTV Virginia Stock\nCorporation Act - § 13.1-\n603\nCode of Virginia: Title\nUnited States 13.1. Corporations: Ch. 9.\nDFWzovV of America us Virginia US-VA Stock Corporation HOV4 shareholder English shareholder 2023-06-28 ACTV Virginia Stock\nCorporation Act - § 13.1-\n603\nCode of Virginia: Title\nUrited sates s . . . . 13.1. Corporations: Ch. .\nEVHXNO N us Virginia US-VA Stock Corporation HOva registered agent English registered agent 2023-06-28 ACTV Virginia Stock\nof America Corporation Act - § 13.1-\n634\nCode of Virginia: Title\nUnited States 13.1. Corporations: Ch. 9.\nINBXEH of America us Virginia US-VA Stock Corporation HOV4 governor English governor 2023-06-28 ACTV Virginia Stock\nCorporation Act - § 13.1-\n603\nCode of Virginia: Title\nUnited States 13.1. Corporations: Ch. 9.\nJAKGDN of America us Virginia US-VA Stock Corporation HOV4 director English director 2023-06-28 ACTV Virginia Stock\nCorporation Act - § 13.1-\n604\nCode of Virginia: Title\nUnited States 13.1. Corporations: Ch. 9.\nKFWQ4uU of America us Virginia US-VA Stock Corporation HOva secretary English secretary 2023-06-28 ACTV Virginia Stock\nCorporation Act - § 13.1-\n603\n\" P PR Code of Virginia: Ch.13 -\nCompany Act § 13.1-1015\n\" P PR Code of Virginia: Ch.13 -\nof America Company\nCompany Act § 13.1-1015\nCode of Virginia: Title\nUnited States 13.1. Corporations: Ch. 9.\nPRPE9QY of America us Virginia US-VA Stock Corporation HOV4 custodian English custodian 2023-06-28 ACTV Virginia Stock\nCorporation Act - § 13.1-\n748\n114/119\n","contentLength":3382,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.719Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Code of Virginia: Title\nUnited States 13.1. Corporations: Ch. 9.\nPWRURE . us Virginia US-VA Stock Corporation HOv4 officer English officer 2023-06-28 ACTV Virginia Stock\nof America .\nCorporation Act - § 13.1-\n604\nCode of Virginia: Title\nUnited States 13.1. Corporations: Ch. 9.\nPXUNV6 . us Virginia US-VA Stock Corporation HOv4 incorporator English incorporator 2023-06-28 ACTV Virginia Stock\nof America .\nCorporation Act - § 13.1-\n604\nCode of Virginia: Title\nUnited States 13.1. Corporations: Ch. 9.\n\nQMHHAS of America us Virginia US-VA Stock Corporation HOV4 beneficial shareholder English beneficial shareholder 2023-06-28 ACTV Virginia Stock\nCorporation Act - § 13.1-\n603\n\n\" P PR Code of Virginia: Ch.13 -\nof America Company\nCompany Act § 13.1-1002\nCode of Virginia: Title\nUnited States 13.1. Corporations: Ch. 9.\nUlYXm . us Virginia US-VA Stock Corporation HOv4 chairman English chairman 2023-06-28 ACTV Virginia Stock\nof America .\nCorporation Act - § 13.1-\n604\nCode of Virginia: Title\nUnited States 13.1. Corporations: Ch. 9.\n\nVIUPBL of America us Virginia US-VA Stock Corporation HOV4 voting trust beneficial owner English voting trust beneficial owner 2023-06-28 ACTV Virginia Stock\nCorporation Act - § 13.1-\n603\nCode of Virginia: Title\n\nUnited States 13.1. Corporations: Ch. 9.\n\nWO4H3D of America us Virginia US-VA Stock Corporation HOV4 president English president 2023-06-28 ACTV Virginia Stock\nCorporation Act - § 13.1-\n604\n\n\" P PR Code of Virginia: Ch.13 -\nCompany Act § 13.1-1003\n\" P PR Code of Virginia: Ch.13 -\nCompany Act § 13.1-1002\nWashington Revised\nUnited States Code: Title 23B:\n\nOGNSSG of America us Washington US-WA Profit Corporation NHYA director English director Dir. 2023-06-28 ACTV Washington Business\nCorporation Act\n23B.01.200\nWashington Revised\n\nUnited States Code: Title 23B:\n\n1YPK3Q of America us Washington US-WA Profit Corporation NHYA governor English governor Gov. 2023-06-28 ACTV Washington Business\nCorporation Act\n23B.01.400\nWashington Revised\n\nUnited States Code: Title 23B:\n\n37T96L of America us Washington US-WA Profit Corporation NHYA subscriber English subscriber 2023-06-28 ACTV Washington Business\nCorporation Act\n23B.01.400\nWashington Revised\n\nUnited States Code: Title 23B:\n\nB6CNAJC of America us Washington US-WA Profit Corporation NHYA qualified director English qualified director Qual.Dir. 2023-06-28 ACTV Washington Business\nCorporation Act\n23B.01.400\nWashington Revised\n\n) Code: Title 23B:\n6KUHDP United States | ;g Washington US-WA Profit Corporation NHYA chairperson English chairperson Ch. 2023-06-28 |ACTV Washington Business\nof America Corporation Act\n23B.01.200\nWashington Revised\nUnited States Code: Title 23B:\n\nAUKFZ6 of America us Washington US-WA Profit Corporation NHYA president English president Pres. 2023-06-28 ACTV Washington Business\nCorporation Act\n23B.01.200\nWashington Revised\n\nUnited States Code: Title 23B:\n\nAWMWFS of America us Washington US-WA Profit Corporation NHYA officer English officer 2023-06-28 ACTV Washington Business\nCorporation Act\n23B.01.200\nWashington Revised\nCode: Title 25: Ch.25.15\n\nDRCSYX United States ) Washington ~ [US-wA Limited Liability F8DD manager English manager Mar. 2023-0628 | ACTV Limited Liability\n\nof America Company Companies - Washington\nlimited liability company\nact 25.15.006\n115/119\n","contentLength":3301,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.719Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Washington Revised\nUnited States Code: Title 23B:\n\nGF31D4 of America us Washington US-WA Profit Corporation NHYA assistant officer English assistant officer 2023-06-28 ACTV Washington Business\nCorporation Act\n23B.08.400\nWashington Revised\n\nUnited States Code: Title 23B:\n\nIHYOXL of America us Washington US-WA Profit Corporation NHYA shareholder English shareholder 2023-06-28 ACTV Washington Business\nCorporation Act\n23B.01.400\nWashington Revised\n\nUnited States Code: Title 23B:\n\nS1INIDX of America us Washington US-WA Profit Corporation NHYA custodial receiver English custodial receiver 2023-06-28 ACTV Washington Business\nCorporation Act\n23B.14.320\nWashington Revised\n\nUnited States Code: Title 23B:\n\nSEPAO9 of America us Washington US-WA Profit Corporation NHYA incorporator English incorporator 2023-06-28 ACTV Washington Business\nCorporation Act\n23B.01.200\nWashington Revised\n\nUnited States Code: Title 23B:\n\nSKAC40 of America us Washington US-WA Profit Corporation NHYA general receiver English general receiver 2023-06-28 ACTV Washington Business\nCorporation Act\n23B.14.320\nWashington Revised\n\nUnited States Code: Title 23B:\n\nTJYSHN of America us Washington US-WA Profit Corporation NHYA registered agent English registered agent 2023-06-28 ACTV Washington Business\nCorporation Act\n23B.05.010\nWashington Revised\n\nUnited States Code: Title 23B:\n\nUHJCAH of America us Washington US-WA Profit Corporation NHYA receiver English receiver 2023-06-28 ACTV Washington Business\nCorporation Act\n23B.01.200\nWashington Revised\n\nUnited States Code: Title 23B:\n\nVIR9)Z of America us Washington US-WA Profit Corporation NHYA trustee English trustee 2023-06-28 ACTV Washington Business\nCorporation Act\n23B.01.200\nWashington Revised\nCode: Title 25: Ch.25.15\n\nVTMBCP United States ) Washington ~ [US-wA Limited Liability F8DD registered agent English registered agent 2023-0628 | ACTV Limited Liability\n\nof America Company Companies - Washington\nlimited liability company\nact 25.15.021\nWashington Revised\nCode: Title 25: Ch.25.15\nYEXPAK United States | ;¢ Washington ~ [US-wA Limited Liability F8DD member English member 2023-06-28 | ACTV Limited Uability\nof America Company Companies - Washington\nlimited liability company\nact 25.15.007\nWest Virginia Code:\nUnited States o . \" \" \" Ch.31D - West Virginia\n0ERQES of America us West Virginia us-wv Corporation (for profit) IJHI receiver English receiver 2023-06-28 ACTV Business Corporation Act\n§31D-14-1432\nWest Virginia Code: Ch.\nUnited States . Limited Liability \" 31B. UNIFORM LIMITED\n2ATITG of America us West Virginia us-wv Company RC5L manager English manager Mar. 2023-06-28 ACTV LIABILITY COMPANY ACT\n§31B-1-101\nWest Virginia Code:\n57NH00 United States ;g West Virginia ~ |us-wv Corporation (for profit) | JHI subscriber English subscriber 2023-0628 |ACTV Ch.31D - West Virginia\nof America Business Corporation Act\n§31D-1-150\nWest Virginia Code:\n72FFVS United States ;o West Virginia | Us-wv Corporation (for profit) | JHI director English director Dir. 2023-06-28 |ACTV Ch.31D - West Virginia\nof America Business Corporation Act\n§31D-2-201\nWest Virginia Code:\nUnited States L N . Ch.31D - West Virginia\n9E2YES of America us West Virginia us-wv Corporation (for profit) IJHI secretary English secretary Sec. 2023-06-28 ACTV Business Corporation Act\n§31D-1-150\nWest Virginia Code: Ch.\nUnited States o Limited Liability \" \" \" 31B. UNIFORM LIMITED\n9LQLWO us West Vi us-wv RC5L English 2023-06-28 ACTV\nQ of America est Virginia Company receiver nglls receiver LIABILITY COMPANY ACT\n§31B-2-205\nWest Virginia Code: Ch.\nUnited States o Limited Liability \" \" \" 31B. UNIFORM LIMITED\n\nBZFYCA of America us West Virginia us-wv Company RC5L agent (for service of process) |English agent (for service of process) 2023-06-28 ACTV LIABILITY COMPANY ACT\n\n§31B-1-108\n116/119\n","contentLength":3806,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.719Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"West Virginia Code: Ch.\nUnited States o Limited Liability \" \" \" 31B. UNIFORM LIMITED\nLO7XOP us West Vi us-wv RC5L English 2023-06-28 ACTV\nof America est Virginia Company organizer nglls organizer LIABILITY COMPANY ACT\n§31B-2-202\nWest Virginia Code:\nUnited States o . f \" f Ch.31D - West Virginia\nMBVPLE of America us West Virginia us-wv Corporation (for profit) IJHI incorporator English incorporator 2023-06-28 ACTV Business Corporation Act\n§31D-2-201\nWest Virginia Code: Ch.\nUnited States o Limited Liability \" 31B. UNIFORM LIMITED\nMRO9BN us West Vi us-wv RC5L b English b 2023-06-28 ACTV\nof America est Virginia Company member nglls member LIABILITY COMPANY ACT\n§31B-2-203\nWest Virginia Code:\n0DVjax United States ;o West Virginia | Us-wv Corporation (for profit) | JHI shareholder English shareholder 2023-06-28 |ACTV Ch.31D - West Virginia\nof America Business Corporation Act\n§31D-1-150\nWest Virginia Code: Ch.\nUnited States o Limited Liability \" 31B. UNIFORM LIMITED\nPPTKZH us West Vi us-wv RC5L trust: English trust: 2023-06-28 ACTV\nof America est Virginia Company rustee nglls rustee LIABILITY COMPANY ACT\n§31B-2-205\nWest Virginia Code:\nSNAOKL United States ;g West Virginia ~ |us-wv Corporation (for profit) | JHI officer English officer 2023-0628 |ACTV Ch.31D - West Virginia\nof America Business Corporation Act\n§31D-8-840\nWest Virginia Code:\nTSZIAL United States | ;¢ West Virginia ~ [US-WV. Corporation (for profit) | JHI assistant officer English assistant officer 2023-06-28 | ACTV Ch.31D - West Virginia\nof America Business Corporation Act\n§31D-8-840\nWest Virginia Code:\nUnited States o . \" \" \" Ch.31D - West Virginia\nW7GXQB of America us West Virginia us-wv Corporation (for profit) IJHI registered agent English registered agent 2023-06-28 ACTV Business Corporation Act\n§31D-1-150\nWest Virginia Code:\nZXUNSU United States | ;¢ West Virginia ~ [US-WV. Corporation (for profit) | JHI custodian English custodian 2023-06-28 | ACTV Ch.31D - West Virginia\nof America Business Corporation Act\n§31D-14-1432\nWisconsin Code: Ch. 180\n1LGWK? United States ;g Wisconsin us-wi Business Corporation |6532 subscriber English subscriber 2023-0628 |ACTV Business corporations -\nof America Wisconsin business\ncorporation law 180.0103\nWisconsin Code: Ch. 180\n3ASL98 United States | ;g Wisconsin Us-wi Business Corporation | 6532 incorporator English incorporator 2023-06-28 |ACTV Business corporations -\nof America Wisconsin business\ncorporation law 180.0120\n\" P PR Wisconsin Code: Ch. 183\n30WO0A United States |, Wisconsin Us-wi umited Liability M5RM registered agent English registered agent 2023-06-28 | ACTV Limited Liability\nof America Company N\nCompanies 183.0105\nWisconsin Code: Ch. 180\nCFWEOS United States ;g Wisconsin us-wi Business Corporation |6532 receiver English receiver 2023-0628 |ACTV Business corporations -\nof America Wisconsin business\ncorporation law 180.0120\nWisconsin Code: Ch. 180\nCMB7KN United States ;o Wisconsin Us-wi Business Corporation | 6532 director English director Dir. 2023-06-28 | ACTV Business corporations -\nof America Wisconsin business\ncorporation law 180.0120\n\" P PR Wisconsin Code: Ch. 183\nUnited Stat Limited Liabilit:\nHSWYUB nited states ;5 Wisconsin Us-wi mited Liability M5RM organizer English organizer 2023-06-28 |ACTV Limited Liability\nof America Company N\nCompanies 183.0102\nWisconsin Code: Ch. 180\nJIESUG United States | ;¢ Wisconsin us-wi Business Corporation [6532 officer English officer 2023-0628 |ACTV Business corporations -\nof America Wisconsin business\ncorporation law 180.0120\n\" P PR Wisconsin Code: Ch. 183\nMWTRNA United States |, Wisconsin Us-wi umited Liability M5RM manager English manager Mar. 2023-06-28 | ACTV Limited Liability\nof America Company N\nCompanies 183.0102\nWisconsin Code: Ch. 180\nONNBMV United States ;g Wisconsin us-wi Business Corporation |6532 assistant officer English assistant officer 2023-0628 |ACTV Business corporations -\nof America Wisconsin business\ncorporation law 180.0840\nWisconsin Code: Ch. 180\nPGDRUC United States | ;¢ Wisconsin us-wi Business Corporation [6532 trustee English trustee 2023-0628 |ACTV Business corporations -\nof America Wisconsin business\ncorporation law 180.0120\nWisconsin Code: Ch. 180\nSAMALE United S.tates us Wisconsin us-wi Business Corporation 6532 registered agent English registered agent 2023-06-28 |ACTV Bgsmess? corp(?ratlons h\nof America Wisconsin business\ncorporation law 180.0501\nWisconsin Code: Ch. 183\nUnited States A . Limited Liability . Limited Liability\nUKHQBL of America us Wisconsin us-wi Company M5RM member English member 2023-06-28 ACTV Companies 183.0102\n117/119\n","contentLength":4607,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.719Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Wisconsin Code: Ch. 180\nULQRB2 United States ;g Wisconsin us-wi Business Corporation |6532 shareholder English shareholder 2023-0628 |ACTV Business corporations -\nof America Wisconsin business\ncorporation law 180.0103\nWyoming Statutes: Title\n16XVD3 United States | ;¢ Wyoming Us-wy Profit Corporation 9GXA subscriber English subscriber 2023-06-28 | ACTV 17: Ch.16 - Wyoming\nof America Business Corporation Act\n17-16-140\nWyoming Statutes: Title\n6LILAS United States ;g Wyoming Us-wy Profit Corporation 9GXA officer English officer 2023-0628 |ACTV 17: Ch.16 - Wyoming\nof America Business Corporation Act\n17-16-120\nWyoming Statutes: Title\nAESGKY United States ;o Wyoming US-wy Profit Corporation 9GXA trustee English trustee 2023-06-28 |ACTV 17: Ch.16 - Wyoming\nof America Business Corporation Act\n17-16-120\nWyoming Statutes: Title\nUnited States . Limited Liability . . . 17: Ch.29 - Wyoming\nBW5A06 us Wy us-wy NB58 tered it English tered t 2023-06-28 ACTV\nof America yoming Company registerec agen nglls registerec agen Limited Liability Company\nAct 17-29-113\nWyoming Statutes: Title\nBXWGCT United States ;g Wyoming Us-wy Profit Corporation 9GXA incorporator English incorporator 2023-0628 |ACTV 17: Ch.16 - Wyoming\nof America Business Corporation Act\n17-16-120\nWyoming Statutes: Title\n41055 United States | ;¢ Wyoming Us-wy Profit Corporation 9GXA shareholder English shareholder 2023-06-28 | ACTV 17: Ch.16 - Wyoming\nof America Business Corporation Act\n17-16-140\nWyoming Statutes: Title\nDVBXXF United States | ;g Wyoming US-wy Uimited Liability NB58 organizer English organizer 2023-06-28 |ACTV 17: Ch.29 - Wyoming\nof America Company Limited Liability Company\nAct 17-29-104\nWyoming Statutes: Title\nFF4PXP United States ;o Wyoming US-wy Profit Corporation 9GXA receiver English receiver 2023-06-28 |ACTV 17: Ch.16 - Wyoming\nof America Business Corporation Act\n17-16-120\nWyoming Statutes: Title\nHPXHCL United States ;g Wyoming Us-wy Profit Corporation 9GXA voting trustee English voting trustee 2023-0628 |ACTV 17: Ch.16 - Wyoming\nof America Business Corporation Act\n17-16-730\nWyoming Statutes: Title\n191GKS United States | ;¢ Wyoming Us-wy Profit Corporation 9GXA chairman English chairman ch. 2023-06-28 | ACTV 17: Ch.16 - Wyoming\nof America Business Corporation Act\n17-16-120\nWyoming Statutes: Title\nJUP2UM United States | ;g Wyoming US-wy Profit Corporation 9GXA qualified director English qualified director Qual.Dir. 2023-06-28 |ACTV 17: Ch.16 - Wyoming\nof America Business Corporation Act\n17-16-140\nWyoming Statutes: Title\nK62X3C United States ;o Wyoming US-wy Profit Corporation 9GXA secretary English secretary Sec. 2023-06-28 |ACTV 17: Ch.16 - Wyoming\nof America Business Corporation Act\n17-16-140\nWyoming Statutes: Title\nMSFTF8 United States ;g Wyoming Us-wy Profit Corporation 9GXA director English director Dir. 2023-0628 |ACTV 17: Ch.16 - Wyoming\nof America Business Corporation Act\n17-16-120\nWyoming Statutes: Title\nUnited States . Limited Liability . 17: Ch.29 - Wyoming\n09G90S us Wy us-wy NB58 English Mgr. 2023-06-28 ACTV\nof America yoming Company manager nglls manager or Limited Liability Company\nAct 17-29-102\nWyoming Statutes: Title\nUnited States . | Limited Liability . o6 17: Ch.29 - Wyoming\nQ86AYV of America us Wyoming us-wy Company NB58 member English member 2023-06-28 ACTV Limited Liability Company\nAct 17-29-103\nWyoming Statutes: Title\nQKBLHF United States | ;g Wyoming US-wy Profit Corporation 9GXA custodian English custodian 2023-06-28 |ACTV 17: Ch.16 - Wyoming\nof America Business Corporation Act\n17-16-1431\nWyoming Statutes: Title\nVTO16R United States ;o Wyoming US-wy Profit Corporation 9GXA president English president Pres. 2023-06-28 |ACTV 17: Ch.16 - Wyoming\nof America Business Corporation Act\n17-16-120\nWyoming Statutes: Title\nWOX35V United States ;g Wyoming Us-wy Profit Corporation 9GXA beneficial owner English beneficial owner 2023-0628 |ACTV 17: Ch.16 - Wyoming\nof America Business Corporation Act\n17-16-723\nWyoming Statutes: Title\nUnited States . | Limited Liability R . o o6 17: Ch.29 - Wyoming\nYDKZW3 of America us Wyoming us-wy Company NB58 liquidating trustee English liquidating trustee 2023-06-28 ACTV Limited Liability Company\nAct 17-29-211\n118/119\n","contentLength":4203,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.719Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Wyoming Statutes: Title\n\nZVZ5XN United States | ;g Wyoming US-wy Profit Corporation 9GXA registered agent English registered agent 2023-06-28 |ACTV 17: Ch.16 - Wyoming\n\nof America Business Corporation Act\n17-16-140\n\n7CCSF4 Virgin Islands, |G company limited by 6EH6 voting trustee English voting trustee 2023-06-28 |ACTV BVI Business Companies\nBritish shares Act - 5.85(1)\n\nAQWFZY Virgin Islands, ¢ company limited by 6EH6 shareholder English shareholder 2023-06-28 |ACTV BVI Business Companies\nBritish shares Act-s.7\n\nB2VRAT Virgin Islands, | company limited by 6EH6 reserve director English reserve director 2023-06-28 |ACTV BVI Business Companies\nBritish shares Act -5.112\n\nBCH4SB Virgin Islands, ¢ company limited by 6EH6 director English director 2023-06-28 |ACTV BVI Business Companies\nBritish shares Act-s.3\n\nFLOPWG Virgin Islands, ¢ company limited by 6EH6 unlimited member English unlimited member 2023-06-28 |ACTV BVI Business Companies\nBritish shares Act-s.78\n\nK3GU8Z Virgin Islands, | company limited by 6EH6 Insolvency Act liquidator English Insolvency Act liquidator 2023-06-28 |ACTV BVI Business Companies\nBritish shares Act -5.150\nVirgin Islands, company limited by ) e BVI Business Companies\n\nLEOAYF British VG shares 6EH6 agent English agent 2023-06-28 ACTV Act - 5.131\n\nQQ4HOO Virgin Islands, ¢ company limited by 6EH6 alternate director English alternate director 2023-06-28 |ACTV BVI Business Companies\nBritish shares Act -5.112\n\nRBCBA8 Virgin Islands, | company limited by 6EH6 guarantee member English guarantee member 2023-06-28 |ACTV BVI Business Companies\nBritish shares Act-s.4\n\nUJ7GXM Vinjg_in Islands, VG company limited by 6EH6 member English member 2023-06-28 ACTV BVI Business Companies\nBritish shares Act-s.5\n\nUKXDXE Virgin Islands, | company limited by 6EH6 voluntary liquidator English voluntary liquidator 2023-06-28 |ACTV BVI Business Companies\nBritish shares Act-s.8\n\nXSLLWS Virgin Islands, ¢ company limited by 6EH6 custodian English custodian 2023-06-28 |ACTV BVI Business Companies\nBritish shares Act-s.2\n\n1191119\n","contentLength":2055,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.719Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Loi canadienne sur les\n5YAUSI Canada CA Canada société par actions UDLA actionnaire French fr actionnaire 2023-06-28 ACTV sociétés par actions 1985\n56(3)\n. . Canada Not-for-profit\nBATZJU Canada cA Canada - Eggfizrg;g?;‘a‘l'“thom D90) director English - director Dir. - 2023-06-28 |ACTV --- Corporations Act 2009 -\ns2(1)\norganisation sans Loi canadienne sur les\nBATZJU Canada CA Canada capital-actions D90) administrateur French fr administrateur 2023-06-28 ACTV organisations a but non\nP lucratif 2009 - s2(1)\nCanada Business\nBPSQS2 Canada CA Canada business corporation UDLA liquidator English liquidator Lig. 2023-06-28 ACTV Corporations Act 1985 -\n5220\nLoi canadienne sur les\nBPSQS2 Canada CA Canada société par actions UDLA liquidateur French fr liquidateur 2023-06-28 ACTV sociétés par actions 1985\n-5220\nCMNFHI Canada CA Canada chambre de commerce |59T2 vice-président French fr vice-président VP 2023-06-28 ACTV Loi sur les chambres de\ncommerce 1985 - s9\nDOYDXK Canada cA Canada cooperative MGEO officer English officer 2023-06-28 |ACTV Canada Cooperatives Act\n1998 - s2(1), 108\nDOYDXK Canada cA Canada coopérative MGEO dirigeant French fr dirigeant 2023-06-28 | ACTV Loi canadienne sur les\ncoopératives 1998 - s2(1)\nCanada Business\nDLLAN]) Canada CA Canada business corporation UDLA officer English officer 2023-06-28 ACTV Corporations Act 1985 -\n52.1(1)\nLoi canadienne sur les\nDLLAN] Canada CA Canada société par actions UDLA dirigeant French fr dirigeant 2023-06-28 ACTV sociétés par actions 1985\n2(1)\nDNCZBP Canada CA Canada chambre de commerce |[59T2 membre du conseil French fr membre du conseil 2023-06-28 |ACTV Loi sur les chambres de\ncommerce 1985 - s9\nCanada Business\nEKJYLZ Canada CA Canada business corporation UDLA managing director English managing director 2023-06-28 ACTV Corporations Act 1985 -\ns115(1)\nLoi canadienne sur les\nEKJYLZ Canada CA Canada société par actions UDLA administrateur-gérant, French fr administrateur-gérant, 2023-06-28 ACTV sociétés par actions 1985\ns115(1)\nCanada Business\nEQNNG8 Canada CA Canada business corporation UDLA receiver English receiver 2023-06-28 ACTV Corporations Act 1985 -\ns94\nLoi canadienne sur les\nEQNNG8 Canada CA Canada société par actions UDLA séquestre French fr séquestre 2023-06-28 ACTV sociétés par actions 1985\n-s94\nCanada Business\nEWEBY) Canada CA Canada business corporation UDLA receiver-manager English receiver-manager 2023-06-28 ACTV Corporations Act 1985 -\ns95\nLoi canadienne sur les\nEWEBY) Canada CA Canada société par actions UDLA séquestre-gérant French fr séquestre-gérant 2023-06-28 ACTV sociétés par actions 1985\n-s95\nHOEOEV Canada cA Canada société de caisse de M4IF dirigeant French fr dirigeant 2023-06-28 |ACTV Loi sur les sociétés de\nretraite caisse de retraite - s8(2)\n. ’ \" . Canada Cooperatives Act\n11083 - MoEo naten _-- 20230628 --- 1998 - s2(1), 254\nILQSS3 Canada CA Canada coopérative MGEO vérificateur French fr vérificateur 2023-06-28 ACTV Loi ca'na(?ienne sur les\ncoopératives 1998 - s2(1)\n; ; Canada Cooperatives Act\nAt - MoEo naten _-- 20230628 --- 1998 - 5266,271\nITMADL Canada cA Canada coopérative MGEO fiduciaire French fr fiduciaire 2023-06-28 |ACTV Loi canadienne sur les\ncoopératives 1998 - s266\nCanada Business\nJM3EYU Canada CA Canada business corporation UDLA incorporator English incorporator 2023-06-28 ACTV Corporations Act 1985 -\n52.1(1)\nLoi canadienne sur les\nJM3EYU Canada CA Canada société par actions UDLA fondateur French fr fondateur 2023-06-28 ACTV sociétés par actions 1985\n2(1)\nK8PWUX Canada CA Canada chambre de commerce |[59T2 membre French fr membre 2023-06-28 |ACTV Loi sur les chambres de\ncommerce 1985 - s20(1)\nCanada Business\nKH2WSA Canada CA Canada business corporation UDLA security holder English security holder 2023-06-28 |ACTV Corporations Act 1985 -\ns49(1)\n13/119\n","contentLength":3804,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.719Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"5 4 Loi canadienne sur les\nKH2WSA Canada cA Canada société par actions ubLA détenteur de valeurs French fr détenteur de valeurs 2023-06-28 | ACTV sociétés par actions 1985\nmobiliéres mobiliéres s49(1)\no - nese o _M- oroee --- f;;g({asfg;peratwes -\nM6KNXB Canada CA Canada coopérative MGEO administrateur-gérant French fr administrateur-gérant 2023-06-28 ACTV Loi cana(?ienne surles\ncoopératives 1998 - s109\nMHDFVR Canada CA Canada chambre de commerce |[59T2 secrétaire French fr secrétaire Sec. 2023-06-28 |ACTV Loi sur les chambres de\ncommerce 1985 - s11\nMOTBDW |Canada cA Canada société de caissede |y membre French fr membre 2023-0628 |ACTV Loi sur les sociétés de\nretraite caisse de retraite - s11(1)\n. . Canada Not-for-profit\ne e - o - Sfigezrs;:;?arlthom > o oo - o -- R --- S\ns2(1)\norganisation sans Loi canadienne sur les\nMSXJOH Canada CA Canada capital-actions D90J dirigeant French fr dirigeant 2023-06-28 |ACTV organisations & but non\nP lucratif 2009 - s2(1)\n. . Canada Not-for-profit\nt ithout\nMWXUCP Ccanada cA Canada corporation withou D90) sequestrator English sequestrator 20230628 |ACTV Corporations Act 2009 -\nshare capital 5116\n. \" Canada Cooperatives Act\nOK6VLQ Canada CA Canada cooperative MGEO sequestrator English sequestrator 2023-06-28 ACTV 1008 - 5278\nCanada Business\n0QPQIW Canada CA Canada business corporation UDLA trustee English trustee 2023-06-28 ACTV Corporations Act 1985 -\ns82(1)\nLoi canadienne sur les\n0QPQIW Canada CA Canada société par actions UDLA fiduciaire French fr fiduciaire 2023-06-28 ACTV sociétés par actions 1985\ns82(1)\noscezv Canada cA Canada coopérative MGEQ détenteur de parts de French fr détenteur de parts de 2023-0628 |ACTV Loi canadienne sur les\nplacement placement coopératives 1998 - s2(1)\no P . e i Canada Business\no e - o - e oo o Icr::;'lglual o oo - Icr::;'lglual o -- R --- S\n52.1(1)\nR, - - a Loi canadienne sur les\nQOBWIO Canada cA Canada société par actions UDLA particulier ayant un controle | .\\ fr particulier ayant un controle 2023-0628 |ACTV sociétés par actions 1985\nimportant important 210\nR6NSTM Canada CA Canada coopérative MGEO membre French fr membre 2023-06-28 ACTV Loi cana(?ienne sur les\ncoopératives 1998 - s2(1)\n. . Canada Not-for-profit\no - Sfigezrs;:;?arlthom > oo --- e --- iy e\ns117\norganisation sans Loi canadienne sur les\nRJDYUC Canada CA Canada capital-actions D90) séquestre-gérant French fr séquestre-gérant 2023-06-28 ACTV organisations a but non\nP Jucratif 2009 - 5117\nRQSTIK Ccanada cA Canada coopérative MGEO administrateur French fr administrateur 2023-0628 | ACTV Loi canadienne sur les\ncoopératives 1998 - s2(1)\n. . Canada Not-for-profit\nt ithout\nSDJY9 Ccanada cA Canada corporation withou D90) trustee English trustee 20230628 |ACTV Corporations Act 2009 -\nshare capital\n5104(1)\norganisation sans Loi canadienne sur les\nSDJJY9 Canada CA Canada capital-actions D90J fiduciaire French fr fiduciaire 2023-06-28 |ACTV organisations & but non\nP lucratif 2009 - s104(1)\n. . Canada Not-for-profit\nt ithout\nSPPFOE Ccanada cA Canada corporation withou D90) incorporator English incorporator 20230628 |ACTV Corporations Act 2009 -\nshare capital $2(1)\norganisation sans Loi canadienne sur les\nSPPFOE Canada CA Canada . ) D90) fondateur French fr fondateur 2023-06-28 ACTV organisations a but non\ncapital-actions .\nlucratif 2009 - s2(1)\nToYUT Canada cA Canada chambre de commerce [59T2 membre de la personne French fr membre de la personne 2023-0628 | ACTV Loi sur les chambres de\nmorale morale commerce 1985 - s9\nCanada Business\nUSORJS Canada CA Canada business corporation UDLA auditor English auditor 2023-06-28 |ACTV Corporations Act 1985 -\n52.1(1)\n14/119\n","contentLength":3644,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.719Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Loi canadienne sur les\nUSORJS Canada CA Canada société par actions UDLA vérificateur French fr vérificateur 2023-06-28 ACTV sociétés par actions 1985\n-2(1)\nmember of the Board of \" member of the Board of Boards of Trade Act 1989\nVe - poard oftrade e Arbitration (arbitrator) naten _ Arbitration (arbitrator) -- 20230628 --- 321\nVMWVEK Canada cA Canada chambre de commerce |59T2 men.qbre du conseil d'arbitrage French fr men.qbre du conseil d’arbitrage 2023-06-28 ACTV Loi sur les chambres de\n(arbitre) (arbitre) commerce 1985 - s32\n. . Canada Not-for-profit\nWPGITO Canada cA Canada - Eggfizrg;g?;‘a‘l'“thom D90) debt obligation holder English - debt obligation holder -- 2023-0628 |ACTV --- Corporations Act 2009 -\ns22(4)\norganisation sans Loi canadienne sur les\nWPGITO Canada CA Canada capital-actions D90) détenteur de titres de créance |French fr détenteur de titres de créance 2023-06-28 ACTV organisations a but non\nP lucratif 2009 - s22(4)\nCanada Business\nWYPWKM Canada CA Canada business corporation UDLA director English director Dir. 2023-06-28 ACTV Corporations Act 1985 -\ns2.1(1)\nLoi canadienne sur les\nWYPWKM Canada CA Canada société par actions UDLA administrateur French fr administrateur 2023-06-28 ACTV sociétés par actions 1985\n-2(1)\n. . Canada Not-for-profit\nti ithout\nYZHQTH Canada cA Canada corporation withou D90) member English member 20230628 |ACTV Corporations Act 2009 -\nshare capital s7(1)\norganisation sans Loi canadienne sur les\nYZHQTH Canada CA Canada capital-actions D90J membre French fr membre 2023-06-28 ACTV organisations a but non\nP lucratif 2009 - s7(1)\nG o N N I S S N CON N NN I R N I I\nShare corporations .\nThe C t Act\nOLIPXO Ccanada cA Manitoba CA-MB (including professional | FN6X liquidator English liquidator Lig. 20230628 |ACTV Hediatetiiies\ncorporations) .\nShare corporations o . o . _\n. > N N individual with significant . individual with significant The Corporations Act\n2GVNB4 Canada CA Manitoba CA-MB (|nc|ud|n_g professional FN6X control English control 2023-06-28 ACTV 2021-2.1.1\ncorporations)\nShare corporations .\nThe C t Act\n9DIBLG Canada cA Manitoba CA-MB (including professional | FN6X director English director Dir. 2023-06-28 |ACTV 20‘;1 f\"'lptl’ra fons Ad\ncorporations) .\nShare corporations .\nThe C t Act\nAIQQIS Canada cA Manitoba CA-MB (including professional | FN6X attorney English attorney Att. 2023-06-28 |ACTV 20‘;1 ?;’;‘gi fons Ad\ncorporations) .\nShare corporations .\nThe C t Act\nDTYRSC Canada cA Manitoba CA-MB (including professional | FN6X trustee English trustee 2023-06-28 |ACTV 20‘;1 f\";p7°;a fons Ad\ncorporations) .\nShare corporations .\nThe C t Act\nJIZLCT Canada CA Manitoba CA-MB (including professional FN6X receiver manager English receiver manager 2023-06-28 ACTV 2021 f)rgpoora fons Ad\ncorporations)\nShare corporations .\nThe C t Act\nKPB64K Canada cA Manitoba CA-MB (including professional | FN6X officer English officer 2023-06-28 |ACTV 20‘;1 f\";‘;orfl'gns <\ncorporations) \"\nShare corporations .\nMBMDLK Canada cA Manitoba CA-MB (including professional | FN6X security holder English security holder 2023-0628 |ACTV ;g‘;lc?;pso';a“ons Act\ncorporations) .\nShare corporations .\nMNOD6X Canada cA Manitoba CA-MB (including professional | FN6X auditor English auditor 2023-0628 |ACTV ;g‘;ff\"’l\"‘l’ralt;%”i Act\ncorporations) - .\nShare corporations .\nThe C t Act\nR3MKzZC Canada CA Manitoba CA-MB (including professional FN6X incorporator English incorporator 2023-06-28 ACTV 2021 f)rlp(l)ras |(l)n5 <\ncorporations) B\nShare corporations .\nSNB5SH Canada cA Manitoba CA-MB (including professional | FN6X receiver English receiver 2023-0628 |ACTV ;g‘;ff’;‘g’rat'ons Act\ncorporations)\nShare corporations .\nSVGMKF Canada cA Manitoba CA-MB (including professional | FN6X inspector English inspector 2023-0628 |ACTV ;g‘;ff’;\"z‘gal“ons Act\ncorporations) .\nShare corporations .\nWMYQEM Canada cA Manitoba CA-MB (including professional | FN6X guarantor English guarantor 2023-0628 |ACTV ;g‘;ff\"’l‘g’rat'ons Act\ncorporations)\n15/119\n","contentLength":3988,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.719Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Share corporations .\nWWPXX4 Canada cA Manitoba CA-MB (including professional | FN6X shareholder English shareholder 2023-0628 |ACTV ;g;lc?rlp(;ranons Act\ncorporations) .\nShare corporations .\nThe C t Act\nZBIUT6 Canada CA Manitoba CA-MB (including professional FN6X managing director English managing director 2023-06-28 ACTV 2021 f)rlpl(:;'al fons Ad\ncorporations) .\nAn Act Respecting Joint\n170IPV Canada CA Nova Scotia CA-NS unlimited company 42GN security holder English security holder 2023-06-28 ACTV Stock Companies 1989 -\n41\nAn Act Respecting Joint\n2SDNLS Canada CA Nova Scotia CA-NS unlimited company 42GN inspector English inspector 2023-06-28 ACTV Stock Companies 1989 -\n116\ncompany limited by An Act Respecting Joint\n25Q1FI Canada cA Nova Scotia CA-NS shares (limited uuyL auditor English auditor 2023-06-28 |ACTV Stock Companies 1989 -\ncompany) 2,117\ncompany limited by An Act Respecting Joint\n4FBGX) Canada CA Nova Scotia CA-NS shares (limited Uyl inspector English inspector 2023-06-28 ACTV Stock Companies 1989 -\ncompany) 116\nAn Act Respecting Joint\nS5H3PMG Canada CA Nova Scotia CA-NS unlimited company 42GN receiver English receiver 2023-06-28 ACTV Stock Companies 1989 -\n71\ncompany limited by An Act Respecting Joint\nAVXXAA Canada CA Nova Scotia CA-NS shares (limited Uyl officer English officer 2023-06-28 ACTV Stock Companies 1989 -\ncompany) 155\nAn Act Respecting Joint\nDZOHXD Canada CA Nova Scotia CA-NS unlimited company 42GN shareholder English shareholder 2023-06-28 ACTV Stock Companies 1989 -\n19A\nAn Act Respecting Joint\nEDL8UG Canada CA Nova Scotia CA-NS unlimited company 42GN member English member 2023-06-28 |ACTV Stock Companies 1989 -\n12\nAn Act Respecting Joint\nEXMLOH Canada CA Nova Scotia CA-NS unlimited company 42GN receiver manager English receiver manager 2023-06-28 ACTV Stock Companies 1989 -\n97\ncompany limited by An Act Respecting Joint\nGWUMBG Canada CA Nova Scotia CA-NS shares (limited uyl debenture holder English debenture holder 2023-06-28 |ACTV Stock Companies 1989 -\ncompany) 19.4A\ncompany limited by An Act Respecting Joint\nJFTS1G Canada CA Nova Scotia CA-NS shares (limited uyl director English director Dir. 2023-06-28 |ACTV Stock Companies 1989 -\ncompany) 2,93\nAn Act Respecting Joint\nJP7THEP Canada CA Nova Scotia CA-NS unlimited company 42GN officer English officer 2023-06-28 ACTV Stock Companies 1989 -\n155\ncompany limited by An Act Respecting Joint\nKJGUWR Canada CA Nova Scotia CA-NS shares (limited Uyl guarantor English guarantor 2023-06-28 ACTV Stock Companies 1989 -\ncompany) 30\ncompany limited by An Act Respecting Joint\nML2CLQ Canada CA Nova Scotia CA-NS shares (limited uu1 secretary English secretary Sec. 2023-06-28 |ACTV Stock Companies 1989 -\ncompany) 155\ncompany limited by An Act Respecting Joint\nOEKN4R Canada CA Nova Scotia CA-NS shares (limited Uyl shareholder English shareholder 2023-06-28 ACTV Stock Companies 1989 -\ncompany) 19A\ncompany limited by An Act Respecting Joint\nooLum Canada CA Nova Scotia CA-NS shares (limited uu1 manager English manager Mgr. 2023-06-28 ACTV Stock Companies 1989 -\ncompany) 73\ncompany limited by An Act Respecting Joint\nPFGMHM Canada CA Nova Scotia CA-NS shares (limited uyl member English member 2023-06-28 |ACTV Stock Companies 1989 -\ncompany) 12\nAn Act Respecting Joint\nPO6MBP Canada CA Nova Scotia CA-NS unlimited company 42GN debenture holder English debenture holder 2023-06-28 |ACTV Stock Companies 1989 -\n19.4A\ncompany limited by An Act Respecting Joint\nRJMPK9 Canada CA Nova Scotia CA-NS shares (limited uu1 receiver manager English receiver manager 2023-06-28 ACTV Stock Companies 1989 -\ncompany) 97\ncompany limited by An Act Respecting Joint\nS2MOQR Canada CA Nova Scotia CA-NS shares (limited Uyl subscriber English subscriber 2023-06-28 ACTV Stock Companies 1989 -\ncompany) 9c\nAn Act Respecting Joint\nTIKX5B Canada CA Nova Scotia CA-NS unlimited company 42GN director English director Dir. 2023-06-28 |ACTV Stock Companies 1989 -\n2,93\nAn Act Respecting Joint\nTOOJGR Canada CA Nova Scotia CA-NS unlimited company 42GN guarantor English guarantor 2023-06-28 ACTV Stock Companies 1989 -\n30\nAn Act Respecting Joint\nWBBV1T Canada CA Nova Scotia CA-NS unlimited company 42GN auditor English auditor 2023-06-28 ACTV Stock Companies 1989 -\n2,117\n16/119\n","contentLength":4262,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.719Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"An Act Respecting Joint\nWFYQOD Canada CA Nova Scotia CA-NS unlimited company 42GN secretary English secretary Sec. 2023-06-28 ACTV Stock Companies 1989 -\n155\ncompany limited by An Act Respecting Joint\nXNOV5V Canada CA Nova Scotia CA-NS shares (limited Uyl receiver English receiver 2023-06-28 ACTV Stock Companies 1989 -\ncompany) 71\ncompany limited by An Act Respecting Joint\nXRH8B8 Canada CA Nova Scotia CA-NS shares (limited Uyl security holder English security holder 2023-06-28 ACTV Stock Companies 1989 -\ncompany) 41\nAn Act Respecting Joint\nXSBCNH Canada CA Nova Scotia CA-NS unlimited company 42GN subscriber English subscriber 2023-06-28 ACTV Stock Companies 1989 -\n9c\ncompany limited by An Act Respecting Joint\nZKIR2) Canada CA Nova Scotia CA-NS shares (limited Uyl share warrant bearer English share warrant bearer 2023-06-28 ACTV Stock Companies 1989 -\ncompany) 47\nAn Act Respecting Joint\nZLWS5PG Canada CA Nova Scotia CA-NS unlimited company 42GN manager English manager Mar. 2023-06-28 ACTV Stock Companies 1989 -\n73\nNot-For-Profit Not-for-Profit\n6MOY0B Canada CA Ontario CA-ON corporations CMB6 Auditor English Auditor 2023-06-28 ACTV Corporations Act, 2010 -\n.68\nNot-for-Profit\n. Not-For-Profit \" Corporations Act, 2010 -\n60RGDR Canada CA Ontario CA-ON corporations CMB6 Member English Member 2023-06-28 ACTV s 48\nNot-For-Profit Not-for-Profit\nBEDGOI Canada CA Ontario CA-ON corporations CMB6 Inspector English Inspector 2023-06-28 ACTV Corporations Act, 2010 -\n5.174\nNot-For-Profit Not-for-Profit\nDRWMKR Canada CA Ontario CA-ON Corporations CMB6 Director English Director 2023-06-28 ACTV Corporations Act, 2010 -\nP ss.1,17,21\nBusiness corporations\nESBPNY Canada cA Ontario CA-ON {which indudes 090R Chief financial officer English Chief financial officer cFO cFO 2023-06-28 |ACTV Business Corporations\nprofessional Act, 1990 -5.127\ncorporations)\nBusiness corporations\nFNLLSB Canada cA Ontario CA-ON (which includes 090R President English President 2023-0628 | ACTV Business Corporations\nprofessional Act, 1990 -5.127\ncorporations)\nNot-For-Profit Not-for-Profit\nHC7KPL Canada CA Ontario CA-ON corporations CMB6 Managing director English Managing director 2023-06-28 ACTV Corporations Act, 2010 -\n5.36\n\" Not-for-Profit\n. Not-For-Profit Chair (of the board of . . )\nHGGWIE Canada CA Ontario CA-ON corporations CMB6 directors) English Chair 2023-06-28 ACTV :c‘;‘rzporatlons Act, 2010 -\nNot-For-Profit Not-for-Profit\nHLBGSV Canada CA Ontario CA-ON corporations CMB6 Proxyholder English Proxyholder 2023-06-28 ACTV Corporations Act, 2010 -\n5.66\nBusiness corporations\n: ~ (which includes P \" P 06 Business Corporations\nKUQzUK Canada CA Ontario CA-ON professional 090R Liquidator English Liquidator 2023-06-28 ACTV Act. 1000 - 5,193\ncorporations)\nBusiness corporations\n. ] (which includes . ' A o6 Business Corporations\nLO2S68 Canada CA Ontario CA-ON professional 090R Managing director English Managing director 2023-06-28 ACTV Act, 1990 - 5,127\ncorporations)\nBusiness corporations\nOMP700 Canada cA Ontario CA-ON (which includes 090R Senior officer English Senior officer 2023-0628 | ACTV Business Corporations\nprofessional Act, 1990 -ss.1\ncorporations)\nNot-For-Profit Not-for-Profit\nOR7PCM Canada CA Ontario CA-ON corporations CMB6 Incorporator English Incorporator 2023-06-28 ACTV Corporations Act, 2010 -\nss.1,7\nBusiness corporations\n. ] (which includes \" o6 Business Corporations\nOTBTOG Canada CA Ontario CA-ON professional 090R Inspector English Inspector 2023-06-28 ACTV Act, 1990 - 5,194\ncorporations)\nBusiness corporations\nPOGUVV Canada cA Ontario CA-ON {which indudes 090R Officer English Officer 2023-06-28 |ACTV Business Corporations\nprofessional Act, 1990 -ss.1, 133\ncorporations)\nBusiness corporations\nP3ETLF Canada cA Ontario CA-ON (which indudes 090R Director English Director 2023-06-28 |ACTV Business Corporations\nprofessional Act, 1990 -ss.1, 115\ncorporations)\n17/119\n","contentLength":3894,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.719Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Business corporations\nPKOFOK Canada cA Ontario CA-ON (which includes 090R Proxyholder English Proxyholder 2023-0628 | ACTV Business Corporations\nprofessional Act, 1990 -5.110\ncorporations)\nBusiness corporations\n. ] (which includes ’ ' ’ o6 Business Corporations\nPXTIO) Canada CA Ontario CA-ON professional 090R Contributory English Contributory 2023-06-28 ACTV Act, 1090 - 5.191\ncorporations)\nNot-For-Profit Not-for-Profit\nQHD6KD Canada CA Ontario CA-ON corporations CMB6 Debt obligation holder English Debt obligation holder 2023-06-28 ACTV Corporations Act, 2010 -\n5.174\nBusiness corporations\nTHQE6A Canada cA Ontario CA-ON (which includes 090R Auditor English Auditor 2023-0628 | ACTV Business Corporations\nprofessional Act, 1990 -5.149\ncorporations)\nBusiness corporations\nUDGMGF | canada cA Ontario CA-ON (which includes 090R Shareholder English Shareholder 2023-06-28 | ACTV Business Corporations\nprofessional Act, 1990 -5.22\ncorporations)\n. Not-For-Profit . Not-for-Profit\nVOA2N2 Canada CA Ontario CA-ON corporations CMB6 Officer English Officer 2023-06-28 ACTV Corporations Act, 2010 -\n5.42\nBusiness corporations\nvuuzu3 Canada cA Ontario CA-ON (which includes 090R Chair English Chair 2023-06-28 | ACTV Business Corporations\nprofessional Act, 1990 -5.127\ncorporations)\nNot-For-Profit Not-for-Profit\nVZPBAR Canada CA Ontario CA-ON corporations CMB6 Liquidator English Liquidator 2023-06-28 ACTV Corporations Act, 2010 -\n5.123\nBusiness corporations\n(which includes Business Corporations\nW3AHLU Canada CA Ontario CA-ON professional 090R Incorporator English Incorporator 2023-06-28 ACTV Act, 1990 - ss.1,\ncorporations)\nBusiness corporations\nWUXIBT Canada cA Ontario CA-ON (which includes 090R Trustee (of a trust indenture) | English Trustee (of a trust indenture) 2023-0628 | ACTV Business Corporations\nprofessional Act, 1990 -5.46\ncorporations)\nNot-For-Profit Not-for-Profit\nYPZMG3 Canada CA Ontario CA-ON : CMB6 Contributory English Contributory 2023-06-28 ACTV Corporations Act, 2010 -\ncorporations\n$s.121, 130\nSociété par actions par \" -\nL I t\nAWMKMT | canada ca Québec cA-Qc Loi sur les sociétés par [UG3Z Administrateur French fr Administrateur 20230628 |ACTV 01 sur les societes par\nactions actions, 2011 - Art.5.8\nSociété par actions par \" -\n£ . 4k £ £ Loi sur les sociétés par\nCBZKJF Canada CA Québec CA-QC Ia.zltiilrj‘rsles sociétés par |UG3Z Séquestre French fr Séquestre 2023-06-28 |ACTV actions, 2011 - Art.451.2\nSociété par actions par \" s\n£ . 4k Lt . Loi sur les sociétés par\nFTDR2G Canada CA Québec CA-QC Ia.zltiilrj‘rsles sociétés par |UG3Z Président French fr Président 2023-06-28 |ACTV actions, 2011 - Art.118.3\nLoi sur la publicité 1égale\ndes entreprises\nH3JKVG Canada CA Québec CA-QC Société en commandite |RQIC Commandité French fr Commandité 2023-06-28 ACTV individuelles, des sociétés\net des personnes\nmorales, 2010 - Art.11\nSociété par actions par Loi sur les sociétés par\nJQDEYE Canada CA Québec CA-QC Loi sur les sociétés par |UG3Z Dirigeant French fr Dirigeant 2023-06-28 |ACTV actions, 2011 - Arts.2,\nactions 116\nSociété par actions par \" s\n4 \" A Lot P Loi sur les sociétés par\nKFS87F Canada CA Québec CA-QC Loi sur les sociétés par |UG3Z Veérificateur French fr Veérificateur 2023-06-28 |ACTV actions, 2011 - Art.231\nactions\nSociété par actions par \" -\n4 \" A . . . . Loi sur les sociétés par\nKNIDAR Canada CA Québec CA-QC Loi sur les sociétés par |UG3Z Actionnaire French fr Actionnaire 2023-06-28 |ACTV actions, 2011 - Art.7\nactions\nSociété par actions par \" -\n4 \" A - - Loi sur les sociétés par\nLIlYBW Canada CA Québec CA-QC Loi sur les sociétés par |UG3Z Liquidateur French fr Liquidateur 2023-06-28 ACTV actions, 2011 - Art.325\nactions\nSociété par actions par \" -\n4 \" A PR PN PP Loi sur les sociétés par\nQV3MLQ Canada CA Québec CA-QC Loi sur les sociétés par |UG3Z Bénéficiaire French fr Bénéficiaire 2023-06-28 |ACTV actions, 2011 - Arts.2\nactions\nSociété par actions par \" s\n4 \" A . T . - Loi sur les sociétés par\nSHZJH1 Canada CA Québec CA-QC Ia-zltif:\\rsles sociétés par |UG3Z Responsable de I'exploitation | French fr Responsable de I’exploitation 2023-06-28 |ACTV actions, 2011 - Art.118.3\nSociété par actions par \" s\n4 \" 4k Loi sur les sociétés par\nSNJ5QF Canada CA Québec CA-QC Ia-zltif:\\rsles sociétés par |UG3Z Responsable des finances French fr Responsable des finances 2023-06-28 |ACTV actions, 2011 - Art.118.3\nSociété par actions par \" s\n4 \" 4k Loi sur les sociétés par\nUAPQXT Canada CA Québec CA-QC Loi sur les sociétés par |UG3Z Fondateur French fr Fondateur 2023-06-28 |ACTV actions, 2011 - Art.3\nactions\n18/119\n","contentLength":4569,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.719Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Loi sur la publicité 1égale\ndes entreprises\nVXAUBK Canada CA Québec CA-QC Société en commandite |RQIC Commanditaire French fr Commanditaire 2023-06-28 ACTV individuelles, des sociétés\net des personnes\nmorales, 2010 - Art.11\nSociété par actions par \" s\n4 \" A £ \" £ \" Loi sur les sociétés par\ne o o reneedeponer e ' reneedepaer -- R --- actions, 2011 - A173\nactions\nSociété par actions par \" s\n4 \" A \" . \" . Loi sur les sociétés par\ne o o espersmpiedelsdrecton e ' esporsmpie el drecton -- R --- actions, 2011 - Art118.3\nOQUESFV Cayman Ky limited liability company | MPUG member English member 2023-06-28 |ACTV Limited Lability\nIslands Companies Act - 5.2\nCayman exempted limited . ) . Exempted Limited\n5YUIGY Ky 6XB7 I I part English Iify I part 2023-0628 | ACTV\nIslands -- partnership qualifying general partner gl qualifying general partner Partnership Act - 5.4(4)\nAFOUBW Cayman Ky company limited by 0SBR shadow director English shadow director 2023-06-28 |ACTV Companies Act (2022\nIslands shares Revision) - s89\nDS6DNK Cayman Ky company limited by 0SBR subscriber English subscriber 2023-06-28 |ACTV Companies Act (2022\nIslands shares Revision) - s12\nDXWS38 Cayman Ky company limited by 0SBR auditor English auditor 2023-06-28 |ACTV Companies Act (2022\nIslands shares Revision) - Table A 43\nEHFTNO Cayman Ky limited partnership XAQA limited partner English limited partner LP. L.P. 2023-06-28 |ACTV Partnership Law (2013\nIslands Revision) - s46.2\nEW065H Cayman Ky limited liability company | MPUG manager English manager Mar. 2023-06-28 |ACTV Limited Liability\nIslands Companies Act - 5.2, 26\nFQQLUA Cayman Ky exempted limited 6XB7 limited partner English limited partner LP. L.P. 2023-0628 | ACTV Exempted Limited\nIslands partnership Partnership Act - 5.2\nGJLBVI Cayman Ky company limited by 0SBR beneficial owner English beneficial owner 2023-06-28 |ACTV Companies Act (2022\nIslands shares Revision) - s244\nCayman T - I - e Limited Liability\nGX90K8 Islands N -- mited liability company | MPUG redistrable person Engtisn _ redistrable person -- 20230628 JACTY --- Companies Act - 5.77\nIDISVT Cayman Ky company limited by 0SBR inspector English inspector 2023-06-28 |ACTV Companies Act (2022\nIslands shares Revision) - s67\nCayman - . . Limited Liability\nIXBETU Islands KY limited liability company | MPUG officer English officer 2023-06-28 ACTV Companies Act - 5.104\nLPB2BS Cayman Ky company limited by 0SBR officer English officer 2023-06-28 |ACTV Companies Act (2022\nIslands shares Revision) - s2.1\nNSRV24 Cayman Ky company limited by 0SBR alternate director English alternate director Alt.Dir. 2023-06-28 |ACTV Companies Act (2022\nIslands shares Revision) - s55\nPVBFEP Cayman Ky company limited by 0SBR member English member 2023-06-28 |ACTV Companies Act (2022\nIslands shares Revision) - s6\nQSEQIN Cayman Ky company limited by 0SBR shareholder English shareholder 2023-06-28 |ACTV Companies Act (2022\nIslands shares Revision) - s37\nREH3J0 Cayman Ky company limited by 0SBR director English director Dir. 2023-06-28 |ACTV Companies Act (2022\nIslands shares Revision) - s55, 78\nCayman company limited by o ) o ] e Companies Act (2022\nUKWP2Z \\slands KY -- shares OSBR liquidator English liquidator Lig. 2023-06-28 ACTV Revision) - 589, 119\nVOH19Z Cayman Ky company limited by 0SBR controller English controller 2023-06-28 |ACTV Companies Act (2022\nIslands shares Revision) - s89\nCayman exempted limited . e Exempted Limited\nVVOVM9 Islands KY -- partnership 6XB7 general partner English general partner GP, G.P. 2023-06-28 ACTV Partnership Act - 5.2\nWF7IY4 Cayman Ky limited liability company | MPUG beneficial owner English beneficial owner 2023-06-28 |ACTV Limited Liability\nIslands Companies Act - 5.73\nCayman o . ) e Partnership Law (2013\ne -- mited partnership XA Enatish _ eren - 020028 A --- Revision) - 546.2\n; ; -- Y=y\nOUIERB China cN Bl ECAK SEATIREBHAT I REA |Chinese zh wai guo gong si zhong guo jing 2023-06-28 |ACTV FEARFME AT #2018\nnei fen zhi ji gou dai biao ren FH—ERF-EHLT=R\nTR TR0t\n2RIHMT China cN Bl ECAK XN Chinese zh shi ji kong zhi ren 2023-06-28 |ACTV TN RSE AF£2018\nBoEBTAR\ne \\RAMEESBLRE\n3AVSUI China N (=i GGZ5 B2 R Chinese 2h dan wei hui yuan 2023-06-28 |ACTV (5 R (20165 =5\nB+&\ne \\RAMEESBLRE\n3UTHOO China N MEE 6GZ5 A Chinese 2h fa i ren 2023-0628 | ACTV HBIRERANIN16H =%\nBAE\n. J s \" \" EAREMEESRESLE\n4UBW2R China CN e 2M6Y fhk Chinese h mi shu zhan 2023-06-28 |ACTV HEA iy\nT mn ——e\nY=y,\n—EH &\n19/119\n","contentLength":4433,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.720Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"2006-5 WEF/\\+ 7%\nFoEF-FRNR\n_ ) _ _ i \\REAEESE S\n-- - §§RI1)§}\\J’% e - eensmsengmoren e -- e o --- Fg}g%mjzomr%fifi;m#—z\n=\nMEF-FE—EFET-R\ni = . e NRFME S kb\n-- mfi§%é{k}\\ e - oS neoren -- e . --- 20;}27%:fi¥3’fi¥é+7\\<\nEd\nBOERNTHE—E—+L%\nBoERE—R\nB-EBT=R\nEE A F004- B FE R\n-- %§%E% 20230628 A q:ifi}\\g;t‘%u@/&afiiz{nsr\nBoEBVEET R\n_ N _ hip N\\RAEMEESEHEILE\nFXDBSO China CN -- Fl g B5UZ AFA Chinese zh fu ze ren 2023-06-28 |ACTV (fiélfi\"é‘figfi%m}ém%\nZEBA/NF\nBF-EBT=R\nmi shu BOERETE B _+=%\nnei fen zhi ji gou dai li ren FH—ERF-EHLT=R\n2006-F—FEE—R\nFNEF—FE/\\+ IR\nBoEBIHOT AR\nFER+—F\nFIERCFRE=ALR\n-- H‘:fifilij\\ ----- ;fggfzfiflaifi%nsr\nBEEB-TEAT R\nFEAFR004-B_FESF 5\ni 3 . he huo qi ye jing yi li e \\RFME S ki\nEd\n2006-F —FEB R\n2006- B HERNA+R%\nBF-EBT=R\nLES-FE+HLR\nBERBZTENL =R\nFER+—F\nBERBZTENL =R\nBZEBZTENLT—%\nshi FNEFATE—EH_+=%\nERAG204-B—FEE &\nFEER=FR/ 4+ NE\n2006-F—FEE—R\n207119\n","contentLength":853,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.720Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"FVO4ID Austria AT Gesellschaft mit AXSB Vertreter German Vertreter 2023-06-28 | ACTV GmbH-Gesetz 30e\nbeschrankter Haftung\nHRV7FF Austria AT Gesellschaft mit AXSB Gesellschafter German Gesellschafter 2023-06-28 | ACTV GmbH-Gesetz 4.4\nbeschrankter Haftung\nHUFs2C Austria AT Gesellschaft mit AXSB Stellvertreter German Stellvertreter 2023-0628 |ACTV GmbH-Gesetz 27\nbeschrankter Haftung\nJBKGUA Austria AT Gesellschaft mit AXSB Liquidator German Liquidator Lig. 2023-0628 | ACTV GmbH-Gesetz 39\nbeschrankter Haftung\nX3UGSY Austria AT Gesellschaft mit AXSB Geschaftsflhrer (des German Geschaftsflhrer (des 2023-06-28 | ACTV GmbH-Gesetz 3.2\nbeschrankter Haftung Vorstandes) Vorstandes)\nXEUVGT Austria AT Gesellschaft mit AXSB Vorsitzender German Vorsitzender 2023-06-28 | ACTV GmbH-Gesetz 28a\nbeschrankter Haftung\n23 MARS 2019. — Loi\nintroduisant le Code des\nsociétés et des\nOREMJF Belgium Société anonyme R85P Commissaire French fr Commissaire 2023-06-28 ACTV associations et portant\ndes dispositions diverses -\nLivre 3: Titre 4: CHAPITRE\n1: Art. 3:58\n23 MAART 2019. — Wet\ntot invoering van het\nWetboek van\nvennootschappen en\nOREMJF Belgium Naamloze vennootschap | R85P Commissaris Dutch Commissaris 2023-06-28 ACTV verenigingen en\nhoudende diverse\nbepalingen - BOEK 3:\nTITEL 4: HOOFDSTUK 1:\nArt.3:58\n23 MARZ 2019. —\nOREMJF Belgium Aktiengesellschaft R85P Wirtschaftspriifer German Wirtschaftspriifer 2023-06-28 [ACTV Gesetzbuch der\nGesellschaften und\nVereinigungen\n23 MARS 2019. — Loi\nintroduisant le Code des\n- iétés et des\n) Association sans but Membre de I'organe de Membre de I'organe de socle. )\n1TAXG9 Belgium lucratif W3WH gestion journaliere French fr gestion journaliere 2023-06-28 ACTV assoc_latlor}s_ et po_rtant\ndes dispositions diverses -\nLivre 9: Titre 2: CHAPITRE\n1: Art. 9:10\n23 MAART 2019. — Wet\ntot invoering van het\nWetboek van\nVereniging zonder Lid van bestuursorgaan het Lid van bestuursorgaan het vennootschappen en\n1TAXG9 Belgium ; W3WH dagelijks bestuur van de Dutch dagelijks bestuur van de 2023-06-28 ACTV verenigingen en\nwinstoogmerk b b \"\nvereniging vereniging houdende diverse\nbepalingen - BOEK 9:\nTITEL 2: HOOFDSTUK 1:\nArt.9:10\n23 MARZ 2019. —\n1TAXGY Belgium Vereinigung ohne 3y Mitglied des taglichen German Mitglied des taglichen 2023-06-28 |ACTV Gesetzbuch der\nGewinnerzielungsabsicht Leitungsorgans Leitungsorgans Gesellschaften und\nVereinigungen\n23 MAART 2019. — Wet\ntot invoering van het\nWetboek van\nvennootschappen en\n23SDIY Belgium Besloten Vennootschap |3W7E Lid van het bestuursorgaan Dutch Lid van het bestuursorgaan 2023-06-28 ACTV verenigingen en\nhoudende diverse\nbepalingen - BOEK 2:\nTITEL 6: HOOFDSTUK 2:\nArt.2:56\n3/119\n","contentLength":2660,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.720Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"i Y\nf : . f \" N R E Rk £12020-\nSFN2PG China CN grilEs GGZ5 3 Chinese h hui zhan 2023-06-28 ACTV 411— Ryt\n-- - - i o -- --- FEERZTRA—R\ni T -\ni \\RAFMEES i 2 E\nVFMMND China CN el GGZ5 AR Chinese zh ge ren hui yuan 2023-06-28 |ACTV EBIDEEEAF016H=F\nBl\n. 3 . N R E Rk £12020-\nW57YAL China CN grilEs GGZ5 3 Chinese h fu ze ren 2023-06-28 ACTV 411— Ryt\n-- e o i i -- --- BEEBZTH MR\ni \\RAFEES i 2 E\nWwMI3I3 China CN el GGZ5 EIRTIEAR Chinese zh zhuan zhi gong zuo ren yuan 2023-06-28 |ACTV EBIDEEEF0I6H =R\nF&\ni kel\nXQSVN1 China CN el ECAK SR/ ON Chinese zh pu tong he huo ren 2023-06-28 |ACTV EF*AEMDEL” Pl\n2006-5F —FH 5K\nf f f N RHAE LT #2018\nXRUDM China CN el ECAK 55 £73% A Chinese h cai wu fu ze ren 2023-06-28 ACTV 411— o\n° -- - e i i -- --- BoEP- TR E\ni =T -\ni e\ni =T }\nZT24CH China cN Bl ECAK nE Chinese zh jian shi 2023-06-28 |ACTV TN RAME AF£2018\nFER+—F\nLov om aktie- og\n1TCNZ5 Denmark DK Anpartsselskab H8VP kapitalejer Danish kapitalejer 2023-06-28 ACTV anpartsselskaber\n(selskabsloven) §50\nLov om aktie- og\n2KL6BY Denmark DK Aktieselskab ZRPO direktor Danish direktor Dir. 2023-06-28 ACTV anpartsselskaber\n(selskabsloven) §111.1\nBekendtggrelse af lov om\n45Q06L Denmark DK Fond 1IMWR revisor Danish revisor 2023-06-28 |ACTV erhvervsdrivende fonde\n§13\n- \" - \" Bekendtggrelse af lov om\nuvildige sagkyndige \" uvildige sagkyndige .\n51PZZ7 Denmark DK -- Fond 1IMWR vurderingsmand Danish vurderingsmand 2023-06-28 |ACTV ;;I;vervsdrlvende fonde\nBekendtggrelse af lov om\n6YTAID Denmark DK Enkeltmandsvirksomhed | FUKI ejer Danish ejer 2023-06-28 ACTV visse erhvervsdrivende\nvirksomheder - 15h\nBekendtggrelse af lov om\n6ZZRKZ Denmark DK Fond 1IMWR rekonstruktor Danish rekonstruktor 2023-06-28 |ACTV erhvervsdrivende fonde\n§122.5\nLov om aktie- og\n77WA85 Denmark DK Anpartsselskab H8VP vurderingsmand Danish vurderingsmand 2023-06-28 ACTV anpartsselskaber\n(selskabsloven) §37\nBekendtggrelse af lov om\n7TOI3U Denmark DK Fond 1IMWR naestformand Danish naestformand 2023-06-28 |ACTV erhvervsdrivende fonde\n§37.5\ndarbeid gt darbeid gt Lov om aktie- og\nmedarbejdervalgte . medarbejdervalgte 06 anpartsselskaber\nA4VGU) Denmark DK Anpartsselskab H8VP bestyrelsesmediem Danish bestyrelsesmediem 2023-06-28 ACTV (sefiskabsloven) 551\nBekendtggrelse af lov om\nBOIXNH Denmark DK Fond 1IMWR stifter Danish stifter 2023-06-28 |ACTV erhvervsdrivende fonde\n§13, 26\nBekendtggrelse af lov om\nCCKVF7 Denmark DK Fond 1MWR bestyrelsesmedlem Danish bestyrelsesmedlem 2023-06-28 ACTV erhvervsdrivende fonde\n§13\nLov om aktie- og\nDA3R6C Denmark DK Aktieselskab ZRPO aktionaer Danish aktionaer 2023-06-28 ACTV anpartsselskaber\n(selskabsloven) §1\nLov om aktie- og\nFFGROQ Denmark DK Aktieselskab ZRPO ledelsesmedlem Danish ledelsesmediem 2023-06-28 ACTV anpartsselskaber\n(selskabsloven) §112.2\nLov om aktie- og\nFQRAJK Denmark DK Anpartsselskab H8VP kapitaltegner Danish kapitaltegner 2023-06-28 ACTV anpartsselskaber\n(selskabsloven) §32.4\nLov om aktie- og\nGFN2FF Denmark DK Anpartsselskab H8VP revisor Danish revisor 2023-06-28 ACTV anpartsselskaber\n(selskabsloven) §39\nLov om aktie- og\nGKFCOA Denmark DK Aktieselskab ZRPO stifter Danish stifter 2023-06-28 ACTV anpartsselskaber\n(selskabsloven) §24\nLov om aktie- og\nGSEO3P Denmark DK Aktieselskab ZRPO anmelde Danish anmelde 2023-06-28 ACTV anpartsselskaber\n(selskabsloven) §15.2\n21/119\n","contentLength":3299,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.720Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"N . Lov om aktie- og\n. medarbejdervalgte \" medarbejdervalgte\nGTSCFQ Denmark DK Aktieselskab ZRPO bestyrelsesmediem Danish bestyrelsesmediem 2023-06-28 ACTV anpartsselskaber\n(selskabsloven) §51\nLov om aktie- og\nHNGHYM Denmark DK Aktieselskab ZRPO likvidator Danish likvidator 2023-06-28 ACTV anpartsselskaber\n(selskabsloven) §218\nLov om aktie- og\n14WNBV Denmark DK Aktieselskab ZRPO kapitaltegner Danish kapitaltegner 2023-06-28 ACTV anpartsselskaber\n(selskabsloven) §32.4\nBekendtggrelse af lov om\nIXHQAP Denmark DK Fond 1IMWR administrator Danish administrator 2023-06-28 |ACTV erhvervsdrivende fonde\n§43\nBekendtggrelse af lov om\nK7FYR9 Denmark DK Fond 1IMWR medlem af direktionen Danish medlem af direktionen 2023-06-28 |ACTV erhvervsdrivende fonde\n§13\nLov om aktie- og\nK7SLGP Denmark DK Aktieselskab ZRPO medarbejderreprassentant Danish medarbejderrepraesentant 2023-06-28 ACTV anpartsselskaber\n(selskabsloven) §142\nBekendtggrelse af lov om\nKBZQ4W Denmark DK Fond 1IMWR reelle ejer Danish reelle ejer 2023-06-28 ACTV erhvervsdrivende fonde\n§21a\nLov om aktie- og\nKNBOMZ Denmark DK Anpartsselskab H8VP anmelde Danish anmelde 2023-06-28 ACTV anpartsselskaber\n(selskabsloven) §15.2\nLov om aktie- og\nLAGHQ3 Denmark DK Aktieselskab ZRPO kapitalejer Danish kapitalejer 2023-06-28 ACTV anpartsselskaber\n(selskabsloven) §50\nBekendtggrelse af lov om\nLVUBET Denmark DK Fond 1IMWR likvidator Danish likvidator 2023-06-28 |ACTV erhvervsdrivende fonde\n§91.6, 108\nBekendtggrelse af lov om\nMEXONB Denmark DK Fond 1IMWR Ledelsesmedlem Danish Ledelsesmedlem 2023-06-28 |ACTV erhvervsdrivende fonde\n§45\nBekendtggrelse af lov om\nMPRLRO Denmark DK Fond 1MWR modtager Danish modtager 2023-06-28 ACTV erhvervsdrivende fonde\n§80\nLov om aktie- og\nMWNM9X Denmark DK Aktieselskab ZRPO vurderingsmand Danish vurderingsmand 2023-06-28 ACTV anpartsselskaber\n(selskabsloven) §37\nLov om aktie- og\nQ2G3VH Denmark DK Aktieselskab ZRPO medlem af bestyrelsen Danish medlem af bestyrelsen 2023-06-28 ACTV anpartsselskaber\n(selskabsloven) §111.1\nLov om aktie- og\nQHWHRC Denmark DK Anpartsselskab H8VP stifter Danish stifter 2023-06-28 ACTV anpartsselskaber\n(selskabsloven) §24\nLov om aktie- og\nRTC489 Denmark DK Anpartsselskab H8VP medarbejderreprassentant Danish medarbejderrepraesentant 2023-06-28 ACTV anpartsselskaber\n(selskabsloven) §142\nBekendtggrelse af lov om\nS60BFP Denmark DK Fond 1IMWR formand Danish formand 2023-06-28 |ACTV erhvervsdrivende fonde\n§37.5\nLov om aktie- og\nSAFBER Denmark DK Anpartsselskab H8VP likvidator Danish likvidator 2023-06-28 ACTV anpartsselskaber\n(selskabsloven) §218\nBekendtggrelse af lov om\nSPUSZZ Denmark DK Fond 1MWR Suppleant Danish Suppleant 2023-06-28 ACTV erhvervsdrivende fonde\n§48\nLov om aktie- og\nTEFAXU Denmark DK Aktieselskab ZRPO formand Danish formand 2023-06-28 ACTV anpartsselskaber\n(selskabsloven) §111.1\nBekendtggrelse af lov om\nTK6263 Denmark DK Fond 1IMWR anmelde Danish anmelde 2023-06-28 |ACTV erhvervsdrivende fonde\n§19\nLov om aktie- og\nUF7GUW Denmark DK Anpartsselskab H8VP medlem af bestyrelsen Danish medlem af bestyrelsen 2023-06-28 ACTV anpartsselskaber\n(selskabsloven) §111.1\nLov om aktie- og\nUKF18H Denmark DK Aktieselskab ZRPO naestformand Danish naestformand 2023-06-28 ACTV anpartsselskaber\n(selskabsloven) §111.1\nLov om aktie- og\nVEZ7VWW Denmark DK Anpartsselskab H8VP reelle ejer Danish reelle ejer 2023-06-28 ACTV anpartsselskaber\n(selskabsloven) §58a\nLov om aktie- og\nVFPWPP Denmark DK Aktieselskab ZRPO medlem af tilsynsrad Danish medlem af tilsynsrad 2023-06-28 |ACTV anpartsselskaber\n(selskabsloven) §111.2\nLov om aktie- og\nVHFSMY Denmark DK Anpartsselskab H8VP formand Danish formand 2023-06-28 ACTV anpartsselskaber\n(selskabsloven) §111.1\n22/119\n","contentLength":3689,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.720Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Lov om aktie- og\n\nX1VW7 Denmark DK Aktieselskab ZRPO revisor Danish revisor 2023-06-28 ACTV anpartsselskaber\n(selskabsloven) §39\nLov om aktie- og\n\nXZFFHT Denmark DK Anpartsselskab H8VP direktor Danish direktor Dir. 2023-06-28 ACTV anpartsselskaber\n(selskabsloven) §111.1\nLov om aktie- og\n\nYDLICZ Denmark DK Anpartsselskab H8VP ledelsesmedlem Danish ledelsesmedlem 2023-06-28 ACTV anpartsselskaber\n(selskabsloven) §112.2\nBekendtggrelse af lov om\n\nYGFXIX Denmark DK Fond 1IMWR direktor Danish direktor Dir. 2023-06-28 |ACTV erhvervsdrivende fonde\n§37\nLov om aktie- og\n\nYJow)D Denmark DK Anpartsselskab H8VP naestformand Danish naestformand 2023-06-28 ACTV anpartsselskaber\n(selskabsloven) §111.1\nLov om aktie- og\n\nZCccuws Denmark DK Anpartsselskab H8VP aktionaer Danish aktionaer 2023-06-28 ACTV anpartsselskaber\n(selskabsloven) §1\nLov om aktie- og\n\nZNCZAU Denmark DK Anpartsselskab H8VP medlem af tilsynsrad Danish medlem af tilsynsrad 2023-06-28 ACTV anpartsselskaber\n(selskabsloven) §111.2\nLov om aktie- og\n\nZTQ4PG Denmark DK Aktieselskab ZRPO reelle ejer Danish reelle ejer 2023-06-28 ACTV anpartsselskaber\n(selskabsloven) §58a\n\n3779PM Estonia Aktsiaselts 9LA Juhatuse liige Estonian Juhatuse liige 20230628 |ACTV Ariseadustik, 2014 -\n$5.243.7, 308\n\n23XWW Estonia Osaiihing jcoy Asutaja Estonian Asutaja 2023-06-28 |ACTV Ariseadustik, 2014 -\nss.17.1,137.2\n\nK710NY Estonia Osaiihing jcoy Noukogu liige Estonian Noukogu liige 2023-06-28 |ACTV Ariseadustik, 2014 -\n$5.139.7, 180\n\nPMWIUQ Estonia Osaiihing ooy Aktsionar Estonian Aktsionar 2023-06-28 |ACTV Ariseadustik, 2014 -\n$5.135.2, 148\n\nX7RR59 Estonia Aktsiaselts 9LA Audiitor Estonian Audiitor 20230628 |ACTV Ariseadustik, 2014 -\n$5.243.7, 328\n\n0CLGDY Finland Fi Aktiebolag DKUW Ordféranden Swedish sv ordféranden 2023-06-28 |ACTV Aktiebolagslag, 2006 - 2\nkap: 2; 6 kap 23\n\n23/119\n","contentLength":1835,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.720Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"N e O I O S o e o O S I S A I N il\ne I T o o O S N L A I N il\nI o O I N - B e S NN S N [ A I N il\nI o O I O S o i I N N S A I N il\nR o I N S T o o O e N S A I N il\nR e I N oo o O e N A I N il\nN o I N e o O o N 7 A I N il\ne O I N e o O S N S A I N il\nT o O I O S o S O U2 A [ A I N il\nI o I e o O S N S A I N il\nT o N I N - B e S O o N S A I N 5l\nR o N I N S B e o O e N S A I N 7l\nN e I N S o e S O S N o A I N il\nD o I O I o - N S N 7 A I N il\ne N N S e o O o N S A I N il\nN O I N o ) o O e I S A I N -l\nT e I O B o S O oS N S A I N il\nT e O I N S B o o O e N S A I N i\nI e I N e e O S N S A I N il\nI o I N N e o N e N S A I N il\nL e I O o o O o N o A I N il\nL e I N S B e o O e N o A I N il\nI e I N e S O N N S A I N 7l\nI o I N N U e o N S N [ A I N 57l\nI e I O - e S O A S A I N il\nI e I O S B S o I S N S A I N i\ne O I N S B e S O G N [ A I N il\ne N N e o o O e N o A I N il\nN o N I N - S B S O N I S A I N il\ne N S e o O e N LT A I N il\nI o I O - S S S O S A S A I N il\nI e I S B S S I S N S A I N i\nI o I N S T e S O e S N L A I N il\nI o O I O e I S o O S N S A I N il\nI e I N o B S O = S N S A I N il\nT O I N N O e S N = A S I I N il\n\n24/119\n","contentLength":1149,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.720Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Société a responsabilité Code de commerce: Livre\n4BIJAS France FR limitée (sans autre VvoQP Gérant French fr Gérant 2023-06-28 |ACTV Il: Titre Il: Chapitre Ill -\nindication) Art.1223-10\nCode de commerce: Livre\n5Z4BUB France FR Société anonyme QVPB Liquidateur French fr Liquidateur 2023-06-28 ACTV II: Titre Il: Chapitre V -\nArt.1225-103\nSociété a responsabilité Code de commerce: Livre\n6F3TTF France FR limitée (sans autre VvoQP Commissaire aux apports French fr Commissaire aux apports 2023-06-28 |ACTV II: Titre Il: Chapitre Il -\nindication) Art.1223-9\nCode de commerce: Livre\n6suczc France FR Société anonyme QVPB Administrateur French fr Administrateur 2023-06-28 ACTV II: Titre Il: Chapitre V -\nArt.1225-18\nCode de commerce: Livre\n8DLJ60 France FR Société anonyme QVvPB Membre du directoire French fr Membre du directoire 2023-06-28 ACTV II: Titre Il: Chapitre V -\nArt.1225-58\nCode de commerce: Livre\nBJQQP8 France FR Société anonyme QvpPB Directeur général French fr Directeur général DG 2023-06-28 ACTV II: Titre Il: Chapitre V -\nArt.1225-35\n- : Code de commerce: Livre\nSAS, t t <4 <4 \"\nCRZGXD France FR A5, SOCIELE par actions | ¢,y Associé French fr Associé 20230628 |ACTV II: Titre Il: Chapitre VI -\nsimplifiée\nArt.1227-1\nOrganisme de Code monétaire et\nDGXQ8F France FR placement collectifen o g Gérant French fr Gérant 2023-06-28 | ACTV financier: Livre |i: Titre\nvaleurs mobiliéres sans ler: Chapitre IV: Section 1:\npersonnalité morale Art. 214-8-6\nOrganisme de Code monétaire et\nEJIQTF France FR placement collectif en | yqyq Directeur général French fr Directeur général DG DG 2023-0628 |ACTV financier: Livre |i: Titre\nvaleurs mobiliéres sans ler: Chapitre IV: Section 1:\npersonnalité morale Art. 214-7-2\n- : Code de commerce: Livre\nSAS, t t P cear \"\nEKJBXA France FR A5, SOCIELE par actions | ¢,y Commissaire aux comptes French fr Commissaire aux comptes 20230628 |ACTV II: Titre Il: Chapitre VI -\nsimplifiée\nArt.1227-9-1\nCode de commerce: Livre\nEM1G8Z France FR Société anonyme QVPB Nue-propriété French fr Nue-propriété 2023-06-28 ACTV II: Titre Il: Chapitre V -\nArt.1225-140\nOrganisme de Code monétaire et\nG44TSG France FR placement collectif en {15 g Directeur général French fr Directeur général DG DG 2023-06-28 |ACTV finander: Livre II: Titre\nvaleurs mobiliéres sans ler: Chapitre IV: Section 1:\npersonnalité morale Art. 214-7-3\nOrganisme de Code monétaire et\n14NTAM France FR placement collectifen o g Souscripteur French fr Souscripteur 2023-06-28 | ACTV financier: Livre |i: Titre\nvaleurs mobiliéres sans ler: Chapitre IV: Section 1:\npersonnalité morale Art. 214-7\n\" \" Code de commerce: Livre\nIFHDEO France FR Société anonyme Quee Membre du consell de French fr Membre du conseil de 2023-06-28 | ACTV II: Titre II: Chapitre V -\nsurveillance surveillance\nArt.1225-17\n- : Code de commerce: Livre\nIGV2PA France FR ffms Iff‘i’g':te paractions gy Dirigeant French fr Dirigeant 2023-06-28 |ACTV II; Titre II: Chapitre VII -\nP Art.1227-8\nCode de commerce: Livre\nJOPRHT France FR Société anonyme QVPB Directeur général délégué French fr Directeur général délégué 2023-06-28 ACTV II: Titre Il: Chapitre V -\nArt.1225-53\nOrganisme de Code monétaire et\nJ3FHWY) France FR placement collectif en | yqyq Actionnaire French fr Actionnaire 2023-0628 |ACTV financier: Livre |i: Titre\nvaleurs mobiliéres sans ler: Chapitre IV: Section 1:\npersonnalité morale Art. 214-7\nSociété a responsabilité Code de commerce: Livre\nKVEAIC France FR limitée (sans autre VvoQP Associé French fr Associé 2023-06-28 |ACTV Il: Titre Il: Chapitre Ill -\nindication) Art.1223-3\nSociété a responsabilité Code de commerce: Livre\nLzS8z4 France FR limitée (sans autre VoQP Commissaire aux comptes French fr Commissaire aux comptes 2023-06-28 ACTV II: Titre Il: Chapitre Il -\nindication) Art.1223-11\n25/119\n","contentLength":3788,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.720Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"- : Code de commerce: Livre\nMFZN2H France FR ffms Iff‘i’g':te paractions gy Commissaire aux apports French fr Commissaire aux apports 2023-06-28 |ACTV II; Titre II: Chapitre VII -\nP Art.1227-1\nCode de commerce: Livre\nNCEVTX France FR Société anonyme QVPB Usufruitier French fr Usufruitier 2023-06-28 ACTV II: Titre IIl: Chapitre V -\nArt.1225-140\nCode de commerce: Livre\nNEJOVP France FR Société anonyme QVPB Vice-président French fr Vice-président VP VP 2023-06-28 ACTV II: Titre Il: Chapitre V -\nArt.1225-81\nCode de commerce: Livre\nPKMCES France FR Société anonyme QvpPB Souscripteur French fr Souscripteur 2023-06-28 ACTV II: Titre IIl: Chapitre V -\nArt.1225-7\nOrganisme de Code monétaire et\nPYWQVO France FR placement collectifen |0 g Membn.'e.de conseil French fr Membre. de conseil 20230628 |ACTV finandier: Livre Il: Titre\nvaleurs mobiliéres sans d'administration d'administration ler: Chapitre IV: Section 1:\npersonnalité morale Art. 214-7-4\nCode de commerce: Livre\nQAENX]) France FR Société anonyme QVvPB Actionnaire French fr Actionnaire 2023-06-28 ACTV II: Titre IIl: Chapitre V -\nArt.1225-15\nOrganisme de Code monétaire et\nQHCHGH France FR placement collectifen o g Membre du directoire French fr Membre du directoire 2023-06-28 | ACTV financier: Livre |i: Titre\nvaleurs mobiliéres sans ler: Chapitre IV: Section 1:\npersonnalité morale Art. 214-7-2\n- : Code de commerce: Livre\nSAS, t t . . . . \"\nRJSTDQ France FR A5, SOCIELE par actions | ¢,y Actionnaire French fr Actionnaire 20230628 |ACTV II: Titre Il: Chapitre VI -\nsimplifiée\nArt.1227-10\nCode de commerce: Livre\nSAD64) France FR Société anonyme QVvPB Fondateur French fr Fondateur 2023-06-28 ACTV II: Titre Il: Chapitre V -\nArt.1225-2\nCode de commerce: Livre\nSNQPSP France FR Société anonyme QVPB Président du directoire French fr Président du directoire 2023-06-28 ACTV II: Titre Il: Chapitre V -\nArt.1225-66\nCode de commerce: Livre\nSPZYYT France FR Société anonyme QVPB Président French fr Président 2023-06-28 ACTV II: Titre Il: Chapitre V -\nArt.1225-17\nOrganisme de Code monétaire et\nTFEZQY France FR placement collectifen o g Porteur French fr Porteur 2023-06-28 | ACTV financier: Livre |i: Titre\nvaleurs mobiliéres sans ler: Chapitre IV: Section 1:\npersonnalité morale Art. 214-8\nOrganisme de Code monétaire et\nVJCYXX France FR placement c.o!l\\ectlf en MQu9 Commissaire aux comptes French fr Commissaire aux comptes 2023-06-28 |ACTV financler:. dvre l: 'I'm.'e\nvaleurs mobiliéres sans ler: Chapitre IV: Section 1:\npersonnalité morale Art. 214-7-2\nCode de commerce: Livre\nXEZOOW France FR Société anonyme QvpPB Commissaire aux apports French fr Commissaire aux apports 2023-06-28 ACTV II: Titre IIl: Chapitre V -\nArt.1225-8\nCode de commerce: Livre\nZ7VCYB France FR Société anonyme QvpPB Commissaire aux comptes French fr Commissaire aux comptes 2023-06-28 ACTV II: Titre IIl: Chapitre V -\nArt.1225-218\n- : Code de commerce: Livre\nSAS, t t Lt i \"\n2C65Q9 France FR A5, SOCIELE par actions | ¢,y Président French fr Président 20230628 |ACTV II: Titre Il: Chapitre VI -\nsimplifiée\nArt.1227-6\nOrganisme de Code monétaire et\nZNNMDI France FR placement collectifen o g Dirigeant French fr Dirigeant 2023-06-28 | ACTV financier: Livre |i: Titre\nvaleurs mobiliéres sans ler: Chapitre IV: Section 1:\npersonnalité morale Art. 214-7-2\nGesetz betreffend die\nGesellschaft mit Gesellschaften mit\nS5BEOW2 Germany beschrankter Haftung 2HBR Gesellschafter German Gesellschafter 2023-06-28 ACTV beschrankter Haftung\n(GmbHG) par.2\nGesetz betreffend die\nGesellschaft mit P P Gesellschaften mit\nBSPBAI G 2HBR Liquidat: G Liquidat: 2023-06-28 ACTV\nermany beschrankter Haftung lquidator erman quidator beschrankter Haftung\n(GmbHG) pars.66\n) . Birgerliches Gesetzbuch:\nDWG1GK Germany itelfctr?t:g des privaten f\\,vy Stifter German Stifter 2023-0628 |ACTV Kapitel 2: Untertitel 2:\nStiftungen par.81\nGesetz betreffend die\nGesellschaft mit ” ” Gesellschaften mit\nDXIEOX G 2HBR Grdind G Griind 2023-06-28 ACTV\nermany beschrankter Haftung runder erman runder beschrankter Haftung\n(GmbHG) par.1\n26/119\n","contentLength":4041,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.720Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Gesetz betreffend die\nals Germany Gesellschaft mit 2HBR Mitglied des Aufsichtsrats German Mitglied des Aufsichtsrats 2023-06-28 |ACTV Gesellschaften mit\nbeschrankter Haftung beschrankter Haftung\n(GmbHG) pars.52\n. L L Aktiengesetz (AktG) par.\nN41RDB Germany Aktiengesellschaft 6QQB Aktionar German Aktionar 2023-06-28 ACTV 26\n) . Birgerliches Gesetzbuch:\nStift d t\nNGVWWS Germany R;c:t:g es privaten 1\\ ovh Personenkreis German Personenkreis 2023-06-28 |ACTV Kapitel 2: Untertitel 2:\nStiftungen par.87\nGesetz betreffend die\nGesellschaft mit Lo P, Gesellschaften mit\n03E52H Germany beschrankter Haftung 2HBR Geschaftsflihrer German Geschaftsflihrer 2023-06-28 ACTV beschrankter Haftung\n(GmbHG) par.6\n) . Birgerliches Gesetzbuch:\nRDR2RE Germany itelfctr?t:g des privaten f\\,vy Vorstandsmitglied German Vorstandsmitglied 2023-0628 |ACTV Kapitel 2: Untertitel 2:\nStiftungen par.81\nHandelsgesetzbuch:\nSPQZ9E Germany Kommanditgesellschaft |826G Kommanditist German Kommanditist 2023-06-28 ACTV Zwelter Ah_'SChn'tt:\nKommanditgesellschaft\npar.161\nHandelsgesetzbuch:\n\" Personlich haftende Personlich haftende Zweiter Abschnitt:\nT9C2XX Germany Kommanditgesellschaft |826G Gesellschafter German Gesellschafter 2023-06-28 ACTV Kommanditgesellschaft\npar.161\nHong Kong, ;) e . .\n0JLTEC China HK FNBH RAT 254M BR Chinese zh Gudong 2023-06-28 ACTV AT 51 2014 - 5,177\nHong Kong, Private company limited . o6 Companies Ordinance,\n0JLTEC China HK -- by shares 254M Shareholder English Shareholder 2023-06-28 ACTV 2014 - 5.177\n4H5LHZ Hong Kong, Company limited by S2E3 Founder member English Founder member 2023-06-28 |ACTV Companies Ordinance,\nChina guarantee 2014 - s5.68, 112\nHong Kong, Public company limited . o6 Companies Ordinance,\n806C12 China HK -- by shares EPG7 Founder member English Founder member 2023-06-28 ACTV 2014 - 55,68, 112\nHong Kong, S ) o o . - e\nADDLWS China HK TN ERAT 254M AFIRE Chinese zh Gongsi mishu 2023-06-28 ACTV TR 2014 - 55.2, 474\nHong Kong, Private company limited . o6 Companies Ordinance,\nADDLWS China HK -- by shares 254M Company secretary English Company secretary Co.Sec. Co.Sec. 2023-06-28 ACTV 2014 - 55.2, 474\nAPBXY6 Hong Kong, Public company limited | gpg; Shareholder English Shareholder 2023-06-28 |ACTV Companies Ordinance,\nChina by shares 2014 -s5.177\nHong Kong, . o s | . \" \" oy\nB4IHL) China HK BRERAT S2E3 EREANL Chinese zh Xu dengji renshi 2023-06-28 |ACTV AR 2014 - 5,622\nHong Kong, Company limited by o . o o6 Companies Ordinance,\nB4IHL) China HK -- guarantee S2E3 Liquidator English Liquidator 2023-06-28 ACTV 2014 - 5.622.9\nHong Kong, Private company limited . o6 Companies Ordinance,\nBEWXRF China HK -- by shares 254M Debenture holder English Debenture holder 2023-06-28 ACTV 2014 - 5.6, 308\nCSKDLG Hong Kong, e Company limited by S2E3 Auditor English Auditor 2023-06-28 |ACTV Companies Ordinance,\nChina guarantee 2014 - 5.304\nHong Kong, Company limited by } . } o6 Companies Ordinance,\nDCVEUI China HK -- guarantee S2E3 Director English Director 2023-06-28 ACTV 2014 - 55.68, 453\nHong Kong, S = JEa | . L \" e\nEFQMHN China HK NRIEBERAT EPG7 EREANL Chinese zh Xu dengji renshi 2023-06-28 |ACTV ST 51 2014 - 5.653C\nHong Kong, Public company limited . . . o6 Companies Ordinance,\nEFQMHN China HK -- by shares EPG7 Registrable person English Registrable person 2023-06-28 ACTV 2014 - 5.653C\nA i B\nHong Kong, Private company limited . o6 Companies Ordinance,\nFAKNQ2 China HK -- by shares 254M Member English Member 2023-06-28 ACTV 2014 - s5.8, 11, 84, 112\nA i B\nHong Kong, Company limited by . o6 Companies Ordinance,\nGQVXWU China HK -- guarantee S2E3 Debenture holder English Debenture holder 2023-06-28 ACTV 2014 - 5.6, 308\n27119\n","contentLength":3662,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.720Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"HEHR87 Hong Kong, Company limited by S2E3 Shadow director English Shadow director 2023-06-28 |ACTV Companies Ordinance,\nChina guarantee 2014 -s.3\nHong Kong, Public company limited . o6 Companies Ordinance,\nHDI4SZ China HK -- by shares S2E3 Manager English Manager 2023-06-28 ACTV 2014 - 55.2, 348\nHong Kong, S ) o 4 . \" oy\nHLPGV4 China HK TN ERAT 254M BFREF Chinese zh Muhou dongshi 2023-06-28 |ACTV TR 2014 - 5.3\nHong Kong, Private company limited N N N Companies Ordinance,\nHLPGV4 China HK -- by shares 254M Shadow director English Shadow director 2023-06-28 ACTV 2014 -5.3\nHong Kong, S ) o & - N e\nIUSEQS China HK TN ERAT 254M Al A Chinese zh Chuangban chengyuan 2023-06-28 |ACTV ST FI 2014 - 55,68, 112\nHong Kong, Private company limited . o6 Companies Ordinance,\nIUSEQS China HK -- by shares 254M Founder member English Founder member 2023-06-28 ACTV 2014 - 55.68, 112\nHong Kong, Private company limited . o6 Companies Ordinance,\nIYNJOS China HK -- by shares 254M Manager English Manager 2023-06-28 ACTV 2014 - 55.2, 348\nHong Kong, . o o . - e\nJHQFEW China HK BRERAT S2E3 AFIRE Chinese zh Gongsi mishu 2023-06-28 |ACTV ST 51 2014 - 5.653C\nHong Kong, Company limited by . . . o6 Companies Ordinance,\nJHQFEW China HK -- guarantee S2E3 Registrable person English Registrable person 2023-06-28 ACTV 2014 - 5.653C\nHong Kong, S = o B . \" e\nJRHOTC o HK AR ERAT EPG7 [N Chinese zh Gaoji renyuan 2023-06-28 |ACTV AEEH1 2014 5.3\nJRHOTC Ho.ng Kong, HK Public company limited EPG7 Officer English Officer 2023-06-28 ACTV Companies Ordinance,\nChina by shares 2014 -s.3\nHong Kong, S ) o s | . \" \" oy\nKBFZ3T China HK TN ERAT 254M EREANL Chinese zh Xu dengji renshi 2023-06-28 |ACTV ST 51 2014 - 5.653C\nHong Kong, Private company limited . . . o6 Companies Ordinance,\nKBFZ3T China HK -- by shares 254M Registrable person English Registrable person 2023-06-28 ACTV 2014 - 5.653C\nHong Kong, Private company limited o . o o6 Companies Ordinance,\nKRV3YG China HK -- by shares 254M Liquidator English Liquidator 2023-06-28 ACTV 2014 - 5.622\nHong Kong, S ) o . \" e\nLJEBJK China HK FNBH RAT 254M EH Chinese zh Dongshi 2023-06-28 ACTV AT 551 2014 - 55.68, 454\nHong Kong, Private company limited } . } o6 Companies Ordinance,\nLJEBJK China HK -- by shares 254M Director English Director 2023-06-28 ACTV 2014 - 55.68, 454\nHong Kong, . o SIS e ) \" N N e\nLRHUNU China HK BRERAT S2E3 AFIHIERBN Chinese zh Gongsi de gingpan ren 2023-06-28 |ACTV AT FI 2014 - 55.2, 348\nHong Kong, Company limited by . o6 Companies Ordinance,\nLRHUNU China HK -- guarantee S2E3 Manager English Manager 2023-06-28 ACTV 2014 - 55.2, 348\nHong Kong, . o o= . N \" e\nLSXNCG China HK BRERAT S2E3 ik il Chinese zh Gongsi he shu shi 2023-06-28 |ACTV TR 2014 - 55.2, 474\nHong Kong, Company limited by . o6 Companies Ordinance,\nLSXNCG China HK -- guarantee S2E3 Company secretary English Company secretary 2023-06-28 ACTV 2014 - 55.2, 474\nHong Kong, S = SIS e ) \" N N e\nM6SGAK China HK NRIEBERAT EPG7 AFIHIERBN Chinese zh Gongsi de gingpan ren 2023-06-28 ACTV AR 2014 - 5,622\nHong Kong, Public company limited o . o o6 Companies Ordinance,\nM6SGAK China HK -- by shares EPG7 Liquidator English Liquidator 2023-06-28 ACTV 2014 - 5.622\nHong Kong, Public company limited } . } o6 Companies Ordinance,\nNEYC10 China HK -- by shares EPG7 Director English Director 2023-06-28 ACTV 2014 - 55.68, 453\nHong Kong, S = 4. . \" e\nO7TNWX China HK AR ARAT EPG7 BrES Chinese zh Muhou dongshi 2023-06-28 ACTV AT 51 2014 - 55.6, 308\nO7TNWX Hong Kong, e Public company limited | gpg 4 Shadow director English Shadow director 2023-06-28 |ACTV Companies Ordinance,\nChina by shares 2014 -s.3\nHong Kong, . o - N e\nocIB5S pittied HK HRERAT S2E3 A Chinese zh Chengyuan 2023-06-28 |ACTV AFI #2014 - 55,68, 112\n0CIB5S Hong Kong, e Company limited by S2E3 Member English Member 2023-06-28 |ACTV Companies Ordinance,\nChina guarantee 2014 -s.9\nHong Kong, . o o B . \" e\nPSKDOR pittied HK HRERAT S2E3 [N Chinese zh Gaoji renyuan 2023-06-28 |ACTV AEEH1 2014 5.3\nPSKDOR Hong Kong, e Company limited by S2E3 officer English Officer 2023-06-28 |ACTV Companies Ordinance,\nChina guarantee 2014 -s.3\nHong Kong, S ) o . N . e\nRBBZPR China HK TN ERAT 254M [ &%= Chinese zh Bei ren dongshi 2023-06-28 |ACTV ST 2014 - s5.2, 455\nHong Kong, Private company limited . . . o6 Companies Ordinance,\nRBBZPR China HK -- by shares 254M Reserve director English Reserve director 2023-06-28 ACTV 2014 - 55.2, 455\n28/119\n","contentLength":4407,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.720Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"RIZTHB Ho.ng Kong, HK Private company limited 254M Officer English Officer 2023-06-28 ACTV Companies Ordinance,\nChina by shares 2014 -s.3\nHong Kong, S = o= . N \" e\nSHSI1E China HK NRIEBERAT EPG7 ik il Chinese zh Gongsi he shu shi 2023-06-28 |ACTV TR 2014 - 55.2, 474\nHong Kong, Public company limited § . § o6 Companies Ordinance,\nSHSI1E China HK -- by shares EPG7 Auditor English Auditor 2023-06-28 ACTV 2014 - 5.304\nHong Kong, S = b N e\nu4wi3s China HK AR ARAT EPG7 A Chinese zh Chengyuan 2023-06-28 ACTV T4 2014 - 55.68, 112\nHong Kong, Public company limited . o6 Companies Ordinance,\nu4wi3s China HK -- by shares EPG7 Member English Member 2023-06-28 ACTV 2014 - s5.8, 11, 84, 112\nHong Kong, S = o . - e\nUBWOMA China HK NRIEBERAT EPG7 AFIRE Chinese zh Gongsi mishu 2023-06-28 ACTV ST 2014 - s5.2, 455\nUBWOMA Hong Kong, HK Public company limited EPG7 Company secretary English Company secretary Co.Sec. Co.Sec. 2023-06-28 ACTV Companies Ordinance,\nChina by shares 2014 -s5.2, 474\nHong Kong, S ) o o= . N \" e\nWSBNFT China HK TN ERAT 254M ik il Chinese zh Gongsi he shu shi 2023-06-28 |ACTV AT FI 2014 - 5,304\nHong Kong, Private company limited § . § o6 Companies Ordinance,\nWSBNFT China HK -- by shares 254M Auditor English Auditor 2023-06-28 ACTV 2014 - 5.304\nT i B\nHong Kong, Public company limited . o6 Companies Ordinance,\nZD3TN4 China HK -- by shares EPG7 Debenture holder English Debenture holder 2023-06-28 ACTV 2014 - 5.6, 308\n- PR The Limited Liability\n9507F8 Umited Liability UsS6 Partner English Partner 2023-0628 |ACTV Partnership Act, 2008 -\nPartnership\n5.2, 22\n- PR The Limited Liability\nLimited Liabilit:\nDIBIY4 mited Liaoffity U5S6 Designated partner English Designated partner 2023-06-28 |ACTV Partnership Act, 2008 -\nPartnership 682, 7\n- PR The Limited Liability\nJKCHFW Umited Liability U5S6 Liquidator English Liquidator 2023-06-28 |ACTV Partnership Act, 2008 -\nPartnership .60\n29/119\n","contentLength":1906,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.720Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"- \" The Indian Partnership\nWopvse m_-- Partership Firm hors Engtisn _-- 20230628 --- Act, 1932 -54\nLimited Liability _ The Limited Liability\nXEM3X9 Partnership u5s6 Company secretary English Company secretary Co. Sec. Co. Sec. 2023-06-28 ACTV Partnership Act, 2008 -\n5.2\ns G O A N e G G S A AN N A B I S\n- S..\n001ZXQ Ireland Private Company Limited| ;7 Director English Director 2023-06-28 |ACTV Companies Act 2014 -\nby Shares 5.22\n. . Irish Collective Asset-\nOWHWDU Ireland Irish Collective Asset- |, .\\ o Subscriber English Subscriber 2023-0628 |ACTV management Vehicles Act\nmanagement Vehicle\n2015 -5.6\n. . Irish Collective Asset-\nOWHWDU Ireland Irish Collective Asset- |, .\\ o Suibscriobhaf Irish (Gaeilge) Suibscriobhaf 2023-0628 |ACTV management Vehicles Act\nmanagement Vehicle\n2015 -5.6\n12BBTO Ireland Private Company Limited| ;7 Secretary English Secretary 2023-06-28 |ACTV Companies Act 2014 -\nby Shares 5.22\nPrivate Company Limited| o i o e Companies Act 2014 -\n2JMOP1 Ireland _-- by Shares MNQ7 Liquidator English Liquidator 2023-06-28 ACTV 5.502\n. . Irish Collective Asset-\n25UDS) Ireland Irish Collective Asset- |, .\\ o Shareholder English Shareholder 2023-0628 |ACTV management Vehicles Act\nmanagement Vehicle\n2015 -5.6\n. . Irish Collective Asset-\n25UDS) Ireland Irish Collective Asset- |, .\\ o Scairshealbhéir Irish (Gaeilge) Scairshealbh6ir 2023-0628 |ACTV management Vehicles Act\nmanagement Vehicle\n2015 - 5.45\nCompanies Act 2014 -\nP . \" . 06 Part 17 (includes Parts 1-\n2Y)8BB Ireland Public Limited Company [VYAX Receiver English Receiver 2023-06-28 ACTV 14 as modified/disapplied\nby the section) - 5.428\nCompanies Act 2014 -\nCuideachta Phoiblf . . ! . Part 17 (includes Parts 1-\n2v)3B8B Ireland VYAX Glacad Irish (Gaeil Glacad 2023-06-28 |ACTV\nL relan Theoranta acadora rish (Gaeilge) acadora 14 as modified/disapplied\nby the section) - 5.428\n305FUD Ireland Private Company Limited MNQ7 Registered person English Registered person 2023-06-28 ACTV Companies Act 2014 -\nby Shares 5.39\n. . Irish Collective Asset-\nIrish Collective Asset-\n3RYMAF Ireland rish Collective Asse! 26v9 Trustee (for debentures) English Trustee (for debentures) 2023-06-28 |ACTV management Vehicles Act\nmanagement Vehicle\n2015 -5.104\n. . Irish Collective Asset-\nIrish Collective Asset-\n3RYMAF Ireland rish Collective Asse! 26v9 Jontaobhaf (do bhintidir) Irish (Gaeilge) Jontaobhaf (do bhintidir) 2023-06-28 |ACTV management Vehicles Act\nmanagement Vehicle 2015 - 5.6\nCompanies Act 2014 -\n4BABAL Ireland Designated Activity LGWG Member English Member 2023-06-28 |ACTV Part 16 (includes Parts 1-\nCompany 14 as modified by the\nsection) - 5.965\n30119\n","contentLength":2639,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.720Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"23 MARS 2019. — Loi\nintroduisant le Code des\niétés et des\n\" Société a responsabilité Membre de I'organe Membre de I'organe societes\n23SDIY Belgium limitée 3W7E d'administration French fr d'administration 2023-06-28 ACTV assoc.latlor.\\s. et portant\ndes dispositions diverses -\nLivre 2: Titre 6: CHAPITRE\n2: Art. 2:56\n23 MARZ 2019. —\n) Gesellschaft mit Mitglied des Mitglied des Gesetzbuch der\n23sbliy Belgium beschrankter Haftung 3wW7E Verwaltungsorgans German Verwaltungsorgans 2023-06-28 ACTV Gesellschaften und\nVereinigungen\n23 MARS 2019. — Loi\nintroduisant le Code des\nsociétés et des\n3PGTDW Belgium Société anonyme R85P Président French fr Président 2023-06-28 ACTV associations et portant\ndes dispositions diverses -\nLivre 2: Titre 7: CHAPITRE\n1: Art. 2:62.3\n23 MAART 2019. — Wet\ntot invoering van het\nWetboek van\nvennootschappen en\n3PGTDW Belgium Naamloze vennootschap | R85P Voorzitter Dutch Voorzitter 2023-06-28 ACTV verenigingen en\nhoudende diverse\nbepalingen - BOEK 2:\nTITEL 7: HOOFDSTUK 1:\nArt.2:62:3\n23 MARZ 2019. —\n3PGTDW Belgium Aktiengesellschaft R85P Vorsitzender German Vorsitzender 2023-06-28 [ACTV Gesetzbuch der\nGesellschaften und\nVereinigungen\n23 MAART 2019. — Wet\ntot invoering van het\nWetboek van\n4QP30K Belgium Besloten Vennootschap |3W7E Stichter Dutch Stichter 2023-0628 |ACTV vennootschappen en\nverenigingen en\nhoudende diverse\nbepalingen - TITEL 1:\nHOOFDSTUK 1: Art.1:2\n23 MARS 2019. — Loi\nintroduisant le Code des\nSociété a bilite sociétés et des\n4QP30K Belgium Iir?filteéee a responsabilite 3W7E Fondateur French fr Fondateur 2023-06-28 ACTV associations et portant\ndes dispositions diverses -\nTitre 1: CHAPITRE 1: Art.\n1.2\n23 MARZ 2019. —\n\" Gesellschaft mit “ “ Gesetzbuch der\n4QP30K Belgium beschrankter Haftung 3W7E Grlinder German Griinder 2023-06-28 ACTV Gesellschaften und\nVereinigungen\n23 MARS 2019. — Loi\nintroduisant le Code des\nsociétés et des\n61LE25 Belgium Société anonyme R85P Fondateur French fr Fondateur 2023-06-28 ACTV associations et portant\ndes dispositions diverses -\nTitre 1: CHAPITRE 1: Art.\n1.2\n23 MAART 2019. — Wet\ntot invoering van het\nWetboek van\n61LE25 Belgium Naamloze vennootschap | R85P Stichter Dutch Stichter 2023-06-28 |ACTV vennootschappen en\nverenigingen en\nhoudende diverse\nbepalingen - TITEL 1:\nHOOFDSTUK 1: Art.1:2\n23 MARZ 2019. —\n61LE25 Belgium Aktiengesellschaft R85P Griinder German Gréinder 2023-06-28 |ACTV Gesetzbuch der\nGesellschaften und\nVereinigungen\n23 MARS 2019. — Loi\nintroduisant le Code des\nsociétés et des\n7Q00AB Belgium Société anonyme R85P Liquidateur French fr Liquidateur 2023-06-28 ACTV associations et portant\ndes dispositions diverses -\nLivre 2: Titre 8: CHAPITRE\n1: Art. 2:82\n23 MAART 2019. — Wet\ntot invoering van het\nWetboek van\nvennootschappen en\n7Q00AB Belgium Naamloze vennootschap | R85P Vereffenaar Dutch Vereffenaar 2023-06-28 ACTV verenigingen en\nhoudende diverse\nbepalingen - BOEK 2:\nTITEL 8: HOOFDSTUK 1:\nArt.2:82\n4/119\n","contentLength":2923,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.721Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":". Companies Act 2014 -\nCuideachta Part 16 (includes Parts 1\n4BABAL Ireland Gniomhafochta LGWG Comhalta Irish (Gaeilge) Comhalta 2023-06-28 |ACTV al (Includes Parts 1-\n. ; 14 as modified by the\nAinmnithe .\nsection) - 5.965\n5SMDLD Ireland Private Company Limited| ;7 Statutory auditor English Statutory auditor 2023-06-28 |ACTV Companies Act 2014 -\nby Shares 5.333\nCompanies Act 2014 -\n5YQ1MS Ireland Designated Activity LGWG Shadow director English Shadow director 2023-06-28 |ACTV Part 16 (includes Parts 1-\nCompany 14 as modified by the\nsection) - 5.221\nCuideachta gorr:;;gni_es |A((:1t 20P14rt> 1\n5YQ1MS Ireland Gniomhafochta LGWG Scathstitirthéir Irish (Gaeilge) Scathstitirthéir 2023-06-28 |ACTV al (Includes Parts 1-\n. ; 14 as modified by the\nAinmnithe .\nsection) - 5.221\nCompanies Act 2014 -\nDesignated Activity . ' A o6 Part 16 (includes Parts 1-\n8KOLE2 Ireland Company LGWG Managing director English Managing director 2023-06-28 ACTV 14 as modified by the\nsection) - 5.159\nCuideachta gorr:;;gni_es |A((:1t 20P14rt> 1\n8KOLE2 Ireland Gniomhafochta LGWG Stidirthéir bainistiochta Irish (Gaeilge) Stidirthéir bainistiochta 2023-06-28 |ACTV al (Includes Parts 1-\n. ; 14 as modified by the\nAinmnithe .\nsection) - 5.159\nCompanies Act 2014 -\n99BNC1 Ireland Designated Activity LGWG Director English Director 2023-06-28 |ACTV Part 16 (includes Parts 1-\nCompany 14 as modified by the\nsection) - 5.985\ni Companies Act 2014 -\nCuideachta o i i o Part 16 (includes Parts 1-\n99BNC1 Ireland Gniomhaiochta LGWG Stitrthoir Irish (Gaeilge) Stitrthoir 2023-06-28 ACTV 14 as modified by the\nAinmnithe section) - 5.985\n. . Irish Collective Asset-\n9BVFKY Ireland Irish Collective Asset- |, .\\ o Receiver English Receiver 2023-0628 |ACTV management Vehicles Act\nmanagement Vehicle\n2015 - 5.153\n. . Irish Collective Asset-\n9BVFKY Ireland Irish Collective Asset- |, .\\ o Glacadéra Irish (Gaeilge) Glacadéra 2023-0628 |ACTV management Vehicles Act\nmanagement Vehicle\n2015 - 5.36\nCompanies Act 2014 -\nA9IXS9G Ireland Designated Activity LGWG Contributory English Contributory 2023-06-28 |ACTV Part 16 (includes Parts 1-\nCompany 14 as modified by the\nsection) - 5.654\nCuideachta fio:;;;ni.es |A((:1t 20P14rt> 1\nA9XS9G Ireland Gniomhafochta LGWG Ranniocach Irish (Gaeilge) Ranniocach 2023-06-28 |ACTV a (includes Parts 1-\n. ; 14 as modified by the\nAinmnithe .\nsection) - 5.654\nCompanies Act 2014 -\nAHUWZC Ireland Designated Activity LGWG Secretary English Secretary 2023-06-28 |ACTV Part 16 (includes Parts 1-\nCompany 14 as modified by the\nsection) - 5.22\nCuideachta fio:;;;ni.es |A((:1t 20P14rt> 1\nAHUWZC Ireland Gniomhafochta LGWG Runaf Irish (Gaeilge) Runaf 2023-06-28 |ACTV a (includes Parts 1-\n. ; 14 as modified by the\nAinmnithe .\nsection) - 5.22\n. . Irish Collective Asset-\nIrish Collective Asset-\nAWUSGB Ireland rish Collective Asse! 26v9 Debenture holder English Debenture holder 2023-06-28 |ACTV management Vehicles Act\nmanagement Vehicle\n2015 - 5.45\n. . Irish Collective Asset-\nIrish Collective Asset-\nAWUSGB Ireland rish Collective Asse! 26v9 Sealbhéir bintidir Irish (Gaeilge) Sealbhéir bintidir 2023-06-28 |ACTV management Vehicles Act\nmanagement Vehicle 2015 - 5.11\nBOBGLV Ireland Private Company Limited| ;7 De facto director English De facto director 2023-06-28 |ACTV Companies Act 2014 -\nby Shares 5.222\nCompanies Act 2014 -\nDUIM7N Ireland Public Limited Company |VYAX Examiner English Examiner 2023-06-28 |ACTV Part 17 (includes Parts 1-\n14 as modified/disapplied\nby the section) - 5.509\nCompanies Act 2014 -\nDUIM7N Ireland Cuideachta Phoiblf VYAX Scradaitheoir Irish (Gaeilge) Scradaitheoir 2023-06-28 |ACTV Part 17 (includes Parts 1-\nTheoranta 14 as modified/disapplied\nby the section) - 5.509\nCompanies Act 2014 -\nF3DKPL Ireland Designated Activity LGWG Receiver English Receiver 2023-06-28 |ACTV Part 16 (includes Parts 1-\nCompany 14 as modified by the\nsection) - 5.428\nCuideachta gorr:;;gni_es |A((:1t 20P14rt> 1\nF3DKPL Ireland Gniomhafochta LGWG Glacadéra Irish (Gaeilge) Glacadéra 2023-06-28 |ACTV al (Includes Parts 1-\n. ; 14 as modified by the\nAinmnithe .\nsection) - 5.428\n317119\n","contentLength":4084,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.721Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Companies Act 2014 -\nF8BVAZ Ireland Public Limited Company |VYAX Shadow director English Shadow director 2023-06-28 | ACTV Part 17 (includes Parts 1-\n14 as modified/disapplied\nby the section) - 5.221\nCompanies Act 2014 -\nF8BVAZ Ireland Cuideachta Phoiblf VYAX Scathstidrthoir Irish (Gaeilge) Scathstidrthoir 2023-06-28 |ACTV Part 17 (includes Parts 1-\nTheoranta 14 as modified/disapplied\nby the section) - 5.221\nCompanies Act 2014 -\nFICKI Ireland Designated Activity LGWG De facto director English De facto director 2023-06-28 |ACTV Part 16 (includes Parts 1-\nCompany 14 as modified by the\nsection) - 5.222\nCuideachta gorr:\\;;gni.es IA((:it 20P14rt> 1\nFICKOI Ireland Gniomhafochta LGWG Stitrthoir de facto Irish (Gaeilge) Stitrthdir de facto 2023-06-28 |ACTV a (includes Parts 1-\n. ; 14 as modified by the\nAinmnithe .\nsection) - 5.222\nFOWTIA Ireland Private Company Limited| ;7 Shadow director English Shadow director 2023-06-28 |ACTV Companies Act 2014 -\nby Shares 5.221\nCompanies Act 2014 -\nGBUL6S Ireland Public Limited Company |VYAX Secretary English Secretary 2023-06-28 |ACTV ii’;skgzicé‘;‘(’igi::;fii;\nby the section) - 5.1112\nCompanies Act 2014 -\nCuideachta Phoibli - ’ ' - Part 17 (includes Parts 1-\nGBUL68 Ireland VYAX R Irish (Gaeil R 2023-06-28 [ACTV\nrelan Theoranta unal rish (Gaeilge) unal 14 as modified/disapplied\nby the section) - 5.1112\n. . Irish Collective Asset-\nIrish Collective Asset-\nGNTNAR Ireland rish Collective Asse! 26v9 Auditor English Auditor 2023-06-28 |ACTV management Vehicles Act\nmanagement Vehicle\n2015 - 5.120\n. . Irish Collective Asset-\nIrish Collective Asset-\nGNTNAR Ireland rish Collective Asse! 26v9 Inidchéir Irish (Gaeilge) Inidchéir 2023-06-28 |ACTV management Vehicles Act\nmanagement Vehicle\n2015 - 5.104\nCompanies Act 2014 -\nHO8I6S Ireland Designated Activity LGWG Examiner English Examiner 2023-06-28 [ACTV Part 16 (includes Parts 1-\nCompany 14 as modified by the\nsection) - 5.509\nCuideachta gorr:\\;;gni.es IA((:it 20P14rt> 1\nHO8I6S Ireland Gniomhafochta LGWG Scradaitheoir Irish (Gaeilge) Scradaitheoir 2023-06-28 |ACTV a (includes Parts 1-\n. ; 14 as modified by the\nAinmnithe .\nsection) - 5.509\n. . Irish Collective Asset-\nHVPWOI Ireland Irish Collective Asset- |, .\\ o Secretary English Secretary 2023-0628 |ACTV management Vehicles Act\nmanagement Vehicle\n2015 - 5.11\n. . Irish Collective Asset-\nHVPWOI Ireland Irish Collective Asset- |, .\\ o Ranaf Irish (Gaeilge) Ranaf 2023-0628 |ACTV management Vehicles Act\nmanagement Vehicle\n2015 -5.37\nCompanies Act 2014 -\ne . i - Part 17 (includes Parts 1-\nYI7LS Ireland Public Limited C VYAX Liquidat English Liquidat 2023-06-28 [ACTV\nJ relan ublic Limited Company iquidator nglis| quidator 14 as modified/disapplied\nby the section) - 5.592\nCompanies Act 2014 -\nCuideachta Phoibli | ’ ' ' Part 17 (includes Parts 1-\nJYI7LS Ireland Theoranta VYAX Leachtaitheora Irish (Gaeilge) Leachtaitheora 2023-06-28 ACTV 14 as modified/disapplied\nby the section) - 5.592\nLIDQUF Ireland Private Company Limited| ;7 Member English Member 2023-06-28 |ACTV Companies Act 2014 -\nby Shares 5.17\nLRNFRX Ireland Private Company Limited| ;7 Examiner English Examiner 2023-06-28 |ACTV Companies Act 2014 -\nby Shares 5.509\nCompanies Act 2014 -\nLZ2IMH Ireland Public Limited Company [VYAX Registered person English Registered person 2023-06-28 ACTV Part 17 (includes Parts 1-\n14 as modified/disapplied\nby the section) - 5.39\nCompanies Act 2014 -\nLZ2IMH Ireland Cuideachta Phoiblf VYAX Duine Chldraithe Irish (Gaeilge) Duine Chldraithe 2023-06-28 |ACTV Part 17 (includes Parts 1-\nTheoranta 14 as modified/disapplied\nby the section) - 5.39\nCompanies Act 2014 -\nP \" \" \" 06 Part 17 (includes Parts 1-\nMQSY2L Ireland Public Limited Company [VYAX Director English Director 2023-06-28 ACTV 14 as modified/disapplied\nby the section) - 5.1088\nCompanies Act 2014 -\nCuideachta Phoibli o ’ ' P Part 17 (includes Parts 1-\nMQSY2L Ireland Theoranta VYAX Stitrthoir Irish (Gaeilge) Stitrthoir 2023-06-28 ACTV 14 as modified/disapplied\nby the section) - 5.1088\n32/119\n","contentLength":4018,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.721Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Companies Act 2014 -\nP . \" . Part 17 (includes Parts 1-\nPMVZFL Ireland Public Limited C VYAX Contribut English Contribut 2023-06-28 [ACTV\nrelan ublic Limite ompany ontributory nglisl ontributory 14 as modlfled/dlsapplled\nby the section) - 5.654\nCompanies Act 2014 -\nCuideachta Phoibli . ’ ' . Part 17 (includes Parts 1-\nPMVZFL Ireland Theoranta VYAX Ranniocach Irish (Gaeilge) Ranniocach 2023-06-28 ACTV 14 as modified/disapplied\nby the section) - 5.654\n. . Irish Collective Asset-\nPOWULA Ireland Irish Collective Asset- |, .\\ o Director English Director 2023-0628 |ACTV management Vehicles Act\nmanagement Vehicle\n2015 - 5.11\n. . Irish Collective Asset-\nPOWULA Ireland Irish Collective Asset- |, .\\ o Stiurthéir Irish (Gaeilge) Stiurthéir 2023-0628 |ACTV management Vehicles Act\nmanagement Vehicle\n2015 - 5.11\n. . Irish Collective Asset-\nSDFT56 Ireland Irish Collective Asset- |, .\\ o Liquidator English Liquidator 2023-0628 |ACTV management Vehicles Act\nmanagement Vehicle\n2015 -5.37\n. . Irish Collective Asset-\nSDFT56 Ireland Irish Collective Asset- |, .\\ o Leachtaitheora Irish (Gaeilge) Leachtaitheora 2023-0628 |ACTV management Vehicles Act\nmanagement Vehicle\n2015 - 5.120\nCompanies Act 2014 -\nSPKBWK Ireland Designated Activity LGWG Statutory auditor English Statutory auditor 2023-06-28 |ACTV Part 16 (includes Parts 1-\nCompany 14 as modified by the\nsection) - 5.333\nCuideachta gorr:;;gni_es |A((:1t 20P14rt> 1\nSPKBWK Ireland Gniomhafochta LGWG Initichéir Irish (Gaeilge) Initichéir 2023-06-28 |ACTV al (Includes Parts 1-\n. ; 14 as modified by the\nAinmnithe .\nsection) - 5.333\nUOMKBA Ireland Private Company Limited| ;7 Contributory English Contributory 2023-06-28 |ACTV Companies Act 2014 -\nby Shares 5.654\nVAKIU9 Ireland Private Company Limited| ;7 Managing director English Managing director 2023-06-28 |ACTV Companies Act 2014 -\nby Shares 5.159\n. . Irish Collective Asset-\nVW3DMX Ireland Irish Collective Asset- |, o o Officer English Officer 2023-06-28 |ACTV management Vehicles Act\nmanagement Vehicle\n2015 - 5.36\n) ) Irish Collective Asset-\nVW3DMX Ireland Irish Collective Asset- | 5Gyg Oifigeach Irish (Gaeilge) Oifigeach 2023-06-28 |ACTV management Vehicles Act\nmanagement Vehicle 2015 - 5.153\n. . Irish Collective Asset-\nVYUECH Ireland Irish Collective Asset- |, o o Member English Member 2023-06-28 |ACTV management Vehicles Act\nmanagement Vehicle\n2015 - 5.15\n. . Irish Collective Asset-\nIrish Collective Asset-\nVYUECH Ireland rish Collective Asse! 26v9 Comhalta Irish (Gaeilge) Comhalta 2023-06-28 |ACTV management Vehicles Act\nmanagement Vehicle\n2015 - 5.15\nCompanies Act 2014 -\nWFWWDP |ireland Public Limited Company |VYAX De facto director English De facto director 2023-06-28 |ACTV Part 17 (includes Parts 1-\n14 as modified/disapplied\nby the section) - 5.222\nCompanies Act 2014 -\nWFWWDP |ireland Cuideachta Phoiblf VYAX Stidrthéir de-facto Irish (Gaeilge) Stidrthéir de facto 2023-06-28 |ACTV Part 17 (includes Parts 1-\nTheoranta 14 as modified/disapplied\nby the section) - 5.222\nCompanies Act 2014 -\nP \" Part 17 (includes Parts 1-\nWINE Ireland Public Limited C VYAX Memb English Memb 2023-06-28 [ACTV\nJQ relant ublic Limited Company lember nglisl lember 14 as modified/disapplied\nby the section) - 5.1006\nCompanies Act 2014 -\nCuideachta Phoibli ’ ' Part 17 (includes Parts 1-\nWINEJQ Ireland Theoranta VYAX Comhalta Irish (Gaeilge) Comhalta 2023-06-28 ACTV 14 as modified/disapplied\nby the section) - 5.1006\nCompanies Act 2014 -\nDesignated Activity . ' . Part 16 (includes Parts 1-\nX3WSC Ireland LGWG Liquidat English Liquidat 2023-06-28 [ACTV\n) relan Company lquidator nglls quidator 14 as modified by the\nsection) - 5.592\nCuideachta fio:;;;ni.es |A((:1t 20P14rt> 1\nX3WSC) Ireland Gniomhafochta LGWG Leachtaitheora Irish (Gaeilge) Leachtaitheora 2023-06-28 |ACTV a (includes Parts 1-\n. ; 14 as modified by the\nAinmnithe .\nsection) - 5.592\nCompanies Act 2014 -\nX9ZKMU Ireland Esrsr\"?]’:&ed Activity LGWG Registered person English Registered person 2023-06-28 |ACTV ii’;sl‘;’ngzicé:zesypfh? 1\nsection) - 5.39\nCuideachta fio:;;;ni.es |A((:1t 20P14rt> 1\nX9ZKMU Ireland IE Gniomhafochta LGWG Duine Chlaraithe Irish (Gaeilge) |ga Duine Chlaraithe 2023-06-28 |ACTV a (includes Parts 1-\n. ; 14 as modified by the\nAinmnithe .\nsection) - 5.39\n33/119\n","contentLength":4265,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.721Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Companies Act 2014 -\nXQLC1E Ireland Public Limited Company |VYAX Managing director English Managing director 2023-06-28 |ACTV Part 17 (includes Parts 1-\n14 as modified/disapplied\nby the section) - 5.159\nCompanies Act 2014 -\nXQLCLE Ireland Cuideachta Phoiblf VYAX Stidrthéir bainistiochta Irish (Gaeilge) Stidrthéir bainistiochta 2023-06-28 |ACTV Part 17 (includes Parts 1-\nTheoranta 14 as modified/disapplied\nby the section) - 5.159\nCompanies Act 2014 -\nXWODAX Ireland Public Limited Company |VYAX Statutory auditor English Statutory auditor 2023-06-28 |ACTV Part 17 (includes Parts 1-\n14 as modified/disapplied\nby the section) - 5.333\nCompanies Act 2014 -\nCuideachta Phoibli L . \" PR Part 17 (includes Parts 1-\nXW9D4X Ireland VYAX [ h Irish (Gaeil [ hi 2023-06-28 ACTV\nrelan Theoranta nidchoir rish (Gaeilge) nidchoir 14 as modified/disapplied\nby the section) - 5.333\nYRS5DD Ireland Private Company Limited| ;7 Receiver English Receiver 2023-06-28 |ACTV Companies Act 2014 -\nby Shares 5.428\nCodice Civile Italiano,\nORP4Q) Italy fis Societa Per Azioni Pa18 Amministratore talian it Amministratore 2023-06-28 | ACTV 1942 (as amended) -\nTitolo V: Capo V -\nart.2328(9)\n. s Codice Civile Italiano,\nSi ta A R bilit: '\nOXHWET taly i3 u‘:‘::fafa esponsabilital 5,3, Socio talian it Socio 2023-06-28 |ACTV 1942 (as amended) -\nTitolo V: Capo 7 - art.2463\nCodice Civile Italiano,\n26)KZE Italy IT Societa Semplice 2XXH Liquidatore Italian it Liquidatore 2023-06-28 ACTV 1942 (as amended) -\nTitolo V: Capo 2 - art.2275\nCodice Civile Italiano,\n30VPC5 Italy T Societa Semplice 2XXH Socio amministratore Italian it Socio amministratore 2023-06-28 ACTV 1942 (as amended) -\nTitolo V: Capo 2 - art.2257\nCodice Civile Italiano,\n3X9A)S Italy T Societa Per Azioni P418 Presidente Italian it Presidente 2023-06-28 ACTV 1942 (as amended) -\nTitolo V: Capo V - art.2381\nPN Codice Civile Italiano,\nSi ta In N '\n4HPSNN taly i3 cgfi':tt?\\/: ome T2X1 Liquidatore talian it Liquidatore 2023-06-28 |ACTV 1942 (as amended) -\nTitolo V: Capo 3 - art.2309\nPN Codice Civile Italiano,\nSi ta In N '\n7CZ4FR taly i3 cgfi':tt?\\/: ome T2X1 Amministratore talian it Amministratore 2023-06-28 |ACTV 1942 (as amended) -\nTitolo V: Capo 3 - art.2298\n. s Codice Civile Italiano,\nSi ta A R bilit: '\n7JLAUG taly i3 u‘:‘::fafa esponsabilital 5,3, Liquidatore talian it Liquidatore 2023-06-28 |ACTV 1942 (as amended) -\nTitolo V: Capo 7 - art.2487\nCodice Civile Italiano,\nN o ) ) 1942 (as amended) -\nDBFKD4 Italy T Societa Per Azioni P418 Promotoro Italian it Promotoro 2023-06-28 ACTV Titolo V: Capo V -\nart.2328(1)\nCodice Civile Italiano,\nG82UZC taly i3 Societa Per Azioni Pa18 Socio talian it Socio 2023-06-28 |ACTV 1942 (as amended) -\nTitolo V: Capo V -\nart.2328(1)\nCodice Civile Italiano,\nGDOXDU Italy T Societa Semplice 2XXH Amministratore Italian it Amministratore 2023-06-28 ACTV 1942 (as amended) -\nTitolo V: Capo 2 - art.2277\n. s Codice Civile Italiano,\nSi ta A R bilit: '\nIGKI9C taly i3 u‘:‘::fafa esponsabilital 5,3, Amministratore talian it Amministratore 2023-06-28 |ACTV 1942 (as amended) -\nTitolo V: Capo 7 - art.2475\nCodice Civile Italiano,\nLDAIPL Italy T Societa Per Azioni P418 Sottoscrittorio Italian it Sottoscrittorio 2023-06-28 ACTV 1942 (as amended) -\nTitolo V: Capo V - art.2334\nCodice Civile Italiano,\nMCEJOR Italy i3 Societa Per Azioni Pa18 Componento del comitato per ;5 it Companento del comitato per 2023-0628 | ACTV 1942 (as amended) -\nil controllo sulla gestione il controllo sulla gestione Titolo V: Capo V -\nart.2409-octiesdecies\nCodice Civile Italiano,\nMPY)G) Italy T Societa Per Azioni P418 Usufruttuario Italian it Usufruttuario 2023-06-28 ACTV 1942 (as amended) -\nTitolo V: Capo V - art.2352\ne . Codice Civile Italiano,\nNVKKWC Italy fis E‘:‘::te;f;\\ Responsabilita | 3 Sindaco talian it Sindaco 2023-0628 |ACTV 1942 (as amended) -\nTitolo V: Capo 7 - art.2477\nCodice Civile Italiano,\n01W90G taly i3 Societa Per Azioni P418 Componento del consiglio di ;5 it Companento del consiglio di 2023-06-28 |ACTV 1942 (as amended) -\nsorveglianza sorveglianza Titolo V: Capo V -\nart.2328(11)\n34/119\n","contentLength":4069,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.721Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Codice Civile Italiano,\nPS6RPZ Italy T Societa Semplice 2XXH Socio Italian it Socio 2023-06-28 ACTV 1942 (as amended) -\nTitolo V: Capo 2 - art.2252\nCodice Civile Italiano,\nQ7DZAK Italy T Societa Per Azioni P418 Direttore generale Italian it Direttore generale 2023-06-28 ACTV 1942 (as amended) -\nTitolo V: Capo V - art.2396\ne Codice Civile Italiano,\nQP2WQH Italy T ggfi'e‘itjv': Nome T2x1 Socio Italian it Socio 2023-0628 |ACTV 1942 (as amended) -\nTitolo V: Capo 3 - art.2291\ne Codice Civile Italiano,\nUB2NMW Italy fis ggfi'e‘itjv': Nome T2X1 Socio di opera talian it Socio di opera 2023-0628 |ACTV 1942 (as amended) -\nTitolo V: Capo 3 - art.2295\nCodice Civile Italiano,\nuQoLow Italy fis Societa Per Azioni Pa18 Sindaco talian it Sindaco 2023-06-28 | ACTV 1942 (as amended) -\nTitolo V: Capo V -\nart.2328(11)\nCodice Civile Italiano,\nZH4NQC Italy T Societa Per Azioni P418 Obbligazionista Italian it Obbligazionista 2023-06-28 ACTV 1942 (as amended) -\nTitolo V: Capo V - art.2411\nPN \" \" \" 06 Companies (Jersey) Law\nSoxr ereey * -- ublic tmited Company |JoXt pudtor naten _ pudtor -- 20230628 AT --- 1991 - 55.102, 113\n. L \" \" \" 06 Companies (Jersey) Law\nAEMSOX erees * -- Private Limited Company) S0XY pudtor naten _ pudtor -- 20230628 ATV --- 1991 - 55.102, 113\n. P Secretary (Company \" Secretary (Company 06 Companies (Jersey) Law\nCQBOLR Jersey JE -- Private Limited Company| SQXV secretary) English secretary) Sec. (Co.Sec.) 2023-06-28 ACTV 1991 - 5.81\n35/119\n","contentLength":1459,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.721Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"VNMZL4 Jersey JE Public Limited Company [jox1 Secretary (Company English Secretary (Company Sec. (Co.Sec.) 2023-06-28 |ACTV Companies (Jersey) Law\nsecretary) secretary) 1991 -s.81\nRéglement grand-ducal\ndu 5 décembre 2017\nportant coordination de la\n1WBCWF Luxembourg LU Société anonyme 5GGB Fondateur French fr Fondateur 2023-06-28 ACTV loi modifiée du 10 ao(t\n1915 concernant les\nsociétés commerciales -\nTitre IV - Art.420-16\nRéglement grand-ducal\ndu 5 décembre 2017\nAP - \" \" rtant coordination de la\nSociété a responsabilité Membre du conseil de Membre du conseil de [ o o\n4NM1JU Luxembourg LU limitée DVXS surveillance French fr surveillance 2023-06-28 ACTV loi modifiée du 10 ao(t\n1915 concernant les\nsociétés commerciales -\nTitre VIl - Art.710-27\nRéglement grand-ducal\ndu 5 décembre 2017\nSociété a bilite portant coordination de la\n7ATCDI Luxembourg | LU ..r?f.'tif aresponsabilite f v q Associé French fr Associé 2023-06-28 |ACTV loi modifiée du 10 aodt\n1915 concernant les\nsociétés commerciales -\nTitre VII - Art.710-1\nLoi du 23 juillet 2016\nSociété relative aux fonds\n8CUYCD Luxembourg LU d'investissement a uDY2 Fondateur French fr Fondateur 2023-06-28 ACTV d'investissement\ncapital variable alternatifs réservés -\nArt.53\nRéglement grand-ducal\ndu 5 décembre 2017\nportant coordination de la\nAWMNI5 Luxembourg LU Société anonyme 5GGB Directeur général French fr Directeur général DG DG 2023-06-28 ACTV loi modifiée du 10 ao(t\n1915 concernant les\nsociétés commerciales -\nTitre IV - Art.441-3\nLoi du 23 juillet 2016\nSociété relative aux fonds\nB7)PPF Luxembourg L d'investissement a uDY2 Porteur de parts French fr Porteur de parts 2023-06-28 ACTV d'investissement\ncapital variable alternatifs réservés -\nArt.27\nLoi du 23 juillet 2016\nSociété relative aux fonds\nFFFZO2 Luxembourg LU d'investissement a uDY2 Dirigeant French fr Dirigeant 2023-06-28 ACTV d'investissement\ncapital variable alternatifs réservés -\nArt.2-1\nSociété LOIi (:-u 23jui|f|et§016\nG4UPPC Luxembourg LU d'investissement a uDY2 Gestionnaire French fr Gestionnaire 2023-06-28 ACTV re‘.a |ve.aux onds\ncapital variable d'investissement\nalternatifs réservés - Art.4\nLoi du 23 juillet 2016\nSociété relative aux fonds\nH7BS3Y Luxembourg L d'investissement a uDY2 Liquidateur French fr Liquidateur 2023-06-28 ACTV d'investissement\ncapital variable alternatifs réservés -\nArt.35\nRéglement grand-ducal\ndu 5 décembre 2017\nSociété dit portant coordination de la\n12X)MM Luxembourg LU sogljaleeen commandite U8BKA Associé commanditaire French fr Associé commanditaire 2023-06-28 ACTV loi modifiée du 10 ao(t\nP 1915 concernant les\nsociétés commerciales -\nTitre Il - Art.320-4\nLoi du 23 juillet 2016\nSociété relative aux fonds\nIWVDJR Luxembourg LU d'investissement a uDY2 Actionnaire French fr Actionnaire 2023-06-28 ACTV d'investissement\ncapital variable alternatifs réservés -\nArt.24\nRéglement grand-ducal\ndu 5 décembre 2017\nportant coordination de la\nKYOJP5 Luxembourg LU Société anonyme 5GGB Associé French fr Associé 2023-06-28 ACTV loi modifiée du 10 ao(t\n1915 concernant les\nsociétés commerciales -\nTitre IV - Art.410-1\n36/119\n","contentLength":3089,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.721Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Réglement grand-ducal\ndu 5 décembre 2017\ns Membre du conseil de Membre du conseil de pc?rtant.cgordination (.ie la\nNUKJB9 Luxembourg LU Société anonyme 5GGB surveillance French fr surveillance 2023-06-28 ACTV loi modifiée du 10 ao(t\n1915 concernant les\nsociétés commerciales -\nTitre IV - Art.442-16\nRéglement grand-ducal\ndu 5 décembre 2017\ns — portant coordination de la\nNYYW7M Luxembourg | LU fi;cl'tzt: aresponsabilité o Souscripteur French fr Souscripteur 2023-06-28 |ACTV loi modifiée du 10 aodt\n1915 concernant les\nsociétés commerciales -\nTitre VII - Art.710-6\nRéglement grand-ducal\ndu 5 décembre 2017\nportant coordination de la\nOLV3BI Luxembourg LU Société anonyme 5GGB Administrateur French fr Administrateur 2023-06-28 ACTV loi modifiée du 10 ao(t\n1915 concernant les\nsociétés commerciales -\nTitre IV - Art.441-2\nRéglement grand-ducal\ndu 5 décembre 2017\nportant coordination de la\nQZPA1R Luxembourg LU Société anonyme 5GGB Commissaire French fr Commissaire 2023-06-28 ACTV loi modifiée du 10 ao(t\n1915 concernant les\nsociétés commerciales -\nTitre IV - Art.443-1\nRéglement grand-ducal\ndu 5 décembre 2017\nSociété en commandite portant coordination de la\nRNLMPQ Luxembourg LU spéciale U8KA Associé commandité French fr Associé commandité 2023-06-28 |ACTV loi modifiée du 10 aolt\nP 1915 concernant les\nsociétés commerciales -\nTitre IIl - Art.320-1\nRéglement grand-ducal\ndu 5 décembre 2017\nSociété en commandite portant coordination de la\nTAKWXW Luxembourg LU spéciale UBKA Gérant French fr Gérant 2023-06-28 |ACTV loi modifiée du 10 aolt\nP 1915 concernant les\nsociétés commerciales -\nTitre IIl - Art.320-3\nLoi du 23 juillet 2016\nSociété relative aux fonds\nTMNTXV Luxembourg L d'investissement a uDY2 Réviseur d'entreprises French fr Réviseur d'entreprises 2023-06-28 ACTV d'investissement\ncapital variable alternatifs réservés -\nArt.43\nRéglement grand-ducal\ndu 5 décembre 2017\nSociété a responsabilité portant coordination de la\nTZ59KH Luxembourg LU limitée P DVXS Fondateur French fr Fondateur 2023-06-28 ACTV loi modifiée du 10 ao(t\n1915 concernant les\nsociétés commerciales -\nTitre VII - Art.710-6\nLoi du 23 juillet 2016\nSociété relative aux fonds\nVCD724 Luxembourg LU d'investissement a uDY2 Gérant French fr Gérant 2023-06-28 ACTV d'investissement\ncapital variable alternatifs réservés -\nArt.28\nLoi du 23 juillet 2016\nSociété relative aux fonds\nWSMGOF Luxembourg LU d'investissement a uDY2 Administrateur French fr Administrateur 2023-06-28 ACTV d'investissement\ncapital variable alternatifs réservés -\nArt.28\nRéglement grand-ducal\ndu 5 décembre 2017\ns — portant coordination de la\nX1S47F Luxembourg | LU fi;cl'tzt: aresponsabilité |/ o Commissaire French fr Commissaire 2023-0628 |ACTV loi modifiée du 10 aodt\n1915 concernant les\nsociétés commerciales -\nTitre VIl - Art.710-27\nRéglement grand-ducal\ndu 5 décembre 2017\nSociété 3 bilité portant coordination de la\nZULBC6 Luxembourg | LU |.°C.'te, © aresponsabilite | pny/xg Gérant French fr Gérant 2023-0628 |ACTV loi modifiée du 10 aotit\nimitée 1915 concernant les\nsociétés commerciales -\nTitre VII - Art.710-7\nRéglement grand-ducal\ndu 5 décembre 2017\nportant coordination de la\nZYKUUH Luxembourg LU Société anonyme 5GGB Membre du directoire French fr Membre du directoire 2023-06-28 ACTV loi modifiée du 10 ao(t\n1915 concernant les\nsociétés commerciales -\nTitre IV - Art.442-3\n37119\n","contentLength":3341,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.721Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"besloten vennootschap ™\n080BGK Netherlands NL met beperkte 54M6 Voorzitter bestuur Dutch Voorzitter bestuur 2023-06-28 ACTV gl#t;eelrléjlgrvt\\leztggsk Boek\naansprakelijkheid .\n. . . 06 Burgerlijk Wetboek Boek\ne ethertands | -- veremane 3o w puten _ u -- 20230628 AT --- 2 Titel 2 art. 26\n6ITGMW Netherlands | NL naamloze vennootschap | B5PM Oprichter Dutch Oprichter 20230628 |ACTV Burgerlijk Wetboek Boek\n2 Titel 4 art. 64\nbesloten vennootschap ™\nBi lijk Wetboek Boek\n7PTVPF Netherlands | NL met beperkte 54M6 Vereffenaar Dutch Vereffenaar 20230628 |ACTV urgerlijk Wethoek Soe\no . 2 Titel 1 art. 4\naansprakelijkheid\n934G9A Netherlands NL naamloze vennootschap | BSPM Voorzitter bestuur Dutch Voorzitter bestuur 2023-06-28 ACTV Burgerlijk Wetboek Boek\n2 Titel 4 art. 129a\n9W99BU Netherlands | NL vereniging 33MN Voorzitter Dutch Voorzitter 2023-06-28 |ACTV Burgerlijk Wetboek Boek\n2 Titel 2 art. 37\nbesloten vennootschap ™\nBi lijk Wetboek Boek\nAJ86T4 Netherlands | NL met beperkte 54M6 Oprichter Dutch Oprichter 20230628 |ACTV urgerij Wethoek Soe\no . 2 Titel 5 art. 175\naansprakelijkheid\nALIVPM Netherlands NL naamloze vennootschap | BSPM Curator Dutch Curator 2023-06-28 ACTV Burgerlijk Wetboek Boek\n2 Titel 1 art. 19\nBFAXP2 Netherlands ~ [NL vennootschap onder g5y 3 Beheerder / Beherend Vennoot | Dutch Beheerder / Beherend Vennoot 2023-06-28 |AcTv Burgerlijk Wetboek Boek\nfirma 7A Titel 9 art. 1673\nWetboek van Koophandel\nBKH1IX Netherlands | NL commanditaire CODH Beherend Vennoot Dutch Beherend Vennoot 2023-0628 |ACTV - Arts.19-21; Burgerliik\nvennootschap Wetboek Boek 7A Titel 9\nart. 1673\nbesloten vennootschap ™\nBi lijk Wetboek Boek\nCHOFER Netherlands NL met beperkte 54M6 Vertegenwoordigingsbevoegde | Dutch Vertegenwoordigingsbevoegde 2023-06-28 ACTV 2‘;5[?;’;‘ art e248e oe\naansprakelijkheid .\nWetboek van Koophandel\ncommanditaire 06 - Arts.13, 17; Burgerlijk\nDJJTS2 Netherlands NL vennootschap CODH Vennoot Dutch Vennoot 2023-06-28 ACTV Wetboek Boek 7A Titel 9\nart. 1662\nbesloten vennootschap . ] -\nHouder van certificaten (van Houder van certificaten (van Burgerlijk Wetboek Boek\nFKHPYN Netherlands NL met beperlf.te . 54M6 aandelen) Dutch aandelen) 2023-06-28 ACTV 2 Titel 5 art. 187\naansprakelijkheid\nvennootschap onder 06 Burgerlijk Wetboek Boek\nGPMRMA Netherlands NL -- firma 62Y3 Vennoot Dutch Vennoot 2023-06-28 ACTV 7A Titel 9 art. 1662\nbesloten vennootschap ™\nGRP0O) Netherlands | NL met beperkte 54M6 Commissaris Dutch Commissaris 2023-06-28 |ACTV g‘flflfeelr';”;rvtvezt?‘;e'( Boek\naansprakelijkheid .\nbesloten vennootschap ™\nBi lijk Wetboek Boek\nKHNVNO Netherlands | NL met beperkte 54M6 Bestuurder Dutch Bestuurder 20230628 |ACTV urgerij Wethoek Soe\no . 2 Titel 5 art. 180\naansprakelijkheid\nKLUFYX Netherlands | NL stichting V44D Oprichter Dutch Oprichter 20230628 |ACTV Burgerlijk Wetboek Boek\n2 Titel 6 art. 289\nWetboek van Koophandel\nKQVLFP Netherlands NL maatschap 9AAK Vennoot / Maat Dutch Vennoot / Maat 2023-06-28 ACTV & Burgerlijk Wetboek\nBoek 7A Titel 9 art. 1662\nLMYSOH Netherlands | NL vereniging 33MN Commissaris Dutch Commissaris 2023-06-28 |ACTV Burgerlijk Wetboek Boek\n2 Titel 2 art. 47\nbesloten vennootschap ™\nBi lijk Wetboek Boek\nODTFBO Netherlands | NL met beperkte 54M6 Aandeelhouder Dutch Aandeelhouder 20230628 |ACTV urgerij Wethoek Soe\no . 2 Titel 5 art. 175\naansprakelijkheid\nWetboek van Koophandel\nOIEAWD Netherlands NL maatschap 9AAK Beheerder Dutch Beheerder 2023-06-28 ACTV & Burgerlijk Wetboek\nBoek 7A Titel 9 art. 1673\nPPIUMW Netherlands | NL stichting V44D Bestuurder Dutch Bestuurder 2023-06-28 |ACTV Burgerlijk Wetboek Boek\n2 Titel 6 art. 286\nPVOS1F Netherlands | NL vereniging 33MN Secretaris Dutch Secretaris 2023-06-28 |ACTV Burgerlijk Wetboek Boek\n2 Titel 2 art. 37\nBurgerlijk Wetboek Boek\nRERTFR Netherlands NL stichting V44D Commissaris Dutch Commissaris 2023-06-28 ACTV 2 Titel 6 art. 292a\n. . Burgerlijk Wetboek Boek\nRPL5H6 Netherlands NL naamloze vennootschap | B5PM Vertegenwoordigingsbevoegde | Dutch Vertegenwoordigingsbevoegde 2023-06-28 ACTV 2 Titel 4 art. 130\n. . . Burgerlijk Wetboek Boek\nSXRUU6 Netherlands NL vereniging 33MN Vertegenwoordigingsbevoegde | Dutch Vertegenwoordigingsbevoegde 2023-06-28 ACTV 2 Titel 2 art, 45\n38/119\n","contentLength":4206,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.721Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"besloten vennootschap ™\nSYLJPO Netherlands | NL met beperkte 54M6 Curator Dutch Curator 2023-06-28 |ACTV g‘flflfeelr'{”;rvtveltgoe'( Boek\naansprakelijkheid .\nTAIWSW Netherlands NL naamloze vennootschap | B5PM Houder van certificaten (van Dutch Houder van certificaten (van 2023-06-28 ACTV Burgerlijk Wetboek Boek\naandelen) aandelen) 2 Titel 4 art. 88\nbesloten vennootschap ™\nBi lijk Wetboek Boek\nTFPVDK Netherlands NL met beperkte 54M6 Uitvoerend bestuurder Dutch Uitvoerend bestuurder 2023-06-28 ACTV urgerij Wethoek Soe\no . 2 Titel 5 art. 239a\naansprakelijkheid\nTP7XTW Netherlands NL naamloze vennootschap | BSPM Commissaris Dutch Commissaris 2023-06-28 ACTV Burgerlijk Wetboek Boek\n2 Titel 4 art. 140\nUWAQQT Netherlands NL commanditaire CODH Stille Vennoot / Commanditaire| o .\\, Stille Vennoot / Commanditaire 2023-0628 |AcTv Wetboek van Koophandel\nvennootschap Vennoot Vennoot - Art.32\nbesloten vennootschap ™\nVA30FP Netherlands NL met beperkte 54M6 Niet uitvoerend bestuurder Dutch Niet uitvoerend bestuurder 2023-06-28 ACTV gl#t;eelrléjlgrvt\\leztggsk Boek\naansprakelijkheid .\nL o o Burgerlijk Wetboek Boek\nWNHFP9 Netherlands NL stichting V44D Vertegenwoordigingsbevoegde | Dutch Vertegenwoordigingsbevoegde 2023-06-28 ACTV 2 Titel 6 art, 202\nWPGA3Y Netherlands | NL naamloze vennootschap | BSPM Voorzitter raad van Dutch Voorzitter raad van 2023-06-28 |ACTV Burgerlijk Wetboek Boek\ncommissaren commissaren 2 Titel 4 art. 132a\nF3W6RD New Zealand [Nz Limited Liability P2R9 Receiver English Receiver 2023-0628 | ACTV Companies Act 1993 -\nCompany 5.228\nILFORX New Zealand [Nz Limited Liability P2R9 Liquidator English Liquidator 2023-0628 | ACTV Companies Act 1993 -\nCompany 5.239)\nOLRY5U New zealand | Nz Limited Liability P2R9 Administrator English Administrator 2023-06-28 |ACTV Companies Act 1993 -\nCompany 5.239B\n0QDTGX New Zealand [Nz Limited Liability P2R9 Director English Director 2023-0628 | ACTV Companies Act 1993 -\nCompany ss.10, 126\nPOHGR) New Zealand [Nz Limited Liability P2R9 Deed administrator English Deed administrator 2023-0628 | ACTV Companies Act 1993 -\nCompany 5.239ACC\nRVQTEK New Zealand [Nz Limited Liability P2R9 Auditor English Auditor 2023-0628 | ACTV Companies Act 1993 -\nCompany s.207A\nUMOKQK New Zealand [Nz Limited Liability P2R9 Debenture holder English Debenture holder 2023-0628 | ACTV Companies Act 1993 -\nCompany s.377\nXSLEAG New Zealand [Nz Limited Liability P2R9 Shareholder English Shareholder 2023-0628 | ACTV Companies Act 1993 -\nCompany ss.10, 96\nLaw on companies\n(Official Gazette of\nNorth KomaHauTHO apywTso \" 06 Republic of North\nOUWDPO Macedonia MK o akum 1490 YneH Ha Hag3opeH oabop Macedonian mk Chlen na nadzoren odbor 2023-06-28 ACTV Macedonia No.99/2022\nlast revision dated\n22.04.2022), article 466\nLaw on companies\n(Official Gazette of\nOVWEWG m(:zri\\donia MK KomaHauTHO apywTso | XH7Z KomaHguTop Macedonian mk Komanditor 2023-06-28 ACTV aiizzgf\\i?x:;;/zozz\nlast revision dated\n22.04.2022), article 156\nLaw on companies\n(Official Gazette of\nRepublic of North\n2T8AG) North MK Jasro Tproscko HEXO Ynpasuten Macedonian | mk Upravitel 2023-06-28 |ACTV Macedonia No.99/2022\nMacedonia ApYWTBO o\nlast revision dated\n22.04.2022), article\n125,126\nLaw on companies\n(Official Gazette of\nNorth \" : 06 Republic of North\n35RWAH Macedonia MK AxunoHepcko gpywTso |DTIU Pesuzop Macedonian mk Revizor 2023-06-28 ACTV Macedonia No.99/2022\nlast revision dated\n22.04.2022), article 342\n39/119\n","contentLength":3430,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.722Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Law on companies\n(Official Gazette of\nNorth DpywTso co Republic of North\n4YQ2HR Macedonia MK orpaHuyeHa KHAB Ynpasuten Macedonian mk Upravitel 2023-06-28 ACTV Macedonia N0.99/2022\nOArosOpHOCT last revision dated\n22.04.2022), article 231\nLaw on companies\n(Official Gazette of\nRepublic of North\n8ERTCY :‘,Imh ' MK Jasro Tproscko HEXO CoapxKyHIK Macedonian | mk Sodruzhnik 2023-06-28 |ACTV Macedonia No.99/2022\nacedonia ApYWTBO L\nlast revision dated\n22.04.2022), article\n125,126\nLaw on companies\n(Official Gazette of\nNorth \" P 06 Republic of North\nAXLDSK Macedonia MK AkunoHepcko apywTso |DTIU YneH Ha u3splueH oabop Macedonian mk Chlen na izvrshen odbor 2023-06-28 ACTV Macedonia No.99/2022\nlast revision dated\n22.04.2022), article 342\nLaw on companies\n(Official Gazette of\nNorth KOMaHauTHO ApyLITEO . . Republic of North\nDTG6L) MK 1490 P Maced k R¢ 2023-06-28 ACTV\nJ Macedonia [T esi1zop acedonian m evizor Macedonia N0.99/2022\nlast revision dated\n22.04.2022), article 466\nLaw on companies\n(Official Gazette of\nNorth KOMaHauTHO ApyLITEO . Republic of North\nEL2INI MK 1490 [ Maced k K | It 2023-06-28 ACTV\nMacedonia [T omMnaemMenTap acedonian m omplementar Macedonia N0.99/2022\nlast revision dated\n22.04.2022), article 466\nLaw on companies\n(Official Gazette of\nNorth CTonaHcka uHTepecHa ' ' o6 Republic of North\nIPRUAR Macedonia MK SaenHuLa JCK1 Ynpasuten Macedonian mk Upravitel 2023-06-28 ACTV Macedonia No.99/2022\nlast revision dated\n22.04.2022), article 562\nLaw on companies\n(Official Gazette of\nJBKMCM I’\\\\‘llt;r(SZdonia MK Tproseu noeauHew, VPFY Tproseu noeauHew Macedonian mk Trgovec poedinec 2023-06-28 ACTV :’Iea’z:zgiit:’\\’}‘:;;/mzz\nlast revision dated\n22.04.2022), article 12\nLaw on companies\ncnf,fa’i.yc)::%? :E\"’CK o (Official Gazette of\nKLX77S North \" MK ApYLWTBO, 0AHOCHO Ha | KXDY PakosoauTen Macedonian mk Rakovoditel 2023-06-28 |ACTV Republlc_of North\nMacedonia Macedonia N0.99/2022\nCTpaHCKy Tprosew i\nnoeauHey last revision dated\n22.04.2022), article 591\nLaw on companies\n(Official Gazette of\nNorth KOMaHauTHO ApyLITEO . . Republic of North\nLBOVUR MK 1490 [ Maced k K it 2023-06-28 ACTV\nMacedonia O aKuum oMananTop acedonian m omanditor Macedonia N0.99/2022\nlast revision dated\n22.04.2022), article 466\nLaw on companies\n(Official Gazette of\nNorth \" P \" 06 Republic of North\nMVM3YS Macedonia MK AkunoHepcko apywTso |DTIU FNaBeH U3BpLIEH QUPEKTOp Macedonian mk Glaven izvrshen direktor 2023-06-28 ACTV Macedonia No.99/2022\nlast revision dated\n22.04.2022), article 342\nLaw on companies\n(Official Gazette of\nNorth ' o6 Republic of North\nNFYKS8 Macedonia MK AxumoHepcko gpywTso |DTIU YneH Ha Hag3opeH oabop Macedonian mk Chlen na nadzoren odbor 2023-06-28 ACTV Macedonia No.99/2022\nlast revision dated\n22.04.2022), article 342\nLaw on companies\nNorth ApyurTeo co Rapcbiic ot norin\nNZNAUR o _ MK orparineHa KHAB CompxyHnk Macedonian | mk Sodruzhnik 2023-0628 |ACTV epublic of fo\nMacedonia Macedonia N0.99/2022\n0AroBOpPHOCT i\nlast revision dated\n22.04.2022), article 231\nLaw on companies\n(Official Gazette of\nNorth MpeTcenaTen Ha U3splIeH . . o6 Republic of North\nPIQ9WA Macedonia MK AxumoHepcko gpywTso |DTIU o60p Macedonian mk Pretsedatel na izvrshen odbor 2023-06-28 ACTV Macedonia No.99/2022\nlast revision dated\n22.04.2022), article 342\nLaw on companies\n(Official Gazette of\nTH2LEX I’\\\\‘llt;r(SZdonia MK AxumoHepcko gpywTso |DTIU Esggse”me\" Ha Hapsoper Macedonian mk Pretsedatel na nadzoren odbor 2023-06-28 ACTV :’Iea’z:zgiit:’\\’}‘:;;/mzz\nlast revision dated\n22.04.2022), article 342\n40/119\n","contentLength":3505,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.722Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"23 MARZ 2019. —\n7QO0AB Belgium Aktiengesellschaft R85P Liquidator German Liquidator 2023-06-28 [ACTV Gesetzbuch der\nGesellschaften und\nVereinigungen\n23 MARS 2019. — Loi\nintroduisant le Code des\nA iati but sociétés et des\n7WBRZD Belgium Iuscsrt:t::? fon sans bul W3WH Commissaire French fr Commissaire 2023-06-28 ACTV associations et portant\ndes dispositions diverses -\nLivre 2: Titre 8: CHAPITRE\n2: Art. 2:110.2\n23 MAART 2019. — Wet\ntot invoering van het\nWetboek van\n. vennootschappen en\n. Vereniging zonder P - verenigingen en\n7WBRZD Belgium winstoogmerk W3WH Commissaris Dutch Commissaris 2023-06-28 ACTV houdende diverse\nbepalingen - BOEK 2:\nTITEL 8: HOOFDSTUK 2:\nArt.2:110.2\n23 MARZ 2019. —\n7WBRZD Belgium Vereinigung ohne 1\\ 3y Wirtschaftspriifer German Wirtschaftspriifer 2023-06-28 |ACTV Gesetzbuch der\nGewinnerzielungsabsicht Gesellschaften und\nVereinigungen\n23 MARS 2019. — Loi\nintroduisant le Code des\n8pZ5)Z Belgium Société anonyme R85P Associé French fr Associé 2023-0628 |ACTV sociétés et des\nassociations et portant\ndes dispositions diverses -\nLIVRE 1: TITRE 1: Art. 1:1\n23 MAART 2019. — Wet\ntot invoering van het\nWetboek van\n8pZ5)Z Belgium Naamloze vennootschap | R85P Vennoot Dutch Vennoot 2023-0628 |ACTV vennootschappen en\nverenigingen en\nhoudende diverse\nbepalingen - BOEK 1:\nTITEL 1: Art.1:1\n23 MARZ 2019. —\n8pZ5)2 Belgium Aktiengesellschaft R85P Gesellschafter German Gesellschafter 2023-06-28 [ACTV Gesetzbuch der\nGesellschaften und\nVereinigungen\n23 MAART 2019. — Wet\ntot invoering van het\nWetboek van\nvennootschappen en\n8UVTTM Belgium Besloten Vennootschap |3W7E Vereffenaar Dutch Vereffenaar 2023-06-28 ACTV verenigingen en\nhoudende diverse\nbepalingen - BOEK 2:\nTITEL 8: HOOFDSTUK 1:\nArt.2:82\n23 MARS 2019. — Loi\nintroduisant le Code des\nAP o sociétés et des\n8UVTTM Belgium fi;(;lteétee a responsabilité 3W7E Liquidateur French fr Liquidateur 2023-06-28 ACTV associations et portant\ndes dispositions diverses -\nLivre 2: Titre 8: CHAPITRE\n1: Art. 2:82\n23 MARZ 2019. —\n\" Gesellschaft mit P P Gesetzbuch der\n8UVTTM Belgium beschrankter Haftung 3W7E Liquidator German Liquidator 2023-06-28 ACTV Gesellschaften und\nVereinigungen\n23 MAART 2019. — Wet\ntot invoering van het\nWetboek van\n\" Houder van Houder van venno.oFschappen en\n9NSOPQ Belgium Besloten Vennootschap |3W7E inschrijvingsrechten Dutch inschrijvingsrechten 2023-06-28 ACTV verenlgmge_n en\nhoudende diverse\nbepalingen - BOEK 5:\nTITEL 4: HOOFDSTUK 2:\nArt.5:86\n23 MARS 2019. — Loi\nintroduisant le Code des\nSR \" : \" iétés et des\n. Société a responsabilité Titulaire de droits de Titulaire de droits de societes\n9NSOPQ Belgium limitée 3W7E souscription French fr souscription 2023-06-28 ACTV assoc.latlor.\\s. et portant\ndes dispositions diverses -\nLivre 5: Titre 4: CHAPITRE\n2: Art. 5:86\n23 MARZ 2019. —\n9NSO0PQ Belgium g::i'f;::gr\":; g |PVTE Bezugsrechtsinhaber German Bezugsrechtsinhaber 2023-06-28 |ACTV gzzzltlzské:‘:f‘t::\"un ;\nVereinigungen\n5/119\n","contentLength":2929,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.722Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Law on companies\n(Official Gazette of\nNorth ' ' o6 Republic of North\nVB9ZHX Macedonia MK KomaHauTHO apywTso | XH7Z Ynpasuten Macedonian mk Upravitel 2023-06-28 ACTV Macedonia No.99/2022\nlast revision dated\n22.04.2022), article 156\nLaw on companies\n(Official Gazette of\nWEBHIRB North MK Cronaricka unTepecra oy AcouujaTueH unen Macedonian | mk Asocijativen chlen 2023-0628 |ACTV Republic of North\nMacedonia 3aegHuUa Macedonia N0.99/2022\nlast revision dated\n22.04.2022), article 562\nLaw on companies\n(Official Gazette of\nNorth ' o6 Republic of North\nWCNOAD Macedonia MK KomaHauTHO apywTso | XH7Z KomnnemeHTap Macedonian mk Komplementar 2023-06-28 ACTV Macedonia No.99/2022\nlast revision dated\n22.04.2022), article 156\nLaw on companies\n(Official Gazette of\nNorth KOMaHauTHO ApyLITEO . Republic of North\nWKATIG MK 1490 [ Maced k Kontrol: 2023-06-28 ACTV\nMacedonia €O akuun oHTponop acedonian m ontrolor Macedonia N0.99/2022\nlast revision dated\n22.04.2022), article 466\nLov 13.juni 1997 nr. 44\n3BF7SV Norway Aksjeselskap Y42 Aksjeeier Norwegian Aksjeeier 2023-06-28 ACTV om aksjeselskaper\n(aksjeloven) - §1.2\nLov 13.juni 1997 nr. 44\nAQHKLL Norway Aksjeselskap Y42 revisor Norwegian revisor 2023-06-28 ACTV om aksjeselskaper\n(aksjeloven) - §2.3, Ch7\nLov 13.juni 1997 nr. 44\nBWYHQQ Norway Aksjeselskap Y142 varamedlem Norwegian varamedlem 2023-06-28 ACTV om aksjeselskaper\n(aksjeloven) - §6.3.1\nLov 13.juni 1997 nr. 44\nNE38A7 Norway Aksjeselskap Y42 styremedlem Norwegian styremedlem 2023-06-28 ACTV om aksjeselskaper\n(aksjeloven) - §3.8.1\nLov 13.juni 1997 nr. 44\nNWM5IB Norway Aksjeselskap Y142 stedfortreder Norwegian stedfortreder 2023-06-28 ACTV om aksjeselskaper\n(aksjeloven) - §5.4.1\nLov 13.juni 1997 nr. 44\nPMJSLX Norway Aksjeselskap Y42 styreleder Norwegian styreleder 2023-06-28 ACTV om aksjeselskaper\n(aksjeloven) - §5.4.1\nLov 13. juni 1997 nr. 44\nPNR8CG Norway Aksjeselskap Yi42 stifte Norwegian stifte 2023-06-28 ACTV om aksjeselskaper\n(aksjeloven) - §2.1\nLov 13.juni 1997 nr. 44\nTUKACA Norway Aksjeselskap Y42 tegneren Norwegian tegneren 2023-06-28 ACTV om aksjeselskaper\n(aksjeloven) - §2.10\nLov 13.juni 1997 nr. 44\nV7D6LM Norway Aksjeselskap Y42 gransker Norwegian gransker 2023-06-28 ACTV om aksjeselskaper\n(aksjeloven) - §5.28\nLov 13.juni 1997 nr. 44\nYYLH4K Norway Aksjeselskap Y142 daglig leder Norwegian daglig leder 2023-06-28 ACTV om aksjeselskaper\n(aksjeloven) - §3.8.1\ne N S ) N P [ S o VY S I 172 = = I I S DS e[S,\nwoezJomr— Jo [ [ e Jews et e o famen T T v [ [ omrmaue\n839,\nwor e o [ [ Jeereaee e oo e v men [ [ www v [ [ [ Jowwane\ng o Jo [ [ Jewewdee Jow e fene o e [ [ wws v [ [ [ Jewimae\no Jowr Jo [ [ Jademe Jww e e o e [ [ wws v [ [ [ Jewimae\nT N TS A S PR PO Py o I I I EEE =0 A N N I e\n839,\nTR N (TS N S P PO Prorgy (7 S s T pewsm o [T Toaeaws\noo JomnJoo [ Teriee Jom oun T fwws pov [T Tomisaws\norseze foaar Joa ] 0000 [ 000 [eweedlss [es Sl oS siirtalr alshariah I N ErPECTTRN A I A R\n839,\n41/119\n","contentLength":2928,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.722Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"ook Jowr Jor [ | feisse [w0 [owspi o Jor Jovaemmena [ | fwmoow pov [ [ | ocicsainy\name o Joo [T Jedeiee o e Peme o e [T Tweem pav [ [ [ Jomisaue\ncwws o Joo [T Jewwbwse Jom e e [ Jew T T weem pav [ [ [ s\ne o Joo [T Jemieies Jom oo [ s pov [ Tomsaae\nR (N N A N P o v R PP [ Jewem oy [ Jaisaue\ne Jow Jo [T Jeeregee e Lo e v e [ [ owew pov [ [ [ Jowwaoe\nO S O A I et ot s N N i (N N (i A N IO\nI (N TS I I PR PPty [ P I I e =R (= I N S\no oo Joo [ [ Jewigss e ewiow [ pwes pav [ Tomsaue\no o Joo [ [ Jedee. o Jewsewio oo Jor Jomaemmema [ Twoow pov [ Jowisaray\nwom oo Jo [T e om Ja Dewe o Jewesr T T o pov [T Jowisars\no oo Joo [T Jedegwr o oo e o e [T weem pov [ [ [ Tomisaue\nT (e S I I PP o oy TR Fooyrn [ pwes pav [ Tomsaue\noo oo Joo [ | Tedtegoe e o e o Jmwress [T o pov [T T Jowrsaras\nv oo Jo [ Jedeee o e [ pees pov T [ [omsaae\no oo Joo [ [ Jewios [wn o [ pees pov T [ [omsaae\nT (N S A R e Fovay S P e Jor Jamaesaona [ [ fweew pov [ femicsaiey\nvowe oo Joo [ | Jewitwiss w0 Lee frewe o Jmermesw [T fweew pev [ [ oo\ns oo Joo [ [ Jeeiesise Jom fw fwwe o e [T fweew pev [ [ oo\nowrg oo Joo [ Jeoicedse w0 ewsew e o Jewwmes [ [ Jawoems v | [ | Joinaue\no oo Joa [ | Jewewwe e Lo Pewe w fmer T T o o [ [ | Jowrsar\nrows oo Joa [ [ Jeweiase Jow Jouoo [ pwes pav [ Tomisaue\no Jow Jo [ feweiise Jem foie e o fmerews [ | fmweew e [ [ | Jowinaes\nGowJow Jo [T Jewmwise e e e [ fweess [ [ owww pov [ [ [ [omwaoe\nmee o Joo [T Jedieges o Jewow [ pwes pav [ Tomisaue\ns Jow Jon [ T Jevewiwe e Lo e v e [ [ fwweem v | [ [ Jomigane\noo Joa [ [ Jeitios w0 owiou [ Jeweem pov [ Juisaue\no oo Joo [ [ Jeiwewoe o Jowew e o Jewwmes [ [ Jawoews v | [ | oinaue\nsowev oo Joo [ | Jeeise fem e e o wermear [ [ Jawoens v | [ | s\n42/119\n","contentLength":1712,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.722Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Voo Jomr Jon [ [ letemedwe w0 e e x| T Twem v [ T oo\nwiamsJomr— Joa [ [ Jewrtorae Jew e e o Jwermewr [T Twoem v [ [ Tomrmaae\nwoorJamar—Joa [ [ fewtemiwe w0 ot e o Jamen [T Twwoem v [ [ Tomrmaue\nT e S I S PV P P [ oo P P v S I N P17 Y VRN = I I I P ST,\nwong Jamr—Joa [ | oo Jem o e o Jewww T Twmoem v [ Torwaue\ng Jowr— Joo | Jeeien e Joe e o fwerman | [ moem v [ | omiwae\n839,\noo e o[ [ Jedemes e ewes e v e [ [ www v [ [ [ Jowwae\n3aKoH 0 3aapyrama -\nODJNNP Serbia RS 3aapyKHu cases 6UPM 4naH ynpasHor og6opa Serbian rs ¢lan upravnog odbora 2023-06-28 ACTV uynaH 72. ctas 2; 4naH 77.\ncTas 8. Tauka 11)\n3aKoH 0 3agpyrama - 4.\n2-3; unaH 15. cTas 3;\n4naH 19. cTas 2. Tauke\ni i 06+ 4),5), 6), 8); unan 23;\n0TULUO Serbia RS 3appyra E7W8 3appyrap Serbian rs zadrugar 2023-06-28 ACTV Gnan 24; 4nam 25, cas 1;\n4naH 28; 4naH 29; YnaH\n30; unaH 31; 4naH 32. cT.\n3.1 7; 4naH 33.\nJpywTso ca 3\nOVIBFY Serbia RS Or paHU4eHoM KIUs 0CTann 3aCTYNHUK Serbian rs ostali zastupnik 2023-06-28 ACTV aKoH O NpUBPeAHUM\nAPYLWTBUAMA - YnaH 32\noarosopHowhky\n2YWGIQ Serbia RS AkunoHapcko apywTso | YVPW 0CTann 3aCTYNHUK Serbian rs ostali zastupnik 2023-06-28 ACTV 3aKoH 0 npuspenHum\nAPYWTBUMa - YnaH 32.\n3aKoH 0 3aapyrama -\n3)SRS7 Serbia RS Sanpyra E7TW8 oCTanM 3aCTYNHIK Serbian rs ostali zastupnik 2023-06-28 |ACTV “naH 13. u 3akoH o\nNpUBPEAHUM ApYWTBMMA\n- unaH 32.\n3aKoH 0 3aapyrama -\n4BVENA Serbia RS 3aapyKHu cases 6UPM 4naH Hag3opHor og6opa Serbian rs ¢lan nadzornog odbora 2023-06-28 ACTV uynaH 72. ctas 2; 4naH 77.\ncTas 8. Tauka 12)\n3aKOH 0 NpuBpeaHNM\nSFPTNL Serbia RS AkunoHapcko apywTso | YVPW reHepasHu QUpeKTop Serbian rs generalni direktor 2023-06-28 ACTV APYLWTBUMa - 4naH 389;\nunaH 423.\n5TWBNO Serbia RS OpywTeeHo npeayseke |88TX “naH u3spLUHor on6opa Serbian rs ¢lan izvrsnog odbora direktora 2023-06-28 ACTV 3akoH 0 npeaysehuma -\nAvpekTopa 4naH 397. Tauke (3) u (4)\nJpywTso ca 3aKOH 0 NpuBpeaHNM\n632T0S Serbia RS Or paHU4eHoM KIUs NPVUBPEMEHN 3aCTYMHNK Serbian rs privremeni zastupnik 2023-06-28 ACTV APYLWTBUMa - YnaH 221.\noarosopHowhky cTas 4.\nJpywTso ca 3aKOH 0 NpuBpeaHNM\n73GXXV Serbia RS Or paHU4eHoM KIuS JMKBWOALVOHW YNpaBHUK Serbian rs likvidacioni upravnik 2023-06-28 ACTV APYLWTBUMa - 4naH 529.\noarosopHowhky ctas 1. n 2.\n43/119\n","contentLength":2227,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.722Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"3aKoH 0 3aapyrama -\n4naH 18. cTas 3. Tauka\n7KKWCN Serbia RS Sanpyra E7TW8 spumnau AyxHocTv Serbian rs vrgilac dugnosti direktora 2023-06-28 |ACTV 4); unaw 49; unaw 77.\navpekTopa\ncTas 1. Tauyka 11); unaH\n102. cTas 3. Tayka 2)\n8HZXEU Serbia RS 3aapyKHu cases 6UPM NPEACeAHNK HaasopHor Serbian rs predsednik nadzornog odbora 2023-06-28 ACTV 3aKoH 0 3apyrama -\nopnbopa YnaH 73. ctas 1 Ta4ka 6)\n3aKOH 0 NpuBpeaHNM\n9U8JKO Serbia RS AkunoHapcko apywTso | YVPW JMKBWOALVOHW YNpaBHUK Serbian rs likvidacioni upravnik 2023-06-28 ACTV ApYWTBUMA - YnaH 529.\nctas 1.1 2.\n9XZ5Y4 Serbia RS MpeayseTHik 9067 npeay3eTHUK Serbian rs preduzetnik 2023-06-28 [ACTV 3aKOH 0 NpUBpeAHuM\nAPYLWTBUMa - 4naH 83.\nBKDSOC Serbia RS OpTayko ApywTs0 ZPOY 0CTanu 3aCTynHUK Serbian rs ostali zastupnik 2023-06-28 ACTV 3aKoH 0 npuspenHIM\nAPYWTBUMa - YnaH 32.\n3aKOH 0 NpuBpeaHNM\nBOBSWX Serbia RS KomaHauTHO apywTso 73PZ KoMniemeHTap Serbian rs komplementar 2023-06-28 ACTV APYLWTBUMA - 4naH 9. CT.\n1. Tayka 2)\n3aKoH 0 jaBHUM\nCSBUXY Serbia RS JasHo npepysehe DEF6 WN3BPLUHN UPeKTop Serbian rs izvréni direktor 2023-06-28 ACTV :sae:)fe:;:\":: é:\"qa: ;3»\n28.\nLpywTeo ca 3aKOH 0 NpuBpeaHNM\n. . . ApYWTBUMa - YnaH 198.\nEGRYYC Serbia RS orpaHu4eHom KIU5 AVpeKTop Serbian rs direktor 2023-06-28 ACTV Cras 2. TauKa 2) v dnan\noArosopHowhy 218. cTas 1.\ne -- AUIONaREKO ApyITeo predsednk nadzormog odbora -- 20230628 ---\nopnbopa APYLWTBUAMA - YnaH\n. npeaceaHVK Haa30pHOr . . 3aKOH 0 jaBHUM\nFHKYYF Serbia RS JasHo npepysehe DEF6 opnbopa Serbian rs predsednik nadzornog odbora 2023-06-28 ACTV npepy3ehuma - un. 16-18.\n\" \" ” 06 3aKOH 0 NpuBpeaHNM\no sertre \" -- FLvoNaReKo apyLTeo | VRV coxpeTap ApywTeR serbian \" sekretar drusive -- 20230628 AT --- ApyuwTsnma - 4n. 448-450\nJpywTso ca 3aKOH 0 NpuBpeaHNM\nGLKRQT Serbia RS Or paHU4eHoM KIUs npeaceiHnK CKynwTuHe Serbian rs predsednik skupstine 2023-06-28 ACTV ApYWTBUMA - YnaH 209.\noarosopHowhky cTas 2.\n3aKOH 0 NpuBpeaHNM\nHD8ZLC Serbia RS AkumoHapcko apywTso |YVPW pesn3op Serbian s revizor 2023-06-28 ACTV ApYWTBUMA - YnaH 329.\ncTas 1. Tayka 14)\n3aKOH 0 NpuBpeaHNM\nHS3EIZ Serbia RS AkunoHapcko apywTso | YVPW 4naH Hap3opHor oabopa Serbian rs ¢lan nadzornog odbora 2023-06-28 ACTV ApYWTBUMA - YnaH 326.\ncTas 3. Tayka 2)\n3aKoH 0 jaBHUM\nHTNRVD Serbia RS JasHo npepysehe DEF6 AVpeKTop Serbian rs direktor 2023-06-28 ACTV npepy3ehnma - YnaH 15.\ncTas 1; 4n. 30-51.\n3aKoH 0 3aapyrama -\n4naH 84. ctas 1. Tauka\nIDNRXK Serbia RS 3aapyKHu cases 6UPM 3aApy>KHU pesn3op Serbian rs zadruzni revizor 2023-06-28 ACTV 3); 4unaH 85. unaH 85.\ncTas 1. Tauke 1)[J4); 4naH\n92.\n3aKOH 0 NpuBpeaHNM\nIXGJRQ Serbia RS OpTayko ApyLITBO ZPOY JMKBWOALVOHW YNpaBHUK Serbian rs likvidacioni upravnik 2023-06-28 ACTV ApYWTBUMA - YnaH 529.\nctas 1.1 2.\n. . 3aKoH 0 NpuBpesHUM\n. npvBpeMeHn cTapanal . privremeni staralac\nJDPRK] Serbia RS -- AkuuoHapcko apywTso | YVPW 330CTaBWTMHE Serbian rs Zaostavétine 2023-06-28 ACTV sfg/:;amma -unaH 172.\n\" \" . 06 3aKOH 0 NpuBpeaHNM\ne sertre \" -- KowanauTHo npywTeo|73P2 Trorypnere serbian \" prokuriete -- 20230628 AT --- ApyWTBIMA - 4naH 36.\n3aKoH 0 3aapyrama -\n4naH 18. cTas 3. Tauka\n4); 4naH 34.cT.1n 3;\n4naH 37. cTas 3. Tauka\n. . . 14); unaH 41. cTas 1.\nKLCKQH Serbi RS 3 E7W8 Serbi direkt 2023-06-28 ACTV N\nQl erbia anpyra AvpeKTop erbian rs irektor TadKa 7); nan 47; 4nam\n48; 4naH 50; 4n. 51-52;\n4naH 77. ctas 1. Tauka\n11); unaH 102. cTas 3.\nTayka 1)\n3aKOH 0 NpuBpeaHNM\nL7SBBO Serbia RS AkunoHapcko apywTso | YVPW HEN3BPLUHU AUPEeKTop Serbian rs neizvrsni direktor 2023-06-28 ACTV sfay:lT.Er:waK; ‘*2';?:\"3:8379'&\n391.\n3aKoH 0 3aapyrama -\n4naH 34. ctas 3; 4naH 37.\nL87ZMD Serbia RS 3appyra E7W8 4naH ynpasHor og6opa Serbian rs ¢lan upravnog odbora 2023-06-28 ACTV cTaB 3. Tayka 20); YnaH\n40; 4n. 41-42; 4n. 51-52;\nYnaH 77. cTas 2. Tayka 1)\nLDGU6Y Serbia RS JasHo npenysehe DEF6 BPLINNAL AYXKHOCTY Serbian rs vréilac duznosti direktora 2023-06-28 |ACTV 3aKOH 0 JasHmM\nAvpekTopa npeay3sehuma - 4n. 52-54.\n44/119\n","contentLength":3918,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.722Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"3aKoH 0 3aapyrama -\n4naH 34. ctas 3; 4naH 37.\nLyjomMT Serbia RS 3appyra E7W8 NPeAcenHnK cKynwTuHe Serbian rs predsednik skupstine 2023-06-28 ACTV cTaB 3. Tayka 20); YnaH\n37. cTas 5; 4naH 38. cT.\n5-6; unaH 43. cTas 4.\n\" \" \" 06 3aKoH 0 3aapyrama -\nLYV33D Serbia RS -- 3anpyxHu case3 6UPM npeacenHuk ynpasHor og6opa | Serbian rs predsednik upravnog odbora -- 2023-06-28 ACTV --- Ynan 73. cTas 1 Tauka 6)\n3aKoH 0 3aapyrama -\nMALOW) Serbia RS 3appyra E7W8 npeacenHuk ynpasHor og6opa | Serbian rs predsednik upravnog odbora 2023-06-28 ACTV unaH 34. ctas 3; 4naH 40.\ncTas 5.\nNpywso ca . . 3aKoH 0 npUBpeaHIM\n. npvBpeMeHn cTapanal . privremeni staralac\nMDFWGK Serbia RS Or paHU4eHoM KIuS 330CTaBWTMHE Serbian rs Zaostavétine 2023-06-28 ACTV APYLWTBUMa - YnaH 172.\noarosopHowhky cTas 2.\n3aKOH 0 NpuBpeaHNM\nMHY44N Serbia RS KomaHauTHO apywTso 73PZ JMKBWOALVOHW YNpaBHUK Serbian rs likvidacioni upravnik 2023-06-28 ACTV APYLWTBUMa - 4naH 529.\nctas 1.1 2.\n3aKOH 0 NpuBpeaHNM\n. . . o6 ApYWTBUMa - YnaH 326.\nNA315M Serbia RS AkunoHapcko apywTso | YVPW AVpEKTOp Serbian rs direktor 2023-06-28 ACTV Cras 2. TauKa 2); dn. 382-\n386\n3aKOH 0 NpuBpeaHNM\nJpywTso ca ApYWTBUMa - 4naH 198.\nNPDROL Serbia RS orpaHu4eHom KIUS 4naH Hag3opHor og6opa Serbian rs ¢lan nadzornog odbora 2023-06-28 ACTV cTaB 3. Tayka 2); 4naH\noarosopHowhky 228.cTaB 1; 4naH 229.\ncTas 2; 4n. 432.n 433\n3aKoH 0 jaBHUM\n0OJBADQ Serbia RS JasHo npeaysehe DEF6 YnaH Komucuje 3a pesunsyjy Serbian rs ¢lan komisije za revizuju 2023-06-28 ACTV npepy3ehnma - YnaH 55.\ncTas 2.\nPALTRV Serbia RS KomaHauTHO apywTso 73PZ 0CTanu 3aCTynHUK Serbian rs ostali zastupnik 2023-06-28 ACTV 3aKoH 0 npuspenHIM\nAPYWTBUMa - YnaH 32.\nJpywTso ca 3aKOH 0 NpuBpeaHNM\nPKPG28 Serbia RS orpaHu4eHom KIUS ynaH Serbian rs ¢lan 2023-06-28 ACTV ApYWTBUMa - 4naH 9.\noarosopHowhky cTas 1. Tauka 3)\n3aKoH 0 3aapyrama -\n4naH 13. n 3aKkoH o\nQ1SUG1 Serbia RS 3appyra E7W8 VKBV AALMOHN YN PaBHUK Serbian rs likvidacioni upravnik 2023-06-28 ACTV NpUBPEAHNM ApyWITEMMA\n-4naH 529. ctas 1.1 2.\n3aKOH 0 NpuBpeaHNM\nQHXUWG Serbia RS KomaHauTHO apywTso 73PZ KoMaHauTop Serbian rs komanditor 2023-06-28 ACTV APYLWTBUMA - 4naH 9. CT.\n1. Tayka 2)\n3aKOH 0 NpuBpeaHNM\nQKCJ8z Serbia RS AkumoHapcko apywTso |YVPW akuunoHap Serbian s akcionar 2023-06-28 ACTV ApYWTBUMa - 4naH 9.\ncTas 1. Tauka 4)\n\" \" . 06 3aKOH 0 NpuBpeaHNM\ne servre \" -- FLvoNaReKo apyLTeo | VRV Trorypner servn ® prokurite -- 2030628 AT --- ApywTenMa - 4n. 35-36.\nApywTso ca 3\n. . . aKkoH O NpUBPEeAHUM\nRCHAAO Serbia RS -- Or paHU4eHoM KIuS npoKypucTa Serbian rs prokurista 2023-06-28 ACTV APYWTBAMA - 4naH 35-36.\noarosopHowhky\n3aKoH 0 3aapyrama -\nRI2Z1M Serbia RS 3aapyKHu cases 6UPM npeacenHnk Serbian rs predsednik 2023-06-28 ACTV ynaH 72. cT. 2-3; 4naH 77.\ncTas 8. Tayka 10)\n3aKoH 0 3aapyrama -\n4naH 34. ctas 3; 4naH 37.\nSGJOFU Serbia RS 3appyra E7W8 4naH Hag3opHor og6opa Serbian rs ¢lan nadzornog odbora 2023-06-28 ACTV cTaB 3. Tayka 20); YnaH\n43; 4naH 46; 4n. 51-52;\nYnaH 77. cTas 2. Tayka 1)\nSOAKUK Serbia RS Mpeay3eTHUK 9067 nocnosoha Serbian rs poslovoda 2023-06-28 |ACTV 3aKoH 0 npuspenHum\nAPYLWTBUMa - 4naH 89.\n3aKoH 0 jaBHUM\nSRFjZM Serbia RS JaBHo npeay3ehe DEF6 fpoKypuCTa Serbian rs prokurista 20230628 |ACTV npeay3ekuma - Ynax 76.\n1 3aKOH 0 NpuBpeaHUM\nAPYWTBUMa - 4naH 36.\n3aKoH 0 3aapyrama -\n4naH 19. cTas 2. Tauka\n15); unaH 37. cTas 3.\nTayke 15)-16); 4naH 84.\nTAUME] Serbia RS 3agpyra E7W8 pesusop Serbian rs revizor 2023-06-28 ACTV cTas 1. Ta4ka 3); 4naH\n85; unaH 88. cTas 3.\nTayke 1), 4); 4n. 90-93;\n4naH 95. cT. 3. 1 5: unaH\n105.\no oo e [ | Jewewww Jeor Jwower e o feoses ] | e ey | ] [ [k\nU7CKFK Serbia RS DpywTseHo npeaysehe |88TX BPLINNAL AYXKHOCTY Serbian rs vréilac duznosti direktora 2023-06-28 |ACTV 3akoH 0 npeaysehuma -\nAvpekTopa YnaH 396. Tayka (3)\n45/119\n","contentLength":3747,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.722Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"3aKOH 0 NpuBpeaHNM\nUIKY2w Serbia RS AkunoHapcko apywTso | YVPW NPVUBPEMEHN 3aCTYMHNK Serbian rs privremeni zastupnik 2023-06-28 ACTV APYLWTBUMa - 4naH 397.\ncTas 1.\nJpywTso ca 3aKOH 0 NpuBpeaHNM\nUOX1F4 Serbia RS Or paHU4eHoM KIUs pesusop Serbian rs revizor 2023-06-28 ACTV ApYWTBUMa - 4naH 200.\noarosopHowhky cTas 1. Tauka 9)\nJpywTso ca 3aKOH 0 NpuBpeaHNM\nVIXII9 Serbia RS orpaHu4eHom KIUS EEEECEHHMK Han3sopHor Serbian rs predsednik nadzornog odbora 2023-06-28 ACTV APYWTBUMA - YnaH 229.\noarosopHowhky P cTas 2.\n3aKOH 0 NpuBpeaHNM\nAPYLWTBUMa - 4naH 326.\nVUL9BD Serbia RS AkumoHapcko apywTso |YVPW WN3BPLUHN UPeKTop Serbian rs izvréni direktor 2023-06-28 ACTV cTaB 3. Tayka 3); YnaH\n387.cTas 1. Tauka 1);\n4naH 388.\n\" \" = 06 3aKoH 0 jaBHUM\nst -- Jaswo penysehe pEre clan nadzomoq odbeore -- 2030628 AT --- npeay3ehuma - un. 16-18.\n3aKOH 0 NpuBpeaHNM\nWRGNWO Serbia RS OpTayko ApywTs0 ZPOY opTak Serbian rs ortak 2023-06-28 ACTV APYLWITBUMa - 4naH 9.\ncTas 1. Tauka 1)\n3aKOH 0 NpuBpeaHNM\nWUMYGP Serbia RS AkumoHapcko apywTso |YVPW NPeAcenHnK cKynwTuHe Serbian rs predsednik skupstine 2023-06-28 ACTV ApYWTBUMA - YnaH 333.\ncTas 1.\n3aKoH 0 3aapyrama -\nXPWFMN Serbia RS Sanpyra E7WS fpoKypuCTa Serbian rs prokurista 20230628 |ACTV UnaH 13. u 3aKoH 0\nNpUBPEAHUM ApYWTBMMA\n- unaH 36.\n. . 3aKoH 0 NpuBpesHUM\n\" npvBpeMeHu cTapanay \" privremeni staralac\nY8IMOS5 Serbia RS -- KomaHauTHO apywTso 73PZ 330CTaBWTMHE Serbian rs Zaostavitine 2023-06-28 ACTV cnf;/:;amma -4naH 172.\n3aKoH 0 3aapyrama -\nYEM75) Serbia RS Sanpyra E7TW8 NPeACeaHIK HaA30pHOr Serbian rs predsednik nadzornog odbora 2023-06-28 |ACTV unaH 34. cras 3; unau 37.\nopnbopa cTas 3. Tayka 20); 4naH\n43. cTas 5; 4n. 51-52.\nYGCDHC Serbia RS AkumoHapcko apywTso |YVPW npeaceaHyk on6opa Serbian rs predsednik odbora direktora 2023-06-28 ACTV 3aKoH 0 npuspenHIM\nAvpekTopa ApYWTBUMa - 4naH 400.\n\" 3aKOH 0 jaBHUM\no -- e e - :z:Ifl;&‘;HMK o e oz e -- e --- o\ncTas 3.\nYGVQZW Serbia RS OpTayko ApyLWITEO ZPOY 3aKOHCKM 3aCTYAHMK Serbian rs zakonski zastupnik 2023-06-28 |ACTV 3aKoH 0 npuspenHIM\nApYWTBUMa - 4naH 111,\nYGWHFW Serbia RS Mpeay3eTHUK 9067 npokypucTa Serbian rs prokurista 2023-06-28 |ACTV 3aKoH 0 npuspenHum\nAPYWTBUMa - 4naH 40.\n3aKoH 0 jaBHUM\nYu3ozy Serbia RS JasHo npeaysehe DEF6 0CTanu 3aCTynHUK Serbian rs ostali zastupnik 2023-06-28 ACTV npeay3sekuma - yna 76.\n1 3aKOH 0 NpuBpeaHUM\nAPYWTBUMa - YnaH 32.\n. . 3aKoH 0 NpuBpesHUM\n. npvBpeMeHn cTapanal . privremeni staralac\nZKYDCF Serbia RS -- OpTayko ApywTs0 ZPOY 330CTaBWTMHE Serbian rs Zaostavétine 2023-06-28 ACTV C‘]fay;.u;'EMMa -4naH 172.\nDJKFa1 South Africa | ZA Private Company GQVQ Business rescue practitioner | gy Business rescue practitioner 20230628 |ACTV Companies Act, 2008 -\n(practitioner) s.129\nR6132R South Africa | zA Public Company XE4Z Business rescue practitioner g jjicpy Business rescue practitioner 2023-06-28 |ACTV Companies Act, 2008 -\n(practitioner) s.129\n46/119\n","contentLength":2892,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.722Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Ley de Sociedades de\nN N N N . N 06 Capital (Real Decreto\n002NY5 Spain ES Sociedad Anonima 5RDO Socio Spanish Socio 2023-06-28 ACTV Legislativo 1/2010, de 2\nde julio) - Art.1\nLey 35/2003, de 4 de\no0TVOSI Spain ES Fondo de Inversion 5025 Depositario Spanish Depositario 2023-06-28 |ACTV noviembre, de -\nInstituciones de Inversién\nColectiva - Art.4\nSociedad de Ley de Sociedades de\n2RAQSL Spain ES Responsabilidad DP3Q Consejero delegado Spanish Consejero delegado 2023-06-28 |ACTV Capital (Real Decreto\nLimitada Legislativo 1/2010, de 2\ndejulio) - Art.249\nLey de Sociedades de\nN . . . 06 Capital (Real Decreto\n3lwuyu Spain ES Sociedad Anonima 5RDO Promotor Spanish Promotor 2023-06-28 ACTV Legislativo 1/2010, de 2\nde julio) - Art.27\nLey de Sociedades de\n6WPADW Spain ES Sociedad Anonima 5RDO Usufructuario Spanish Usufructuario 2023-06-28 |ACTV Capital (Real Decreto\nLegislativo 1/2010, de 2\ndejulio) - Art.121\nSociedad de Ley de Sociedades de\n9C5AFP Spain ES Responsabilidad DP3Q Administrador suplente Spanish Administrador suplente 2023-0628 | ACTV Capital (Real Decreto\nLimitada Legislativo 1/2010, de 2\ndejulio) - Art.216\nLey de Sociedades de\nN . . . 06 Capital (Real Decreto\n9JMOXD Spain ES Sociedad Anonima 5RDO Interventor Spanish Interventor 2023-06-28 ACTV Legislativo 1/2010, de 2\ndejulio) - Art.381\nSociedad de Ley de Sociedades de\n9WBLFO Spain ES Responsabilidad DP3Q Presidente Spanish Presidente 2023-0628 | ACTV Capital (Real Decreto\nLimitada Legislativo 1/2010, de 2\ndejulio) - Art.191\nLey de Sociedades de\nAL8GLE Spain ES Sociedad Anonima 5RDO Secretario Spanish Secretario 2023-06-28 |ACTV Capital (Real Decreto\nLegislativo 1/2010, de 2\ndejulio) - Art.191\nSociedad de Ley de Sociedades de\nCAWALQ Spain ES Responsabilidad DP3Q Auditor Spanish Auditor 2023-0628 | ACTV Capital (Real Decreto\nLimitada Legislativo 1/2010, de 2\ndejulio) - Art.263\nLey 35/2003, de 4 de\nCZHEPZ Spain ES Fondo de Inversion 5025 Participe Spanish Participe 2023-06-28 |ACTV noviembre, de -\nInstituciones de Inversién\nColectiva - Art.5\nLey de Sociedades de\n’ : ' o ' o o6 Capital (Real Decreto\nEALQDL Spain ES Sociedad Anonima 5RDO Obligacionista Spanish Obligacionista 2023-06-28 ACTV Legislativo 1/2010, de 2\nde julio) - Art.265\nSociedad de Ley de Sociedades de\nFQFPM7 Spain ES Responsabilidad DP3Q Fundador Spanish Fundador 2023-0628 | ACTV Capital (Real Decreto\nLimitada Legislativo 1/2010, de 2\nde julio) - Art.73\nSociedad de Ley de Sociedades de\n\" P PR \" \" P Capital (Real Decreto\nFVJMXB Spain ES Responsabilidad DP3Q Obligacionista Spanish Obligacionista 2023-06-28 ACTV PN\nLimitada Legislativo 1/2010, de 2\nde julio) - Art.265\nLey de Sociedades de\nN . . . 06 Capital (Real Decreto\nG8HYXM Spain ES Sociedad Anonima S5RDO Otorgante Spanish Otorgante 2023-06-28 ACTV Legislativo 1/2010, de 2\nde julio) - Art.51\nSociedad de Ley de Sociedades de\nN o N . N Capital (Real Decreto\nJJFGDT Spain ES Responsabilidad DP3Q Usufructuario Spanish Usufructuario 2023-06-28 ACTV PN\nLimitada Legislativo 1/2010, de 2\ndejulio) - Art.121\nSociedad de Ley de Sociedades de\nN P . Capital (Real Decreto\nKGJBSM Spain ES Responsabilidad DP3Q Otorgante Spanish Otorgante 2023-06-28 ACTV PN\nLimitada Legislativo 1/2010, de 2\nde julio) - Art.51\n47/119\n","contentLength":3227,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.723Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Ley de Sociedades de\n\" \" . . 06 Capital (Real Decreto\nKSL1IMQ Spain ES Sociedad Anonima 5RDO Fundador Spanish Fundador 2023-06-28 ACTV Legislativo 1/2010, de 2\nde julio) - Art.27\nLey de Sociedades de\nN N N \" . \" 06 Capital (Real Decreto\nKUWBS Spain ES Sociedad Anonima 5RDO Auditor Spanish Auditor 2023-06-28 ACTV Legislativo 12010, de 2\nde julio) - Art.107\nLey de Sociedades de\nL82TON Spain ES Sociedad Anonima 5RDO Accionista Spanish Accionista 2023-06-28 |ACTV Capital (Real Decreto\nLegislativo 1/2010, de 2\nde julio) - Art.81\nLey de Sociedades de\nN N N - . P 06 Capital (Real Decreto\nLC1PXN Spain ES Sociedad Anonima 5RDO Liquidador Spanish Liquidador 2023-06-28 ACTV Legislativo 12010, de 2\nde julio) - Art.160\nLey de Sociedades de\nLczIP3 Spain ES Sociedad Anonima 5RDO Presidente Spanish Presidente 2023-06-28 |ACTV Capital (Real Decreto\nLegislativo 1/2010, de 2\nde julio) - Art.191\nSociedad de Ley de Sociedades de\nN o - . P Capital (Real Decreto\nNVGU)4 Spain ES Responsabilidad DP3Q Liquidador Spanish Liquidador 2023-06-28 ACTV PN\nLimitada Legislativo 1/2010, de 2\nde julio) - Art.74\nSociedad de Ley de Sociedades de\nPUXJEO Spain ES Responsabilidad DP3Q Administrador Spanish Administrador 2023-0628 | ACTV Capital (Real Decreto\nLimitada Legislativo 1/2010, de 2\nde julio) - Art.4bis\nSociedad de Ley de Sociedades de\nSBUSKZ Spain ES Responsabilidad DP3Q Socio Spanish Socio 2023-06-28 |ACTV Capital (Real Decreto\nLimitada Legislativo 1/2010, de 2\nde julio) - Art.1\nSociedad de Ley de Sociedades de\nN o N . N Capital (Real Decreto\nSOX39V Spain ES Responsabilidad DP3Q Secretario Spanish Secretario 2023-06-28 ACTV PN\nLimitada Legislativo 1/2010, de 2\nde julio) - Art.191\nLey de Sociedades de\nTIDYOP Spain ES Sociedad Anonima 5RDO Administrador Spanish Administrador 2023-06-28 |ACTV Capital (Real Decreto\nLegislativo 1/2010, de 2\nde julio) - Art.23\nLey de Sociedades de\nN N N . . \" 06 Capital (Real Decreto\nWUGLAN Spain ES Sociedad Anonima 5RDO Consejero delegado Spanish Consejero delegado 2023-06-28 ACTV Legislativo 12010, de 2\nde julio) - Art.249\nLey de Sociedades de\nZNV3EG Spain ES Sociedad Anonima 5RDO Administrador suplente Spanish Administrador suplente 2023-06-28 |ACTV Capital (Real Decreto\nLegislativo 1/2010, de 2\nde julio) - Art.216\nLey 35/2003, de 4 de\nZXWEMF Spain ES Fondo de Inversion 5025 Sociedad gestora Spanish Sociedad gestora 2023-06-28 |ACTV noviembre, de \"\nInstituciones de Inversién\nColectiva - Art.1\n\\deell forening (som .\nL ki ki\n7QX))4 Sweden SE bedriver 1TNO Verkstallande direktsr Swedish sv Verkstallande direktsr 2023-06-28 |ACTV -ag om ekonomisia\n. féreningar - 7 kap: 5.27\nnaringsverksamhet)\nBF3WOF Sweden SE Aktiebolag XJHM Verkstallande direktsr Swedish sv Verkstallande direktsr 2023-06-28 |ACTV Aktiebolagslag, 2005 - 7\nkap: s.32; 8 kap: s5.27, 50\nLag om handelsbolag och\nC3LXOF Sweden SE Kommanditbolag CX05 Komplementar Swedish sv Komplementar 2023-06-28 ACTV enkla bolag, 1980 - 1 kap:\ns.2\n\\deell forening (som .\nL ki ki\nEOWVDR Sweden SE bedriver 1TNO Ordférande Swedish sv ordférande 2023-06-28 |ACTV -ag om ekonomisia\n. féreningar - 7 kap: .17\nnaringsverksamhet)\n\\deell forening (som .\nGT988T Sweden SE bedriver 1TNO Medlem Swedish sv Medlem 2023-06-28 |ACTV Lag om ekonomiska\n. féreningar - 1 kap: 5.3\nnaringsverksamhet)\nLag om handelsbolag och\nMLTDPF Sweden SE Kommanditbolag CX05 Sérskild likvidator Swedish sv Sérskild likvidator 2023-06-28 ACTV enkla bolag, 1980 - 2 kap:\ns.31\n48/119\n","contentLength":3448,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.723Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Lag om handelsbolag och\nONVWJA Sweden SE Kommanditbolag CX05 Kommanditdelagaren Swedish sv Kommanditdelagaren 2023-06-28 ACTV enkla bolag, 1980 - 1 kap:\ns.2\nLag om handelsbolag och\nSCP321 Sweden SE Kommanditbolag CX05 Bolagsman Swedish sv Bolagsman 2023-06-28 ACTV enkla bolag, 1980 - 3 kap:\n5.2\nIdeell férening (som .\nUYVSER Sweden SE bedriver 1TNO Revisor Swedish sv Revisor 2023-0628 |ACTV Lag om ekonomiska\n. féreningar - 1 kap: 5.3\nnaringsverksamhet)\nIdeell férening (som i\nL ki ki\nVD29ZN Sweden SE bedriver 1TNO Styrelseledamot Swedish sv Styrelseledamot 2023-06-28 |ACTV g om ekonomisia\n. féreningar - 1 kap: 5.3\nnaringsverksamhet)\nLoi fédérale, sur les\nplacements collectifs de\ncapitaux, (Loi sur les\n09VUYQ Switzerland CH Fonds FLNB Commandité French fr Commandité 2023-06-28 ACTV placements collectifs,\nLPCC), du 23 juin 2006\n(Etat le 1ler janvier 2020)\n- Art.98\nBundesgesetz tiber die\nkollektiven Kapitalanlagen\n. Kommanditarinnen und Kommanditarinnen und 06 (Kollektivanlagengesetz,\n09VUYQ Switzerland CH Fonds FLNB Kommanditére German Kommanditére 2023-06-28 ACTV KAG) vom 23. Juni 2006\n(Stand am 1. Januar\n2020) - Art.98\nLegge federale sugli\ninvestimenti collettivi di\ncapitale (Legge sugli\n09VUYQ Switzerland CH Fondo FLNB Accomandatario Italian it Accomandatario 2023-06-28 |ACTV investimenti collettivi,\nLICol) del 23 giugno 2006\n(Stato 1° gennaio 2020) -\nArt.98\nLoi fédérale complétant le\nCode civil suisse (Livre\n521C1R Switzerland |CH Société a responsabllité | 3yq Président French fr Président 2023-0628 |ACTV cinquiéme: Droit des\nlimitée obligations) du 30 mars\n1911 (Etat le ler juillet\n2021) - Art.809\nBundesgesetz betreffend\ndie Erganzung des\nSchweizerischen\n521C1R Switzerland |CH Gesellschaft mit 3EKS Vorsitz German Vorsitz 2023-0628 |ACTV Zivilgesetzbuches\nbeschrankter Haftung (Funfter Teil:\nObligationenrecht) vom\n30. Mérz 1911 (Stand am\n1. Juli 2021) - Art.809\nLegge federale di\ncomplemento del Codice\nPN . civile svizzero (Libro\n521CIR Switzerland | CH fi:qcl'tittz agaranzia 3EKS Presidenza talian it Presidenza 2023-06-28 |ACTV quinto: Diritto delle\nobbligazioni) del 30\nmarzo 1911 (Stato 1°\nluglio 2021) - Art.809\nLoi fédérale, sur les\nplacements collectifs de\ncapitaux, (Loi sur les\n5DSFUY Switzerland CH Fonds FLNB Commanditaire French fr Commanditaire 2023-06-28 |ACTV placements collectifs,\nLPCC), du 23 juin 2006\n(Etat le ler janvier 2020)\n- Art.98\nBundesgesetz tiber die\nkollektiven Kapitalanlagen\nN = \" 06 (Kollektivanlagengesetz,\nS5DSFUY Switzerland CH Fonds FLNB Komplementar German Komplementar 2023-06-28 ACTV KAG) vom 23. Juni 2006\n(Stand am 1. Januar\n2020) - Art.98\nLegge federale sugli\ninvestimenti collettivi di\ncapitale (Legge sugli\n5DSFUY Switzerland CH Fondo FLNB Accomandanto Italian it Accomandanto 2023-06-28 |ACTV investimenti collettivi,\nLICol) del 23 giugno 2006\n(Stato 1° gennaio 2020) -\nArt.98\n49/119\n","contentLength":2865,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.723Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Loi fédérale complétant le\nCode civil suisse (Livre\n6BIUGL Switzerland CH Société anonyme MVIl Secrétaire French fr Secrétaire 2023-06-28 |ACTV cinquieme: Droit des\nobligations) du 30 mars\n1911 (Etat le ler juillet\n2021) - Art.712\nBundesgesetz betreffend\ndie Erganzung des\nSchweizerischen\n6BIUGL Switzerland [CH Aktiengesellschaft Mvil Sekretar German Sekretar 2023-06-28 [ACTV (Z;;'r\"?tiie%fi‘_‘d‘es\nObligationenrecht) vom\n30. Mérz 1911 (Stand am\n1. Juli 2021) - Art.712\nLegge federale di\ncomplemento del Codice\ncivile svizzero (Libro\n6BIUGL Switzerland CH Societa anonima MVII Segretario Italian it Segretario 2023-06-28 ACTV quinto: Diritto delle\nobbligazioni) del 30\nmarzo 1911 (Stato 1°\nluglio 2021) - Art.712\nLoi fédérale complétant le\nCode civil suisse (Livre\n7HGG)7 Switzerland | CH Société a responsabilité [ 3y Organe de révision French fr Organe de révision 2023-0628 | ACTV cinquieme: Droit des\nlimitée obligations) du 30 mars\n1911 (Etat le ler juillet\n2021) - Art.818\nBundesgesetz betreffend\ndie Erganzung des\nSchweizerischen\n7HGG)7 Switzerland |CH Gesellschaft mit 3EKS Revisionsstelle German Revisionsstelle 2023-0628 |ACTV Zivilgesetzbuches\nbeschrankter Haftung (Funfter Teil:\nObligationenrecht) vom\n30. Mérz 1911 (Stand am\n1.Juli 2021) - Art.818\nLegge federale di\ncomplemento del Codice\ne : civile svizzero (Libro\nSi t\nTHGG)7 Switzerland | CH g & garanzia 3EKS Ufficio di revisione talian it Ufficio di revisione 20230628 |ACTV quinto: Diritto delle\nimitata I\nobbligazioni) del 30\nmarzo 1911 (Stato 1°\nluglio 2021) - Art.818\nLoi fédérale, sur les\nplacements collectifs de\ncapitaux, (Loi sur les\nBD5PBL Switzerland CH Fonds FLNB Société d'audit agréée French fr Société d'audit agréée 2023-06-28 ACTV placements collectifs,\nLPCC), du 23 juin 2006\n(Etat le 1ler janvier 2020)\n- Art.126\nBundesgesetz tiber die\nkollektiven Kapitalanlagen\nBDSPBL Switzerland | CH Fonds FLNB Priifgesellschaft German Prifgesellschaft 2023-0628 | ACTV g’fi”)‘*bg:’z\";gfi:lg‘;z%t;\n(Stand am 1. Januar\n2020) - Art.126\nLegge federale sugli\ninvestimenti collettivi di\ncapitale (Legge sugli\nBD5PBL Switzerland CH Fondo FLNB Societa di audit Italian it Societa di audit 2023-06-28 |ACTV investimenti collettivi,\nLICol) del 23 giugno 2006\n(Stato 1° gennaio 2020) -\nArt.126\nLoi fédérale complétant le\nCode civil suisse (Livre\nBZSNV5 Switzerland |CH Société a responsabllité | 3yq Associé French fr Associé 2023-0628 |ACTV cinquieme: Droit des\nlimitée obligations) du 30 mars\n1911 (Etat le ler juillet\n2021) - Art.775\nBundesgesetz betreffend\ndie Erganzung des\nSchweizerischen\ni Gesellschaft mit Zivilgesetzbuches\nBZSNV5 Switzerland CH beschrankter Haftung 3EKS Gesellschafter German Gesellschafter 2023-06-28 ACTV (Fiinfter Teil:\nObligationenrecht) vom\n30. Mérz 1911 (Stand am\n1.Juli 2021) - Art.775\nLegge federale di\ncomplemento del Codice\nPN . civile svizzero (Libro\nBZSNVS Switzerland | CH fi;cl'titt\"; agaranzia 3EKS Soco talian it Soco 2023-06-28 |ACTV quinto: Diritto delle\nobbligazioni) del 30\nmarzo 1911 (Stato 1°\nluglio 2021) - Art.775\n50/119\n","contentLength":3036,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.725Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"23 MARS 2019. — Loi\nintroduisant le Code des\n\" \" sociétés et des\nAWBFSV Belgium Société anonyme R85P Membre du conseil de French fr Membre du conseil de 2023-06-28 | ACTV assodiations et portant\ndirection direction y o .\ndes dispositions diverses -\nLivre 7: Titre 4: CHAPITRE\n1: Art. 7:85\n23 MAART 2019. — Wet\ntot invoering van het\nWetboek van\nvennootschappen en\nAWBFSV Belgium Naamloze vennootschap [ R85P Lid van directieraad Dutch Lid van directieraad 2023-06-28 ACTV verenigingen en\nhoudende diverse\nbepalingen - BOEK 7:\nTITEL 4: HOOFDSTUK 1:\nArt.7:104\n23 MARZ 2019. —\nAWBFSV Belgium Aktiengesellschaft R85P Direktionsratsmitglied German Direktionsratsmitglied 2023-06-28 |ACTV Gesetzbuch der\nGesellschaften und\nVereinigungen\n23 MARS 2019. — Loi\nintroduisant le Code des\n. sociétés et des\nEXM6MH Belgium Association sansbut 5y Membre French fr Membre 2023-06-28 | ACTV associations et portant\nlucratif des dispositions diverses -\nTitre 1: CHAPITRE 1: Art.\n1.2\n23 MAART 2019. — Wet\ntot invoering van het\nWetboek van\nEXM6MH Belgium Vereniging zonder W3WH Lid Dutch Lid 2023-06-28 | ACTV vennootschappen en\nwinstoogmerk verenigingen en\nhoudende diverse\nbepalingen - TITEL 1:\nHOOFDSTUK 1: Art. 1.2\n23 MARZ 2019. —\nEXM6MH Belgium Vereinigung ohne W3WH Mitglied German Mitglied 2023-06-28 |ACTV Gesetzbuch der\nGewinnerzielungsabsicht Gesellschaften und\nVereinigungen\n23 MAART 2019. — Wet\ntot invoering van het\nWetboek van\nHouder van met medewerking Houder van met medewerking vennootschappen en\nF23SLY Belgium Besloten Vennootschap |3W7E van de vennootschap Dutch van de vennootschap 2023-06-28 ACTV verenigingen en\nuitgegeven certificaten uitgegeven certificaten houdende diverse\nbepalingen - BOEK 5:\nTITEL 4: HOOFDSTUK 2:\nArt.5:86\n23 MARS 2019. — Loi\nintroduisant le Code des\nSArd N o Titulaire de certificats émis Titulaire de certificats émis sociétés et des\nF23SLY Belgium fi;(;lteétee a responsabilite 3W7E avec la collaboration de la French fr avec la collaboration de la 2023-06-28 ACTV associations et portant\nsociété société des dispositions diverses -\nLivre 5: Titre 4: CHAPITRE\n2: Art. 5:86\nInhaber von Zertifikaten, die Inhaber von Zertifikaten, die 23 MARZ 2019. —\nF23sLY Belgium Gesellschaft mit 3W7E unter Mitwirkung des German unter Mitwirkung des 2023-06-28 |ACTV Gesetzbuch der\nbeschrankter Haftung Unternehmens ausgestellt Unternehmens ausgestellt Gesellschaften und\nwurden wurden Vereinigungen\n23 MARS 2019. — Loi\nintroduisant le Code des\n- sociétés et des\nF6YSZC Belgium fif;f;i:?non sans but W3WH Liquidateur French fr Liquidateur 2023-06-28 ACTV associations et portant\ndes dispositions diverses -\nLivre 2: Titre 8: CHAPITRE\n2: Art. 2:118\n23 MAART 2019. — Wet\ntot invoering van het\nWetboek van\nVi P d vennootschappen en\nF6YSZC Belgium ereniging zonder W3WH Vereffenaar Dutch Vereffenaar 2023-06-28 |ACTV verenigingen en\nwinstoogmerk \"\nhoudende diverse\nbepalingen - BOEK 2:\nTITEL 6: HOOFDSTUK 2:\nArt.2:118\n23 MARZ 2019. —\nF6YSZC Belgium Vereinigung ohne |,y 3y Liquidator German Liquidator 20230628 |ACTV Gesetzbuch der\nGewinnerzielungsabsicht Gesellschaften und\nVereinigungen\n23 MARS 2019. — Loi\nintroduisant le Code des\n\" P Titulaire de droits de Titulaire de droits de societ.es.et des\nGGYNJZ Belgium Société anonyme R85P souscription French fr souscription 2023-06-28 ACTV assoc_latlor}s_ et po_rtant\ndes dispositions diverses -\nLivre 7: Titre 4: CHAPITRE\n2: Art. 7:135\n6/119\n","contentLength":3399,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.728Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Loi fédérale, sur les\nplacements collectifs de\ncapitaux, (Loi sur les\nCNNGBH Switzerland CH Fonds FLNB Liquidateur French fr Liquidateur 2023-06-28 ACTV placements collectifs,\nLPCC), du 23 juin 2006\n(Etat le 1ler janvier 2020)\n- Art.138a\nBundesgesetz tiber die\nkollektiven Kapitalanlagen\nN - N P N 06 (Kollektivanlagengesetz,\nCNNGBH Switzerland CH Fonds FLNB Konkursliquidatorin German Konkursliquidatorin 2023-06-28 ACTV KAG) vom 23. Juni 2006\n(Stand am 1. Januar\n2020) - Art.138a\nLegge federale sugli\ninvestimenti collettivi di\ncapitale (Legge sugli\nCNNGBH Switzerland CH Fondo FLNB Liquidatore Italian it Liquidatore 2023-06-28 |ACTV investimenti collettivi,\nLICol) del 23 giugno 2006\n(Stato 1° gennaio 2020) -\nArt.138a\nLoi fédérale complétant le\nCode civil suisse (Livre\nCUKVBB Switzerland | CH Société anonyme MVl Participant French fr Participant 2023-06-28 |ACTV cinquime: Droit des\nobligations) du 30 mars\n1911 (Etat le ler juillet\n2021) - Art.656¢C\nBundesgesetz betreffend\ndie Erganzung des\nSchweizerischen\nCukvBB Switzerland [CH Aktiengesellschaft Mvil Partizipant German Partizipant 2023-06-28 [ACTV (Z;E:?tfie;éfil-mhes\nObligationenrecht) vom\n30. Mérz 1911 (Stand am\n1. Juli 2021) - Art.656C\nLegge federale di\ncomplemento del Codice\ncivile svizzero (Libro\nCUKVBB Switzerland CH Societa anonima MVII Partecipante Italian it Partecipante 2023-06-28 ACTV quinto: Diritto delle\nobbligazioni) del 30\nmarzo 1911 (Stato 1°\nluglio 2021) - Art.656¢\nLoi fédérale complétant le\nCode civil suisse (Livre\nDGX1LL Switzerland | CH Société anonyme mviI Représentant dépositaire French fr Représentant dépositaire 2023-06-28 |ACTV cinguiéme: Droit des\nobligations) du 30 mars\n1911 (Etat le ler juillet\n2021) - Art.689\nBundesgesetz betreffend\ndie Erganzung des\nSchweizerischen\nDGX1LL Switzerland | CH Aktiengesellschaft Ml Depotvertrete German Depotvertrete 2023-0628 | ACTV (Z;E:?tfie;éfil-mhes\nObligationenrecht) vom\n30. Mérz 1911 (Stand am\n1.Juli 2021) - Art.689\nLegge federale di\ncomplemento del Codice\ncivile svizzero (Libro\nDGX1LL Switzerland CH Societa anonima MvIl Rappresentante depositare Italian it Rappresentante depositare 2023-06-28 ACTV quinto: Diritto delle\nobbligazioni) del 30\nmarzo 1911 (Stato 1°\nluglio 2021) - Art.689\nLoi fédérale complétant le\nCode civil suisse (Livre\nDIWYAR Switzerland |CH Société a responsabllité | 3yq Gérant French fr Gérant 2023-0628 |ACTV cinquieme: Droit des\nlimitée obligations) du 30 mars\n1911 (Etat le ler juillet\n2021) - Art.809\nBundesgesetz betreffend\ndie Erganzung des\nSchweizerischen\nDIWYAR Switzerland |CH Gesellschaft mit 3EKS Geschaftsfiihrer German Geschaftsfiihrer 2023-0628 |ACTV Zivilgesetzbuches\nbeschrankter Haftung (Funfter Teil:\nObligationenrecht) vom\n30. Mérz 1911 (Stand am\n1. Juli 2021) - Art.809\nLegge federale di\ncomplemento del Codice\nPN . civile svizzero (Libro\nDIWYAR Switzerland | CH fi:qcl'tittz agaranza 3EKS Gerente talian it Gerente 20230628 |ACTV quinto: Diritto delle\nobbligazioni) del 30\nmarzo 1911 (Stato 1°\nluglio 2021) - Art.809\n51/119\n","contentLength":3014,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.729Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Code civil suisse du 10\n) . L L décembre 1907 (Etat le\nDYAOED Switzerland CH Fondation 2)z4 Organe de révision French fr Organe de révision 2023-06-28 ACTV ler janvier 2021) -\nArt.83b\nSchweizerisches\nZivilgesetzbuch vom 10.\nDYAOED Switzerland CH Stiftung 2)z4 Revisionsstelle German Revisionsstelle 2023-06-28 ACTV Dezember 1907 (Stand\nam 1. Januar 2021) -\nArt.83b\nCodice civile svizzero del\nDYAOED Switzerland | CH Fondazione 274 Ufficio di revisione talian it Ufficio di revisione 2023-06-28 |ACTV 10 dicembre 1907 (Stato\n1° gennaio 2021) -\nArt.83b\nCode civil suisse du 10\nEWZ8HD Switzerland | CH Fondation 2jz4 [Membre de] L'organe French fr [Membre de] L'organe 2023-0628 | ACTV décembre 1907 (Etat le\nsupréme de la fondation supréme de la fondation ler janvier 2021) -\nArt.83b\nSchweizerisches\n- T Zivilgesetzbuch vom 10.\n. ) [Mitglied des] Oberste[n] [Mitglied des] Oberste[n]\nEWZ8HD Switzerland CH Stiftung 2)z4 Stiftungsorgan(s] German Stiftungsorgan(s] 2023-06-28 ACTV Dezember 1907 (Stand\nam 1. Januar 2021) -\nArt.83b\nCodice civile svizzero del\nEWZ8HD Switzerland CcH Fondazione 2)z4 [Membro dl]_l organo superioref,, .. it [Membro d|]_| organo superiore 2023-06-28 ACTV l? dlcem_bre 1907 (Stato\ndella fondazione della fondazione 1° gennaio 2021) -\nArt.83b\nLoi fédérale complétant le\nCode civil suisse (Livre\nGV4RS) Switzerland | CH Société anonyme Mvil Membre du conseil French fr Membre du conseil 2023-06-28 |ACTV cinquieme: Droit des\nd’administration d’administration obligations) du 30 mars\n1911 (Etat le ler juillet\n2021) - Art.707\nBundesgesetz betreffend\ndie Erganzung des\nSchweizerischen\n. . Mitglied des Verwaltungsrat Mitglied des Verwaltungsrat 06 Zivilgesetzbuches\nGVA4RS) Switzerland CH Aktiengesellschaft MVII der Gesellschaft German der Gesellschaft 2023-06-28 ACTV (Fiinfter Teil:\nObligationenrecht) vom\n30. Mérz 1911 (Stand am\n1.Juli 2021) - Art.707\nLegge federale di\ncomplemento del Codice\n\" P, \" o ivile svizzero (Libro\n. PN \" Membro di consiglio \" P Membro di consiglio civi e\nGV4RS) Switzerland CH Societa anonima MVl d’amministrazione Italian it d'amministrazione 2023-06-28 ACTV quln.to. E.)lrlt.to delle\nobbligazioni) del 30\nmarzo 1911 (Stato 1°\nluglio 2021) - Art.707\nLoi fédérale complétant le\nCode civil suisse (Livre\nHBF4SK Switzerland [CH Société anonyme Mvil Représentant indépendant French fr Représentant indépendant 2023-06-28 [ACTV cinquieme: Droit des\nobligations) du 30 mars\n1911 (Etat le ler juillet\n2021) - Art.689\nBundesgesetz betreffend\ndie Erganzung des\nSchweizerischen\n. . Unabhéangige Unabhéangige 06 Zivilgesetzbuches\nHBF4SK Switzerland CH Aktiengesellschaft MVII Stimmrechtsvertrete German Stimmrechtsvertrete 2023-06-28 ACTV (Fiinfter Teil:\nObligationenrecht) vom\n30. Mérz 1911 (Stand am\n1.Juli 2021) - Art.689\nLegge federale di\ncomplemento del Codice\ncivile svizzero (Libro\nHBF4SK Switzerland CH Societa anonima MvIl Rappresentante indipendente | Italian it Rappresentante indipendente 2023-06-28 ACTV quinto: Diritto delle\nobbligazioni) del 30\nmarzo 1911 (Stato 1°\nluglio 2021) - Art.689\nLoi fédérale complétant le\nCode civil suisse (Livre\nHOAPS1 Switzerland |CH Société a responsabllité | 3yq Usufruitier French fr Usufruitier 2023-0628 |ACTV cinquieme: Droit des\nlimitée obligations) du 30 mars\n1911 (Etat le ler juillet\n2021) - Art.806b\nBundesgesetz betreffend\ndie Erganzung des\nSchweizerischen\nHOAP51 Switzerland |CH Gesellschaft mit 3EKS Nutzniesser German Nutzniesser 2023-0628 |ACTV Zivilgesetzbuches\nbeschrankter Haftung (Funfter Teil:\nObligationenrecht) vom\n30. Mérz 1911 (Stand am\n1.Juli 2021) - Art.806b\n52/119\n","contentLength":3584,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.729Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Legge federale di\ncomplemento del Codice\nPN . civile svizzero (Libro\nHOAP51 Switzerland | CH fi;cl'titt\"; agaranzia 3EKS Usufrutto talian it Usufrutto 2023-06-28 |ACTV quinto: Diritto delle\nobbligazioni) del 30\nmarzo 1911 (Stato 1°\nluglio 2021) - Art.806b\nLoi fédérale complétant le\nCode civil suisse (Livre\ncinquiéme: Droit des\nJYC364 Switzerland CH Société anonyme MVII Curateur French fr Curateur 2023-06-28 ACTV obligations) du 30 mars\n1911 (Etat le ler juillet\n2021) - Art.725a\nBundesgesetz betreffend\ndie Erganzung des\nSchweizerischen\nJYC364 Switzerland [CH Aktiengesellschaft Mvil Sachwalter German Sachwalter 2023-06-28 [ACTV (Z;;'r\"?tisre;zki’l‘_‘d‘es\nObligationenrecht) vom\n30. Mérz 1911 (Stand am\n1.Juli 2021) - Art.725a\nLegge federale di\ncomplemento del Codice\ncivile svizzero (Libro\nJYC364 Switzerland CH Societa anonima MVII Commissario Italian it Commissario 2023-06-28 ACTV quinto: Diritto delle\nobbligazioni) del 30\nmarzo 1911 (Stato 1°\nluglio 2021) - Art.725a\nLoi fédérale, sur les\nplacements collectifs de\ncapitaux, (Loi sur les\nMLVNXU Switzerland CH Fonds FLNB Actionnaire French fr Actionnaire 2023-06-28 ACTV placements collectifs,\nLPCC), du 23 juin 2006\n(Etat le 1ler janvier 2020)\n-Art.4l\nBundesgesetz tiber die\nkollektiven Kapitalanlagen\nN Unternehmeraktionarinnen Unternehmer Aktionar / 06 (Kollektivanlagengesetz,\nMLVNXU Switzerland CH Fonds FLNB und -aktionare German Aktionar 2023-06-28 ACTV KAG) vom 23. Juni 2006\n(Stand am 1. Januar\n2020) - Art.41\nLegge federale sugli\ninvestimenti collettivi di\ncapitale (Legge sugli\nMLVNXU Switzerland CH Fondo FLNB Azionista Italian it Azionista 2023-06-28 ACTV investimenti collettivi,\nLICol) del 23 giugno 2006\n(Stato 1° gennaio 2020) -\nArt.41\nLoi fédérale complétant le\nCode civil suisse (Livre\nNFHSCS Switzerland |CH Société a responsabllité | 3yq Liquidateur French fr Liquidateur 2023-0628 |ACTV cinquiéme: Droit des\nlimitée obligations) du 30 mars\n1911 (Etat le ler juillet\n2021) - Art.826\nBundesgesetz betreffend\ndie Erganzung des\nSchweizerischen\n\" Gesellschaft mit P P Zivilgesetzbuches\nNFHSCS Switzerland CH 3EKS Liquidat: G Liquidat: 2023-06-28 ACTV\nwitzerlan beschréankter Haftung iquicator erman quidator (Funfter Teil:\nObligationenrecht) vom\n30. Mérz 1911 (Stand am\n1.Juli 2021) - Art.826\nLegge federale di\ncomplemento del Codice\nPN . civile svizzero (Libro\nNFHSCS Switzerland | CH fi;cl'titt\"; agaranzia 3EKS Liquidatore talian it Liquidatore 2023-06-28 |ACTV quinto: Diritto delle\nobbligazioni) del 30\nmarzo 1911 (Stato 1°\nluglio 2021) - Art.826\nLoi fédérale complétant le\nCode civil suisse (Livre\nRSGCDV Switzerland | CH Société anonyme mviI Liquidateur French fr Liquidateur 2023-06-28 |ACTV cinguiéme: Droit des\nobligations) du 30 mars\n1911 (Etat le ler juillet\n2021) - Art.740\nBundesgesetz betreffend\ndie Erganzung des\nSchweizerischen\nRSGCDV Switzerland CH Aktiengesellschaft MVl Liquidator German Liquidator 2023-06-28 |ACTV (Z;;'r\"?tiie%fi‘_‘d‘es\nObligationenrecht) vom\n30. Mérz 1911 (Stand am\n1.Juli 2021) - Art.740\n53/119\n","contentLength":3013,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.729Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Legge federale di\ncomplemento del Codice\ncivile svizzero (Libro\nRSGCDV Switzerland CH Societa anonima MvIl Liquidatore Italian it Liquidatore 2023-06-28 ACTV quinto: Diritto delle\nobbligazioni) del 30\nmarzo 1911 (Stato 1°\nluglio 2021) - Art.740\nCode civil suisse du 10\nS7E6SG Switzerland CH Fondation 2)z4 Fondateur French fr Fondateur 2023-06-28 ACTV décembre 1907 (Etat le\nler janvier 2021) - Art.81\nSchweizerisches\nZivilgesetzbuch vom 10.\nSTE6SG Switzerland CH Stiftung 2)z4 Stifter German Stifter 2023-06-28 ACTV Dezember 1907 (Stand\nam 1. Januar 2021) -\nArt.81\nCodice civile svizzero del\nS7E6SG Switzerland CH Fondazione 2)z4 Fondatore Italian it Fondatore 2023-06-28 ACTV 10 dicembre 1907 (Stato\n1° gennaio 2021) - Art.81\nLoi fédérale complétant le\nCode civil suisse (Livre\n. o Membre d’un organe de la Membre d’un organe de la cinquiéme: Droit des\nSD3IEC Switzerland CH Société anonyme MVII société (Organe) French fr société (Organe) 2023-06-28 ACTV obligations) du 3q r.nars\n1911 (Etat le ler juillet\n2021) - Art.689\nBundesgesetz betreffend\ndie Erganzung des\nSchweizerischen\nSD3IEC Switzerland CH Aktiengesellschaft MVII Organvertreter German Organvertreter 2023-06-28 ACTV (Z;E:?teesre.ltéki)lt.)ches\nObligationenrecht) vom\n30. Mérz 1911 (Stand am\n1.Juli 2021) - Art.689\nLegge federale di\ncomplemento del Codice\n\" \" civile svizzero (Libro\nSD3IEC Switzerland | CH Societa anonima Mvil Membro di un organo della talian it Membro di un organo della 2023-06-28 |ACTV quinto: Diritto delle\nsocieta societa A\nobbligazioni) del 30\nmarzo 1911 (Stato 1°\nluglio 2021) - Art.689\nLoi fédérale complétant le\nCode civil suisse (Livre\nSGF5C3 Switzerland |CH Société a responsabilité. | 3pyq Fondateur French fr Fondateur 2023-06-28 | ACTV cinquieme: Droit des\nlimitée obligations) du 30 mars\n1911 (Etat le ler juillet\n2021) - Art.777\nBundesgesetz betreffend\ndie Erganzung des\nSchweizerischen\nSGF5C3 Switzerland |CH Gesellschaft mit 3EKS Griinder German Gréinder 2023-06-28 | ACTV Zivilgesetzbuches\nbeschrankter Haftung (Funfter Teil:\nObligationenrecht) vom\n30. Mérz 1911 (Stand am\n1.Juli 2021) - Art.777\nLegge federale di\ncomplemento del Codice\nPN . civile svizzero (Libro\nSGF5C3 Switzerland | CH fi;cl'titt\"; agaranzia 3EKS Promotoro talian it Promotoro 2023-06-28 |ACTV quinto: Diritto delle\nobbligazioni) del 30\nmarzo 1911 (Stato 1°\nluglio 2021) - Art.777\nLoi fédérale complétant le\nCode civil suisse (Livre\nSORBMB Switzerland CH Société anonyme MVl Président French fr Président 2023-06-28 |ACTV cinguiéme: Droit des\nobligations) du 30 mars\n1911 (Etat le ler juillet\n2021) - Art.712\nBundesgesetz betreffend\ndie Erganzung des\nSchweizerischen\nSORBMB Switzerland CH Aktiengesellschaft MVl Prasident German Prasident 2023-06-28 |ACTV (Z;;'r\"?tisre;zki’l‘_‘d‘es\nObligationenrecht) vom\n30. Marz 1911 (Stand am\n1. Juli 2021) - Art.712\nLegge federale di\ncomplemento del Codice\ncivile svizzero (Libro\nSORBMB Switzerland CH Societa anonima MvIl Presidente Italian it Presidente 2023-06-28 ACTV quinto: Diritto delle\nobbligazioni) del 30\nmarzo 1911 (Stato 1°\nluglio 2021) - Art.712\n54/119\n","contentLength":3078,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.729Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Loi fédérale complétant le\nCode civil suisse (Livre\nUXZPKZ Switzerland CH Société anonyme MVIl Fondateur French fr Fondateur 2023-06-28 |ACTV cinquieme: Droit des\nobligations) du 30 mars\n1911 (Etat le ler juillet\n2021) - Art.635\nBundesgesetz betreffend\ndie Erganzung des\nSchweizerischen\nUxzpPkz Switzerland | CH Aktiengesellschaft Ml Griinder German Griinder 2023-0628 | ACTV (Z;;'r\"?tiie%fi‘_‘d‘es\nObligationenrecht) vom\n30. Mérz 1911 (Stand am\n1.Juli 2021) - Art.635\nLegge federale di\ncomplemento del Codice\ncivile svizzero (Libro\nUXZPKZ Switzerland CH Societa anonima MVII Promotoro Italian it Promotoro 2023-06-28 ACTV quinto: Diritto delle\nobbligazioni) del 30\nmarzo 1911 (Stato 1°\nluglio 2021) - Art.635\nLoi fédérale complétant le\nCode civil suisse (Livre\nWE9R0OG Switzerland CH Société a responsabilité f 3eq Ayant droit économique French fr Ayant droit économique 2023-06-28 |ACTV cinquiéme: Droit des\nlimitée obligations) du 30 mars\n1911 (Etat le ler juillet\n2021) - Art.790a\nBundesgesetz betreffend\ndie Erganzung des\nSchweizerischen\n. Gesellschaft mit Wirtschaftlich berechtigte Wirtschaftlich berechtigte Zivilgesetzbuches\nWE9R0G Switzerland CH beschrankter Haftung 3EKS Person German Person 2023-06-28 | ACTV (Funfter Teil:\nObligationenrecht) vom\n30. Mérz 1911 (Stand am\n1. Juli 2021) - Art.790a\nLegge federale di\ncomplemento del Codice\nPN . \" \" civile svizzero (Libro\nWE9R0G Switzerland | CH Societa a garanzia 3EKS Avente economicamente talian it Avente economicamente 2023-0628 |ACTV quinto: Diritto delle\nlimitata diritto diritto o\nobbligazioni) del 30\nmarzo 1911 (Stato 1°\nluglio 2021) - Art.790a\nLoi fédérale complétant le\nCode civil suisse (Livre\nXJGBVH Switzerland CH Société anonyme MVIl Organe de révision French fr Organe de révision 2023-06-28 |ACTV cinquieme: Droit des\nobligations) du 30 mars\n1911 (Etat le ler juillet\n2021) - Art.727\nBundesgesetz betreffend\ndie Erganzung des\nSchweizerischen\nXJGBVH Switzerland [CH Aktiengesellschaft Mvil Revisionsstelle German Revisionsstelle 2023-06-28 [ACTV (Z;;'r\"?tiie%fi‘_‘d‘es\nObligationenrecht) vom\n30. Mérz 1911 (Stand am\n1.Juli 2021) - Art.727\nLegge federale di\ncomplemento del Codice\ncivile svizzero (Libro\nXJGBVH Switzerland CH Societa anonima MvIl Ufficio di revisione Italian it Ufficio di revisione 2023-06-28 ACTV quinto: Diritto delle\nobbligazioni) del 30\nmarzo 1911 (Stato 1°\nluglio 2021) - Art.727\nLoi fédérale, sur les\nplacements collectifs de\nMembre di il Membre di il capitaux, (Loi sur les\nY1QHMK Switzerland |CH Fonds FLNB Jemore U consel French fr Jemore U consel 2023-06-28 |AcTv placements collectifs,\nd’administration d’administration o\nLPCC), du 23 juin 2006\n(Etat le 1ler janvier 2020)\n- Art.51\nBundesgesetz (iber die\nkollektiven Kapitalanlagen\n; Mitglied von der Mitglied von der (Kollektivanlagengesetz,\nY1QHMK Switzerland CH Fond: FLNB G 2023-06-28 ACTV\nQ witzerlan onds Verwaltungsrat erman Verwaltungsrat KAG) vom 23. Juni 2006\n(Stand am 1. Januar\n2020) - Art.51\nLegge federale sugli\ninvestimenti collettivi di\n\" PSR \" T itale (Legge sugli\n. Membro di consiglio di \" P Membro di consiglio di capital b o\nY1QHMK Switzerland CH Fondo FLNB amministrazione Italian it amministrazione 2023-06-28 ACTV investimenti Ct.JllettIVI,\nLICol) del 23 giugno 2006\n(Stato 1° gennaio 2020) -\nArt.51\n55/119\n","contentLength":3287,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.730Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Loi fédérale complétant le\nCode civil suisse (Livre\nZLAQO4 Switzerland CH Société anonyme MVIl Ayant droit économique French fr Ayant droit économique 2023-06-28 |ACTV cinquieme: Droit des\nobligations) du 30 mars\n1911 (Etat le ler juillet\n2021) - Art.697)\nBundesgesetz betreffend\ndie Erganzung des\nSchweizerischen\n2LAQO4 Switzerland CH Aktiengesellschaft MvII Wirtschaftlich berechtigte German Wirtschaftlich berechtigte 2023-06-28 ACTV Zl\\fllgesetz?uches\nPerson Person (Funfter Teil:\nObligationenrecht) vom\n30. Mérz 1911 (Stand am\n1.Juli 2021) - Art.697)\nLegge federale di\ncomplemento del Codice\n\" \" civile svizzero (Libro\nZLAQO4 Switzerland [CH Societa anonima Mvil ’gi‘:,iet’t‘;e economicamente Italian it ’gi‘:,iet’t‘;e economicamente 2023-06-28 |ACTV quinto: Diritto delle\nobbligazioni) del 30\nmarzo 1911 (Stato 1°\nluglio 2021) - Art.697j\nLoi fédérale complétant le\nCode civil suisse (Livre\nZNTXJT Switzerland | CH Société anonyme MVII Actionnaire French fr Actionnaire 2023-06-28 | ACTV cinguidme: Droit des\nobligations) du 30 mars\n1911 (Etat le ler juillet\n2021) - Art.689\nBundesgesetz betreffend\ndie Erganzung des\nSchweizerischen\nZNTXJT Switzerland CH Aktiengesellschaft MVl Aktionar German Aktionar 2023-06-28 |ACTV (Z;E:?tzie;éfil-mhes\nObligationenrecht) vom\n30. Mérz 1911 (Stand am\n1.Juli 2021) - Art.689\nLegge federale di\ncomplemento del Codice\ncivile svizzero (Libro\nZNTXJT Switzerland CH Societa anonima MVII Azionista Italian it Azionista 2023-06-28 |ACTV quinto: Diritto delle\nobbligazioni) del 30\nmarzo 1911 (Stato 1°\nluglio 2021) - Art.689\n. Private Limited by .\nUnited c Act 2006 -\nBG76UD nite GB Guarantee/No Share G12F Secretary English Secretary 2023-06-28 |ACTV ompanies Ac\nKingdom . s.12\nCapital\nBMXCX3 United GB Private Limited Company| HOPO Shadow director English Shadow director 2023-06-28 |ACTV Companies Act 2006 -\nKingdom 5.157\nDIIGVY United GB Public Limited Company |B6ES Shadow director English Shadow director 2023-06-28 |ACTV Companies Act 2006 -\nKingdom 5.157\nDIUHIM United GB Private Limited Company| HOPO Person with significant control | English Person with significant control | PSC psC 2023-06-28 |ACTV Companies Act 2006 -\nKingdom Part 21A\n. Private Limited by .\nEU95JU United GB Guarantee/No Share G12F Member English Member 2023-0628 |ACTV Companies Act 2006\nKingdom ) 5.112\nCapital\nF705XY United GB Public Limited Company |B6ES Person with significant control | English Person with significant control | PSC psC 2023-06-28 |ACTV Companies Act 2006 -\nKingdom Part 21A\nUnited Limited Liability . ) . Limited Liability\nFKYOGU GB 20EY D ted memb English D ted memb 2023-06-28 |ACTV\nKingdom -- Partnership eoignated memmer \"o _ eoignated memmer -- --- Partnership Act 2000 - 5.2\n. Private Limited by .\nUnited c Act 2006 -\nIVYFOL nite GB Guarantee/No Share G12F Person with significant control | English Person with significant control |PSC psC 2023-06-28 |ACTV ompanies Ac\nKingdom Capital Part 21A\nIWFKSE United GB Public Limited Company |B6ES Subscriber English Subscriber 2023-06-28 |ACTV Companies Act 2006 -\nKingdom 5.112\n. Private Limited by .\nJKPKHT Ei’:;‘lm GB Guarantee/No Share G12F Director English Director 2023-0628 |ACTV s‘;’;pa”'es Act 2006\nCapital .\nK7VXGZ United GB Public Limited Company |B6ES Auditor English Auditor 2023-06-28 |ACTV Companies Act 2006 -\nKingdom 5.489\n. Private Limited by .\nKGSO0G United GB Guarantee/No Share G12F Shadow director English Shadow director 2023-06-28 |ACTV Companies Act 2006\nKingdom . s.157\nCapital\nUnited Limited Liability ) Limited Liability\nL02DFG GB 20EY Memb English Memb 2023-06-28 |ACTV\nKingdom -- Partnership ember \"o _ e -- --- Partnership Act 2000 - 5.2\nPKFFIH United GB Private Limited Company| HOPO Auditor English Auditor 2023-06-28 |ACTV Companies Act 2006 -\nKingdom 5.485\nQKAYAH United GB Public Limited Company |B6ES Secretary English Secretary 2023-06-28 |ACTV Companies Act 2006 -\nKingdom 5.12\n56/119\n","contentLength":3913,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.730Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"- Private Limited by -\nUnited c Act 2006 -\nS3MHKP nite GB Guarantee/No Share | G12F Auditor English Auditor 2023-0628 | ACTV ompanies AC\nKingdom . 5.485\nCapital\nuDU176 United B Private Limited Company| HOPO Director English Director 2023-0628 | ACTV Companies Act 2006 -\nKingdom 5.12\nV7RKAI United GB Private Limited Company| HOPO Secretary English Secretary 2023-06-28 |ACTV Companies Act 2006 -\nKingdom 5.12\nVXSNEB United GB Public Limited Company |B6ES Director English Director 2023-06-28 |ACTV Companies Act 2006 -\nKingdom 5.12\nWKICVF United GB Limited Partnership D30 General partner English General partner 6P GP 20230628 |ACTV Limited Partnerships Act\nKingdom 1907 -s.4\nYABZY8 United GB Private Limited Company| HOPO Subscriber English Subscriber 2023-06-28 |ACTV Companies Act 2006 -\nKingdom 5.112\nUnited - . . ) - Limited Partnerships Act\ne -- Lmited Partnership P20 Enatish _ 20230628 --- 1907 - 5.4\nCFR: Title 12 Volume 1:\nUnited States Chapter I: Part 7:\n0SDYW9 of America us National Bank 62V) Shareholder English Shareholder 2023-06-28 ACTV SUBPART B - National\nBank Corporate Practices\n-5.7.2003\nCode of Federal\nRegulations (CFR): Title\n; . 12 Chapter Il Subchapter\nSKH7EZ gf”';reriitcztes us E\"o‘;t:fljzi\"rggcsoam”dany Z7ER Officer English Officer 2023-0628 |ACTV A Part 238 - SAVINGS\nP AND LOAN HOLDING\nCOMPANIES (REGULATION\nL) -52382\nUS Code Title 12 Chapter |\n' . Part 161- DEFINITIONS\nUnited Stat Federal S\n6ILXHY of e |us e oings 3800 Officer English Officer 2023-0628 | ACTV FOR REGULATIONS\nAFFECTING ALL SAVINGS\nASSOCIATIONS - 5.161.35\nCFR: Title 12 Chapter I\nSubchapter A Part 211\n6TUUGC United States | ;g Edge Act Corporation | 3MM4 Director English Director 2023-06-28 |ACTV Subpart A - International\nof America Operations of U.S.\nBanking Organizations -\n52115\nUS Code Title 12 Chapter |\nPart 161- DEFINITIONS\nUnited States Federal Savings \" \" \" FOR REGULATIONS\n7KHGX6 of America us Association 3800 Controlling person English Controlling person 2023-06-28 ACTV AFFECTING ALL SAVINGS\nASSOCIATIONS - 5.161.14\nUS Code Title 12 Chapter |\n' . Part 161- DEFINITIONS\n82HHKL gf”';reriitcztes us ;ig:;\"’;ns:: ings 3800 President English President 2023-0628 |ACTV FOR REGULATIONS\nAFFECTING ALL SAVINGS\nASSOCIATIONS - 5.161.35\nCFR: Title 12 Volume 1:\n' Chapter I: Part 7:\nAPGQHA gf”';reriitcztes us National Bank 62V) Director English Director 2023-06-28 |ACTV SUBPART B - National\nBank Corporate Practices\n-5.7.2005\nCFR: Title 12 Volume 1:\n' Chapter I: Part 7:\nDO3ULL United States |, National Bank 62v) President English President 2023-06-28 |ACTV SUBPART B - National\nof America .\nBank Corporate Practices\n-5.7.2012\nUS Code Title 12 Chapter |\n' . Part 161- DEFINITIONS\nUnited Stat Federal S\nEDN1SD of e |us e oings 3800 Vice-president English Vice-president vp vp 2023-0628 | ACTV FOR REGULATIONS\nAFFECTING ALL SAVINGS\nASSOCIATIONS - 5.161.35\nCode of Federal\nRegulations (CFR): Title\n; . 12 Chapter Il Subchapter\nEHY3DF gf”';reriitcztes Us E\"o‘;t:fljzi\"rggcsoam”dany Z7ER Principal shareholder English Principal shareholder 2023-06-28 |ACTV A Part 238 - SAVINGS\nP AND LOAN HOLDING\nCOMPANIES (REGULATION\nL) -52382\nUS Code Title 12 Chapter |\n' . Part 161- DEFINITIONS\nESHOHN gf”:reriitcztes Us :‘:‘::E?;tis::'”gs 3800 Chairman English Chairman 2023-06-28 |ACTV FOR REGULATIONS\nAFFECTING ALL SAVINGS\nASSOCIATIONS - 5.161.35\nUS Code Title 12 Chapter |\n' . Part 161- DEFINITIONS\nEZZJED gf”:reriitcztes Us :i(si:?;ns:: ings 3800 Treasurer English en Treasurer 2023-06-28 |ACTV FOR REGULATIONS\nAFFECTING ALL SAVINGS\nASSOCIATIONS - 5.161.35\n577119\n","contentLength":3560,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.730Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"US Code Title 12 Chapter |\n\" \" Part 161- DEFINITIONS\nUnited Stat Federal S\nGZOMMG |y 2O us e oings 3800 Comptroller English Comptroller 20230628 |ACTV FOR REGULATIONS\nAFFECTING ALL SAVINGS\nASSOCIATIONS -5.161.35\nUS Code Title 12 Chapter |\n\" \" Part 161- DEFINITIONS\nUnited Stat Federal S\nHBPIYE of e |us e oings 3800 Director English Director 2023-06-28 |AcTv FOR REGULATIONS\nAFFECTING ALL SAVINGS\nASSOCIATIONS -5.161.18\nCFR: Title 12 Volume 1:\nUnited States . . \" . Chapter |: Part 7:.\nJ8HMKF . us National Bank 62V) Chairman English Chairman 2023-06-28 ACTV SUBPART B - National\nof America :\nBank Corporate Practices\n-5.7.2012\nCode of Federal\nRegulations (CFR): Title\n; . 12 Chapter Il Subchapter\nUnited Stat Mutual S d\nK5RRKA of”'Arenericz e us Lol;:iiolz;/r:;ggoamn any |27ER Controlling shareholder English Controlling shareholder 2023-06-28 |ACTV A Part 238 - SAVINGS\nP AND LOAN HOLDING\nCOMPANIES (REGULATION\nLL) -5.238.2\nCode of Federal\nRegulations (CFR): Title\n; . 12 Chapter Il Subchapter\nKX1EB7 gf”:renizt;tes Us Elol;t:fljz;/r:;ggoi:dany Z7ER Director English Director 2023-06-28 |ACTV A Part 238 - SAVINGS\nP AND LOAN HOLDING\nCOMPANIES (REGULATION\nLL) -5.238.2\nCFR: Title 12 Volume 1:\nUnited States Chapter I: Part 7:\nM4NPTM of America us National Bank 62V) Honorary/advisory director English Honorary/advisory director 2023-06-28 |ACTV SUBPART B - National\nBank Corporate Practices\n-5.7.2004\nCode of Federal\nRegulations (CFR): Title\n; . 12 Chapter Il Subchapter\nUnited Stat Mutual S d\nN7ITCC of”'Arenericz e us Lol;:iiolz;/r:;ggoamn any |27ER Management official English Management official 2023-06-28 |ACTV A Part 238 - SAVINGS\nP AND LOAN HOLDING\nCOMPANIES (REGULATION\nLL) -5.238.2\nCFR: Title 12 Chapter Il\nSubchapter A Part 211\n0Q4JPM United States ;g Edge Act Corporation | 3MM4 Shareholder English Shareholder 2023-0628 |ACTV Subpart A - International\nof America Operations of U.S.\nBanking Organizations -\n5.211.5\nCFR: Title 12 Volume 1:\nUnited States Chapter I: Part 7:\n0ZMM5Y of America us National Bank 62V) Chief Executive Officer English Chief Executive Officer CEO CEO 2023-06-28 ACTV SUBPART B - National\nBank Corporate Practices\n-5.7.2012\nCFR: Title 12 Volume 1:\n' Chapter I: Part 7:\nQX9BU7 gf”:re‘irsit;t“ us National Bank 62V) Officer English Officer 2023-06-28 | ACTV SUBPART B - National\nBank Corporate Practices\n-5.7.2015\nUS Code Title 12 Chapter |\n\" \" Part 161- DEFINITIONS\nSWIXMS gf”:re‘irsit;t“ us ;igii:ns:: ings 3800 Secretary English Secretary 2023-0628 |ACTV FOR REGULATIONS\nAFFECTING ALL SAVINGS\nASSOCIATIONS -5.161.35\nCFR: Title 12 Chapter Il\nSubchapter A Part 211\nW4KOTL United States ;g Edge Act Corporation | 3MM4 Officer English Officer 2023-0628 |ACTV Subpart A - International\nof America Operations of U.S.\nBanking Organizations -\n5.211.5\nUnited States The Code of Alabama\n1PWRCA of America us Alabama US-AL For-Profit Corporation HFGV organizer English organizer 2023-06-28 ACTV 1975: Title 10A: Section\n10A-1-1.03\nUnited States The Code of Alabama\n5R9B1F of America us Alabama US-AL For-Profit Corporation HFGV incorporator English incorporator 2023-06-28 ACTV 1975: Title 10A: Section\n10A-2A-2.01\nUnited States The Code of Alabama\n5Z0I3C of America us Alabama US-AL For-Profit Corporation HFGV managerial official English managerial official 2023-06-28 ACTV 1975: Title 10A: Section\n10A-1-1.03\n58/119\n","contentLength":3347,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.730Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"The Code of Alabama\n\" P PR 1975: Title 10A: Ch.5A -\nUnited Stat Limited Liabilit:\n7EAPAU nited states ;5 Alabama US-AL mited Liability CWRI member English member 2023-06-28 |ACTV known as the Alabama\nof America Company . P\nLimited Liability Company\nLaw 5.1-02\nUnited States The Code of Alabama\nAFLBWS of America us Alabama US-AL For-Profit Corporation HFGV president English president Pres. 2023-06-28 ACTV 1975: Title 10A: Section\n10A-1-1.03\nUnited States The Code of Alabama\nAGMINC of America us Alabama US-AL For-Profit Corporation HFGV voting trustee English voting trustee 2023-06-28 ACTV 1975: Title 10A: Section\n10A-2A-7.30\nThe Code of Alabama\n\" P PR 1975: Title 10A: Ch.5A -\nUnited Stat Limited Liabilit:\nBOPVQA nited States ;g Alabama US-AL mitec Liability CWRI qualified person English qualified person 2023-0628 | ACTV known as the Alabama\nof America Company . P\nLimited Liability Company\nLaw s.1-02\nThe Code of Alabama\n\" P PR 1975: Title 10A: Ch.5A -\nUnited Stat Limited Liabilit:\nDH47UU nited states ;5 Alabama US-AL mited Liability CWRI registered agent English registered agent 2023-06-28 |ACTV known as the Alabama\nof America Company . P\nLimited Liability Company\nLaw 5.2-01\nUnited States The Code of Alabama\nERNR5Z : us Alabama US-AL For-Profit Corporation HFGV registered agent English registered agent 2023-06-28 ACTV 1975: Title 10A: Section\nof America\n10A-1-5.31\nUnited States The Code of Alabama\nGWBD80O . us Alabama US-AL For-Profit Corporation HFGV qualified director English qualified director 2023-06-28 ACTV 1975: Title 10A: Section\nof America\n10A-2A-1.43\nUnited States The Code of Alabama\nHUMNHM . us Alabama US-AL For-Profit Corporation HFGV receiver English receiver 2023-06-28 ACTV 1975: Title 10A: Section\nof America\n10A-2A-14.12\nUnited States The Code of Alabama\nIFNTRW . us Alabama US-AL For-Profit Corporation HFGV officer English officer 2023-06-28 ACTV 1975: Title 10A: Section\nof America\n10A-1-1.03\nUnited States The Code of Alabama\nIRHZ5H . us Alabama US-AL For-Profit Corporation HFGV custodian English custodian 2023-06-28 ACTV 1975: Title 10A: Section\nof America\n10A-2A-14.12\nUnited States The Code of Alabama\n0U6BVO . us Alabama US-AL For-Profit Corporation HFGV owner English owner 2023-06-28 ACTV 1975: Title 10A: Section\nof America\n10A-1-1.03\nUnited States The Code of Alabama\nQTVZP6 . us Alabama US-AL For-Profit Corporation HFGV treasurer English treasurer Treas. 2023-06-28 ACTV 1975: Title 10A: Section\nof America\n10A-1-1.03\nThe Code of Alabama\n\" P PR 1975: Title 10A: Ch.5A -\nRMTAQ9 United States |, Alabama US-AL umited Liability CWRI manager English manager Mar. 2023-0628 |ACTV known as the Alabama\nof America Company L P\nLimited Liability Company\nLaw 5.4-07\nUnited States The Code of Alabama\nTVQHOU . us Alabama US-AL For-Profit Corporation HFGV director English director Dir. 2023-06-28 ACTV 1975: Title 10A: Section\nof America\n10A-1-1.03\nUnited States The Code of Alabama\nTZM2HL . us Alabama US-AL For-Profit Corporation HFGV secretary English secretary Sec. 2023-06-28 ACTV 1975: Title 10A: Section\nof America\n10A-1-1.03\nUnited States The Code of Alabama\nUPX080 . us Alabama US-AL For-Profit Corporation HFGV vice president English vice president V.P., VP 2023-06-28 ACTV 1975: Title 10A: Section\nof America\n10A-1-1.03\nUnited States The Code of Alabama\nVSCJLY of America us Alabama US-AL For-Profit Corporation HFGV stockholder English stockholder 2023-06-28 ACTV 1975: Title 10A: Section\n10A-2A-1.42\nThe Code of Alabama\nXLNZRY United States | ;g Alabama US-AL For-Profit Corporation | HFGV. subscriber English subscriber 2023-06-28 |ACTV 1975: Title 10A: Section\nof America 10A-1-1.03\nUnited States The Code of Alabama\nYVBVUF . us Alabama US-AL For-Profit Corporation HFGV member English member 2023-06-28 ACTV 1975: Title 10A: Section\nof America\n10A-1-1.03\nThe Code of Alabama\n\" P PR 1975: Title 10A: Ch.5A -\nZ40AZF United States |, Alabama US-AL umited Liability CWRI organizer English organizer 2023-0628 |ACTV known as the Alabama\nof America Company L P\nLimited Liability Company\nLaw 5.2-01\nAlaska Statutes 2020:\nTITLE 10. CORPORATIONS\n\" P PR AND ASSOCIATIONS.\nUnited Stat Limited Liabilit:\n1G5GRX nited states ;5 Alaska US-AK mited Liability D4YS managing member English managing member 2023-06-28 |ACTV Chapter 50. Alaska\nof America Company N P P\nRevised Limited Liability\nCompany Act. Sec.\n10.50.135\nUnited States Alaska Statutes: Title 10:\n37ZUwWP . us Alaska US-AK Business Corporation BRO8 director English director Dir. 2023-06-28 ACTV Ch.6 Alaska Corporations\nof America\nCode - §10.06.020\n59/119\n","contentLength":4567,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.730Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"United States Alaska Statutes: Title 10:\n5FCCRG of America us Alaska US-AK Business Corporation BRO8 president English president 2023-06-28 ACTV Ch.6 Alaska Corporations\nCode - §10.06.165\nUnited States Alaska Statutes: Title 10:\nBAU4BA of America us Alaska US-AK Business Corporation BRO8 secretary English secretary 2023-06-28 ACTV Ch.6 Alaska Corporations\nCode - §10.06.483\nUnited States Alaska Statutes: Title 10:\nBQGIKY of America us Alaska US-AK Business Corporation BRO8 incorporator English incorporator 2023-06-28 ACTV Ch.6 Alaska Corporations\nCode - §10.06.205\nUnited States Alaska Statutes: Title 10:\nECFEZU of America us Alaska US-AK Business Corporation BRO8 shareholder English shareholder 2023-06-28 ACTV Ch.6 Alaska Corporations\nCode - §10.06.020\nUnited States Alaska Statutes: Title 10:\nGAONNI of America us Alaska US-AK Business Corporation BRO8 voting trustee English voting trustee 2023-06-28 ACTV Ch.6 Alaska Corporations\nCode - § 10.06.425\nUnited States Alaska Statutes: Title 10:\nHEEAIZ of America us Alaska US-AK Business Corporation BRO8 vice president English vice president 2023-06-28 ACTV Ch.6 Alaska Corporations\nCode - §10.06.165\nUnited States Alaska Statutes: Title 10:\nHTHOXU of America us Alaska US-AK Business Corporation BRO8 subscriber English subscriber 2023-06-28 ACTV Ch.6 Alaska Corporations\nCode - §10.06.438\nUnited States Alaska Statutes: Title 10:\nI6HA5U . us Alaska US-AK Business Corporation BRO8 officer English officer 2023-06-28 ACTV Ch.6 Alaska Corporations\nof America\nCode - §10.06.020\nUnited States Alaska Statutes: Title 10:\nJTGQLP of America us Alaska US-AK Business Corporation BRO8 five percent shareholder English five percent shareholder 2023-06-28 ACTV Ch.6 Alaska Corporations\nCode - § 10.06.990\nAlaska Statutes 2020:\nTITLE 10. CORPORATIONS\n\" P PR AND ASSOCIATIONS.\nUnited Stat Limited Liabilit:\nOBLYG2 nited states ;5 Alaska US-AK mited Liability D4YS registered agent English registered agent 2023-06-28 |ACTV Chapter 50. Alaska\nof America Company N P P\nRevised Limited Liability\nCompany Act. Sec.\n10.50.055\nUnited States Alaska Statutes: Title 10:\nRHXFDU . us Alaska US-AK Business Corporation BRO8 receiver English receiver 2023-06-28 ACTV Ch.6 Alaska Corporations\nof America\nCode - §10.06.643\nAlaska Statutes 2020:\nTITLE 10. CORPORATIONS\n\" P PR AND ASSOCIATIONS.\nUnited Stat Limited Liabilit:\nRWWXZK nited states ;5 Alaska US-AK mited Liability D4YS manager English manager Mar. 2023-06-28 |ACTV Chapter 50. Alaska\nof America Company N P P\nRevised Limited Liability\nCompany Act. Sec.\n10.50.075\nUnited States Alaska Statutes: Title 10:\nS1C7XY . us Alaska US-AK Business Corporation BRO8 treasurer English treasurer 2023-06-28 ACTV Ch.6 Alaska Corporations\nof America\nCode - §10.06.483\nAlaska Statutes 2020:\nTITLE 10. CORPORATIONS\n\" P PR AND ASSOCIATIONS.\nUnited Stat Limited Liabilit:\nUGABU9 nited states ;5 Alaska US-AK mited Liability D4YS organizer English organizer 2023-06-28 |ACTV Chapter 50. Alaska\nof America Company N P P\nRevised Limited Liability\nCompany Act. Sec.\n10.50.070\nUnited States Alaska Statutes: Title 10:\nWB2AI8 . us Alaska US-AK Business Corporation BRO8 registered agent English registered agent 2023-06-28 ACTV Ch.6 Alaska Corporations\nof America\nCode - §10.06.150\nAlaska Statutes 2020:\nTITLE 10. CORPORATIONS\n\" P PR AND ASSOCIATIONS.\nXJ1Z7L United States |, Alaska US-AK Limited Liability D4YS member English member 2023-06-28 |ACTV Chapter 50. Alaska\nof America Company N P R\nRevised Limited Liability\nCompany Act. Sec.\n10.50.095\nUnited States . _ Corporation (Business or : \" \" : \" 06 Arizona Revised Statutes:\nA5FOOR of America us Arizona US-AZ for-profit) FGVH vice president English vice president 2023-06-28 ACTV Title 10: § 10-140\nUnited States . Corporation (Business or \" Arizona Revised Statutes:\nA5HRHT us Al US-AZ FGVH t English t 2023-06-28 ACTV\nof America rizona for-profit) reasurer nglls reasurer Title 10: § 10-140\nUnited States . Corporation (Business or ) Arizona Revised Statutes:\nAD9ZWW of America us Arizona US-AZ for-profit) FGVH officer English officer 2023-06-28 ACTV Title 10: § 10-840\nUnited States . : Corporation (Business or ' ' ' o6 Arizona Revised Statutes:\nCVKQ5D of America us Arizona US-AZ for-profit) FGVH director English director 2023-06-28 ACTV Title 10: § 10-140\nArizona Revised Statutes:\nUnited States . Limited Liability \" Title 29: Ch 7 - Arizona\nD8DHQR of America us Arizona US-AZ Company 085w manager English manager Mar. 2023-06-28 ACTV Limited Liability Company\nAct 29-3102\nUnited States . ] Corporation (Business or I . Arizona Revised Statutes:\nDRJ7AD of America us Arizona US-AZ for-profit) FGVH shareholder English shareholder 2023-06-28 ACTV Title 10: § 10-140\nUnited States . Corporation (Business or \" \" \" Arizona Revised Statutes:\nE3ZIL) us Al US-AZ FGVH dent English dent 2023-06-28 ACTV\nJ of America rizona for-profit) president nglls president Title 10: § 10-140\n60/119\n","contentLength":4915,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.730Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"23 MAART 2019. — Wet\ntot invoering van het\nWetboek van\n\" Houder van Houder van venno.o.schappen en\nGGYNJZ Belgium Naamloze vennootschap | R85P inschrijvingsrechten Dutch inschrijvingsrechten 2023-06-28 ACTV verenlgmge_n en\nhoudende diverse\nbepalingen - BOEK 7:\nTITEL 4: HOOFDSTUK 2:\nArt.7:135\n23 MARZ 2019. —\nGGYNJZ Belgium Aktiengesellschaft R85P Bezugsrechtsinhaber German Bezugsrechtsinhaber 2023-06-28 ACTV Gesetzbuch der\nGesellschaften und\nVereinigungen\n23 MARS 2019. — Loi\nintroduisant le Code des\nA iati but sociétés et des\nHGNKXH Belgium Iuscit:t::? fon sans bul W3WH Administrateur French fr Administrateur 2023-06-28 ACTV associations et portant\ndes dispositions diverses -\nLivre 9: Titre 2: CHAPITRE\n1: Art. 9:5\n23 MAART 2019. — Wet\ntot invoering van het\nWetboek van\nVi P d vennootschappen en\nHGNKXH Belgium ereniging zonder W3WH Bestuurder Dutch Bestuurder 2023-06-28 |ACTV verenigingen en\nwinstoogmerk \"\nhoudende diverse\nbepalingen - BOEK 9:\nTITEL 2: HOOFDSTUK 1:\nArt.9:5\n23 MARZ 2019. —\n) Vereinigung ohne Gesetzbuch der\nHGNKXH Belgium Gewinnerzielungsabsicht W3WH Verwalter German Verwalter 2023-06-28 ACTV Gesellschaften und\nVereinigungen\n23 MAART 2019. — Wet\ntot invoering van het\nWetboek van\nvennootschappen en\nH)ZOXI Belgium Besloten Vennootschap |3W7E Aandeelhouder Dutch Aandeelhouder 2023-06-28 ACTV verenigingen en\nhoudende diverse\nbepalingen - BOEK 2:\nTITEL 7: HOOFDSTUK 1:\nArt.2:61\n23 MARS 2019. — Loi\nintroduisant le Code des\nSociété a bilite sociétés et des\nHjZOXI Belgium e | coponsabile |3y 7e Actionnaire French fr Actionnaire 20230628 |ACTV associations et portant\ndes dispositions diverses -\nLivre 2: Titre 7: CHAPITRE\n1: Art. 2:61.1\n23 MARZ 2019. —\n\" Gesellschaft mit P P, Gesetzbuch der\nHJZOXI Belgium beschrankter Haftung 3W7E Aktionar German Aktionar 2023-06-28 ACTV Gesellschaften und\nVereinigungen\n23 MARS 2019. — Loi\nintroduisant le Code des\nsociétés et des\nIQFRXX Belgium Société anonyme R85P Actionnaire French fr Actionnaire 2023-06-28 ACTV associations et portant\ndes dispositions diverses -\nLivre 2: Titre 7: CHAPITRE\n1: Art. 2:61.1\n23 MAART 2019. — Wet\ntot invoering van het\nWetboek van\nvennootschappen en\nIQFRXX Belgium Naamloze vennootschap [ R85P Aandeelhouder Dutch Aandeelhouder 2023-06-28 ACTV verenigingen en\nhoudende diverse\nbepalingen - BOEK 2:\nTITEL 7: HOOFDSTUK 1:\nArt.2:61\n23 MARZ 2019. —\nIQFRXX Belgium Aktiengesellschaft R85P Aktionar German Aktionar 2023-06-28 [ACTV Gesetzbuch der\nGesellschaften und\nVereinigungen\n23 MARS 2019. — Loi\nintroduisant le Code des\n- iétés et des\n\" Association sans but Membre de I'organe Membre de I'organe societes\nKR3NFE Belgium lucratif W3WH d'administration French fr d'administration 2023-06-28 ACTV assoc.latlor.u;. et po.rtant\ndes dispositions diverses -\nLivre 2: Titre 6: CHAPITRE\n2: Art. 2:56\n7/119\n","contentLength":2798,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.730Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Arizona Revised Statutes:\nUnited States . Limited Liability ot \" A Title 29: Ch 7 - Arizona\nK8SFNB us Al US-AZ 085w I dati it English liquidat it 2023-06-28 ACTV\nof America rizona Company lquidating agent nglls lquidating agent Limited Liability Company\nAct 29-3702\nUnited States . Corporation (Business or \" Arizona Revised Statutes:\nLFEJQO us Al US-AZ FGVH tatut it English tatut t 2023-06-28 ACTV\n1Q of America rizona for-profit) statutory agen nglls statutory agen Title 10: § 10-501\nUnited States . ] Corporation (Business or . I . o6 Arizona Revised Statutes:\nMSN9V1 of America us Arizona US-AZ for-profit) FGVH subscriber English subscriber 2023-06-28 ACTV Title 10: § 10-140\nUnited States . Corporation (Business or f \" f Arizona Revised Statutes:\nowQowl us Al US-AZ FGVH t English t 2023-06-28 ACTV\nQ! of America rizona for-profit) incorporator nglis incorporator Title 10: § 10201\nArizona Revised Statutes:\n0YQ559 United States | ;g Arizona Us-AZ Uimited Liability 085W member English member 2023-06-28 |ACTV Title 29: Ch 7 - Arizona\nof America Company Limited Liability Company\nAct 29-3102\nUnited States . ] Corporation (Business or . I . . Arizona Revised Statutes:\nPMNKNM of America us Arizona US-AZ for-profit) FGVH voting trustee English voting trustee 2023-06-28 ACTV Title 10: § 10-730\nUnited States . ] Corporation (Business or . I . . o6 Arizona Revised Statutes:\nRLHENI of America us Arizona US-AZ for-profit) FGVH assistant officer English assistant officer 2023-06-28 ACTV Title 10: § 10-840\nUnited States . ] Corporation (Business or I . Arizona Revised Statutes:\nuucorv of America us Arizona US-AZ for-profit) FGVH secretary English secretary 2023-06-28 ACTV Title 10: § 10-140\nArizona Revised Statutes:\nUnited States . Limited Liability \" Title 29: Ch 7 - Arizona\nXUBKQ5 of America us Arizona US-AZ Company 085w statutory agent English statutory agent 2023-06-28 ACTV Limited Liability Company\nAct 29-3102\nArizona Revised Statutes:\nY130zW United States | ;g Arizona Us-AZ Uimited Liability 085W organizer English organizer 2023-06-28 |ACTV Title 29: Ch 7 - Arizona\nof America Company Limited Liability Company\nAct 29-3102\nUnited States . Corporation (Business or \" \" \" Arizona Revised Statutes:\nZIVL5! us Al US-AZ FGVH English 2023-06-28 ACTV\nQ of America rizona for-profit) receiver nglls receiver Title 10: § 10-1432\nArkansas Code: Title 4:\nAGEHFX United States |;g Arkansas US-AR For-Profit Corporation EjX1 memb.er of the executive English memb.er of the executive 20230628 |ACTV Subtitle 3: Ch.26 -\nof America committee committee Arkansas Business\nCorporation Act 4-26-808\nArkansas Code: Title 4:\n64PBDS United States | ;g Arkansas US-AR For-Profit Corporation | EJX1 secretary English secretary Sec. 2023-06-28 |ACTV Subtitle 3: Ch.26 -\nof America Arkansas Business\nCorporation Act 4-26-812\nArkansas Code: Title 4:\nC7EICS United States | ;g Arkansas US-AR Uimited Liability M4FO member English member 2023-06-28 |ACTV Subtitle 3: Ch.37 -\nof America Company Uniform Limited Liability\nCompany Act 4-37-102\nArkansas Code: Title 4:\nUnited States Limited Liability \" \" \" Subtitle 3: Ch.37 -\nEOFTN9 of America us Arkansas US-AR Company M4FO registered agent English registered agent 2023-06-28 ACTV Uniform Limited Liability\nCompany Act 4-37-203\nArkansas Code: Title 4:\nG4J0XB United S.tates us Arkansas US-AR Limited Liability M4FO protected-series manager English protected-series manager 2023-06-28 ACTV Suk.)tltle 3 Ch.37 o\nof America Company Uniform Limited Liability\nCompany Act 4-37-106\nArkansas Code: Title 4:\nKROBFL United States | ;g Arkansas US-AR For-Profit Corporation | EjX1 subscriber English subscriber 2023-0628 | ACTV Subtitle 3: Ch.26 -\nof America Arkansas Business\nCorporation Act 4-26-102\nArkansas Code: Title 4:\nMBJOFN United States | ;g Arkansas US-AR For-Profit Corporation | EjX1 vice-president English vice-president VP 2023-0628 | ACTV Subtitle 3: Ch.26 -\nof America Arkansas Business\nCorporation Act 4-26-812\nArkansas Code: Title 4:\nMIOY3E United States | ;g Arkansas US-AR For-Profit Corporation | EJX1 director English director Dir. 2023-06-28 |ACTV subtitle 3: Ch.26 -\nof America Arkansas Business\nCorporation Act 4-26-202\nArkansas Code: Title 4:\n0OC3FQ4 United S_tates us Arkansas US-AR For-Profit Corporation EJX1 treasurer English treasurer Treas. 2023-06-28 ACTV Subtitle 3: Ch_'ZG -\nof America Arkansas Business\nCorporation Act 4-26-812\nArkansas Code: Title 4:\nPTTLSO United States | ;g Arkansas US-AR For-Profit Corporation | EJX1 incorporator English incorporator 2023-06-28 |ACTV subtitle 3: Ch.26 -\nof America Arkansas Business\nCorporation Act 4-26-201\nArkansas Code: Title 4:\nUnited States Limited Liability ) I ) Subtitle 3: Ch.37 -\nSBKD)B of America us Arkansas US-AR Company M4FO associated member English associated member 2023-06-28 |ACTV Uniform Limited Liability\nCompany Act 4-37-302\nArkansas Code: Title 4:\nUnited States Limited Liability \" Subtitle 3: Ch.37 -\nV3DCQO us Ark: US-AR M4FO English Mgr. 2023-06-28 ACTV\nQ of America rkansas Company manager nglls manager or Uniform Limited Liability\nCompany Act 4-37-102\n61/119\n","contentLength":5100,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.730Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Arkansas Code: Title 4:\nX3ATXH United States ;g Arkansas US-AR For-Profit Corporation | EJX1 president English president Pres. 2023-0628 |ACTV subtitle 3: Ch.26 -\nof America Arkansas Business\nCorporation Act 4-26-812\nArkansas Code: Title 4:\nY6FLGL United States ;g Arkansas US-AR For-Profit Corporation | EJX1 shareholder English shareholder 2023-06-28 | ACTV subitle 3: Ch.26 -\nof America Arkansas Business\nCorporation Act 4-26-102\nCORPORATIONS CODE -\nCORP TITLE 1.\nCORPORATIONS [100 -\nUnited States P y For-Profit Corporation i e 14631] ( Title 1 enacted\n1M)ZE) of America us California US-CA General Stock H1UM General manager English General manager GM GM 2023-06-28 ACTV by Stats. 1947, Ch. 1038.\n) DIVISION 1. GENERAL\nCORPORATION LAW [100\n-2319] -5.312\nCORPORATIONS CODE -\nCORP TITLE 2.6.\n' R CALIFORNIA REVISED\n1NMZOS gf”:renizt;tes Us California US-CA ggqn':e:n';,'ab\"'ty El4) Initial member English Initial member 2023-06-28 |ACTV UNIFORM LIMITED\nP LIABILITY COMPANY ACT\n[17701.01 - 17713.13] -\n5.17701.11\nCORPORATIONS CODE -\nCORP TITLE 2.6.\n' R CALIFORNIA REVISED\n7KUUVL gf”:re‘irsit;t“ us california US-CA gg\"n'qte:n';,'ab\"'ty El4) Chief executive officer English Chief executive officer CEO CEO 2023-0628 |ACTV UNIFORM LIMITED\nP LIABILITY COMPANY ACT\n[17701.01 - 17713.13] -\n5.17702.09\nCORPORATIONS CODE -\nCORP TITLE 1.\nCORPORATIONS [100 -\nUnited States P y For-Profit Corporation i e 14631] ( Title 1 enacted\n9KN8DO of America us California US-CA General Stock H1UM Corporate agent English Corporate agent 2023-06-28 ACTV by Stats. 1947, Ch. 1038.\n) DIVISION 1. GENERAL\nCORPORATION LAW [100\n-2319] -5.1701\nCORPORATIONS CODE -\nCORP TITLE 1.\nCORPORATIONS [100 -\nUnited States P y For-Profit Corporation e i . N e 14631] ( Title 1 enacted\nCDK6QZ of America us California US-CA General Stock H1UM Chief financial officer English Chief financial officer CFO CFO 2023-06-28 ACTV by Stats. 1947, Ch. 1038.\n) DIVISION 1. GENERAL\nCORPORATION LAW [100\n-2319] - 5.313\nCORPORATIONS CODE -\nCORP TITLE 2.6.\n' R CALIFORNIA REVISED\nFHVHYV gf”:re‘irsit;t“ us california US-CA gg\"n'qte:n';,'ab\"'ty El4) Transfer agent English Transfer agent 2023-0628 |ACTV UNIFORM LIMITED\nP LIABILITY COMPANY ACT\n[17701.01 - 17713.13] -\n5.17704.07\nCORPORATIONS CODE -\nCORP TITLE 1.\nCORPORATIONS [100 -\nUnited States P y For-Profit Corporation . i . e 14631] ( Title 1 enacted\nGCDGOU of America us California US-CA General Stock H1UM President English President 2023-06-28 ACTV by Stats. 1947, Ch. 1038.\n) DIVISION 1. GENERAL\nCORPORATION LAW [100\n- 2319] - 5.305\nCORPORATIONS CODE -\nCORP TITLE 1.\nCORPORATIONS [100 -\nUnited States P y For-Profit Corporation ) i ) e 14631] ( Title 1 enacted\nGQQKIS of America us California US-CA General Stock H1UM Assistant secretary English Assistant secretary 2023-06-28 ACTV by Stats. 1947, Ch. 1038.\n) DIVISION 1. GENERAL\nCORPORATION LAW [100\n-2319] - 5.313\nCORPORATIONS CODE -\nCORP TITLE 2.6.\n' R CALIFORNIA REVISED\nUnited Stat Limited Liabilit\nGVYONS of e |us California US-CA o eany'a s El4) Chairperson English Chairperson 20230628 |ACTV UNIFORM LIMITED\nP LIABILITY COMPANY ACT\n[17701.01 - 17713.13] -\n5.17704.07\nCORPORATIONS CODE -\nCORP TITLE 1.\nCORPORATIONS [100 -\nUnited States P y For-Profit Corporation i e 14631] ( Title 1 enacted\nGVYBYE of America us California US-CA General Stock H1UM Officer English Officer 2023-06-28 ACTV by Stats. 1947, Ch. 1038.\n) DIVISION 1. GENERAL\nCORPORATION LAW [100\n-2319] -5.312\n62/119\n","contentLength":3444,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.731Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"CORPORATIONS CODE -\nCORP TITLE 2.6.\n_ o CALIFORNIA REVISED\nHJVPKM United States ;g California US-CA Limited Liability El4) Chief financial officer English Chief financial officer CFO CFO 2023-06-28 |ACTV UNIFORM LIMITED\nof America Company LIABILITY COMPANY ACT\n[17701.01 - 17713.13] -\n5.17704.07\nCORPORATIONS CODE -\nCORP TITLE 1.\nCORPORATIONS [100 -\nUnited States I For-Profit Corporation . . ' . ' 14631] ( Title 1 enacted\nKVOPE| us Calift US-CA H1UM Vi dent English Vi dent VP VP 2023-0628 | ACTV\n) of America alifornia General Stock ice presiden nglls ice presiden by Stats. 1947, Ch. 1038.\n) DIVISION 1. GENERAL\nCORPORATION LAW [100\n-2319] - 5.307\nCORPORATIONS CODE -\nCORP TITLE 2.6.\n' s CALIFORNIA REVISED\nUnited Stat Limited Liabilit\nMA2N60 of”'Arenericz e us California US-CA cg:\"q eany'a ity El4) Assistant treasurer English Assistant treasurer 2023-06-28 |ACTV UNIFORM LIMITED\nP LIABILITY COMPANY ACT\n[17701.01 - 17713.13] -\n5.17704.07\nCORPORATIONS CODE -\nCORP TITLE 1.\nCORPORATIONS [100 -\nUnited States I ’ For-Profit Corporation ' e 14631] ( Title 1 enacted\nNEHQI2 of America us California US-CA General Stock H1UM Secretary English Secretary 2023-06-28 ACTV by Stats. 1947, Ch. 1038.\n) DIVISION 1. GENERAL\nCORPORATION LAW [100\n- 2319] - 5.305\nCORPORATIONS CODE -\nCORP TITLE 2.6.\n' s CALIFORNIA REVISED\nUnited Stat Limited Liabilit\nNNBOSK of”'Arenericz e us California US-CA cg:\"q eany'a ity El4) Organizer English Organizer 2023-06-28 |ACTV UNIFORM LIMITED\nP LIABILITY COMPANY ACT\n[17701.01 - 17713.13] -\n5.17702.01\nCORPORATIONS CODE -\nCORPTITLE 1.\nCORPORATIONS [100 -\nUnited States I ’ For-Profit Corporation ' e 14631] ( Title 1 enacted\nOKTQOF of America us California US-CA General Stock H1UM Transfer agent English Transfer agent 2023-06-28 ACTV by Stats. 1947, Ch. 1038.\n) DIVISION 1. GENERAL\nCORPORATION LAW [100\n-2319] - 5.601\nCORPORATIONS CODE -\nCORP TITLE 2.\nPARTNERSHIPS [15800 -\nUnited States 16962] ( Title 2 added by\nOLAQEA . us California US-CA Limited Partnership 5HQ4 General partner English General partner GP GP 2023-06-28 ACTV Stats. 1949, Ch. 383.)\nof America \"\nCHAPTER 4.5. Uniform\nLimited Partnership Act of\n2008 [15900 - 15912.07]\n5.15501\nCORPORATIONS CODE -\nCORP TITLE 2.6.\n' s CALIFORNIA REVISED\nPOOUXF gf”:re‘irsit;t“ us california US-CA gg\"n'qte:n';,'ab\"'ty El4) Assistant secretary English Assistant secretary 2023-0628 |ACTV UNIFORM LIMITED\nP LIABILITY COMPANY ACT\n[17701.01 - 17713.13] -\n5.17704.07\nCORPORATIONS CODE -\nCORPTITLE 1.\nCORPORATIONS [100 -\nUnited States I ’ For-Profit Corporation - ! ' . ! e 14631] ( Title 1 enacted\nPPPBAE of America us California US-CA General Stock H1UM Provisional director English Provisional director 2023-06-28 ACTV by Stats. 1947, Ch. 1038.\n) DIVISION 1. GENERAL\nCORPORATION LAW [100\n- 2319] - 5.308\nCORPORATIONS CODE -\nCORP TITLE 1.\nCORPORATIONS [100 -\nQ3AWBO gf\":re‘il_sit;t“ Us California US-CA g‘;:z:‘;?tsfi)ocfo’a“\"” H1UM Chief executive officer English Chief executive officer cEO CEO 2023-06-28 |ACTV é;‘g;;‘_ E‘;’f{ g::\"i;e:&\n) DIVISION 1. GENERAL\nCORPORATION LAW [100\n-2319] -5.312\nCORPORATIONS CODE -\nCORPTITLE 1.\nCORPORATIONS [100 -\nUnited States I ’ For-Profit Corporation ' e 14631] ( Title 1 enacted\nQJDNUB of America us California US-CA General Stock H1UM Agent English Agent 2023-06-28 ACTV by Stats. 1947, Ch. 1038.\n) DIVISION 1. GENERAL\nCORPORATION LAW [100\n-2319] -5.317\n63/119\n","contentLength":3376,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.731Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"CORPORATIONS CODE -\nCORPTITLE 2.6.\n' [ CALIFORNIA REVISED\nS5TZWT gf”:re‘irsit;t“ us california US-CA gg\"n'qte:n';,'ab\"'ty El4) Officer English Officer 2023-0628 |ACTV UNIFORM LIMITED\nP LIABILITY COMPANY ACT\n[17701.01 - 17713.13] -\n5.17704.01\nCORPORATIONS CODE -\nCORPTITLE 2.6.\nUnited States Limited Liability CALIFORNIA REVISED\nUBHCQQ of America us California US-CA Company El4) President English President 2023-06-28 |ACTV UNIFORM LIMITED\nLIABILITY COMPANY ACT\n[17701.01 - 17713.13] -\n5.17704.07\nCORPORATIONS CODE -\nCORPTITLE 2.6.\n' [ CALIFORNIA REVISED\nUnited Stat Limited Liabilit\nUDEF8T of”'Arenericz e us California US-CA cg:\"q eany'a ity El4) Agent English Agent 2023-06-28 |ACTV UNIFORM LIMITED\nP LIABILITY COMPANY ACT\n[17701.01 - 17713.13] -\n5.17704.08\nCORPORATIONS CODE -\nCORPTITLE 2.6.\n' [ CALIFORNIA REVISED\nV2HBTX gf”:re‘irsit;t“ us california US-CA gg\"n'qte:n';,'ab\"'ty El4) Manager English Manager 2023-0628 |ACTV UNIFORM LIMITED\nP LIABILITY COMPANY ACT\n[17701.01 - 17713.13] -\n5.17701.06\nCORPORATIONS CODE -\nCORPTITLE 1.\nCORPORATIONS [100 -\nUnited States - For-Profit Corporation i 14631] ( Title 1 enacted\nV2Z0PX us Calif Us-cA H1UM I t English I t 2023-0628 | ACTV\nof America alifornia General Stock ncorporator gl ncorporator by Stats. 1947, Ch. 1038.\n) DIVISION 1. GENERAL\nCORPORATION LAW [100\n-2319] - 5.210\nCORPORATIONS CODE -\nCORPTITLE 2.6.\n' [ CALIFORNIA REVISED\nVC6W4R gf”:renizt;tes Us California US-CA ggqn':e:n';,'ab\"'ty El4) Member English Member 2023-06-28 |ACTV UNIFORM LIMITED\nP LIABILITY COMPANY ACT\n[17701.01 - 17713.13] -\n5.17701.06\nCORPORATIONS CODE -\nCORPTITLE 2.6.\n' [ CALIFORNIA REVISED\nUnited Stat Limited Liabilit\nWCODHA of”'Arenericz e us California US-CA cg:\"q eany'a ity El4) Secretary English Secretary 2023-06-28 |ACTV UNIFORM LIMITED\nP LIABILITY COMPANY ACT\n[17701.01 - 17713.13] -\n5.17704.07\nCORPORATIONS CODE -\nCORPTITLE 2.6.\n' [ CALIFORNIA REVISED\nUnited Stat Limited Liabilit\nWCARQ2 of e |us California Us-CcA o eany'a i El4) Vice president English Vice president VP VP 20230628 |ACTV UNIFORM LIMITED\nP LIABILITY COMPANY ACT\n[17701.01 - 17713.13] -\n5.17704.07\nCORPORATIONS CODE -\nCORPTITLE 1.\nCORPORATIONS [100 -\nUnited States - ) For-Profit Corporation ! i ! o 14631] ( Title 1 enacted\nWRMU1X of America us California US-CA General Stock H1UM Director English Director 2023-06-28 ACTV by Stats. 1947, Ch. 1038.\n) DIVISION 1. GENERAL\nCORPORATION LAW [100\n-2319] - 5.164\nCORPORATIONS CODE -\nCORPTITLE 2.6.\n' [ CALIFORNIA REVISED\nUnited Stat Limited Liabilit\nWwW2u41 of”'Arenericz e us California US-CA cg:\"q eany'a ity El4) Transferee English Transferee 2023-06-28 |ACTV UNIFORM LIMITED\nP LIABILITY COMPANY ACT\n[17701.01 - 17713.13] -\n51770113\nCORPORATIONS CODE -\nCORP TITLE 2.\nPARTNERSHIPS [15800 -\nUnited States 16962] ( Title 2 added by\nXGUNTG of America us California US-CA Limited Partnership 5HQ4 Limited partner English Limited partner LP LP 2023-06-28 ACTV Stats. 1949, Ch. 383.)\nCHAPTER 4.5. Uniform\nLimited Partnership Act of\n2008 [15900 - 15912.07]\n5.15501\n64/119\n","contentLength":3024,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.731Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"CORPORATIONS CODE -\nCORP TITLE 1.\nCORPORATIONS [100 -\nUnited States \" \" - For-Profit Corporation \" \" \" 06 14631] ( Title 1 enacted\nXJ3VXN of America us California US-CA General Stock H1UM Independent auditor English Independent auditor 2023-06-28 ACTV by Stats. 1947, Ch. 1038.\n) DIVISION 1. GENERAL\nCORPORATION LAW [100\n-2319]-5.1502.1\nCORPORATIONS CODE -\nCORP TITLE 1.\nCORPORATIONS [100 -\nUnited States \" \" - For-Profit Corporation Director from an \" Director from an 06 14631] ( Title 1 enacted\nXNCQNZ of America us California Us-cA General Stock H1UM underrepresented community English underrepresented community 2023-06-28 ACTV by Stats. 1947, Ch. 1038.\n) DIVISION 1. GENERAL\nCORPORATION LAW [100\n-2319] -s.3014\nCORPORATIONS CODE -\nCORP TITLE 1.\nCORPORATIONS [100 -\nUnited States \" \" - For-Profit Corporation Chairperson \" Chairperson 06 14631] ( Title 1 enacted\nXsv3pp of America us California Us-CA General Stock HiuM (chair/chairwoman/chairman) English (chair/chairwoman/chairman) 2023-06-28 ACTV by Stats. 1947, Ch. 1038.\n) DIVISION 1. GENERAL\nCORPORATION LAW [100\n-2319] -5.305\nCORPORATIONS CODE -\nCORP TITLE 2.6.\n\" P PR CALIFORNIA REVISED\nXZPM6T gf”:re‘irsit;t“ us california US-CA gg\"n'qte:n';,'ab\"'ty El4) Agent for service of process | English Agent for service of process 2023-0628 |ACTV UNIFORM LIMITED\nP LIABILITY COMPANY ACT\n[17701.01 - 17713.13] -\n5.17701.13\nCORPORATIONS CODE -\nCORP TITLE 1.\nCORPORATIONS [100 -\nUnited States \" \" - For-Profit Corporation \" 06 14631] ( Title 1 enacted\nZGQQvB of America us California US-CA General Stock H1UM Shareholder English Shareholder 2023-06-28 ACTV by Stats. 1947, Ch. 1038.\n) DIVISION 1. GENERAL\nCORPORATION LAW [100\n-2319] -5.185\nCORPORATIONS CODE -\nCORP TITLE 1.\nCORPORATIONS [100 -\nUnited States \" \" - For-Profit Corporation \" 06 14631] ( Title 1 enacted\nZ0OA4LG of America us California US-CA General Stock H1UM Transferee English Transferee 2023-06-28 ACTV by Stats. 1947, Ch. 1038.\n) DIVISION 1. GENERAL\nCORPORATION LAW [100\n-2319] - 5.300\nCORPORATIONS CODE -\nCORP TITLE 1.\nCORPORATIONS [100 -\nUnited States \" \" - For-Profit Corporation \" \" \" 06 14631] ( Title 1 enacted\nZQZYHE of America us California US-CA General Stock H1UM Assistant treasurer English Assistant treasurer 2023-06-28 ACTV by Stats. 1947, Ch. 1038.\n) DIVISION 1. GENERAL\nCORPORATION LAW [100\n-2319]-s.313\nColorado Revised\n3DV32W United States | ;¢ Colorado Us-co For-Profit Corporation | OWR6 custodian English custodian 2023-06-28 | ACTV Statutes: Title 7: Colorado\nof America Business Corporations Act\n7-114-303\nColorado Revised\n3)PCQV United States ;o Colorado Us-co For-Profit Corporation | OWR6 secretary English secretary Sec. 2023-06-28 |ACTV Statutes: Title 7: Colorado\nof America Business Corporations Act\n7-101-401\nColorado Revised\n5FO5CW United States ;g Colorado Us-co For-Profit Corporation | OWRE incorporator English incorporator 2023-0628 |ACTV Statutes: Title 7: Colorado\nof America Business Corporations Act\n7-102-101\nColorado Revised\nUnited States Limited Liability \" \" \" Statutes: Title 7: Art.80 -\n5U6NJS of America us Colorado us-co Company L1oT registered agent English registered agent 2023-06-28 ACTV Colorado Limited Liability\nCompany Act 7-80-204\nColorado Revised\n8AIHLS United States | ;g Colorado Us-co For-Profit Corporation | OWR6 director English director Dir. 2023-06-28 | ACTV Statutes: Title 7: Colorada\nof America Business Corporations Act\n7-102-106\nColorado Revised\nA4ICID United States ;o Colorado Us-co Limited Liability L10T member English member 2023-06-28 |ACTV Statutes: Title 7: Art.80 -\nof America Company Colorado Limited Liability\nCompany Act 7-80-102\nColorado Revised\ncaocwx United States ) Colorado Us-co Limited Liability L10T receiver English receiver 2023-0628 | ACTV Statutes: Title 7: At.80 -\nof America Company Colorado Limited Liability\nCompany Act 7-80-811\n65/119\n","contentLength":3858,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.731Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Colorado Revised\nCFOB6Z United States ;g Colorado Us-co For-Profit Corporation | OWRE receiver English receiver 2023-0628 |ACTV Statutes: Title 7: Colorado\nof America Business Corporations Act\n7-114-303\nColorado Revised\nUnited States Limited Liability \" Statutes: Title 7: Art.80 -\nFIVQW) of America us Colorado us-co Company L10T manager English manager Mar. 2023-06-28 ACTV Colorado Limited Liability\nCompany Act 7-80-102\nColorado Revised\nKDWDCY United States ;g Colorado Us-co For-Profit Corporation | OWRE beneficial owner English beneficial owner 2023-0628 |ACTV Statutes: Title 7: Colorado\nof America Business Corporations Act\n7-101-401\nColorado Revised\nMZ87LY United States | ;¢ Colorado Us-co Limited Liability L10T officer English officer 2023-06-28 | ACTV Statutes: Title 7: Art.80 -\nof America Company Colorado Limited Liability\nCompany Act 7-80-403\nColorado Revised\nQQUROY United states g Colorado us-co For-Profit Corporation OWR6 registered agent English registered agent 2023-06-28 |ACTV Statutes: Title 7: C.olorado\nof America Business Corporations Act\n7-105-101\nColorado Revised\nRLMD1U United States ;o Colorado Us-co For-Profit Corporation | OWR6 subscriber English subscriber 2023-06-28 |ACTV Statutes: Title 7: Colorado\nof America Business Corporations Act\n7-101-401\nColorado Revised\nSUMOAM United States ;o Colorado Us-co Limited Liability L10T custodian English custodian 2023-06-28 |ACTV Statutes: Title 7: Art.80 -\nof America Company Colorado Limited Liability\nCompany Act 7-80-811\nColorado Revised\nUnited States . : ; Statutes: Title 7: Colorado\nuD5TDY of America us Colorado us-co For-Profit Corporation OWR6 shareholder English shareholder 2023-06-28 ACTV Business Corporations Act\n7-101-401\nColorado Revised\nXM2CFI United States | ;¢ Colorado Us-co For-Profit Corporation | OWR6 officer English officer 2023-06-28 | ACTV Statutes: Title 7: Colorado\nof America Business Corporations Act\n7-108-301\nGeneral Statutes of\nConnecticut: Title 34:\nUnited States \" Limited Liability \" CHAPTER 613a UNIFORM\n372YPQ of America us Connecticut US-CT Company Y182 member English member 2023-06-28 ACTV LIMITED LIABILITY\nCOMPANY ACT Sec. 34-\n243a\nGeneral Statutes of\nUnited States Connecticut: Title 33:\n5EB5MR of America us Connecticut us-CT Stock Corporation JKOT president English president 2023-06-28 ACTV Ch.601 Connecticut\nBusiness Corporation Act\n- Sec. 33-608\nGeneral Statutes of\nUnited States Connecticut: Title 33:\n82WBMB of America us Connecticut US-CT Stock Corporation JKOT secretary English secretary 2023-06-28 ACTV Ch.601 Connecticut\nBusiness Corporation Act\n- Sec. 33-602\nGeneral Statutes of\nUnited States Connecticut: Title 33:\nAES300 of America us Connecticut us-CT Stock Corporation JKOT director English director 2023-06-28 ACTV Ch.601 Connecticut\nBusiness Corporation Act\n- Sec. 33-735\nGeneral Statutes of\nUnited States Connecticut: Title 33:\nASYOGB of America us Connecticut us-CT Stock Corporation JKOT beneficial shareholder English beneficial shareholder 2023-06-28 ACTV Ch.601 Connecticut\nBusiness Corporation Act\n- Sec. 33-602\nGeneral Statutes of\nUnited States Connecticut: Title 33:\nEIQTOT of America us Connecticut us-CT Stock Corporation JKOT custodian English custodian 2023-06-28 ACTV Ch.601 Connecticut\nBusiness Corporation Act\n- Sec. 33-868\nGeneral Statutes of\nConnecticut: Title 34:\nUnited States \" Limited Liability \" \" \" CHAPTER 613a UNIFORM\nEJAGYM of America us Connecticut US-CT Company Y182 organizer English organizer 2023-06-28 ACTV LIMITED LIABILITY\nCOMPANY ACT Sec. 34-\n243a\nGeneral Statutes of\nConnecticut: Title 34:\nUnited States \" Limited Liability \" CHAPTER 613a UNIFORM\nHSVU5G us C cticut us-CT Y182 English Mgr. 2023-06-28 ACTV\nof America onnecticu Company manager nglls manager or LIMITED LIABILITY\nCOMPANY ACT Sec. 34-\n243a\n66/119\n","contentLength":3795,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.731Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"General Statutes of\nUnited States Connecticut: Title 33:\nMMRVQR of America us Connecticut us-CT Stock Corporation JKOT chairman English chairman 2023-06-28 ACTV Ch.601 Connecticut\nBusiness Corporation Act\n- Sec. 33-608\nGeneral Statutes of\nUnited States Connecticut: Title 33:\nPL4AVBY of America us Connecticut US-CT Stock Corporation JKOT voting trustee English voting trustee 2023-06-28 ACTV Ch.601 Connecticut\nBusiness Corporation Act\n- Sec. 33-715\nGeneral Statutes of\nConnecticut: Title 34:\nUnited States \" Limited Liability \" CHAPTER 613a UNIFORM\nQ3ERLN of America us Connecticut US-CT Company Y182 officer English officer 2023-06-28 ACTV LIMITED LIABILITY\nCOMPANY ACT Sec. 34-\n2559\nGeneral Statutes of\nUnited States Connecticut: Title 33:\nSPQCON of America us Connecticut us-CT Stock Corporation JKOT interest holder English interest holder 2023-06-28 ACTV Ch.601 Connecticut\nBusiness Corporation Act\n- Sec. 33-673a/b\nGeneral Statutes of\nUnited States Connecticut: Title 33:\nTYK8MD of America us Connecticut us-CT Stock Corporation JKOT vice president English vice president 2023-06-28 ACTV Ch.601 Connecticut\nBusiness Corporation Act\n- Sec. 33-624\nGeneral Statutes of\nUnited States Connecticut: Title 33:\nU6XPPN of America us Connecticut US-CT Stock Corporation JKOT registered agent English registered agent 2023-06-28 ACTV Ch.601 Connecticut\nBusiness Corporation Act\n- Sec. 33-660\nGeneral Statutes of\nUnited States Connecticut: Title 33:\nUFTXAO of America us Connecticut us-CT Stock Corporation JKOT receiver English receiver 2023-06-28 ACTV Ch.601 Connecticut\nBusiness Corporation Act\n- Sec. 33-868\nGeneral Statutes of\nited Connecticut: Title 33:\nV4HKIO United States ;g Connecticut us-cT Stock Corporation JKOT subscriber English subscriber 2023-06-28 |ACTV Ch.601 Connecticut\nof America Business Corporation Act\n- Sec. 33-602\nGeneral Statutes of\nUnited States Connecticut: Title 33:\nW64FU9 of America us Connecticut us-CT Stock Corporation JKOT incorporator English incorporator 2023-06-28 ACTV Ch.601 Connecticut\nBusiness Corporation Act\n- Sec. 33-635\nGeneral Statutes of\nUnited States Connecticut: Title 33:\nWKILMU of America us Connecticut us-CT Stock Corporation JKOT qualified director English qualified director 2023-06-28 ACTV Ch.601 Connecticut\nBusiness Corporation Act\n- Sec. 33-602\nGeneral Statutes of\nUnited States Connecticut: Title 33:\nWTPQDH of America us Connecticut us-CT Stock Corporation JKOT officer English officer 2023-06-28 ACTV Ch.601 Connecticut\nBusiness Corporation Act\n- Sec. 33-763\nGeneral Statutes of\nConnecticut: Title 34:\nUnited States \" Limited Liability \" \" \" CHAPTER 613a UNIFORM\nYPPLDL of America us Connecticut US-CT Company Y182 registered agent English registered agent 2023-06-28 ACTV LIMITED LIABILITY\nCOMPANY ACT Sec. 34-\n243a\nGeneral Statutes of\nUnited States Connecticut: Title 33:\nZN1EQE of America us Connecticut us-CT Stock Corporation JKOT shareholder English shareholder 2023-06-28 ACTV Ch.601 Connecticut\nBusiness Corporation Act\n- Sec. 33-602\nUnited States Delaware Code: Title 6:\n0SMMNE of America us Delaware US-DE Limited Partnership T91T Personal representative English Personal representative 2023-06-28 ACTV Subtitle 2: Chapter 17\n5.17-701\n6ADUFX United States | ;g Delaware US-DE Corporation XTIQ officer English Officer 2023-06-28 |ACTV Delaware Code: Title 8:\nof America Chapter 1 5.110\nUnited States Delaware Code: Title 6:\n60FDKU of America us Delaware US-DE Limited Partnership T91T Registered agent English Registered agent 2023-06-28 |ACTV Subtitle 2: Chapter 17\n5.17-104\nUnited States . \" \" \" Delaware Code: Title 8:\ne vspe xme Redtstered agent naten _ Reaisered agent -- 20230628 --- Chapter 15132\nUnited States Delaware Code: Title 6:\nANPVIG . us Delaware US-DE Limited Partnership T91T General partner English General partner GP GP 2023-06-28 ACTV Subtitle 2: Chapter 17\nof America 5.17-701\nBLFLOI United States | ;g Delaware US-DE Corporation XTIQ Provisional director English Provisional director 2023-06-28 |ACTV Delaware Code: Title 8:\nof America Chapter 1 5.353\n67/119\n","contentLength":4053,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.731Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"BROMMZ United States | ;g Delaware US-DE Corporation XTIQ Interested stockholder English Interested stockholder 2023-06-28 |ACTV Delaware Code: Title 8:\nof America Chapter 15.203\nUnited States Delaware Code: Title 6:\nCBNI9S ! us Delaware US-DE Limited Partnership TOIT Limited partner English Limited partner Lp Lp 2023-06-28 [ACTV Subtitle 2: Chapter 17\nof America 5.17-701\nUnited States Delaware Code: Title 12:\nCVLXPG ! us Delaware US-DE Statutory Trust 4FSX officer English Officer 2023-06-28 [ACTV Chapter 38: Subchapter 1\nof America\n5.3806b.7\nUnited States Delaware Code: Title 12:\nEQ4LAO of America us Delaware US-DE Statutory Trust 4FSX Manager English Manager 2023-06-28 ACTV Chapter 38: Subchapter 1\n5.3806b.7\nF582)U United States | ;g Delaware US-DE Corporation XTIQ Stockholder English Stockholder 20230628 |ACTV Delaware Code: Title 8:\nof America Chapter 1 5.102\n. - Delaware Code: Title 6:\nUnited Stat Limited Liabilit\nFABSWT nited states ;5 Delaware US-DE mited Liability HZEH Liquidating trustee English Liquidating trustee 2023-06-28 |ACTV Subtitle 2: Chapter 18\nof America Company 5.18-109\nUnited States Delaware Code: Title 12:\nFLQU84 ! us Delaware US-DE Statutory Trust 4FSX Employee English Employee 2023-06-28 [ACTV Chapter 38: Subchapter 1\nof America\n5.3806b.7\n! - Delaware Code: Title 6:\nFWU6BQ United States |, Delaware US-DE Limited Liability HZEH Member English Member 2023-0628 |ACTV Subtitle 2: Chapter 18\nof America Company\n5.18-101\nUnited States . . I . Delaware Code: Title 8:\ncuBwre VSpE xme Member of the governing body | Endlish _ Member ofthe governing body -- 20230628 --- Chapter15.114\nHPASDL United States | ;g Delaware US-DE Corporation XTIQ Member English Member 2023-06-28 |ACTV Delaware Code: Title 8:\nof America Chapter 1 5.102\nUnited States . . I . Delaware Code: Title 8:\nKuxozm VSpE xme Engtisn _-- 20230628 --- Chapter 15.226\n. - Delaware Code: Title 6:\nUnited Stat Limited Liabilit\nL8LDTW nited states ;5 Delaware US-DE mited Liability HZEH Assignee English Assignee 2023-06-28 |ACTV Subtitle 2: Chapter 18\nof America Company 5.18-702\n. - Delaware Code: Title 6:\nUnited Stat Limited Liabilit\nMHUOPP nited states ;5 Delaware US-DE mited Liability HZEH Receiver English Receiver 2023-06-28 |ACTV Subtitle 2: Chapter 18\nof America Company\n5.18-805\nUnited States Delaware Code: Title 12:\nMSUUJM ! us Delaware US-DE Statutory Trust 4FSX Trustee English Trustee 2023-06-28 [ACTV Chapter 38: Subchapter 1\nof America 5.3801\n. . . Delaware Code: Title 12:\nUnited States Registered agent (for . Registered agent (for 8\n05KB2U of America us Delaware US-DE Statutory Trust 4FSX investment companies) English investment companies) 2023-06-28 ACTV ?g%%tfr 38: Subchapter 1\nted Delaware Code: Title 12:\nOBXOAB United States ;g Delaware US-DE Statutory Trust 4FSX Beneficial owner English Beneficial owner 2023-06-28 |ACTV Chapter 38: Subchapter 1\nof America 5.3801\nUnited States . I Delaware Code: Title 8:\nPaspo) VSpE xme Engtisn _-- 20230628 --- Chapter 15.292\nQXQQDG United S.tates us Delaware US-DE Corporation XTIQ Committee member English Committee member 2023-06-28 ACTV Delaware Code: Title 8:\nof America Chapter 1 5.141\nUnited States . I Delaware Code: Title 8:\nTR VSpE xme Engtisn _-- 20230628 --- Chapter 1 5.107\n. - Delaware Code: Title 6:\nUnited Stat Limited Liabilit\nVAAYBH nited states ;5 Delaware US-DE mited Liability HZEH Manager English Manager 2023-06-28 |ACTV Subtitle 2: Chapter 18\nof America Company\n5.18-101\nVOYVSD United States | ;g Delaware US-DE Corporation XTIQ Director English Director 2023-06-28 |ACTV Delaware Code: Title 8:\nof America Chapter 1 5.102\n. Delaware Code: Title 12:\nUnited States Independent trustee (for . Independent trustee (for 8\nYDIRR] of America us Delaware US-DE Statutory Trust 4FSX investment companies) English investment companies) 2023-06-28 ACTV ?g%%tler 38: Subchapter 1\n. - Delaware Code: Title 6:\nUnited Stat Limited Liabilit\nzoc)v4 nited states ;5 Delaware US-DE mited Liability HZEH Registered agent English Registered agent 2023-06-28 |ACTV Subtitle 2: Chapter 18\nof America Company 5.18-104\nZAKXYO United States | ;g Delaware US-DE Corporation XTIQ Custodian English Custodian 2023-06-28 |ACTV Delaware Code: Title 8:\nof America Chapter 1 5.226\nUnited States Delaware Code: Title 6:\nZVYKBD of America us Delaware US-DE Limited Partnership T91T Liquidating trustee English Liquidating trustee 2023-06-28 ACTV Subtitle 2: Chapter 17\n5.17-109\nCode of the District of\n\" _— Business Corporation Columbia: Ch.3 Business\nUnited Stat District of\n0BQJRA nited states ;5 istrict o Us-DC (including professional | CNQ3 director English director 2023-06-28 |ACTV Corporations: Business\nof America Columbia h .\ncorporation) Corporation Act of 2010 -\n§29-302.05\nCode of the District of\n\" _— Business Corporation Columbia: Ch.3 Business\nUnited Stat District of\n8LZETG nited States ;g strict o Us-DC (including professional | CNQ3 independent director English independent director 2023-0628 | ACTV Corporations: Business\nof America Columbia h .\ncorporation) Corporation Act of 2010 -\n§29-306.01\n68/119\n","contentLength":5089,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.731Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Code of the District of\n\" _— Business Corporation Columbia: Ch.3 Business\nUnited Stat District of\n95DYNV nited States ;g strict o Us-DC (including professional | CNQ3 incorporator English incorporator 20230628 |ACTV Corporations: Business\nof America Columbia h :\ncorporation) Corporation Act of 2010 -\n§29-302.01\nCode of the District of\n\" _— Business Corporation Columbia: Ch.3 Business\nUnited Stat District of\nCFO6IS nited states ;5 istrict o Us-DC (including professional | CNQ3 secretary English secretary 2023-06-28 |ACTV Corporations: Business\nof America Columbia h :\ncorporation) Corporation Act of 2010 -\n§29-301.02\nCode of the District of\n\" _— Business Corporation Columbia: Ch.3 Business\nUnited Stat District of\nESFDQG nited states ;5 istrict o Us-DC (including professional | CNQ3 shareholder English shareholder 2023-06-28 |ACTV Corporations: Business\nof America Columbia h :\ncorporation) Corporation Act of 2010 -\n§29-301.02\nCode of the District of\nLimited Liability Columbia: Title 29: Ch.8\nUnited States District of . Company (including . o6 Limited Liability\nFAKFAO of America us Columbia us-bc professional LLC and VNIU manager English manager Mgr. 2023-06-28 ACTV Companies - Uniform\nseries LLC) Limited Liability Company\nAct 0of 2010 § 29-801.02\nCode of the District of\nLimited Liability Columbia: Title 29: Ch.8\nFGKT2P United States | ;g District of Us-DC Company (including VNIU member English member 2023-06-28 |ACTV Limited Lability\nof America Columbia professional LLC and Companies - Uniform\nseries LLC) Limited Liability Company\nAct 0of 2010 § 29-801.02\nCode of the District of\n\" _— Business Corporation Columbia: Ch.3 Business\nHBXHUO gf”:re‘irsit;t“ us E:;tfl‘i;gf Us-DC (including professional | CNQ3 officer English officer 2023-0628 |ACTV Corporations: Business\ncorporation) Corporation Act of 2010 -\n§29-306.40\nCode of the District of\n\" _— Business Corporation Columbia: Ch.3 Business\nHNFOAQ g?:;izgm us E:;tfl‘i;gf Us-DC (including professional | CNQ3 voting trustee English voting trustee 2023-0628 |ACTV Corporations: Business\ncorporation) Corporation Act of 2010 -\n§29-305.40\nCode of the District of\n\" _— Business Corporation Columbia: Ch.3 Business\nMH9RYW g;\\::fideztcaates us E:;::‘:Lg us-DC (including professional CNQ3 transfer agent English transfer agent 2023-06-28 ACTV Corporations: Business\ncorporation) Corporation Act of 2010 -\n§29-301.03\nCode of the District of\n\" _— Business Corporation Columbia: Ch.3 Business\nMQDSLD g;\\::fideztcaates us E:;::‘:Lg us-DC (including professional CNQ3 receiver English receiver 2023-06-28 ACTV Corporations: Business\ncorporation) Corporation Act of 2010 -\n§29-312.21\nCode of the District of\n\" _— Business Corporation Columbia: Ch.3 Business\nNBUYJO gf”:re‘irsit;t“ us E:;tfl‘i;gf Us-DC (including professional | CNQ3 assistant secretary English assistant secretary 2023-06-28 | ACTV Corporations: Business\ncorporation) Corporation Act of 2010 -\n§29-301.03\nCode of the District of\nLimited Liability Columbia: Title 29: Ch.8\n\" _— \" \" Limited Liability\nUnited States District of . Company (including \" \" \" 06 - .\nODMPYU of America us Columbia us-DC professional LLC and VNIU registered agent English registered agent 2023-06-28 ACTV C_ompanl_es ,.l.Jr“form\nseries LLC) Limited Liability Company\nAct of 2010 § 29-802.06\nCode of the District of\n\" _— Business Corporation Columbia: Ch.3 Business\nST4YMT gf”:re‘irsit;t“ Us E:;tfl‘i;gf Us-DC (including professional | CNQ3 qualified director English qualified director 2023-06-28 |ACTV Corporations: Business\ncorporation) Corporation Act of 2010 -\n§29-301.21\nCode of the District of\nLimited Liability Columbia: Title 29: Ch.8\nUnited States District of Company (including . . . Limited Liability\nTUS2uB us us-DC VNIU English 2023-06-28 ACTV\nof America Columbia professional LLC and organizer gl organizer Companies - Uniform\nseries LLC) Limited Liability Company\nAct 0of 2010 § 29-801.02\nCode of the District of\n\" _— Business Corporation Columbia: Ch.3 Business\nUnited Stat District of\nVOEZOV nited states ;5 istrict o Us-DC (including professional | CNQ3 subscriber English subscriber 2023-06-28 |ACTV Corporations: Business\nof America Columbia h :\ncorporation) Corporation Act of 2010 -\n§29-301.02\nCode of the District of\n\" _— Business Corporation Columbia: Ch.3 Business\nUnited Stat District of\nXXISCR nited states ;5 istrict o Us-DC (including professional | CNQ3 chair English chair 2023-06-28 |ACTV Corporations: Business\nof America Columbia h :\ncorporation) Corporation Act of 2010 -\n§29-306.07\nCode of the District of\n\" _— Business Corporation Columbia: Ch.3 Business\nUnited Stat District of\n29GJuW nited states ;5 istrict o Us-DC (including professional | CNQ3 beneficial owner English beneficial owner 2023-06-28 |ACTV Corporations: Business\nof America Columbia h :\ncorporation) Corporation Act of 2010 -\n§29-305.23\n69/119\n","contentLength":4846,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.731Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Code of the District of\n\" - Business Corporation Columbia: Ch.3 Business\nUnited Stat District of\nZWNFRZ nited states ;5 istrict o Us-DC (including professional | CNQ3 custodian English custodian 2023-06-28 |ACTV Corporations: Business\nof America Columbia h :\ncorporation) Corporation Act of 2010 -\n§29-312.21\n\" . it 2021 Florida Statutes:\n16FTKP United States |, Florida US-FL umited Liability 8N21 Member English Member 2023-0628 |ACTV Title 36: Chapter 605:\nof America Company\n605.0102\nUnited States 2021 Florida Statutes:\n256CEO of America us Florida US-FL Profit Corporation TRI2 Director English Director 2023-06-28 ACTV Title 36: Chapter 607:\n607.205\nUnited States 2021 Florida Statutes:\n92DAFD of America us Florida US-FL Profit Corporation TRI2 Registered agent English Registered agent 2023-06-28 ACTV Title 36: Chapter 607:\n607.01501\n\" - \" 2021 Florida Statutes:\nUnited States . . Beneficial \" Beneficial . N A\n\" . it 2021 Florida Statutes:\nAAOVMQ United States ;¢ Florida US-FL Limited Liability 8N21 Authorized representative English Authorized representative 2023-06-28 |ACTV Title 36: Chapter 605:\nof America Company\n605.0102\nUnited States 2021 Florida Statutes:\nC1RYRZ of America us Florida US-FL Profit Corporation TRI2 Senior executive English Senior executive 2023-06-28 ACTV Title 36: Chapter 607:\n607.1301\nUnited States 2021 Florida Statutes:\nCDRPXL of America us Florida US-FL Profit Corporation TRI2 Receiver English Receiver 2023-06-28 ACTV Title 36: Chapter 607:\n607.748\nUnited States 2021 Florida Statutes:\nDP1TLX of America us Florida US-FL Profit Corporation TRI2 Benefit officer English Benefit officer 2023-06-28 ACTV Title 36: Chapter 607:\n607.502\nUnited States 2021 Florida Statutes:\nEPVBXY of America us Florida US-FL Profit Corporation TRI2 Incorporator English Incorporator 2023-06-28 ACTV Title 36: Chapter 607:\n607.201\nUnited States 2021 Florida Statutes:\nJRZFMK of America us Florida US-FL Profit Corporation TRI2 Officer English Officer 2023-06-28 ACTV Title 36: Chapter 607:\n607.303\nUnited States 2021 Florida Statutes:\nKQWRJQ of America us Florida US-FL Profit Corporation TRI2 Interested shareholder English Interested shareholder 2023-06-28 ACTV Title 36: Chapter 607:\n607.0902\nUnited States 2021 Florida Statutes:\nLWMJ2R of America us Florida US-FL Profit Corporation TRI2 Governor English Governor 2023-06-28 ACTV Title 36: Chapter 607:\n607.01401\nUnited States 2021 Florida Statutes:\nNImM8LI of America us Florida US-FL Profit Corporation TRI2 Shareholder English Shareholder 2023-06-28 ACTV Title 36: Chapter 607:\n607.01401\n\" . it 2021 Florida Statutes:\nUnited Stat Limited Liabilit:\nNTWGSF nited states ;5 Florida US-FL mited Liability 8N21 Governor English Governor 2023-06-28 |ACTV Title 36: Chapter 605:\nof America Company\n605.0102\nUnited States 2021 Florida Statutes:\nOLH3AA of America us Florida US-FL Profit Corporation TRI2 Committee member English Committee member 2023-06-28 ACTV Title 36: Chapter 607:\n607.825\n\" . it 2021 Florida Statutes:\nUnited Stat Limited Liabilit:\nQEMMLX nited states ;5 Florida US-FL mited Liability 8N21 Custodian English Custodian 2023-06-28 |ACTV Title 36: Chapter 605:\nof America Company\n605.0704\n2021 Florida Statutes:\nSNXRXY United States |, Florid US-FL Umited Liability 8N21 Registered agent English Registered agent 2023-0628 | ACTV Title 36: Chapter 605:\nof America orida - Company egistered agen nglis egistered agen -06-: s o\n\" . it 2021 Florida Statutes:\nTVOAGY United States |, Florida US-FL umited Liability 8N21 Manager English Manager 2023-0628 |ACTV Title 36: Chapter 605:\nof America Company\n605.0102\nUnited States 2021 Florida Statutes:\nTWBCEZ of America us Florida US-FL Profit Corporation TRI2 Provisional director English Provisional director 2023-06-28 ACTV Title 36: Chapter 607:\n607.749\nUnited States 2021 Florida Statutes:\nVB06BS of America us Florida US-FL Profit Corporation TRI2 Qualified director English Qualified director 2023-06-28 |ACTV Title 36: Chapter 607:\n607.143\n\" . it 2021 Florida Statutes:\nVKEVI2 United States |, Florida US-FL umited Liability 8N21 Receiver English Receiver 2023-0628 |ACTV Title 36: Chapter 605:\nof America Company\n605.0704\n\" - PR _— . \" \" 2021 Florida Statutes:\nUnited States : Limited Liability Beneficial owner/beneficial ; Beneficial owner/beneficial h N N\nWMKPIS of America us Florida US-FL Company 8N21 member English member 2023-06-28 ACTV Title 36: Chapter 605:\n605.1061\nUnited States 2021 Florida Statutes:\nY48KXA of America us Florida US-FL Profit Corporation TRI2 Secretary English Secretary 2023-06-28 ACTV Title 36: Chapter 607:\n607.01401\nUnited States 2021 Florida Statutes:\nYECNUU of America us Florida US-FL Profit Corporation TRI2 Benefit director English Benefit director 2023-06-28 ACTV Title 36: Chapter 607:\n607.502\n70/119\n","contentLength":4784,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.732Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"23 MAART 2019. — Wet\ntot invoering van het\nWetboek van\nVi P d vennootschappen en\nKR3NFE Belgium ereniging zonder W3WH Lid van het bestuursorgaan | Dutch Lid van het bestuursorgaan 2023-06-28 |ACTV verenigingen en\nwinstoogmerk \"\nhoudende diverse\nbepalingen - BOEK 2:\nTITEL 6: HOOFDSTUK 2:\nArt.2:56\n23 MARZ 2019. —\nKR3NFE Belgium Vereinigung ohne |,y 3y Mitglied des German Mitglied des 2023-06-28 |ACTV Gesetzbuch der\nGewinnerzielungsabsicht Verwaltungsorgans Verwaltungsorgans Gesellschaften und\nVereinigungen\n23 MAART 2019. — Wet\ntot invoering van het\nWetboek van\nvennootschappen en\nNHHOPA Belgium Besloten Vennootschap |3W7E Houder van converteerbare | 1, Houder van converteerbare 2023-06-28 | ACTV verenigingen en\nobligaties obligaties y\nhoudende diverse\nbepalingen - BOEK 5:\nTITEL 4: HOOFDSTUK 2:\nArt.5:86\n23 MARS 2019. — Loi\nintroduisant le Code des\nSR P : F— iétés et des\n) Société a responsabilité Titulaire d’obligations Titulaire d’obligations societes\nNHHOPA Belgium limitée 3W7E convertibles French fr convertibles 2023-06-28 ACTV assoc.latlor.u;. et portant\ndes dispositions diverses -\nLivre 5: Titre 4: CHAPITRE\n2: Art. 5:86\n23 MARZ 2019. —\n\" Gesellschaft mit Inhaber von Inhaber von Gesetzbuch der\nNHHOPA Bel 3W7E G 2023-06-28 ACTV\nelgium beschrankter Haftung Wandelschuldverschreibungen erman Wandelschuldverschreibungen Gesellschaften und\nVereinigungen\n23 MAART 2019. — Wet\ntot invoering van het\nWetboek van\nvennootschappen en\nNKIWVK Belgium Besloten Vennootschap |3W7E Voorzitter Dutch Voorzitter 2023-06-28 ACTV verenigingen en\nhoudende diverse\nbepalingen - BOEK 2:\nTITEL 7: HOOFDSTUK 1:\nArt.2:62:3\n23 MARS 2019. — Loi\nintroduisant le Code des\nSociété a responsabilité sociétés et des\nNKIWVK Belgium limitée P 3W7E Président French fr Président 2023-06-28 |ACTV associations et portant\ndes dispositions diverses -\nLivre 2: Titre 7: CHAPITRE\n1: Art. 2:62.3\n23 MARZ 2019. —\n\" Gesellschaft mit \" \" Gesetzbuch der\nNKIWVK Belgium beschrankter Haftung 3W7E Vorsitzende German Vorsitzende 2023-06-28 ACTV Gesellschaften und\nVereinigungen\n23 MARS 2019. — Loi\nintroduisant le Code des\n\" \" sociétés et des\nPDES2K Belgium Société anonyme R85P z!i?;:fifi;?::en French fr zl‘irdnn?\\:'siifai(i)::e” 2023-06-28 ACTV associations et portant\ndes dispositions diverses -\nLivre 7: Titre 4: CHAPITRE\n1: Art. 7:99\n23 MAART 2019. — Wet\ntot invoering van het\nWetboek van\nvennootschappen en\nPDES2K Belgium Naamloze vennootschap [ R85P Lid van de raad van bestuur Dutch Lid van de raad van bestuur 2023-06-28 ACTV verenigingen en\nhoudende diverse\nbepalingen - BOEK 7:\nTITEL 4: HOOFDSTUK 1:\nArt.7:99\n23 MARZ 2019. —\nPDES2K Belgium Aktiengesellschaft R85P Vorstandsmitglied German Vorstandsmitglied 2023-06-28 [ACTV Gesetzbuch der\nGesellschaften und\nVereinigungen\n23 MARS 2019. — Loi\nintroduisant le Code des\n. P Membre du conseil de Membre du conseil de sociét_és_et des\nPNPDW1 Belgium Société anonyme R85P surveillance French fr surveillance 2023-06-28 ACTV assoc.latlor.u;. et portant\ndes dispositions diverses -\nLivre 7: Titre 4: CHAPITRE\n1: Art. 7:85\n8/119\n","contentLength":3053,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.732Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"United States 2021 Florida Statutes:\nYGAEJN of America us Florida US-FL Profit Corporation TRI2 Custodian English Custodian 2023-06-28 ACTV Title 36: Chapter 607:\n607.748\nUnited States 2021 Florida Statutes:\nYKMJNU of America us Florida US-FL Profit Corporation TRI2 Record shareholder English Record shareholder 2023-06-28 ACTV Title 36: Chapter 607:\n607.01401\nUnited States 2021 Florida Statutes:\nYSHHXC of America us Florida US-FL Profit Corporation TRI2 Subscriber English Subscriber 2023-06-28 ACTV Title 36: Chapter 607:\n607.01401\n\" . it 2021 Florida Statutes:\nZURXF6 United States |, Florida US-FL umited Liability 8N21 Senior executive English Senior executive 2023-06-28 | ACTV Title 36: Chapter 605:\nof America Company\n605.1061\nCode of Georgia: TITLE\n\" P PR 14: CHAPTER 11. LIMITED\nUnited Stat Limited Liabilit:\n30NBEX nited states ;5 Georgia US-GA mited Liability organizer English organizer 2023-06-28 |ACTV LIABILITY COMPANIES -\nof America Company P P\nGeorgia Limited Liability\nCompany Act § 14-11-203\nCode of Georgia: TITLE\nUnited States 14: CHAPTER 2 BUSINESS\n6A1BTH of America us Georgia US-GA Profit Corporation MFY) vice president English vice president VP 2023-06-28 ACTV CORPORATIONS - Georgia\nBusiness Corporation\nCode §14-2-151\nCode of Georgia: TITLE\nUnited States 14: CHAPTER 2 BUSINESS\nAPLFSO of America us Georgia US-GA Profit Corporation MFY) incorporator English incorporator 2023-06-28 ACTV CORPORATIONS - Georgia\nBusiness Corporation\nCode §14-2-201\nCode of Georgia: TITLE\nUnited States 14: CHAPTER 2 BUSINESS\nASBZOT of America us Georgia US-GA Profit Corporation MFY) assistant secretary English assistant secretary Asst.Sec. 2023-06-28 ACTV CORPORATIONS - Georgia\nBusiness Corporation\nCode §14-2-151\nCode of Georgia: TITLE\n\" P PR 14: CHAPTER 11. LIMITED\nBLWFUU United States |, Georgia US-GA umited Liability member English member 2023-0628 |ACTV LIABILITY COMPANIES -\nof America Company P R,\nGeorgia Limited Liability\nCompany Act § 14-11-101\nCode of Georgia: TITLE\nUnited States 14: CHAPTER 2 BUSINESS\nE80JBN of America us Georgia US-GA Profit Corporation MFY) secretary English secretary Sec. 2023-06-28 ACTV CORPORATIONS - Georgia\nBusiness Corporation\nCode §14-2-140\nCode of Georgia: TITLE\nUnited States 14: CHAPTER 2 BUSINESS\nF5SWMYA of America us Georgia US-GA Profit Corporation MFY) president English president Pres. 2023-06-28 ACTV CORPORATIONS - Georgia\nBusiness Corporation\nCode §14-2-151\nCode of Georgia: TITLE\nUnited States 14: CHAPTER 2 BUSINESS\nFIZ)58 of America us Georgia US-GA Profit Corporation MFY) custodian English custodian 2023-06-28 ACTV CORPORATIONS - Georgia\nBusiness Corporation\nCode §14-2-501\nCode of Georgia: TITLE\nUnited States 14: CHAPTER 2 BUSINESS\nGQ5LHD of America us Georgia US-GA Profit Corporation MFY) shareholder English shareholder 2023-06-28 ACTV CORPORATIONS - Georgia\nBusiness Corporation\nCode §14-2-140\nCode of Georgia: TITLE\n\" P PR 14: CHAPTER 11. LIMITED\nUnited Stat Limited Liabilit:\nH4LBOX nited states ;5 Georgia US-GA mited Liability receiver English receiver 2023-06-28 |ACTV LIABILITY COMPANIES -\nof America Company P P\nGeorgia Limited Liability\nCompany Act § 14-11-205\nCode of Georgia: TITLE\n14: CHAPTER 2 BUSINESS\nLVAFJO United States ;g Georgia US-GA Profit Corporation MFY) director English director Dir. 2023-06-28 |ACTV CORPORATIONS - Georgia\nof America Business Corporation\nCode §14-2-151\nCode of Georgia: TITLE\n\" P PR 14: CHAPTER 11. LIMITED\nNEH6F3 United States |, Georgia US-GA umited Liability manager English manager Mar. 2023-0628 |ACTV LIABILITY COMPANIES -\nof America Company P R,\nGeorgia Limited Liability\nCompany Act § 14-11-101\nCode of Georgia: TITLE\nUnited States 14: CHAPTER 2 BUSINESS\nQHJJAU of America us Georgia US-GA Profit Corporation MFY) officer English officer 2023-06-28 ACTV CORPORATIONS - Georgia\nBusiness Corporation\nCode §14-2-151\nCode of Georgia: TITLE\n\" P PR 14: CHAPTER 11. LIMITED\nU4CGaV United States |, Georgia US-GA umited Liability registered agent English registered agent 2023-06-28 | ACTV LIABILITY COMPANIES -\nof America Company P R,\nGeorgia Limited Liability\nCompany Act § 14-11-209\n71/119\n","contentLength":4118,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.732Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Code of Georgia: TITLE\nUnited States 14: CHAPTER 2 BUSINESS\nUPJEQO of America us Georgia US-GA Profit Corporation MFY) receiver English receiver 2023-06-28 ACTV CORPORATIONS - Georgia\nBusiness Corporation\nCode §14-2-501\nCode of Georgia: TITLE\nUnited States 14: CHAPTER 2 BUSINESS\nWQHOFC of America us Georgia US-GA Profit Corporation MFY) registered agent English registered agent 2023-06-28 ACTV CORPORATIONS - Georgia\nBusiness Corporation\nCode §14-2-501\nCode of Georgia: TITLE\nUnited States 14: CHAPTER 2 BUSINESS\nZZOQER of America us Georgia US-GA Profit Corporation MFY) subscriber English subscriber 2023-06-28 ACTV CORPORATIONS - Georgia\nBusiness Corporation\nCode §14-2-140\nHawaii Revised Statutes:\nTitle 23A TITLE 23A.\nUnited States m Limited Liability \" OTHER BUSINESS\nTKZZTW of America us Hawaii US-HI Company VPBH member English member 2023-06-28 ACTV ENTITIES: Ch.428 -\nUniform Limited Liability\nCompany Act § 428-202\nHawaii Revised Statutes:\nTitle 23A TITLE 23A.\nUnited States m Limited Liability \" OTHER BUSINESS\nEAJBZK of America us Hawaii US-HI Company VPBH trustee English trustee 2023-06-28 ACTV ENTITIES: Ch.428 -\nUniform Limited Liability\nCompany Act § 428-810\nHawaii Revised Statutes:\nTitle 23A TITLE 23A.\nUnited States m Limited Liability \" OTHER BUSINESS\nEPJNHA of America us Hawaii US-HI Company VPBH manager English manager Mar. 2023-06-28 ACTV ENTITIES: Ch.428 -\nUniform Limited Liability\nCompany Act § 428-101\nHawaii Revised Statutes:\nEU9FSY United States ;g Hawaii US-HI Corporation L2qv shareholder English shareholder 2023-0628 |ACTV Title 23: Ch.414 - Hawail\nof America Business Corporation Act\n§414-3\nHawaii Revised Statutes:\nFRSJKD United S_tates us Hawaii US-HI Corporation L2qQv assistant secretary English assistant secretary Asst.Sec. 2023-06-28 |ACTV T'tle_ 23: Ch.414 - !-lawau\nof America Business Corporation Act\n§414-11\nHawaii Revised Statutes:\nGA4RGSG United States ;g Hawaii US-HI Corporation L2qv registered agent English registered agent 2023-0628 |ACTV Title 23: Ch.414 - Hawail\nof America Business Corporation Act\n§414-61\nHawaii Revised Statutes:\nTitle 23A TITLE 23A.\nUnited States m Limited Liability \" \" \" OTHER BUSINESS\nKCXM77 us H US-HI VPBH tered it English tered t 2023-06-28 ACTV\nof America awall Company registerec agen nglls registerec agen ENTITIES: Ch.428 -\nUniform Limited Liability\nCompany Act § 428-107\nHawaii Revised Statutes:\nMFVXZU United States ;g Hawaii US-HI Corporation L2qv officer English officer 2023-0628 |ACTV Title 23: Ch.414 - Hawail\nof America Business Corporation Act\n§414-11\nHawaii Revised Statutes:\nNHBCRQ United States | ;¢ Hawaii US-HI Corporation L2qv president English president Pres. 2023-06-28 | ACTV Title 23: Ch.414 - Hawail\nof America Business Corporation Act\n§414-11\nHawaii Revised Statutes:\nUnited States m . f \" f Title 23: Ch.414 - Hawaii\nNNUYVQ of America us Hawaii US-HI Corporation L2qQv incorporator English incorporator 2023-06-28 ACTV Business Corporation Act\n§414-11, 31\nHawaii Revised Statutes:\nTitle 23A TITLE 23A.\nUnited States m Limited Liability \" \" \" OTHER BUSINESS\nPHMOKI of America us Hawaii US-HI Company VPBH organizer English organizer 2023-06-28 ACTV ENTITIES: Ch.428 -\nUniform Limited Liability\nCompany Act § 428-203\nHawaii Revised Statutes:\nRRSXBU United States | ;¢ Hawaii US-HI Corporation L2qv voting trustee English voting trustee 2023-06-28 | ACTV Title 23: Ch.414 - Hawail\nof America Business Corporation Act\n§414-161\nHawaii Revised Statutes:\nSMMEI3 United States | ;g Hawaii US-HI Corporation L2qQV director English director Dir. 2023-06-28 | ACTV Title 23: Ch.414 - Hawail\nof America Business Corporation Act\n§414-11\nHawaii Revised Statutes:\nUKBPHX United States | ;¢ Hawaii US-HI Corporation L2qv secretary English secretary sec. 2023-06-28 | ACTV Title 23: Ch.414 - Hawail\nof America Business Corporation Act\n§414-3\n72/119\n","contentLength":3845,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.732Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Hawaii Revised Statutes:\nVLTX4R United States ;g Hawaii US-HI Corporation L2qv custodian English custodian 2023-0628 |ACTV Title 23: Ch.414 - Hawail\nof America Business Corporation Act\n§414-413\nHawaii Revised Statutes:\nWKANPQ United States | ;¢ Hawaii US-HI Corporation L2qv receiver English receiver 2023-06-28 | ACTV Title 23: Ch.414 - Hawail\nof America Business Corporation Act\n§414-413\nHawaii Revised Statutes:\nWWIBE3 United States ;g Hawaii US-HI Corporation L2qv chairperson English chairperson ch. 2023-0628 |ACTV Title 23: Ch.414 - Hawail\nof America Business Corporation Act\n§414-11\nHawaii Revised Statutes:\nXGYZLD United States | ;¢ Hawaii US-HI Corporation L2qv subscriber English subscriber 2023-06-28 | ACTV Title 23: Ch.414 - Hawail\nof America Business Corporation Act\n§414-3\nHawaii Revised Statutes:\nXK3UST United States ;g Hawaii US-HI Corporation L2qv beneficial owner English beneficial owner 2023-0628 |ACTV Title 23: Ch.414 - Hawail\nof America Business Corporation Act\n§414-161\nIdaho Statutes: Title 30:\nCh. 29 GENERAL\nUnited States General Business \" \" \" \" BUSINESS\n8GCYDM us Idahs us-ID U9HL directs English directs Dir. 2023-06-28 ACTV\nof America aho Corporation irector gl irector \" CORPORATIONS - Idaho\nBusiness Corporation Act\n30-29-120\nIdaho Statutes: Title 30:\nUnited States Limited Liability \" Ch.25 - Idaho Uniform\nBABARP of America us Idaho US-ID Company RU6X manager English manager Mar. 2023-06-28 ACTV Limited Liability Company\nAct 30-25-102\nIdaho Statutes: Title 30:\nCh. 29 GENERAL\nUnited States General Business \" BUSINESS\nBIDLNV of America us Idaho us-ID Corporation U9HL officer English officer 2023-06-28 ACTV CORPORATIONS - Idaho\nBusiness Corporation Act\n30-29-120\nIdaho Statutes: Title 30:\nCh. 29 GENERAL\nUnited States General Business \" \" \" BUSINESS\nDSIO0] us Idahs us-ID U9HL tered it English tered t 2023-06-28 ACTV\n) of America aho Corporation registerec agen gl registerec agen CORPORATIONS - Idaho\nBusiness Corporation Act\n30-29-120\nIdaho Statutes: Title 30:\nENSCYU United States ) Idaho Us-D Limited Liability RUBX registered agent English registered agent 2023-0628 | ACTV €h.25 - Idaho Uniform\nof America Company Limited Liability Company\nAct 30-25-102\nIdaho Statutes: Title 30:\nCh. 29 GENERAL\nUnited States General Business \" \" \" BUSINESS\nF5XATI of America us Idaho uUs-ID Corporation U9HL subscriber English subscriber 2023-06-28 ACTV CORPORATIONS - Idaho\nBusiness Corporation Act\n30-29-140\nIdaho Statutes: Title 30:\nFIX2PV United States ) Idaho Us-D Limited Liability RUBX member English member 2023-0628 | ACTV €h.25 - Idaho Uniform\nof America Company Limited Liability Company\nAct 30-25-102, 401\nIdaho Statutes: Title 30:\nCh. 29 GENERAL\nUnited States General Business \" \" \" BUSINESS\nGJMz8T of America us Idaho us-ID Corporation U9HL receiver English receiver 2023-06-28 ACTV CORPORATIONS - Idaho\nBusiness Corporation Act\n30-29-120, 748\nIdaho Statutes: Title 30:\nCh. 29 GENERAL\nUnited States General Business \" \" . BUSINESS\nH6QW3X us Idahs us-ID U9HL beneficial sharehold: English beneficial sharehold:s 2023-06-28 ACTV\nQ of America aho Corporation eneficial shareholder gl eneficial shareholder CORPORATIONS - Idaho\nBusiness Corporation Act\n30-29-140\nIdaho Statutes: Title 30:\nCh. 29 GENERAL\nUnited States General Business \" BUSINESS\nHQJLUK of America us Idaho us-ID Corporation U9HL secretary English secretary Sec. 2023-06-28 ACTV CORPORATIONS - Idaho\nBusiness Corporation Act\n30-29-140\nIdaho Statutes: Title 30:\nCh. 29 GENERAL\nUnited States General Business \" \" \" BUSINESS\nHTYBDT of America us Idaho US-ID Corporation U9HL chairman English chairman Ch. 2023-06-28 ACTV CORPORATIONS - Idaho\nBusiness Corporation Act\n30-29-120\nIdaho Statutes: Title 30:\nUnited States Limited Liability . . . Ch.25 - Idaho Uniform\nIOPBR4 of America us Idaho US-ID Company RU6X organizer English organizer 2023-06-28 ACTV Limited Liability Company\nAct 30-25-102, 201\n73/119\n","contentLength":3910,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.733Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Idaho Statutes: Title 30:\nCh. 29 GENERAL\nUnited States General Business f \" f BUSINESS\nJA3UBE of America us Idaho us-ID Corporation U9HL incorporator English incorporator 2023-06-28 ACTV CORPORATIONS - Idaho\nBusiness Corporation Act\n30-29-120\nIdaho Statutes: Title 30:\nCh. 29 GENERAL\nKAWXHC gf\":re‘il_sit;t“ us \\daho US-ID gs:;;f;t?;:'”e“ U9HL voting trust beneficial owner | English voting trust beneficial owner 20230628 |ACTV ggi’:‘g&ifl ONS - 1daho\nBusiness Corporation Act\n30-29-140\nIdaho Statutes: Title 30:\nCh. 29 GENERAL\nUnited States General Business \" \" \" BUSINESS\nLQNLE8 of America us Idaho uUs-ID Corporation U9HL custodian English custodian 2023-06-28 ACTV CORPORATIONS - Idaho\nBusiness Corporation Act\n30-29-748\nIdaho Statutes: Title 30:\nCh. 29 GENERAL\nUnited States General Business \" BUSINESS\nRDUP11 of America us Idaho us-ID Corporation U9HL trustee English trustee 2023-06-28 ACTV CORPORATIONS - Idaho\nBusiness Corporation Act\n30-29-730\nIdaho Statutes: Title 30:\nSUY2KN United States | ;¢ Idaho Us-D Limited Liability RUBX receiver English receiver 2023-06-28 | ACTV €h.25 -Idaho Uniform\nof America Company Limited Liability Company\nAct 30-25-503\nIdaho Statutes: Title 30:\nCh. 29 GENERAL\nUnited States General Business record shareholder \" record shareholder BUSINESS\nVRU4XO of America us Idaho us-b Corporation UOHL (shareholder) English (shareholder) 2023-06-28 |ACTV CORPORATIONS - Idaho\nBusiness Corporation Act\n30-29-140\nIdaho Statutes: Title 30:\nCh. 29 GENERAL\nUnited States General Business e \" \" i \" \" BUSINESS\nYLEC6M us Idahs us-ID U9HL lified direct: English lified direct: 1. Dir. 2023-06-28 ACTV\nof America aho Corporation qualified cirector gl qualified cirector Qual.Dir CORPORATIONS - Idaho\nBusiness Corporation Act\n30-29-143\nIdaho Statutes: Title 30:\nCh. 29 GENERAL\nUnited States General Business \" \" \" BUSINESS\nZKO1BB of America us Idaho uUs-ID Corporation U9HL president English president Pres. 2023-06-28 ACTV CORPORATIONS - Idaho\nBusiness Corporation Act\n30-29-120\nlllinois Compiled Statutes:\nBUSINESS\n5SDAEFW United S.tates us Us-IL Business Corporation AZUK director English director Dir. 2023-06-28 |ACTV ORGANIZAT!ONS (805\nof America ILCS 5/) Business\nCorporation Act of 1983\nSec. 1.10\nlllinois Compiled Statutes:\nBUSINESS\n5QCXYC United S_tates us Us-IL Business Corporation AZUK treasurer English treasurer Treas. 2023-06-28 |ACTV ORGANIZAT!ONS (805\nof America ILCS 5/) Business\nCorporation Act of 1983\nSec. 1.10\nlllinois Compiled Statutes:\nBUSINESS\n9X2H6B United States ;g Us-IL Business Corporation | AZUK president English president Pres. 2023-06-28 | ACTV ORGANIZATIONS (805\nof America ILCS 5/) Business\nCorporation Act of 1983\nSec. 1.10\nlllinois Compiled Statutes:\nBUSINESS\nUnited States Limited Liability \" ORGANIZATIONS (805\nDA7RSS us uUs-IL 8RLE ffi English ffi 2023-06-28 ACTV\nof America Company officer nglls officer ILCS 180/) Limited\nLiability Company Act\nSec. 35-40\nlllinois Compiled Statutes:\nBUSINESS\nUnited States \" . : \" \" : \" ORGANIZATIONS (805\nDRJJ1I of America us US-IL Business Corporation AZUK vice-president English vice-president VP 2023-06-28 ACTV ILCS 5/) Business\nCorporation Act of 1983\nSec. 1.10\nlllinois Compiled Statutes:\nBUSINESS\nE37STS gp::qdeztcaates us US-IL Business Corporation AZUK registered agent English registered agent 2023-06-28 ACTV fizgg’;‘)ifiz:gfi‘;(sos\nCorporation Act of 1983\nSec. 1.80\n74/119\n","contentLength":3383,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.733Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"lllinois Compiled Statutes:\nBUSINESS\nFTszz0 United States | ;g US-IL Business Corporation | AZUK receiver English receiver 2023-06-28 |ACTV ORGANIZATIONS (805\nof America ILCS 5/) Business\nCorporation Act of 1983\nSec. 1.10\nlllinois Compiled Statutes:\nBUSINESS\nGM350L United States ;g Us-IL Business Corporation | AZUK subscriber English subscriber 2023-06-28 | ACTV ORGANIZATIONS (805\nof America ILCS 5/) Business\nCorporation Act of 1983\nSec. 1.80\nlllinois Compiled Statutes:\nBUSINESS\nGX2K9G United States ;g Us-IL Business Corporation | AZUK assistant officer English assistant officer 2023-06-28 | ACTV ORGANIZATIONS (805\nof America ILCS 5/) Business\nCorporation Act of 1983\nSec. 8.50\nlllinois Compiled Statutes:\nBUSINESS\nIHSHJE United States ;g Us-IL Business Corporation [ AZUK receiver English receiver 2023-06-28 |ACTV ORGANIZATIONS (805\nof America ILCS 5/) Business\nCorporation Act of 1983\nSec. 12.60\nlllinois Compiled Statutes:\nBUSINESS\n\" P PR ORGANIZATIONS (805\nUnited Stat Limited Liabilit:\nJaveeqQ nited states ;5 US-IL mited Liability 8RLE chief operating officer English chief operating officer coo 2023-06-28 |ACTV ILCS 180/) Limited\nof America Company PR\nLiability Company Act\nSec. 1-26. Low-profit\nlimited liability company\nlllinois Compiled Statutes:\nBUSINESS\nJ2UKIA gf\":re‘il_sit;t“ us Us-IL Business Corporation | AZUK secretary English secretary Sec. 2023-0628 | ACTV fi’_zg?/‘)'ifiz:gg‘;(sm\nCorporation Act of 1983\nSec. 1.10\nlllinois Compiled Statutes:\nBUSINESS\nKBDWKZ United States ;g Us-IL Business Corporation | AZUK incorporator English incorporator 2023-06-28 | ACTV ORGANIZATIONS (805\nof America ILCS 5/) Business\nCorporation Act of 1983\nSec. 2.05\nlllinois Compiled Statutes:\nBUSINESS\nKUSBDM United S.tates us US-IL Business Corporation AZUK chairman English chairman Ch. 2023-06-28 ACTV ORGANIZAT!ONS (805\nof America ILCS 5/) Business\nCorporation Act of 1983\nSec. 8.11\nlllinois Compiled Statutes:\nBUSINESS\nLHUZJO United S_tates us us-IL. Business Corporation AZUK assistant secretary English assistant secretary Asst.Sec. 2023-06-28 ACTV ORGANIZAT!ONS (805\nof America ILCS 5/) Business\nCorporation Act of 1983\nSec. 1.10\nlllinois Compiled Statutes:\nBUSINESS\nLKV5WY United S.tates us Us-IL Business Corporation AZUK beneficial owner English beneficial owner 2023-06-28 |ACTV ORGANIZAT!ONS (805\nof America ILCS 5/) Business\nCorporation Act of 1983\nSec. 6.40\nlllinois Compiled Statutes:\nBUSINESS\nUnited States Limited Liability \" \" \" ORGANIZATIONS (805\nLNDUFV us uUs-IL 8RLE tered it English tered t 2023-06-28 ACTV\nof America Company registerec agen nglls registerec agen ILCS 180/) Limited\nLiability Company Act\nSec. 1-5\nlllinois Compiled Statutes:\nBUSINESS\nUnited States . Limited Liability \" 06 ORGANIZATIONS (805\nMHCJF7 of America us US-IL Company 8RLE member English member 2023-06-28 ACTV ILCS 180/) Limited\nLiability Company Act\nSec. 1-5\nlllinois Compiled Statutes:\nBUSINESS\nUnited States Limited Liability \" \" \" ORGANIZATIONS (805\nMP8FBC us uUs-IL 8RLE English 2023-06-28 ACTV\nof America Company organizer nglls organizer ILCS 180/) Limited\nLiability Company Act\nSec. 1-5\nlllinois Compiled Statutes:\nBUSINESS\nUnited States . Limited Liability \" \" \" 06 ORGANIZATIONS (805\nMWLVIF of America us US-IL Company 8RLE receiver English receiver 2023-06-28 ACTV ILCS 180/) Limited\nLiability Company Act\nSec. 30-20\n75/119\n","contentLength":3342,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.733Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"lllinois Compiled Statutes:\nBUSINESS\nNVTJPY United States ;g Us-IL Business Corporation | AZUK trustee English trustee 2023-06-28 | ACTV ORGANIZATIONS (805\nof America ILCS 5/) Business\nCorporation Act of 1983\nSec. 1.10\nlllinois Compiled Statutes:\nBUSINESS\n0JBTCO gf\":re‘il_sit;t“ us Us-IL Business Corporation | AZUK liquidating receiver English liquidating receiver 2023-0628 | ACTV fi’_zg?/‘)'ifiz:gg‘;(sm\nCorporation Act of 1983\nSec. 12.60\nlllinois Compiled Statutes:\nBUSINESS\nUnited States \" . P \" P ORGANIZATIONS (805\nouLeD of America us uUS-IL Business Corporation AZUK interested shareholder English interested shareholder 2023-06-28 ACTV ILCS 5/) Business\nCorporation Act of 1983\nSec. 11.75\nlllinois Compiled Statutes:\nBUSINESS\nPCZXED United S.tates us Us-IL Business Corporation AZUK shareholder English shareholder 2023-06-28 |ACTV ORGANIZAT!ONS (805\nof America ILCS 5/) Business\nCorporation Act of 1983\nSec. 1.80\nlllinois Compiled Statutes:\nBUSINESS\n\" P PR ORGANIZATIONS (805\nUnited Stat Limited Liabilit:\nT1igPP nited states ;5 US-IL mited Liability 8RLE director English director Dir. 2023-06-28 |ACTV ILCS 180/) Limited\nof America Company PR\nLiability Company Act\nSec. 1-26. Low-profit\nlimited liability company\nlllinois Compiled Statutes:\nBUSINESS\nUnited States Limited Liability \" ORGANIZATIONS (805\nUDBCUD us uUs-IL 8RLE English Mgr. 2023-06-28 ACTV\nof America Company manager nglls manager or ILCS 180/) Limited\nLiability Company Act\nSec. 1-5\nlllinois Compiled Statutes:\nBUSINESS\nVO5KE2 United States ;g Us-IL Business Corporation | AZUK officer English officer 2023-06-28 | ACTV ORGANIZATIONS (805\nof America ILCS 5/) Business\nCorporation Act of 1983\nSec. 1.10\nlllinois Compiled Statutes:\nBUSINESS\nUnited States Limited Liability \" ORGANIZATIONS (805\nXTZCJF us uUs-IL 8RLE trust: English trust: 2023-06-28 ACTV\n) of America Company rustee nglls rustee ILCS 180/) Limited\nLiability Company Act\nSec. 45-40\nIndiana Code: Title 23.\n\" . it Business and Other\nUnited Stat Limited Liabilit:\n2AMCNS nited states ;5 US-IN mited Liability DQBZ officer English officer 2023-06-28 |ACTV Associations: Art. 18.\nof America Company Limited Liability\nCompanies 23-18-3-2.5\nIndiana Code: Title 23.\nUnited States Business and Other\nBVWIFZ . us US-IN For-Profit Corporation ROBI director English director Dir. 2023-06-28 ACTV Associations: Art.1.\nof America \" \"\nIndiana Business\nCorporation Law 23-1-21\nIndiana Code: Title 23.\n\" . it Business and Other\nHLEDFH United States |, US-IN Limited Liability DQBZ member English member 2023-06-28 | ACTV Associations: Art. 18.\nof America Company Limited Liability\nCompanies 23-18-1\nIndiana Code: Title 23.\nUnited States Business and Other\nHQAMIK of America us US-IN For-Profit Corporation ROBI beneficial owner English beneficial owner 2023-06-28 ACTV Associations: Art.1.\nIndiana Business\nCorporation Law 23-1-20\nIndiana Code: Title 23.\nUnited States Business and Other\nJCABSO of America us US-IN For-Profit Corporation ROBI officer English officer 2023-06-28 ACTV Associations: Art.1.\nIndiana Business\nCorporation Law 23-1-22\nIndiana Code: Title 23.\nUnited States Business and Other\nJDWJXK of America us US-IN For-Profit Corporation ROBI secretary English secretary Sec. 2023-06-28 ACTV Associations: Art.1.\nIndiana Business\nCorporation Law 23-1-20\nIndiana Code: Title 23.\nUnited States Business and Other\nKQORPY of America us US-IN For-Profit Corporation ROBI subscriber English subscriber 2023-06-28 ACTV Associations: Art.1.\nIndiana Business\nCorporation Law 23-1-20\n76/119\n","contentLength":3518,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.733Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Indiana Code: Title 23.\nUnited States Business and Other\nLHFXAJ of America us US-IN For-Profit Corporation ROBI assistant officer English assistant officer 2023-06-28 ACTV Associations: Art.1.\nIndiana Business\nCorporation Law 23-1-36\nIndiana Code: Title 23.\n\" . it Business and Other\nUnited Stat Limited Liabilit:\nLLIYOL nited states ;5 US-IN mitec Liability DQBZ registered agent English registered agent 2023-06-28 |ACTV Associations: Art. 18.\nof America Company P P\nLimited Liability\nCompanies 23-18-9-3\nIndiana Code: Title 23.\nUnited States Business and Other\nPHO29N . us US-IN For-Profit Corporation ROBI custodian English custodian 2023-06-28 ACTV Associations: Art.1.\nof America \" \"\nIndiana Business\nCorporation Law 23-1-48\nIndiana Code: Title 23.\nBusiness and Other\nUnited States . : ; Associations: Art.1.\nT4INHV of America us US-IN For-Profit Corporation ROBI shareholder English shareholder 2023-06-28 ACTV \\ndiana Business\nCorporation Law 23-1-20\nIndiana Code: Title 23.\nUnited States Business and Other\nu8Y2KG of America us US-IN For-Profit Corporation ROBI incorporator English incorporator 2023-06-28 ACTV Associations: Art.1.\nIndiana Business\nCorporation Law 23-1-21\nIndiana Code: Title 23.\nUnited States Business and Other\nYGNHUU of America us US-IN For-Profit Corporation ROBI receiver English receiver 2023-06-28 ACTV Associations: Art.1.\nIndiana Business\nCorporation Law 23-1-47\nIndiana Code: Title 23.\n\" . it Business and Other\nZFBVL United States |, US-IN Limited Liability DQBZ manager English manager Mar. 2023-06-28 | ACTV Associations: Art. 18.\nof America Company P P\nLimited Liability\nCompanies 23-18-1\nCode of lowa: Title XII:\nUnited States Subtitle Il: Ch.490:\n5I5X4F of America us US-1A Profit Corporation Du35 chair English chair Ch. 2023-06-28 ACTV Business Corporations -\nlowa Business\nCorporation Act 490.120\nCode of lowa: Title XII:\nUnited States Subtitle Il: Ch.490:\n5PXY6G of America us US-1A Profit Corporation Du35 shareholder English shareholder 2023-06-28 ACTV Business Corporations -\nlowa Business\nCorporation Act 490.140\nCode of lowa: Title XII:\ncPM13B United States ;o US-IA Limited Liability TXPF member English member 2023-06-28 |ACTV Subtitle Il: Ch.490a - lowa\nof America Company Limited Liability Company\nAct 490A.102\nCode of lowa: Title XII:\nEEDMD3 United States ) Us-IA Limited Liability 7XPF registered agent English registered agent 2023-0628 | ACTV subtitle |I: Ch.490a - lowa\nof America Company Limited Liability Company\nAct 490A.501\nCode of lowa: Title XII:\nUnited States Subtitle Il: Ch.490:\nEZMVYI of America us US-IA Profit Corporation DU35 qualified director English qualified director Qual.Dir. 2023-06-28 |ACTV Business Corporations -\nlowa Business\nCorporation Act 490.143\nCode of lowa: Title XII:\nUnited States Subtitle Il: Ch.490:\nGSGCYV of America us US-IA Profit Corporation DU35 custodian English custodian 2023-06-28 ACTV Business Corporations -\nlowa Business\nCorporation Act 490.748\nCode of lowa: Title XII:\nUnited States : : ; : Sub.tltle I Ch.490:.\nIC)I84 of America us US-IA Profit Corporation DU35 receiver English receiver 2023-06-28 ACTV Business Corporations -\nlowa Business\nCorporation Act 490.120\nCode of lowa: Title XII:\nUnited States Subtitle Il: Ch.490:\nKOMPG3 of America us US-IA Profit Corporation DU35 registered agent English registered agent 2023-06-28 ACTV Business Corporations -\nlowa Business\nCorporation Act 490.501\nCode of lowa: Title XII:\nUnited States Subtitle Il: Ch.490:\nLMESCS of America us US-IA Profit Corporation DU35 governor English governor Gov. 2023-06-28 ACTV Business Corporations -\nlowa Business\nCorporation Act 490.140\nCode of lowa: Title XII:\nUnited States Subtitle Il: Ch.490:\nLO6GBU of America us US-IA Profit Corporation DU35 voting trust beneficial owne English voting trust beneficial owne 2023-06-28 ACTV Business Corporations -\nlowa Business\nCorporation Act 490.140\n77/119\n","contentLength":3888,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.733Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Code of lowa: Title XII:\nNBznDw [United States ;g Us-IA Limited Liability 7XPF manager English manager Mar. 2023-0628 | ACTV subtitle |I: Ch.490a - lowa\nof America Company Limited Liability Company\nAct 490A.102\nCode of lowa: Title XII:\nUnited States Subtitle Il: Ch.490:\nNKWIPN of America us US-IA Profit Corporation DU35 beneficial shareholder English beneficial shareholder 2023-06-28 ACTV Business Corporations -\nlowa Business\nCorporation Act 490.140\nCode of lowa: Title XII:\nUnited States Subtitle Il: Ch.490:\nQDCUX4 of America us US-IA Profit Corporation DU35 record shareholder English record shareholder 2023-06-28 ACTV Business Corporations -\nlowa Business\nCorporation Act 490.140\nCode of lowa: Title XII:\nUnited States Subtitle Il: Ch.490:\nQRIKPH of America us US-IA Profit Corporation DU35 director English director Dir. 2023-06-28 ACTV Business Corporations -\nlowa Business\nCorporation Act 490.143\nCode of lowa: Title XII:\nUnited States Subtitle Il: Ch.490:\nSEX3A1 of America us US-IA Profit Corporation DU35 officer English officer 2023-06-28 ACTV Business Corporations -\nlowa Business\nCorporation Act 490.120\nCode of lowa: Title XII:\nSubtitle Il: Ch.490:\nUnited States . : Business Corporations -\nSVKCHI of America us US-IA Profit Corporation DU35 secretary English secretary Sec. 2023-06-28 ACTV lowa Business\nCorporation Act 490.140\nCode of lowa: Title XII:\nUnited States : ; Sub.tltle I Ch.490:.\nWQTCSD of America us US-IA Profit Corporation DU35 trustee English trustee 2023-06-28 ACTV Business Corporations -\nlowa Business\nCorporation Act 490.120\nCode of lowa: Title XII:\nUnited States Subtitle Il: Ch.490:\nWUR214 of America us US-IA Profit Corporation DU35 incorporator English incorporator 2023-06-28 ACTV Business Corporations -\nlowa Business\nCorporation Act 490.201\nCode of lowa: Title XII:\nUnited States Subtitle Il: Ch.490:\nXP0375 of America us US-IA Profit Corporation DU35 subscriber English subscriber 2023-06-28 ACTV Business Corporations -\nlowa Business\nCorporation Act 490.140\nCode of lowa: Title XII:\nUnited States Subtitle Il: Ch.490:\nXSTVFA of America us US-IA Profit Corporation DU35 president English president Pres. 2023-06-28 ACTV Business Corporations -\nlowa Business\nCorporation Act 490.120\nCode of lowa: Title XII:\nUnited States Subtitle Il: Ch.490:\nYFTH4U of America us US-IA Profit Corporation DU35 interest holder English interest holder 2023-06-28 ACTV Business Corporations -\nlowa Business\nCorporation Act 490.140\nKansas Statutes: Chapter\n\" P PR 17: Art.76 Limited Liability\nUnited Stat Limited Liabilit:\n119H7Y nited states ;5 USs-ks mited Liability FBNO liquidating trustee English liquidating trustee 2023-06-28 |ACTV Companies - Kansas\nof America Company . P A\nrevised limited liability\ncompany act 17-7697\nKansas Statutes: Chapter\n\" P PR 17: Art.76 Limited Liability\n8ETOCF United States |, US-KS umited Liability FBNO resident agent English resident agent 2023-06-28 | ACTV Companies - Kansas\nof America Company . P o\nrevised limited liability\ncompany act 17-7667\nKansas Statutes: Chapter\n\" P PR 17: Art.76 Limited Liability\nFCTLAU United States |, US-KS umited Liability FBNO member English member 2023-0628 |ACTV Companies - Kansas\nof America Company . P o\nrevised limited liability\ncompany act 17-7663\nKansas Statutes: Chapter\n\" P PR 17: Art.76 Limited Liability\nT20)W United States |, US-KS umited Liability FBNO manager English manager Mar. 2023-06-28 | ACTV Companies - Kansas\nof America Company . P o\nrevised limited liability\ncompany act 17-7663\nKansas Statutes: Chapter\n\" P PR 17: Art.76 Limited Liability\nZULT4P United States |, US-KS umited Liability FBNO officer English officer 2023-0628 |ACTV Companies - Kansas\nof America Company . P o\nrevised limited liability\ncompany act 17-7697\n78/119\n","contentLength":3756,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.734Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Kentucky Revised\nStatutes: Title XXIlI:\n1RNBCC United States ;g Kentucky US-KY Limited Liability F2QV member English member 2023-06-28 | ACTV Ch.275 Limited Liability\nof America Company (profit) Companies - Kentucky\nLimited Liability Company\nAct 275.016\nKentucky Revised\nStatutes: Title XXIlI:\nUnited States Limited Liability \" \" \" Ch.275 Limited Liability\n7UIU8P us Kentuck: US-KY F2Qv tered it English tered t 2023-06-28 ACTV\nof America entucky Company (profit) Q registerec agen nglls registerec agen Companies - Kentucky\nLimited Liability Company\nAct 275.115\nKentucky Revised\nStatutes: Title XXIlI:\nAOXILY United States ;g Kentucky US-KY Corporation (profit) QWPR beneficial owner English beneficial owner 2023-06-28 | ACTV Ch.271B Business\nof America Corporations - Kentucky\nBusiness Corporation Act\n271B.7-230\nKentucky Revised\nStatutes: Title XXIlI:\nB3HDCI United States ) Kentucky US-KY Corporation (profit) QWPR custodian English custodian 2023-0628 | ACTV Ch-271B Business\nof America Corporations - Kentucky\nBusiness Corporation Act\n271B.14-310\nKentucky Revised\nStatutes: Title XXIlI:\nDpYMCOT United States ) Kentucky US-KY Corporation (profit) QWPR incorporator English incorporator 2023-0628 | ACTV Ch-271B Business\nof America Corporations - Kentucky\nBusiness Corporation Act\n271B.2-010\nKentucky Revised\nStatutes: Title XXIlI:\nGGPGPY United States | ;g Kentucky US-KY Corporation (profit) QWPR director English director Dir. 2023-06-28 |ACTV Ch.2718 Business\nof America Corporations - Kentucky\nBusiness Corporation Act\n271B.2-050\nKentucky Revised\nStatutes: Title XXIlI:\nIGQ6EPY United States ;¢ Kentucky US-KY Corporation (profit) QWPR assistant officer English assistant officer 2023-06-28 |ACTV Ch.271B Business\nof America Corporations - Kentucky\nBusiness Corporation Act\n271B.8-400\nKentucky Revised\nStatutes: Title XXIlI:\nUnited States . \" Ch.271B Business\nIVNVJJ of America us Kentucky US-KY Corporation (profit) QWPR shareholder English shareholder 2023-06-28 ACTV Corporations - Kentucky\nBusiness Corporation Act\n271B.1-400\nKentucky Revised\nStatutes: Title XXIlI:\nJK8BY3 United States ) Kentucky US-KY Corporation (profit) QWPR subscriber English subscriber 2023-0628 | ACTV Ch-271B Business\nof America Corporations - Kentucky\nBusiness Corporation Act\n271B.1-400\nKentucky Revised\nStatutes: Title XXIlI:\nUnited States . \" \" . Ch.271B Business\nMV2RDD of America us Kentucky US-KY Corporation (profit) QWPR voting trustee English voting trustee 2023-06-28 ACTV Corporations - Kentucky\nBusiness Corporation Act\n271B.7-300\nKentucky Revised\nStatutes: Title XXIlI:\nUnited States . Limited Liability \" 06 Ch.275 Limited Liability\nP9P4ANX of America us Kentucky US-KY Company (profit) F2Qv manager English manager Mar. 2023-06-28 ACTV Companies - Kentucky\nLimited Liability Company\nAct 275.015\nKentucky Revised\nStatutes: Title XXIlI:\nQUOTOF United States | ;g Kentucky US-KY Corporation (profit) QWPR receiver English receiver 2023-06-28 |ACTV Ch.271B Business\nof America Corporations - Kentucky\nBusiness Corporation Act\n271B.14-310\nKentucky Revised\nStatutes: Title XXIlI:\nUnited States . Limited Liability \" \" \" 06 Ch.275 Limited Liability\nRAKOEH of America us Kentucky US-KY Company (profit) F2Qv organizer English organizer 2023-06-28 ACTV Companies - Kentucky\nLimited Liability Company\nAct 275.020\nKentucky Revised\nStatutes: Title XXIlI:\nUnited States . \" Ch.271B Business\nRJAGB6 of America us Kentucky US-KY Corporation (profit) QWPR secretary English secretary Sec. 2023-06-28 ACTV Corporations - Kentucky\nBusiness Corporation Act\n271B.1-400\n79/119\n","contentLength":3563,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.734Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Kentucky Revised\nStatutes: Title XXIlI:\nUnited States . \" Ch.271B Business\nUVGAX8 of America us Kentucky US-KY Corporation (profit) QWPR officer English officer 2023-06-28 ACTV Corporations - Kentucky\nBusiness Corporation Act\n271B.6-240\nKentucky Revised\nStatutes: Title XXIlI:\nZ8AVL) gp:s\\deitca;es us Kentucky US-KY Corporation (profit) QWPR registered agent English registered agent 2023-06-28 |ACTV E:}f:z;:afltigfi???(seitucky\nBusiness Corporation Act\n271B.5-010\nLouisiana Revised\nUnited States Statutes: Title 12\n35QB3T of America us Louisiana US-LA Domestic Corporation record shareholder English record shareholder 2023-06-28 ACTV Corporations and\nAssociations: Business\nCorporation Act - §1-140\nLouisiana Revised\nUnited States . : : . ; . Statutes:. Title 12\n5GXISI of America us Louisiana US-LA Domestic Corporation president English president 2023-06-28 ACTV Corporations and\nAssociations: Business\nCorporation Act - §1-120\nLouisiana Revised\nUnited States Statutes: Title 12\nBBSOOW of America us Louisiana US-LA Domestic Corporation voting trust beneficial owner English voting trust beneficial owner 2023-06-28 ACTV Corporations and\nAssociations: Business\nCorporation Act - §1-140\nLouisiana Revised\nUnited States . Domestic Limited \" \" \" Statutes: Title 12: 1301:\nGKUQOS of America us Louisiana US-LA Liability Company CD90 registered agent English registered agent 2023-06-28 ACTV Ch.22 Limited Liability\nCompanies §1308\nLouisiana Revised\nUnited States Statutes: Title 12\nGVXRYK of America us Louisiana US-LA Domestic Corporation liquidator English liquidator 2023-06-28 ACTV Corporations and\nAssociations: Business\nCorporation Act - §1-1432\nLouisiana Revised\nUnited States . Domestic Limited \" Statutes: Title 12: 1301:\nGXD9EA us L US-LA CD90 English Mgr. 2023-06-28 ACTV\nof America ouisiana Liability Company manager nglls manager or Ch.22 Limited Liability\nCompanies §1301\nLouisiana Revised\n) Statutes: Title 12\nIDLEML United States ;g Louisiana US-LA Domestic Corporation officer English officer 2023-06-28 |ACTV Corporations and\nof America Associations: Business\nCorporation Act - §1-120\nLouisiana Revised\nUnited States . Domestic Limited P \" P P Statutes: Title 12: 1301:\nJBMX3R of America us Louisiana US-LA Liability Company CD90 liquidator English liquidator Lig. 2023-06-28 ACTV Ch.22 Limited Liability\nCompanies §1336\nLouisiana Revised\nUnited States Statutes: Title 12\nLMFSBU of America us Louisiana US-LA Domestic Corporation beneficial shareholder English beneficial shareholder 2023-06-28 ACTV Corporations and\nAssociations: Business\nCorporation Act - §1-140\nLouisiana Revised\nUnited States Statutes: Title 12\nONNJRJ of America us Louisiana US-LA Domestic Corporation registered agent English registered agent 2023-06-28 ACTV Corporations and\nAssociations: Business\nCorporation Act - §1-120\nLouisiana Revised\nUnited States Statutes: Title 12\nPVC6UJ of America us Louisiana US-LA Domestic Corporation incorporator English incorporator 2023-06-28 ACTV Corporations and\nAssociations: Business\nCorporation Act - §1-120\nLouisiana Revised\nUnited States Statutes: Title 12\nRHQDPL of America us Louisiana US-LA Domestic Corporation receiver English receiver 2023-06-28 ACTV Corporations and\nAssociations: Business\nCorporation Act - §1-1432\nLouisiana Revised\nUnited States . Domestic Limited \" Statutes: Title 12: 1301:\nTOYG)Y of America us Louisiana US-LA Liability Company CD90 member English member 2023-06-28 ACTV Ch.22 Limited Liability\nCompanies §1301\nLouisiana Revised\nUnited States - ) . . . i Statutes:. Title 12\nTFUSYH of America us Louisiana US-LA Domestic Corporation director English director 2023-06-28 ACTV Corporations and\nAssociations: Business\nCorporation Act - §1-120\nLouisiana Revised\nUnited States Statutes: Title 12\nUXEPDD of America us Louisiana US-LA Domestic Corporation voting trustee English voting trustee 2023-06-28 ACTV Corporations and\nAssociations: Business\nCorporation Act - §1-730\n80/119\n","contentLength":3937,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.734Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"23 MAART 2019. — Wet\ntot invoering van het\nWetboek van\nvennootschappen en\nPNPDW1 Belgium Naamloze vennootschap | R85P Lid van raad van toezicht Dutch Lid van raad van toezicht 2023-06-28 ACTV verenigingen en\nhoudende diverse\nbepalingen - BOEK 7:\nTITEL 4: HOOFDSTUK 1:\nArt.7:104\n23 MARZ 2019. —\nPNPDW1 Belgium Aktiengesellschaft R85P Aufsichtsratsmitglied German Aufsichtsratsmitglied 2023-06-28 [ACTV Gesetzbuch der\nGesellschaften und\nVereinigungen\n23 MAART 2019. — Wet\ntot invoering van het\nWetboek van\nvennootschappen en\nPQEFRO Belgium Besloten Vennootschap |3W7E Obligatiehouder Dutch Obligatiehouder 2023-06-28 ACTV verenigingen en\nhoudende diverse\nbepalingen - BOEK 5:\nTITEL 1: HOOFDSTUK 2:\nArt.5:27.1\n23 MARS 2019. — Loi\nintroduisant le Code des\nAP o sociétés et des\nPQEFRO Belgium fi:.’f.'tif aresponsabilité |, .0 Obligataire French fr Obligataire 2023-0628 |ACTV assodiations et portant\ndes dispositions diverses -\nLivre 5: Titre 1: CHAPITRE\n2: Art. 5:27:1\n23 MARZ 2019. —\nPQEFRO Belgium Gesellschaft mit 3W7E Anleiheinhaber German Anleiheinhaber 2023-06-28 |ACTV Gesetzbuch der\nbeschrankter Haftung Gesellschaften und\nVereinigungen\n23 MARS 2019. — Loi\nintroduisant le Code des\n- sociétés et des\nQCeKMP Belgium fijfi‘;i:?“on sans but W3WH Associé French fr Associé 2023-06-28 |ACTV associations et portant\ndes dispositions diverses -\nPARTIE 1re: LIVRE ler:\nTITRE ler: Art. 1:1\n23 MAART 2019. — Wet\ntot invoering van het\nWetboek van\nQCCKMP Belgium Vereniging zonder W3WH Vennoot Dutch Vennoot 2023-06-28 |ACTV vennootschappen en\nwinstoogmerk verenigingen en\nhoudende diverse\nbepalingen - TITEL 1:\nHOOFDSTUK 1: Art.1:1\n23 MARZ 2019. —\nQCCKMP Belgium Vereinigung ohne |,y 3y Gesellschafter German Gesellschafter 2023-0628 |ACTV Gesetzbuch der\nGewinnerzielungsabsicht Gesellschaften und\nVereinigungen\n23 MAART 2019. — Wet\ntot invoering van het\nWetboek van\nvennootschappen en\nQMTCGJ Belgium Besloten Vennootschap |3W7E Bestuurder Dutch Bestuurder 2023-06-28 ACTV verenigingen en\nhoudende diverse\nbepalingen - BOEK 5:\nTITEL 4: HOOFDSTUK 1:\nArt.5:73.1\n23 MARS 2019. — Loi\nintroduisant le Code des\nAP o sociétés et des\nQMTCG) Belgium fi:.’f.'tif aresponsabilité |5, ¢ Administrateur French fr Administrateur 2023-06-28 |ACTV assodiations et portant\ndes dispositions diverses -\nLivre 5: Titre 4: CHAPITRE\n1 Art. 5:73:1\n23 MARZ 2019. —\n\" Gesellschaft mit Gesetzbuch der\nMTCG, Bel 3W7E Vi It G Vi It 2023-06-28 ACTV\nQ ) elgium beschrankter Haftung erwaiter erman erwaiter Gesellschaften und\nVereinigungen\n23 MARS 2019. — Loi\nintroduisant le Code des\nsociétés et des\nQRWQDE Belgium Société anonyme R85P Administrateur French fr Administrateur 2023-06-28 |ACTV associations et portant\ndes dispositions diverses -\nLivre 7: Titre 4: CHAPITRE\n1: Art. 7:104\n9/119\n","contentLength":2753,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.734Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Louisiana Revised\nUnited States Statutes: Title 12\nVNYBYA of America us Louisiana US-LA Domestic Corporation secretary English secretary 2023-06-28 ACTV Corporations and\nAssociations: Business\nCorporation Act - §1-140\nLouisiana Revised\nUnited States Statutes: Title 12\nW4XH8W of America us Louisiana US-LA Domestic Corporation qualified director English qualified director 2023-06-28 ACTV Corporations and\nAssociations: Business\nCorporation Act - §1-140\nLouisiana Revised\nUnited States . : : \" ; : Statutes:. Title 12\nW5KI2E of America us Louisiana US-LA Domestic Corporation chairman English chairman 2023-06-28 ACTV Corporations and\nAssociations: Business\nCorporation Act - §1-120\nLouisiana Revised\nUnited States Statutes: Title 12\nYBCAEA of America us Louisiana US-LA Domestic Corporation subscriber English subscriber 2023-06-28 ACTV Corporations and\nAssociations: Business\nCorporation Act - §1-140\nLouisiana Revised\nUnited States Statutes: Title 12\nZCBHX4 of America us Louisiana US-LA Domestic Corporation shareholder English shareholder 2023-06-28 ACTV Corporations and\nAssociations: Business\nCorporation Act - §1-140\nLouisiana Revised\nUnited States Statutes: Title 12\nZZUTND of America us Louisiana US-LA Domestic Corporation interest holder English interest holder 2023-06-28 ACTV Corporations and\nAssociations: Business\nCorporation Act - §1-140\nMaine Revised Statutes:\n3JMPZR United States | ;¢ US-ME Business Corporation | TTB4 assistant officer English assistant officer 2023-06-28 | ACTV Title 13-C - Maine\nof America Business Corporation Act\n§841\nMaine Revised Statutes:\nAYFAT United States | ;g US-ME Business Corporation | TTB3 director English director Dir. 2023-06-28 | ACTV Title 13-C - Maine\nof America Business Corporation Act\n§205\nMaine Revised Statutes:\nBBXFRZ United States | ;¢ US-ME Business Corporation | TTB3 receiver English receiver 2023-06-28 | ACTV Title 13-C - Maine\nof America Business Corporation Act\n§121\nMaine Revised Statutes:\ncM)B3B United States | ;g US-ME Business Corporation | TTB3 clerk English clerk 2023-06-28 |ACTV Title 13-C - Maine\nof America Business Corporation Act\n§511\nMaine Revised Statutes:\nUnited States Title 13-C - Maine\nFJULMM of America us US-ME Business Corporation TTB3 incorporator English incorporator 2023-06-28 ACTV Business Corporation Act\n§121\nMaine Revised Statutes:\nFKHM1U United States | ;g US-ME Business Corporation | TTB3 interest holder English interest holder 2023-06-28 | ACTV Title 13-C - Maine\nof America Business Corporation Act\n§102\nMaine Revised Statutes:\n\" P PR Title 31: Ch.21 Limited\nHDTQOV United States |, US-ME Limited Liability 53DC officer English officer 2023-06-28 | ACTV Liabiity Companies -\nof America Company . R PN\nMaine Limited Liability\nCompany Act § 1560\nMaine Revised Statutes:\nKXJDRC United States ;g US-ME Business Corporation | TTB3 president English president Pres. 2023-0628 |ACTV Title 13-C - Maine\nof America Business Corporation Act\n§121, 842\nMaine Revised Statutes:\n\" P PR Title 31: Ch.21 Limited\nMRVLUG United States |, US-ME umited Liability 53DC secretary English secretary Sec. 2023-0628 |ACTV Liabiity Companies -\nof America Company . R P\nMaine Limited Liability\nCompany Act § 1560\nMaine Revised Statutes:\nUnited States Title 13-C - Maine\nP9ZQLF of America us US-ME Business Corporation TTB3 registered agent English registered agent 2023-06-28 ACTV Business Corporation Act\n§ 512 - referring to Title\n5, sec. 113\nMaine Revised Statutes:\nPB4E12 United States ;o US-ME Business Corporation | TTB3 shareholder English shareholder 2023-06-28 |ACTV Title13-C - Maine\nof America Business Corporation Act\n§102\nMaine Revised Statutes:\n\" P PR Title 31: Ch.21 Limited\nUnited Stat Limited Liabilit:\nPMHOX4 nited states ;5 US-ME mited Liability 53DC member English member 2023-06-28 |ACTV Liabiity Companies -\nof America Company \" P P\nMaine Limited Liability\nCompany Act § 1502\n81/119\n","contentLength":3889,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.734Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Maine Revised Statutes:\nRAPRTG United States ;g US-ME Business Corporation | TTB3 chair English chair ch. 2023-0628 |ACTV Title 13-C - Maine\nof America Business Corporation Act\n§121\nMaine Revised Statutes:\nTitle 31: Ch.21 Limited\nUnited States Limited Liability \" \" \" Liabiity Companies -\nRYQYMO us US-ME 53DC tered it English tered t 2023-06-28 ACTV\nQ of America Company registerec agen nglls registerec agen Maine Limited Liability\nCompany Act § 1592,\n1661\nMaine Revised Statutes:\nS1SFEU United States ;g US-ME Business Corporation | TTB3 officer English officer 2023-0628 |ACTV Title 13-C - Maine\nof America Business Corporation Act\n§121\nMaine Revised Statutes:\n\" P PR Title 31: Ch.21 Limited\nSZBHWO United States |, US-ME umited Liability 53DC director English director Dir. 2023-0628 |ACTV Liabiity Companies -\nof America Company . R P\nMaine Limited Liability\nCompany Act § 1560\nMaine Revised Statutes:\n\" P PR Title 31: Ch.21 Limited\nUNEHSF United States |, US-ME umited Liability 53DC treasurer English treasurer Treas. 2023-06-28 | ACTV Liabiity Companies -\nof America Company . R P\nMaine Limited Liability\nCompany Act § 1560\nMaine Revised Statutes:\nV6NYCE United States ;g US-ME Business Corporation | TTB3 member English member 2023-0628 |ACTV Title 13-C - Maine\nof America Business Corporation Act\n§102\nMaine Revised Statutes:\nXNZYYQ United States ;g US-ME Business Corporation | TTB3 subscriber English subscriber 2023-06-28 | ACTV Title 13-C - Maine\nof America Business Corporation Act\n§102\nMaine Revised Statutes:\nZGZDBM United States | ;g US-ME Business Corporation | TTB3 qualified director English qualified director Qual.Dir. 2023-06-28 |ACTV Title 13-C - Maine\nof America Business Corporation Act\n§102\nMaryland Code:\nUnited States Corporations and\n08X2MA of America us Maryland US-MD Stock Corporation HLRS officer English officer 2023-06-28 ACTV Associations: Titles 1-3 -\nMaryland General\nCorporation Law §1-301\nMaryland Code:\nCorporations and\n3Q15T1 United States ) Maryland Us-MD Stock Corporation HLR4 secretary English secretary Sec. 2023-0628 | ACTV Associations: Titles 1-3 -\nof America Maryland General\nCorporation Law §1-301,\n2-412\nMaryland Code:\nUnited States Corporations and\n5BOGMT . us Maryland US-MD Stock Corporation HLR4 vice-chairman English vice-chairman 2023-06-28 ACTV Associations: Titles 1-3 -\nof America\nMaryland General\nCorporation Law §1-301\nMaryland Code:\n) Corporations and\n70500M United States | Maryland Us-MD Stock Corporation HLR4 assistant treasurer English assistant treasurer 20230628 | ACTV Assodations: Titles 1.3 -\nof America Maryland General\nCorporation Law §1-301\nMaryland Code:\nUnited States Corporations and\n7QS1GT of America us Maryland US-MD Stock Corporation HLR4 director English director Dir. 2023-06-28 ACTV Associations: Titles 1-3 -\nMaryland General\nCorporation Law §1-101\nMaryland Code:\nUnited States Corporations and\n9CRVO) of America us Maryland US-MD Stock Corporation HLR4 chairman English chairman Ch. 2023-06-28 ACTV Associations: Titles 1-3 -\nMaryland General\nCorporation Law §1-301\nMaryland Code:\nUnited States Corporations and\nBUTBO8 of America us Maryland US-MD Stock Corporation HLR4 chief executive officer English chief executive officer CEO 2023-06-28 ACTV Associations: Titles 1-3 -\nMaryland General\nCorporation Law §1-301\nMaryland Code:\nUnited States Corporations and\nJPPMPO of America us Maryland US-MD Stock Corporation HLR4 assistant secretary English assistant secretary Asst.Sec. 2023-06-28 ACTV Associations: Titles 1-3 -\nMaryland General\nCorporation Law §1-301\nMaryland Code:\nCorporations and\nLPTGBT United States ) Maryland Us-MD Stock Corporation HLR4 treasurer English treasurer Treas. 2023-0628 | ACTV Associations: Titles 1-3 -\nof America Maryland General\nCorporation Law §1-301,\n2-412\n82/119\n","contentLength":3790,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.734Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Maryland Code:\nUnited States Corporations and\nMO6A7C . us Maryland US-MD Stock Corporation HLR6 subscriber English subscriber 2023-06-28 ACTV Associations: Titles 1-3 -\nof America\nMaryland General\nCorporation Law §2-215\nMaryland Code:\n; - PR Corporations and\nUnited Stat Limited Liabilit:\nMYKFT3 nited states ;5 Maryland US-MD mited Liability Jlom member English member 2023-06-28 |ACTV Associations: Title 4A\nof America Company P o\nLimited Liability Company\nAct § 4A-101\nMaryland Code:\nUnited States Corporations and\nNXT8AY . us Maryland US-MD Stock Corporation HLR4 stockholder English stockholder 2023-06-28 ACTV Associations: Titles 1-3 -\nof America\nMaryland General\nCorporation Law §1-301\nMaryland Code:\nUnited States Corporations and\nOBOXXW . us Maryland US-MD Stock Corporation HLR4 receiver English receiver 2023-06-28 ACTV Associations: Titles 1-3 -\nof America\nMaryland General\nCorporation Law §2-215\nMaryland Code:\nUnited States Corporations and\nPTUSKX of America us Maryland US-MD Stock Corporation HLR4 chief operating officer English chief operating officer [ee]e] 2023-06-28 ACTV Associations: Titles 1-3 -\nMaryland General\nCorporation Law §1-301\nMaryland Code:\n; - PR Corporations and\nPYJ4WA United States |, Maryland US-MD umited Liability Jjom resident agent English resident agent 2023-0628 |ACTV Associations: Title 4A\nof America Company P P\nLimited Liability Company\nAct § 4A-210\nMaryland Code:\nUnited States Corporations and\nRGERZA of America us Maryland US-MD Stock Corporation HLR4 chief financial officer English chief financial officer CFO 2023-06-28 ACTV Associations: Titles 1-3 -\nMaryland General\nCorporation Law §1-301\nMaryland Code:\nUnited States Corporations and\nSSOBZ3 of America us Maryland US-MD Stock Corporation HLR4 vice president English vice president VP 2023-06-28 ACTV Associations: Titles 1-3 -\nMaryland General\nCorporation Law §1-301\nMaryland Code:\nCorporations and\nTXRERL United States | ;¢ Maryland US-MD Stock Corporation HLR4 president English president Pres. 20230628 |ACTV Assodations: Titles 1-3 -\nof America Maryland General\nCorporation Law §1-301,\n2-412\nMaryland Code:\nUnited States Corporations and\nXGPQKU of America us Maryland US-MD Stock Corporation HLR4 resident agent English resident agent 2023-06-28 ACTV Associations: Titles 1-3 -\nMaryland General\nCorporation Law §1-102\nGeneral Laws: Part 1: Title\n\" . \" XXII: Ch.156D Business\nUnited Stat D tic B\n5SMCJR nited States ;g Massachusetts |US-MA omestic Business 2Tk receiver English receiver 20230628 |ACTV Corporations -\nof America Corporation .\nMassachusetts Business\nCorporation Act 5.14.32\nGeneral Laws: Part 1: Title\n7MZKOU United States | ;g Massachusetts |US-MA Uimited Liability BYFU manager English manager Mar. 2023-06-28 |ACTV XXII: Ch156C-\nof America Company Massachusetts Limited\nLiability Company Act 5.2\nGeneral Laws: Part 1: Title\nUnited States Domestic Business XXIl: Ch.156D Business\n7VX7DW of America us Massachusetts | US-MA Corporation ZJTK custodian English custodian 2023-06-28 ACTV Corporations -\nMassachusetts Business\nCorporation Act 5.14.32\nGeneral Laws: Part 1: Title\n\" . \" XXII: Ch.156D Business\nUnited Stat D tic B\n95YGWE nited States ;g Massachusetts |US-MA omestic Business 2Tk treasurer English treasurer Treas. 20230628 |ACTV Corporations -\nof America Corporation .\nMassachusetts Business\nCorporation Act 5.8.40\nGeneral Laws: Part 1: Title\n\" . \" XXII: Ch.156D Business\nUnited Stat D tic B\nBOFJAC nited States ;g Massachusetts |US-MA omestic Business 2Tk beneficial owner English beneficial owner 2023-0628 | ACTV Corporations -\nof America Corporation .\nMassachusetts Business\nCorporation Act 5.7.23\nGeneral Laws: Part 1: Title\n\" . \" XXII: Ch.156D Business\nUnited Stat D tic B\nEHF4DS nited states ;5 Massachusetts |US-MA omestic Business 2Tk secretary English secretary Sec. 2023-06-28 |ACTV Corporations -\nof America Corporation .\nMassachusetts Business\nCorporation Act s.1.40\n83/119\n","contentLength":3926,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.735Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"General Laws: Part 1: Title\n\" . \" XXII: Ch.156D Business\nUnited Stat D tic B\nFOATLL nited States ;g Massachusetts |US-MA omestic Business 2Tk president English president Pres. 20230628 |ACTV Corporations -\nof America Corporation .\nMassachusetts Business\nCorporation Act 5.8.40\nGeneral Laws: Part 1: Title\n\" . \" XXII: Ch.156D Business\nUnited Stat D tic B\nGSMGKA nited States ;g Massachusetts |US-MA omestic Business 2Tk incorporator English incorporator 20230628 |ACTV Corporations -\nof America Corporation .\nMassachusetts Business\nCorporation Act 5.2.01\nGeneral Laws: Part 1: Title\n\" . \" XXII: Ch.156D Business\nUnited Stat D tic B\nHXVMS 7 nited States ;g Massachusetts |US-MA omestic Business 2Tk director English director Dir. 20230628 |ACTV Corporations -\nof America Corporation .\nMassachusetts Business\nCorporation Act 5.7.28\nGeneral Laws: Part 1: Title\n\" . \" XXII: Ch.156D Business\nUnited Stat D tic B\nM2FJY) nited States ;g Massachusetts |US-MA omestic Business 2Tk shareholder English shareholder 20230628 |ACTV Corporations -\nof America Corporation .\nMassachusetts Business\nCorporation Act s.1.40\nGeneral Laws: Part 1: Title\nUnited States Voluntary Association \" XXII: Ch.182 VOLUNTARY\nMUTROU of America us Massachusetts |US-MA and Business Trusts Z73Z2 trustee English trustee 2023-06-28 ACTV ASSOCIATIONS AND\nCERTAIN TRUSTS s.2\nGeneral Laws: Part 1: Title\n\" . \" XXII: Ch.156D Business\nUnited Stat D tic B\nNODHMC nited States ;g Massachusetts |US-MA omestic Business 2Tk assistant officer English assistant officer 2023-0628 | ACTV Corporations -\nof America Corporation .\nMassachusetts Business\nCorporation Act 5.8.40\nGeneral Laws: Part 1: Title\nPVJBOE United States | ;g Massachusetts |US-MA Uimited Liability BYFU resident agent English resident agent 2023-06-28 |ACTV XXII: Ch156C-\nof America Company Massachusetts Limited\nLiability Company Act s.5\nGeneral Laws: Part 1: Title\n\" . \" XXII: Ch.156D Business\nQDKC3R United States |, Massachusetts |US-MA Domestic Business 27K assistant secretary English assistant secretary Asst.Sec. 2023-06-28 | ACTV Corporations -\nof America Corporation .\nMassachusetts Business\nCorporation Act 5.8.40\nGeneral Laws: Part 1: Title\n\" . \" XXII: Ch.156D Business\nUnited States Domestic Business \" \" \" .\nQE6TLO of America us Massachusetts | US-MA Corporation ZJTK subscriber English subscriber 2023-06-28 ACTV Corporations - )\nMassachusetts Business\nCorporation Act s.1.40\nGeneral Laws: Part 1: Title\n\" . \" XXII: Ch.156D Business\nTM3AYZ United States |, Massachusetts |US-MA Domestic Business 27K registered agent English registered agent 2023-06-28 | ACTV Corporations -\nof America Corporation .\nMassachusetts Business\nCorporation Act 5.5.01\nGeneral Laws: Part 1: Title\nTUYTCQ United States | ;g Massachusetts |US-MA Limited Liability BYFU member English member 2023-06-28 |ACTV XXIi: Ch.156C-\nof America Company Massachusetts Limited\nLiability Company Act 5.2\nGeneral Laws: Part 1: Title\n\" . \" XXII: Ch.156D Business\nUnited Stat D tic B\nWNHJHM nited States ;g Massachusetts |US-MA omestic Business 2Tk interest holder English interest holder 2023-0628 | ACTV Corporations -\nof America Corporation .\nMassachusetts Business\nCorporation Act s.1.40\nGeneral Laws: Part 1: Title\n\" . \" XXII: Ch.156D Business\nXV2NZ5 United States |, Massachusetts |US-MA Domestic Business 27K voting trustee English voting trustee 2023-0628 |ACTV Corporations -\nof America Corporation .\nMassachusetts Business\nCorporation Act 5.7.30\nGeneral Laws: Part 1: Title\n\" . \" XXII: Ch.156D Business\nUnited States Domestic Business \" .\nZBLB3L of America us Massachusetts |US-MA Corporation ZJTK officer English officer 2023-06-28 ACTV Corporations - )\nMassachusetts Business\nCorporation Act 5.8.40\n2021 Michigan Compiled\nLaws: Ch. 450 -\n1CKOEH United States | ;g Michigan us-MI Corporation (For-Profit) |U7HC independent director English independent director Ind.Dir. 2023-06-28 |ACTV Corporations Act 284 of\nof America 1972 - Business\nCorporation Act 450.1107\n2021 Michigan Compiled\nUnited States Laws: Ch. 450 -\n9WMLST . us Michigan us-mi Corporation (For-Profit) |U7HC chairman English chairman Ch. 2023-06-28 ACTV Corporations Act 284 of\nof America .\n1972 - Business\nCorporation Act 450.1531\n2021 Michigan Compiled\nUnited States Laws: Ch. 450 -\nABMCPX . us Michigan us-mi Corporation (For-Profit) |U7HC shareholder English shareholder 2023-06-28 ACTV Corporations Act 284 of\nof America .\n1972 - Business\nCorporation Act 450.1201\n84/119\n","contentLength":4447,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.735Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"2021 Michigan Compiled\n. P PR Laws: Ch.50 Corporations\nUnited Stat Limited Liabilit:\nFT11Q nited States ;g Michigan Us-MI mitec Liability UH5 manager English manager Mar. 2023-06-28 |ACTV Act 23 of 1993 - Michigan\nof America Company . P,\nLimited Liability Company\nAct 450.4102\n2021 Michigan Compiled\nUnited States Laws: Ch. 450 -\nH7FBLU . us Michigan us-mi Corporation (For-Profit) |U7HC officer English officer 2023-06-28 ACTV Corporations Act 284 of\nof America .\n1972 - Business\nCorporation Act 450.1223\n2021 Michigan Compiled\nUnited States Laws: Ch. 450 -\nMzVPUX . us Michigan us-mi Corporation (For-Profit) |U7HC incorporator English incorporator 2023-06-28 ACTV Corporations Act 284 of\nof America .\n1972 - Business\nCorporation Act 450.1109\n2021 Michigan Compiled\nUnited States Laws: Ch. 450 -\nOOMMRJ . us Michigan us-mi Corporation (For-Profit) |U7HC secretary English secretary Sec. 2023-06-28 ACTV Corporations Act 284 of\nof America .\n1972 - Business\nCorporation Act 450.1531\n2021 Michigan Compiled\nUnited States Laws: Ch. 450 -\nPEBOHT of America us Michigan us-MiI Corporation (For-Profit) |U7HC director English director Dir. 2023-06-28 ACTV Corporations Act 284 of\n1972 - Business\nCorporation Act 450.1106\n2021 Michigan Compiled\n. P PR Laws: Ch.50 Corporations\nQLJRNX United States |, Michigan Us-Mi umited Liability UH5 resident agent English resident agent 2023-06-28 | ACTV Act 23 of 1993 - Michigan\nof America Company . e\nLimited Liability Company\nAct 450.4207\n2021 Michigan Compiled\n. P PR Laws: Ch.50 Corporations\nQX8SBZ United States |, Michigan Us-Mi umited Liability UH5 member English member 2023-0628 |ACTV Act 23 of 1993 - Michigan\nof America Company . e\nLimited Liability Company\nAct 450.4102\n2021 Michigan Compiled\nUnited States Laws: Ch. 450 -\nROQBAY of America us Michigan us-MiI Corporation (For-Profit) |U7HC president English president Pres. 2023-06-28 ACTV Corporations Act 284 of\n1972 - Business\nCorporation Act 450.1531\n2021 Michigan Compiled\nUnited States Laws: Ch. 450 -\nSCFXSG of America us Michigan us-MiI Corporation (For-Profit) |U7HC treasurer English treasurer Treas. 2023-06-28 ACTV Corporations Act 284 of\n1972 - Business\nCorporation Act 450.1531\n2021 Michigan Compiled\nUnited States Laws: Ch. 450 -\nUEZFGU of America us Michigan us-MiI Corporation (For-Profit) |U7HC registered agent English registered agent 2023-06-28 ACTV Corporations Act 284 of\n1972 - Business\nCorporation Act 450.1241\n2021 Michigan Compiled\nUnited States Laws: Ch. 450 -\nZJEDT7 of America us Michigan us-mi Corporation (For-Profit) |U7HC vice president English vice president VP 2023-06-28 ACTV Corporations Act 284 of\n1972 - Business\nCorporation Act 450.1531\n2021 Minnesota Statutes:\nUnited States Ch. 302A. BUSINESS\n88GTMC of America us Minnesota US-MN Business Corporation S2K8 shareholder English shareholder 2023-06-28 ACTV CORPORATIONS -\nMinnesota Business\nCorporation Act 302A.011\n2021 Minnesota Statutes:\nUnited States Ch. 302A. BUSINESS\n8ZXG5S of America us Minnesota US-MN Business Corporation S2K8 incorporator English incorporator 2023-06-28 ACTV CORPORATIONS -\nMinnesota Business\nCorporation Act 302A.105\n2021 Minnesota Statutes:\n\" . it Ch. 322C. Minnesota\nUnited Stat Limited Liabilit:\n9GDBHO nited states ;5 Minnesota US-MN mitec Liability BQRL member English member 2023-06-28 |ACTV Revised Uniform Limited\nof America Company P\nLiability Company Act\n322C.0102\n2021 Minnesota Statutes:\nUnited States Ch. 302A. BUSINESS\nAU6879 of America us Minnesota US-MN Business Corporation S2K8 officer English officer 2023-06-28 ACTV CORPORATIONS -\nMinnesota Business\nCorporation Act 302A.011\n2021 Minnesota Statutes:\nited imited Liabili Ch. 322C. Minnesota\nC22DPX United States ;g Minnesota US-MN Limited Liabllity BQRL governor English governor Gov. 20230628 |ACTV Revised Uniform Limited\nof America Company Liability Company Act\n322C.0102\n85/119\n","contentLength":3867,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.737Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"2021 Minnesota Statutes:\nUnited States Ch. 302A. BUSINESS\nDTOAKH of America us Minnesota US-MN Business Corporation S2K8 voting trustee English voting trustee 2023-06-28 ACTV CORPORATIONS -\nMinnesota Business\nCorporation Act 302A.453\n2021 Minnesota Statutes:\nUnited States Ch. 302A. BUSINESS\nDXCHXX of America us Minnesota US-MN Business Corporation S2K8 chief executive officer English chief executive officer CEO 2023-06-28 ACTV CORPORATIONS -\nMinnesota Business\nCorporation Act 302A.301\n2021 Minnesota Statutes:\nUnited States Ch. 302A. BUSINESS\nFJWS)V of America us Minnesota US-MN Business Corporation S2K8 registered agent English registered agent 2023-06-28 ACTV CORPORATIONS -\nMinnesota Business\nCorporation Act 302A.121\n2021 Minnesota Statutes:\nUnited States Ch. 302A. BUSINESS\nFNRKE] of America us Minnesota US-MN Business Corporation S2K8 owner English owner 2023-06-28 ACTV CORPORATIONS -\nMinnesota Business\nCorporation Act 302A.011\n2021 Minnesota Statutes:\nUnited States Ch. 302A. BUSINESS\nHUVHRS of America us Minnesota US-MN Business Corporation S2K8 chief financial officer English chief financial officer CFO 2023-06-28 ACTV CORPORATIONS -\nMinnesota Business\nCorporation Act 302A.301\n2021 Minnesota Statutes:\n\" . it Ch. 322C. Minnesota\nMR1PDT United States |, Minnesota US-MN umited Liability BQRL manager English manager Mar. 2023-0628 |ACTV Revised Uniform Limited\nof America Company e\nLiability Company Act\n322C.0102\n2021 Minnesota Statutes:\n\" . it Ch. 322C. Minnesota\n052D6K United States |, Minnesota US-MN umited Liability BQRL registered agent English registered agent 2023-0628 |ACTV Revised Uniform Limited\nof America Company e\nLiability Company Act\n322C.0113\n2021 Minnesota Statutes:\n\" . it Ch. 322C. Minnesota\nQAP8PI United States |, Minnesota US-MN umited Liability BQRL organizer English organizer 2023-0628 |ACTV Revised Uniform Limited\nof America Company e\nLiability Company Act\n322C.0102\n2021 Minnesota Statutes:\nUnited States Ch. 302A. BUSINESS\nQMHX5) of America us Minnesota US-MN Business Corporation S2K8 receiver English receiver 2023-06-28 ACTV CORPORATIONS -\nMinnesota Business\nCorporation Act 302A.755\n2021 Minnesota Statutes:\nUnited States Ch. 302A. BUSINESS\nTCFEDD of America us Minnesota US-MN Business Corporation S2K8 director English director Dir. 2023-06-28 ACTV CORPORATIONS -\nMinnesota Business\nCorporation Act 302A.011\n2021 Minnesota Statutes:\nUnited States Ch. 302A. BUSINESS\nXRFLHO of America us Minnesota US-MN Business Corporation S2K8 beneficial owner English beneficial owner 2023-06-28 ACTV CORPORATIONS -\nMinnesota Business\nCorporation Act 302A.011\n2021 Minnesota Statutes:\nUnited States Ch. 302A. BUSINESS\nZHIY9H of America us Minnesota US-MN Business Corporation S2K8 interested shareholder English interested shareholder 2023-06-28 ACTV CORPORATIONS -\nMinnesota Business\nCorporation Act 302A.011\nMississippi Uniform\nUnited States Commercial Code: Title\n0IHKFU of America us us-mMs Business Corporation XST3 incorporator English incorporator 2023-06-28 ACTV 79: Ch. 4 - Mississippi\nBusiness Corporation Act\n§79-4-2.01\nMississippi Uniform\nUnited States Commercial Code: Title\n1FWPRU of America us Us-Ms Business Corporation XST3 qualified director English qualified director Qual.Dir. 2023-06-28 ACTV 79: Ch. 4 - Mississippi\nBusiness Corporation Act\n§79-4-1.40\nMississippi Uniform\nUnited States Commercial Code: Title\n5GGL6A of America us US-Ms Business Corporation XST3 registered agent English registered agent 2023-06-28 ACTV 79: Ch. 4 - Mississippi\nBusiness Corporation Act\n§79-4-14.05\nMississippi Uniform\nUnited States Commercial Code: Title\n9N34PB of America us us-mMs Business Corporation XST3 shareholder English shareholder 2023-06-28 ACTV 79: Ch. 4 - Mississippi\nBusiness Corporation Act\n§79-4-1.40\n86/119\n","contentLength":3775,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.737Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Mississippi Uniform\nCommercial Code: Title\nCoESVW United States | ;¢ Us-MS Limited Liability WPCN manager English manager Mar. 2023-06-28 | ACTV 79: Ch. 29 - Revised\nof America Company Mississippi Limited\nLiability Company Act §\n79-29-105\nMississippi Uniform\n) Commercial Code: Title\nDORADS United States ;g US-Ms Business Corporation XST3 director English director Dir. 2023-06-28 |ACTV 79: Ch. 4 - Mississippi\nof America Business Corporation Act\n§79-4-2.05\nMississippi Uniform\nUnited States Commercial Code: Title\nECCDMM of America us US-Ms Business Corporation XST3 secretary English secretary Sec. 2023-06-28 ACTV 79: Ch. 4 - Mississippi\nBusiness Corporation Act\n§79-4-1.40\nMississippi Uniform\nCommercial Code: Title\n71DCE United States ) Us-Ms Limited Liability WPCN registered agent English registered agent 2023-0628 | ACTV 79: Ch. 29 - Revised\nof America Company Mississippi Limited\nLiability Company Act §\n79-29-113\nMississippi Uniform\nCommercial Code: Title\nJWYWIR United States ) Us-Ms Limited Liability WPCN receiver English receiver 2023-0628 | ACTV 79: Ch. 29 - Revised\nof America Company Mississippi Limited\nLiability Company Act §\n79-29-803\nMississippi Uniform\nCommercial Code: Title\nLzGewp United States | ;¢ Us-MS Limited Liability WPCN liquidating trustee English liquidating trustee 2023-06-28 | ACTV 79: Ch. 29 - Revised\nof America Company Mississippi Limited\nLiability Company Act §\n79-29-403\nMississippi Uniform\nUnited States Commercial Code: Title\nOD4E30 of America us Us-Ms Business Corporation XST3 subscriber English subscriber 2023-06-28 ACTV 79: Ch. 4 - Mississippi\nBusiness Corporation Act\n§79-4-1.40\nMississippi Uniform\nCommercial Code: Title\nVPQHRI United States ) Us-Ms Limited Liability WPCN member English member 2023-0628 | ACTV 79: Ch. 29 - Revised\nof America Company Mississippi Limited\nLiability Company Act §\n79-29-105\nMississippi Uniform\nCommercial Code: Title\nVWHLPD United States | ;¢ Us-MS Limited Liability WPCN officer English officer 2023-06-28 | ACTV 79: Ch. 29 - Revised\nof America Company Mississippi Limited\nLiability Company Act §\n79-29-105\nMississippi Uniform\nCommercial Code: Title\nWILRIL United States | ;g Us-Ms Uimited Liability WPCN custodian English custodian 2023-06-28 |ACTV 79: Ch. 29 - Revised\nof America Company Mississippi Limited\nLiability Company Act §\n79-29-803\nMissouri Revised\nUnited States Statutes: Ch. 351 — The\nO0CGNG5 of America us Missouri US-MO For-Profit Corporation KC7z receiver English receiver 2023-06-28 ACTV General and Business\nCorporation Law of\nMissouri 351.046\nMissouri Revised\nUnited States Statutes: Ch. 351 — The\nORUBCQ of America us Missouri Us-MO For-Profit Corporation KC7z incorporator English incorporator 2023-06-28 ACTV General and Business\nCorporation Law of\nMissouri 351.015\nMissouri Revised\nStatutes: Ch. 347 —\n\" P PR Limited Liability\nUnited Stat Limited Liabilit:\n3X6BXP nited states ;5 Missouri Us-MO mited Liability 7F5B receiver English receiver 2023-06-28 |ACTV Companies - Mergers and\nof America Company P\nConsolidations of\nBusiness Organizations\n347.047\nMissouri Revised\nUnited States Statutes: Ch. 351 — The\n6LZ2XW of America us Missouri US-MO For-Profit Corporation KC7z custodian English custodian 2023-06-28 ACTV General and Business\nCorporation Law of\nMissouri 351.498\nMissouri Revised\nUnited States Statutes: Ch. 351 — The\n81CMNP of America us Missouri us-mMo For-Profit Corporation KC7z president English president Pres. 2023-06-28 ACTV General and Business\nCorporation Law of\nMissouri 351.046\n87/119\n","contentLength":3517,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.739Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Missouri Revised\nUnited States Statutes: Ch. 351 — The\nHIQBSE of America us Missouri us-mMo For-Profit Corporation KC7z shareholder English shareholder 2023-06-28 ACTV General and Business\nCorporation Law of\nMissouri 351.015\nMissouri Revised\nStatutes: Ch. 347 —\n\" P PR Limited Liability\nJOODXN gf”';reriitcztes us Missouri US-MO é'g‘r:s:n';ab'\"ty 7F5B organizer English organizer 2023-0628 |ACTV Companies - Mergers and\nConsolidations of\nBusiness Organizations\n347.015\nMissouri Revised\n) Statutes: Ch. 351 — The\nONOPBN United States | ;g Missouri US-MO For-Profit Corporation |KC7Z director English director Dir. 2023-06-28 |ACTV General and Business\nof America Corporation Law of\nMissouri 351.046\nMissouri Revised\nUnited States Statutes: Ch. 351 — The\nPCQKNO of America us Missouri us-mMo For-Profit Corporation KC7z registered agent English registered agent 2023-06-28 ACTV General and Business\nCorporation Law of\nMissouri 351.370\nMissouri Revised\nUnited States Statutes: Ch. 351 — The\nPG80OYX of America us Missouri Us-Mo For-Profit Corporation KC7Z subscriber English subscriber 2023-06-28 |ACTV General and Business\nCorporation Law of\nMissouri 351.015\nMissouri Revised\nUnited States Statutes: Ch. 351 — The\nPZR2ZX of America us Missouri Us-MO For-Profit Corporation KC7z secretary English secretary Sec. 2023-06-28 ACTV General and Business\nCorporation Law of\nMissouri 351.285\nMissouri Revised\nUnited States Statutes: Ch. 351 — The\nUXNRGX of America us Missouri Us-MO For-Profit Corporation KC7z officer English officer 2023-06-28 ACTV General and Business\nCorporation Law of\nMissouri 351.046\nMissouri Revised\nStatutes: Ch. 347 —\n\" P PR Limited Liability\nUZYRU) g;:s\\dersitcaates us Missouri US-MO gg\\r:s:nl)_,lablhty 7F5B registered agent English registered agent 2023-06-28 ACTV Companies - Mergers and\nConsolidations of\nBusiness Organizations\n347.030\nMissouri Revised\nUnited States Statutes: Ch. 351 — The\nWODEOU of America us Missouri US-MO For-Profit Corporation KC7z chairman English chairman Ch. 2023-06-28 ACTV General and Business\nCorporation Law of\nMissouri 351.046\nMissouri Revised\nStatutes: Ch. 347 —\n\" P PR Limited Liability\nWQDTIV g;:s\\dersitcaates us Missouri US-MO gg\\r:s:nl)_,lablhty 7F5B manager English manager Mar. 2023-06-28 ACTV Companies - Mergers and\nConsolidations of\nBusiness Organizations\n347.015\nMissouri Revised\nStatutes: Ch. 347 —\n\" P PR Limited Liability\nYTBM3U gf”:reriitcztes Us Missouri Us-MO é';\"r:s:n';ab'\"ty 7F5B member English member 2023-06-28 |ACTV Companies - Mergers and\nConsolidations of\nBusiness Organizations\n347.015\nMissouri Revised\nUnited States Statutes: Ch. 351 — The\nYTMRIC of America us Missouri Us-MO For-Profit Corporation KC7z chief executive officer English chief executive officer CEO 2023-06-28 ACTV General and Business\nCorporation Law of\nMissouri 351.360\nMontana Code 2021:\nUnited States TITLE 35: Ch. 14 -\n10SHPP of America us Montana US-MT Corporation 9STD shareholder English shareholder 2023-06-28 ACTV Montana Business\nCorporation Act 35-14-\n143\nMontana Code 2021:\nUnited States TITLE 35: Ch. 14 -\n32HzUul of America us Montana US-MT Corporation 9STD governor English governor Gov. 2023-06-28 ACTV Montana Business\nCorporation Act 35-14-\n140\nMontana Code 2021:\nUnited States TITLE 35: Ch. 14 -\n6LXPZ5 of America us Montana US-MT Corporation 9STD voting trust beneficial owne English voting trust beneficial owne 2023-06-28 ACTV Montana Business\nCorporation Act 35-14-\n145\n88/119\n","contentLength":3449,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.739Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Montana Code 2021:\n9P3GOL United States ) Montana Us-MT Limited Liability AEKO member English member 2023-0628 | ACTV TITLE 35: Ch. 8 - Montana\nof America Company Limited Liability Company\nAct 35-8-102\nMontana Code 2021:\nUnited States TITLE 35: Ch. 14 -\nBKILJE of America us Montana US-MT Corporation 9STD record shareholder English record shareholder 2023-06-28 ACTV Montana Business\nCorporation Act 35-14-\n142\nMontana Code 2021:\nUnited States . . . . TITLE 35: Ch. 14 -\nFAJCXL of America us Montana USs-mMT Corporation 9STD custodian English custodian 2023-06-28 ACTV Montana Business\nCorporation Act 35-14-\n1432\nMontana Code 2021:\nUnited States Limited Liability \" TITLE 35: Ch. 8 - Montana\nKY)5G3 of America us Montana US-MT Company AEKO manager English manager Mar. 2023-06-28 ACTV Limited Liability Company\nAct 35-8-102\nMontana Code 2021:\nMAVXFA United States ) Montana Us-MT Limited Liability AEKO authorized agent English authorized agent 2023-0628 | ACTV TITLE 35: Ch. 8 - Montana\nof America Company Limited Liability Company\nAct 35-8-102\nMontana Code 2021:\nUnited Stat TITLE 35: Ch. 14 -\nouzZT3L f”\": tates ys Montana US-MT Corporation 9STD registered agent English registered agent 2023-06-28 |ACTV Montana Business\nof America Corporation Act 35-14-\n501\nMontana Code 2021:\nQLoB2!I United States | ;¢ Montana Us-MT Limited Liability AEKO receiver English receiver 2023-06-28 | ACTV TITLE 35: Ch. 8 - Montana\nof America Company Limited Liability Company\nAct 35-8-204\nMontana Code 2021:\nUnited States . . . . TITLE 35: Ch. 14 -\nWIITCY . us Montana US-MT Corporation 9STD incorporator English incorporator 2023-06-28 ACTV Montana Business\nof America :\nCorporation Act 35-14-\n201\nMontana Code 2021:\nUnited States . . . ! TITLE 35: Ch. 14 -\nWOYNLM . us Montana US-MT Corporation 9STD receiver English receiver 2023-06-28 ACTV Montana Business\nof America :\nCorporation Act 35-14-\n1432\nMontana Code 2021:\nUnited States . . . f ! TITLE 35: Ch. 14 -\nYJTKDQ . us Montana US-MT Corporation 9STD director English director Dir. 2023-06-28 ACTV Montana Business\nof America :\nCorporation Act 35-14-\n205\nMontana Code 2021:\nUnited States . . . . TITLE 35: Ch. 14 -\nYWSKQI . us Montana US-MT Corporation 9STD interest holder English interest holder 2023-06-28 ACTV Montana Business\nof America :\nCorporation Act 35-14-\n141\nMontana Code 2021:\nUnited States . . . ) TITLE 35: Ch. 14 -\nYXBTH3 . us Montana US-MT Corporation 9STD subscriber English subscriber 2023-06-28 ACTV Montana Business\nof America :\nCorporation Act 35-14-\n144\nNebraska Revised\nUnited States Statutes: Ch. 21 (21-\n09D24S of America us Nebraska US-NE Domestic Corporation RH6N registered agent English registered agent 2023-06-28 ACTV 201ff) - Nebraska Model\nBusiness Corporation Act\n21-233\nNebraska Revised\nUnited States Statutes: Ch. 21 (21-\n4CMSF2 of America us Nebraska US-NE Domestic Corporation RH6N record shareholder English record shareholder 2023-06-28 ACTV 201ff) - Nebraska Model\nBusiness Corporation Act\n21-214\nNebraska Revised\nUnited States Statutes: Ch. 21 (21-\nB2ZCHB of America us Nebraska US-NE Domestic Corporation RH6N qualified director English qualified director Qual.Dir. 2023-06-28 ACTV 201ff) - Nebraska Model\nBusiness Corporation Act\n21-214\nNebraska Revised\n\" i Statutes: Ch. 21 -\nJXLLES United States |, Nebraska US-NE Domestic Limited 8APW member English member 2023-0628 |ACTV Nebraska Uniform Limited\nof America Liability Company e\nLiability Company Act 21-\n102\nNebraska Revised\nUnited States Statutes: Ch. 21 (21-\nNSOWMT of America us Nebraska US-NE Domestic Corporation RH6N custodian English custodian 2023-06-28 |ACTV 201ff) - Nebraska Model\nBusiness Corporation Act\n21-283\n89/119\n","contentLength":3673,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.739Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Nebraska Revised\n\" i Statutes: Ch. 21 -\nUnited Stat D tic Limited\nNZRWDX nited states ;5 Nebraska US-NE Jomestic Limite SAPW agent (for service of process) | English agent (for service of process) 2023-06-28 |ACTV Nebraska Uniform Limited\nof America Liability Company o\nLiability Company Act 21-\n113\nNebraska Revised\nUnited States Statutes: Ch. 21 (21-\nOUALTX of America us Nebraska US-NE Domestic Corporation RH6N beneficial shareholder English beneficial shareholder 2023-06-28 ACTV 201ff) - Nebraska Model\nBusiness Corporation Act\n21-214\nNebraska Revised\nUnited States Statutes: Ch. 21 (21-\nPGMMEB of America us Nebraska US-NE Domestic Corporation RH6N subscriber English subscriber 2023-06-28 ACTV 201ff) - Nebraska Model\nBusiness Corporation Act\n21-214\nNebraska Revised\nUnited States Statutes: Ch. 21 (21-\nRISQ17 of America us Nebraska US-NE Domestic Corporation RHEN incorporator English incorporator 2023-06-28 ACTV 201ff) - Nebraska Model\nBusiness Corporation Act\n21-219\nNebraska Revised\n\" i Statutes: Ch. 21 (21-\nUnited Stat D tic Limited\nseMcQV e States fys Nebraska US-NE omestie Limite 8APW manager English manager Mar. 2023-06-28 |AcTv 101ff) - Nebraska Uniform\nof America Liability Company P o\nLimited Liability Company\nAct 21-102\nNebraska Revised\nUnited States Statutes: Ch. 21 (21-\nUIVG5P of America us Nebraska US-NE Domestic Corporation RH6N voting trustee English voting trustee 2023-06-28 ACTV 201ff) - Nebraska Model\nBusiness Corporation Act\n21-272\nNebraska Revised\nU s Statutes: Ch. 21 (21-\nit tat -\nYVI2EX nited States ;g Nebraska US-NE Domestic Corporation | RHEN shareholder English shareholder 2023-0628 | ACTV 201ff) - Nebraska Model\nof America Business Corporation Act\n21-214\nNebraska Revised\nUnited States Statutes: Ch. 21 (21-\nZB5YQ1 of America us Nebraska US-NE Domestic Corporation RH6N secretary English secretary Sec. 2023-06-28 ACTV 201ff) - Nebraska Model\nBusiness Corporation Act\n21-214\nNebraska Revised\nUnited States Statutes: Ch. 21 (21-\nZFCKLX of America us Nebraska US-NE Domestic Corporation RH6N voting trust beneficial owne English voting trust beneficial owne 2023-06-28 ACTV 201ff) - Nebraska Model\nBusiness Corporation Act\n21-214\nNebraska Revised\nUnited States Statutes: Ch. 21 (21-\nZORWLM of America us Nebraska US-NE Domestic Corporation RH6N receiver English receiver 2023-06-28 ACTV 201ff) - Nebraska Model\nBusiness Corporation Act\n21-283\nNebraska Revised\nUnited States Statutes: Ch. 21 (21-\nZYXAEF of America us Nebraska US-NE Domestic Corporation RH6N director English director Dir. 2023-06-28 ACTV 201ff) - Nebraska Model\nBusiness Corporation Act\n21-223\nUnited States Nevada Revised Statutes:\n4N5RQM . us Nevada US-NV Profit Corporation 8wWm4 secretary English secretary Sec. 2023-06-28 ACTV Ch. 78 Private\nof America :\nCorporations 78.130\n\" . it Nevada Revised Statutes:\n5Mj2DM United States |, Nevada US-NV umited Liability trustee English trustee 2023-0628 |ACTV Ch. 86 Limited Liability\nof America Company N\nCompanies 86-5411\nUnited States Nevada Revised Statutes:\nAQDANE of America us Nevada US-NV Profit Corporation 8wWmM4 interested stockholder English interested stockholder 2023-06-28 ACTV Ch. 78 Private\nCorporations 78.3787\n\" . it Nevada Revised Statutes:\nCIQHXB United States |, Nevada US-NV umited Liability noneconomic member English noneconomic member 2023-06-28 | ACTV Ch. 86 Limited Liability\nof America Company N\nCompanies 86-293\nUnited States Nevada Revised Statutes:\nESUP9H of America us Nevada US-NV Profit Corporation 8WM4 director English director Dir. 2023-06-28 ACTV Ch. 78 Private\nCorporations 78.010\n\" . it Nevada Revised Statutes:\nF2K0OG United States |, Nevada US-NV umited Liability receiver English receiver 2023-0628 |ACTV Ch. 86 Limited Liability\nof America Company N\nCompanies 86-5411\n\" . it Nevada Revised Statutes:\nFLHSGA United States |, Nevada US-NV umited Liability custodian of records English custodian of records 2023-06-28 | ACTV Ch. 86 Limited Liability\nof America Company N\nCompanies 86-241\n\" . it Nevada Revised Statutes:\nFZNG6Q United States |, Nevada US-NV Limited Liability organizer English organizer 2023-0628 |ACTV Ch. 86 Limited Liability\nof America Company N\nCompanies 86-161\n\" . it Nevada Revised Statutes:\nGOET32 United States |, Nevada US-NV umited Liability member English member 2023-0628 |ACTV Ch. 86 Limited Liability\nof America Company N\nCompanies 86-081\n90/119\n","contentLength":4379,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.740Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"23 MAART 2019. — Wet\ntot invoering van het\nWetboek van\nvennootschappen en\nQRWQDE Belgium Naamloze vennootschap | R85P Bestuurder Dutch Bestuurder 2023-06-28 ACTV verenigingen en\nhoudende diverse\nbepalingen - BOEK 7:\nTITEL 4: HOOFDSTUK 1:\nArt.7:85\n23 MARZ 2019. —\nQRWQDE Belgium Aktiengesellschaft R85P Verwalter German Verwalter 2023-06-28 |ACTV Gesetzbuch der\nGesellschaften und\nVereinigungen\n23 MARS 2019. — Loi\nintroduisant le Code des\nTitulaire de certificats émis Titulaire de certificats émis sociétés et des\nRUBNLX Belgium Société anonyme R85P avec la collaboration de la French fr avec la collaboration de la 2023-06-28 |ACTV associations et portant\nsociété société des dispositions diverses -\nLivre 7: Titre 4: CHAPITRE\n2: Art. 7:135\n23 MAART 2019. — Wet\ntot invoering van het\nWetboek van\nHouder van met medewerking Houder van met medewerking vennootschappen en\nRUBNLX Belgium Naamloze vennootschap | R85P van de vennootschap Dutch van de vennootschap 2023-06-28 ACTV verenigingen en\nuitgegeven certificaten uitgegeven certificaten houdende diverse\nbepalingen - BOEK 7:\nTITEL 4: HOOFDSTUK 2:\nArt.7:135\nInhaber von Zertifikaten, die Inhaber von Zertifikaten, die 23 MARZ 2019. —\nRUSNLX Belgium Aktiengesellschaft R85P unter Mitwirkung des German unter Mitwirkung des 2023-06-28 |ACTV Gesetzbuch der\nUnternehmens ausgestellt Unternehmens ausgestellt Gesellschaften und\nwurden wurden Vereinigungen\n23 MAART 2019. — Wet\ntot invoering van het\nWetboek van\nvennootschappen en\nVRBAQV Belgium Besloten Vennootschap |3W7E Commissaris Dutch Commissaris 2023-06-28 ACTV verenigingen en\nhoudende diverse\nbepalingen - BOEK 3:\nTITEL 4: HOOFDSTUK 1:\nArt.3:58\n23 MARS 2019. — Loi\nintroduisant le Code des\nAP o sociétés et des\nVRBAQV Belgium fi,‘.’f.'tif aresponsabilité |\\, Commissaire French fr Commissaire 2023-06-28 |ACTV associations et portant\ndes dispositions diverses -\nLivre 3: Titre 4: CHAPITRE\n1: Art. 3:58\n23 MARZ 2019. —\nVRBAQV Belgium Ss:f:\\'f;:sgr\":\";fiung 3W7E Wirtschaftsprifer German Wirtschaftspriifer 2023-0628 | ACTV Gesetabuch der\nVereinigungen\n23 MARS 2019. — Loi\nintroduisant le Code des\nsociétés et des\nWGOPLW Belgium Société anonyme R85P Obligataire French fr Obligataire 2023-06-28 ACTV associations et portant\ndes dispositions diverses -\nLivre 7: Titre 3: CHAPITRE\n2: Art. 7:62\n23 MAART 2019. — Wet\ntot invoering van het\nWetboek van\nvennootschappen en\nWGOPLW Belgium Naamloze vennootschap | R85P Obligatiehouder Dutch Obligatiehouder 2023-06-28 ACTV verenigingen en\nhoudende diverse\nbepalingen - BOEK 7:\nTITEL 3: HOOFDSTUK 2:\nArt.7:62\n23 MARZ 2019. —\nWGOPLW Belgium Aktiengesellschaft R85P Anleiheinhaber German Anleiheinhaber 2023-06-28 |ACTV Gesetzbuch der\nGesellschaften und\nVereinigungen\n23 MAART 2019. — Wet\ntot invoering van het\nWetboek van\nWOYWOR | Belgium Besloten Vennootschap | 3W7E Vennoot Dutch Vennoot 2023-06-28 [ACTV vennootschappen en\nverenigingen en\nhoudende diverse\nbepalingen - BOEK 1:\nTITEL 1: Art.1:1\n10/119\n","contentLength":2947,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.740Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"United States Nevada Revised Statutes:\nIYHBND of America us Nevada US-NV Profit Corporation 8WM4 custodian English custodian 2023-06-28 ACTV Ch. 78 Private\nCorporations 78.347\nUnited States Nevada Revised Statutes:\nJ77N3K of America us Nevada US-NV Profit Corporation 8wWmM4 president English president Pres. 2023-06-28 ACTV Ch. 78 Private\nCorporations 78.130\n\" . it Nevada Revised Statutes:\nLOPCXD United States |, Nevada US-NV umited Liability managing member English managing member 2023-0628 |ACTV Ch. 86 Limited Liability\nof America Company N\nCompanies 86-298\nUnited States Nevada Revised Statutes:\nOJXY7Y of America us Nevada US-NV Profit Corporation 8wWM4 stockholder (of record) English stockholder (of record) 2023-06-28 ACTV Ch. 78 Private\nCorporations 78.013\n\" . it Nevada Revised Statutes:\nOLDRCT United States |, Nevada US-NV umited Liability registered agent English registered agent 2023-0628 |ACTV Ch. 86 Limited Liability\nof America Company N\nCompanies 86-118\nUnited States Nevada Revised Statutes:\nPDDFVU of America us Nevada US-NV Profit Corporation 8WM4 treasurer English treasurer Treas. 2023-06-28 ACTV Ch. 78 Private\nCorporations 78.130\nUnited States Nevada Revised Statutes:\nPQ2LP4 of America us Nevada US-NV Profit Corporation 8wWmM4 registered agent English registered agent 2023-06-28 ACTV Ch. 78 Private\nCorporations 78.012\nUnited States Nevada Revised Statutes:\nPWBKOB . us Nevada US-NV Profit Corporation 8wWm4 voting trustee English voting trustee 2023-06-28 ACTV Ch. 78 Private\nof America :\nCorporations 78.365\n\" . it Nevada Revised Statutes:\nUnited Stat Limited Liabilit:\nQHYUH6 nited states ;5 Nevada US-NV mited Liability manager English manager Mar. 2023-06-28 |ACTV Ch. 86 Limited Liability\nof America Company \"\nCompanies 86-071\nUnited States Nevada Revised Statutes:\nSI3LNP . us Nevada US-NV Profit Corporation 8wWm4 receiver English receiver 2023-06-28 ACTV Ch. 78 Private\nof America :\nCorporations 78.011\nUnited States Nevada Revised Statutes:\nSRESJH . us Nevada US-NV Profit Corporation 8wWm4 beneficial owner English beneficial owner 2023-06-28 ACTV Ch. 78 Private\nof America :\nCorporations 78.414\nUnited States Nevada Revised Statutes:\nTIGKV1 of America us Nevada US-NV Profit Corporation 8WM4 custodian of records English custodian of records 2023-06-28 |ACTV Ch. 78 Private\nCorporations 78.105\nUnited States Nevada Revised Statutes:\nZNAOSA of America us Nevada US-NV Profit Corporation 8WM4 trustee English trustee 2023-06-28 ACTV Ch. 78 Private\nCorporations 78.600\nUnited States Nevada Revised Statutes:\nZUYGQz of America us Nevada US-NV Profit Corporation 8WM4 officer English officer 2023-06-28 ACTV Ch. 78 Private\nCorporations 78.037\nNew Hampshire Revised\nUnited States Statutes: TITLE XXVII: Ch.\n2C4SSB of America us New Hampshire |US-NH Business Corporation registered agent English registered agent 2023-06-28 ACTV 293-A - NEW HAMPSHIRE\nBUSINESS CORPORATION\nACT 293-A:1.20\nNew Hampshire Revised\nStatutes: TITLE XXVIII: Ch.\n\" P PR 304-C Limited Liability\n2P4URL United States |, New Hampshire [US-NH Limited Liability 0JoK member English member 2023-06-28 |ACTV Companies - New\nof America Company N N\nHampshire Revised\nLimited Liability Company\nAct 304-C:14\nNew Hampshire Revised\nUnited States Statutes: TITLE XXVII: Ch.\n4KK6ZN of America us New Hampshire |US-NH Business Corporation custodian English custodian 2023-06-28 ACTV 293-A - NEW HAMPSHIRE\nBUSINESS CORPORATION\nACT 293-A:14.32\nNew Hampshire Revised\nUnited States Statutes: TITLE XXVII: Ch.\n6ZGMF4 of America us New Hampshire |US-NH Business Corporation assistant secretary English assistant secretary Asst.Sec. 2023-06-28 ACTV 293-A - NEW HAMPSHIRE\nBUSINESS CORPORATION\nACT 293-A:1.20\nNew Hampshire Revised\nUnited States Statutes: TITLE XXVII: Ch.\nA5JL51 of America us New Hampshire |US-NH Business Corporation receiver English receiver 2023-06-28 ACTV 293-A - NEW HAMPSHIRE\nBUSINESS CORPORATION\nACT 293-A:1.20\nNew Hampshire Revised\nStatutes: TITLE XXVIII: Ch.\n\" P PR 304-C Limited Liability\nUnited Stat Limited Liabilit:\nGKALAW nited States ;g New Hampshire |US-NH mitec Liability 0JoK liquidating trustee English liquidating trustee 2023-0628 | ACTV Companies - New\nof America Company N N\nHampshire Revised\nLimited Liability Company\nAct 304-C:139\nNew Hampshire Revised\nUnited States Statutes: TITLE XXVII: Ch.\nHNZUD5 of America us New Hampshire |US-NH Business Corporation voting trustee English voting trustee 2023-06-28 ACTV 293-A - NEW HAMPSHIRE\nBUSINESS CORPORATION\nACT 293-A:7.30\n91/119\n","contentLength":4506,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.740Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"New Hampshire Revised\nStatutes: TITLE XXVIII: Ch.\n\" P PR 304-C Limited Liability\nLSUGTF United States |, New Hampshire [US-NH umited Liability 0JoK registered agent English registered agent 2023-06-28 | ACTV Companies - New\nof America Company Hampshire Revised\nLimited Liability Company\nAct 304-C:36\nNew Hampshire Revised\nUnited States Statutes: TITLE XXVII: Ch.\nMKT1UQ of America us New Hampshire |US-NH Business Corporation beneficial owner English beneficial owner 2023-06-28 ACTV 293-A - NEW HAMPSHIRE\nBUSINESS CORPORATION\nACT 293-A:7.30\nNew Hampshire Revised\nUnited States Statutes: TITLE XXVII: Ch.\nNN4XWQ of America us New Hampshire |US-NH Business Corporation director English director Dir. 2023-06-28 ACTV 293-A - NEW HAMPSHIRE\nBUSINESS CORPORATION\nACT 293-A:1.20\nNew Hampshire Revised\nUnited States Statutes: TITLE XXVII: Ch.\nOO1PE) of America us New Hampshire |US-NH Business Corporation chairman English chairman Ch. 2023-06-28 ACTV 293-A - NEW HAMPSHIRE\nBUSINESS CORPORATION\nACT 293-A:1.20\nNew Hampshire Revised\nUnited States Statutes: TITLE XXVII: Ch.\nOXJFPZ of America us New Hampshire |US-NH Business Corporation officer English officer 2023-06-28 ACTV 293-A - NEW HAMPSHIRE\nBUSINESS CORPORATION\nACT 293-A:1.20\nNew Hampshire Revised\nStatutes: TITLE XXVIII: Ch.\n\" P PR 304-C Limited Liability\nUnited Stat Limited Liabilit:\nPIXSFO nited States ;g New Hampshire |US-NH mitec Liability 0JoK director English director Dir. 2023-0628 | ACTV Companies - New\nof America Company Hampshire Revised\nLimited Liability Company\nAct 304-C:76\nNew Hampshire Revised\nUnited States Statutes: TITLE XXVII: Ch.\nQFLAAN of America us New Hampshire |US-NH Business Corporation trustee English trustee 2023-06-28 ACTV 293-A - NEW HAMPSHIRE\nBUSINESS CORPORATION\nACT 293-A:1.20\nNew Hampshire Revised\nUnited Stat Statutes: TITLE XXVII: Ch.\nRAORTC amerea > |us New Hampshire [US-NH Business Corporation subscriber English subscriber 2023-06-28 |ACTV 293-A - NEW HAMPSHIRE\nof America BUSINESS CORPORATION\nACT 293-A:1.140\nNew Hampshire Revised\nUnited States Statutes: TITLE XXVII: Ch.\nRH3ZVS of America us New Hampshire |US-NH Business Corporation president English president Pres. 2023-06-28 ACTV 293-A - NEW HAMPSHIRE\nBUSINESS CORPORATION\nACT 293-A:1.20\nNew Hampshire Revised\nUnited States Statutes: TITLE XXVII: Ch.\nRJWV)7 of America us New Hampshire |US-NH Business Corporation secretary English secretary Sec. 2023-06-28 ACTV 293-A - NEW HAMPSHIRE\nBUSINESS CORPORATION\nACT 293-A:1.20\nNew Hampshire Revised\nStatutes: TITLE XXVIII: Ch.\n\" P PR 304-C Limited Liability\nUnited Stat Limited Liabilit:\nRYSQH) nited states ;5 New Hampshire |US-NH mited Liability 0JoK manager English manager Mar. 2023-06-28 |ACTV Companies - New\nof America Company Hampshire Revised\nLimited Liability Company\nAct 304-C:13\nNew Hampshire Revised\nUnited States Statutes: TITLE XXVII: Ch.\nSESZCW of America us New Hampshire |US-NH Business Corporation interest holder English interest holder 2023-06-28 ACTV 293-A - NEW HAMPSHIRE\nBUSINESS CORPORATION\nACT 293-A:1.140\nNew Hampshire Revised\nUnited States Statutes: TITLE XXVII: Ch.\nSFH44F of America us New Hampshire |US-NH Business Corporation qualified director English qualified director Qual.Dir. 2023-06-28 ACTV 293-A - NEW HAMPSHIRE\nBUSINESS CORPORATION\nACT 293-A:1.140\nNew Hampshire Revised\nUnited States Statutes: TITLE XXVII: Ch.\nSLBMTZ of America us New Hampshire |US-NH Business Corporation incorporator English incorporator 2023-06-28 ACTV 293-A - NEW HAMPSHIRE\nBUSINESS CORPORATION\nACT 293-A:1.20\nNew Hampshire Revised\nStatutes: TITLE XXVIII: Ch.\n\" P PR 304-C Limited Liability\nUGYMO8 United States |, New Hampshire [US-NH Limited Liability 0JoK officer English officer 2023-06-28 |ACTV Companies - New\nof America Company N N\nHampshire Revised\nLimited Liability Company\nAct 304-C:76\n92/119\n","contentLength":3815,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.741Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"New Jersey Statutes:\n\" \" TITLE 17: CORPORATIONS\nUnited Stat S d L\n6UMRS) of e |us New Jersey US-N) e Loan N508 Vice president English Vice president 20230628 |ACTV AND INSTITUTIONS FOR\nFINANCE AND INSURANCE\n-17:12B-65\nNew Jersey Business\nCorporation Act - 14A:6-\nUnited States ! ’ ’ ’ ’ ' ’ . o6 15; New Jersey Statutes:\n7EOLG) of America us New Jersey US-NJ Business Corporation XSNP Vice president English Vice president VP VP 2023-06-28 ACTV TITLE 14A\nCORPORATIONS,\nGENERAL\nNew Jersey Business\nCorporation Act - 14A:6-\nUnited States ! ’ ’ ’ ' ’ o6 15; New Jersey Statutes:\n8HLH49 of America us New Jersey US-NJ Business Corporation XSNP President English President 2023-06-28 ACTV TITLE 14A\nCORPORATIONS,\nGENERAL\nNew Jersey Business\nCorporation Act - 14A:1-\nUnited States ! ’ ’ ’ ' ’ o6 2.1; New Jersey Statutes:\n9NFRGT of America us New Jersey US-NJ Business Corporation XSNP Subscriber English Subscriber 2023-06-28 |ACTV TITLE 14A\nCORPORATIONS,\nGENERAL\nRevised Uniform Limited\nLiability Company Act -\n. P PR 42:2C-26; New Jersey\nAQZLTO gf”:re‘irsit;t“ us New Jersey US-NJ gg\"n'qte:n';,'ab\"'ty P7RH Managing member English Managing member 2023-0628 |ACTV Statutes: TITLE 42:\nP PARTNERSHIPS AND\nPARTNERSHIP\nASSOCIATIONS\nNew Jersey Statutes:\nB5CPN5 gp::qdeztcaates us New Jersey US-NJ Nonprofit Corporation T4AM6 Treasurer Board of Trustees English Treasurer Board of Trustees 2023-06-28 ACTV Zg;ié::TIONS\nNONPROFIT\nNew Jersey Business\nCorporation Act - 14A:1-6;\nUnited States ! ’ ’ ’ ' ’ o6 New Jersey Statutes:\nBIYEBM of America us New Jersey US-NJ Business Corporation XSNP Assistant secretary English Assistant secretary Asst. Sec. Asst. Sec. 2023-06-28 ACTV TITLE 14A\nCORPORATIONS,\nGENERAL\nRevised Uniform Limited\nLiability Company Act -\n. P PR 42:2C-2; New Jersey\nCITREN gf”:re‘irsit;t“ us New Jersey US-NJ gg\"n'qte:n';,'ab\"'ty P7RH Member English Member 2023-0628 |ACTV Statutes: TITLE 42:\nP PARTNERSHIPS AND\nPARTNERSHIP\nASSOCIATIONS\nNew Jersey Statutes:\nF77YH4 gp::qdeztcaates us New Jersey US-NJ Nonprofit Corporation T4M6 Secretary Board of Trustees English Secretary Board of Trustees 2023-06-28 ACTV Zg;ié::TIONS\nNONPROFIT\nUniform Limited\nPartnership Law (1976) -\nUnited States 42:2A-5; New Jersey\nHZP3BD of America us New Jersey US-NJ Limited Partnership THY7 Limited partner English Limited partner 2023-06-28 ACTV Statutes: TITLE 42:\nPARTNERSHIPS AND\nPARTNERSHIP\nASSOCIATIONS\nNew Jersey Statutes:\nUnited States TITLE 17: CORPORATIONS\n11BPI7 of America us New Jersey US-NJ Commercial Bank G421 Controlling person English Controlling person 2023-06-28 ACTV AND INSTITUTIONS FOR\nFINANCE AND INSURANCE\n- 17:9A-423\nNew Jersey Business\nCorporation Act - 14A:1-\nUnited States ! ’ . \" o6 2.1; New Jersey Statutes:\nIPZGAR of America us New Jersey US-NJ Business Corporation XSNP Shareholder English Shareholder 2023-06-28 ACTV TITLE 14A\nCORPORATIONS,\nGENERAL\nNew Jersey Statutes:\nUnited States TITLE 17: CORPORATIONS\nJGZIUP of America us New Jersey US-NJ Commercial Bank G421 Stockholder English Stockholder 2023-06-28 ACTV AND INSTITUTIONS FOR\nFINANCE AND INSURANCE\n-17:9A-6.3\nNew Jersey Business\nCorporation Act - 14A:6-\nJSAGEB gp::qdeztcaates us New Jersey US-NJ Business Corporation XSNP Treasurer English Treasurer 2023-06-28 |ACTV ;IS.IiLgel\\:v‘JAersey Statutes:\nCORPORATIONS,\nGENERAL\n93/119\n","contentLength":3307,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.741Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"Revised Uniform Limited\nLiability Company Act -\n. P PR 42:2C-2; New Jersey\nJWINYA gf”:re‘irsit;t“ us New Jersey US-NJ gg\"n'qte:n';,'ab\"'ty P7RH Manager English Manager 2023-0628 |ACTV Statutes: TITLE 42:\nP PARTNERSHIPS AND\nPARTNERSHIP\nASSOCIATIONS\nNew Jersey Statutes:\nUnited States TITLE 17: CORPORATIONS\nLIKGWD of America us New Jersey US-NJ Commercial Bank G421 Vice president English Vice president 2023-06-28 ACTV AND INSTITUTIONS FOR\nFINANCE AND INSURANCE\n-17:9A-6.2\nNew Jersey Statutes:\n\" \" TITLE 17: CORPORATIONS\nUnited Stat S d L\nL33PHW of”'Arenericz e us New Jersey US-N) Ai:(')’;?:t;: oan N508 Officer English Officer 2023-06-28 |ACTV AND INSTITUTIONS FOR\nFINANCE AND INSURANCE\n-17:12B-38.1, 17:12B-65\nNew Jersey Business\nCorporation Act - 14A:6-\nUnited States ! ’ ’ ' ' ' o6 15; New Jersey Statutes:\nMMHZSQ of America us New Jersey US-NJ Business Corporation XSNP Chairman English Chairman 2023-06-28 ACTV TITLE 14A\nCORPORATIONS,\nGENERAL\nNew Jersey Statutes:\n\" \" TITLE 17: CORPORATIONS\nUnited Stat S d L St t C St t C\nMPBROW of”'Arenericz e us New Jersey US-N) Ai:(')’;?:t;: oan N508 525:;:3')( ompany English s:geet::;/)( ompany Sec. Sec. 2023-06-28 |ACTV AND INSTITUTIONS FOR\nFINANCE AND INSURANCE\n-17:12B-46\nNew Jersey Statutes:\nUnited States TITLE 17: CORPORATIONS\nN52QZT of America us New Jersey US-NJ Commercial Bank G421 Manager English Manager 2023-06-28 ACTV AND INSTITUTIONS FOR\nFINANCE AND INSURANCE\n-17:9A-7\nNew Jersey Business\nCorporation Act - 14A:1-\nUnited States ! ’ ’ ! ' ! o6 2.1; New Jersey Statutes:\nNWSVW7 of America us New Jersey US-NJ Business Corporation XSNP Director English Director 2023-06-28 ACTV TITLE 14A\nCORPORATIONS,\nGENERAL\nNew Jersey Statutes:\n\" \" TITLE 17: CORPORATIONS\nORFN57 gf”:re‘irsit;t“ us New Jersey US-NJ i?;(')’;?:t;’:]d Loan N508 Director English Director 2023-0628 |ACTV AND INSTITUTIONS FOR\nFINANCE AND INSURANCE\n-17:12B-5, 17:12B-62\nRevised Uniform Limited\nLiability Company Act -\n. P PR 42:2C-14; New Jersey\nUnited Stat Limited Liabilit:\nPMYWYX oplAriericaa es us New Jersey US-NJ c(n;nn: eanyla ity P7RH Agent for service of process English Agent for service of process 2023-06-28 ACTV Statutes: TITLE 42:\nP PARTNERSHIPS AND\nPARTNERSHIP\nASSOCIATIONS\nNew Jersey Statutes:\n\" \" TITLE 17: CORPORATIONS\nPN7BHH gf”:re‘irsit;t“ us New Jersey US-NJ i?;(')’;?:t;’:]d Loan N508 Chairman English Chairman 2023-0628 |ACTV AND INSTITUTIONS FOR\nFINANCE AND INSURANCE\n-17:12B-65\nUniform Limited\nPartnership Law (1976) -\n42:2A-5; New Jersey\nPNCGNS United States | ;g New Jersey US-NJ Limited Partnership THY7 General partner English General partner 2023-06-28 | ACTV Statutes: TITLE 42:\nof America PARTNERSHIPS AND\nPARTNERSHIP\nASSOCIATIONS\nNew Jersey Statutes:\n\" \" TITLE 17: CORPORATIONS\nQGDLS3 gf”:re‘irsit;t“ us New Jersey US-NJ i?;(')’;?:t;’:]d Loan N508 Treasurer English Treasurer 2023-0628 |ACTV AND INSTITUTIONS FOR\nFINANCE AND INSURANCE\n-17:12B-65\nNew Jersey Business\nCorporation Act - 14A:1-6;\nUnited States . . Secretary (Company . Secretary (Company New Jersey Statutes:\nTKYRD us N US-N Bi C t XSNP English Sec. Sec. 2023-06-28 ACTV\nQ of America ew Jersey d usiness Corporation secretary) gl secretary) ec ec TITLE 14A\nCORPORATIONS,\nGENERAL\nNew Jersey Statutes:\n\" \" TITLE 17: CORPORATIONS\nUnited Stat S d L\nRRQDGE of e |us New Jersey |US-NJ e Loan N508 Member English Member 2023-06-28 | ACTV AND INSTITUTIONS FOR\nFINANCE AND INSURANCE\n-17:12B-74\n94/119\n","contentLength":3413,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.741Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"New Jersey Business\nCorporation Act - 14A:4-1;\nUnited States ! ’ ’ I ' I o6 New Jersey Statutes:\nSHN9YL of America us New Jersey US-NJ Business Corporation XSNP Registered agent English Registered agent 2023-06-28 ACTV TITLE 14A\nCORPORATIONS,\nGENERAL\nNew Jersey Business\nCorporation Act - 14A:5-\nUnited States ! ’ ’ ' o6 22; New Jersey Statutes:\nSKHGAZ of America us New Jersey US-NJ Business Corporation XSNP Bondholder English Bondholder 2023-06-28 |ACTV TITLE 14A\nCORPORATIONS,\nGENERAL\nNew Jersey Statutes:\nUnited States . \" \" \" TITLE 15A:\nSPFYJM of America us New Jersey US-NJ Nonprofit Corporation T4M6 Registered Agent English Registered Agent 2023-06-28 ACTV CORPORATIONS,\nNONPROFIT\nNew Jersey Business\nCorporation Act - 14A:5-\nUnited States ! ’ ’ ' o6 25; New Jersey Statutes:\nTAGIX4 of America us New Jersey US-NJ Business Corporation XSNP Inspector English Inspector 2023-06-28 ACTV TITLE 14A\nCORPORATIONS,\nGENERAL\nNew Jersey Statutes:\n\" \" TITLE 17: CORPORATIONS\nUWUYLN gf”:re‘irsit;t“ us New Jersey US-NJ i?;(')’;?:t;’:]d Loan N508 President English President 2023-0628 |ACTV AND INSTITUTIONS FOR\nFINANCE AND INSURANCE\n-17:12B-46\nRevised Uniform Limited\nLiability Company Act -\n. P PR 42:2C-18; New Jersey\nUnited Stat Limited Liabilit:\nVDSHJQ of”'Arenericz e us New Jersey US-NJ cg:\"q eany'a s P7RH Organizer English Organizer 2023-06-28 |ACTV Statutes: TITLE 42\nP PARTNERSHIPS AND\nPARTNERSHIP\nASSOCIATIONS\nNew Jersey Statutes:\nUnited States TITLE 17: CORPORATIONS\nVDVLFS of America us New Jersey US-NJ Commercial Bank G421 Incorporator English Incorporator 2023-06-28 ACTV AND INSTITUTIONS FOR\nFINANCE AND INSURANCE\n-17:9A-3\nNew Jersey Statutes:\n\" \" TITLE 17: CORPORATIONS\nVKGMQK gf”:re‘irsit;t“ us New Jersey US-NJ i?;(')’;?:t;’:]d Loan N508 President English President 2023-0628 |ACTV AND INSTITUTIONS FOR\nFINANCE AND INSURANCE\n-17:12B-65\nNew Jersey Statutes:\nUnited States TITLE 17: CORPORATIONS\nVXQL8N of America us New Jersey US-NJ Commercial Bank G421 Director English Director 2023-06-28 ACTV AND INSTITUTIONS FOR\nFINANCE AND INSURANCE\n-17:9A-3\nNew Jersey Business\nCorporation Act - 14A:2-6;\nWBFMHD United States us New Jersey US-NJ Business Corporation XSNP Incorporator English Incorporator 2023-06-28 |ACTV New Jersey Statutes:\nof America TITLE 14A\nCORPORATIONS,\nGENERAL\nNew Jersey Business\nCorporation Act - 14A:3-5;\nWGBKRS United States | ;g New Jersey US-N) Business Corporation | XSNP Officer English Officer 20230628 |ACTV New Jersey Statutes:\nof America TITLE 14A\nCORPORATIONS,\nGENERAL\nNew Jersey Statutes:\nUnited States . \" \" \" TITLE 15A:\nWKYRRR of America us New Jersey US-NJ Nonprofit Corporation T4AM6 President Board of Trustees English President Board of Trustees 2023-06-28 ACTV CORPORATIONS,\nNONPROFIT\nNew Jersey Statutes:\n\" \" TITLE 17: CORPORATIONS\nX6QB3G gf”:re‘irsit;t“ us New Jersey US-NJ i?;(')’;?:t;’:]d Loan N508 Stockholder English Stockholder 2023-0628 |ACTV AND INSTITUTIONS FOR\nFINANCE AND INSURANCE\n-17:12B-5\nNew Jersey Statutes:\n} TITLE 17: CORPORATIONS\nXjows1 United States ;g New Jersey US-NJ Commercial Bank G421 Officer English Officer 2023-06-28 |ACTV AND INSTITUTIONS FOR\nof America FINANCE AND INSURANCE\n-17:9A-3\nNew Jersey Statutes:\n\" \" TITLE 17: CORPORATIONS\nYFOEA2 gf”:re‘irsit;t“ Us New Jersey US-NJ i?;(')’;?:t;’:]d Loan N508 Incorporator English Incorporator 2023-06-28 |ACTV AND INSTITUTIONS FOR\nFINANCE AND INSURANCE\n-17:12B-13\n95/119\n","contentLength":3399,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.741Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"New Jersey Statutes:\nUnited States TITLE 17: CORPORATIONS\nZOFANA of America us New Jersey US-NJ Commercial Bank G421 President English President 2023-06-28 ACTV AND INSTITUTIONS FOR\nFINANCE AND INSURANCE\n-17:9A-6.2\nUnited States New Mexico Statutes:\nOPHOTY of America us New Mexico US-NM Profit Corporation VG3S subscriber English subscriber 2023-06-28 ACTV Ch.53: Art.11: Business\nCorporation Act - 53-11-2\nUnited States New Mexico Statutes:\n94ELPW of America us New Mexico US-NM Profit Corporation VG3S incorporator English incorporator 2023-06-28 ACTV Ch.53: Art.11: Business\nCorporation Act - 53-12-1\nNew Mexico Statutes:\nCGEVSG United States ;g New Mexico [US-NM Profit Corporation VG3S director English director 2023-0628 |ACTV Ch.53: Art.11: Business\nof America Corporation Act - 53-11-\n4.1\nNew Mexico Statutes:\nUnited States \" . ot \" \" A \" Ch.53: Art.11: Business\nDPFNFP of America us New Mexico US-NM Profit Corporation VG3S liquidating receiver English liquidating receiver 2023-06-28 ACTV Corporation Act - 53-16-\n17\nNew Mexico Statutes:\nFBICME United States ) New Mexico |US-NM Limited Liability 4Y0A member English member 2023-0628 | ACTV Article 19 - Limited\nof America Company Liability Company Act 53-\n19-2\nNew Mexico Statutes:\nFOHSMZ United States ;g New Mexico [US-NM Profit Corporation VG3S officer English officer 2023-0628 |ACTV Ch.53: Art.11: Business\nof America Corporation Act - 53-11-\n4.1\nNew Mexico Statutes:\nFTDCOM United States ;g New Mexico |US-NM Profit Corporation VG3s receiver English receiver 2023-06-28 | ACTV Ch.53: Art.11: Business\nof America Corporation Act - 53-16-\n17\nUnited States New Mexico Statutes:\nGXEPEX of America us New Mexico US-NM Profit Corporation VG3S shareholder English shareholder 2023-06-28 ACTV Ch.53: Art.11: Business\nCorporation Act - 53-11-2\nNew Mexico Statutes:\n10ZBJ8 United States ) New Mexico |US-NM Limited Liability 4Y0A receiver English receiver 2023-0628 | ACTV Article 19 - Limited\nof America Company Liability Company Act 53-\n19-12\nNew Mexico Statutes:\nUnited States \" Limited Liability \" Article 19 - Limited\nL3QXNB of America us New Mexico US-NM Company 4Y0A manager English manager Mar. 2023-06-28 ACTV Liability Company Act 53-\n19-2\nNew Mexico Statutes:\nUnited States \" Limited Liability \" \" \" Article 19 - Limited\nNP4EUY us New M US-NM 4YOA tered it English tered t 2023-06-28 ACTV\nof America ew Mexico Company registerec agen nglls registerec agen Liability Company Act 53-\n19-5\nNew Mexico Statutes:\nUnited States \" . \" \" \" Ch.53: Art.11: Business\nNT8ZRF of America us New Mexico US-NM Profit Corporation VG3S registered agent English registered agent 2023-06-28 ACTV Corporation Act - 53-11-\n11\nNew Mexico Statutes:\nWKVIZR United States ) New Mexico |US-NM Limited Liability 4Y0A organizer English organizer 2023-0628 | ACTV Article 19 - Limited\nof America Company Liability Company Act 53-\n19-9\nNew Mexico Statutes:\nzL8DYC United States ;g New Mexico [US-NM Profit Corporation VG3S voting trustee English voting trustee 2023-0628 |ACTV Ch.53: Art.11: Business\nof America Corporation Act - 53-11-\n34\nNew York Consolidated\nUnited States Limited Liability \" \" \" Laws CHAPTER 34 New\n0YQOLS of America us New York US-NY Company SDX0 Registered agent English Registered agent 2023-06-28 ACTV York Limited Liability\nCompany Law -5.203\nNew York Consolidated\nUnited States . : ; Laws Bus.lness\n2MAQSP . us New York US-NY Business Corporation PJ10 Bondholder English Bondholder 2023-06-28 ACTV Corporation (BSC)\nof America .\nCHAPTER 4 Business\nCorporation Law - 5.518\nNew York Consolidated\nUnited States . . . Laws Bus.lness\n4D0z6Z . us New York US-NY Business Corporation PJ10 Inspector English Inspector 2023-06-28 ACTV Corporation (BSC)\nof America .\nCHAPTER 4 Business\nCorporation Law - 5.610\nNew York Consolidated\nUnited States . . . Laws Bus.lness\n4)QK49 . us New York US-NY Business Corporation PJ10 Incorporator English Incorporator 2023-06-28 ACTV Corporation (BSC)\nof America .\nCHAPTER 4 Business\nCorporation Law - 5.401\nNew York Consolidated\nLaws Business\n50SNBX United States | ;g New York US-NY Business Corporation |PJ10 Voting trustee English Voting trustee 2023-06-28 |ACTV Corporation (BSC)\nof America CHAPTER 4 Business\nCorporation Law - 5.621\n96/119\n","contentLength":4245,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.741Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"New York Consolidated\nUnited States Laws Business\nAK9FOO . us New York US-NY Business Corporation PJ10 Beneficial owner English Beneficial owner 2023-06-28 ACTV Corporation (BSC)\nof America .\nCHAPTER 4 Business\nCorporation Law - 5.513\nNew York Consolidated\nUnited States Laws Business\nCAUXXB . us New York US-NY Business Corporation PJ10 Committee member English Committee member 2023-06-28 ACTV Corporation (BSC)\nof America .\nCHAPTER 4 Business\nCorporation Law - 5.712\nNew York Consolidated\nCFFXDB United States ) New York Us-NY Limited Liability SDX0 Authorized person English Authorized person 2023-0628 | ACTV Laws CHAPTER 34 New\nof America Company York Limited Liability\nCompany Law - 5.102\nNew York Consolidated\nUnited States Laws Business\nCMLMM7 of America us New York US-NY Business Corporation P10 Director English Director 2023-06-28 ACTV Corporation (BSC)\nCHAPTER 4 Business\nCorporation Law - 5.102\nNew York Consolidated\nUnited States Laws Business\nETBDX3 of America us New York US-NY Business Corporation P10 Vice-chairman English Vice-chairman 2023-06-28 ACTV Corporation (BSC)\nCHAPTER 4 Business\nCorporation Law - 5.508\nNew York Consolidated\nUnited States . : ; Laws Bus.lness\nEXDZYK . us New York US-NY Business Corporation PJ10 Referee English Referee 2023-06-28 ACTV Corporation (BSC)\nof America .\nCHAPTER 4 Business\nCorporation Law - 5.1108\nNew York Consolidated\nUnited States . : ; Laws Bus.lness\nEZPUOB . us New York US-NY Business Corporation PJ10 Treasurer English Treasurer 2023-06-28 ACTV Corporation (BSC)\nof America .\nCHAPTER 4 Business\nCorporation Law - 5.508\nNew York Consolidated\nUnited States . : . ; : Laws Bus.lness\nGAKIEO . us New York US-NY Business Corporation PJ10 Chairman English Chairman 2023-06-28 ACTV Corporation (BSC)\nof America .\nCHAPTER 4 Business\nCorporation Law - 5.508\nNew York Consolidated\nH7RVEP United States ) New York Us-NY Limited Liability SDX0 Manager English Manager 2023-0628 | ACTV Laws CHAPTER 34 New\nof America Company York Limited Liability\nCompany Law - 5.102\nNew York Consolidated\nUnited States Laws Business\nHEGOCP of America us New York US-NY Business Corporation P10 Assistant treasurer English Assistant treasurer 2023-06-28 ACTV Corporation (BSC)\nCHAPTER 4 Business\nCorporation Law - 5.508\nNew York Consolidated\nHP108D United States | ;¢ New York Us-NY Limited Liability SDX0 Organizer English Organizer 2023-06-28 | ACTV Laws CHAPTER 34 New\nof America Company York Limited Liability\nCompany Law -5.203\nNew York Consolidated\nUnited States Laws Business\nIWVYWI . us New York US-NY Business Corporation PJ10 Authorized person English Authorized person 2023-06-28 ACTV Corporation (BSC)\nof America .\nCHAPTER 4 Business\nCorporation Law - 5.102\nNew York Consolidated\nNUQEZ8 United States | ;¢ New York Us-NY Limited Liability SDX0 Member English Member 2023-06-28 | ACTV Laws CHAPTER 34 New\nof America Company York Limited Liability\nCompany Law - 5.102\nNew York Consolidated\nUnited States . : ; Laws Bus.lness\nO5PYNY . us New York US-NY Business Corporation PJ10 Shareholder English Shareholder 2023-06-28 ACTV Corporation (BSC)\nof America .\nCHAPTER 4 Business\nCorporation Law - 5.505\nNew York Consolidated\nUnited States Laws Business\nS1ZHTS . us New York US-NY Business Corporation PJ10 Assistant secretary English Assistant secretary 2023-06-28 ACTV Corporation (BSC)\nof America .\nCHAPTER 4 Business\nCorporation Law - 5.508\nNew York Consolidated\nUnited States . . . . . Laws Bus.lness\nSMRSTY . us New York US-NY Business Corporation PJ10 President English President 2023-06-28 ACTV Corporation (BSC)\nof America .\nCHAPTER 4 Business\nCorporation Law - 5.508\nNew York Consolidated\nUnited States Laws Business\nuooizm . us New York US-NY Business Corporation PJ10 Chief executive officer English Chief executive officer CEO CEO 2023-06-28 ACTV Corporation (BSC)\nof America .\nCHAPTER 4 Business\nCorporation Law - 5.408\n97/119\n","contentLength":3886,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.741Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"New York Consolidated\nUnited States Laws Business\nUB0GZK . us New York US-NY Business Corporation PJ10 Interested shareholder English Interested shareholder 2023-06-28 ACTV Corporation (BSC)\nof America .\nCHAPTER 4 Business\nCorporation Law - 5.505\nNew York Consolidated\nUnited Stat Laws Business\nnited States i\nWP4K90 : us New York US-NY Business Corporation [ PJ10 Registered agent English Registered agent 2023-06-28 |ACTV Corporation (BSC)\nof America s ! o 9 9 o 9 CHAPTER 4 Business\nCorporation Law - 5.305\nNew York Consolidated\nUnited States Laws Business\nWUCT39 of America us New York US-NY Business Corporation PJ10 Subscriber English Subscriber 2023-06-28 ACTV Corporation (BSC)\nCHAPTER 4 Business\nCorporation Law - 5.503\nNew York Consolidated\nUnited States Laws Business\nXSZMKP of America us New York US-NY Business Corporation P10 Secretary English Secretary 2023-06-28 ACTV Corporation (BSC)\nCHAPTER 4 Business\nCorporation Law - 5.508\nNew York Consolidated\nUnited States . : : ; \" Laws BLIS.IHESS\nXXQSUN . us New York US-NY Business Corporation PJ10 Receiver English Receiver 2023-06-28 ACTV Corporation (BSC)\nof America .\nCHAPTER 4 Business\nCorporation Law - 5.503\nNew York Consolidated\nUnited States Laws Business\nZEDHGI . us New York US-NY Business Corporation PJ10 Vice-president English Vice-president VP VP 2023-06-28 ACTV Corporation (BSC)\nof America .\nCHAPTER 4 Business\nCorporation Law - 5.508\n2005 North Carolina\nUnited States Code: Ch. 55: North\n3MMZWH of America us North Carolina |US-NC Business Corporation 1QMT officer English officer 2023-06-28 ACTV Carolina Business\nCorporation Act - §\n55-1-20\n2005 North Carolina\nUnited States : . : : ; \" COdef ch. 55.: torth\n8PDQOB of America us North Carolina |US-NC Business Corporation 1QMT receiver English receiver 2023-06-28 ACTV Carolina Business\nCorporation Act - §\n55-7-23\n2005 North Carolina\nUnited States : . : \" ; : COdef ch. 55.: torth\nAPELNG of America us North Carolina |US-NC Business Corporation 1QMT chair English chair 2023-06-28 ACTV Carolina Business\nCorporation Act - §\n55-1-20\nNorth Carolina General\nBWPQPN United States ) North Carolina |US-NC Limited Liability X1EL organizer English organizer 2023-0628 | ACTV Statutes: Ch. 57D - North\nof America Company Carolina Limited Liability\nCompany Act 57D-1-03\n2005 North Carolina\nUnited States Code: Ch. 55: North\nCPW5GE of America us North Carolina |US-NC Business Corporation 1QMT president English president 2023-06-28 ACTV Carolina Business\nCorporation Act - §\n55-1-20\nNorth Carolina General\nEHGZUB United States ;o North Carolina |US-NC Limited Liability X1EL interest owner English interest owner 2023-06-28 |ACTV Statutes: Ch. 57D - North\nof America Company Carolina Limited Liability\nCompany Act 57D-1-03\n2005 North Carolina\nUnited States Code: Ch. 55: North\nF34HV7 of America us North Carolina |US-NC Business Corporation 1QMT voting trustee English voting trustee 2023-06-28 ACTV Carolina Business\nCorporation Act - §\n55-7-30\n2005 North Carolina\nUnited States Code: Ch. 55: North\nF5GQW7 of America us North Carolina |US-NC Business Corporation 1QMT incorporator English incorporator 2023-06-28 ACTV Carolina Business\nCorporation Act - §\n55-1-20\nNorth Carolina General\nUnited States \" Limited Liability \" \" \" Statutes: Ch. 57D - North\nFIERMQ of America us North Carolina |US-NC Company X1EL company official English company official 2023-06-28 ACTV Carolina Limited Liability\nCompany Act 57D-1-03\nNorth Carolina General\nHPEKMU United States | ;g North Carolina |US-NC Uimited Liability X1EL registered agent English registered agent 2023-06-28 |ACTV Statutes: Ch. 57D - North\nof America Company Carolina Limited Liability\nCompany Act 57D-2-40\nNorth Carolina General\nHSYSWT United States | ;¢ North Carolina |US-NC Limited Liability X1EL member English member 2023-06-28 | ACTV Statutes: Ch. 57D - North\nof America Company Carolina Limited Liability\nCompany Act 57D-1-03\n98/119\n","contentLength":3921,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.741Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"North Carolina General\njZDWTA United States ) North Carolina |US-NC Limited Liability X1EL receiver English receiver 2023-0628 | ACTV Statutes: Ch. 57D - North\nof America Company Carolina Limited Liability\nCompany Act 57D-1-20\n2005 North Carolina\nUnited States Code: Ch. 55: North\nKPW3SH of America us North Carolina |US-NC Business Corporation 1QMT registered agent English registered agent 2023-06-28 ACTV Carolina Business\nCorporation Act - §\n55-5-01\n2005 North Carolina\nUnited States Code: Ch. 55: North\nL431NF of America us North Carolina |US-NC Business Corporation 1QMT director English director 2023-06-28 ACTV Carolina Business\nCorporation Act - §\n55-1-20\nNorth Carolina General\nUnited States i Limited Liability . Statutes: Ch. 57D - North\nLINJJX of America us North Carolina |US-NC Company X1EL manager English manager Mar. 2023-06-28 ACTV Carolina Limited Liability\nCompany Act 57D-1-03\n2005 North Carolina\nUnited States Code: Ch. 55: North\nMHGDGW of America us North Carolina |US-NC Business Corporation 1QMT shareholder English shareholder 2023-06-28 ACTV Carolina Business\nCorporation Act - §\n55-1-42\n2005 North Carolina\nUnited States Code: Ch. 55: North\nU4SBHY of America us North Carolina |US-NC Business Corporation 1QMT beneficial owner English beneficial owner 2023-06-28 ACTV Carolina Business\nCorporation Act - §\n55-14-32\nNorth Carolina General\nVGHOQQ United States | ;g North Carolina |US-NC Limited Liability X1EL trustee English trustee 2023-06-28 |ACTV Statutes: Ch. 57D - North\nof America Company Carolina Limited Liability\nCompany Act 57D-1-20\n2005 North Carolina\nUnited States Code: Ch. 55: North\nXUEMSX of America us North Carolina |US-NC Business Corporation 1QMT assistant officer English assistant officer 2023-06-28 ACTV Carolina Business\nCorporation Act - § 55-8-\n40\nNorth Dakota Century\n\" . P Code: Title 10: Ch. 10-\n52GDRV United States |, North Dakota |US-ND {Business) Limited GHB2 treasurer English treasurer Treas. 2023-0628 |ACTV 32.1 - North Dakota\nof America Liability Company ; . PR\nUniform Limited Liability\nCompany Act 10-32.1-39\nNorth Dakota Century\n\" . P Code: Title 10: Ch. 10-\n52GDRV United States |, North Dakota |US-ND {Business) Limited GHB2 chief financial officer English chief financial officer cFo 2023-0628 |ACTV 32.1 - North Dakota\nof America Liability Company ; . PR\nUniform Limited Liability\nCompany Act 10-32.1-40\nNorth Dakota Century\nUnited States Code: Title 10: Ch. 19.1 -\n5CPVR2 of America us North Dakota US-ND (Business) Corporation S745 voting trustee English voting trustee 2023-06-28 ACTV North Dakota Business\nCorporation Act 10-19.1-\n81\nNorth Dakota Century\nUnited States Code: Title 10: Ch. 19.1 -\n6EYMQQ of America us North Dakota US-ND (Business) Corporation |S745 registered agent English registered agent 2023-06-28 ACTV North Dakota Business\nCorporation Act 10-19.1-\n10\nNorth Dakota Century\n\" . P Code: Title 10: Ch. 10-\nUnited Stat Bi Limited\n7FI6DX nited states ;5 North Dakota |US-ND (Business) Limite GHB2 receiver English receiver 2023-06-28 |ACTV 32.1 - North Dakota\nof America Liability Company ; o PR\nUniform Limited Liability\nCompany Act 10-32.1-89\nNorth Dakota Century\nUnited States Code: Title 10: Ch. 19.1 -\nAA5P7) of America us North Dakota US-ND (Business) Corporation S745 shareholder English shareholder 2023-06-28 ACTV North Dakota Business\nCorporation Act 10-19.1-\n01\nNorth Dakota Century\nUnited States Code: Title 10: Ch. 19.1 -\nBMAVGN . us North Dakota US-ND (Business) Corporation |S745 president English president Pres. 2023-06-28 ACTV North Dakota Business\nof America :\nCorporation Act 10-19.1-\n52\nNorth Dakota Century\nUnited States Code: Title 10: Ch. 19.1 -\nBMAVGN of America us North Dakota US-ND (Business) Corporation S745 chief executive officer English chief executive officer CEO 2023-06-28 ACTV North Dakota Business\nCorporation Act 10-19.1-\n52\nNorth Dakota Century\nUnited States Code: Title 10: Ch. 19.1 -\nFCGTSZ of America us North Dakota US-ND (Business) Corporation S745 beneficial owner English beneficial owner 2023-06-28 ACTV North Dakota Business\nCorporation Act 10-19.1-\n84\n99/119\n","contentLength":4106,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.742Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf","content":"North Dakota Century\nUnited States ) ) . Code: Title 10: Ch.. 19.1-\nFUQ81V of America us North Dakota US-ND (Business) Corporation S745 secretary English secretary Sec. 2023-06-28 ACTV North Dakota Business\nCorporation Act 10-19.1-\n52\nNorth Dakota Century\nUnited States Code: Title 10: Ch. 19.1 -\nHFOSXX . us North Dakota US-ND (Business) Corporation |S745 vice president English vice president VP 2023-06-28 ACTV North Dakota Business\np p p\nof America :\nCorporation Act 10-19.1-\n52\nNorth Dakota Century\n\" . P Code: Title 10: Ch. 10-\nUnited Stat Bi Limited\nJF34WU of e |us North Dakota | US-ND L:;'I'i‘;s?m']m;:y GHB2 president English president Pres. 20230628 |ACTV 32.1- North Dakota\nP Uniform Limited Liability\nCompany Act 10-32.1-42\nNorth Dakota Century\n\" . P Code: Title 10: Ch. 10-\nUnited Stat Bi Limited\nJF34WU of”:;‘eri CZ e us North Dakota |US-ND L:;'I'i‘;s?m']m;:y GHB2 chief executive officer English chief executive officer cEO 2023-06-28 |ACTV 32.1 - North Dakota\nP Uniform Limited Liability\nCompany Act 10-32.1-43\nNorth Dakota Century\nUnited States Code: Title 10: Ch. 19.1 -\nKXF1AO of America us North Dakota US-ND (Business) Corporation |S745 subscriber English subscriber 2023-06-28 ACTV North Dakota Business\nCorporation Act 10-19.1-\n01\nNorth Dakota Century\nUnited States Code: Title 10: Ch. 19.1 -\nMUMGHY of America us North Dakota US-ND (Business) Corporation S745 treasurer English treasurer Treas. 2023-06-28 ACTV North Dakota Business\nCorporation Act 10-19.1-\n52\nNorth Dakota Century\nUnited States . . . . . . . Code: Title 10: Ch. 19.1 -\nMUMGHY of America us North Dakota US-ND (Business) Corporation S745 chief financial officer English chief financial officer CFO 2023-06-28 ACTV North Dakota Business\nCorporation Act 10-19.1-\n52\nNorth Dakota Century\n\" . P Code: Title 10: Ch. 10-\nUnited Stat Bi Limited\nOX8GCT nited states ;5 North Dakota |US-ND (Business) Limite GHB2 trustee English trustee 2023-06-28 |ACTV 32.1 - North Dakota\nof America Liability Company ; o PR\nUniform Limited Liability\nCompany Act 10-32.1-89\nNorth Dakota Century\n\" . P Code: Title 10: Ch. 10-\nUnited Stat Bi Limited\nPQP7ME oplArenericaa e us North Dakota |US-ND L:;'I'i‘;s?m']m;:y GHB2 liquidating trustee English liquidating trustee 2023-06-28 |ACTV 32.1 - North Dakota\nP Uniform Limited Liability\nCompany Act 10-32.1-102\nNorth Dakota Century\n\" . P Code: Title 10: Ch. 10-\nUnited Stat Bi Limited\nPTNHWG nited states ;5 North Dakota |US-ND (Business) Limite GHB2 owner English owner 2023-06-28 |ACTV 32.1 - North Dakota\nof America Liability Company ; o PR\nUniform Limited Liability\nCompany Act 10-32.1-06\nNorth Dakota Century\n\" . P Code: Title 10: Ch. 10-\nUnited Stat Bi Limited\nRBPLLH oplArenericaa e us North Dakota |US-ND L:;'I'i‘;s?m']m;:y GHB2 governor English governor Gov. 2023-06-28 |ACTV 32.1 - North Dakota\nP Uniform Limited Liability\nCompany Act 10-32.1-02\nNorth Dakota Century\nUnited States Code: Title 10: Ch. 19.1 -\nRG3BHN of America us North Dakota US-ND (Business) Corporation S745 owner English owner 2023-06-28 ACTV North Dakota Business\nCorporation Act 10-19.1-\n01\nNorth Dakota Century\n\" . P Code: Title 10: Ch. 10-\nS6IKEI gf”';reriitcztes us North Dakota |US-ND fi:kfi'l?;s?o'r‘r\"m::;’ GHB2 member English member 2023-0628 |ACTV 32.1 - North Dakota\nP Uniform Limited Liability\nCompany Act 10-32.1-04\nNorth Dakota Century\n\" . P Code: Title 10: Ch. 10-\nT22MOA United States |, North Dakota |US-ND {Business) Limited GHB2 manager English manager Mar. 2023-0628 |ACTV 32.1 - North Dakota\nof America Liability Company ; . PR\nUniform Limited Liability\nCompany Act 10-32.1-03\nNorth Dakota Century\n\" . P Code: Title 10: Ch. 10-\nVYWS50Y United States |, North Dakota |US-ND {Business) Limited GHB2 registered agent English registered agent 2023-0628 |ACTV 32.1 - North Dakota\nof America Liability Company ; . PR\nUniform Limited Liability\nCompany Act 10-32.1-16\nNorth Dakota Century\nUnited States Code: Title 10: Ch. 19.1 -\nWJGYSL of America us North Dakota US-ND (Business) Corporation S745 officer English officer 2023-06-28 ACTV North Dakota Business\nCorporation Act 10-19.1-\n01\n100/119\n","contentLength":4107,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:09:49.742Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/gleif-accepted-legal-jurisdictions-code-list/gleif_acceptedjurisdictions_v1.4.pdf","content":"Legal Jurisdictions\nVersion 1.4\nFebruary 2022\n","contentLength":46,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:10:05.860Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/gleif-accepted-legal-jurisdictions-code-list/gleif_acceptedjurisdictions_v1.4.pdf","content":"Sagedoen __——————————————————————— @,y Jowmwooy, ]\nse_——————————————————————@y ooy ]\nsg__—————— ooy ]\nsomige _————————— ooy ]\n[Bolvia Planatonar Statecy ———————————————————— % ————————————————————————————————— o oony_—_——————————————————————————————]\n[Borare, S Eustats and Sabg_—_———————————————————pg ——— ooy\nooy ]\nroie. ———— oo Jowmwony ]\n[Domiean Repablo e —————————————————————————— @ Jeowmwooy __—_——————————————————————————————]\n2/5\n","contentLength":440,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:10:05.860Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/gleif-accepted-legal-jurisdictions-code-list/gleif_acceptedjurisdictions_v1.4.pdf","content":"meoresa ——— 0 0000 Jjeewwony____\nwoerg ———— 00 oo fjeowwoy____\ne ———— e fjewwwo~y____\nweorver —————0 00 0000 Jewwo~y____\noz ———— ooy\n[Brtsh Tnan Ocean Teroy o) __———————————— 0 00— 10— oo fjee~nwony\ng % ooy\n[van sl Regupltocy —————————————————————————— w0 fjeev’owvony\n[Voldova e Republo ___—————————————————————————wp, ————————————————————————————————————Joowomwony,____——————————————————————————|\ne Joowwoy_ |\nwaer _———————————————————————————— . Joowmwvony,_____————————————————————————|\nworgora ___—————— W Joomwvony______——————————————————————————————|\nwe?o ————————— o Jowmwony,____—————————————————————————————|\n[Norhern WVertana trelo Gho) __—————————————————————————————————————wp ——————————————————————————————————————Joowomwony,___—_———————————————————————————|\nweorterey, __——— ———————————fw —————————————————————————————————Jowomwony,_ __——————————————————————————————|\noacz.__—————— . Joowmwony, ___——————————————————————————\nvy __————————————————————————————————————Jowmwony, ___————————————————————————————\n355\n","contentLength":1029,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:10:05.860Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/gleif-accepted-legal-jurisdictions-code-list/gleif_acceptedjurisdictions_v1.4.pdf","content":"o ——— ooy ]\ne TJoowwow\n[Saim Prre ama whgoelon __—_——————— \" _———————————————————————————————————————Jowmwy ooy __—_——————————————————————————————]\nFeetomi(oe _—————————————————————— 0 e Jowwowy ]\nooy ]\nForariy —————————— g ooy\na5\n","contentLength":231,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:10:05.860Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/about-lei/code-lists/gleif-accepted-legal-jurisdictions-code-list/gleif_acceptedjurisdictions_v1.4.pdf","content":"5/5\n","contentLength":4,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:10:05.860Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-verifiable-lei-vlei/2023-04-03_vlei-q-a-updated_v1.1_final.pdf","content":"@’ Enatblillg glzpc_:il:icllintiiy\nvLEI Q&A\nPublic\nVersion 1.1\n2023-04-03\n| | e o/ \"’\nL ’i’ ~ 3 * ’ ,\n, 3849.60 - - ’J; S— 'q ‘\n.\\ “a “ N’\\j\" \"‘ i~ o © '. % . : :\n.- .: ‘r ('\\‘ }03 {Z’({ ' b4 ...‘ ‘ .. 3 . ]\noL = J . ‘ A ° A W - :\n. * = ‘ . ’ :\nPN\n","contentLength":248,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:10:55.129Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-verifiable-lei-vlei/2023-04-03_vlei-q-a-updated_v1.1_final.pdf","content":"Questions and Answers regarding the verifiable LEI (vLEI)\nHow can the LEIl and the vLEl solve identity and authentication challenges?\nUsing the LEI within the vLEI will address the need for secure, certain and verifiable organizational\nidentity. When dealing business to business, business to consumer and private sector to public\nsector, it is critical to know with certainly the entity with which you are dealing.\nWe all are familiar with the negative realities of not knowing with certainty the entity with which you\nare dealing - identity impersonation, fraud, social engineering in the form of phishing/smishing and\nrobocalls.\nThe LEI as a unique, permanent and persistent identifier based on an international standard can be\nuseful as our world undergoes digital transformation\n— Digital engagement\n— Digital transactions\n— In both ‘local’ and ‘global’ interactions\nWith the VLEI, there an opportunity for secure, verifiable organizational identity to be realized more\ncheaply, with certainty, by leveraging improvements in automated cryptographic verification with\nthe potential to decrease, and in some cases, eliminate risks.\nThe vLEI will give public sector government entities, companies and consumers worldwide the\ncapacity to use the LEI's non-repudiable identification data in a growing number of digital business\nactivities, such as approving business transactions and contracts, onboarding customers, transacting\nwithin import/export and supply chain business networks and submitting regulatory filings and\nreports.\nMore information is included in the Press Release about the launch of the vLEI Ecosystem and\nInfrastructure in December 2022: https://www.gleif.org/en/newsroom/press-releases/first-suite-of-\nvlei-services-to-enable-digital-signing-and-automated-verification-of-corporate-caller-ids\nWhat makes GLEIF the ‘Root of trust’ for the vLEI?\nGovernance has been an important cornerstone of the Global LEI System and in the establishing\nGLEIF's role in operating and managing this system of LEls. GLEIF is subject to oversight by global\nregulators and according to our statutes has established strong governance for the process of\nvalidating legal entities for LEl issuance and the maintenance and updating of legal entity reference\ndata\nBuilding on this strong governance which begins with the issuance and maintenance of the LEl itself,\nGLEIF will be the anchor of the VLEI ecosystem, at the root of the governance that will position the\nLEl as a key component in building a trust layer for identification and verification of legal entities as\nthe LEI allows authentication that the legal entity is indeed who it claims to be and that those who\nact on its behalf, can.\nPage 2 of 17\n@ Public Version 1.1\n2023-04-03_vLEI-Q&A-updated_v1.1_Final 2023-04-03\n","contentLength":2777,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:10:55.130Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-verifiable-lei-vlei/2023-04-03_vlei-q-a-updated_v1.1_final.pdf","content":"What is the nested delegation that KERI uses?\nThere are two types of delegation:\n\n— Delegated AIDs (Autonomic Identifiers (AlDs) which have associated Decentralized Identifier\n(DIDs). These are primary identifiers. Unless otherwise indicated, whenever the term\nidentifier is used with reference to KERI, the references are to primary identifiers.\n\n— Delegated Authentic Chained Data Container (ACDC) credentials, the credential type used for\nVLEls, in which an LEI code is an attribute of a vLEI. A LEIl code is a secondary identifier.\n\nDelegated AlIDs use cooperative delegation. Delegated ACDCs (vLEls) do not use cooperative\ndelegation.\nAn ACDC (VLEl) is issued by a DID (derived from an AID) and issued to a DID (derived from an AID).\nThus a delegated vLEl issuance has an issuer and a holder. However, the DIDs for the issuer and\nholder of this delegated vLEI may or may not be related via a cooperative AID delegation.\nUsually cooperative AIDs are based on some formal relationship such as employer-employee or other\naffiliation like GLEIF and its VvLEI Issuers. The cooperation relationship imposes friction but with the\nreward of enhanced security.\nDelegation of ACDCs (vLEIls) are non-cooperative delegations. Thus, they could always be used to\nprovenance any VLElI and any data within the vLEI without imposing a cooperation relationship on the\ndelegation parties.\nNested delegation can store keys in a less secure manner but be protected by the delegator’s key\nmanagement infrastructure. This allows higher performance by delegated infrastructure without\nsacrificing ultimate security. See the following for a more detailed discussion of the advantages of\nnested delegation:\nhttps://github.com/SmithSamuelM/Papers/blob/master/whitepapers/IdentifierTheory web.pdf\nGlossary of Additional KERI Terms\nA subset of KERI terms is provided below for convenience. A full description of all KERI terminology is\nbeyond the scope of this document but may be found in the KERI White Paper here:\nhttps://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI WP.web.pdf\nPage 11 of 17\n@ Public Version 1.1\n2023-04-03_vLEI-Q&A-updated_v1.1_Final 2023-04-03\n","contentLength":2157,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:10:55.130Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-verifiable-lei-vlei/2023-04-03_vlei-q-a-updated_v1.1_final.pdf","content":"Duplicitous Event Log\nA Duplicitous Event Log (DEL) is record of inconsistent event messages produced by a given\nController or Witness with respect to a given KERL. The duplicitous events are indexed to the\ncorresponding event in a KERL. A duplicitous event is represented by a set of two or more provably\nmutually inconsistent event messages with respect to a KERL. Each Watcher keeps a DEL for each\nController and all designated Witnesses with respect to a KERL. Any Validator may confirm duplicity\nby examining a DEL.\nTransferable (Non-transferable) Identifier\nA Transferable (Non-transferable) Identifier allows (dis-allows) transfer of its control authority from\nthe current set of controlling keys to a new (next or ensuing) set via a rotation event (see below). An\nidentifier may be declared non-transferable at inception in its derivation code and/or in its inception\nevent (see below). Derivation code declaration is defined only for basic self-certifying identifiers. A\nrotation event (operation) on a transferable identifier may rotate to a null key thereby irreversibly\nconverting it into a Non-transferable Identifier. Once an identifier becomes non-transferable, no\nmore events are allowed for that identifier. The identifier is effectively abandoned from the\nstandpoint of KERI. By convention, when non-transferability of an identifier is declared in its\nderivation code then its authoritative (signing) key-pair may be converted to an encryption key-pair\nto enable a self-contained bootstrap to a secure communications channel using only the exchange of\nthe non-transferable identifier. Although a non-transferable identifier is abandoned from the\nstandpoint of KERI, it does not preclude a given application from employing the identifier. It is just\nthat no more events within KERI are allowed on the identifier (see event definition below). An\nidentifier declared at inception as non-transferable may have one and only one event, that is, the\ninception event. In this sense, a Non-transferable Identifier at inception is pre-abandoned. These\nidentifiers are typically meant to be used as ephemeral identifiers or identifiers where replacement\nof the identifier instead of key rotation is the preferred approach when the identifier becomes\ncompromised.\nCooperative Delegation\nA delegation or identifier delegation operation is provided by a pair of events. One event is the\ndelegating event and the other event is the delegated event. This pairing of events is a somewhat\nnovel approach to delegation in that the resultant delegation requires cooperation between the\ndelegator and delegate. This is called Cooperative Delegation. In a Cooperative Delegation, a\ndelegating identifier performs an establishment operation (inception or rotation) on a delegated\nidentifier. A delegating event is a type of event that includes in its data payload an event seal of the\ndelegated event that is the target the delegation operation. This delegated event seal includes a\ndigest of the delegated event.\nDelegating Event Message\nT\nFigure: Delegating Event\nPage 12 of 17\n@ Public Version 1.1\nO 2023-04-03_vLEI-Q&A-updated_v1.1_Final 2023-04-03\n","contentLength":3148,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:10:55.130Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-verifiable-lei-vlei/2023-04-03_vlei-q-a-updated_v1.1_final.pdf","content":"Delegated Event Seal\nm event digest\nFigure: Delegated Event Seal\nLikewise, the targeted delegated event has a delegating event location seal that includes the unique\nlocation of the delegating event.\nDelegated Event Message\n\" 0 \" h\ndelegation seal(s) | signatures |\nN~ — 7\nFigure: Delegated Event\nDelegating Event Location Seal\not [on| it | proi\nFigure: Delegating Event Location Seal\nThe pair of seals cross-reference the two events participating in the cooperative delegation\noperation. In general, we may refer to both delegating and delegated event seals as delegation event\nseals or delegation seals. A delegation seal is either an event seal or an event location seal. The\ndelegating event seal is an event location seal and a delegated event seal is an event seal. The\ndelegated event seal in the delegating event provides an anchor to the delegated event. Likewise,\nthe delegating event location seal in the delegated event provides an anchor back to the delegating\nevent.\nBecause the delegating event payload is a list, a single delegating event may perform multiple\ndelegation operations, one per set of delegation seals.\nDelegating Event Data\nData (Seals) ‘\nDelegaled Event Seal _\n’ header ‘ configuration prefix | sn ‘ event digest | signatures\nFigure: Delegating Event Data\nDelegated Establishment Event Data\nDelegation Delegating Location Seal\nEanne\nFigure: Delegated Event Data\nA delegation operation directly delegates an establishment event, either an inception or rotation.\nThus, a delegation operation may either delegate an inception or delegate a rotation that\nrespectively may create and rotate the authoritative keys for delegated self-certifying identifier\nprefix.\nPage 13 of 17\n@ Public Version 1.1\n2023-04-03_vLEI-Q&A-updated_v1.1_Final 2023-04-03\n","contentLength":1774,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:10:55.130Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-verifiable-lei-vlei/2023-04-03_vlei-q-a-updated_v1.1_final.pdf","content":"The delegated identifier prefix is a type of self-addressing self-certifying prefix. This binds the\ndelegated identifier to its delegating identifier. The delegating identifier controller retains\nestablishment control authority over the delegated identifier in that the new delegated identifier\nmay only authorize non-establishment events with respect to itself. Delegation therefore authorizes\nsigning authority that can be revoked to some other self-certifying identifier. The delegated identifier\nmay have its own delegated key event sequence where the inception event is a delegated inception\nand any rotation events are delegated rotation events. Control authority for the delegated identifier\ntherefore requires verification of a given delegated establishment event which in turn requires\nverification of the delegating identifier’s establishment event subsequence.\nTo reiterate, because the delegation seal in the data payload of the delegating event includes a\ndigest of the full delegated event, it thereby provides a forward cryptographic commitment to the\ndelegated identifier as well as any permissions and other configuration data in its associated event.\nThe delegation seal included in the delegated event provides a backward reference to the delegating\nevent’s unique location. This uniquely establishes which event in the delegating event log holds the\ncorresponding seal. This provides a type of cross reference that enables a verifier to look up the\ndelegating event and verify the existence of the delegation seal in the list of seals in that delegating\nevent and then verify that the event seal digest is a digest of the delegated event.\nA common use case of delegation would be to delegate signing authority to a new identifier prefix.\nThe signing authority may be exercised by a sequence of signing keys that are able to be revoked\ndistinct from the keys used for the root identifier. This enables horizontal scalability of signing\noperations. The other major benefit of a cooperative delegation is that any exploiter that\ncompromises only the delegate’s authoritative keys may not thereby capture control authority of the\ndelegate. A successful exploiter must also compromise the delegator’s authoritative keys. Any exploit\nof the delegate is recoverable by the delegator. Conversely, merely compromising the delegator’s\nsigning keys may not enable a delegated rotation without also compromising the delegates pre-\nrotated keys. Both sets of keys must be compromised simultaneously. This joint compromise\nrequirement is a distinctive security feature of cooperative delegation. Likewise as explained later,\nthis cooperative feature also enables recovery of a joint compromise of a delegation at any set of\ndelegation levels by a recovery at the next higher delegation level.\nOne reason to use rotations for delegation is for enhanced security. A rotation event is a first time\nuse of the pre-rotated keys to sign an event. The distinction between an interaction event rotating a\ndelegated identifier’s keys and a rotation event rotating a delegated identifier’s keys is that the latter\nenables nested recovery of a compromise of the delegate’s keys, even its pre-rotated keys. A\nrotation event may be used to supersede an interaction event. When this happens the key event log\nforks at the superseding rotation event. With delegated events this means recovery is enabled even\nin the event of the joint compromise of a delegating identifier’s signing keys and the delegated\nidentifiers pre-rotated keys. The delegating identifier merely needs to perform a rotation event that\nprovides a superseding rotation of the interaction event used to delegate a rotation of the delegate.\nThis superseding rotation also performs a superseding rotation of the delegates rotation. This nested\nrecovery may be applied to multiple levels of delegation. A rotation at the next higher level of\ndelegation may be used to recover from key compromise across any set of lower levels of delegation.\nPage 14 of 17\n@ Public Version 1.1\nO 2023-04-03_vLEI-Q&A-updated_v1.1_Final 2023-04-03\n","contentLength":4087,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:10:55.130Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-verifiable-lei-vlei/2023-04-03_vlei-q-a-updated_v1.1_final.pdf","content":"Seal\nA seal is a cryptographic commitment in the form of a cryptographic digest or hash tree root (Merkle\nroot) that anchors arbitrary data or a tree of hashes of arbitrary data to a particular event in the key\nevent sequence. According to the dictionary, a seal provides evidence of authenticity. A key event\nsequence provides a verifiable proof of current control authority at the location of each event in the\nkey event sequence. In this sense therefore, a seal included in an event provides proof of current\ncontrol authority, i.e., authenticity of the data anchored at the location of the seal in the event\nsequence. A seal is an ordered self-describing data structure. Abstractly, this means each element of\nthe seal has a tag or label that describes the associated element’s value. So far there are four\nnormative types of seals - these are digest, root, event, and location seals.\nA digest seal includes a digest of external data. This minimal seal has an element whose label\nindicates that the value is a digest. The value is fully qualified Base64 with a prepended derivation\ncode that indicates the type of hash algorithm used to create the digest.\nDigest Seal\ndigest\nFigure: KERI Digest Seal\nA root seal provides the hash tree root of external data. This minimal seal has an element whose\nlabel indicates that the value is the root of a hash tree. The value is fully qualified Base64 with a\nprepended derivation code that indicates the type of hash algorithm used to create the hash root. In\norder to preclude second pre-image attacks, hash trees used for hash trees roots in KERI seals must\nbe sparse and of known depth similar to certificate transparency. One simple way to indicate depth is\nthat internal nodes in a sparse tree include a depth prefix that decrements with each level and must\nremain non-negative at a leaf.\nHash Tree Root Seal\nroot\nFigure: KERI Root Seal\nAn event seal includes the identifier prefix, sequence number, and digest of an event in a key event\nlog. The prefix, sequence number, and digest allow locating the event in an event log database. The\ndigest also allows confirmation of the anchored event contents. An event seal anchors one event to\nanother event. The two events may be either in the same key event sequence in two different key\nevent sequences with different identifier prefixes. Thus, a seal may provide a cryptographic\ncommitment to some key event from some other key event.\nEvent Seal\nprefix | sn | digest\nFigure: KERI Event Seal\nAn event location seal is similar to an event seal. A location seal includes the prefix, sequence\nnumber, ilk and prior digest from an event. These four values together uniquely identify the location\nof an event in a Key Event Log. A location event is useful when two seals in two different events are\nPage 15 of 17\n@ Public Version 1.1\n2023-04-03_vLEI-Q&A-updated_v1.1_Final 2023-04-03\n","contentLength":2874,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:10:55.130Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-verifiable-lei-vlei/2023-04-03_vlei-q-a-updated_v1.1_final.pdf","content":"cross-anchoring each other. This provides a cross reference of one event to another where the other\nevent’s digest must include the seal in the event contents so it cannot contain the first event’s digest\nbut the digest of the preceding event.\nTo clarify, digest creation means that only one of the cross anchors can include a complete digest of\nthe other event. The other cross anchor must use a unique subset of data such as the unique location\nof the event. The ilk is required in the location because of the special case of recovery where a\nrotation event supersedes an interaction event. This is described in detail in the white paper under\nrecovery. Location seals are also useful in external data that is anchored to an event log. The location\nseal allows the external data to include a reference to the event that is anchoring the external data’s\ncontents. Because the anchoring event includes a seal with the digest of the external data, it is\nanother form of cross anchor.\nEvent Location Seal\not o0 1 dgest |\nFigure: KERI Event Location Seal\nThe data structure that provides the elements of a seal must have a canonical order so that it may be\nreproduced in a digest of elements of an event. Different types of serialization encodings may\nprovide different types of ordered mapping data structures. One universal canonical ordering data\nstructure is a list of lists (array or arrays) of (label, value) pairs. The order of appearance in each list of\neach (label, value) pair is standardized and may be used to produce a serialization of the associated\nvalues.\nThe interpretation of the data associated with the digest or hash tree root in the seal is independent\nof KERI. This allows KERI to be agnostic about anchored data semantics. Another way of saying this is\nthat seals are data agnostic; they do not care about the semantics of the associated data. This better\npreserve privacy because the seal itself does not leak any information about the purpose or specific\ncontent of the associated data. Furthermore, because digests are a type of content address, they are\nself-discoverable. This means there is no need to provide any sort of context or content specific tag\nor label for the digests. Applications that use KERI may provide discovery of a digest via a hash table\n(mapping) whose indexes (hash keys) are the digests and the values in the table are the location of\nthe digest in a specific event. To restate, the semantics of the digested data are not needed for\ndiscovery of the digest within a key event sequence.\nTo elaborate, the provider of the data understands the purpose and semantics and may disclose\nthose as necessary, but the act of verifying authoritative control does not depend on the data\nsemantics, merely the inclusion of the seal in an event. It is up to the provider of the data to declare\nor disclose the semantics when used in an application. This may happen independently of verifying\nthe authenticity of the data via the seal. This declaration may be provided by some external\nApplication Program Interface (API) that uses KERI. In this way, KERI provides support to applications\nthat satisfies the spanning layer maxim of minimally sufficient means. Seals merely provide evidence\nof authenticity of the associated (anchored) data whatever that may be.\nPage 16 of 17\n@ Public Version 1.1\nO 2023-04-03_vLEI-Q&A-updated_v1.1_Final 2023-04-03\n","contentLength":3384,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:10:55.130Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-verifiable-lei-vlei/2023-04-03_vlei-q-a-updated_v1.1_final.pdf","content":"This approach follows the design principle of context independent extensibility. Because the seals are\ncontext agnostic, the context is external to KERI. Therefore, the context extensibility is external to,\nand hence, independent of KERI. This is in contrast to context dependent extensibility or even\nindependently extensible contexts that use extensible context mechanisms such as linked data or tag\nregistries. Context independent extensibility means that KERI itself is not a locus of coordination\nbetween contexts for anchored data. This maximizes decentralization and portability.\nExtensibility is provided instead at the application layer above KERI though context specific external\nAPIs that reference KERI seals in order to establish control authority, and hence, authenticity of the\nanchored (digested) data. Each API provides the context, not KERI. This means that interoperability\nwithin KERI is focused solely on interoperability of control establishment. But that interoperability is\ntotal and complete and is not dependent on anchored data context.\nPage 17 of 17\n@ Public Version 1.1\nO 2023-04-03_vLEI-Q&A-updated_v1.1_Final 2023-04-03\n","contentLength":1151,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:10:55.130Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-verifiable-lei-vlei/2023-04-03_vlei-q-a-updated_v1.1_final.pdf","content":"To document the governance for the vLEI Ecosystem and Infrastructure, GLEIF chose the to leverage\n\nthe Ecosystem Governance Framework of the Trust over IP Foundation (/ink to TolP website), which\n\nGLEIF joined as a Contributor member at its inception.\n\nThe TolP Technology Stack covers technical trust. The TolP Governance Stack covers human\n\ntrust which includes an Ecosystem Governance Framework which documents requirements at the\n\nbusiness, legal, and social layers. To the Self-Sovereign Identity experts engaged in TolP, the LEl, as a\n\nkey component in building a trust layer and technical infrastructure for identification and verification\n\nof organizations, is the basis for a textbook example of being able to satisfy organizational identity\n\nrequirements for any number of use cases or domains through the use of vLEls.\n\nAlso, see the related question in the Technical Question section below, ‘How was GLEIF established\n\nas the root-of-trust for the vLEI ecosystem?’\n\nPage 3 of 17\n\nGLEIF Public Version 1.1\n\n@ 2023-04-03_vLEI-Q&A-updated_v1.1_Final 2023-04-03\n","contentLength":1070,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:10:55.130Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-verifiable-lei-vlei/2023-04-03_vlei-q-a-updated_v1.1_final.pdf","content":"Technical Questions regarding the vLEI Ecosystem Infrastructure\nWhat does GLEIF see as important technical features that the technical solution for vLEI ecosystem\ninfrastructure must have?\nGLEIF think that the technical solution for vLEIl ecosystem infrastructure must be interoperable and\nportable.\n* Open source/non-proprietary\n* Interoperable\n* Works with all technical solutions — blockchain/Distributed Ledger Technology (DLT)\nas well as cloud-based solutions\nIncorporating these features would allow the vLEl infrastructure to be integrated with existing\nimplementations/use cases using blockchain/DLT technology without the users needing to abandon\ntheir existing technical solutions. The new approach also could accommodate existing and new\nimplementations not based on blockchain/DLT technology. GLEIF anticipates interfaces of the vLEl\ntechnical infrastructure to Hyperledger, Ethereum, Quorum and Corda based networks as well as\ncloud applications.\nWhat is KERI (Key Event Receipt Infrastructure)?\nKey Event Receipt Infrastructure (KERI) is a ledgerless approach to identity that enables a universal\ndecentralized key management infrastructure (DKMI). KERI takes the objectives that conventional\nPublic Key Infrastructure (PKI) tries to achieve with centralized, administrative roots of trust and\nachieves them with decentralized, cryptographic roots of trust. This solves many problems: security,\nprivacy, scalability, performance, cost, governance, and more. (Link to KERI white paper: Smith, S.\nM., “Key Event Receipt Infrastructure (KERI) Design”, Revised 2020/09/06, 2019/07/03)\nWhat Decentralized Identifier (DID) methods will the vLEl infrastructure use?\nAs part of supporting the vLEI ecosystem, GLEIF is shepparding the development of the did:keri DID\nMethod. This will be a native DID method that will leverage the GLEIF provided Witnesses and\nWatchers (these KERI roles are described below) for discovery. The native did:keri method provides\na compatibility hook for DID Resolvers allowing any application that requires a fully complaint DID\nDocument can receive one for the KERI identifiers of the vLEIl ecosystem. Integration with KERI\nWitnesses and Watchers provides discovery of any identifier that is known to those components.\nEcosystems (like the vLEI) can have global “Super Watchers” that monitor the entire ecosystem to\nprovide visibility of all relevant identifiers.\nA VLEI “Super Watcher” will be made available by GLEIF to provide this access for anyone interested\nin resolving the key state of any identifier. Anyone interested in receiving DID Documents for a vLElI\nidentifier can run an instance of the did:keri did method resolver pointing at this vLEI “Super\nWatcher”.\nPage 4 of 17\n@ Public Version 1.1\nO 2023-04-03_vLEI-Q&A-updated_v1.1_Final 2023-04-03\n","contentLength":2796,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:10:55.130Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-verifiable-lei-vlei/2023-04-03_vlei-q-a-updated_v1.1_final.pdf","content":"Click here for the link to the W3C DID standard.\nWhat are the roles in the KERI design?\nController\nA Controller is a controlling entity of an identifier. At any point in time an identifier has at least one\nbut may have more than one controlling entity. Let L be the number of controlling entities. This set of\ncontrolling entities constitute the Controller. All proper key management events on the identifier\nmust include a signature from the sole controlling entity when there is only one member in the set of\ncontrolling entities or a least one signature from one of the controlling entities when there is more\nthan one. This signature may be expressed as a single collective signature when a collective signing\nscheme is used. Without loss of generality, when the context is unambiguous, the term Controller\nmay refer either to the whole set or a member of the set of controlling entities.\nTypically, when there is more than one controlling entity, control is established via L signatures, one\nfrom each entity Controller. This is called multi-signature or multi-sig for short. Alternatively, with a K\nof L threshold control scheme, where K < L, control is established via any set of at least K signatures\neach one from a subset of at least size K of the L Controllers. A more sophisticated scheme may use\nfractional weighted multiple signatures. These multiple signatures under a threshold control scheme\nmay be expressed as a single collective threshold signature from an appropriate collective threshold\nsigning scheme. The description of the KERI protocol assumes the simplest case of individual not\ncollective signatures, but it is anticipated that the protocol may be extended to support collective\nmulti-signature schemes.\nVerifier\nA Verifier is an entity or component that cryptographically verifies the signature(s) on an event\nmessage. In order to verify a signature, a Verifier must first determine which set of keys are or were\nthe controlling set for an identifier when an event was issued. In other words, a Verifier must first\nestablish control authority for an identifier. For identifiers that are declared as non-transferable at\ninception this control establishment merely requires a copy of the inception event for the identifier.\nFor identifiers that are declared transferable at inception this control establishment requires a\ncomplete copy of the sequence of key operation events (inception and all rotations) for the identifier\nup to the time at which the statement was issued.\nValidator\nA Validator is an entity or component that determines that a given signed statement associated with\nan identifier was valid at the time of its issuance. Validation first requires that the statement is\nverifiable, that is, has a verifiable signature from the current controlling key-pair(s) at the time of its\nissuance. Therefore, a Validator must first act as a Verifier in order to establish the root authoritative\nset of keys. Once verified, the Validator may apply other criteria or constraints to the statement in\norder to determine its validity for a given use case. This use-case specific validation logic may be\nassociated with interaction event statements.\nPage 5 of 17\nGLEIF Public Version 1.1\n@ 2023-04-03_vLEI-Q&A-updated_v1.1_Final 2023-04-03\n","contentLength":3268,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:10:55.130Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-verifiable-lei-vlei/2023-04-03_vlei-q-a-updated_v1.1_final.pdf","content":"Witness\nA Witness is an entity or component designated (trusted) by the Controller of an identifier. The\nprimary role of a Witness is to verify, sign, and keep events associated with an identifier. A witness is\nthe Controller of its own self-referential identifier which may or may not be the same as the\nidentifier to which it is a Witness. As a special case a Controller may serve as its own Witness.\nWitness designations are included in key (establishment) events. As a result, the role of a Witness\nmay be verified using the identifier’s rotation history. When designated, a Witness becomes part of\nthe supporting infrastructure establishing and maintaining control authority over an identifier. An\nidentifier Witness therefore is part of its trust basis and may be controlled (but not necessarily so) by\nits Controller.\nThe purpose of a pool of Witnesses is to protect the Controller from external exploit of its identifier.\nA Witness may use the controlling key-pairs of its own self-referential identifier to create digital\nsignatures on event messages it has received but are associated with identifiers not necessarily\nunder its control. To clarify, a Witness controls its own self-referential identifier and acts as a witness\nof event messages for some identifier not necessarily under its control. A Witness may receive,\nverify, and store an event on an identifier. Verify means verify the signature attached to the event\nusing the current controlling key-pairs for the event at the time of event issuance.\nThus, a Witness first acts as an event Verifier. It determines current control authority of the event’s\nidentifier with respect to the sequence of key (establishment) events it has so far received for that\nidentifier. The Witness follows a policy explained in more detail later for how it treats different\nversions of an event it may receive. Simply, it always gives priority to the first version of an event it\nreceives (first seen). The Witness signifies this by only signing and keeping the first successfully\nverified version of an event it receives. To restate, a Witness will never sign any other conflicting\nversion of the same event in an event sequence. The event sequence kept by a Witness for an\nidentifier must therefore be internally consistent.\nWatcher\nA Watcher is an entity or component that keeps a copy of a Key Event Receipt Log (KERL) for an\nidentifier but is not designated by the Controller thereof as one of its Witnesses. To clarify, a\nWatcher is not designated in the associated identifier’s key events. A Watcher is the Controller of its\nown self-referential identifier which may not be the same as the identifier to which it is a Watcher.\nAn identifier Watcher may be part of the trust basis of a Validator and may also be controlled (but\nnot necessarily so) by the Validator’s controlling entity. A Watcher may sign copies of its KERL or\nparts of its KERL but because a Watcher is not a designated Witness these are not witnessed receipts.\nThey may be considered Watcher receipts or ersatz receipts.\nResolver\nA Resolver is an entity or component that provides discovery for identifiers. A Resolver is the\nController of its own self-referential identifier which may not be the same as the identifier to which it\nis a Resolver. A Resolver primarily maps identifiers to the Uniform Resource Locators (URLs) or\nInternet Protocol (IP) addresses of components of the trust bases for identifiers. These components\ninclude Controllers, Witnesses and Watchers. Given the URL or IP address of a component, a user\nmay there from obtain or be directed to the associated event histories (Key Event Logs (KELs), Key\nPage 6 of 17\n@ Public Version 1.1\nO 2023-04-03_vLEI-Q&A-updated_v1.1_Final 2023-04-03\n","contentLength":3734,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:10:55.130Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-verifiable-lei-vlei/2023-04-03_vlei-q-a-updated_v1.1_final.pdf","content":"Event Receipt Logs (KERLs), and Duplicitous Event Logs (DELs)) in order that the user may establish\n\ncurrent (root) control authority for the identifier. The Resolver may cache these event histories or\n\nkey event subsequences as end verifiable proofs of root control authority. A Watcher may act as a\n\nResolver.\n\nA Resolver provides a bootstrap discovery mechanism for KERI identifiers (AIDs). With respect to\n\nKERI, the target data for discovery is different for the two operative classes of identifier in KERI, that\n\nare, transferable and non-transferable identifier prefixes. In the case of a non-transferable identifier\n\nprefix, such as that of a Witness or Watcher, the target data may include a mapping from the non-\n\ntransferable identifier prefix to a service endpoint Uniform Resource Locator (URL) or directly to the\n\nInternet Protocol (IP) address of the Witness or Watcher KERL service. In this case, a Validator could\n\nquery the resultant IP address for a copy of the full KERL for the transferable identifier prefix to\n\nwhich the Witness or Watcher is entrained.\n\nIn the case of transferable identifiers, discovery may provide a mapping of the identifier prefix to a\n\ncached copy of either its full KEL or a copy of its inception event plus the latest rotation event or\n\nequivalently the latest key event state. From this copy, one may extract the identifier prefixes of the\n\ncurrent Witness set and then use discovery to access the KERLs for those Witnesses.\n\nBecause KELs and KERLs are end-verifiable, almost any method of internet discovery is viable for KERI\n\nbecause discovery is merely a bootstrap mechanism. The end-verification that happens post\n\ndiscovery ensures that the discovered material is securely attributed.\n\nPage 7 of 17\n\n@ Public Version 1.1\nO 2023-04-03_vLEI-Q&A-updated_v1.1_Final 2023-04-03\n","contentLength":1828,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:10:55.130Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-verifiable-lei-vlei/2023-04-03_vlei-q-a-updated_v1.1_final.pdf","content":"How does KERI Key Management work?\nAll ledger-based system security is based on signing keys not becoming compromised. The difference\nin KERI is that pre-rotated keys enable recovery of compromise of signing keys. And delegated\nidentifier keys may be recovered by any delegating identifiers. Multiple levels of delegation provide\nenhanced recovery. KERI’s delegation is unique and is described as cooperative delegation. See the\nglossary below for a detailed summary of cooperative delegation. But the most important feature of\ncooperative delegation is the nested levels of delegation provide protection via recovery rotations of\nkey compromise both of signing keys and pre-rotated keys of the levels below.\nBest practices for key management are assumed by any user of public-private key pairs. But like any\nkey management system one must protect one’s secrets. KERI’s pre-rotation makes those best\npractices all the more secure and nested delegation even more so. KERI specifically addresses the\nweakest link in conventional key management systems, that is key rotation. The pre-rotated keys\nnever need be exposed to side channel attacks against event signing infrastructure until they are\nactually used for a rotation. And pre-rotated are one-time-use rotation keys. This is a best practice\nand not subject to a host of side channel attacks from which non-one-time-use rotation keys must be\nprotected. The pre-rotated keys are also protected with a post-quantum proof hash thereby future\nproofing the system employed by KERI. Other key rotation algorithms that do not employ pre-\nrotation use much more complicated mechanisms for post-quantum proofing or not at all.\nMoreover, the nested delegation of identifiers that KERI employs enables enhanced security as the\ndelegated identifiers are protected by the keys of the delegating identifiers. This means that the root\nkeys need only be used once to delegate and never again unless the delegated keys become\ncompromised. With multiple levels of delegation this minimizes potential attacks on the root keys.\nKERI key management provides multiple layers of threshold structures that serve to multiply the\nnumber of attack surfaces that must be simultaneously compromised for a successful exploit. These\nare pre-rotation, multi-sig, and nested delegation. Moreover, Witnesses and Watchers provide\nthreshold structures for protecting event signing and event signing verification. Unlike many other\nschemes that merely bolt on multi-signature support, KERI's support for multi-sig is built in as a first-\nclass citizen. With nested delegated design of the vLEl infrastructure, a successful attacker must\nsimultaneously compromise multiple nested multi-signatures on multiple sets of pre-rotated keys.\nIndeed, one may say that the vLEl infrastructure KERI implementation by GLEIF employs not just best\npractices for key management but best in class key management.\nBut to summarize, compromised pre-rotated keys on any but the root level the layer above may\nmerely perform a rotation to invalidate compromised pre-rotated keys. Given that the upper layers\nat least will be multi-sig, such a compromise would be extremely difficult and such compromises of\nmulti-sig systems are extremely rare. For example, so far there is no published case of a successful\nexploit of the Gnosis multi-sig wallet. And this does not even employ pre-rotation or multiple levels\nof delegation like KERI. So, KERI would be orders of magnitude more difficult to exploit. Such an\nexploit would be equivalent in difficulty to the compromise of the root keys for the most secure\ncritical infrastructure. This is not at all equivalent to the compromise of a Domain Name Servers\nPage 8 of 17\n@ Public Version 1.1\nO 2023-04-03_vLEI-Q&A-updated_v1.1_Final 2023-04-03\n","contentLength":3784,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:10:55.130Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-verifiable-lei-vlei/2023-04-03_vlei-q-a-updated_v1.1_final.pdf","content":"(DNS) certificate which is based on the well-known vulnerabilities in the outdated, flawed insecure\nDNS/CA (Certificate Authority) system.\nIn addition, as per the KERI architecture, any participant in the vLEIl ecosystem will add\nreliability/availability by operating their own Watcher pools which will keep copies of the GLEIF Key\nEvent Logs (KELs). The following slide presentation provides diagrams of the notional witness\nnetwork:\nhttps://github.com/SmithSamuelM/Papers/blob/master/presentations/GLEIF_with KERIL.web.pdf\nAn even more extreme case would be a total compromise of all keys including the root pre-rotated\nkeys. In this case the root identifier must be abandoned, and a new root created. This is equivalent to\nthe total compromise of a ledger.\nMore on the security implications of KERI\nThe following white paper discusses in more detail the security implications of threshold structures\nand key management and root-of-trust with respect to KERI in a GLEIF class application:\nhttps://github.com/SmithSamuelM/Papers/blob/master/whitepapers/IdentifierTheory web.pdf\nIt is important to make apples to apples comparisons between key management schemes especially\nwith regards the root-of-trust. It is easy to confuse the security difference between a convenient\nscheme for the recovery of a weak root-of-trust and more inconvenient recovery scheme but for a\nmuch stronger root-of-trust. The latter may be magnitudes more secure than the former. The goal is\nto make compromise of the root-of-trust vanishingly remote as opposed to enabling the more\nconvenient but also more common recovery of a weak root-of-trust. The cumulative harm to the\nsystem is much greater for the weak root of trust as the cumulative harm grows the more one must\nrecover from exploit.\nKERI enables a scalable distributed hierarchical dissemination of trust out to the leaves but with\nultimate recovery potential back to the extremely well protected root. Multi-level threshold\nstructures provide the strongest possible security mechanisms and may be designed to be arbitrarily\nsecure merely by multiplying the number of attack surfaces that must be simultaneously breached\nfor successful attack. KERI’s hierarchical cooperative delegation enables convenient and scalable\nperformance at the outer levels without sacrificing ultimate security provided by increasingly higher\nlevels of security of the nested levels ending in the root level.\nHow was GLEIF established as the root-of-trust for the vLEI ecosystem?\nIn order to understand how a hypothetically one would handle the compromise of keys, it is helpful\nto understand the original process by which the root-of-trust root Autonomic Identifier (AID) GLEIF ID\n(GID) is established.\nPage 9 of 17\n@ Public Version 1.1\n2023-04-03_vLEI-Q&A-updated_v1.1_Final 2023-04-03\n","contentLength":2804,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:10:55.130Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-verifiable-lei-vlei/2023-04-03_vlei-q-a-updated_v1.1_final.pdf","content":"The original root identifier GID becomes qualified after its creation by a multi-factor association with\nGLEIF as the controller. Once this multi-factor association is sufficiently published and recognized\nthat it becomes “common knowledge”. At which point the identifier (KERI AID = GID) may be used as\nthe recognized root-of-trust. The first action of this root of trust will be to delegate other identifiers\n(GIDs = KERI AIDs). The root level is only used for delegation and only allows rotations. This means\nthat each set of keys is a one-time use key set for a rotation that delegates. Each rotation commits to\na new set of pre-rotated keys that have never been exposed. Because the first rotation makes a set\nof delegations this root set may never need to be used again until such time as recovery or rotation\nof delegated keys is needed. Thus, the usage is minimized and be performed in the most secure\nmanner possible.\nBut suppose that somehow despite all these security measures, the root GID set of pre-rotated keys\nbecomes compromised (note this would be a multi-sig compromise of unused keys stored in\nseparate locations), then the original GID would have to be abandoned and a new GID would have to\nbe established via the same multi-factor association process as the original GID.\nRecall, that any PKI scheme ultimately must perform such an abandonment and re-association if all\nkeys are compromised. What is unique about KERI is that by using threshold structures of multi-sig,\nnested delegation, and limiting exposure through one-time pre-rotated keys, the likelihood of such a\ncomplete compromise is as small as practically possible using current widely accepted digital\nsignature Public Key Infrastructure (PKI) libraries.\nHow will the vLEl infrastructure handle revocation of credentials?\nGLEIF believes that revocation enforcement is one of the key differentiators to X.509 certificates.\nGLEIF’'s TolP Ecosystem Governance Framework establishes a decentralized, hierarchical Public Key\nInfrastructure (PKI) with GLEIF being the root of trust for the associated vLEIl ecosystem. Revocation\nis provided at each level of chained issued VLEI credentials. LEIs will be wrapped as Verifiable\nCredentials according to the TolP Authentic Chained Data Container (ACDC) and associated Internet\nEngineering Task Force (IETF) standards. The ACDC specification is also a standards track proof\nformat for the W3C VC standard. As an ACDC VC, the LEI will be cryptographically bound to the\nowner of the designated private/public key pair. Each vLEI will get a Decentralized Identifier (DID)\nassigned. Data will be discoverable via respective interfaces. vLEIs will support personal and\norganizational wallets and the respective protocols. Having this said, governance of revocation does\nnot only have technical but also business implications. One could imagine that a vLEI gets revoked\nthe moment the underlying LEI lapses. This would also help the LEI system and the reinforcement of\nrenewals in order to achieve higher data quality levels.\nPage 10 of 17\n@ Public Version 1.1\nO 2023-04-03_vLEI-Q&A-updated_v1.1_Final 2023-04-03\n","contentLength":3132,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:10:55.130Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-verifiable-lei-vlei/gleif-ebook-the-vlei-introducing-digital-i-d-for-organizations-everywhere/01-06-2023-gleif_introduction-to-the-vlei_redesign_v2.2.pdf","content":"The vLEI: Introducing Digital I.D.\n\nfor Organizations Everywhere\n\nHow GLEIF is addressing the global need for digitized,\n\nautomated authentication and verification of\n\norganizations across a broad range of industries\n\nGLEIF ’\n\nEnabling global identity\nProtecting digital trust\n","contentLength":277,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:11:55.926Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-verifiable-lei-vlei/gleif-ebook-the-vlei-introducing-digital-i-d-for-organizations-everywhere/01-06-2023-gleif_introduction-to-the-vlei_redesign_v2.2.pdf","content":"Trust:\n[ ]\nThe missing ingredient in digital transformation -~ .. -\nIn today’s digital world, where organizations For this huge leap forward to succeed, This is a new ecosystem\nare increasingly cooperating and transacting therefore, the world’s economies must also with one clear goal: to\nremotely and across borders, trust can no modernize the methods we use to create create a standardized,\nlonger be established with just a handshake trust. Establishing a universal way to digitally digitized service capable\nor a paper-based signature. Yet confidence in verify the legal identities of counterparty of enabling instant, automated\ndigital authenticity remains in short supply. organizations and their key representatives is verification, enabling trust between\n. . . . now critical to the future health and stability organizations and their authorized\nAs innovations in loT, blockchain, cloud L .\n. L of the global digital economy. representatives, and the counterparty\ncomputing and open APIs, among others, inspire o A .\n. . . organizations and representatives with\nnew business propositions and redefine how Only then can counterparties work together A .\nL . . . . which they interact.\norganizations connect and engage with one in ways that will unlock the true potential\nanother, the issue of trust remains outstanding. of digitalization: enabling innovation and The ecosystem will operate across\nHow can you be sure you are using your bank’s collaboration to thrive unlimited by geography, all industry sectors, globally.\nreal website? Did that invoice really come from and money, goods and services to flow securely\nyour business partner? around the world faster, more efficiently, and at\nCovid-19 has increased the pace of change. alower cost than ever before.\nAccording to a global McKinsey & Company The Global Legal Entity Identifier Foundation\nstudy, the pandemic has accelerated business’ (GLEIF) is answering this urgent, unmet need.\ndigital initiatives by up to seven years! GLEIF is pioneering a multi-stakeholder L. . .\nThis evolution of traditional business models effort to create a new global ecosystem for Establishing a universal way to digitally\nbrinas with it a huge opbortunity for betterment organizational digital identity. In February 2022, verify the legal identities of counterparty\nbut %nl occur if tl?e wgfid's or gnizcltions can ’ GLEIF published an Ecosystem Governance organizations and their key representatives\nny L 9 Framework, together with a technical is now critical to the future health and\ntrust in the authenticity of their customers, supporting infrastructure, for a verifiable LEI stability of the digital global econom\npartners and suppliers. Cybercrime remains big PP 9! . ' . . Y g g Y-\n. ; ; (VLE), a digitally verifiable credential containing\nbusiness. So big, that it cost the global economy the Legal Entity Identifier (LED)\nan estimated $6 trillion in 20212 9 4 :\nTHow COVID-19 has pushed companies over the technology tipping point — and transformed business forever - McKinsey, October 2020.\n2Cybersecurity Ventures Official Annual Cybercrime Report, Cybercrime Magazine\n","contentLength":3127,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:11:55.926Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-verifiable-lei-vlei/gleif-ebook-the-vlei-introducing-digital-i-d-for-organizations-everywhere/01-06-2023-gleif_introduction-to-the-vlei_redesign_v2.2.pdf","content":"[ R LU\nInternational\nmomentum st S\nFollowing the launch of the vLEI development program in November 2020, and in addition to the sector-specific use cases\nidentified previously, GLEIF and its partners have made significant progress in a variety of other initiatives to support the\ncreation of the vLEI ecosystem.\n\nNovember February February March June July December\n2020 2021 2022 2022 2022 2022 2022\nLaunch of GLEIF unveils Publication Publication GLEIF and Launch of the First publicly\nthe vLEI technical of vLEI of ISO 5009 PharmalLedger vVLEl Issuer available trial of\ndevelopment infrastructure Ecosystem standard, announce the Qualification organizational\nprogram model Governance facilitating deployment program identity services\nFramework the inclusion of vLEI within leveraging the\nbased on of ‘official blockchain- VvLEI\nTrust Over IP organizational enabled\nGovernance roles’ in vLEIs healthcare\nMetamodel solution\nVLEI\ne, development G e O\nprogresses\nFirst use of the\nVLEI to sign\nGLEIF’s 2021\nannual report\n","contentLength":1020,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:11:55.926Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-verifiable-lei-vlei/gleif-ebook-the-vlei-introducing-digital-i-d-for-organizations-everywhere/01-06-2023-gleif_introduction-to-the-vlei_redesign_v2.2.pdf","content":"E .',,‘.:,..;.‘.\nBl N\nAR\n' - '\\\n&(‘ n ‘ \"_,. ® .__\n|\n","contentLength":53,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:11:55.926Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-verifiable-lei-vlei/gleif-ebook-the-vlei-introducing-digital-i-d-for-organizations-everywhere/01-06-2023-gleif_introduction-to-the-vlei_redesign_v2.2.pdf","content":"Keen to\nG t in I I learn more?\nContact us on:\nL. . . . . . . info@gleif.org\nGLEIF now invites further engagement from parties operating across all industry sectors with a view to exploring\nopportunities to leverage vLEI identity verification in future applications, services, and business models.\nAbout the Legal Entity About the Global Legal Entity History of the\nIdentifier (LEI) Identifier Foundation (GLEIF) Global LEI System\nThe Legal Entity Identifier (LEI) is a Established by the Financial Stability Board in June In 2011, the Group of Twenty (G20)\n20-character, alpha-numeric code based 2014, the Global Legal Entity Identifier Foundation called on the Financial Stability Board\non the ISO 17442 standard developed (GLEIF) is a not-for-profit organization created to (FSB) to provide recommendations\nby the International Organization for support the implementation and use of the Legal for a global Legal Entity Identifier\nStandardization (ISO). The LEI connects Entity Identifier (LED. GLEIF is headquartered in (LED and a supporting governance\nto key reference information that Basel, Switzerland. structure. This led to the development\nenables clear and unique identification . . . . of the Global LEI System which,\n. L GLEIF services ensure the operational integrity of .\nof legal entities participating in . through the issuance of LEls, now\n. . . the Global LEI System. GLEIF also makes available . . . . .\nfinancial transactions. Each LEI contains . . . provides unique identification of legal\n. . - . the technical infrastructure to provide, via an open . R .\ninformation about an entity’s ownership . f entities participating in financial\n. . data license, access to the full global LEI repository .\nstructure, answering the questions . transactions across the globe. The FSB\n. . , : , free of charge to users. GLEIF is overseen by the . .\nof ‘who is who' and ‘who owns whom'. . . L emphasized that global adoption of\n. . . LEI Regulatory Oversight Committee, which is . o .\nIt provides a universally recognized . - o the LEI underpins multiple “financial\n. . . . . . made up of representatives of public authorities . AR\nidentifier paired with essential entity - . . stability objectives” and also offers\n. . . from across the globe. For more information, visit . . \"\ndataq, rigorous verification processes . . many benefits to the private sector”.\n. . the GLEIF website at https://fwww.gleif.org/en.\nand high data quality.\nSource:\n— Global Legal Entity Identifier Foundation, St. Alban-Vorstadt 5, 4052 Basel, Switzerland\n— Chair of the Board: Dessa Glasser, CEO: Stephan Wolf\n— Commercial-Register-No.: CHE-200.595.965, VAT-No.: CHE-200.595.965MWST\n— LEI: 506700GE1G29325QX363\n","contentLength":2698,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:11:55.926Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-verifiable-lei-vlei/gleif-ebook-the-vlei-introducing-digital-i-d-for-organizations-everywhere/01-06-2023-gleif_introduction-to-the-vlei_redesign_v2.2.pdf","content":", 134%°\n4268 TR\ns 1N .\nv .\n' » o\n° A . ‘\nin ;\no887+ 71007\n31438 %\ng 92490 i\n[} 45.161° || :\n92595 ([ |\n' 'Ifb ' . 6[ |\nI ' ' | | 1 S‘. } |\nl 2207 ‘\nGLEIF . %\n0 073 > T\nEnabling global identity The content of this e-book is the property of GLEIF. Reproduction and/or sharing of this content =\nProtecting digital trust is encouraged and must be accompanied by a clear attribution to GLEIF. 83712 -_ . o\n. e 69:64\n3 - - =F z\n50267\n","contentLength":428,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:11:55.926Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-verifiable-lei-vlei/gleif-ebook-the-vlei-introducing-digital-i-d-for-organizations-everywhere/01-06-2023-gleif_introduction-to-the-vlei_redesign_v2.2.pdf","content":"[ ] [ ]\n\nOrientation:\nA briefrecap\n\nWhat is an LEI? What is GLEIF? Who has an LEI?\nA Legal Entity Identifier (LEI) is an ISO- The Global Legal Entity Identifier Foundation Until recently, most LEls have been obtained by\nstandardized 20-character code® that uniquely (GLEIF) was established by the Group of Twenty organizations in response to a legal mandate to\nidentifies a legally registered organization, or (G20) and the Financial Stability Board (FSB) comply with regulatory reporting requirements.\n‘legal entity’. It enables anyone, anywhere in in June 2014. It is a supra-national non-for- More than 200 financial regulators around the\nthe world to trust that an organization is who it profit organization overseen by the Regulatory world now require companies to obtain an LEI\nclaims to be. Oversight Committee and backed by the G20, before they go public.\nEach LEl is unique and can represent only one S?:t }L:p Eo SU:OEOF.t tTg mafilem(el_r;il:)otmn and use As aresult, the system has created\nlegal entity. Each LEI links to a corresponding of the Legal Entity Identifier ’ unprecedented levels of transparency for all\n‘LEI record’ which contains a range of identifying players operating in capital markets including\ninformation about the legal entity, such as its regulators, individual companies, investors,\nregistered location, legal name, and ownership and anyone else around\nstructure. Because LEls use a global standard, the world that has an\nthey are a benchmark that regulators and other interest.\nlegal entities worldwide recognize, agree with, At the\nand trust. start of 2022,\nAll LEl records are held in a freely available and there are over\nsearchable centralized repository, called the ™ two million LEIs\nGlobal LEI Index.‘Thls is the only gIong online — in use around\nsource that provides open, standardized, and\nhigh-quality legal entity reference data. Together, the world.\nthese elements comprise the Global LEI System,\nwhich anyone can use to answer identity related\nquestions related to legal entities, principally ‘who\nis who' and ‘who owns whom.\n5The LEl is created using the ISO 17442 standard. Learn more here:\nhttps://www.gleif.org/en/about-lei/iso-17442-the-lei-code-structure/\n","contentLength":2211,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:11:55.926Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-verifiable-lei-vlei/gleif-ebook-the-vlei-introducing-digital-i-d-for-organizations-everywhere/01-06-2023-gleif_introduction-to-the-vlei_redesign_v2.2.pdf","content":"[ ] [ ] .\n\nOrientation:\n(J\n\nA brief recap\n\n° ‘_____—-_—\\\nAn independent, =\ninternational, Need more |\n\nbackground S\\\nnot-for-profit system S @) _I\nPlease consult: 1 VAR B VST N\nImportantly, the Global LEI System is set . 1/\nup as a public good. https://www.glglf.org/ I\nen/about/this-is-gleif\nIt has no commercial, technical, or governmental T\ndependencies that influence its decisions and “ |\ndirection. GLEIF, which oversees the running of the\nsystem and manages its network of accredited IIIlI Iy S By | S Ry S\npartners, known as LEI issuing organizations, is a (RN llllll\nnon-profit foundation whose activities are overseen ; ‘r\nby a group of 65 financial markets regulators and i l “III\nother public authorities and 19 observers from more (\nthan 50 countries. This diverse and influential group / | \\/ | »\nis called the Regulatory Oversight Committee. . “m“\\m =\nFundamentally, GLEIF exists to enables smarter, less i , Al\ncostly, and more reliable decisions about who to do ‘““““ ““““l“ i\nbusiness with by supporting the implementation of AL ““““l“ \"’ 18\nthe LEI and the availability of the Global LEI Index. ““l“““ i = — [\\ Y\n“““Illl' I \\..i \\\\\\\\ '\n7 -\n» 7 (1]\n","contentLength":1167,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:11:55.926Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-verifiable-lei-vlei/gleif-ebook-the-vlei-introducing-digital-i-d-for-organizations-everywhere/01-06-2023-gleif_introduction-to-the-vlei_redesign_v2.2.pdf","content":"[ »,\nin the LEIl story ity\nHaving successfully proven the power of the Global LEI | i : \\:‘\\Q\\\nSystem to deliver transparency in capital markets, GLEIF n «»\\\\ N\nis now broadening its ambitions and is working to drive I e R\nvoluntary LEI adoption by organizations everywhere. | fi 'T\\ ~\nI ‘\nGLEIF's new vision is that every organization worldwide X “ ‘ \" W\nshould have only one global identity, which can support its I, | N . '\nparticipation in an increasingly digital economy. ; ; .y\nThe Global LEI System is the structure through which this il ey B\nvision can be realised. Happily, it is already well established. ML\nThe next step is to ensure that ‘the one identity’ should ;Gfi”' %‘M,fl L ML\nincorporate a digital identity. il e e\\ w\ni ,!;“E“; L\ni '_E,,a,ry{gggf,\\;;{; R\nWity\nit 8\ne} ng‘.gg {\nJ RRT—————— ]\n: _\\_\\52 4 A\nAR & P —\n- N = oy amr _“-——\nN W T ———————\n. = I — T, e S S ST T\n","contentLength":885,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:11:55.926Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-verifiable-lei-vlei/gleif-ebook-the-vlei-introducing-digital-i-d-for-organizations-everywhere/01-06-2023-gleif_introduction-to-the-vlei_redesign_v2.2.pdf","content":"H °\n°\nHow the world will benefit\nA new dawn in organizational identity\nThe VvLEI gives companies, government organizations, and other legal entities worldwide the capacity to use non-repudiable identification data pertaining\nto their legal status, ownership structure and authorized representatives in any kind of digital interaction, transaction, or e-signature scenario.\nEarly-stage use-case examples include:\n° O | ‘:\n\\° v=\nDigitally signing regulatory Expediting supply chain due Verifying business Expediting membership and Accelerating business entity\nfilings and reports. diligence processes. payments. registration to payment registration and license\nsystems. issuance.\n— = =\n)l .. &/ =\nStreamlining and accelerating Facilitating customs and Confirming authenticity Securing the remote To support data protection\nclient onboarding/ Know border control checks. when applying for and execution of business in all use-cases, including\nYour Customer processes for vetting trusted network contracts. those mandated by\nfinancial and other providers membership. regulation.\nof certain regulated services.\n","contentLength":1106,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:11:55.926Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-verifiable-lei-vlei/gleif-ebook-the-vlei-introducing-digital-i-d-for-organizations-everywhere/01-06-2023-gleif_introduction-to-the-vlei_redesign_v2.2.pdf","content":"ST\nT | | =\n‘w‘ .\ne S e\nThis is just the T -\nH H\nbeginning. = St\nHn .\\_.\nThe real potential of this technology ”‘;‘-’—LA: wg\nlies in its ability to unlock innovation. ‘ = = = —%\nA wide range of vertical sector use cases XX oA ‘E‘fi\"““ = = —/\nhave already been identified relating to s | e Dl = ) —/\npilots’ licenses; smishing and e-bot calls; === 725N i it :%\nmedical e-consent; client onboarding; === A T e w /\nsecure exchange of sensitive healthcare — ] | VE »\ninformation and more. ) | =EE it\n. |} i ——\nOnly when market uptake increases and 0 T e e I\"\nindustries around the world develop new “\\\\ il E==\nservices and use-cases based on the 0§ %% = \\\nfreedom this technology provides, will the ) ol \\\ntrue power of the vLEI will be revealed. 0 i !'.\\'\\\nWRN\nRl\nN\nW]\ni~ O ’fi( ~.\n{ i N %\n| ' \nF E The vLEI has the potential to become one of the most\n{(’ % “‘ , valuable digital credentials in the world, because it is the\nL ,’k ¥ hallmark of authenticity for an organization of any kind. The\nQ- p family of digital credentials in the GLEIF vLEI Governance\ny @ Drummond Reed, Frame.work canserveasa chain of trus:t fo.r anyone needing\n; Steering Committee Member, to verify the legal identity of an organization or of a person\n4 ' Trust Over IP Foundation legally acting on that organization’s behalf.\n”? —————\n","contentLength":1306,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:11:55.926Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-verifiable-lei-vlei/gleif-ebook-the-vlei-introducing-digital-i-d-for-organizations-everywhere/01-06-2023-gleif_introduction-to-the-vlei_redesign_v2.2.pdf","content":"(J (J (J\n[ J\nThe vLEl: The digital extension\n(J (J (J\nof a globally recognized identity system é E z\nThe vLEI concept is simple: It is How does it work?\nthe secure digital counterpart of\na ?onve.nfional LEL In other wor.ds, GLEIF has based the design of the VLEI on Authentic Chained Data Container (ACDC) developed\nit is a digitally trustworthy version within the Trust over IP Foundation (which is hosted by the Linux Foundation). ACDCs use the Key\nof the 20-digit LEI code which is Event Receipt Infrastructure (KERI) protocol for more secure, enhanced key management.\nautomatically verified, without the . .\nneed for hum);n intervention. The VvLEI system establishes GLEIF as the digital ‘root of trust’ that safeguards the integrity of\nBy wrapping new and existing LEls the vLEI trust chain. This means all vLEls are traceable, through a cryptographically protected chain\nin digital credentials that can be of credentials, back to their entity identity source LEI in the Global LEI Index.\nverified, the vLEI offers a digitally\ntrustworthy version of the LEI which\nallows autgmated entity verification, GLEIF has established a formal Qualification Program to vet and monitor a network of vLEl issuers.\nthus can replace the manual processes\nconventionally required to access and GLEIF\nconfirm an entity’s LEI data. o\nBecause the vLEl leverages the :\nwell-established Global LEI System, :\nwhich is the only open, standardized e QuahfiedOVLEl Issuers\nand regulatory-endorsed legal :\nentity identification system, . .\nit is capable of establishing e Organizations\ndigital trust between O\nall organizations, o < :\neverywhere. o (@Y Figure I GLEIFis the oot of trust'in o @) Persons Representing\nthe vLEl issuance model enabling it to Orga nizations\nO safeguard the integrity of the system\n","contentLength":1787,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:11:55.926Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-verifiable-lei-vlei/gleif-ebook-the-vlei-introducing-digital-i-d-for-organizations-everywhere/01-06-2023-gleif_introduction-to-the-vlei_redesign_v2.2.pdf","content":"° (J (J (J\nThe vLEl: The digital extension\nof a globally recognized identity system\nHow does it work? (cont)\no . RGANIZATION PERSON ROLE\n\nOnce an organization has obtained ORGAN °\n\nits VLEI it can proceed with the m\n\nissuance of additional vLEI credentials fi -2\n\nto authorized representatives of i s\n\nthe organization, allowing them to E T o\n\ndigitally confirm their authenticity 22292 o\n\n(their name and their official role)\n\nwhen performing sensitive business : : :\n\nactivities, such as remotely approving : :\n\ntransactions, or e-signing contracts. 0 - 0 - @@ 0\nO O O\n LEGALENTITY PERSON’S ROLE\nIDENTIFIER IDENTIFICATION\n\nFigure 2: the vLEl wraps the LEl, a person’s [LEI STANDARD] [STRING]\n\nidentification, and their role inside a\n\ncryptographically secure organization\n\nige,.fiigtggigfif ng each component to be Crypographically bound to the owner of the keys\n","contentLength":862,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:11:55.926Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-verifiable-lei-vlei/gleif-ebook-the-vlei-introducing-digital-i-d-for-organizations-everywhere/01-06-2023-gleif_introduction-to-the-vlei_redesign_v2.2.pdf","content":"Independent, open,\n[ ] [ ]\nand unlversally lnteroperable Q;\n[} (]\n.\nH 0\nTo fulfil its global potential, the vLEI system The vLEI technical infrastructure will enable the\nmust interoperate seamlessly and securely VvLEI's cryptographic keys to be generated and\nwith all technology models, including all DLTs controlled directly by GLEIF, by vLEI Issuers and\n(like blockchain), cloud services and APls, by by VLEI holders, in accordance with the legal\nadopting a ‘network of networks’ approach. requirements around the world. - “ /\nTo accomplish this, GLEIF is leveraging the Key . S . I/ /\n. ! Each party will maintain full, independent control\n\nEvent Receipt Infrastructure (KERI) protocol to d bili This all GLEIF q A <\ndevelop the VvLEI's technical underpinnings. anap ortability across systems. This allows = N /!\n\nand its vLEI ecosystem to take advantage of ! :\nKERI provides a cryptographic development all blockchain, distributed ledger, self-sovereign 7 1/,/ @ifi\nframework enabling vLEls to be anchored identity, and other cloud-based public utilities to \"‘i‘ —°\nand verified without requiring a self-sovereign notarize cryptographic actions or transactions, @\nidentity, blockchain or distributed ledger utility maximizing interoperability and flexibility in the \\/,\n\nk te. LEl system.\n\nnetwork to operate \\Y % ¢ )/\nUsing the KERI protocol, vLEIs can be created d\nand utilized independently of any specific ~—\norganization, with the highest levels of security, ‘ ‘ \\_/,,\nprivacy, and ease of use. KERI also enables iL@\nGLEIF and the VLEI ecosystem to operate N SS%) [\\/\nunder GLEIF's governance framework, >ZTIS%\nunencumbered by the governance of external . .\nsystems, including those of blockchains and For more information on the KERI protocol, please consult:\ndistributed ledger consortia.\n\n=> https://iwww.gleif.org/en/vlei/introducing-the-verifiable-lei-viei\n\n=> https://keri.one\n","contentLength":1891,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:11:55.926Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-primary-document_v1.0_final.pdf","content":"O:GLEIF, Protecting digital st\nverifiable LEI (vLEI)\nEcosystem Governance Framework v1.0\nPrimary Document\nPublic\nDocument Version 1.0\n2022-12-16\n. . - I!Q ry\n- . F . ‘ -\n. O 2 ga\\_‘ _..; S SN\nA 38460 | :/ ; Soe— f.‘.\n\nN L\\ - ey B e 5 .\nN e S\no‘__: .. / J ° ‘ A ° s O ~ . .\n\n) . \" - ’ o\nN\n| -\n","contentLength":292,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:12:31.493Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-primary-document_v1.0_final.pdf","content":"The DID URL to this Primary Document is: did:keri:EINmHd5g7iV-UldkkkKyBIHO52blyxZNBn9pg-\nzNrYoS?service=vlei-documents&relativeRef=/egf/docs/2022-12-16_verifiable-LEI-(VLEI)-Ecosystem-\nGovernance-Framework-Primary-Document_v1.0_final.docx\nThe 1.0 Draft can be viewed at:\nhttps://www.gleif.org/en/lei-solutions/gleifs-digital-strategy-for-the-lei/introducing-the-verifiable-\nlei-vlei\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 2 of 12\nPrimary Document\nPublic Document Version 1.0\n@ 2022-12-16_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2022-12-16\nPrimary-Document _v1.0_final.docx\n","contentLength":611,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:12:31.493Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-primary-document_v1.0_final.pdf","content":"Business Requirements\nverifiable LEI (vLEI) Ecosystem Governance Framework Business Requirements v1.0\nThis document specifies certain business requirements for the vLEI services of GLEIF and Qualified\nVLEI Issuers (QVIs).\nTechnical Requirements\nverifiable LEI (vLEI) Ecosystem Governance Framework Technical Requirements\nPart 1: KERI Infrastructure, v1.0\nverifiable LEI (VLEI) Ecosystem Governance Framework Technical Requirements\nPart 2: vLEI Credentials, v1.0\nverifiable LEI (VLEI) Ecosystem Governance Framework Technical Requirements\nPart 3: Technical Schema Types SAIDs\nInformation Trust Requirements\nverifiable LEI (vLEI) Ecosystem Governance Framework Information Trust Policies, v1.0\nA document that defines the information security, privacy, availability, confidentiality, and processing\nintegrity policies that apply to vLEI Ecosystem stakeholders.\nLegal Agreements\nvLEI Issuer Qualification Agreement, v1.0\nAn agreement between GLEIF and an organization that has been qualified by GLEIF to operate as a\nQuialified vLEl Issuer (QVI). The vLEl Issuer Qualification Agreement will be the same for all QVIs.\nAppendices to vLEI Issuer Qualification Agreement\nAppendix 1: Non-Disclosure Agreement (NDA), v1.0\nAn agreement that outlines requirements for handling confidential information.\nAppendix 2: vLEI Issuer Qualification Program Manual, v1.0\nThe document that describes the Qualification program.\nAppendix 3: vLEI Issuer Qualification Program Checklist, v1.0\nThe document that details the control and process requirements for Qualification.\nAppendix 4: vLEI Issuer Contact Details, v1.0\nA list of contact details of GLEIF and the Candidate vLEI Issuer during Qualification and of GLEIF and\nthe QVI during ongoing operations.\nAppendix 5: Qualified vLEI Issuer Service Level Agreement (SLA) v1.2\nA document that details the services to be provided by GLEIF and Qualified vLEI Issuers.\nAppendix 6: Qualified vLEI Issuer TrustMark Terms of Use, v1.0\nA document that details the terms of use of the TrustMark by a QVI.\nAppendix 7: Qualified vLEI Issuer-Legal Entity Required Contract Terms, v1.0\nA document that specifies the contract terms that must be included in the agreement between a QVI\nand a Legal Entity for vLEI services.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 11 of 12\nPrimary Document\nPublic Document Version 1.0\nGLEIF 2022-12-16_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2022-12-16\nPrimary-Document _v1.0_final.docx\n","contentLength":2470,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:12:31.493Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-primary-document_v1.0_final.pdf","content":"Identifier and Credential Governance Frameworks\nGLEIF Identifier Governance Framework, v1.0\nA document that details the purpose, principles, policies, and specifications that apply to\nthe use of the GLEIF Root Autonomic Identifier (AID) and its GLEIF Delegated AlDs in the vLEI\nEcosystem.\nQualified vLEl Issuer Identifier and vLEI Credential Governance Framework, v1.0\nA document that details the requirements to enable the Delegated AlIDs and the vLEI to be issued by\nGLEIF to QVIs which allows the QViIs to issue, verify and revoke Legal Entity vLEI Credentials, Legal\nEntity Official Organizational Role VLEI Credentials and Legal Entity Engagement Context Role vLEI\nCredentials.\nQualified vLEl Issuer Authorization vLEI Credential Governance Framework, v1.0\nA document that details the requirements for this vLEI to enable the simple, safe, secure instruction\nand authorization by a Legal Entity Authorized Representative (LAR) sent to a QVI for the issuance\nand revocation of vLEI Role Credentials.\nLegal Entity vLEI Credential Governance Framework, v1.0\nA document that details the requirements for a vLEI as the entity level credential issued by a QVI to a\nLegal Entity.\nLegal Entity Official Organizational Role vLEIl Credential Governance Framework, v1.0\nA document that details the requirements for vLEI Role Credentials issued to by a QVI to official\nrepresentatives of a Legal Entity.\nLegal Entity Engagement Context Role vLEI Credential Governance Framework, v1.0\nA document that details the requirements for vLEI Role Credentials issued to representatives of a\nLegal Entity in other than official roles but in functional or other context of engagement.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 12 of 12\nPrimary Document\nPublic Document Version 1.0\nGLEIF 2022-12-16_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2022-12-16\nPrimary-Document _v1.0_final.docx\n","contentLength":1900,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:12:31.493Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-primary-document_v1.0_final.pdf","content":"Introduction\nThe verifiable LEI (vLEI) Ecosystem Governance Framework is a Layer Four Ecosystem Governance\nFramework of the Trust over IP Foundation (TolP). The Legal Entity Identifier (LEl) is used as a key\ncomponent in building a trust layer for identification and verification of organizational identity that\ncan be used in any other Governance Frameworks that require organizational identity.\nThe LEI had its beginnings in the aftermath of the global financial crisis responding initially to a call by\nglobal regulators to establish a standard international identifier *and related reference data that\ncould be accessed and used in regulatory frameworks and supervision.\nThe LEIl and the Global LEI System were envisioned from the start as a public-private partnership that\nshould bring transparency and benefits to both the public and the private sectors. And although the\nLEl was used initially to identify legal entities in financial services, the need for identification of legal\nentities is not limited to the financial services domain.\nNow, years after the Global LEI System was established, which the Global Legal Entity Identifier\nFoundation (GLEIF) operates and maintains, this Governance Framework establishes GLEIF’s role in\ndigital identity and Authentic Chained Data Container (ACDC) Credentials to add trust to interactions\nin the global digital economy.\nTerminology\nTolP Governance Requirements Glossary\n* Requirements include any combination of Machine-Testable Requirements and Human-\nAuditable Requirements. Unless otherwise stated, all Requirements MUST be expressed as\ndefined in RFC 2119.\n* Mandates are Requirements that use a MUST, MUST NOT, SHALL, SHALL NOT or\nREQUIRED keyword.\n¢ Recommendations are Requirements that use a SHOULD, SHOULD NOT, or\nRECOMMENDED keyword.\no Options are Requirements that use a MAY or OPTIONAL keyword.\n» Machine-Testable Requirements are those with which compliance can be verified using an\nautomated test suite and appropriate scripting or testing software.\n© Rules are Machine-Testable Requirements that are written in a Machine-Readable\nlanguage and can be processed by a Rules Engine. They are expressed in a structured\nrules language as specified by the Governance Framework.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 3 of 12\nPrimary Document\nPublic Document Version 1.0\nGLEIF 2022-12-16_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2022-12-16\nPrimary-Document _v1.0_final.docx\n","contentLength":2471,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:12:31.493Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-primary-document_v1.0_final.pdf","content":" Human-Auditable Requirements are those with which compliance can only be verified by an\naudit of people, processes, and procedures.\n¢ Policies are Human-Auditable Requirements written using standard conformance\nterminology. The Policies used in the Governance Framework will use the standard\nterminology detailed in RFC 2119 keywords. Note that all RFC 2119 keywords have\nweight from an auditing perspective. An implementer MUST explain why a SHOULD\nor RECOMMENDED requirement was not implemented and SHOULD explain why a\nMAY requirement was implemented.\n\n« Specifications are documents containing any combination of Machine-Testable\nRequirements and Human-Auditable Requirements needed to produce technical\ninteroperability.\n\nLocalization\n\n1. The official language of the vLEI Ecosystem Governance Framework SHALL be American\nEnglish.\n\n2. The Governance Framework Website SHALL include introductory remarks in the languages of\nthe G20 countries.\n\n3. For situations in which the vLEI Ecosystem Governance Framework MAY be needed in\nanother language, GLEIF will consider these on a case-by-case basis.\n\nGoverning Authority\n1. The Global Legal Entity Identifier Foundation (GLEIF), as Governing Authority, is responsible\nfor the vLEI Ecosystem Governance Framework.\n2. The LEI of GLEIF is 506700GE1G29325QX363.\n3. The contact information for GLEIF is:\nSt. Alban-Vorstadt 5, PO Box, 4002 Basel, Switzerland\nContact: Karla McKenna, Head of Standards\nKarla.McKenna@gleif.or\nAdministering Authority\n1. The Global Legal Entity Identifier Foundation (GLEIF) also is the Administering Authorityfor\nthe VLEI Ecosystem Governance Framework.\nPurpose\nThe purpose of the verifiable LEI (vLEI) Ecosystem Governance Framework is to deliver a global\ninfrastructure that enables decentralized verifiable digital identity of legal entities in all use cases\nwhere it is required and can enable industry and participant benefits.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 4 of 12\nPrimary Document\nPublic Document Version 1.0\nGLEIF 2022-12-16_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2022-12-16\nPrimary-Document _v1.0_final.docx\n","contentLength":2142,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:12:31.494Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-primary-document_v1.0_final.pdf","content":"Scope\nThe following entities are stakeholders in the Trust Community:\n\no GLEIF — Global Legal Entity Identifier Foundation operates and manages the Global LEI\nSystem (GLEIS);\n\ne LElIssuer — An organization accredited by GLEIF to validate legal entity information and\nregister new LEls and reference data which are sent to GLEIF for inclusion in the GLEIS;\n\ne Qualified vLEl Issuer (QVI) — An organization qualified by GLEIF to issue Legal Entity vLEI\nCredentials, Legal Entity Official Organizational Role vLEI Credentials (OOR vLEI Credentials)\nand Legal Entity Engagement Context Role VLEI Credentials (ECR VvLEI Credentials)\n\no Legal Entity — a legal person or structure that is organized under the laws of any jurisdiction\nthat meets the eligibility criteria for registering for a LEI;\n\no Official Organizational Role Persons (OOR Persons) — Persons who represent Legal Entities in\nofficial roles;\n\n¢ Engagement Context Role Persons (ECR Persons) — Persons who represent Legal Entities in\nfunctional roles;\n\no VLEI User — any user of vLEI credentials in any applicable use case.\n\nThe scope of the vLEI Ecosystem Governance Framework is to enable these stakeholders to issue,\nhold and verify vLEI Credentials using the GLEIF Controller Network and to ensure that these\nactivities take place in compliance with the vLEI Ecosystem Governance Framework.\n\nOut of scope for the vLEI Ecosystem Governance Framework are the LEI governance processes and\nrules which are managed separately by GLEIF with its own specification and documents. In addition,\nalthough GLEIF encourages other governance frameworks to make use of the vLEI Ecosystem\nGovernance Framework and the vLEI Credentials, these governance frameworks also are out of\nscope.\n\nObjectives\n\nThe objectives of the VLEI Ecosystem Governance Framework for a global infrastructure for\norganizational digital identity based on the LEl are:\n\nDrive LEl Adoption\n\no Expand the value LEls can bring to the global economy by enabling cryptographically\nverifiable vLEls;\n\n» Make it easy and profitable for a wide range of QVIs to begin issuing VLEls;\n\no Attract developers to build vLEIs into applications that depend on digital trust;\n\no Assist regulators in understanding and incorporating LEIs and vLEls so that they are\nintegrated into numerous critical business processes and workflows.\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 5 of 12\n\nPrimary Document\n\nPublic Document Version 1.0\nGLEIF 2022-12-16_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2022-12-16\n\nPrimary-Document _v1.0_final.docx\n","contentLength":2574,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:12:31.494Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-primary-document_v1.0_final.pdf","content":"o Establish GLEIF as a Global Root of Trust for Organizational Identifiers\n» Position VLEls as the simplest, strongest solution for any use case requiring digital verification\nof the attributes, transactions, or attestations of a legal entity or its official persons or\npersons in other functions;\n« Enable a vLEI chain of trust: GLEIF, QVIs, Legal Entities, OOR Persons, ECR Persons;\n« Support unlimited levels of delegated identifiers and associated Verifiable Credentials to\nprovide both horizontal and vertical scalability.\nEnable New Uses for LEIs\nA list of use-cases, including those identified through vLEI research, includes:\nVerifiable corporate documentation and communications\n» Company and signatory-specific documents and reports;\n» Regulatory filing and reporting by a third-party filer on behalf of the filer/reporting entity or\nby an auditor;\no Contracts and legal agreements;\n« Private, secure, peer-to-peer communication with customers, employees, and other\nstakeholders.\nCounterparty verification supporting digital business interaction/automation\no Client/counterparty due diligence and Know Your Customer (KYC) compliance;\n» Import/export, supply chain, customs/border control, payment for goods (e-invoicing);\n« Authorized signatory verification;\n« e-invoice and e-payment instruction validation.\nLicensing and corporate registration\no Trusted supplier/provider network membership and registration;\n« Payment systems membership and registration;\no Business entity registration and licenses;\n« Educational institutions - qualification certification and verification.\nOther use cases\n« Digital wallets, digital asset management, and decentralized finance;\n« Verification of transacting parties;\n» Employee and authorized agent ID for any organizational use-case.\nEnhance Security, Reduce Fraud and Simplify Compliance\n« Enhance security of Autonomic ldentifiers (AIDs) and vLEI credentials by replacing an\nadministrative root of trust with a cryptographic root of trust;\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 6 of 12\nPrimary Document\nPublic Document Version 1.0\nGLEIF 2022-12-16_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2022-12-16\nPrimary-Document _v1.0_final.docx\n","contentLength":2223,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:12:31.494Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-primary-document_v1.0_final.pdf","content":"» Ensure complete, cryptographically verifiable auditability of transactions and other\ninteractions involving vLEIs and sub-identifiers;\n\no Resist quantum computer attacks;\n\n« Combine with other verifiable factors to further increase security, such as:\n\na. identity / biometrics\nb. delegated multi-signature capabilities\nEnhance Independent Control, Efficiency, Scalability and Sustainability\n\n« Eliminate dependence on any single SSI utility network by delivering the vLEl infrastructure\nusing an interoperable and technology agnostic approach;\n\n» Reduce dependence on SSI utility network governance structures beyond the control of\nGLEIF;\n\no Ensure highly performant global scalability;\n\n« Establish global best practices for key management;\n\n« Aid the development of a competitive market for all the software, tools, and services\nnecessary to implement vLEls;\n\n» Work with QVIs to ensure a sustainable commercial model for vLEIs for GLEIF, QVIs, and\nLegal Entities and other vLEI Ecosystem stakeholders.\n\nPrinciples\n\n1. The vLEl Ecosystem Governance Framework MUST enable GLEIF’s role to support and\ncontribute to unique global persistent organizational identity as a public good.\n\n2. The vLEIl Ecosystem Governance Framework MUST deliver on GLEIF’s vision that every legal\nentity be able to be identified uniquely, having only one global identity and this identity\nshould include a digital identity.\n\n3. The vLEIl Ecosystem Governance Framework MUST leverage the principle of free and open\naccess and use of the data in the Global LEI System regarding legal entities and their entity-\nlevel and relationships.\n\n4. The vLEI Ecosystem Governance Framework MUST support GLEIF’s intention to deliver the\nvLEl infrastructure using a technology agnostic approach and to use open source whenever\npossible.\n\n5. The vLEl Ecosystem Governance Framework MUST support GLEIF’s use of open standards.\n\n6. The vLEl Ecosystem Governance Framework MUST fulfil GLEIF’s intention to make the vLEI\ninfrastructure widely available as broadly useful as possible.\n\n7. The vLEIl Ecosystem Governance Framework MUST enable interoperability, for the digital\nidentity data of an entity to be represented, exchanged, secured, protected, and verified\ninteroperably using open, public, and royalty-free standards, as well as portability, the ability\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 7 of 12\n\nPrimary Document\n\nPublic Document Version 1.0\nGLEIF 2022-12-16_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2022-12-16\n\nPrimary-Document _v1.0_final.docx\n","contentLength":2562,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:12:31.494Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-primary-document_v1.0_final.pdf","content":"of identity rights holders to move or transfer a copy of their digital identity data to the agents\nor systems of their choice.\n\n8. The vLEl Ecosystem Governance Framework MUST empower vLEIl Holders to secure their\ndigital identity data at rest and in motion, to control their own identifiers and encryption\nkeys, and to employ end-to-end encryption for all interactions and to protect the privacy of\ntheir digital identity data when applicable.\n\n9. The vLEIl Ecosystem Governance Framework MUST ensure verifiability and authenticity by\nempowering VLEI Holders to provide verifiable proof of the authenticity of their digital\nidentity data.\n\n10. The vLEI Ecosystem Governance Framework MUST allow vLEI Ecosystem stakeholders to be\naccountable to each other for conformance to the purpose, principles, and policies of the\nVLEI Ecosystem Governance Framework. All vLEI Ecosystem stakeholders MUST be\nresponsible and be able to demonstrate compliance with any other requirements of\napplicable law. Nothing in the vLEI Ecosystem Governance Framework SHOULD require vLEI\nEcosystem stakeholder to breach applicable law in order to perform its obligations under the\nVLEI Ecosystem Governance Framework.\n\nGeneral Requirements\n\n1. All LEls contained in vLEIs MUST maintain a LEI Entity Status of Active and a LEI Registration\nStatus of Issued, Pending Transfer or Pending Archival in the Global LEI System.\n\n2. AllIssuers of vLEIs MUST verify that a Holder’s Autonomic Identifier (AID) is controlled by the\nHolder.\n\n3. Al QVIs MUST have executed a vLEI Issuer Qualification Agreement.\n\n4. AllQVIs MUST successfully complete Annual vLEI Issuer Qualification.\n\n5. GLEIF MUST publish the vLEI Ecosystem Governance Framework on gleif.org and follow the\npolicies in the Revisions section for all revisions of the vLEI Ecosystem Governance\nFramework.\n\n6. VLEIs MUST be revocable following the policies specified in vLEI Ecosystem Governance\nFramework.\n\n7. QVIs MUST ensure that parties providing Third-Party Services comply with the vLEI\nEcosystem Governance Frameworks when providing vLEI services to a QVI.\n\nRevisions\n1. At a minimum, the vLEI Ecosystem Governance Framework MUST be reviewed annually.\n2. Interim revisions to the vLEI Ecosystem Governance Framework to reflect necessary\ntechnical changes or updates also MAY be considered.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 8 of 12\nPrimary Document\nPublic Document Version 1.0\nGLEIF 2022-12-16_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2022-12-16\n\nPrimary-Document _v1.0_final.docx\n","contentLength":2559,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:12:31.494Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-primary-document_v1.0_final.pdf","content":"2.1 These revisions MAY be triggered by changes to vLEI Ecosystem services, processes,\noperations, technical architecture and infrastructure, Identifier or Credential\nGovernance Frameworks.\n\n3. Revisions to the Primary Document are subject to the following policies:\n\na. Allrevisions to the Primary Document MUST be identified with a revision number\nthat is a sequential integer.\n\nb. Revisions to the Primary Document SHALL be subject to public review which will be\nconducted as community reviews by members of the Trust over IP Foundation for a\nperiod of at least 15 days.\n\n4. Revisions to the Controlled Documents are subject to the following policies:\n\na. All revisions to Controlled Documents MUST be identified with a revision number\nthat is a sequential integer.\n\nb. Revisions to the vLEl Issuer Qualification Agreement, including all of its appendices,\nSHALL NOT be subject to public review and will be reviewed and approved by GLEIF\nonly.\n\nc. All other Controlled Documents SHALL be subject to public review which will be\nconducted as community reviews by members of the Trust over IP Foundation for a\nperiod of at least 15 days.\n\n5. All revisions to the vLEI Ecosystem Governance Framework MUST be approved by GLEIF\nusing its Change Management Process.\n\nExtensions\n\n1. GLEIF welcomes other Governance Frameworks to leverage the vLEI Ecosystem Governance\nFramework but does not anticipate the need at this time to specify formal extensions from\nother external Governance Frameworks that will leverage the vLEI Ecosystem Governance\nFramework.\n\n2. The vLEIl Ecosystem Governance Framework is extended by the following internal\ngovernance frameworks: GLEIF Identifier Governance Framework, Qualified vLEI Issuer\nIdentifier and vLEI Credential Governance Framework and 4 Credential Governance\nFrameworks\n\nGLEIF Identifier Governance Framework, v1.0\nA document that details the purpose, principles, policies, and specifications that apply to the use\nof the GLEIF Root Autonomic Identifier (AID) and its GLEIF Delegated AIDs in the vLEI Ecosystem.\nQualified vLEl Issuer Identifier and vLEI Credential Governance Framework, v1.0\nA document that details the requirements to enable the Delegated AlDs and the vLEI to be issued\nby GLEIF to QVIs which allows the QVIs to issue, verify and revoke Legal Entity vLEI Credentials,\nLegal Entity Official Organizational Role vLEI Credentials and Legal Entity Engagement Context\nRole vLEI Credentials.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 9 of 12\nPrimary Document\nPublic Document Version 1.0\nGLEIF 2022-12-16_verifiable-LEI-(vLEI)-Ecosystem-Governance-Framework- 2022-12-16\nPrimary-Document _v1.0_final.docx\n","contentLength":2674,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:12:31.494Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-primary-document_v1.0_final.pdf","content":"Qualified vLEI Issuer Authorization vLEIl Credential Governance Framework, v1.0\nA document that details the requirements for this vLEI to enable simple, safe, secure instruction\nand authorization by a Legal Entity Authorized Representative (LAR) sent to a QVI for the\nissuance and revocation of vLEI Role Credentials.\nLegal Entity vLEI Credential Governance Framework, v1.0\nA document that details the requirements for a vLEI as the entity level credential issued by a QVI\nto a Legal Entity.\nLegal Entity Official Organizational Role vLEI Credential Governance Framework, v1.0\nA document that details the requirements for vLEI Role Credentials issued by a QVI to official\nrepresentatives of a Legal Entity.\nLegal Entity Engagement Context Role vLEI Credential Governance Framework, v1.0\nA document that details the requirements for vLEI Role Credentials issued to representatives of a\nLegal Entity in other than official roles but in functional or other context of engagement.\nSchedule of Controlled Documents\nDID URLs for all documents will be published with the v1.0 Draft of the Ecosystem Governance\nFramework.\nThe v1.0 Draft can be viewed at:\nhttps://www.gleif.org/en/lei-solutions/gleifs-digital-strategy-for-the-lei/introducing-the-verifiable-\nlei-vlei\nGlossary\nverifiable LEI (vLEI) Ecosystem Governance Framework Glossary, v1.0\nA document that lists all defined terms have been referenced in the vLEI EGF documents.\nRisk Assessment\nverifiable LEI (vLEI) Ecosystem Governance Framework Risk Assessment, v1.0\nA spreadsheet that assesses certain risk categories regarding the operation of the vLEI Ecosystem and\nInfrastructure.\nTrust Assurance and Certification\nverifiable LEI (vLEI) Ecosystem Governance Framework Trust Assurance Framework, v1.0\nThis spreadsheet focuses on the ‘MUST’ statements within the other vLEI EGF documents and\nspecifies the services/processes that will be used to evaluate compliance with these statements.\nGovernance Requirements\nverifiable LEI (vLEI) Ecosystem Governance Framework Governance Requirements v1.0\nThis document specifies the governance of GLEIF in its role in the Global LEI System including the the\nregulatory oversight of GLEIF by the Regulatory Oversight Committee. Every LEl must be managed\naccording to this governance which places GLEIF in the management role for the Global LEI System.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 10 of 12\nPrimary Document\nPublic Document Version 1.0\nGLEIF 2022-12-16_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2022-12-16\nPrimary-Document _v1.0_final.docx\n","contentLength":2574,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:12:31.494Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-gleif-identifier-governance-framework_v1.0_final.pdf","content":"OGLEIF’ protecting digital rust\nverifiable LEI (vLEI)\nEcosystem Governance Framework v1.0\nGLEIF Identifier Governance Framework\nPublic\nDocument Version 1.0\n2022-12-16\nS e A\no - ” AN 4\n‘ 60 N B s\n' ey . F . .\n\ni - - \".‘-‘.}:3 ‘.' ¥ e .o o 2 :\nAN ’o.,{{-r(f,,...‘g B . .\no“ .' .. \" ° ‘ A ® » L » . 3\n\nR, B\n.\n","contentLength":306,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:13:03.325Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-gleif-identifier-governance-framework_v1.0_final.pdf","content":"verifiable LEI (VLEI) Ecosystem Governance Framework\nGLEIF Identifier Governance Framework\ndid:keri:EINmHd5g7iV-UldkkkKyBIHO52blyxZNBn9pq-\nzNrYoS?service=vlei-documents&relativeRef=/egf/docs/2022-12-\n13_GLEIF-Identifier-GF-Prep-1.0-Publication_v0.7_work.docx\n_ Global Legal Entity Identifier Foundation (GLEIF)\nThe verifiable LEI (vLEI) Ecosystem Governance Framework is\npublished on the GLEIF website. All documents published on the\nGLEIF website are published under the Creative Commons\nAttribution license.\n1 Introduction\nThis is a Controlled Document of the verifiable LEI (VLEI) Ecosystem Governance Framework. It is the\nauthoritative Governance Framework for the purpose, principles, policies, and specifications that\napply to the use of the GLEIF Root Autonomic Identifier (AID) and its GLEIF Delegated AIDs in the vLEI\nEcosystem.\n2 Terminology\nAll terms in First Letter Capitals are defined in the vLEI Glossary.\n3 Purpose\nThe GLEIF Root AID provides the Root of Trust for the ecosystem tree of trust. Each branch in that\ntree is a Chain of Trust. The Delegated AID Chain of Trust branch provides trust for delegated GLEIF\nAIDs and Qualified vLEl Issuer Delegated AIDs. The vLEI Chain of Trust branch, that attaches to the\nDelegated AID Chain of Trust branch, provides trust for all vLEIs within the vLEl ecosystem.\nScope\nThe scope of this Identifier Governance Framework is limited to the GLEIF Root AID and its Delegated\nAlDs.\n4 Principles\nThe following principles guide the development of policies in this Identifier Governance Framework.\nNote that they apply in addition to the Core Policies defined in the vLEl Ecosystem Governance\nFramework.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 2 of 10\nGLEIF Identifier Governance Framework\nPublic Document Version 1.0\nGLEIF 2022-12-16_verfiable-LEI-vLEI-Ecosystem-Governance-Framework-GLEIF- 2022-12-16\nIdentifier-Governance-Framework_v1.0_final.docx\n","contentLength":1926,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:13:03.325Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-gleif-identifier-governance-framework_v1.0_final.pdf","content":"4.1 Highest Duty of Care\n\nGLEIF shall exercise the highest duty of care in generating and administering the GLEIF AID and all its\nDelegated AlDs as these are the security foundation of the entire vLEI Ecosystem.\n\n4.2 Self-Certifying (Autonomic) Identifiers\n\nAll identifiers in the vLEI Ecosystem shall be self-certifying identifiers (specifically KERI Autonomic\nIdentifiers or AIDs), i.e., it must be possible to verify directly using cryptography alone as defined by\nthe Key Event Receipt Infrastructure (KERI) protocol that the identifier was generated from a specific\nset of cryptographic key pair(s).\n\n4.3 Cryptographic Root of Trust\n\nAll AIDs in the VLEI Ecosystem shall be generated from a random number seed large enough to\nprovide adequate cryptographic security for the branch of the tree of trust that provides the Chain of\nTrust for which a given AID is the head.\n\n5 AID Generation\n\n1. An AID conformant with this Governance Framework MUST be created from two sets of\nasymmetric signing key pairs generated from a cryptographically-secure pseudo-random\nnumber generator (SPRNG) or a true random number generator with at least 128 bits of\ncryptographic Root (see section 3.1 of Technical Requirements Part 1 KERI Infrastructure).\n\n2. The AID MUST then be derived from a cryptographic digest of a serialization of the public\nkeys of the first set of key pairs and a cryptographic digest of second set of key pairs, as well\nas any other identifiers and configuration parameters associated with the supporting\ninfrastructure for the Root Identifier as specified in the Technical Requirements Part 1 KERI\nInfrastructure.\n\n3. The cryptographic digest MUST have at least 128 bits of cryptographic strength.\n\n6 AID Controllers\n\n1. All Controllers MUST establish their own Private Key Store.\n\n2. All Controllers MUST keep their private keys secret.\n\n3. Agiven Controller MUST control one and only one key pair from each set of keys.\n\n4. The KERI protocol MUST be used to transfer control authority from one set of keys to\nanother.\n\n5. Continuity and Survivorship\n\na. GLEIF MUST have a Continuity Policy for the survival of control authority of all\nControllers for the GLEIF Root AID and its Delegated AIDs, including Escrow Agents.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 3 of 10\nGLEIF Identifier Governance Framework\nPublic Document Version 1.0\nGLEIF 2022-12-16_verfiable-LEI-vLEI-Ecosystem-Governance-Framework-GLEIF- 2022-12-16\nIdentifier-Governance-Framework_v1.0_final.docx\n","contentLength":2504,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:13:03.325Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-gleif-identifier-governance-framework_v1.0_final.pdf","content":"b. QVIs and Legal Entities SHOULD have a Continuity Policy for the survival of control\n\nauthority of their Controllers.\n7 GLEIF AID Genesis\nThe policies in this section apply to the genesis event for the GLEIF Root AID, the GLEIF Internal\nDelegated AID (GIDA) and the GLEIF External Delegated AID (GEDA).\n\n1. GLEIF MUST establish a list of initial GLEIF Controllers that specifies:\n\na. The legal identity of each Controller.\n\nb. Which Controllers shall control the GLEIF Root AID, the GIDA and the GEDA.\n\nc. Aset of policies MUST be put in place that ensure fault-tolerance with respect to\ncommon mode failures of the multi-sig signing authority of the set of GLEIF\nControllers, e.g., a Designated Survivor policy and/or restrictions on joint travel and\nin-person attendance of meetings).\n\n2. GLEIF MUST establish real-time Out-of-Band Interaction (OOBI) session(s) in which all initial\nGLEIF Controllers are present. An example is a continuous web meeting attended by all\nparties on both audio and video. The essential feature is that there is a mutual live\npresentation by all participants that verifies their live participation in the session.\n\na. Each session MUST be recorded, and the recording stored in high-security storage.\n\n3. All GLEIF Controllers MUST mutually authenticate each other’s legal identities before\nproceeding with any further steps. An example is each Controller visually presenting one or\nmore legal identity credentials for all other Controllers to verify against the list of initial GLEIF\nControllers.\n\n4. The Root AID GLEIF Authorized Representative, the Internal Delegated AID GLEIF Authorized\nRepresentative and the External Delegated AID GLEIF Authorized Representative are GLEIF\nControllers.\n\n5. Creation of GLEIF Root AID\nThe following steps MUST be performed in the order listed and completed during each OOBI\nsession for the GLEIF Root AID.\n\na. Each Root AID GLEIF Authorized Representative (Root GAR) MUST generate its own\nsingle signature AID that is a participating member in the group of AIDs that will be\nused to create the GLEIF Root AID.\n\nb. Each Root GAR MUST use an OOBI protocol (such as a QR code or live chat) to share\nits own AID and Service Endpoints with the other Root GAR. For each Root GAR this\nprovides the participating AID and the service endpoint whereby the other Root\nGARs may obtain the Key Event Log (KEL) of its participating AID.\n\nc. Each Root GAR MUST send a Challenge Message to every other Root GAR as defined\nin the Technical Requirements Part 1 for the purposes of cryptographic\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 4 of 10\n\nGLEIF Identifier Governance Framework\n\nPublic Document Version 1.0\nGLEIF 2022-12-16_verfiable-LEI-vLEI-Ecosystem-Governance-Framework-GLEIF- 2022-12-16\n\nIdentifier-Governance-Framework_v1.0_final.docx\n","contentLength":2822,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:13:03.325Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-gleif-identifier-governance-framework_v1.0_final.pdf","content":"authentication of their Root GAR AID. The Challenge Message MUST be unique to\neach OOBI session.\n\nd. Each Root GAR MUST verify in real time that a response to the Challenge Message\nwas received from every other Root GAR.\n\ne. Each Root GAR MUST verify the signature of every other Root GAR.\n\nf. One of the Root GARs MUST be designated as the Root AID GLEIF Authorized\nRepresentative Lead (Root GAR Lead).\n\ng. The Root GAR Lead MUST select the AIDs from the set of Root GAR s for the ordered\nset of authorized participant members in the multi-sig group and configure and\napprove the weight threshold and ordered set of participants for both the current\nand next set and threshold of participants.\n\nh. The Root GAR Lead MUST select the AIDs and Service Endpoints for the GLEIF Root\nAID Witness Pool.\n\ni. Using the current public key and the next public key digest from each of the\nparticipating AID Inception Events and the Root Witness AIDs, the Root GAR Lead\nMUST generate the GLEIF Root AID Inception Event and publish this to the other\nRoot GARs and to the Root AID Witnesses designated by that Inception Event. The\npublished Inception Event includes as an attachment OOBIs for each of the Root AID\nWitnesses.\n\nj. Each Root GAR MUST verify the set of public keys, the next public key digest, the\nthreshold, the next threshold, and Root AID Witness identifiers in the Root AID\nInception Event.\n\nk. Each Root GAR MUST verify the set of service endpoints for the Root AID Witnesses.\n\n|. Each Root GAR MUST sign and publish to the Root AID Witnesses their signature on\nthe Root AID Inception Event.\n\nm. Each Root GAR MUST verify that the Root AID Inception Event is fully witnessed by\nevery Root AID Witness.\n\n6. Creation of the GLEIF Internal Delegated AIDs\nThe following steps MUST be performed in the order listed and completed during each OOBI\nsession for each of the two GLEIF Delegated AlIDs, namely, the GLEIF Internal Delegated AID\n(GIDA) in this section, and the GLEIF External Delegated AID (GEDA) in section 7.\n\na. Each Internal Delegated AID GLEIF Authorized Representative (Internal GAR) that is a\nparticipating member in the group of AIDs MUST generate its own single signature\nAID that will be used to create the GIDA.\n\nb. Each Internal GAR MUST use an OOBI protocol (such as a QR code or live chat) to\nshare its own AID and Service Endpoints with the other Internal GARs. For each\nInternal GAR, this provides the participating AID and the service endpoint whereby\nthe other Internal GARs may obtain the KEL of its participating AID.\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 5 of 10\n\nGLEIF Identifier Governance Framework\n\nPublic Document Version 1.0\nGLEIF 2022-12-16_verfiable-LEI-vLEI-Ecosystem-Governance-Framework-GLEIF- 2022-12-16\n\nIdentifier-Governance-Framework_v1.0_final.docx\n","contentLength":2821,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:13:03.325Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-gleif-identifier-governance-framework_v1.0_final.pdf","content":"c. Each Internal GAR MUST send a Challenge Message to every other Internal GAR as\ndefined in the Technical Requirements Part 1 KERI Infrastructure for the purposes\nof cryptographic authentication of their GIDA. The Challenge Message MUST be\nunique to each OOBI session.\n\nd. Each Internal GAR MUST verify in real time that a response to the Challenge Message\nwas received from every other Internal GAR.\n\ne. Each Internal GAR MUST verify the signature of every other Internal GAR.\n\nf. One of the Internal GAR s MUST be designated as the Internal Delegated AID GLEIF\nAuthorized Representative (Internal GAR Lead)\n\ng. The Internal GAR Lead MUST select the AIDs and Service Endpoints for the GLEIF\nInternal Delegated AID Witness Pool.\n\nh. The Internal GAR Lead MUST select the AIDs from the set of Internal GAR for the\nordered set of authorized participant members in the multi-sig group and configure\nand approve the weight threshold and ordered set of participants for both the\ncurrent and next set and threshold of participants.\n\ni. Using the current public key and the next public key digest from each of the\nparticipating AID Inception Events, the Internal Delegated Witness AIDs, and the\nGLEIF Root AID, the Internal GAR Lead MUST generate the GLEIF Internal Delegated\nAID Inception Event and publish this to the other Internal GARs and to the Delegated\nAID Witnesses designated by that Inception Event. The published Inception Event\nincludes as an attachment OOBIs for each of the Internal Delegated AID Witnesses.\n\nj. Each Internal GAR MUST verify the set of public keys, the next public key digest, the\nWitness identifiers, the threshold, the next threshold, and the Root AID in the\nInternal Delegated AID Inception Event.\n\nk. Each Internal GAR MUST verify the set of Witness endpoints for the GIDA.\n\nI. Each Internal GAR MUST sign and publish to the Internal Delegated AID Witnesses its\nsignature on the Internal Delegated AID Inception Event.\n\nm. Each Internal GAR MUST verify that the Internal Delegated AID Inception Event is\nfully witnessed by every Witness.\n\n7. Creation of the GLEIF External Delegated AlDs\nThe following steps MUST be performed in the order listed and completed during-each OOBI\nsession for each of the two GLEIF Delegated AlIDs, namely, the GLEIF Internal Delegated AID\n(GIDA) in section 6 and the GLEIF External Delegated AID (GEDA) in this section.\n\na. Each External Delegated AID GLEIF Authorized Representative (External GAR) that is\na participating member in the group of AIDs MUST generate its own single signature\nAID that will be used to create the GEDA.\n\nb. Each External GAR MUST use an OOBI protocol (such as a QR code or live chat) to\nshare its own AID and Service Endpoints with the other External GARs. For each\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 6 of 10\n\nGLEIF Identifier Governance Framework\n\nPublic Document Version 1.0\nGLEIF 2022-12-16_verfiable-LEI-vLEI-Ecosystem-Governance-Framework-GLEIF- 2022-12-16\n\nIdentifier-Governance-Framework_v1.0_final.docx\n","contentLength":3032,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:13:03.325Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-gleif-identifier-governance-framework_v1.0_final.pdf","content":"External GAR, this provides the participating AID and the service endpoint whereby\nthe other External GARs may obtain the KEL of its participating AID.\n\nc. Each External GAR MUST send a Challenge Message to every other External GAR as\ndefined in the Technical Requirements Part 1 KERI Infrastructure for the purposes of\ncryptographic authentication of their GEDA. The Challenge Message MUST be\nunique to each OOBI session.\n\nd. Each External GAR MUST verify in real time that a response to the Challenge\nMessage was received from every other External GAR.\n\ne. Each External GAR MUST verify the signature of every other External GAR.\n\nf. One of the External GARs MUST be designated as the External Delegated AID GLEIF\nAuthorized Representative Lead (External GAR Lead).\n\ng. The External GAR Lead MUST select the AIDs and Service Endpoints for the GLEIF\nExternal Delegated AID Witness Pool.\n\nh. The External GAR Lead MUST select the AIDs from the set of External GARs for the\nordered set of authorized participant members in the multi-sig group and configure\nand approve the weight threshold and ordered set of participants for both the\ncurrent and next set and threshold of participants.\n\ni. Using the current public key and the next public key digest from each of the\nparticipating AID Inception Events, the External Delegated Witness AlDs, and the\nGLEIF Root AID, or the External GAR Lead MUST generate the GLEIF External\nDelegated AID Inception Event and publish this to the other External GARs and to the\nExternal Delegated AID Witnesses designated by that Inception Event. The published\nInception Event includes as an attachment OOBIs for each of the External Delegated\nAID Witnesses.\n\nj. Each External GAR MUST verify the set of public keys, the next public key digest, the\nWitness identifiers, the threshold, the next threshold, and the Root AID in the\nExternal Delegated AID Inception Event.\n\nk. Each External GAR MUST verify the set of Witness endpoints for the GEDA.\n\nI. Each External GAR MUST sign and publish to the External Delegated AID Witnesses\ntheir signature on the External Delegated AID Inception Event.\n\nm. Each External GAR MUST verify that the External Delegated AID Inception Event is\nfully witnessed by every Witness.\n\n8. Rotation Event to delegate the GLEIF Internal Delegated AlDs\nThe following steps MUST be performed in the order listed and completed during this OOBI\nsession for each of the two GLEIF Delegated AlIDs, namely, the GLEIF Internal Delegated AID\n(GIDA) in this section and the GLEIF External Delegated AID (GEDA) in section 9.\nThe anchor in this Rotation Event is the mechanism by which the delegation is authorized by\nthe Delegator. The Rotation Event with the anchoring digest of the Inception Event of the\nDelegated AID, when Fully Signed, is a verifiable cryptographic commitment to the\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 7 of 10\nGLEIF Identifier Governance Framework\nPublic Document Version 1.0\nGLEIF 2022-12-16_verfiable-LEI-vLEI-Ecosystem-Governance-Framework-GLEIF- 2022-12-16\nIdentifier-Governance-Framework_v1.0_final.docx\n","contentLength":3104,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:13:03.325Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-gleif-identifier-governance-framework_v1.0_final.pdf","content":"delegation. The Delegated AlDs are not verifiable until they are anchored in the KEL of the\nDelegator e.g., the Root AID. A new event must be created to include these anchors.\n(Delegation in KERI is cooperative. It requires a cryptographic commitment from both the\nDelegator and the Delegate.)\n\na. Athreshold satisficing subset of Internal GARs MUST each rotate their participating\nAlDs.\n\nb. Using the current public key, the next public key digest from each of the participating\nAID Rotation Events, and the digest of the GLEIF Internal Delegated AID Inception\nEvent, the Internal GAR Lead MUST generate a GLEIF Internal Delegated AID Rotation\nEvent and publish this to the other participating Internal GARs and to the Root AID\nWitnesses.\n\nc. Each Internal GAR MUST verify the set of public keys, the next public key digest, and\ndelegated Inception Event digests in that Rotation Event.\n\nd. Each Internal GAR MUST sign and publish to the Root AID Witnesses their signature\non the Root AID Rotation Event.\n\ne. Each Internal GAR MUST verify that the Root AID Rotation Event is fully witnessed by\nevery Root AID Witness.\n\n9. Rotation Event to delegate the GLEIF External Delegated AlDs\nThe following steps MUST be performed in the order listed and completed during this OOBI\nsession for each of the two GLEIF Delegated AlIDs, namely, the GLEIF Internal Delegated AID\n(GIDA) in section 8 and the GLEIF External Delegated AID (GEDA) on this section.\nThe anchor in this Rotation Event is the mechanism by which the delegation is authorized\nby the Delegator. The Rotation Event with the anchoring digest of the Inception Event of\nthe Delegated AID, when Fully Signed, is a verifiable cryptographic commitment to the\ndelegation. The Delegated AlDs are not verifiable until they are anchored in the KEL of the\nDelegator e.g. the Root AID. A new event must be created to include these anchors.\n(Delegation in KERI is cooperative. It requires a cryptographic commitment from both the\nDelegator and the Delegate.)\n\na. Athreshold satisficing subset of External GARs MUST each rotate their participating\nAlDs.\n\nb. Using the current public key, the next public key digest from each of the participating\nAID Rotation Events, and the digest of GLEIF External Delegated AID Inception Event,\nthe External GAR Lead MUST generate a GLEIF External Delegated AID Rotation Event\nand publish this to the other participating External GARs and to the Root AID\nWitnesses.\n\nc. Each External GAR MUST verify the set of public keys, the next public key digest, and\ndelegated Inception Event digests in that Rotation Event.\n\nd. Each External GAR MUST sign and publish to the Root AID Witnesses their signature\non the Root AID Rotation Event.\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 8 of 10\n\nGLEIF Identifier Governance Framework\n\nPublic Document Version 1.0\nGLEIF 2022-12-16_verfiable-LEI-vLEI-Ecosystem-Governance-Framework-GLEIF- 2022-12-16\n\nIdentifier-Governance-Framework_v1.0_final.docx\n","contentLength":2985,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:13:03.325Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-gleif-identifier-governance-framework_v1.0_final.pdf","content":"e. Each External GAR MUST verify that the Root AID Rotation Event is fully\nwitnessed by every Root AID Witness.\n\nf. Each participating External GAR MUST verify the delegated Inception Event digest in\nthat Interaction Event.\n\ng. Each participating External GAR MUST sign and publish to the GLEIF External\nDelegated AID Witnesses their signature on the GLEIF External Delegated AID\nInteraction Event.\n\nh. Each participating External GAR MUST verify that the GLEIF External Delegated AID\nInteraction Event is fully witnessed by every Witness.\n\n8 Publication of GLEIF Root AID and GLEIF\nDelegated AIDs\n\n1. The GLEIF Root AID and GLEIF Delegated Internal and External AIDs MUST be published in a\nsufficiently strongly correlated and fault-tolerant manner to establish them as unique AlDs\nfor GLEIF.\n\n2. The set of publication points MUST include at least 4 of the list of publication points initially\n(highlighted below) following the creation of the GLEIF Root AID and GLEIF Delegated\nInternal and External AlDs.\n\na. The GLEIF HTTPS website.\n\nb. The HTTPS website of the GLEIF Regulatory Oversight Committee.\n\nc. The HTTPS websites of all QVis.\n\nd. Inthe KERI Event Log hosted by GLEIF KERI Witnesses.\n\ne. Published to at least 3 international newspapers in separate national jurisdictions\n(applies only to the GLEIF Root AID).\n\nThese publications are: Financial Times UK edition, South China Morning Post - Business\nand American Banker.\n\nf. Published to github repositories\nThe Web of Trust github repository\nPublic GLEIF-controlled github repository\n\ng. Published to public registries\nIANA (IETF RFCs) registries\nISO registries\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 9 of 10\n\nGLEIF Identifier Governance Framework\n\nPublic Document Version 1.0\nGLEIF 2022-12-16_verfiable-LEI-vLEI-Ecosystem-Governance-Framework-GLEIF- 2022-12-16\n\nIdentifier-Governance-Framework_v1.0_final.docx\n","contentLength":1901,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:13:03.325Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-gleif-identifier-governance-framework_v1.0_final.pdf","content":"9 Abandonment\n1. Voluntary abandonment\nGLEIF MUST abandon its GLEIF Root AID if GLEIF no longer holds the role of root of trust\nfor the vLEI Ecosystem.\n2. Private key compromise or natural disaster\nIf in the extremely unlikely event of the failure of all key recovery provisions specified in\nTechnical Requirements Part 1: KERI Infrastructure, GLEIF MUST abandon its Root AID\nand Delegated Internal and External AIDs and create and publish its new Root AID and\nDelegated Internal and External AIDs.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 10 of 10\nGLEIF Identifier Governance Framework\nO Public Document Version 1.0\n@ 2022-12-16_verfiable-LEI-vLEI-Ecosystem-Governance-Framework-GLEIF- 2022-12-16\nIdentifier-Governance-Framework_v1.0_final.docx\n","contentLength":768,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:13:03.325Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-qualified-vlei-issuer-identifer-vlei-credential-governance-framewo.pdf","content":"O:GLEIF, S\nverifiable LEI (vLEI)\nEcosystem Governance Framework v1.0\nQualified vLEI Issuer Identifier and\nVvLEIl Credential Governance Framework\nPublic\nDocument Version 1.1\n2023-04-03\nS\n- ” AN 4\n' S N . e\n' T & = .\ni - - Wt '}\\)/o ‘.' ¥ e .o o 2 :\n.\\ . T’ 3 \"' ,{z\"{( ,' . .O\" ve * ; .. o.\no“ .' .. \" ° ‘ A ® * o » . 3\no .\n.\n","contentLength":325,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:13:32.483Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-qualified-vlei-issuer-identifer-vlei-credential-governance-framewo.pdf","content":"verifiable LEI (vLEI) Ecosystem Governance Framework\nQualified vLEl Issuer Identifier and vLEI Credential Governance\nFramework\ndid:keri:EINmHd5g7iV-UldkkkKyBIHO52blyxZNBn9pq-\nzNrYoS?service=vlei-documents&relativeRef=/egf/docs/2023-04-\n03_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework-Qualified-\nVLEl-Issuer-Identifer-vLEI-Credential-Governance-\nFramework_v1.1 Final.docx\n_ Global Legal Entity Identifier Foundation (GLEIF)\nThe verifiable LEI (vLEI) Ecosystem Governance Framework is published\non the GLEIF website. All documents published on the GLEIF website are\npublished under the Creative Commons Attribution license.\n1 Introduction\nThis is a Controlled Document of the verifiable LEI (VLEI) Ecosystem Governance Framework (VLEI\nEcosystem Governance Framework). It is the authoritative Governance Framework for the Qualified\nVLE! Issuer Delegated AIDs and the vLEI Credential (QVI vLEI Credential). It specifies the purpose,\nprinciples, policies, and specifications that apply to the use of the Qualified vLEI Issuer Delegated\nAlDs and the QVI vLEI Credential in the vLEI Ecosystem.\n2 Terminology\nAll terms in First Letter Capitals are defined in the vLEI Glossary.\n3 Purpose\nThe purpose of the QVI vLEI Credential is to:\n\no enable a QVIto issue, verify and revoke Legal Entity vLEI Credentials, Legal Entity Official\nOrganizational Role vLEI Credentials and Legal Entity Engagement Context Role VLEI\nCredentials;\n\no revoke this Credential in the case that a QVI has been terminated for not successfully\ncompleting Annual vLEI Issuer Qualification, for not remediating qualification issues\ndocumented as a result of Annual vLEI Issuer Qualification, or if the LEI of a QVI lapses or is\nretired, which would prevent the terminated vLEI Issuer from any further issuance,\nverification or revocation of vLEls;\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 2 of 9\n\nQualified vLEI Issuer Identifier and vLEI Credential Governance\n\nFramework\n\nPublic Document Version 1.1\n\n2023-04-03_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2023-04-03\nGLEIF Qualified-vLEl-Issuer-ldentifier-vLEI-Credential-Governance-Framework_\n\nv1.1_Final\n","contentLength":2160,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:13:32.483Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-qualified-vlei-issuer-identifer-vlei-credential-governance-framewo.pdf","content":"* introduce a grace period within this Credential to allow GLEIF to be able to manage the\ntransition of Legal Entities for which Legal Entity vLEI Credentials, Legal Entity Official\nOrganization Role vLEI Credentials, as well as Legal Entity Engagement Context Role vLEI\nCredentials, to contract with new QViIs.\n\n4 Scope\nThe scope of this Identifier and Credential Governance Framework is limited to GLEIF and the Issuer,\nHolders, and Verifiers of the QVI Delegated AIDs and the QVI vLEI Credential.\n5 Principles\nThe following principles guide the development of policies in this Identifier and Credential\nGovernance Framework. Note that they apply in addition to the Core Policies defined in the vLElI\nEcosystem Governance Framework.\n5.1 Binding to Holder\n1. The QVI vLEI Credential MUST be designed to provide a strong enough binding to the QVI\nVLEI Credential Holder that a Proof Request for the QVI vLEI Credential can be satisfied\nonly by the QVI vLEI Credential Holder.\n5.2 Context Independence\n1. The QVI vLEI Credential MUST be designed to fulfil a Proof Request for the operational\nstatus of the QVI regardless of context, including in-person, online, or over the phone.\n6 Issuer Policies\n6.1 Qualifications\n1. The Issuer MUST ensure that the Issuer of the QVI vLEI Credentials is GLEIF.\n6.2 Credential\nThe Issuer MUST:\n1. Use the QVI vLEI Credential schema defined in section 10.1.\n2. Include the Claims marked as Required in section 10.1.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 3 of 9\nQualified vLEI Issuer Identifier and vLEI Credential Governance\nFramework\nPublic Document Version 1.1\n2023-04-03_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2023-04-03\nGLEIF Qualified-vLEl-Issuer-ldentifier-vLEI-Credential-Governance-Framework_\nv1.1_Final\n","contentLength":1786,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:13:32.483Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-qualified-vlei-issuer-identifer-vlei-credential-governance-framewo.pdf","content":"6.3 QVI Identity Verification\n1. Identity Assurance\n\na. An External GLEIF Authorized Representative (External GAR) MUST perform\nidentity assurance of each person serving in the role of QVI Authorized\nRepresentative (QAR) to at least Identity Assurance Level 2 (IAL2) as defined in\nNIST 800-63A (https://pages.nist.gov/800-63-3/sp800-63a.html)\n\nb. A minimum of two QARs MUST form the QVI multi-sig group.\n\nC. An External GAR MUST lead for the anchoring action for the QVI External\nDelegated AID described below.\n\nd. The External GAR Lead MAY be a different External GAR than the External GAR\nLead for the creation of the GLEIF External Delegated AlIDs.\n\n2. Identity Authentication\n\na. Acredential wallet MUST be set up for the QVI.\n\nb. The QVI MUST designate a QAR to act on its behalf.\n\nC. An External GAR and each QAR MUST establish a real-time OOBI session in which\nthe External GAR and the QAR are present. An example is a continuous web\nmeeting attended by all parties on both audio and video.\n\nd. The following steps MUST be performed in this order and completed during this\nOOBI session.\n\nI. The External GAR MUST perform manual verification of the QAR’s legal identity\nfor which the External GAR has already performed Identity Assurance. An\nexample is the QAR visually presenting one or more legal identity credentials and\nthe External GAR compares the credentials verified during Identity Assurance to\nthe QAR Person.\n\nII. The External GAR MUST use an OOBI protocol (such as a QR code or live chat) to\nshare the GLEIF External Delegated AID (GEDA) with the QAR.\n\nIl. An QAR MUST use an OOBI protocol (such as a QR code or live chat) to share the\nQVI AID with the External GAR.\n\nIV. The External GAR MUST send a Challenge Message from the GEDA to the QVI AID\nas defined in the Technical Requirements Part 1 KERI Infrastructure for the\npurposes of cryptographic authentication of the QVI AID. The Challenge\nMessage MUST be unique to the OOBI session.\n\nV. The QAR MUST use its Private Key Store to sign and return the response to the\nChallenge Message, after which the QAR MUST acknowledge that this action has\nbeen completed.\n\nVI. The External GAR MUST verify in real time that the response to the Challenge\nMessage was received from the QAR.\n\nVII. When the response to the Challenge Message has been received, the External\nGAR MUST verify the signature of the QAR.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 4 of 9\nQualified vLEI Issuer Identifier and vLEI Credential Governance\nFramework\nPublic Document Version 1.1\n2023-04-03_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2023-04-03\n@ Qualified-vLEl-Issuer-ldentifier-vLEI-Credential-Governance-Framework_\nv1.1_Final\n","contentLength":2712,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:13:32.483Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-qualified-vlei-issuer-identifer-vlei-credential-governance-framewo.pdf","content":"6.4 Creation of QVI Delegated AIDs\n1. The creation of the QVI Delegated AlDs follows the successful completion of Identity\nVerification by the External GAR Lead of each QAR.\n2. The following steps MUST be performed in the order listed and completed during an OOBI\nsession for a given QVI Delegated AID.\n\na. Each Delegated AID QVI Authorized Representative (QAR) that is a participating\nmember in the group of AIDs MUST generate its own individual single signature\nAID that will be used to create the QVI Delegated AID.\n\nb. Each QAR MUST use an OOBI protocol (such as a QR code or live chat) to share its\nown AID with the other QAR s. For each QAR, this provides the participating AID\nand the service endpoint whereby the other QARs may obtain the KEL of its\nparticipating AID.\n\nc. Each QAR MUST send a Challenge Message to every other QAR as defined in the\nTechnical Requirements Part 1 KERI Infrastructure for the purposes of\ncryptographic authentication of their individual single signature AID. The\nChallenge Message MUST be unique to the OOBI session.\n\nd. Each QAR must verify in real time that a response to the Challenge Message was\nreceived from every other QAR.\n\ne. Each QAR must verify the signature of every other QAR.\n\nf. One of the QARs must be designated as the Delegated AID QVI Authorized\nRepresentative (QAR Lead).\n\ng. The QAR Lead MUST either configure or select the AIDs and Service Endpoints for\nthe QVI Delegated AID Witness Pool.\n\nh. The QAR Lead MUST select the AIDs from the set of QARs for the ordered set of\nauthorized participant members in the multi-sig group and configure and approve\nthe weight threshold and ordered set of participants for both the current and next\nset and threshold of participants.\n\ni. Using the current public key and the next public key digest from each of the\nparticipating AID Inception Events, the Delegated Witness AIDs, and the GEDA, the\nQAR Lead MUST generate the QVI Delegated AID Inception Event and publish this\nto the other QARs and to the Delegated AID Witnesses designated by that\nInception Event.\n\nj. Each QAR MUST verify the set of public keys, the next public key digest, the\nWitness identifiers, the threshold, the next threshold, and the GEDA in the\nDelegated AID Inception Event.\n\nk. Each QAR MUST verify the set of Witness endpoints for the QVI Delegated AID.\n\nI. Each QAR MUST sign and publish to the Delegated AID Witnesses their signature\non the Delegated AID Inception Event.\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 5 of 9\n\nQualified vLEI Issuer Identifier and vLEI Credential Governance\n\nFramework\n\nPublic Document Version 1.1\n\n2023-04-03_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2023-04-03\nGLEIF Qualified-vLEl-Issuer-ldentifier-vLEI-Credential-Governance-Framework_\n\nv1.1_Final\n","contentLength":2793,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:13:32.483Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-qualified-vlei-issuer-identifer-vlei-credential-governance-framewo.pdf","content":"m. Each QAR MUST verify that the Delegated AID Inception Event is fully witnessed by\nevery Witness.\n\nn. GLEIF MUST designate one of the External Delegated AID GLEIF Authorized\nRepresentative (External GARs) as the External Delegated AID GLEIF Authorized\nRepresentative (External GAR Lead).\n\n6.5 Delegation of the QVI Delegated AIDs\n1. Unless otherwise pre-approved by the GLEIF Root GARs, GLEIF External AID MUST use an\nInteraction Event to approve the delegation of the QVI Delegated AlDs.\n2. The following steps MUST be performed in the order listed and completed during this\nOO0BI session for the GLEIF External Delegated AID (GEDA).\nThe anchor in this Interaction Event is the mechanism by which the delegation is\nauthorized by the Delegator. The Interaction Event with the anchoring digest of the\nInception Event of the GEDA when Fully Signed, is a verifiable cryptographic commitment\nto the delegation.\n(Delegation in KERI is cooperative. It requires a cryptographic commitment from both the\nDelegator and the Delegate.)\na. The QAR Lead initiates a set of QARs to create a mulit-sig group and the QARs\nmutually are authenticated.\nb. The QAR Lead initiates the creation of the Inception Event using the published GLEIF\nExternal AID as the Delegator.\nc. The External GAR Lead verifies that the set of QARs in the multi-sig group in\nthis Inception Event to delegate the QVI External AID match those that the External\nGAR Lead verified according to section 6.3 above.\nd. The External GAR Lead submits request to the External GAR multi-sig group to\nanchor the Interaction event. All members of the External GAR multi-sig group trust\nExternal GAR Lead to anchor because the External GARs already have trusted\nthe External GAR Lead to perform Identity Assurance on the QARs.\ne. The External GAR Lead then submits a request to issue the Qualified vLEI Issuer vLEI\nCredential to QVI vLEIl to the External GAR multi-sig group as an Interaction Event.\n6.6 QVI vLEl Credential Issuance\n1. The GAR MUST approve issuance of a QVI vLEI Credential after the completion of QVI\nIdentity Verification in section 6.3 above.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 6 of 9\nQualified vLEI Issuer Identifier and vLEI Credential Governance\nFramework\nPublic Document Version 1.1\n2023-04-03_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2023-04-03\nGLEIF Qualified-vLEI-Issuer-ldentifier-vLEI-Credential-Governance-Framework_\nv1.1_Final\n","contentLength":2446,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:13:32.483Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-qualified-vlei-issuer-identifer-vlei-credential-governance-framewo.pdf","content":"6.7 QVI vLEI Credential Revocation\n1. Voluntary revocation\na. An External QAR MUST revoke a QVI vLEI Credential upon receipt of a Fully Signed\nrevocation request by the QAR(s) using the vLEI software.\nb. An External GAR MUST perform the revocation within the timeframe specified in\nAppendix 5, Service Level Agreement (SLA).\n2. Involuntary revocation\na. Involuntary revocation of vLEI Credentials MUST follow the process specified in\nAppendix 5, Service Level Agreement (SLA).\n6.8 Level of Assurance\ne The QVI VvLEI Credential SHOULD be issued with only a single Level of Assurance. Future\nversions of this credential governance framework MAY define multiple Levels of\nAssurance.\n6.9 Grace Period\nThe QVI vLEI Credential includes a grace period which would commence on the revocation\ndate of this credential and continue for up to 90 Days if a VLEI Issuer has been terminated for\nnot successfully completing Annual vLEI Issuer Qualification, for not remediating documented\nqualification issues, agreement or service level breaches, ceases operation or if the LEI of a QVI\nlapses or is retired.\nThe QVI vLEI Credential would be revoked, initiating the grace period, which would prevent\nthe terminated vLEI Issuer from any further issuance, verification or revocation of vLEls, and\nwill allow GLEIF to be able to manage the transition of Legal Entities holding valid Legal Entity\nVLEI Credentials, as well as Legal Entity Official Organization Role vLEI Credentials and Legal\nEntity Engagement Context Role vLEI Credentials, to contract with new QVIs.\n7 QVI Self-issuance of vLEls\n1. Following the issuance of Qualified vLEI Issuer vLEI Credentials to organizations which\nGLEIF qualifies as Qualified vLEl Issuers (QVIs), QVIs MAY issue a Legal Entity vLEl\nCredential and Legal Entity Official Organizational vLEI Role Credentials to themselves as\nLegal Entities.\n2. GLEIF MUST oversee the assighment of these VLEI Credentials issued by QVIs to\nthemselves.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 7 of 9\nQualified vLEI Issuer Identifier and vLEI Credential Governance\nFramework\nPublic Document Version 1.1\n2023-04-03_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2023-04-03\nGLEIF Qualified-vLEl-Issuer-ldentifier-vLEI-Credential-Governance-Framework_\nv1.1_Final\n","contentLength":2291,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:13:32.483Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-qualified-vlei-issuer-identifer-vlei-credential-governance-framewo.pdf","content":"3. GLEIF MAY announce a date after which QVIs qualified by GLEIF MUST contract with third-\nparty QVI organizations for the issuance of their Legal Entity vLEI Credential and Legal\nEntity Official Organizational vLEI Role Credentials. In the event the GLEIF announces such\na date, that date will be published with advance notice so that Verifiers will be able to\nupdate their tooling in order to distinguish correctly between compliant QVI self-issued\nLegal Entity vLEls and OOR vLEI Role Credentials issued before that date and non-\ncompliant QVI self-issued Legal Entity vLEls and OOR vLEI Role Credentials issued after that\ndate.\n8 Holder Policies\nThere are no restrictions on the Holders of vLEI Credentials specified in the vLEI Ecosystem.\nRestrictions may be introduced in other Ecosystems that use the vLEI Ecosystem.\n9 Verifier Policies\nThere are no restrictions on the Verifiers of vLEI Credentials specified in the vLEl Ecosystem.\nRestrictions may be introduced in other Ecosystems that use the vLEI Ecosystem. GLEIF vLElI\ncredentials are chained credentials following the TolP ACDC standard\n(https://github.com/trustoverip/tswg-acdc-specification).\n1. Each vLEI MAY be part of a provenance chain of vLEls.\n2. When part of a chain, each chained vLEI MUST include a reference to one or more\npreceding VLEls in its provenance chain.\n3. If any preceding vLEls in the provenance chain or a given vLEl is revoked, then that given\nVvLElI MUST not verify.\n4. The schema for each type of vLEI defines what type or types of vLEIs MUST or MAY be\nreferenced in its provenance section.\n10 Credential Definition\n10.1 Schema\ne The OOR vLEl Credential MUST be an Authentic Chained Data Container (ACDC) that\nMUST use for its schema at the time of issuance, the JSON Schema found in:\nhttps://github.com/WebOfTrust/vLEIl/blob/dev/schema/acdc/qualified-vLEl-issuer-vLEI-\ncredential.json\n¢ The field values in the credential MUST be as follows:\nThe \"LEI\" field value MUST be the LEI of the QVI.\nThe \"gracePeriod\" field value MUST be at least 90 (ninety) Days.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 8 of 9\nQualified vLEI Issuer Identifier and vLEI Credential Governance\nFramework\nPublic Document Version 1.1\n2023-04-03_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2023-04-03\nGLEIF Qualified-vLEl-Issuer-ldentifier-vLEI-Credential-Governance-Framework_\nv1.1_Final\n","contentLength":2386,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:13:32.483Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-qualified-vlei-issuer-identifer-vlei-credential-governance-framewo.pdf","content":"The elements in this type of credential can be returned in response to a presentation\nrequest as defined in the IPEX protocol (see below).\nThe ACDC specification is covered in the ACDC protocol specification which can be found\nin: https://github.com/WebOfTrust/ietf-keri\nThe issuance and presentation exchange protocols are covered in the Issuance and\nPresentation Exchange (IPEX) protocol specification, which can be found in:\nhttps://github.com/WebOfTrust/IETF-IPEX\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 9 of 9\nQualified vLEI Issuer Identifier and vLEI Credential Governance\nFramework\nPublic Document Version 1.1\n2023-04-03_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2023-04-03\nGLEIF Qualified-vLEl-Issuer-ldentifier-vLEI-Credential-Governance-Framework_\nv1.1_Final\n","contentLength":804,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:13:32.483Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-legal-entity-vlei-credential-governance-framework_v1.0_final.pdf","content":"OGLEIF’ protecting digital rust\nverifiable LEI (vLEI)\nEcosystem Governance Framework v1.0\nLegal Entity VLEI Credential Governance\nFramework\nPublic\nDocument Version 1.0\n2022-12-16\nNt e\n'\\' X . » £ 2.\n: S A W o e\n' £ N/ . e\n' U0, e . .\n. \" 5 SR 0’*’. \"‘ o B e .. g . :\nN r?;f*(:’_' -t BRewe - . .\n. LR .\n. \". . 2 ° ® * L » . 3\n' e ‘ , ‘ y - '. N\n)\n.\n","contentLength":348,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:13:57.388Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-legal-entity-vlei-credential-governance-framework_v1.0_final.pdf","content":"verifiable LEI (vLEI) Ecosystem Governance Framework\nLegal Entity vLEI Credential Governance Framework\ndid:keri:EINmHd5g7iV-UldkkkKyBIHO52blyxZNBn9pq-\nzNrYoS?service=vlei-documents&relativeRef=/egf/docs/2022-12-\n16_Legal-Entity-vLEI-Credential-Governance-Framework_v1.0_final.docx\n_ Global Legal Entity Identifier Foundation (GLEIF)\nThe verifiable LEI (vLEI) Ecosystem Governance Framework is published\non the GLEIF website. All documents published on the GLEIF website are\npublished under the Creative Commons Attribution license.\n1 Introduction\nThis is a Controlled Document of the verifiable LEI (vLEI) Ecosystem Governance Framework (vLEI\nEcosystem Governance Framework). It is the authoritative Governance Framework for the Legal\nEntity vLEI Credential. It specifies the purpose, principles, policies, and specifications that apply to\nthe use of this Credential in the vLEI Ecosystem.\n2 Terminology\nAll terms in First Letter Capitals are defined in the vLEI Glossary.\n3 Purpose\nThe purpose of the Legal Entity vLEI Credential is to enable the simple, safe, secure identification of a\nLegal Entity vLEI Credential Holder to any Verifier that accepts a Legal Entity vLEI Credential.\n4 Scope\nThe scope of this Credential Governance Framework is limited to Issuers, Holders, and Verifiers of the\nvLE| Legal Entity Credential.\n5 Principles\nThe following principles guide the development of policies in this Credential Governance Framework.\nNote that they apply in addition to the Core Policies defined in the vLEI Ecosystem Governance\nFramework.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 2 of 7\nLegal Entity vLEI Credential Governance Framework\nPublic Document Version 1.0\nGLEIF 2022-12-16_verifiable-LEI-vLEI-Ecosystem-Governance-Framework- 2022-12-16\nLegal-Entity-vLEI-Credential-Governance-Framework_v1.0_final\n","contentLength":1835,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:13:57.388Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-legal-entity-vlei-credential-governance-framework_v1.0_final.pdf","content":"5.1 Binding to Holder\nThe Legal Entity vLEI Credential shall be designed to provide a strong enough binding to the\nLegal Entity vLEI Credential Holder that a Proof Request for the Legal Entity vLEI Credential can\nbe satisfied only by the Legal Entity vLEI Credential Holder.\n5.2 Context Independence\nThe Legal Entity vLEI Credential shall be designed to fulfil a Proof Request for the legal identity\nof the Legal Entity vLEI Credential Holder regardless of context, including in-person, online, or\nover the phone.\n6 Issuer Policies\n6.1 Qualifications\nThe Issuer MUST:\n1. be a Qualified vLEl Issuer (QVI) in the VvLEI Ecosystem with Qualification up to date.\n2. follow all of the requirements specified in the vLEI Issuer Qualification Agreement.\n3. use the VvLEI software for hosting Witnesses, Watchers and for Key Management.\n6.2 Credential\nThe Issuer MUST:\n1. use the Legal Entity vLEI Credential schema defined in section 9.1.\n2. include the Claims marked as Required in section 9.1.\n6.3 Legal Entity Identity Verification\n1. Identity Assurance\na. A QVIAuthorized Representative (QAR) MUST verify that the LEI supplied for the\nCredential is the LEI of the Legal Entity for which the issuance request for the\nCredential has been made.\nb. A QAR MUST verify the Legal Entity Identifier (LEIl) of the Legal Entity has a LEI\nEntity Status of Active and a LEI Registration Status of Issued, Pending Transfer or\nPending Archival in the Global LEI System.\nc. The Legal Entity MUST designate a set of one or more Legal Entity Authorized\nRepresentatives (LARs) to act on its behalf.\ni. The Legal Entity SHOULD designate at least three LARs in order to use the\ngreater security of KERI multi-sig protocols.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 3 of 7\nLegal Entity vLEI Credential Governance Framework\nPublic Document Version 1.0\nGLEIF 2022-12-16_verifiable-LEI-vLEI-Ecosystem-Governance-Framework- 2022-12-16\nLegal-Entity-vLEI-Credential-Governance-Framework_v1.0_final\n","contentLength":1989,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:13:57.388Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-legal-entity-vlei-credential-governance-framework_v1.0_final.pdf","content":"d. A QAR MUST perform identity assurance of a person serving in the role of a Legal\nEntity Authorized Representative (LAR) to at least Identity Assurance Level 2 (IAL2)\nas defined in NIST 800-63A (https://pages.nist.gov/800-63-3/sp800-63a.html).\nEven when IAL2 is used for Identity Assurance, a real-time OOBI session is required\nas specified in 2.b below (essentially including the IAL3 requirement for a\nSupervised Remote In-person session).\n\ne. Asan alternative to d., the QVI MAY use Third-Party Services to perform identity\nassurance on the LARs.\n\ni. Proper security access controls MUST be put in place between the QVI and\nthe third-party provider so that the QAR can view the results of identity\nassurance and confirm that the persons that have been identity assured\nare the LARs that join the real-time OOBI session specified in 2. b.) below,\nas well as to ensure that the third-party provider follows the requirements\nof the vLEI Ecosystem Governance Framework.\n\n2. Identity Authentication\n\na. Acredential wallet MUST be set up for the Legal Entity and for each LAR.\n\ni. The Legal Entity SHOULD designate at least three LARs in order to use the\ngreater security of KERI multi-sig protocols.\n\nb. A QAR and the LARs MUST establish a real-time OOBI session in which the QAR\nand all LARs are present. An example is a continuous web meeting attended by all\nparties on both audio and video.\n\nc. The following steps MUST be performed in this completed during this OOBI\nsession.\n\ni. The QAR MUST perform manual verification of each LAR’s legal identity for\nwhich the QAR has already performed identity Assurance. An example is\neach LAR visually presenting one or more legal identity credentials and the\nQAR compares the credentials verified during ldentity Assurance to the\nAVR Person.\n\nii. The QAR MUST use an OOBI protocol (such as a QR code or live chat) to\nshare the QVI Autonomic Identifier (AID) with the LARs.\n\niii. Each LAR MUST use an OOBI protocol (such as a QR code or live chat) to\nshare the Legal Entity AID with the QAR.\n\niv. The QAR MUST send a Challenge Message to the Legal Entity AID as\ndefined in the Technical Requirements Part 1 for the purposes of\ncryptographic authentication of the Legal Entity AID. The Challenge\nMessage MUST be unique to the OOBI session.\n\nv. Each LAR MUST use its Private Key Store to sign and return the response\nto the Challenge Message, after which the LAR MUST acknowledge that\nthis action has been completed.\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 4 of 7\n\nLegal Entity vLEI Credential Governance Framework\n\nPublic Document Version 1.0\nGLEIF 2022-12-16_verifiable-LEI-vLEI-Ecosystem-Governance-Framework- 2022-12-16\n\nLegal-Entity-vLEI-Credential-Governance-Framework_v1.0_final\n","contentLength":2752,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:13:57.388Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-legal-entity-vlei-credential-governance-framework_v1.0_final.pdf","content":"vi. The QAR MUST verify in real time that a response to the Challenge\nMessage was received from each LAR.\n\nvii. When all responses to the Challenge Messages sufficient to satisfy the\nmulti-sig threshold have been received, the QAR MUST verify the\ncomplete set of signatures.\n\n6.4 Issuance\n\n1. The Legal Entity Identity Verification process outlined in section 6.3 MUST be completed\nbefore Legal Entity vLEI Credential issuance can begin.\n\n2. A workflow MUST be implemented in the operations of the QVI which requires two QARs\nto be involved in the issuance and signing a Legal Entity vLEI Credential. The first QAR\nwill perform the required above-mentioned Identity Assurance, or confirm if a third-\nparty provider is used), Identity Authentication and out-of-band validations and then will\nsign the credential. Another QAR then approves the issuance and signs the Legal Entity\nVLEI Credential.\n\n3. A QAR MUST call the vLEI Reporting API for each issuance event of Legal Entity vLEI\nCredentials.\n\n4. GLEIF MUST update the list of vLEI Credentials on the LEI page of the Legal Entity to\nreflect OOR vLEI credential issuances that have been reported by QVls.\n\n6.5 Revocation\n1. Voluntary revocation\na. A QAR MUST revoke a Legal Entity vLEI Credential upon receipt of a Fully Signed\nrevocation request by the LAR(s) of the Legal Entity, e.g., if the Legal Entity\nchooses to no longer be the Holder of this Credential.\nb. A QAR MUST perform the revocation within the timeframe specified in Appendix\n5, Service Level Agreement (SLA).\n\n2. Involuntary revocation of vLEI Credentials MUST follow the process specified in Appendix\n5, Service Level Agreement (SLA).\n\n3. A QAR MUST call the vLEI Reporting API for each revocation event of Legal Entity vLElI\nCredentials.\n\n4. GLEIF MUST update the list of vLEI Credentials on the LEI page of the Legal Entity to\nreflect vLEI credential revocations that have been reported by QVis.\n\n5. The QAR SHOULD remove the LEI of the Legal Entity from the process to monitor the\nstatus of LEls used within vLEls.\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 5 of 7\n\nLegal Entity vLEI Credential Governance Framework\n\nPublic Document Version 1.0\nGLEIF 2022-12-16_verifiable-LEI-vLEI-Ecosystem-Governance-Framework- 2022-12-16\n\nLegal-Entity-vLEI-Credential-Governance-Framework_v1.0_final\n","contentLength":2332,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:13:57.388Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-legal-entity-vlei-credential-governance-framework_v1.0_final.pdf","content":"6.6 Level of Assurance\nThe Legal Entity vLEI Credential SHOULD be issued with only a single Level of Assurance. Future\nversions of this credential governance framework MAY define multiple Levels of Assurance.\n7 Holder Policies\nThere are no restrictions on the Holders of vLEI Credentials specified in the vLEI Ecosystem.\nRestrictions may be introduced in other Ecosystems that use the vLEI Ecosystem.\n8 Verifier Policies\nThere are no restrictions on the Verifiers of vLEI Credentials specified in the vLEI Ecosystem.\nRestrictions may be introduced in other Ecosystems that use the vLEI Ecosystem.\n9 Credential Definition\n9.1 Schema\n1. The Legal Entity vLEI Credential MUST be an Authentic Chained Data Container (ACDC) that\nMUST use for its schema at the time of issuance, the JSON Schema found in:\nhttps://github.com/WebOfTrust/vLEl/blob/dev/schema/acdc/legal-entity-vLEI-\ncredential.json\n2. Thefield values in the credential MUST be as follows:\n\"LEI\" field value MUST be the LEI of Legal Entity Holder.\nAdditional data elements can be specified about the Legal Entity through issuance of\nanother ACDC credential containing these additional elements by using the chaining\ncapabilities of ACDC credentials to chain this additional ACDC credential to the related\nLegal Entity vLEI Credential.\n3. The Sources section MUST contain a source reference to the Qualified vLEI Issuer VLEI\nCredential of the QVI that issued this Legal Entity vLEI Credential.\nThe elements in this type of credential can be returned in response to a presentation request\nas defined in the IPEX protocol (see below).\nThe ACDC specification is covered in the ACDC protocol specification which can be found in:\nhttps://github.com/WebOfTrust/ietf-keri\nThe issuance and presentation exchange protocols are covered in the Issuance and\nPresentation Exchange (IPEX) protocol specification, which can be found in:\nhttps://github.com/WebOfTrust/IETF-IPEX\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 6 of 7\nLegal Entity vLEI Credential Governance Framework\nPublic Document Version 1.0\nGLEIF 2022-12-16_verifiable-LEI-vLEI-Ecosystem-Governance-Framework- 2022-12-16\nLegal-Entity-vLEI-Credential-Governance-Framework_v1.0_final\n","contentLength":2207,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:13:57.388Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-legal-entity-vlei-credential-governance-framework_v1.0_final.pdf","content":"Additional data elements can be specified about the Legal Entity, OOR Person and ECR Person\nthrough issuance of another ACDC credential containing these additional elements by using\nthe chaining capabilities of ACDC credentials to chain this additional ACDC credential to the\nrelated Legal Entity vLEI Credential, Legal Entity Official Organizational Role vLEl or a Legal\nEntity Engagement Context vLEI Credential.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 7 of 7\nLegal Entity vLEI Credential Governance Framework\nPublic Document Version 1.0\n@ 2022-12-16_verifiable-LEI-vLEI-Ecosystem-Governance-Framework- 2022-12-16\nLegal-Entity-vLEI-Credential-Governance-Framework_v1.0_final\n","contentLength":700,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:13:57.388Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-qualified-vlei-issuer-authorization-vlei-credential-framework_v1.pdf","content":"OGLEIF’ S T\nverifiable LEI (vLEI)\nEcosystem Governance Framework v1.0\nQualified vLEI Issuer Authorization\nVvLEIl Credential Framework\nPublic\nDocument Version 1.0\n2022-12-16\nS\n- ” AN 4\n' S N . e\n' T & = .\ni - - Wt '}\\)/o ‘.' ¥ e .o o 2 :\n.\\ ' T’ b \"' ,{z\"{( ,' . .O\" ® ¢ * ; .. o.\no“ .' .. \" ° ‘ A ® » L » . 3\no .\n.\n","contentLength":315,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:14:22.347Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-qualified-vlei-issuer-authorization-vlei-credential-framework_v1.pdf","content":"verifiable LEI (vLEI) Ecosystem Governance Framework\nQuialified vLEl Issuer Authorization vLEI Credential Framework\ndid:keri:EINmHd5g7iV-UldkkkKyBIHO52blyxZNBn9pq-\nzNrYoS?service=vlei-documents&relativeRef=/egf/docs/2022-12-\n16_Legal-Entity-QVI-AUTH-vLEI-Credential-Governance-\nFramework v1.0 final.docx\n_ Global Legal Entity Identifier Foundation (GLEIF)\nThe verifiable LEI (vLEI) Ecosystem Governance Framework is published\non the GLEIF website. All documents published on the GLEIF website are\npublished under the Creative Commons Attribution license.\n1 Introduction\nThis is a Controlled Document of the verifiable LEI (vLEI) Ecosystem Governance Framework (vLElI\nEcosystem Governance Framework). It is the authoritative Governance Framework for the Qualified\nVLEI Issuer Authorization vLEI Credentials (QVI AUTH vLEI Credentials). There are two variants of this\nAUTH credential as defined by their schema. The first variant is the Qualified vLEI Issuer OOR\nAuthorization vLEI Credential (QVI OOR AUTH vLEI Credential). The second variant is the Qualified\nvLEI Issuer ECR Authorization vLEI Credential (QVI ECR AUTH vLEI Credential). This document\nspecifies the purpose, principles, policies, and specifications that apply to the use of these\nCredentials in the vLEI Ecosystem.\n2 Terminology\nAll terms in First Letter Capitals are defined in the vLEI Glossary.\n3 Purpose\nThe purpose of the QVI AUTH vLEI Credential is to enable simple, safe, secure instruction and\nauthorization by a Legal Entity Authorized Representative (LAR) sent to a QVI for the issuance and\nrevocation of vLEI Role Credentials.\n4 Scope\nThe scope of this Credential Governance Framework is limited to Legal Entities and QVIs for which\nLegal Entities have contracted for vLEI services.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 2 of 7\nQualified vLEI Issuer Authorization vLEI Credential Framework\nPublic Document Version 1.0\n2022-12-16_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2022-12-16\nGLEIF Qualified-vLEI-Issuer-Authorization-vLEI-Credential-\nFramework_v1.0_final\n","contentLength":2076,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:14:22.348Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-qualified-vlei-issuer-authorization-vlei-credential-framework_v1.pdf","content":"5 Principles\nThe following principles guide the development of policies in this Credential Governance Framework.\nNote that they apply in addition to the Core Policies defined in the vLEl Ecosystem Governance\nFramework.\n5.1 Binding to Holder\nThe QVI AUTH vLEI Credentials shall be designed to provide a strong binding between and the\nLegal Entity Authorized Representatives (LARs) so the Qualified vLEI Issuer Authorized\nRepresentatives (QARs) cannot act to issue or to revoke vLEI Role Credentials without\ninstructions and authorization from a LAR.\n5.2 Context Independence\nThe QVI AUTH vLEI Credentials shall be designed to fulfil a Proof Request for the authorization\nby a LAR regardless of context, including in-person, online, or over the phone.\n6 Issuer Policies\n6.1 Qualifications\n1. The Issuer MUST be a LAR of a Legal Entity that holds a valid Legal Entity vLEI Credential\nthat was issued by the QVI with which the Legal Entity has contracted to issue vLEI Role\nCredentials.\n6.2 Credential\nThe Issuer MUST:\n1. use the QVI AUTH vLEI Credential schema defined in sections 9.1 and 9.2 for authorizing\nthe associated OOR vLEl or ECR vLEI AUTH credentials respectively.\n2. include the Claims marked as Required in the schema indicated in 9.1 and 9.2.\n6.3 Identity Verification\nLARs will need to include the Autonomic Identifiers (AIDs) of Official Organizational Role\nPersons (OOR Persons) and Engagement Context Role Persons (ECR Persons) as an element\nwithin the QVI AUTH vLEI Credentials issued for each vLEI Role Credential.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 3 of 7\nQualified vLEI Issuer Authorization vLEI Credential Framework\nPublic Document Version 1.0\n2022-12-16_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2022-12-16\nGLEIF Qualified-vLEI-Issuer-Authorization-vLEI-Credential-\nFramework_v1.0_final\n","contentLength":1848,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:14:22.348Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-qualified-vlei-issuer-authorization-vlei-credential-framework_v1.pdf","content":"1. Identity Assurance\na. ALAR MUST perform identity assurance of an OOR Person or ECR Person\ndesignated by the Legal Entity to receive vLEI Role Credentials to at least Identity\nAssurance Level 2 (IAL2) as defined in NIST 800-63A (https://pages.nist.gov/800-\n63-3/sp800-63a.html). Even when IAL2 is used for Identity Assurance, a real-time\nOOBI session is required as specified in 2.b. below (essentially including the 1AL3\nrequirement for a Supervised Remote In-person session).\n2. Identity Authentication\na. Acredential wallet MUST be set up for the OOR Person or ECR Person.\nb. ALAR and the OOR Person or ECR Person MUST establish a real-time OOBI session\nin which the LAR and the OOR Person or ECR Person are present. An example is a\ncontinuous web meeting attended by all parties on both audio and video.\nc. The following steps MUST be performed in this order and completed during this\nOOBI session.\ni. The LAR MUST perform manual verification of the OOR Person’s or ECR\nPerson’s legal identity for which the LAR has already performed Identity\nAssurance. An example, the OOR Person or ECR Person visually presenting\none or more legal identity credentials and the LAR compares the\ncredentials verified during Identity Assurance to the OOR Person or ECR\nPerson.\nii. The LAR MUST use an OOBI protocol (such as a QR code or live chat) to\nshare its Autonomic Identifier (AID) with the OOR Person or ECR Person.\niii. The OOR Person or ECR Person MUST use an OOBI protocol (such as a QR\ncode or live chat) to share its AID with the LAR.\niv. The LAR MUST send a Challenge Message to the OOR Person’s or ECR\nPerson’s AID as defined in the Technical Requirements Part 1 for the\npurposes of cryptographic authentication of the OOR Person’s or ECR\nPerson’s AID. The Challenge Message MUST be unique to the OOBI\nsession.\nv. The OOR Person or ECR Person MUST use its Private Key Store to sign and\nreturn the response to the Challenge Message, after which the OOR\nPerson or ECR Person MUST acknowledge that this action has been\ncompleted.\nvi. The LAR MUST verify in real time that the response to the Challenge\nMessage was received from the OOR Person or ECR Person.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 4 of 7\nQualified vLEI Issuer Authorization vLEI Credential Framework\nPublic Document Version 1.0\n2022-12-16_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2022-12-16\nGLEIF Qualified-vLEI-Issuer-Authorization-vLEI-Credential-\nFramework_v1.0_final\n","contentLength":2473,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:14:22.348Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-qualified-vlei-issuer-authorization-vlei-credential-framework_v1.pdf","content":"vii. When the response to the Challenge Message has been received by the\nLAR, the LAR MUST verify the OOR Person’s or ECR Person’s signature.\n6.4 Issuance\n\n1. The LAR MUST include the OOR Person’s or ECR Person’s AID obtained during Identify\nVerification of the OOR Person or ECR Person, as well as the name and role of the OOR\nPerson and ECR Person, as elements within the appropriate QVI AUTH vLEI Credential for\nthe issuance of the associated vLEI Role Credential.\n\n2. A workflow MAY be implemented in the operations of a Legal Entity which requires two\nLARs to be involved in the issuance and signing of a QVI AUTH vLEI Credential. The first\nLAR would prepare the QVI AUTH vLEI Credential for the issuance of a vLEI Role Credential.\nAnother LAR then approves and signs the QVI AUTH vLEI Credential.\n\n3. ALAR MUST issue QVI AUTH vLEI Credential explicitly authorizing the QARs of a QVI to\nissue each vLEI Role Credential. The QVI AUTH vLEI Credential will become part of the\nchain of the vLEI Role Credentials.\n\n6.5 Revocation\n\n1. Torevoke a previously issued VLEI Role Credential, the LAR(s) MUST revoke the QVI AUTH\nvLEI Credential related to a specific issuance of a vLEI Role Credential.\n\n2. The QAR then MUST revoke the vLEI Role Credential.\n\n6.6 Level of Assurance\n\n1. The QVI AUTH vLEI Credential SHOULD be issued with only a single Level of Assurance.\nFuture versions of this credential governance framework MAY define multiple Levels of\nAssurance.\n\n6.7 Monitoring\n\n1. GLEIF MUST monitor the QVI Transaction Event Logs (TELs) to detect revocations of QVI\nAUTH vLEI Credentials by LARs. This will advise GLEIF in the case of a terminated QVI or\nQVI leaving the vLEI Ecosystem to follow up on revocation of any OOR vLEI Credentials.\n\n7 Holder Policies\nThere are no restrictions on the Holders of vLEI Credentials specified in the vLEI Ecosystem.\nRestrictions may be introduced in other Ecosystems that use the vLEI Ecosystem.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 5 of 7\nQualified vLEI Issuer Authorization vLEI Credential Framework\nPublic Document Version 1.0\n2022-12-16_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2022-12-16\nGLEIF Qualified-vLEI-Issuer-Authorization-vLEI-Credential-\nFramework_v1.0_final\n","contentLength":2251,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:14:22.348Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-qualified-vlei-issuer-authorization-vlei-credential-framework_v1.pdf","content":"8 Verifier Policies\nThere are no restrictions on the Verifiers of vLEI Credentials specified in the vLEl Ecosystem.\nRestrictions may be introduced in other Ecosystems that use the vLEI Ecosystem.\n9 Privacy Considerations\nPrivacy Considerations are applicable to QVI ECR AUTH vLEI Credentials. It is the sole responsibility\nof QVIs as Issuees of QVI ECR AUTH vLEI Credentials to present these Credentials in a privacy-\npreserving manner using the mechanisms provided in the Issuance and Presentation Exchange (IPEX)\nprotocol specification and the Authentic Chained Data Container (ACDC)\nspecification. https://github.com/WebOfTrust/IETF-IPEX and https://github.com/trustoverip/tswg-\nacdc-specification\n10 Credential Definition\n10.1 Schema QVI OOR AUTH vLEI Credential\n1. The QVI OOR AUTH vLEI Credential MUST be an Authentic Chained Data Container (ACDC)\nthat MUST use for its schema at the time of issuance, the JSON Schema found in:\nhttps://github.com/WebOfTrust/vLEI/blob/dev/schema/acdc/oor-authorization-vlei-\ncredential.json\n2. The field values in the credential MUST be as follows:\nThe \"AID\" field value MUST be the AID of OOR Person.\nThe \"LEI\" field value MUST be the LEI of Legal Entity Holder.\nThe \"personLegalName\" field value MUST be the Legal Name of the Person in the Official\nOrganizational Role at the Legal Entity.\nThe \"officialRole\" field value MUST be the the Official Organizational Role to be assigned in\nthe vLEI OOR Credential.\nThe elements in this type of credential can be returned in response to a presentation\nrequest as defined in the IPEX protocol (see below).\n10.2 Schema QVI ECR AUTH vLEI Credential\n1. The QVI ECR AUTH vLEI Credential MUST be an Authentic Chained Data Container (ACDC)\nthat MUST use for its schema at the time of issuance, the JSON Schema found in:\nhttps://github.com/WebOfTrust/vLEIl/blob/dev/schema/acdc/ecr-authorization-vlei-\ncredential.json\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 6 of 7\nQualified vLEI Issuer Authorization vLEI Credential Framework\nPublic Document Version 1.0\n2022-12-16_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2022-12-16\nGLEIF Qualified-vLEI-Issuer-Authorization-vLEI-Credential-\nFramework_v1.0_final\n","contentLength":2210,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:14:22.348Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-qualified-vlei-issuer-authorization-vlei-credential-framework_v1.pdf","content":"2. The field values in the credential must be as follows:\nThe \"AID\" field value MUST be the AID of ECR Person.\nThe \"LEI\" field value MUST be the LEI of Legal Entity Holder.\nThe \"personLegalName\" field value MUST be the Legal Name of the Person in the\nEngagement Context Role at the Legal Entity.\nThe \"engagementContextRole\" field value MUST be the the Engagement Context Role to\nbe assigned in the ECR vLEI Credential.\n\n3. The Sources section MUST contain a source reference to the Legal Entity vLEI Credential\n(via SAID) held by the Legal Entity issuer of this credential. The Issuer of the referenced\nLegal Entity vLEI Credential MUST be the target holder of this QVI ECR AUTH vLElI\nCredential.\n\nThe elements in this type of credential can be returned in response to a presentation\n\nrequest as defined in the IPEX protocol (see below).\n\nThe ACDC specification is covered in the ACDC protocol specification which can be found\n\nin: https://github.com/WebOfTrust/ietf-keri\n\nThe issuance and presentation exchange protocols are covered in the Issuance and\n\nPresentation Exchange (IPEX) protocol specification, which can be found in:\n\nhttps://github.com/WebOfTrust/IETF-IPEX\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 7 of 7\n\nQualified vLEI Issuer Authorization vLEI Credential Framework\n\nPublic Document Version 1.0\n\n2022-12-16_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2022-12-16\nGLEIF Qualified-vLEI-Issuer-Authorization-vLEI-Credential-\n\nFramework_v1.0_final\n","contentLength":1493,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:14:22.348Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-legal-entity-official-organizational-role-vlei-credential-govern.pdf","content":"@’ protecting digital rust\nverifiable LEI (vLEI)\nEcosystem Governance Framework v1.0\nLegal Entity Official Organizational Role\nVLEI Credential Framework\nPublic\nDocument Version 1.0\n2022-12-16\n@ | e Y\n@ - fiw;/ e 0 =z\n: 60 L L -\n\nb a3 Lo \".3.}:’ ‘.' ¥ o © .. . .' :\n. * . 3 r.,{zi{f’, . . B . .\n.‘~ ..A', \" ° ‘ A ® s o » (3 5\n\no B\n-\n","contentLength":331,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:14:46.948Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-legal-entity-official-organizational-role-vlei-credential-govern.pdf","content":"verifiable LEI (vLEI) Ecosystem Governance Framework\nLegal Entity Official Organizational Role vLEI Credential Framework\ndid:keri:EINmHd5g7iV-UldkkkKyBIHO52blyxZNBn9pq-\nzNrYoS?service=vlei-documents&relativeRef=/egf/docs/2022-12-\n16_Legal-Entity-Official-Organizational-Role-vLEI-Credential-Governance-\nFramework_v1.0_final.docx\n_ Global Legal Entity Identifier Foundation (GLEIF)\nThe verifiable LEI (vLEI) Ecosystem Governance Framework is published\non the GLEIF website. All documents published on the GLEIF website are\npublished under the Creative Commons Attribution license.\n1 Introduction\nThis is a Controlled Document of the verifiable LEI (vLEl) Ecosystem Governance Framework (VLEI\nEcosystem Governance Framework). It is the authoritative Governance Framework for the Legal\nEntity Official Organizational Role vLEI Credential (OOR vLEI Credential). It specifies the purpose,\nprinciples, policies, and specifications that apply to the use of this Credential in the vLEI Ecosystem.\n2 Terminology\nAll terms in First Letter Capitals are defined in the vLEI Glossary.\n3 Purpose\nThe purpose of the OOR vLEI Credential is to enable the simple, safe, secure identification of an OOR\nvLEI Credential Holder to any Verifier that accepts a OOR vLEI Credential.\n4 Scope\nThe scope of this Credential Governance Framework is limited to Issuers, Holders, and Verifiers of\nOOR VLEI Credentials.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 2 of 7\nLegal Entity Official Organizational Role vLEI Credential\nFramework\nPublic Document Version 1.0\n2022-12-16_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2022-12-16\nGLEIF Legal-Entity-Official-Organizational-Role-vLEI-Credential-\nFramework_v1.0_final\n","contentLength":1716,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:14:46.948Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-legal-entity-official-organizational-role-vlei-credential-govern.pdf","content":"5 Principles\nThe following principles guide the development of policies in this Credential Governance Framework.\nNote that they apply in addition to the Core Policies defined in the vLEl Ecosystem Governance\nFramework.\n5.1 Binding to Holder\nThe OOR vLEI Credential shall be designed to provide a strong binding to the OOR vLEI\nCredential Holder that a Proof Request for the OOR vLEI Credential can be satisfied by the\nLegal Entity, the OOR vLEI Credential Holder, and/or against one or more public sources.\n5.2 Context Independence\nThe OOR vLEI Credential shall be designed to fulfil a Proof Request for the legal identity of the\nOOR vLEI Credential Holder regardless of context, including in-person, online, or over the\nphone.\n6 Issuer Policies\n6.1 Qualifications\nThe Issuer MUST:\n1. be a Qualified vLEI Issuer (QVI) that has been contracted by a Legal Entity holding a valid\nLegal Entity vLEI Credential to issue OOR vLEI Credentials.\n6.2 Credential\nThe Issuer MUST:\n1. use the OOR vLEI Credential schema defined in section 9.1.\n2. include the Claims marked as Required in section 9.1.\n6.3 Legal Entity Identity Verification\n1. Identity Assurance\na. A QVIAuthorized Representative (QAR) MUST verify that the LEI supplied for the\nCredential is the LEI of the Legal Entity for which the issuance request for the\nCredential has been made.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 3 of 7\nLegal Entity Official Organizational Role vLEI Credential\nFramework\nPublic Document Version 1.0\n2022-12-16_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2022-12-16\nGLEIF Legal-Entity-Official-Organizational-Role-vLEI-Credential-\nFramework_v1.0_final\n","contentLength":1666,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:14:46.948Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-legal-entity-official-organizational-role-vlei-credential-govern.pdf","content":"b. A QAR MUST verify the Legal Entity Identifier (LEIl) of the Legal Entity has a LEI\nEntity Status of Active and a LEI Registration Status of Issued, Pending Transfer or\nPending Archival in the Global LEI System.\n\n2. ldentity Authentication\n\na. ldentity Authentication for the Legal Entity is not applicable for the issuance of an\nOOR VLEI Credential.\n\n6.4 Legal Entity Authorized Representative (LAR) Identity\n\nVerification\n\nIdentity Assurance and Identity Authentication for the LARs are specified in section 6.3 of the\n\nLegal Entity vLEI Credential Governance Framework.\n\n6.5 OOR Person Identity Verification\n\n1. Identity Assurance\n\n2. Identity Assurance of a person serving in an Official Organizational Role (OOR Person) MAY\nbe performed either by a QAR, directly or through the use of Third-Party Services, or by a\nLAR.\n\n3. When the Identity Assurance is performed by a QAR, the Identity Assurance MUST be in\nthe same Supervised Remote In-person session as the Identity Authentication by the QAR.\n\n4. ldentity Assurance of an OOR person MUST be performed to at least Identity Assurance\nLevel 2 (IAL2) as defined in NIST 800-63A (https://pages.nist.gov/800-63-3/sp800-\n63a.html). Even when IAL2 is used for Identity Assurance, a real-time OOBI session is\nrequired as specified 6.d below (essentially including the IAL3 requirement for a\nSupervised Remote In-person session).\n\n5. If Identity Assurance and Identity Authentication to generate the AID of the OOR Person is\nperformed by the LAR, then Identity Assurance and Identity Authentication can be\nperformed by a separate Supervised Remote In-person session.\n\n6. Identity Authentication by a QAR\n\na. A QAR MUST validate the name and the Official Organizational Role of an OOR\nPerson using one or more official public sources.\n\nb. If the name and the Official Organizational Role of the OOR Person cannot be\nvalidated using one or more official public sources, the QAR MUST request from\nthe LAR(s) copies of documents of the Legal Entity, such as Board minutes or\nresolutions, statutes or articles, which would validate the name and the role of the\nOOR Person.\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 4 of 7\n\nLegal Entity Official Organizational Role vLEI Credential\n\nFramework\n\nPublic Document Version 1.0\n\n2022-12-16_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2022-12-16\nGLEIF Legal-Entity-Official-Organizational-Role-vLEI-Credential-\n\nFramework_v1.0_final\n","contentLength":2453,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:14:46.948Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-legal-entity-official-organizational-role-vlei-credential-govern.pdf","content":"c. The QAR MUST call the GLEIF API to look up the OOR code for the OOR Person role\nprovided by the Legal Entity to be used in the OOR vLEI Credential (when the lists\nof OOR codes and reference data are accessible using the API). In the interim, a\ntext string will be used for the OOR in the OOR vLEI Credential.\n\nd. Inall cases, a QAR and the OOR Person MUST establish a real-time OOBI session in\nwhich the QAR and the OOR Person are present. An example is a continuous web\nmeeting attended by all parties on both audio and video.\n\ne. The following steps MUST be performed in this order and completed during this\nOOBI session.\n\ni. The QAR MUST send a Challenge Message to the OOR Person’s AID as\ndefined in the Technical Requirements Part 1 for the purposes of\ncryptographic authentication of the OOR Person’s AID. The Challenge\nMessage MUST be unique to the OOBI session.\n\nii. The OOR Person MUST use its Private Key Store to sign and return the\nresponse to the Challenge Message, after which the OOR Person MUST\nacknowledge that this action has been completed.\n\niii. The QAR MUST verify in real time that the response to the Challenge\nMessage was received from the OOR Person.\n\niv. When the response to the Challenge Message has been received by the\nQAR, the QAR MUST verify the OOR Person’s signature.\n\n6.6 Issuance\n\n1. The Legal Entity and OOR Person Identity Verification process outlined in sections 6.3 and\n6.5 MUST be completed before OOR vLEI Credential issuance can begin.\n\n2. The LAR(s) MUST issue a QVI AUTH OOR vLEI Credential to a QVI to request issuance of a\nOOR VLEI Credential.\n\n3. A workflow MUST be implemented in the operations of the QVI which requires two QARs\nto be involved in the issuance and signing an OOR vLEI Credential. The first QAR will\nperform the required above-mentioned Identity Authentication and out-of-band\nvalidations and then signs the credential. Another QAR then approves the issuance and\nsigns the OOR vLEI Credential.\n\n4. A QAR MUST call the vLEI Reporting API for each issuance event of OOR vLEI Credentials.\n\n5. GLEIF MUST update the list of vLEI Credentials on the LEI page of the Legal Entity to reflect\nOOR VLEI credential issuances that have been reported by QVIs.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 5 of 7\n\nLegal Entity Official Organizational Role vLEI Credential\n\nFramework\n\nPublic Document Version 1.0\n\n2022-12-16_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2022-12-16\nGLEIF Legal-Entity-Official-Organizational-Role-vLEI-Credential-\n\nFramework_v1.0_final\n","contentLength":2549,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:14:46.948Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-legal-entity-official-organizational-role-vlei-credential-govern.pdf","content":"6.7 Revocation\n1. To revoke an OOR vLEI Credential:\n\na. The Legal Entity MUST notify the QVI to revoke an OOR vLEI Credential.\n\nb. To revoke a previously issued OOR vLEI Credential, the LAR(s) MUST revoke the\nQVI AUTH OOR VLEI Credential related to a specific issuance of an OOR VLEI\nCredential.\n\nc. The QAR then MUST revoke the OOR vLEI Credential.\n\nd. A QAR MUST perform the revocation within the timeframe specified in Appendix 5\nService Level Agreement (SLA).\n\n2. A QAR MUST call the vLEI Reporting API for each revocation event of OOR vLEI Credentials.\n3. If the QVI has been terminated:\n\na. Atthe end of the Grace Period for the Qualified vLEI Issuer vLEI Credential that has\nbeen revoked by GLEIF, the QVI MUST revoke all of the OOR vLEI Credentials that\nthe QVI has issued.\n\nb. Then, the terminated QVI MUST transfer a copy of its revocation log to\nGLEIF.\n\n4. GLEIF MUST update the list of vLEI Credentials on the LEI page of the Legal Entity to reflect\nOOR VLEI Credential revocations that have been reported by QVis.\n6.8 Level of Assurance\nThe OOR vLEI Credential SHOULD be issued with only a single Level of Assurance. Future\nversions of this credential governance framework MAY define multiple Levels of Assurance.\n6.9 Monitoring\n1. GLEIF MUST monitor the QVI Transaction Event Logs (TELs) to detect the issuance or\nrevocation of OOR vLEI Credentials which were not reported using the vLEI Reporting API.\n7 Holder Policies\nThere are no restrictions on the Holders of vLEI Credentials specified in the vLEI Ecosystem.\nRestrictions may be introduced in other Ecosystems that use the vLEI Ecosystem.\n8 Verifier Policies\nThere are no restrictions on the Verifiers of vLEI Credentials specified in the vLEI Ecosystem.\nRestrictions may be introduced in other Ecosystems that use the vLEI Ecosystem.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 6 of 7\nLegal Entity Official Organizational Role vLEI Credential\nFramework\nPublic Document Version 1.0\n2022-12-16_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2022-12-16\nGLEIF Legal-Entity-Official-Organizational-Role-vLEI-Credential-\nFramework_v1.0_final\n","contentLength":2133,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:14:46.949Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-legal-entity-official-organizational-role-vlei-credential-govern.pdf","content":"9 Credential Definition\n9.1 Schema\n1. The OOR vLEI Credential MUST be an Authentic Chained Data Container (ACDC) that MUST\nuse for its schema at the time of issuance, the JSON Schema found in:\nhttps://github.com/WebOfTrust/vLEIl/blob/dev/schema/acdc/legal-entity-official-\norganizational-role-vLEI-credential.json\n2. The field values in the credential MUST be as follows:\nThe \"LEI\" field value MUST be the LEI of Legal Entity Holder.\nThe \"personLegalName\" field value MUST be the Legal Name of the Person in the Official\nRole at the Legal Entity.\nThe \"officialRole\" field value MUST be the the Official Organizational Role.\nAdditional data elements can be specified about the OOR Person through issuance of\nanother ACDC credential containing these additional elements by using the chaining\ncapabilities of ACDC credentials to chain this additional ACDC credential to the Legal Entity\nOfficial Organizational Role vLEI Credential.\n\n1. The Sources section of the OOR vLEI Credential MUST contain a source reference to the\nQVI AUTH VvLEI Credential (via SAID) that the issuing QVI received authorizing the issuance\nof this OOR vLEI Credential. The Sources section of that QVI AUTH vLEI Credential MUST\ncontain a source reference to the Legal Entity vLEI Credential that was issued by the QVI to\nthe Legal Entity and contain the same value for the “LEI” field as the Legal Entity VvLEI\nCredential.\n\nThe elements in this type of credential can be returned in response to a presentation request\n\nas defined in the IPEX protocol (see below).\n\nThe ACDC specification is covered in the ACDC protocol specification which can be found in:\n\nhttps://github.com/WebOfTrust/ietf-keri\n\nThe issuance and presentation exchange protocols are covered in the Issuance and\n\nPresentation Exchange (IPEX) protocol specification, which can be found in:\n\nhttps://github.com/WebOfTrust/IETF-IPEX\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 7 of 7\n\nLegal Entity Official Organizational Role vLEI Credential\n\nFramework\n\nPublic Document Version 1.0\n\n2022-12-16_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2022-12-16\nGLEIF Legal-Entity-Official-Organizational-Role-vLEI-Credential-\n\nFramework_v1.0_final\n","contentLength":2202,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:14:46.949Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-legal-entity-engagement-context-role-vlei-credential-framework_v.pdf","content":"OGLEIF’ protecting digital rust\nverifiable LEI (vLEl)\nEcosystem Governance Framework v1.0\nLegal Entity Engagement Context Role\nVLEI Credential Framework\nDocumel:\\l:k\\)lltiacrsion 1.0\n2022-12-16\n< l 2 d- ‘ . ‘\n“4\nf . o\n. O - _J' o O —_—\n60 Lp \" , VKD N . .\n\nT . '\\/o - 4\" o : . “\" o\n» . Tu. \"-;, {i‘(f , . ..\" ¥ \"o ° '.. . . o.\nob‘ .' .. \" 5‘ A ® » L » . 3\n\nA, B\n.\n","contentLength":364,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:15:15.044Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-legal-entity-engagement-context-role-vlei-credential-framework_v.pdf","content":"verifiable LEI (vLEI) Ecosystem Governance Framework\nLegal Entity Engagement Context Role vLEI Credential Framework\ndid:keri:EINmHd5g7iV-UldkkkKyBIHO52blyxZNBn9pq-\nzNrYoS?service=vlei-documents&relativeRef=/egf/docs/2022-12-\n16_Legal-Entity-Engagement-Context-Role-vLEI-Credential-Governance-\nFramework_v1.0_final.docx\n_ Global Legal Entity Identifier Foundation (GLEIF)\nThe verifiable LEI (vLEI) Ecosystem Governance Framework is published\non the GLEIF website. All documents published on the GLEIF website. All\ndocuments published on the GLEIF website are published under the\nCreative Commons Attribution license.\n1 Introduction\nThis is a Controlled Document of the verifiable LEI (vLEI) Ecosystem Governance Framework (VLEI\nEcosystem Governance Framework). It is the authoritative Governance Framework for the Legal\nEntity Engagement Context Role vLEI Credential (ECR vLEI Credential). It specifies the purpose,\nprinciples, policies, and specifications that apply to the use of this Credential in the vLEI Ecosystem.\n2 Terminology\nAll terms in First Letter Capitals are defined in the vLEI Glossary.\n3 Purpose\nThe purpose of the ECR vLEI Credential is to enable the simple, safe, secure identification of an ECR\nvLEI Credential Holder to any Verifier that accepts an ECR vLEI Credential.\n4 Scope\nThe scope of this Credential Governance Framework is limited to Issuers, Holders, and Verifiers of the\nECR vLEI Credential.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 2 of 9\nLegal Entity Engagement Context Role VLEI Credential\nFramework\nPublic Document Version 1.0\n2022-12-16_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2022-12-16\nGLEIF Legal-Entity-Engagement-Context-Role-vLEI-Credential-\nFramework_v1.0_final\n","contentLength":1741,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:15:15.045Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-legal-entity-engagement-context-role-vlei-credential-framework_v.pdf","content":"5 Principles\nThe following principles guide the development of policies in this Credential Governance Framework.\nNote that they apply in addition to the Core Policies defined in the vLEI Ecosystem Governance\nFramework.\n5.1 Binding to Holder\nThe ECR vLEI Credential shall be designed to provide a strong enough binding to the ECR VLEI\nCredential Holder that a Proof Request for the ECR vLEI Credential can be satisfied only by the\nLegal Entity vLEI Credential or the ECR Person.\n5.2 Context Independence\nThe ECR vLEI Credential shall be designed to fulfil a Proof Request for the legal identity of the\nECR Person regardless of context, including in-person, online, or over the phone.\n6 Issuer Policies\n6.1 Qualifications\nThe Issuer MUST:\n\n1. bea QVI with which a Legal Entity holding a valid Legal Entity vLEI Credential has\ncontracted with for the issuance of ECR vLEI Credentials, offered by QVIs as a value-\nadded service.\n\n2. be a Legal Entity holding a valid Legal Entity vLEI Credential who will issue ECR vLEI\nCredentials directly to ECR Persons.\n\n6.2 Credential\nThe Issuer MUST:\n1. use the ECR vLEl Credential schema elements defined in section 10.1.\n2. include the Claims marked as Required in section 10.1.\n6.3 Legal Entity Identity Verification\nFor an Issuerin 6.1.1:\n1. Identity Assurance\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 3 of 9\nLegal Entity Engagement Context Role VLEI Credential\nFramework\nPublic Document Version 1.0\n2022-12-16_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2022-12-16\nGLEIF Legal-Entity-Engagement-Context-Role-vLEI-Credential-\nFramework_v1.0_final\n","contentLength":1618,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:15:15.045Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-legal-entity-engagement-context-role-vlei-credential-framework_v.pdf","content":"a. AQualified vLEI Issuer Authorized Representative (QAR) MUST verify that the LEI\nsupplied for the Credential is the LEI of the Legal Entity for which the issuance\nrequest for the Credential has been made.\n\nb. A QAR MUST verify the Legal Entity Identifier (LEI) of the Legal Entity has a LEI\nEntity Status of Active and a LEI Registration Status of Issued, Pending Transfer or\nPending Archival in the Global LEI System.\n\n2. Identity Authentication\n\na. ldentity Authentication for the Legal Entity is not applicable for the issuance of an\n\nECR vLEI Credential.\nFor an Issuerin 6.1.2:\n\n1. ldentity Assurance for the Legal Entity is not applicable for the issuance of an ECR\nVLEI Credential.\n\n2. ldentity Authentication for the Legal Entity is not applicable for the issuance of an\nECR vLEI Credential.\n\n6.4 Legal Entity Authorized Representative (LAR) Identity\nVerification\nFor an Issuerin 6.1.1:\nIdentity Assurance and ldentity Authentication for the LAR are specified section 6.3 of the\nLegal Entity vLEI Credential Governance Framework.\nFor an Issuerin 6.1.2:\n1. The LARs of the Legal Entity MUST act as the Issuer of ECR vLEI Credentials when these\ncredentials are issued directly by a Legal Entity.\n6.5 ECR Person Identity Verification\nFor an Issuerin 6.1.1:\n1. Identity Assurance\n\na. ldentity Assurance of a person serving in an Engagement Context Role (ECR\nPerson) MAY be performed either by a QAR, directly or using Third-Party Services,\nor by a LAR.\n\nb. When the Identity Assurance is performed by a QAR, the Identity Assurance MUST\nbe in the same Supervised Remote In-person session as the Identity\nAuthentication by the QAR.\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 4 of 9\n\nLegal Entity Engagement Context Role VLEI Credential\n\nFramework\n\nPublic Document Version 1.0\n\n2022-12-16_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2022-12-16\nGLEIF Legal-Entity-Engagement-Context-Role-vLEI-Credential-\n\nFramework_v1.0_final\n","contentLength":1959,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:15:15.045Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-legal-entity-engagement-context-role-vlei-credential-framework_v.pdf","content":"c. ldentity Assurance of an ECR person MUST be performed to at least Identity\nAssurance Level 2 (IAL2) as defined in NIST 800-63A (https://pages.nist.gov/800-\n63-3/sp800-63a.html). Even when IAL2 is used for Identity Assurance, a real-time\nOOBI session is required as specified 2.b.i below (essentially including the IAL3\nrequirement for a Supervised Remote In-person session).\n\nd. If Identity Assurance and Identity Authentication to generate the AID of the ECR\nPerson is performed by the LAR, then Identity Assurance and Identity\nAuthentication MAY be performed by a separate Supervised Remote In-person\nsession.\n\n2. Identity Authentication by a QAR\n\na. Acredential wallet MUST be set up for the ECR Person.\n\nb. Inall cases, a QAR and the ECR Person MUST establish a real-time OOBI session in\nwhich the QAR and the ECR Person are present. An example is a continuous web\nmeeting attended by all parties on both audio and video.\n\nc. The following steps MUST be performed in this order and completed during this\nOOBI session.\n\ni. The QAR MUST send a Challenge Message to the ECR Person’s AID as\ndefined in the Technical Requirements Part 1 for the purposes of\ncryptographic authentication of the ECR Person’s AID. The Challenge\nMessage MUST be unique to the OOBI session.\n\nii. The ECR Person MUST use its Private Key Store to sign and return a\nresponse to the Challenge Message, after which the ECR Person MUST\nacknowledge that this action has been completed.\n\niii. The QAR MUST verify in real time that the response to the Challenge\nMessage was received from the ECR Person.\n\niv. When the response to the Challenge Message has been received by the\nQAR, the QAR MUST verify the ECR Person’s signature.\n\nFor an Issuerin 6.1.2:\n1. Identity Assurance\n\na. A LAR MUST perform identity assurance of a person serving in an Engagement\nContext Role (ECR Person) to at least Identity Assurance Level 2 (I1AL2) as defined\nin NIST 800-63A (https://pages.nist.gov/800-63-3/sp800-63a.html). Even when\nIAL2 is used for Identity Assurance, a real-time OOBI session is required as\nspecified 2.b below (essentially including the IAL3 requirement for a Supervised\nRemote In-person session).\n\n2. ldentity Authentication\na. Acredential wallet MUST be set up for the ECR Person.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 5 of 9\nLegal Entity Engagement Context Role VLEI Credential\nFramework\nPublic Document Version 1.0\n2022-12-16_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2022-12-16\nGLEIF Legal-Entity-Engagement-Context-Role-vLEI-Credential-\nFramework_v1.0_final\n","contentLength":2574,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:15:15.045Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-legal-entity-engagement-context-role-vlei-credential-framework_v.pdf","content":"b. ALAR and the ECR Person MUST meet in person or establish a real-time OOBI\nsession in which the QAR and the ECR Person are present. An example is a\ncontinuous web meeting attended by all parties on both audio and video.\n\nc. The following steps MUST be performed in this order and completed during this\nOOBI session.\n\ni. The LAR MUST perform manual verification of the ECR Person’s legal\nidentity for which the QVI has already performed Identity Assurance. An\nexample, the ECR Person visually presenting one or more legal identity\ncredentials and the LAR compares the credentials verified during ldentity\nAssurance to the ECR Person.\n\nii. The LAR MUST use an OOBI protocol (such as a QR code or live chat) to\nshare the QVI Autonomic Identifier (AID) with the LARs.\n\niii. The ECR Person MUST use an OOBI protocol (such as a QR code or live\nchat) to share its AID with the LAR.\n\niv. The LAR MUST send a Challenge Message to the ECR Person’s AID as\ndefined in the Technical Requirements Part 1 for the purposes of\ncryptographic authentication of the ECR Person’s AID. The Challenge\nMessage MUST be unique to the OOBI session.\n\nv. The ECR Person MUST use its Private Key Store to sign and return a\nresponse to the Challenge Message, after which the ECR Person MUST\nacknowledge that this action has been completed.\n\nvi. The LAR MUST verify in real time that the response to the Challenge\nMessage was received from the ECR Person.\n\nvii. When the response to the Challenge Message has been received by the\nLAR, the LAR MUST verify the ECR Person’s signature.\n6.6 Issuance\n\nFor an Issuerin 6.1.1:\n\n1. The Legal Entity and ECR Person Identity Verification process outlined in sections 6.3 and\n6.5 MUST be completed before ECR vLEI Credential issuance can begin.\n\n2. The LAR(s) MUST issue a QVI AUTH ECR vLEI Credential to a QVI to request issuance of a\nECR vLEIl Credential.\n\n3. A workflow MUST be implemented in the operations of the QVI which requires two QARs\nto be involved in the issuance and signing an ECR vLEI Credential. The first QAR will\nperform the required above-mentioned Identity Authentication and out-of-band\nvalidations and then signs the credential. Another QAR then approves the issuance and\nsigns the ECR vLEI Credential.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 6 of 9\n\nLegal Entity Engagement Context Role VLEI Credential\n\nFramework\n\nPublic Document Version 1.0\n\n2022-12-16_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2022-12-16\nGLEIF Legal-Entity-Engagement-Context-Role-vLEI|-Credential-\n\nFramework_v1.0_final\n","contentLength":2559,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:15:15.045Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-legal-entity-engagement-context-role-vlei-credential-framework_v.pdf","content":"For an Issuerin 6.1.2:\n\n1. The ECR Person Identity Verification process outlined in section 6.5 MUST be completed\nbefore ECR vLEI Credential issuance can begin.\n\n2. A workflow MUST be put in place by the Legal Entity for ECR vLEI Role Credentials to meet\nthe requirement for two LARs to sign the ECR vLEI Role Credentials at issuance.\n\n6.7 Revocation\n\nFor an Issuerin 6.1.1:\n\n1. The Legal Entity MUST notify the QVI to revoke an ECR vLEI Credential.\n\n2. Torevoke a previously issued ECR vLEI Credential, the LAR(s) MUST revoke the QVI AUTH\nECR vLEI Credential related to a specific issuance of an ECR vLEI Credential.\n\n3. The QAR then MUST revoke the ECR vLEI Credential.\n\n4. The QAR MUST perform the revocation within the timeframe specified in the agreement\nthat has delegated the issuance of ECR vLEI Credentials to one or more QVIs, offered by\nQVIs as a value-added service.\n\n5. At the end of the Grace Period for the Qualified vLEI Issuer vLEI Credential that has been\nrevoked by GLEIF, the QVI MUST revoke all of the ECR vLEI Credentials that the QVI has\nissued.\n\n6. Then the terminated QVI MUST transfer a copy of its revocation log to GLEIF.\n\nFor an Issuerin 6.1.2:\n\nThe Legal Entity SHOULD put in place its own processes specifying how LARs are to be notified\n\nwhen ECR vLEI Credentials should be revoked and the timeframe in which the ECR vLElI\n\nCredentials are to be revoked.\n\n6.8 Level of Assurance\nThe ECR vLEI Credential SHOULD be issued with only a single Level of Assurance. Future\nversions of this credential governance framework MAY define multiple Levels of Assurance.\n7 Holder Policies\n7.1 Restrictions\nThere are no restrictions on the Holders of vLEI Credentials specified in the vLEI Ecosystem.\nRestrictions may be introduced in other Ecosystems that use the vLEI Ecosystem.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 7 of 9\nLegal Entity Engagement Context Role VLEI Credential\nFramework\nPublic Document Version 1.0\n2022-12-16_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2022-12-16\nGLEIF Legal-Entity-Engagement-Context-Role-vLEI-Credential-\nFramework_v1.0_final\n","contentLength":2115,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:15:15.045Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-legal-entity-engagement-context-role-vlei-credential-framework_v.pdf","content":"7.2 Privacy Considerations\n\nIt is the sole responsibility of Holders as Issuees of an ECR vLEI Credential to present that Credential\nin a privacy-preserving manner using the mechanisms provided in the Issuance and Presentation\nExchange (IPEX) protocol specification and the Authentic Chained Data Container (ACDC)\nspecification. https://github.com/WebOfTrust/IETF-IPEX and https://github.com/trustoverip/tswg-\nacdc-specification\n\n8 Verifier Policies\n\nThere are no restrictions on the Verifiers of vLEI Credentials specified in the vLEl Ecosystem.\nRestrictions may be introduced in other Ecosystems that use the vLEI Ecosystem.\n\n9 Credential Definition\n\n9.1 Schema\n\n1. The ECR vLEl Credential MUST be an Authentic Chained Data Container (ACDC) that MUST\nuse for its schema at the time of issuance, the JSON Schema found in:\n\nhttps://github.com/WebOfTrust/vLEl/blob/dev/schema/acdc/legal-entity-engagement-\ncontext-role-vLEl-credential.json\n\n2. The field values in the credential must be as follows:\n\nThe \"LEI\" field value MUST be the LEI of Legal Entity Holder.\n\nThe \"personLegalName\" field value MUST be the Legal Name of the Person in the\nEngagement Context Role at the Legal Entity.\n\nThe \"engagementContextRole\" field value MUST be the the Engagement Context Role.\nAdditional data elements can be specified about the ECR Person through issuance of another\nACDC credential containing these additional elements by using the chaining capabilities of\nACDC credentials to chain this additional ACDC credential to the Legal Entity Engagement\nContext vLEI Credential.\n\n3. Foranlssuerin 6.1.1, the Sources section of the ECR vLEI Credential MUST contain a source\nreference to the QVI AUTH vLEI Credential (via SAID) that the issuing QVI received\nauthorizing the issuance of this ECR vLEI Credential. The Sources section of that QVI AUTH\nvLEI Credential MUST contain a source reference to the Legal Entity vLEI Credential that was\nissued by the QVI to the Legal Entity and contain the same value for the “LEI” field as the\nLegal Entity vLEI Credential.\n\n4. ForanlIssuerin 6.1.2, the Sources section of the ECR vLEI Credential MUST contain a source\nreference to the Legal Entity vLEI Credential (via SAID) held by the Legal Entity that is issuing\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 8 of 9\n\nLegal Entity Engagement Context Role VLEI Credential\n\nFramework\n\nPublic Document Version 1.0\n\n2022-12-16_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2022-12-16\nGLEIF Legal-Entity-Engagement-Context-Role-vLEI-Credential-\n\nFramework_v1.0_final\n","contentLength":2563,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:15:15.045Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-legal-entity-engagement-context-role-vlei-credential-framework_v.pdf","content":"this ECR vLEI Credential. The value of the “LEI” field of the Legal Entity vLEI Credential MUST\nmatch the value of the “LEI” field in this ECR vLEI Credential.\nThe elements in this type of credential can be returned in response to a presentation request\nin a manner that provides for graduated disclosure and contractually protected disclosure as\ndefined in the IPEX protocol (see below).\nThe ACDC specification is covered in the ACDC protocol specification which can be found in:\nhttps://github.com/WebOfTrust/ietf-keri\nThe issuance and presentation exchange protocols are covered in the Issuance and\nPresentation Exchange (IPEX) protocol specification, which can be found in:\nhttps://github.com/WebOfTrust/IETF-IPEX\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 9 of 9\nLegal Entity Engagement Context Role VLEI Credential\nFramework\nPublic Document Version 1.0\n2022-12-16_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2022-12-16\nGLEIF Legal-Entity-Engagement-Context-Role-vLEI|-Credential-\nFramework_v1.0_final\n","contentLength":1037,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:15:15.045Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-glossary_v1.1_final.pdf","content":":GLEIF’ Protecing dgat st\nverifiable LEI (vLEI)\nEcosystem Governance Framework v1.0\nGlossary\nPublic\nDocument Version 1.1\n2023-04-03\nS e A\no - ” AN 4\n' S N . e\n' Ny . TF . .\n\nb 23 - \".‘-‘.}:/. ‘.' ¥ i .o ® < :\n:firfez“\"\":} v\no“ .' .. \" ° ‘ A ® » L » . 3\n\n-~ '\n","contentLength":258,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:15:49.925Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-glossary_v1.1_final.pdf","content":"_ verifiable LEI (vLEI) Ecosystem Governance Framework Glossary\ndid:keri:EINmHd5g7iV-UldkkkKyBIHO52blyxZNBn9pq-\nzNrYoS?service=vlei-documents&relativeRef=/egf/docs/2023-04-\n03_verifiable-LEI-(VLEI)-Ecosystem-Governance-Framework-\nGlossary v1.1 Final.docx\n\n_ Global Legal Entity Identifier Foundation (GLEIF)\n\nThe verifiable LEI (vLEI) Ecosystem Governance Framework is published\non the GLEIF website. All documents published on the GLEIF website are\npublished under the Creative Commons Attribution license.\n\n1 Introduction\n\nThis is a Controlled Document of the verifiable LEI (VLEI) Ecosystem Governance Framework (VLEI\n\nEcosystem Governance Framework). It is the Glossary for the vLEI Ecosystem Governance Framework.\n\n2 Glossary Terms and Definitions\n\nAll terms in First Letter Capitals in the (vLEI) Ecosystem Governance Framework Primary Document and\n\nControlled Documents are defined in the vLEI Ecosystem Governance Framework Glossary. Additional\n\nterms will continue to be added.\n\nA LEI Entity status in the Global LEI System.\nA formal annual evaluation process performed by GLEIF to ensure that the\nQuialified vLEI Issuer continues to meet the requirements of the vLElI\nEcosystem Governance Framework.\nAn audit report provided to the Qualified VLEI Issuer by its internal or\nexternal auditors or comparable function.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 2 of 13\nGlossary\nPublic Document Version 1.1\n2023-04-03_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2023-04-03\nGLEIF Glossary_v1.1_Final\n","contentLength":1535,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:15:49.925Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-glossary_v1.1_final.pdf","content":"Non-Transferable AlDs Non-transferable AlIDs are self-certifying but are not meant for long term\npersistent use and hence their key-pair(s) are not rotatable. Instead, the\nidentifier is abandoned and replaced with a new identifier with a new set of\nkey-pair(s). These may also be called ephemeral AlDs. Within KERI, the\nprimary use for non-transferable (ephemeral) AlDs are for the Witness\nidentifiers. Because Witnesses are used in a pool, the pool forms a threshold\nstructure which provides protection from the exploit of a minority of the key-\npairs of the ephemeral Witness AlIDs in the pool. If a given Witness AID has its\nkey(s) compromised, then the Witness AID itself is abandoned and replaced.\nThus, the Witness pool management policy protects Witness ephemeral\nAlDs.\n\nProof Request One of the initiating steps in the Issuance and Presentation Exchange\nProtocol (IPEX). In this step, a Verifier is requesting a credential presentation\nfrom a holder of a credential as proof that the holder is in possession of a\ncredential that meets criterial defined in the proof request.\n\nDistributed Ledger Technology (DLT) can be used to store Key Events.\n\nResolver An entity or component that provides discovery for identifiers. A Resolver is\nthe Controller of its own self-referential identifier which may not be the same\nas the identifier to which it is a Resolver.\n\nSeal . . . L\nA cryptographic commitment in the form of a cryptographic digest or hash\ntree root (Merkle root) that anchors arbitrary data or a tree of hashes of\n\n-\n\nSignature Verification An attack against signature verification infrastructure typically requires\n\nInfrastructure replacing the signature verification code with malicious code that falsely\nreports signature verification on signed statements. KERI provides a specific\nprotection mechanism for signature verification via a Watcher pool where an\nevent is only accepted as verified if a sufficient majority of the Watchersin a\npool agree on the verification status of the signature(s) on that event. This\nprovides a threshold structure where an attacker must compromise the code\nintegrity of a sufficient number of Watchers for successful attack. Because\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 11 of 13\n\nGlossary\n\nPublic Document Version 1.1\n\n2023-04-03_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2023-04-03\nGLEIF Glossary_v1.1_Final\n","contentLength":2398,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:15:49.925Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-glossary_v1.1_final.pdf","content":"the composition of a Watcher pool does not need to be publicly disclosed, an\nattacker must also discover that composition to ensure a successful attack.\n\nSources The sources or edges section of a vLEI credential cause the vLEI credential to\nbecome a fragment of a distributed property graph. The sources chain a vLEI\ncredential to other vLEI credential to which this credential is dependent.\n\nSpot Check The operation of performing an OOBI exchange and challenge/response\nexchange over a live session with an unauthenticated contact to ensure the\nother person in the live session has control of the contact’s private keys.\n\nStrength All key-pairs MUST be generated using a cryptographic algorithm with at\nleast 128 bits of cryptographic strength for the salt or seed used to generate\nthe private key of the key pair.\n\nValidator An entity or component that determines that a given signed statement\nassociated with an identifier was valid at the time of its issuance.\n\nVerifier An entity or component that cryptographically verifies the signature(s) on an\nevent message.\n\nVLE| Software Open-source developed software sponsored by GLEIF with the capabilities for\nVvLEI Credential Issuance, vLEI Credential Presentation, Identifier and Key\nManagement and vLEI Credential Revocation and supporting functions.\n\nWatcher An entity or component that keeps a copy of a Key Event Receipt Log (KERL)\nfor an identifier but is not designated by the Controller thereof as one of its\nWitnesses.\n\nWitness An entity or component designated (trusted) by the Controller of an\nidentifier. The primary role of a Witness is to verify, sign, and keep events\nassociated with an identifier. A Witness is the Controller of its own self-\nreferential identifier which may or may not be the same as the identifier to\nwhich it is a Witness. As a special case a Controller may serve as its own\nWitness. Witness designations are included in key (establishment) events. As\na result, the role of a Witness may be verified using the identifier’s rotation\nhistory. When designated, a Witness becomes part of the supporting\ninfrastructure establishing and maintaining control authority over an\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 12 of 13\n\nGlossary\n\nPublic Document Version 1.1\n\n2023-04-03_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2023-04-03\nGLEIF Glossary_v1.1_Final\n","contentLength":2371,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:15:49.925Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-glossary_v1.1_final.pdf","content":"identifier. An identifier Witness therefore is part of its trust basis and may be\ncontrolled (but not necessarily so) by its Controller.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 13 of 13\nGlossary\nPublic Document Version 1.1\n2023-04-03_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2023-04-03\nO:GLE\":> Glossary_v1.1_Final\n","contentLength":351,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:15:49.925Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-glossary_v1.1_final.pdf","content":"Candidate vLEl Issuer An organization that has applied to become a Qualified vLEI\nIssuer.\nContinuity Policy A policy that GLEIF must have for the survival of control authority of all\ncontrollers for the GLEIF Root AID and its Delegated AIDs, including Escrow\nControllers and that QVIs and Legal Entities should have for survival of\ncontrol authority of their Controllers.\nDay A business day, provided that a given day only counts as such ifitis a\nbusiness day both at GLEIF's legal domicile in the operating office in\nFrankfurt/Germany, and at the Qualified vLEI Issuer’s domicile. Defined\nterm in the vLEl Issuer Qualification Agreement.\nDesignated Authorized A representative of a Qualified vLEI Issuer or a Legal Entity that are\nRepresentatives (DARs) authorized by the QVI or the Legal Entity to act officially on behalf of the QVI\nor the Legal Entity. DARs of QVIs can authorize vLEl Issuer Qualification\nProgram Checklists, execute the vLEI Issuer Qualification Agreement and\nprovide designate/replace Qualified vLEI Issuer Authorized Representatives\n(QARs). DARs of Legal Entities can execute the contract between a Qualified\nvLE! Issuer and the Legal Entity and provide designate/replace Legal Entity\nAuthorized Representatives (LARs).\nEffective Date The later of the dates of sighing shown on the first page of the vLEl Issuer\nQualification Agreement.\nEngagement Context Role Person | p orson that represents the Legal Entity in a functional or in another\n(ECR Person) context role and is issued an ECR VLEI Credential.\nExtraordinary vLEl Issuer Qualification conducted under exceptional circumstances which give GLEIF\nQuialification reason to believe that the Qualification Documentation is no longer current\nor being adhered to\nGLEIF Global Legal Entity Identifier Foundation\nGLEIF Authorized Representative A representative of GLEIF authorized to perform the identity verification\n(GAR) requirements needed to issue the QVI vLEI Credential. GLEIF has authorized\nspecific GARs, Internal and External GARs, for the GIDA and GEDA (see\ndefinition of Delegated AlIDs).\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 3 of 13\nGlossary\nPublic Document Version 1.1\n2023-04-03_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2023-04-03\nGLEIF Glossary_v1.1_Final\n","contentLength":2286,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:15:49.925Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-glossary_v1.1_final.pdf","content":"GLEIF Business Day Business Day in Frankfurt am Main, Germany (Monday — Friday).\n\nGLEIF Identifier Governance A document that details the purpose, principles, policies, and specifications\n\nFramework, v1.0 that apply to the use of the GLEIF Root Autonomic Identifier (AID) and its\nGLEIF Delegated AlDs in the vLEI Ecosystem.\n\nGLEIS Global Legal Entity Identifier System\n\nGlobal LEI Repository A database managed by GLEIF containing all current and historical LEls and\nLEI reference data.\n\nIdentity Assurance A process that is part of Identity Verification, the steps of which are defined\nin each of the vLEI Credential Frameworks of the vLEI Ecosystem\nGovernance Framework, which must be conducted before the issuance of\nVLEI Credentials.\n\nIdentity Authentication A process that is part of Identity Verification, the steps of which are defined\nin each of the vLEI Credential Frameworks of the vLEI Ecosystem\nGovernance Framework, which must be conducted before the issuance of\nVLEI Credentials.\n\nLegal Entity As defined in 1ISO 17442:2020, a legal person or structure that is organized\nunder the laws of any jurisdiction; includes, but is not limited to, unique\nparties that are legally or financially responsible for the performance of\nfinancial transactions or have the legal right in their jurisdiction to enter\nindependently into legal contracts, regardless of whether they are\nincorporated or constituted in some other way (e.g., trust, partnership,\ncontractual). It includes governmental organizations and supranationals and\nindividuals when acting in a business capacity but excludes natural persons.\nIt also includes international branches.\n\nLegal Entity Authorized A representative of a Legal Entity that are authorized by a DAR of a Legal\n\nRepresentative (LAR) Entity to request issuance and revocation of vLEI Legal Entity Credentials,\nLegal Entity Official Organizational Role vLEI Credentials (OOR VLElI\nCredentials), and Legal Entity Engagement Context Role vLEI Credentials\n(ECR vLEI Credentials).\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 4 of 13\n\nGlossary\n\nPublic Document Version 1.1\n\n2023-04-03_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2023-04-03\nGLEIF Glossary_v1.1_Final\n","contentLength":2226,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:15:49.926Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-glossary_v1.1_final.pdf","content":"A document that details the requirements for vLEI Role Credentials issued to\nrepresentatives of a Legal Entity in other than official roles but in functional\nor other context of engagement.\nA document that details the requirements for vLEI Role Credentials issued to\nofficial representatives of a Legal Entity.\nA document that details the requirements for vLEI Credential issued by a\nQuialified vLEl Issuer to a Legal Entity.\nAn organization accredited by GLEIF to validate legal entity information and\nregister new LEls and reference data which are sent to GLEIF for inclusion in\nthe GLEIS.\nLegal Entity Identifier(s)\nAn agreement that outlines requirements for handling confidential\ninformation (Appendix 1 to the vLEI Issuer Qualification Agreement)\nA person that represents the Legal Entity in an official organizational role\nand is issued an OOR vLEI Credential.\nA session, an example is a continuous web meeting attended by all parties\non both audio and video.\nA document in the standard portable document format \"pdf\"-format\nThe formal evaluation process performed by GLEIF to ensure that an\norganization which has applied for Qualification (a Candidate vLEI Issuer)\nmeets the requirements of the vLEI Ecosystem Governance Framework.\nThe documentation to be provided by the Candidate or Qualified vLEI Issuer\nto GLEIF for evaluation for Qualification.\nA document that specifies the contract terms that must be included in the\nagreement between a Qualified vLEI Issuer and a Legal Entity that has\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 5 of 13\n\nGlossary\n\nPublic Document Version 1.1\n\n2023-04-03_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2023-04-03\n\nGLEIF Glossary_v1.1_Final\n","contentLength":1718,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:15:49.926Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-glossary_v1.1_final.pdf","content":"requested a Legal Entity vLEI. (Appendix 7 to the vLEIl Issuer Qualification\nAgreement)\nQualified VLEI Issuer (QV1) The contracting party to the vLEl Issuer Qualification Agreement that has\nbeen qualified by GLEIF as a Qualified vLEI Issuer.\nQualified VLEI Issuer Authorization | | | credential that enables simple, safe, secure instruction and\nVLEI Credential authorization by a Legal Entity Authorized Representative (LAR) sent to a\nQVI for the issuance and revocation of vLEI Role Credentials.\nQualified VLEI Issuer Authorized A designated representative of a QVI authorized to conduct QVI operations\nRepresentative (QAR) with GLEIF and Legal Entities. QARs perform the Identity Verification\nrequirements needed to issue VLEI Legal Entity Credentials, Legal Entity\nOfficial Organizational Role vLEI Credentials (OOR vLEI Credentials), and\nLegal Entity Engagement Context Role VLEI Credentials (ECR vLEI Credentials)\nas well as the issuance and revocation these Credentials.\nQualified vLEI Issuer Business Day | p,;siness Day according to local Qualified VLEI Issuer business calendar.\nQualified VLEI Issuer Identifier and A document that details the requirements to create and delegate AlDs for\nVLEI Credential Governance the QVI and to enable the vLE| Credential to be issued by GLEIF to Qualified\nFramework VLEI Issuers which allows the Qualified vLEl Issuers to issue, verify and\nrevoke Legal Entity VLEI Credentials, Legal Entity Official Organizational Role\nVvLEI Credentials, and Legal Entity Engagement Context Role vLEI Credentials.\nQualified vLEI Issuer TrustMark A document that details the terms of use of the TrustMark by the Qualified\nTerms of Use VLE| Issuer. (Appendix 6 to the VLEI Issuer Qualification Agreement)\nQVI Authorized Representative A designated representative of a QVI authorized to conduct QVI operations\n(QAR) with GLEIF and Legal Entities.\nQVI Authorized Representative A person in the role of a QAR.\n(QAR) Person\nRoot of Trust Strong governance which begins with the issuance and maintenance of the\nLEl itself, GLEIF will be the anchor of the vLEIl ecosystem, at the root of the\ngovernance that will position the LEI as a key component in building a trust\nlayer for identification and verification of legal entities as the LEI allows\nauthentication that the legal entity is indeed who it claims to be and that\nthose who act on its behalf, can.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 6 of 13\nGlossary\nPublic Document Version 1.1\n2023-04-03_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2023-04-03\nGLEIF Glossary_v1.1_Final\n","contentLength":2589,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:15:49.926Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-glossary_v1.1_final.pdf","content":"A document that contains detailed descriptions of the services to be\nprovided by GLEIF and Qualified vLEI Issuers and the service level\nrequirements expected for these services. (Appendix 5 to the VLEI Issuer\nQualification Agreement)\nA set of rules, orders, regulation and court decisions which constitutes the\nlaw in Switzerland. The source of Swiss law can be federal or cantonal. GLEIF\nwill host a list of links where Swiss law can be found.\nIT or operational infrastructure services outsourced by Qualified vLEl Issuers.\nA TrustMark for a Qualified vLEI Issuer provided GLEIF by to the Qualified\nVLE! Issuer (refer to Appendix 6 to the vLEI Issuer Qualification Agreement)\nAn Authentic Chained Data Container credential which contains an LEI\nissued in accordance with the vLEI Ecosystem Governance Framework\nrequirements.\nA document that defines the information security, privacy, availability,\nconfidentiality and processing integrity policies that apply to all vLEI\nEcosystem Members.\nThe cryptographic chain of trust for organizational identity established for\nthe vLEI which connects the following entities:\nGLEIF>Qualified VvLEI Issuers>Legal Entities>Persons Representing Legal\nEntities.\nA stakeholder in the vLEI Ecosystem following the requirements outlined in\nthe vLEI Ecosystem Governance Framework.\nThe process of issuing a vLEI Credential.\nA list of contact details of GLEIF and the Candidate vLEI Issuer during\nQuialification and of GLEIF and the Qualified vLEI Issuer during ongoing\noperations. Also, will include the names and email addresses of Designated\nAuthorized Representatives (DARs) of the Legal Entity (Appendix 4 to the\nvLEl Issuer Qualification Agreement).\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 7 of 13\n\nGlossary\n\nPublic Document Version 1.1\n\n2023-04-03_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2023-04-03\n\nGLEIF Glossary_v1.1_Final\n","contentLength":1902,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:15:49.926Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-glossary_v1.1_final.pdf","content":"An agreement between GLEIF and an organization that has been qualified by\nGLEIF to operate as a Qualified vLEl Issuer.\nThe document that details the control and process requirements for\nQualification (Appendix 3 to the vLEI Issuer Qualification Agreement).\nThe document that describes the Qualification program (Appendix 2 to the\nvLEl Issuer Qualification Agreement).\nAll steps taken to ensure that the vLEI continues to be based on the\nexistence of a LEI that maintains the required entity and registration\nstatuses in the GLEIS as well as keeping credential wallets and private keys\nsecure.\nThe process of revoking a vLEI Credential.\nAny user of vLEI credentials in any applicable use case.\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 8 of 13\n\nGlossary\n\nPublic Document Version 1.1\n\n2023-04-03_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2023-04-03\n\nGLEIF Glossary_v1.1_Final\n","contentLength":908,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:15:49.926Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-glossary_v1.1_final.pdf","content":"Technical Terms Technical Definitions\n\nAutonomic Identifiers (AIDs) AlIDs are self-certifying identifiers that are imbued with self-management\ncapabilities via the KERI protocol. There are two main classes of AIDs in KERI:\n1) transferable AIDS, and 2) non-transferable AIDS. Key management policies\nare different for the two classes of AIDs.\n\nChallenge Message A message sent and responded to during the Identity Authorization session.\n\nController A controlling entity of an identifier. See the examples Root AID GLEIF\nAuthorized Representative, the Internal Delegated AID GLEIF Authorized\nRepresentative and the External Delegated AID GLEIF Authorized\nRepresentative in the GLEIF Identifier Governance Framework.\n\nDelegated AlDs Autonomic Identifiers (AIDs) which have associated Decentralized Identifier\n(DIDs). These are primary identifiers. Unless otherwise indicated, whenever\nthe term identifier is used with reference to KERI, the references are to\nprimary identifiers. Examples are: GLEIF Internal Delegated AID (GIDA) and\nGLEIF External Delegated AID (GEDA).\n\nDistributed Hash Table (DHT) In computing, a data structure that implements an associative array abstract\ndata type, a structure that can map keys to values (Wikipedia). Within the\nVLEI Ecosystem, these tables are used for the discovery of AlDs.\n\nEscrow Agent Specific organizations appointed by GLEIF as secondary signers to the GLEIF\nRoot AID, to be able to act if the required weighted multi-sig threshold of\nGLEIF primary signers is not available for key rotation or recovery.\n\nFully Signed Meets the threshold of the signed keys\n\nGLEIF API API to directly access the complete LEI data pool in real time with rich query\ncapabilities.\n\nQVIs must use the GLEIF API to look up the Registration Status of LEls, to\nensure that vLEI credentials are only issued to organizations who have an LElI\nin good standing and to identify, if vLEI credentials have to be revoked\nbecause the LEI has LAPSED or is otherwise not in good standing anymore.\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 9 of 13\n\nGlossary\n\nPublic Document Version 1.1\n\n2023-04-03_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2023-04-03\n\nGLEIF Glossary_v1.1_Final\n","contentLength":2223,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:15:49.926Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-glossary_v1.1_final.pdf","content":"GLEIF Root of Trust AID The GLEIF Root Aid provides the Root of Trust for the ecosystem tree of trust.\nEach branch in that tree is a Chain of Trust. The Delegated Aid Chain of Trust\nbranch provides trust for delegated GLEIF AIDS and Qualified vLEI Issuer\nDelegated AlIDs. The vLEI Chain of Trust branch, that attaches to the\nDelegated AID Chain of Trust branch, provides trust for all vLEIs within the\nVLEl ecosystem.\n\nInception Event Initial event used during the creation of an AID.\n\nInteraction Event Non-establishment Event that anchors external data to the key-state as\nestablished by the most recent prior establishment event.\n\nIT Information Technology, encompassing application software, computer and\nnetwork systems and suitable equipment for the implementation and\nsupport of such systems.\n\nKey Event Receipt Infrastructure Provides the identifier and key management architecture for the vLElI\n\n(KERI) Ecosystem Technical Architecture\n\nKey Management Unless otherwise specified, the term key-pair refers to an asymmetric (public,\nprivate) key-pair for digital signatures. The private key is used to generate\nsignatures and the public key is used to validate signatures. Ecosystem key\nmanagement policies are grouped into three sets of policies for protecting\nthree different infrastructures.\n\n1. Key-pair creation and storage infrastructure;\n2. Signature creation infrastructure;\n3. Signature verification infrastructure.\n\nKey Pre-Rotation for Transferable | KERI, the authoritative key stage of a transferable AID consists of two sets of\n\nAlDs key-pairs. The first set is the current set of signing keys and the second set is\nthe pre-committed set of one-time rotation keys that after rotation will\nbecome the next or pre-rotated set of signing keys. These two sets provide\nthe basis for KERI’s pre-rotation mechanism and the on-device storage of\npublic/private key pairs associated with an AID.\n\nKey Store The on-device storage of public/private key pairs associated with an AID.\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 10 of 13\n\nGlossary\n\nPublic Document Version 1.1\n\n2023-04-03_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2023-04-03\nGLEIF Glossary_v1.1_Final\n","contentLength":2207,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:15:49.926Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-risk-assessment_v1.1_final.pdf","content":"GLEIF verifiable LEI (vLEI) Ecosystem Governance Framework 1.0 Risk Assessment Document Version 1.1 2023-04-03\nVersion Date: 2023-04-03\nStatus: Final\nDID URL for Risk Assessment:\ndid:keri:EINmHd5g7iV-UldkkkKyBIHO52blyxZNBn9pg-\nzNrYoS?service=vlei-\ndocuments&relativeRef=/egf/docs/2023-04-\n03_verifiable-LEI-(vLEl)-Ecosystem-Governance-\nFramework-Risk-Assessment_v1.1_Final.xlsx\n","contentLength":378,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:16:12.528Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-risk-assessment_v1.1_final.pdf","content":"ceir) verifiable LEI (VLEI) Ecosystem Governance Framework 1.0 Risk Assessment Document Version v1.1_Final 2023-04-03\nRISK N RISK TOIP L. [RLSTARERS SEVERITY LIKELIHOOD RicK RISK CONSIDERATION ACTIONS RISK TREATMENT RISK TREATMENT ACTION RISIDUAL RISK\no Ve ARFECTED IMPACT\nGOVERNING AUTHORITY (GLEIF) RISKS GLEIF - Global Legal Entity Identifier Foundation operates and manages the Global LEI System (GLEIS);\nLack of competence to perform role Ecosystem Governance 4 1 peediiofexneticncedipersennelipiopertialneland Mitigation Mitigated by proper, regular training ResidallnsKiegardediolbelionand\ngovernance framework acceptable.\nLack of sufficient policy and practices Ecosystem Governance 1 1 Low Need for complete governance framework and feedback Mitigation Mitigated by GLEIF workflows supported by KERI vLEI Residual risk regarded to be low and\nloop software acceptable.\nP \" Y 5 Residual risk |\nLack of consistency,inits ownloperating practices Eeosystemy] (Govemance 3 1 LoW Requlre§ independent oversight and trust assurance AGEEEER Covered l?y 1SO 20000 certification along with esidual risk regarded to be low and\nmechanisms systematic control acceptable.\nit Fi k, VLEI\nLack of consistency in operating practices of Qualified vLEI Requires proper oversight and trust assurance o pleated b'y'Ecc'system GEUAHEIES AEES U Residual risk regarded to be low and\nEcosystem Governance 3 3 A Mitigation Issuer Qualification Program and use of Key Event\nIssuers mechanisms N acceptable.\nReceipt Infrastructure (KERI) protocol\n\" . . Mitgated by Ecosystem Governance Framework, and . )\nR | risk |\nLack of accountability of roles in network Ecosystem Governance 3 1 LOW (RIS (e su'perwsory aodicealicienlehuandiisr Mitigation specifically for Qualified vLEI Issuers, the VLEI Issuer aaleiee adeditclocionfand\nassurance mechanisms . acceptable.\nQualification Agreement\nLack of legal enforcability of Authentic Chained Data . o o GLEIF is researching and monitoring the legal Residual risk regarded to be low and\nContainer (ACDC) credentials in jurisdictions eSS Coenance B B ESlicslmenitonnelciitRaliceallaceeptance Ritesue enforcability of ACDCs in jurisdictions. acceptable.\nRequires members of ecosystems to agree to use the Work with industries to support their use cases with Residual risk regarded to be low and\nEcosystem lacks industry acceptance or insufficient demand Ecosystem Governance 4 3 q 4 8 Mitigation R . p;'n' . E\nVLEI VLEI for organizational identification needs acceptable.\nQualified vLEI Issuer — An organization qualified by\nQualified vLEI Issuer Risks GLEIF to issue Legal Entity vLEI Credentials and Legal\nEntity Official Organizational Role vLEI Credentials\nRequires authorization by Legal Entity's Authorized\n\" . . _— Representatives (LARs), Identificaton of the person and\nVLEI Legal Entity Credential or vLEI Legal Entity Official\n'g . R s J . ty . . Processing Requires training, trust assurance practices, controlled S Official Organizational Role (OOR) of the OOR Person, Residual risk regarded to be low and\nOrganizational Role Credential issued without appropriate Credential 3 5 3 A Mitigation P\ne Integrity practices and proper workflow verification of control of KERI DID. Include a acceptable.\nverification R e,\nIssuer/Approver workflow in Qualified vLEI Issuer\noperations\n. . L . . Requires appropriate monitoring of obligations of Legal o Monitoring of the status of the Legal Entity's LEI by Residual risk regarded to be low and\nLegal Entity vLEI Credential Becoming invalid Credential Security 5 3 . Entities holding vLEls Mitigation Qualified VLEI Issuers acceptable.\nRiskis not to GLEIF. Legal Entities will be solely\nLegal Entity Official Organizational Role VLEI Credentials Requires appropriate action by Legal Entities to manage responsible for the management of vLEI Role Residual risk regarded to be low and\nd A ty \" = Credential Security 1 1 LOW q e ] v ¢ Acceptance b A ¢ ey . e\nbecoming invalid their vLEI Role Credentials Credentials issued and the composition of their acceptable.\norganizational wallets.\ne . . . - \" S \" . Residual risk regarded to be low and\nQualified VLEI Issuer operations unavailable Credential Availability 5 3 Requires network redundancy procedures Mitigation Requires contingency and systen redundancy .\n","contentLength":4286,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:16:12.528Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-risk-assessment_v1.1_final.pdf","content":"Qualified vLEI Issuer using obsolete and/or untested vLEI . Processing Requires change management process for Qualified vLEI . Eirng ma‘n‘agernent reeess el I i el Residual risk regarded to be low and\nCredential s 5 3 Mitigation Issuer Qualification Agreement. GLEIF to manage the\nsoftware or APls Integrity Issuers o acceptable.\nchange management process for Qualified vLEI Issuers\nVerifier Risks Verifier - An entity that is verifying the components and provenance of a vLEI credential for a use case\nLack of consistent verification practices Credential Security 2 1 LOW- Requires tralnlng, trust assurance practices and Mitigation Mitigated by educatlhg Verlfler? of the existence of Residual risk regarded to be low and\nMEDIUM controlled practices proof requests to verify credentials acceptable.\nEvidence of verification incomplete or in incorrect format of Credential Processing 5 2 Requires standard formats and formatting controls for Mitigation Develop standard formats and formatting controls for ~ Residual risk regarded to be low and\nproof requests Integrity proof requests £ proof requests acceptable.\nResidual risk will be the time\n\" - . e . between request to revoke is made\nRequires adequate VLEI status and validity checkin, Mitigated by KERI VLEI software that automaticall\nRevoked VLEI being accepted Credential Security 5 2 q q v 8 Mitigation 8 v . N V. by the Legal Entity and actual\nprocedures checksrevocation status before accepting a credential A .\nrevocation at the Qualified vLEI\nIssuer.\nn . . . e . . \" e . . S e . - Residual risk regarded to be low and\nMan-in-the_middle attack during legitimate verification Credential Security 5 3 Requires Verifier vulnerability practices Mitigation Mitigate with security in KERI vLEI software ——\nVerifier network unavailable Credential Availability 5 3 Requires network redundancy procedures Mitigation Mltlgate paiapercpriateiEtenledundaneyond Raliskicesiediclbelowlend\ncontingency acceptable.\nGLEIF Credential Registry Risks GLEIF manages its own Credential Registry. These are risks associated with that repository.\nLack of competence to perform role Credential Governance 5 1 A REGMIES tralnlng, [Setasstiancelpiact cesland Mitigation Mitigated by proper, regular training Residalliekecardediiolbelionand\nMEDIUM controlled practices acceptable.\nUnavailable registry Credential Availability 5 3 Requires availability controls Mitigation Mltlgate ihlaporeniaiciyetenliedindancyiang Residalliekecardediiolbelionand\ncontingency acceptable.\nA n . . \" . S e . . Residual risk regarded to be low and\nLack of appropriate access to registry Credential Security 5 3 Requires appropriate access controls Mitigation Mitigate with effective access controls .\n\" . . . . \" . S e . - Residual risk regarded to be low and\nInapproriate access writes to registry Credential Security 5 2 Requires appropriate access management controls Mitigation Mitigate with security in KERI vLEI software L\nBreach of registry Credential Security 5 2 Requlr‘es approprlna‘te s.ecunty EermecrbEach Mitigation Mitigate with security in KERI vLEI software R aliERceeediiobeliowland\ndetection and notification controls acceptable.\nExploited use of stolen vLEls Credential Security 5 2 Requires adequate breach notification processes Mitigation Mltlga?ed iy ¥ 63 () ) s wiidn (e i Residalliekecardediiolbelionand\nReporting API acceptable.\nGLEIF VLEl Issuer Qualification Program Risks GLEIF operates its own VLEI Issuer Qualification program. These are the risks associated with that program.\nLack of competence to perform role Ecosystem Governance 1 1 LOW RegEs tralr.ung, suff|.C|ent exbetiencelandeenerall Mitigation Mitigated by proper, regular training Residalliekecardediiolbelionand\naccepted auditor practices acceptable.\nInconsistent or biased qualification process Eeosystemy] (Govemance 2 1 LoW ReqL‘ures we!l-documented requirements and process, Mitigation Mltlgated by comprehensive program, applied Residual risk regarded to be low and\napplied consistently consistently acceptable.\nLegal Entity Risks Legal Entity — a legal person or structure that is organized under the laws of any jurisdiction that meets the eligibility criteria for registering for a LEI.\nMitigated, since an invalid LEI would never appear and\nCounterfeit credentials (not based on valid LEIs) being issued Credential Privacy 5 1 Lo Requires adequate credential non-repudiation practices Mitigation et nst e cheatztlin tie ClEB el cc?unterfelt e ol krseaiedicbeloniond\nMEDIUM never would be able to connect to the chain of trust of acceptable.\nthe VLEI system.\nThis risk must be tackled at the issuance stage. First,\nthe QVI only can issue on receipt of a QVI Authorization\nVLEI sent by the Legal Entity Authorized\nRepresentatives (LARs). Then,as part of the Identity\nVerification process, the QVI will verify that the OOR\nRequires adequate VLEI Role Credential issuance Person is in control of their DID. OOR VLEI Role Residual risk regarded to be low and\nLack of binding between Legal Entity and VLEls issued Credential Confidentiality 5 2 q q Mitigation . . . . 8\nmeasures Credentials will have role lists that can act as a guide acceptable.\nfor the types of OORs expected for the entity legal\nform of the Legal Enity, preventing OOR Credential\nissuance for bogus official roles. Assigning roles for\nEngagement Context Role Credentials entirely will be\nthe responsibiity of the Legal Entity.\n","contentLength":5425,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:16:12.528Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-risk-assessment_v1.1_final.pdf","content":"Residual risk is that Holders do not\nadequately protect their wallets and\nThere will be a list of requirements/features for re\\?ent cot:fsion despite the\nImposter using valid Legal Entity vLEI Credential Credential Security 5 2 Requires adequate wallet protection measures Mitigation wallets holding credentials and that will be relied upon h . . & .\nguidance and requirements in the\nby VvLEI Holders.\nVLEI Ecosystem Governance\nFramework.\nMitigated by KERI prerotation and effective wallet\nmanagement.\nThe best mitigation for a wallet's access key is to use Residual risk resarded to be low and\nPrivate signing key is compromised Credential Security 5 5 HIGH Requires adequate protection measures for private keys Mitigation multi-signatures for the identfier which means that tabl 8\nmultiple wallets must be compromised. Thus acceptable.\ncompromise of one wallet private key does not result in\nloss of control of the identifier.\nLack of portability of vLEIs Credential Availability 5 2 - Requires adequate VLEI interoperability practices Mitigation KERI will provide vLEI portability. ::cst-lz‘:’:aaLIZSk [cesdediiobelionand\nThe vLEl is designed as an Ecosystem Governance Residual risk ded to be | d\nLack of credential federation across ecosystems Ecosystem Availability 5 3 Requires adequate credential interoperability practices ~ Mitigation Framework to be able to interoperate within other esl :ablns regarded to be low an\necosystems. acceptable.\nSocial engineering attacks sucessfully gather credentials b Credentials will be cryptographically bound to wallets Residual risk regarded to be low and\n8 8 ve Y Credential Security 5 2 Requires adequate wallet protection measures Mitigation . _ryp 8rap Y 8\nperpetrators and can be biometrically bound to Holders acceptable.\nUtility Risks Risks associated with KERI infrastructure (Part 1) and vLEI Credentials (Part 2)\nAll VLEI software will be publicly available open source\no code that will be conformance tested prior to Residual risk regarded to be low and\n5 2 Mitigation distribution. ATVA (Topological Vulnerability Analysis) acceptable.\nVLE software contains undetected bugs or defects that can VLEI software should be tested and/or reviewed or scan can be requested to be performed for new\nbe exploited by attackers. * Utility Security audited for bugs and defects, internally and externally applications.\no Can be tested us_lngathlrd-partysecuntyrlsk Residual risk regarded to be low and\n5 1 Mitigation assessment against KERI Key Management acceptable\nInadequate protection of pre-rotated sets of keys* Utility Security Training and monitoring of key management practices Requirements '\n5 a A Can be tested using a third-party security risk Residual risk regarded to be low and\nBest practices for code delivery and library usage not g assessment against KERI Key Management acceptable.\nfollowed for signature verification infrastructure* Utility Security Training and monitoring of best practices implemented Requirements\nCan be tested using a third-party security risk . .\nThe specific holders of cryptographic keys have not been kept 3 2 Mitigation assessment against KERI Key Management ReS|d:aL|r|sk [cesdediiobelionand\nconfidential.* Utility Security Training and monitoring of key management practices Requirements acceptable.\nThe time and place of key rotation have not been kept Can be tested using a third-party security risk . .\nconfidential among the key holders until after the rotation 3 2 Mitigation assessment against KERI Key Management ReS|d:aL|r|sk [cesdediiobelionand\nhas been completed.* Utility Security Training and monitoring of key management practices Requirements acceptable.\nlified VLEI | h t itored their publi\nQlfa fHed v ssue‘rs ave not moni ore. elr‘pu ¢ S Residual risk regarded to be low and\nWitnesses for vLEI issuance and revocation registry for 5 1 Mitigation tabl\nerroneous or malicious issuances and revocations. Utility Security Secondary monitoring by GLEIF GLEIF secondary Witness monitoring program acceptable.\n*Note: Utility layer risks also can affect the higher layers.\n","contentLength":4084,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:16:12.528Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-risk-assessment_v1.1_final.pdf","content":"COLUMN HEADER EXPLANATION Potential Values\n[ RiskF |Auniaue dentiler of o ik for ierence purposes [\nRisk Description Description of a unique risk\nTolP Layer The Governance Stack Layer the risk operates based on the TolP Governance Stack Eredzntlal\nUtility\nAvailability\nTrust Area Affected Information trust component affected by the risk\nAvailability\nProcessing Integrity\nNegligible\nSeverity Judgmental evaluation of impact the risk would have on the entity if realized\nHighly Unlikely\nJudgmental evaluation of the potential that the risk will occur risk without controls or\nother circumstances to prevent it.\nLow\nJudgmental scoring of risk's effect based on severity and and likelihood.\nRisk Consideration Actions Factors to consider regarding risk treatment\nMitigation\nRisk Treatment Recommended action category to take to handle the risk\nRisk Treatment Action High level action identified to treat risk\nResidual Risk Judgmental level or state of risk after applying risk treatment Text or Impact Level\n","contentLength":1005,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:16:12.528Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-risk-assessment_v1.1_final.pdf","content":"--\n\n8 -- o -\n\no\n\n=\n\n]\n\nw\n\n=\n\n-\n\nw\n\no\n\nw\n\nI\n\n8 - - o -\n- MEDIUM MEDIUM MEDIUM-HIGH HIGH\n- MEDIUM MEDIUM-HIGH HIGH HIGH\n","contentLength":118,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:16:12.528Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-trust-assurance-framework_v1.1_final.pdf","content":"GLEIF verifiable LEI (vLEI) Ecosystem Governance Framework 1.0 Trust Assurance Framework Document Version 1.1 Final 2023-04-03\nVersion Date: 2023-04-03\nStatus: Final\nDID URL for the Trust Assurance Framework:\ndid:keri:EINmHd5g7iV-Uldkkk Ky BIH052bly xZNBn9pg-\nzNrYoS?service=vlei-documents&relativeRef=/egf/docs/2023-04-\n03_verifiable-LEI-(vLEIl)-Ecosystem-Governance-Framework-Trust-\nAssurance-Framework_v1.1_Final.xlsx\n","contentLength":421,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:17:43.094Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-trust-assurance-framework_v1.1_final.pdf","content":"GLEIF verifiable LEI (vLEI) Ecosystem Governance Framework 1.0 Trust Assurance Framework Document Version 1.1 Final 2023-04-03\nVersion Date: 2023-04-03\nStatus: Final\nThe VLEI Ecosystem Governance Framework MUST _enable GLEIF’s role to support and contribute to unique global persistent X; GLEIF is acting 'as the Roo't of\no R . . Trust under a sustainable business\no organizational identity as a public good.\nPrinciples 1. model\nThe VLEI Ecosystem Governance Framework MUST deliver on GLEIF’s vision that every legal entity be able to be identified X; existence of vLEls for Legal\n5 uniquely, having only one global identity and this identity should include a digital identity. Entities\nThe VLEI Ecosystem Governance Framework MUST leverage the principle of free and open access and use of the data in the X; no fees to data users accessing\n3 Global LEI System regarding legal entities and their entity-level and relationships. VLEl information on GLEIS\nThe VLEI Ecosystem Governance Framework MUST support GLEIF’s intention to deliver the vLEl infrastructure using a technology X; KERl implemented through open source\nagnostic approach and to use open source whenever possible. development and maintenance\nThe VLEI Ecosystem Governance Framework MUST support GLEIF’s use of open standards. X; use of standards in vLEls (IS0, X; KER| implemented through Open source\n5. W3C, TolP) development and maintenance\nThe VLEI Ecosystem Governance Framework MUST fulfill GLEIF’s intention to make the vLEl infrastructure widely available as X ap'p|IC'abI|ItY of V!'EI to digital X; availability of Qualified vLEl Issuers on . . .\n. organizational identity across use . X; KERI interoperability and portability\nbroadly useful as possible. . a global basis\ncases and domains\nThe VLEI Ecosystem Governance Framework MUST enable interoperability, for the digital identity data of an entity to be\nrepresented, exchanged, secured, protected, and verified interoperably using open, public, and royalty-free standards, as well as X: KERI it bili d vortabilit\nportability, the ability of identity rights holders to move or transfer a copy of their digital identity data to the agents or systems of . interoperability and portability\ntheir choice.\n7.\nThe VLEI Ecosystem Governance Framework MUST empower vLEI Credential holders to secure their digital identity data at rest X: KERI \" h d .\nand in motion, to control their own identifiers and encryption keys, and to employ end-to-end encryption for all interactions and to . cryptography and security\n. A . . features; quantum proof\nprotect the privacy of their digital identity data when applicable.\nThe VLEI Ecosystem Governance Framework MUST ensure verifiability and authenticity by empowering vLE| Credential holders to X; VLEI Credential Identity X; vLEI Credential Identity Verification . A\n. . L o . e . . . X; Credential verification process\nprovide verifiable proof of the authenticity of their digital identity data. Verification Requirements Requirements\nThe VLEI Ecosystem Governance Framework MUST allow vLEI Ecosystem stakeholders to be accountable to each other for\nconformance to the purpose, principles, and policies of the vLEl Ecosystem Governance Framework. All vLEI Ecosystem X; confirmation during Annual vLEl Issuer\nstakeholders MUST be responsible and be able to demonstrate compliance with any other requirements of applicable law. X; annual certification Qualification for both Qualified vLEI\nNothing in the vLEl Ecosystem Governance Framework SHOULD require VLEI Ecosystem stakeholder to breach applicable law in Issuer and GLEIF\n10 order to perform its obligations under the vLEI Ecosystem Governance Framework.\nGeneral All LE'Is conta'lned' in vLEIs MUST maintain a LE| Entity Status of Active and a LEI Registration Status of Issued, Pending Transfer or X; requirement in Credential X; check using GLEIF API X; check using GLEIF API\nRequirements |1. Pending Archival in the Global LEI System. Frameworks\nAll Issuers of vLEIs MUST verify that a Holder's Autonomic Identifier (AID) is controlled by the Holder. X; mandat'ory checkin vLEI Issuer X; co'vered as part of th‘,e Credential\n2. Credential Issuance workflow issuance process with KERI\nAll QVIs MUST have executed a VLEI Issuer Qualification Agreement. X; executed VLE| Issuer Qualification\n3. Agreements\nAll QVIs MUST successfully complete Annual vLEI Issuer Qualification. X conflrmat'lo'n 01\" Annual vLELIssuer\nQualification by GLEIF\n","contentLength":4454,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:17:43.094Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-trust-assurance-framework_v1.1_final.pdf","content":"6.5 Key The specific holders of cryptographic keys MUST be kept confidential and shall be determined by Qualified vLEI Issuer internal policy. X; confirmation duntlr?g Annual VLEI Issuer\nManagement |1. Qualification\n- GLEIF External GARs MUST approve a QVI Rotation Event that occurs no less than six months from the last QVI Rotation Event. _— X; conflrmatlogs:lrilfr;cgafir;:ual VLEI Issuer _\nQualified vLEI Issuer Authorized Representatives (QARs) MUST contact GLEIF External GARs for approval of any QVI Rotation Event that occurs less than X; confirmation during Annual vLEI Issuer\nsix months from the last QVI Rotation Event. Qualification\nSigning keys MUST be rotated whenever there is a likelihood of key compromise. X; confirmation duntlr?g Annual VLEI Issuer X; covered by KEBI Key Management\n5. Qualification Architecture\n-_ The time and place of key rotation MUST be kept confidential among the key holders until after the rotation has been completed. _— X; conflrmatlogs:lrilfr;cgafir;:ual VLEI Issuer _\nEncryption keys protecting private keys SHOULD be rotated prophylactically at least quarterly and MUST be rotated whenever the associated signing key X; confirmation during Annual vLEI Issuer\n7. store host configuration changes. Qualification\nThe Delegated AID of a Qualified VLEI Issuer MUST set the Do Not Delegate configuration trait to True. (NOTE: This may change in future versions in X; confirmation during Annual vLEI Issuer X; covered by KERI Key Management\n6.6 Delegation order to accommodate horizontal scalability of the vLEI signing infrastructure.) Qualification Architecture\n6.7 Key . Qualified vLEI Issuers MUST monitor their public Witnesses for their vLEl issuance and revocation registry for erroneous or malicious issuances and X; confirmation during Annual vLEI Issuer\nCompromise revocations (primarily issuances) in order to in-form their key management process that a key recovery may be required. Qualification\nMonitoring 1.\n6.8 Key\nCompromise In any case of key compromise, a Qualified vLEI Issuer MUST:\nRecovery 1.\n-- Investigate as expeditiously as possible at its own expense the source of the key compromise and make a full report of the investigation to GLEIF. _— X; conflrmatlogs:lrilfr;cgafir;:ual VLEI Issuer _\nMake a recovery rotation event that forks their KEL and submit the recovering rotation event and signatures to GLEIF in order that GLEIF may anchor a X; confirmation during Annual vLEI Issuer\n[ confirmation seal in its KEL. Qualification\n-_ Send a key recovery event explanation to GLEIF for publication in GLEIF’s public registry of Qualified vLEI Issuer recovery events. _— X; confi rmatlogs:lrilfr;cgafir;:ual VLEI Issuer _\n6.9 VLEI\nIssuance and Qualified vLEI Issuers MUST monitor their public Witnesses for their vLEI issuance and revocation registry for erroneous or malicious issuances and X; confirmation during Annual vLEI Issuer\nRevocation revocations (primarily issuances) in order to in-form their key management process that a key recovery may be required. Qualification\nPolicies 1.\n6.10 Challenge\nMessage The Challenge Message MUST include a cryptographic nonce generated in real time. X; covered by KERI operations\nPolicies 1.\nThe Challenge Response Message MUST be Fully Signed by the Responder. X; covered by KEBI Key Management\n3. Architecture\n| Ja [The Challenger MUST verify that: - ]\nThe Fully Signed Response contains the same cryptographic nonce as the Challenge Message. X; covered by KEBI Key Management\nArchitecture\nThe signatures of the Responders were generated by the private keys that control the Responder’s AID. X; covered by KEBI Key Management\nArchitecture\n6.11 Policies\nfor Sharing Contact sharing with new members of a group multi-sig AID MUST be performed by a threshold satisfying number of existing members. X; covered by KERI operations\nAuthenticated\nAlDs 1.\nNew members MUST be able to Spot Check through Identity Authentication and the Challenge Response process any new authenticated AID they receive X; covered by KERI Key Management\n2. from existing members or their new group multi-sig AID. Architecture\n","contentLength":4107,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:17:43.094Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-trust-assurance-framework_v1.1_final.pdf","content":"GLEIF verifiable LEI (vLEI) Ecosystem Governance Framework 1.0 Trust Assurance Framework Document Version 1.1 Final 2023-04-03\nVersion Date: 2023-04-03\nStatus: Final\n1 Credential\nSpecifications\n1.2\n\\SIpEC'IfICatIOn Previous versions explicitly cited by policies in this document MUST be supported for a period 18 months . X\nersion\nUpgrades 1.\nNew versions MUST be implemented within a period 12 months after final approval of the new version, unless otherwise X\n2. superseded by revised policies in a new version of the vLEI Ecosystem Governance Framework.\nAfter upgrading to a new version, implementers MUST NOT begin using any breaking changes until the end of the time period\nrequired to adopt new versions. For example, v2.0 must be compatible with v1.0 until the end of the v2.0 adoption period. So v2.0 X\nq pi p p: ption p\n3. must be used in a v1.0 compatible mode.\n2 Security and All signatures for the vLEI Credentials MUST use Ed25519 Signatures CESR Proof Format. X; covered by KERI,VLEI Credential\nPrivacy 1. Operations\nAll VvLEI Credential schema MUST be SIS compliant. X; covered by KERI,VLEI Credential\n2. Operations\nAll instantiated vLEI Credentials MUST be ACDC compliant. X; covered by KERI,VLEI Credential\n3. Operations\nperations\nX; covered by KERI vLEI Credential\n3 Requirements Issuer and Holder Identifiers MUST be KERI AIDs that use the did:keri Method. prerations\nfor vLEI ACDCs |1.\nAll vLEI Credentials MUST include an ACDC version string field. X; covered by KERI,VLEI Credential\n2. Operations\nX; covered by KERI vLEI Credential\n3. All vLEI Credentials MUST support JSON serialization. Operations\nperations\nThe following ACDC sections MUST include a SAID - Attribute (data payload) section, Schema section and Rules section. X; covered by KERI,VLEI Credential\n5. Operations\nAll source links MUST include the SAID of the referenced ACDC. X; covered by KERI,VLEI Credential\n7. Operations\nperations\nIssuers MUST provide the SADs at issuance to Holders when issuing forms 2 and 3, by either including the SAD in the presentation X X X; covered by KERI vLEI Credential\n10 or including a reference to the highly-available service endpoint from which the SAD can be retrieved. Operations\nAviEl . . o X; covered by KERI vLEI Credential\nCredential VLEI Credential schema MUST be compliant the SAID and SIS specifications. Operations\nSchema 1.\nAll VvLEI Credential schema MUST include a SAID (as evidence of immutability). X; covered by KERI,VLEI Credential\n2. Operations\n","contentLength":2488,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:17:43.094Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-trust-assurance-framework_v1.1_final.pdf","content":"-- Fach VLEI Credential MUST be in compliance with its specific vLE| Credential Governance Framework __ e KERI'VLEI e\n3. Operations\nEach vLEI Credential MUST be chained to its source(s), if any, as required by the applicable vLEI Credential Governance Framework X; covered by KERI vLEI Credential\n3.1 in accordance with the ACDC specification. Operations\n5 Composable\nEvent .\nStreaming The Proof Format for vLEI credentials MUST comply with the CESR Proof Format specification. X; covered lg KERL,VLEI Credential\nerations\nRepresentation P\n(CESR) 1.\n6 Credential\nRegistry and . S . . . . . . . . . . .\n. Each vLEl credential Issuer MUST maintain a highly-available issuance and registration registry in compliance with the Public X; covered by KERI vLEI Credential\nRevocation . e . X .\nTransaction Event Log (PTEL) Specification. Operations\nRegistry\nRequirements |1.\n7 Exchange VLEI credential Issuers MUST comply with the Issuance Exchange Protocol Specification for ACDC and KERI. X X; covered by KERI,VLEI Credential\nProtocols 1 Operations\n","contentLength":1042,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:17:43.094Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-trust-assurance-framework_v1.1_final.pdf","content":"GLEIF verifiable LEI (VLEI) Ecosystem Governance Framework 1.0 Trust Assurance Framework Document Version 1.1 Final 2023-04-03\nVersion Date: 2023-04-03\nStatus: Final\n2. Official vLEI\nSchema Requirements\ni [The digest algorithm employed for generating schema SAIDs MUST have an spproximate cryptographic strength of 286 | x [ | | %\nI A Ve e i IR SR R R R S\n2. CESR encoding indicates the type of cryptographic digest used to generate the SAID.\nI A s AN T N I A\n3. official schema.\n[ e e S\nN A A IR S N I A\n1. backward incompatible version.\n- 0000000000000 r - -t 00000\nI e e O\nI e e e\ne e\nI e e O\ne I e e e\nI e e O\nI e e e\n- 0000000000000 r - -t 00000\nI e e O\nI e e e\ne e\nI e e O\ne I e e e\nI e e O\nI e e e\n- 0000000000000 r - -t 00000\nI e e O\nI e e e\ne e\nI e e O\ne I e e e\nI e e O\nI e e e\n- 0000000000000 r - -t 00000\nI e e O\nI e e e\ne e\n","contentLength":837,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:17:43.094Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-trust-assurance-framework_v1.1_final.pdf","content":"S verifiable LEI (VLEI) Ecosystem Governance Framework 1.0 Trust Assurance Framework Document Version 1.1 Final 2023-04-03\nVersion Date: 2023-04-03\nStatus: Final\nMUST' Statements GLEIF Identifiers (GLEIF Root AID, GLEIF Internal and External Delegated AIDs)\nAn AID conformant'mth this Governance Framework MUST be created from two sets of asymmetric signing key palrs generated X; requirement in GLEIF Identifier X; covered as part of KERI Key\n5 AID from a cryptographically-secure pseudo-random number generator (CSPRNG) or a true random number generator with at least Governance Framework Management\nGeneration 1. 128 bits of cryptographic strength. g\nThe AID MU'ST t'hen be derived from a cryptt')gra phic digest of a SEFIE'1|IZat{0'n of the publ'lc keys' of the first set of keY pairs a'nd a X; requirement in GLEIF Identifier X; covered as part of KERI Key\ncryptographic digest of second set of key pairs, as well as any other identifiers and configuration parameters associated with the Governance Framework Management\n2. supporting infrastructure for the Root Identifier as specified in the Technical Requirements Part 1 KERI Infrastructure. 8\nThe cryptographic digest MUST have at least 128 bits of cryptographic strength. X; requirement in GLEIF Identifier X; covered as part of KERI Key\n3. Governance Framework Management\n6 AID All Controllers MUST establish their own Private Key Store. X; requirement in GLEIF Identifier X; covered as part of KERI Key\nControllers 1. Governance Framework Management\nAll Controllers MUST keep their private keys secret. X; requirement in GLEIF Identifier\n2. Governance Framework\nA given Controller MUST control one and only one key pair from each set of keys. X; requirement in GLEIF Identifier X; covered as part of KERI Key\n3. Governance Framework Management\novernance Framewor process wi\n5 Cdontlnmty GLEIF MUST have a Continuity Policy for the survival of control authority of all Controllers for the GLEIF Root AID and its Delegated | X; requirement in GLEIF Identifier\nan AlIDs, including Escrow Agents. Governance Framework\nSurvivorship\n7 GLEIF AID GLEIF MUST establish a list of initial GLEIF Controllers that specifies:\nGenesis 1\novernance Framewor\nX; requirement in GLEIF Identifier\nWhich Controllers shall control the GLEIF Root AID, the GIDA and the GEDA. Governance Framework\nAset o'f policies MUST be put in place that ensure f'a uIt—toIerant':e with 'respect to comr'no'n mode. f'allures of the 'mult|—5|g signing X; requirement in GLEIF Identifier\nauthority of the set of GLEIF Controllers, e.g., a Designated Survivor policy and/or restrictions on joint travel and in-person\nA Governance Framework\nC. attendance of meetings).\nGLEIF MUST establish real-time Out-of-Band Interaction (OOBI) session(s) in which all initial GLEIF Controllers are present. An . . e\n. . . . | . . | . X; requirement in GLEIF Identifier\nexample is a continuous web meeting attended by all parties on both audio and video. The essential feature is that there is a Governance Framework\n2. mutual live presentation by all participants that verifies their live participation in the session.\novernance Framewor\nAll GLEIF'Controllers MUST r'nutually authe'ntlcate each other’s Ie'gal |(?ent|t|es bt?fore proceeding with any further 'steps. 'An X; requirement in GLEIF Identifier X; covered as part of KERI Identifier\nexample is each Controller visually presenting one or more legal identity credentials for all other Controllers to verify against the Governance Framework Operations\n3. list of initial GLEIF Controllers. P\n5. Creation of . . . . .\nThe following steps MUST be performed in the order listed and completed during each OOBI session for the GLEIF Root AID.\nGLEIF Root AID\nEach Root AID GLEIF Authorized Representative (Root GAR) MUST generate its own single signature AID that is a participating X; requirement in GLEIF Identifier X; covered as part of KERI Identifier\nmember in the group of AIDs that will be used to create the GLEIF Root AID. Governance Framework Operations\nEach Root GAR MUST use an OOBI proto'col (su'ch asa QR c'ot'ie o'r live chat) to share '|ts own A!D and Service Endpoints with the X; requirement in GLEIF Identifier X; covered as part of KER| Identifier\nother Root GARs. For each Root GAR, this provides the participating AID and the service endpoint whereby the other Root GARs Governance Framework Operations\nmay obtain the Key Event Log (KEL) of its participating AID. P\n","contentLength":4444,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:17:43.094Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-trust-assurance-framework_v1.1_final.pdf","content":"Each Root GAR MUST send a Challenge Message to every other Root GAR as defined in the Technical Requirements Part 1 for the | X; requirement in GLEIF Identifier X; covered as part of KERI Identifier\npurposes of cryptographic authentication of their Root GAR AID. The Challenge Message MUST be unique to each OOBI session. Governance Framework Operations\nc.\nEach Root GAR MUST verify in real time that a response to the Challenge Message was received from every other Root GAR. X; requirement in GLEIF Identifier X; covered as part O,f KERI Identifier\nGovernance Framework Operations\nEach Root GAR MUST verify the signature of every other Root GAR. X; requirement in GLEIF Identifier X; covered as part o'f KERI Identifier\nGovernance Framework Operations\nOne of the Root GARs MUST be designated as the Root AID GLEIF Authorized Representative Lead (Root GAR Lead). X; requirement in GLEIF Identifier X; covered as part O,f KERI Identifier\nf. Governance Framework Operations\nThe I'ioc'>t GAR Lead MUST select the AIDs from the' set of Root GARs for the ordered set'o'f authorized participant members in the X; requirement in GLEIF Identifier X; covered as part of KER| Identifier\nmulti-sig group and configure and approve the weight threshold and ordered set of participants for both the current and next set .\no Governance Framework Operations\nand threshold of participants.\nThe Root GAR Lead MUST select the AIDs and Service Endpoints for the GLEIF Root AID Witness Pool. X; requirement in GLEIF Identifier X; covered as part O,f KER| Identifier\nh. Governance Framework Operations\nUS'I ng the current public key and the next public key digest from each of the ;')artlupatlng AID IrTceptl'on Events and the Root X; requirement in GLEIF Identifier X; covered as part of KERI Identifier\nWitness AIDs, the Root GAR Lead MUST generate the GLEIF Root AID Inception Event and publish this to the Root GARs and to the .\n| ) . Governance Framework Operations\nRoot AID Witnesses designated by that Inception Event.\nEach Root GAR MUST verify the set of public keys, the next public key digest, the threshold, the next threshold and Root AID X; requirement in GLEIF Identifier X; covered as part of KERI Key\nWitness identifiers in the Root AID Inception Event. Governance Framework Management\nEach Root GAR MUST verify the set of service endpoints for the Root AID Witnesses. X; requirement in GLEIF Identifier X; covered as part O,f KERI Identifier\nk. Governance Framework Operations\nEach Root GAR MUST sign and publish to the Root AID Witnesses their signature on the Root AID Inception Event. X; requirement in GLEIF Identifier X; covered as part O,f KERI Identifier\nGovernance Framework Operations\nEach Root GAR MUST verify that the Root AID Inception Event is fully witnessed by every Root AID Witness. X; requirement in GLEIF Identifier X; covered as part O,f KERI Identifier\nm. Governance Framework Operations\n-- Fach Root GAR MUST verify that the Root AID Inception Event i ully witnessed by every Root AID Witness. ____\n6. Creation of | The following steps MUST be performed in the order listed and completed during each OOBI session for each of the two GLEIF\nGLEIF Internal |Delegated AIDs, namely, the GLEIF Internal Delegated AID (GIDA) in this section and the GLEIF External Delegated AID (GEDA) in\nDelegated AIDs |S€ction 7.\nEach Internal Delegated AID GLEIF Authorized Representative (Internal GAR) that is a participating member in the group of AIDs | X; requirement in GLEIF Identifier X; covered as part of KERI Identifier\nMUST generate its own single signature AID that will be used to create the GIDA. Governance Framework Operations\nEach Internal GAR MUST use an OOBI protocol (su'ch as 2'1 QR code or'Il've c'hat) to share its owr'1 AID and'Serwce Endpoints with X; requirement in GLEIF Identifier X; covered as part of KERI Identifier\nthe other Internal GARs. For each Internal GAR, this provides the participating AID and the service endpoint whereby the other .\n. ) L Governance Framework Operations\nInternal GARs may obtain the KEL of its participating AID.\nEach Internal GAR MUST send a Challenge Messag'e to every'oth'er Interna'l GAR as defined in the Technical Requlremer?ts Part1 X; requirement in GLEIF Identifier X; covered as part of KERI Identifier\nKERI Infrastructure for the purposes of cryptographic authentication of their GIDA. The Challenge Message MUST be unique to .\n| Governance Framework Operations\nc. each OOBI session.\nEach Internal GAR MUST verify in real time that a response to the Challenge Message was received from every other Internal X; requirement in GLEIF Identifier X; covered as part of KERI Identifier\nGAR. Governance Framework Operations\nEach Internal GAR MUST verify the signature of every other Internal GAR. X; requirement in GLEIF Identifier X; covered as part O,f KERI Identifier\nGovernance Framework Operations\nOne of the Internal GARs MUST be designated as the Internal Delegated AID GLEIF Authorized Representative (Internal GAR X; requirement in GLEIF Identifier X; covered as part of KERI Identifier\nf. Lead). Governance Framework Operations\nThe Internal GAR Lead MUST select the AIDs and Service Endpoints from the GLEIF Internal Delegated AID Witness Pool. X; requirement in GLEIF Identifier X; covered as part O,f KERI Identifier\nGovernance Framework Operations\nThe Interna'l (?‘AR Lead MUST se'lect the AIDs from the se\"c of Internal GARs for the ordered set'm'c authorized participant members X; requirement in GLEIF Identifier X; covered as part of KER| Identifier\nin the multi-sig group and configure and approve the weight threshold and ordered set of participants for both the current and .\nL Governance Framework Operations\nh. next set and threshold of participants.\nUsing the current public key and the next public key digest from each of the participating AID Inception Events, the Internal\nDelegated Witness AIDs, and the GLEIF Root AID, the Internal GAR Lead MUST generate the GLEIF Internal Delegated AID X; requirement in GLEIF Identifier X; covered as part of KERI Key\nInception Event and publish this to the Internal GARs and to the Delegated AID Witnesses designated by that Inception Event. The Governance Framework Management\npublished Inception Event includes as an attachment OOBIs for each of the Internal Delegated AID Witnesses.\n","contentLength":6314,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:17:43.094Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-trust-assurance-framework_v1.1_final.pdf","content":"Each Internal GAR MUST verify the set of public keys, the next public key digest, the Witness identifiers, the threshold, the next X; requirement in GLEIF Identifier X; covered as part of KERI Key\nthreshold and the Root AID in the Internal Delegated AID Inception Event. Governance Framework Management\nEach Internal GAR MUST verify the set of Witness endpoints for the GIDA. X; requirement in GLEIF Identifier X; covered as part O,f KER| Identifier\nk. Governance Framework Operations\nEach Internal GAR MUST sign and publish to the Internal Delegated AID Witnesses its signature on the Internal Delegated AID X; requirement in GLEIF Identifier X; covered as part of KERI Identifier\nInception Event. Governance Framework Operations\nEach Internal GAR MUST verify that the Internal Delegated AID Inception Event is fully witnessed by every Witness. X; requirement in GLEIF Identifier X; covered as part O,f KERI Identifier\nm. Governance Framework Operations\n7. Creation of\nGLEIF External\nDelegated AIDs\nEach External Delegated AID GLEIF Authorized Representative (External GAR) that is a participating member in the group of AIDs | X; requirement in GLEIF Identifier X; covered as part of KERI Identifier\nMUST generate its own single signature AID that will be used to create the GEDA. Governance Framework Operations\nEach External GAR MUST use an OOBI protocol (sut':h as a'QR code or I'|v'e ch'at) to share its own'AID and S'erwce Endpoints with X; requirement in GLEIF Identifier X; covered as part of KER| Identifier\nthe other External GARs. For each External GAR, this provides the participating AID and the service endpoint whereby the other .\n. | R Governance Framework Operations\nExternal GARs may obtain the KEL of its participating AID.\nEach External GAR MUST send a Challenge Messag'e to every' oth'er Extern'fll GAR as defined in the Technical Requlremer?ts Part 1 X; requirement in GLEIF Identifier X; covered as part of KER| Identifier\nKERI Infrastructure for the purposes of cryptographic authentication of their GEDA. The Challenge Message MUST be unique to .\n| Governance Framework Operations\nC. each OOBI session.\nEach External GAR MUST verify in real time that a response to the Challenge Message was received from every other External X; requirement in GLEIF Identifier X; covered as part of KERI Identifier\nGAR. Governance Framework Operations\nEach External GAR MUST verify the signature of every other External GAR. X; requirement in GLEIF Identifier X; covered as part O,f KER| Identifier\nGovernance Framework Operations\nOne of the External GARs MUST be designated as the External Delegated AID GLEIF Authorized Representative Lead (External X; requirement in GLEIF Identifier X; covered as part of KERI Identifier\nf. GAR Lead). Governance Framework Operations\nThe External GAR Lead MUST select the AIDs and Service Endpoints from the GLEIF External Delegated AID Witness Pool. X; requirement in GLEIF Identifier X; covered as part O,f KER| Identifier\nGovernance Framework Operations\nThe Extern'al GAR Lea'd MUST select the A'IDs from the set of Exterr?al GARs for the ordered set of author'lz'ed participant X; requirement in GLEIF Identifier X; covered as part of KERI Identifier\nmembers in the multi-sig group and configure and approve the weight threshold and ordered set of participants for both the .\ne Governance Framework Operations\nh. current and next set and threshold of participants.\nUsing the current public key and the next public key digest from each of the participating AID Inception Events, the External\nDelegated Witness AIDs, and the GLEIF Root AID, the External GAR Lead MUST generate the GLEIF External Delegated AID X; requirement in GLEIF Identifier X; covered as part of KERI Key\nInception Event and publish this to the External GARs and to the Delegated AID Witnesses designated by that Inception Event. The Governance Framework Management\npublished Inception Event includes as an attachment OOBIs for each of the External Delegated AID Witnesses.\nEach External GAR MUST verify the set of public keys, the next public key digest, the Witness identifiers, the threshold, the next X; requirement in GLEIF Identifier X; covered as part of KERI Key\nthreshold and the Root AID in the External Delegated AID Inception Event. Governance Framework Management\nEach External GAR MUST verify the set of Witness endpoints for the GEDA. X; requirement in GLEIF Identifier X; covered as part O,f KERI Identifier\nk. Governance Framework Operations\nEach External GAR MUST sign and publish to the External Delegated AID Witnesses their signature on the External Delegated AID | X; requirement in GLEIF Identifier X; covered as part of KERI Identifier\nInception Event. Governance Framework Operations\nEach External GAR MUST verify that the External Delegated AID Inception Event is fully witnessed by every Witness. X; requirement in GLEIF Identifier X; covered as part O,f KERI Identifier\nm. Governance Framework Operations\n8. Rotation The following steps MUST be performed in the order listed and completed during this OOBI session for each of the two GLEIF\nEvent to Delegated AlDs, namely, the GLEIF Internal Delegated AID (GIDA) in this section and the GLEIF External Delegated AID (GEDA) in\ndelegate the section 9.\nGLEIF Internal\nDelegated AIDs\nA threshold satisficing subset of Internal GARs MUST each rotate their participating AlDs. X; requirement in GLEIF Identifier X; covered as part O,f KERI Identifier\nGovernance Framework Operations\nUsing the current public key, the ne)ft public key digest from each of the participating AID Rotation Events, and the digests 'of the X; requirement in GLEIF Identifier X; covered as part of KERI Key\nGLEIF Internal Delegated AID Inception Event, the Internal GAR Lead MUST generate a GLEIF Internal Delegated AID Rotation\n) | ] N Governance Framework Management\nEvent and publish this to the other participating Internal GARs and to the Root AID Witnesses.\n","contentLength":5932,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:17:43.094Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-trust-assurance-framework_v1.1_final.pdf","content":"Each Internal GAR MUST verify the set of public keys, the next public key digest, and delegated Inception Event digests in that X; requirement in GLEIF Identifier X; covered as part of KERI Key\nC. Rotation Event. Governance Framework Management\nEach Internal GAR MUST sign and publish to the Root AID Witnesses their signature on the Root AID Rotation Event. X; requirement in GLEIF Identifier X; covered as part O,f KER| Identifier\nGovernance Framework Operations\nEach Internal GAR MUST verify that the Root AID Rotation Event is fully witnessed by every Root AID Witness. X; requirement in GLEIF Identifier X; covered as part O,f KER| Identifier\nGovernance Framework Operations\n9. Rotation The following steps MUST be performed in the order listed and completed during this OOBI session for each of the two GLEIF\nEvent to Delegated AlDs, namely, the GLEIF Internal Delegated AID (GIDA) in section 8 and the GLEIF External Delegated AID (GEDA) in this\ndelegate the section.\nGLEIF External\nDelegated AIDs\nA threshold satisficing subset of External GARs MUST each rotate their participating AIDs. X; requirement in GLEIF Identifier X; covered as part O,f KERI Identifier\nGovernance Framework Operations\nUsing the current public key, the nex't public key digest from each of the participating AID Rotation Events, and the digests o'f the X; requirement in GLEIF Identifier X; covered as part of KERI Key\nGLEIF External Delegated AID Inception Event, the External GAR Lead MUST generate a GLEIF External Delegated AID Rotation\n. i L A Governance Framework Management\nEvent and publish this to the other participating External GARs and to the Root AID Witnesses.\nEach External GAR MUST verify the set of public keys, the next public key digest, and delegated Inception Event digests in that X; requirement in GLEIF Identifier X; covered as part of KERI Key\nC. Rotation Event. Governance Framework Management\nEach External GAR MUST sign and publish to the Root AID Witnesses their signature on the Root AID Rotation Event. X; requirement in GLEIF Identifier X; covered as part O,f KERI Identifier\nGovernance Framework Operations\nEach External GAR MUST verify that the Root AID Rotation Event is fully witnessed by every Root AID Witness. X; requirement in GLEIF Identifier X; covered as part O,f KERI Identifier\nGovernance Framework Operations\n8 Publication\nof GLEIF Root The GLEIF Root AID and GLEIF Delegated Internal and External AIDs MUST be published in a sufficiently strongly correlated and X; requirement in GLEIF Identifier\nAID and GLEIF fault-tolerant manner to establish it as the unique AID for GLEIF. Governance Framework\nDelegated\nAlDs 1.\nThe set of publication points MUST include at least 4 of the list of publication points initially (highlighted below) following the X; requirement in GLEIF Identifier\n2. creation of the GLEIF Root AID and GLEIF Delegated Internal and External AIDs. Governance Framework\nThe GLEIF HTTPS website. X; requirement in GLEIF Identifier\nGovernance Framework\nThe HTTPS website of the GLEIF Regulatory Oversight Committee. X; requirement in GLEIF Identifier\nGovernance Framework\nThe HTTPS websites of all QVIs. X; requirement in GLEIF Identifier\nC. Governance Framework\nIn the KERI Event Log hosted by GLEIF KERI Witnesses. X; requirement in GLEIF Identifier\nGovernance Framework\nPublished to at least 3 international newspapers in separate national jurisdictions (applies only to GLEIF Root AID). These X; requirement in GLEIF Identifier\npublications are: Financial Times UK edition, South China Morning Post - Business and American Banker. Governance Framework\nPublished to github repositories: The Web of Trust github repository, Public GLEIF-controlled github repository X; requirement in GLEIF Identifier\nf. Governance Framework\nPublished to public registries: IANA (IETF RFCs) registries, ISO registries X; requirement in GLEIF Identifier\nGovernance Framework\n9 Voluntary abandonment\nAbandonment |1.\nGLEIF MUST abandon its GLEIF Root AID if GLEIF no longer holds the role of root of trust for the vLEI Ecosystem. X; requirement in GLEIF Identifier\nGovernance Framework\n| Ja. [private Key Compromise or Natural Disaster 0]\nIf in the extremely unlikely event of tr'1e failure of all key recovery provisions specified in Technical Requlrement's. Pz?rt 1: KERI X; requirement in GLEIF Identifier X; covered as part of KER| Identifier\nInfrastructure, GLEIF MUST abandon its Root AID and Delegated Internal and External AlDs and create and publish its new Root .\nGovernance Framework Operations\nAID and Delegated Internal and External AlDs.\n","contentLength":4581,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:17:43.095Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-trust-assurance-framework_v1.1_final.pdf","content":"GLEIF verifiable LEI (VLEI) Ecosystem Governance Framework 1.0 Trust Assurance Framework Document Version 1.1 Final 2023-04-03\nVersion Date: 2023-04-03\nStatus: Final\n6 Issuer\nPolicies\n. . . X; assessment and demonstration of\nL X; requirement in Credential A o\n6.1 The Issuer MUST ensure that the Issuer of the QVI vLEI Credential is GLEIF. Governance Framework compliance for Qualified vLEI Issuer and\nQualifications |1. GLEIF\n62Credential | [The lssuer MUST: e e\n. . . X; assessment and demonstration of\n. . . . X; requirement in Credential \" . . .\nuse the QVI vLEI Credential schema defined in section 10.1. Governance Framework compliance for Qualified vLEI Issuer and X; Credential format in KERI code\n1. GLEIF\n. . . X; assessment and demonstration of\n. . . . . X; requirement in Credential A \" . .\ninclude the Claims marked as Required in section 10.1. compliance for Qualified vLEI Issuer and X; Credential format in KERI code\nGovernance Framework\n2. GLEIF\n6.3 QVl\nIdentity 1. Identity\nVerification |Assurance\nAn Externa I' GLEIF Authorlzeq Representative (Externa I' GAR) MUST perform identity asst'Jranc'e of a person serving in the role of X; requirement in Credential X; assessment and demonstration of\nQVI Authorized Representative (QAR) to at least Identity Assurance Level 2 (IAL2) as defined in NIST 800-63A R\ni Governance Framework compliance for GLEIF\n(https://pages.nist.gov/800-63-3/sp800-63a.html).\nA minimum of two QARs MUST form the QVI multi-sig group. X; requirement in Credential X; asse'ssment and dt'er'nonstratlon of X; co'vered as part of tht'e Credential\nGovernance Framework compliance for Qualified vLEI Issuer issuance process with KERI\nAn External GAR MUST lead for the anchoring action for the QVI External Delegated AID described below. X; requirement in Credential X; assessment' and demonstration of\nC. Governance Framework compliance for GLEIF\n2. |dentity\nAuthentication\nA credential wallet MUST be set up for the QVI. X; requirement in Credential X; asse'ssment and dt'er'nonstratlon of\nGovernance Framework compliance for Qualified vLEI Issuer\nThe QVI MUST designate a QAR to act on its behalf. X; requirement in Credential X; asse'ssment and dt'er'nonstratlon of\nGovernance Framework compliance for Qualified vLEI Issuer\nAn External GAR and the QAR MUST establish a real-time OOBI session in which the External GAR and the QAR are present. An X; requirement in Credential X as'sessment and'd'emonstratlon of\n. . . . . . compliance for Qualified vLEI Issuer and\nexample is a continuous web meeting attended by all parties on both audio and video. Governance Framework GLEIF\n[\n. . . X; assessment and demonstration of\n. . . . . . X; requirement in Credential A o\nThe following steps MUST be performed in this order and completed during this OOBI session. Governance Framework compliance for Qualified vLEI Issuer and\nGLEIF\nThe External GAR MUST perform manual verification of the QAR’s legal identity for which the External GAR has already i . . .\n. . . . . . . X; requirement in Credential X; assessment and demonstration of\nperformed Identity Assurance. An example is the QAR visually presenting one or more legal identity credentials and the External i\n. . . . Governance Framework compliance for GLEIF\nGAR compares the credentials verified during Identity Assurance to the QAR Person.\nThe External GAR MUST use an OOBI protocol (such as a QR code or live chat) to share the GLEIF External Delegated AID (GEDA) X; requirement in Credential X; assessment and demonstration of\nwith the QAR. Governance Framework compliance for GLEIF\n. . X; requirement in Credential X; assessment and demonstration of\nAn QAR MUST use an OOBI protocol (such as a QR code or live chat) to share the QVI AID with the External GAR. A .\nGovernance Framework compliance for Qualified vLEI Issuer\nThe External GAR MUST send a Challenge Message from the GEDA to the QVI AID as defined in the Technical Requirements Part . . . . .\nA . ) X; requirement in Credential X; assessment and demonstration of X; covered as part of the Credential\n1 KERI Infrastructure for the purposes of cryptographic authentication of the QVI AID. The Challenge Message MUST be unique to R . .\n. the 0OBI . Governance Framework compliance for GLEIF issuance process with KERI\niv. e session.\n","contentLength":4283,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:17:43.095Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-trust-assurance-framework_v1.1_final.pdf","content":"The QAR MUST use its Private Key Store to sign and return the response to the Challenge Message, after which the QAR MUST X; requirement in Credential X; assessment and demonstration of X; covered as part of the Credential\nV. acknowledge that this action has been completed. Governance Framework compliance for Qualified vLEI Issuer issuance process with KERI\nThe External GAR must verify in real time that the response to the Challenge Message was received from the QAR. X; requirement in Credential X; assessment' and demonstration of X; cc'>vered as part of th? Credential\nVi. Governance Framework compliance for GLEIF issuance process with KERI\nWhen the response to the Challenge Message has been received, the External GAR must verify the signature of the QAR. X; requirement in Credential X; assessmen\"c and demonstration of\nvii. Governance Framework compliance for GLEIF\n6.4 Creation X; assessment and demonstration of\nof the QVI The creation of the QVI Delegated AIDs follows the successful completion of Identity Verification by the External GAR Lead of X; requirement in Credential s o\ncompliance for Qualified vLEI Issuer and\nDelegated each QAR. Governance Framework GLEIF\nAlIDs 1.\nThe following steps MUST be performed in the order listed and completed during an OOBI session for a given QVI Delegated AID. X; requirement in Credential X; asse'ssment and d'er\"nonstratlon of\n2. Governance Framework compliance for Qualified vLEI Issuer\nEach Delegated AID QVI Authorized Representative (QAR) that is a participating member in the group of AIDs MUST generate its X; requirement in Credential X; assessment and demonstration of\nown individual single signature AID that will be used to create the QVI Delegated AID. Governance Framework compliance for Qualified vLEI Issuer\nEach QAR MUST use an OOBI protocol (such as a QR code or live chat) to share its own AID with the other QAR s. For each QAR, X; requirement in Credential X; assessment and demonstration of\nthis provides the participating AID and the service endpoint whereby the other QARs may obtain the KEL of its participating AID. Governance Framework compliance for Qualified vLEI Issuer\nEach QAR MUST send a Challenge Message tc'> every oth'er QAR as de'f|r'1ed'|r'1 the T'echnlc'al Requirements Part 1 KERI X; requirement in Credential X; assessment and demonstration of\nInfrastructure for the purposes of cryptographic authentication of their individual single signature AID. The Challenge Message R o\nA N Governance Framework compliance for Qualified vLEI Issuer\nC. MUST be unique to the OOBI session.\nEach QAR must verify in real time that a response to the Challenge Message was received from every other QAR. X; requirement in Credential X; asse'ssment and d'er\"nonstratlon of\nGovernance Framework compliance for Qualified vLEI Issuer\nEach QAR must verify the signature of every other QAR. X; requirement in Credential X; asse'ssment and d'er\"nonstratlon of\nGovernance Framework compliance for Qualified vLEI Issuer\nOne of the QARs must be designated as the Delegated AID QVI Authorized Representative (QAR Lead). X; requirement in Credential X; asse'ssment and d'er\"nonstratlon of\nf. Governance Framework compliance for Qualified vLEI Issuer\n. . . . . X; requirement in Credential X; assessment and demonstration of\nThe QAR Lead MUST either configure or select the AIDs and Service Endpoints for the QVI Delegated AID Witness Pool. i o\nGovernance Framework compliance for Qualified vLEI Issuer\nThe QAR Lead MUST select the AIDs from the set of QARs for the ordered set of authorized participant members in the multi-sig i . . .\n) . . X; requirement in Credential X; assessment and demonstration of\ngroup and configure and approve the weight threshold and ordered set of participants for both the current and next set and R o\n. Governance Framework compliance for Qualified vLEI Issuer\nh. threshold of participants.\nUs.'lng the current public key and the next public key digest from each of the participating {-\\ID Inception Even\"cs, the' Delegated X; requirement in Credential X; assessment and demonstration of\nWitness AIDs, and the GEDA, the QAR Lead MUST generate the QVI Delegated AID Inception Event and publish this to the other R .\n) N A Governance Framework compliance for Qualified vLEI Issuer\nQARs and to the Delegated AID Witnesses designated by that Inception Event.\nEach QAR MUST verify the set of public keys, the next public key digest, the Witness identifiers, the threshold, the next threshold, X; requirement in Credential X; assessment and demonstration of\nand the GEDA in the Delegated AID Inception Event. Governance Framework compliance for Qualified vLEI Issuer\nEach QAR MUST verify the set of Witness endpoints for the QVI Delegated AID. X; requirement in Credential X asse'ssment and d'er\"nonstratlon of\nk. Governance Framework compliance for Qualified vLEI Issuer\nEach QAR MUST sign and publish to the Delegated AID Witnesses their signature on the Delegated AID Inception Event. X; requirement in Credential X asse'ssment and d'er\"nonstratlon of\nGovernance Framework compliance for Qualified vLEI Issuer\nEach QAR MUST verify that the Delegated AID Inception Event is fully witnessed by every Witness. X; requirement in Credential X asse'ssment and d'er\"nonstratlon of\nm. Governance Framework compliance for Qualified vLEI Issuer\nGLEIF MUST designate one of the External Delegated AID GLEIF Authorized Representative (External GARs) as the External X; requirement in Credential X aisessr:en;an(li'gedmolls.ltlratlon Ofd\nDelegated AID GLEIF Authorized Representative (External GAR Lead). Governance Framework compliance tor ;T_IL_IIFe v ssueran\n6.5\nDelegation of Unless otherwise pre-approved by the GLEIF Root GARs, GLEIF External AID MUST use an Interaction Event to approve the X; requirement in Credential X; as.'sessment and'd'emonstratlon of\nthe QVI . compliance for Qualified vLEl Issuer and\ndelegation of the QVI Delegated AlDs. Governance Framework\nDelegated GLEIF\nAlIDs 1.\nThe following steps MUST be performed in the order listed and completed during this OOBI session for the GLEIF External X; requirement in Credential X; as.'sessment and'd'emonstratlon of\ncompliance for Qualified vLEI Issuer and\nDelegated AID (GEDA). Governance Framework\n2. GLEIF\nThe QAR Lead initiates a set of QARs to create a multi-sig group and the QARs mutually are authenticated. X; requirement in Credential X asse'ssment and d'er\"nonstratlon of\nGovernance Framework compliance for Qualified vLEI Issuer\n","contentLength":6497,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:17:43.095Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-trust-assurance-framework_v1.1_final.pdf","content":"GLEIF MUST publish the vLEI Ecosystem Governance Framework on gleif.org and follow the policies in the Revisions section for all X; gleif.org section for vLEI\n5 revisions of the VvLEI Ecosystem Governance Framework. Ecosystem Governance Framework\nVLEIs MUST be revocable following the policies specified in vLEI Ecosystem Governance Framework. X; GLEIF revocatlon of 'Crefientlals X; Qualified VI,'EI Issue'r revocation of X; KERI revocation functionality\nservice level monitoring Credentials service levels\nQVIs MUST ensure that third-parties comply with the vLEI Ecosystem Governance Frameworks when providing vLE| services to a X; documentation provided by Qualified\n; QVl. VLEI Issuers\nAt a minimum, the vLEl Ecosystem Governance Framework MUST be reviewed annually. | XGlEFprocessmonitoring | 00000000000\nAll revisions to the Primary Document MUST be identified with a revision number that is a sequential integer. X; compliant to Documented\n3.a. Information Procedure\nX; Document approvals follow the\nAll revisions to Controlled Documents MUST be identified with a revision number that is a sequential integer. defined Documented Information\nProcedure\n. I X; Document approvals follow the\nAll revisions to the VvLEI Ecosystem Governance Framework MUST be approved by GLEIF using its Change Management Process. i i\ndefined Documented Information\n5. Procedure\nBusiness There MUST be availability targets defined for all vLEI services included in the Appendix 5 of the vLE| Issuer Qualification X; GLEIF availability targets X; Qualified vLEI Issuer availability\nRequirements |3. Agreement (SLA). documented in SLA targets documented in SLA\nThe QVI MUST be solely responsible for managing the revenue that is produced and costs that are incurred in the running of its , ),(; O\"u?llfled VLElIssuer p'roof of\n. business' management during Annual\nVLEI operations. L\n5. VLEI Issuer Qualification\nX; Qualified VvLEI Issuer proof of\nThe QVI MUST ensure that its operations regarding vLEls are sustainably financed. 'business' management during Annual\nVLEI Issuer Qualification\nGLEIF MUST not contribute funds of any form whatsoever for QVI operations. X; no e'vidence of receipt of funds by\n7. Qualified vLEI Issuers from GLEIF\nInclusion,\nEquitability . .\n. . L . X; Services are defined and\nand GLEIF MUST design the vLEI Ecosystem to be able to make vLEls available to any Legal Entity issued a LEIl in the Global LEI System. . . . .\n- integrated in existing Service\nAccessibility ¥ ¢ Syst\nRequirements |N/A anagement system\n","contentLength":2523,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:17:43.095Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-trust-assurance-framework_v1.1_final.pdf","content":"The QAR Lead initiates the creation of the Inception Event using the published GLEIF External AID as the Delegator. X; requirement in Credential X asse'ssment and d'er\"nonstratlon of\nGovernance Framework compliance for Qualified vLEI Issuer\nThe External GAR Lead verifies that the set of QARs in the multi-sig group in this Inception Event to delegate the QVI External AID X; requirement in Credential X as.'sessment and'd'emonstratlon of\ne . . compliance for Qualified vLEI Issuer and\nmatch those that the External GAR Lead verified according to section 6.3 above. Governance Framework GLEIF\nc.\nThe External GAR Lead submits request to the External GAR multi-sig group to anchor the Interaction event. All members of the X: requirement in Credential X; assessment and demonstration of\nExternal GAR multi-sig group trust External GAR Lead to anchor because the External GARs already have trusted the External GAR ! ch/ernance Framework compliance for Qualified vLEl Issuer and\nLead to perform Identity Assurance on the QARs. GLEIF\nThe External GAR Lead then submits a request to issue the Qualified VLEI Issuer VLEI Credential to QVI vLEI to the External GAR X; requirement in Credential X; as.'sessment and'd'emonstratlon of\nN . compliance for Qualified vLEI Issuer and\nmulti-sig group as an Interaction Event. Governance Framework GLEIE\n6.6 QVI vLEI The External GAR MUST approve issuance of a QVI vLEI Credential after the completion of QVI Identity Verification in section 6.3 X; requirement in Credential X; as.'sessment and'd'emonstratlon of\nCredential compliance for Qualified vLEI Issuer and\nabove. Governance Framework\nIssuance 1. GLEIF\n6.7 QVI VLEI\nCredential 1. Voluntary\nRevocation Revocation\nAn External GAR MUST revoke a Legal Entity vLEI Credential upon receipt of a Fully Signed revocation request by the QAR(s ) of X; requirement in Credential X; as.'sessment and'd'emonstratlon of X; covered as part of the Credential\n. . . . . . compliance for Qualified vLEI Issuer and . .\nthe Legal Entity, e.g., if the Legal Entity chooses to no longer be the Holder of this Credential using the vLEI software. Governance Framework GLEIF revocation process with KERI\n. . . X; assessment and demonstration of\n. L . o . . X; requirement in Credential A o\nAn External GAR MUST perform the revocation within the timeframe specified in Appendix 5, Service Level Agreement (SLA). compliance for Qualified vLEI Issuer and\nGovernance Framework\nGLEIF\n. . . X; assessment and demonstration of\nX; requirement in Credential A o\n2. Involuntary compliance for Qualified vLEl Issuer and\nGovernance Framework\nRevocation GLEIF\nInvoluntary revocation of vLEI Credentials MUST follow the process specified in Appendix 5, Service Level Agreement (SLA). X; requirement in Credential X; assessmen\"c and demonstration of\nGovernance Framework compliance for GLEIF\n7 QVI Self- . . . X; assessment and demonstration of\n. L X; requirement in Credential A \"\nissuance of GLEIF MUST oversee the assignment of these vLEI Credentials issued by QVIs to themselves. compliance for Qualified vLEI Issuer and\nGovernance Framework\nVLEIs 2. GLEIF\n9 Verifier When part of a chain, each chained vLEI MUST include a reference to one or more preceding VLEls in its provenance chain. X; requirement in Credential\nPolicies 2. Governance Framework\nIf any preceding vLEls in the provenance chain or a given VLEI is revoked, then that given vLEI MUST not verify. X; requirement in Credential\n3. Governance Framework\nThe schema for each type of vLEI defines what type or types of vLEIs MUST or MAY be referenced in its provenance section. X; requirement in Credential\nGovernance Framework\n10 Credential\nDefinition\nThe OOR VLEI Credential MUST be an Authentic Chained Data Container (ACDC) that MUST use for its schema at the time of . . .\nA A X; requirement in Credential\nissuance, the JSON Schema found in: Governance Framework\n10.1 Schema |1. https://github.com/WebOfTrust/vLEl/blob/dev/schema/acdc/qualified-vLEI-issuer-vLEI-credential .json\nThe field values in the credential MUST be as follows: X; requirement in Credential\n2. Governance Framework\nR X; requirement in Credential\nThe \"LEI\" field value MUST be the LEI of the QVI.\nGovernance Framework\nThe \"gracePeriod\" field value MUST be at least 90 (ninety) Days. X; requirement in Credential\nGovernance Framework\n","contentLength":4327,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:17:43.095Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-trust-assurance-framework_v1.1_final.pdf","content":"GLEIF verifiable LEI (VLEI) Ecosystem Governance Framework 1.0 Trust Assurance Framework Document Version 1.1 Final 2023-04-03\nVersion Date: 2023-04-03\nStatus: Final\n6 Issuer\nPolicies\n| [ [ThelssuermMusT: e e e\n6.1 be a Qualified vLEl Issuer (QVI) in the vLEl Ecosystem with qualification up to date. X; requirement in Credential X assetss'ment and demonstre'ltlon of\nQualifications |1. Governance Framework Qualified vLEI Issuer compliance\nfollow all of the requirements specified in the vLEl Issuer Qualification Agreement. X; requirement in Credential X assetss'ment and demonstre'ltlon of\n2. Governance Framework Qualified vLEI Issuer compliance\nuse the vLE| software for hosting Witnesses, Watchers and for Key Management. X; requirement in Credential X assetss'ment and demonstre'ltlon of\n3. Governance Framework Qualified vLEI Issuer compliance\n| [ [The IssuerMuST: - r - ]\nuse the Legal Entity vLEI Credential schema defined in section 8.1. X; requirement in Credential X assetss'ment and demonstre'ltlon of X; Credential format in KERI code\n6.2 Credential |1. Governance Framework Qualified vLEI Issuer compliance\ninclude the Claims marked as Required in section 8.1. X; requirement in Credential X assetss'ment and demonstre'ltlon of X; Credential format in KERI code\n2. Governance Framework Qualified vLEI Issuer compliance\n6.3 Legal Entity\nIdentity 1. Identity\nVerification Assurance\nA QVI Authorized Representative (QAR) MUST verify that the LEI supplied for the Credential is the LEI of the Legal Entity for which X; requirement in Credential X; assessment and demonstration of\nthe issuance request for the Credential has been made. Governance Framework Qualified vLEI Issuer compliance\nA QAR MUST verify the Legal Entity Identifier (LEI) of the Legal Entity has an entity status of Active and an LEI registration status X; requirement in Credential X; assessment and demonstration of\nother than Lapsed, Retired, Duplicate, Annulled or Merged (will be deprecated in March 2022) in the Global LEI System. Governance Framework Qualified vLEI Issuer compliance\nA QAR MUST perform identity assurance of a person serving in the role of a Legal Entity Authorized Representative (LAR) to at\nleast Identity Assurance Level 2 (IAL2) as defined in NIST 800-63A (https://pages.nist.gov/800-63-3/sp800-63a.html). Even when X; requirement in Credential X; assessment and demonstration of\nIAL2 is used for Identity Assurance, a real-time OOBI session is required as specified 2.b. below (essentially including the IAL3 Governance Framework Qualified vLEI Issuer compliance\nc requirement for a Supervised Remote In-person session).\n2. Identity\nAuthentication\n. . X; requirement in Credential\nA credential wallet MUST be set up for the Legal Entity and for each LAR.\nGovernance Framework\nThe Legal Entity MUST designate a set of one or more LARs to act on its behalf. X; requirement in Credential\nGovernance Framework\nA QAR and the LARs MUST establish a real-time OOBI session in which the QAR and all LARs are present. An example is a X; requirement in Credential X; assessment and demonstration of\n[ continuous web meeting attended by all parties on both audio and video. Governance Framework Qualified vLEI Issuer compliance\nThe following steps MUST be performed in this order and completed during this OOBI session. X; requirement in Credential X; assetss'ment and demonstre'ltlon of\nGovernance Framework Qualified vLEI Issuer compliance\nThe QAR MUST perform' manual vernflcatlon of each LAR’s legal identity ft')r wh'lch the QA'R has already performed Identity X; requirement in Credential X; assessment and demonstration of\nAssurance. An example is each LAR visually presenting one or more legal identity credentials and the QAR compares the - .\nB o i , Governance Framework Qualified vLEI Issuer compliance\ncredentials verified during Identity Assurance to the LAR Person.\nThe QAR MUST use an OOBI protocol (such as a QR code or live chat) to share the QVI Autonomic Identifier (AID) with the LARs. X; requirement in Credential X; assetss'ment and demonstre'ltlon of\nGovernance Framework Qualified vLEI Issuer compliance\nA LAR MUST use an OOBI protocol (such as a QR code or live chat) to share the Legal Entity AID with the QAR. X; requirement in Credential\nGovernance Framework\n","contentLength":4285,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:17:43.095Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-trust-assurance-framework_v1.1_final.pdf","content":"The QAR MUST send a Challenge Message to the Legal Entity AID as defined in the Technical Requirements Part 1 for the X; requirement in Credential X; assessment and demonstration of X; covered as part of the Credential\n. purposes of cryptographic authentication of the Legal Entity AID. The Challenge Message MUST be unique to the OOBI session. Governance Framework Qualified vLEI Issuer compliance issuance process with KERI\niv.\nEach LAR MUST use its Private Key Store to sign and return a response to the Challenge Message, after which the LAR MUST X; requirement in Credential X; assessment and demonstration of X; covered as part of the Credential\nV. acknowledge that this action has been completed. Governance Framework Qualified vLEI Issuer compliance issuance process with KERI\nThe QAR MUST verify in real time that a response to the Challenge Message was received from each LAR. X; requirement in Credential X; asse:ssjment and demonstrz'ltlon of\nVi. Governance Framework Qualified vLEI Issuer compliance\nWhen all responses to Challenge Messages sufficient to satisfy the multi-sig threshold have been received, the QAR MUST verify X; requirement in Credential X; assessment and demonstration of X; covered as part of the Credential\nVii. the complete set of signatures. Governance Framework Qualified vLEI Issuer compliance issuance process with KERI\nThe Legal Entity Identity Verification process outlined in section 6.3 MUST be completed before Legal Entity vLEI Credential X; requirement in Credential\n6.4 Issuance 1. issuance can begin. Governance Framework\nIn a'ddltlon, a work'flow MUST be |mplemer'1ted in the c'>perat|ons of the QYI which ret'qulr'es, prior to issuing and :<.|gn'|ng an Legal X; requirement in Credential X; assessment and demonstration of\nEntity vLEI Credential, that the above-mentioned Identity Assurance, Identity Authentication and out-of-band validations are e R\nA A 3 i Governance Framework Qualified vLEI Issuer compliance\n2. performed by a QAR. Another QAR then approves the issuance and signs the Legal Entity vLEI Credential.\nQVIs MUST call the vLEI Reporting APl with each issuance event of Legal Entity vLEI Credentials. X; requirement in Credential X; asse:ssjment and demonstrz'ltlon of\n3. Governance Framework Qualified vLEI Issuer compliance\nGLEIF MUST update the list of vLEI Credentials on the LEI page of the Legal Entity to reflect Legal Entity vLE| credential issuances X; requirement in Credential X; assessment and demonstration of\nthat have been reported by QVIs. Governance Framework GLEIF compliance\n1. Voluntary\n6.5 Revocation |Revocation\nA QAR MUST revoke a Legal Entity vLEI Credential upon receipt of a Fully Signed revocation request by the LAR(s) of the Legal X; requirement in Credential X; assessment and demonstration of X; covered as part of the Credential\nEntity, e.g., if the Legal Entity chooses to no longer be the Holder of this Credential. Governance Framework Qualified vLEI Issuer compliance revocation process with KERI\nA QAR MUST perform the revocation within the timeframe specified in Appendix 5, Service Level Agreement (SLA). X; requirement in Credential X; asse:ssjment and demonstrz'ltlon of\nGovernance Framework Qualified vLEI Issuer compliance\n. . o . . X; requirement in Credential X; assessment and demonstration of\nInvoluntary revocation of vLEI Credentials MUST follow the process specified in Appendix 5, Service Level Agreement (SLA). - .\n) Governance Framework Qualified vLEI Issuer compliance\nA QAR MUST call the vLEI Reporting APl with each revocation event of Legal Entity vLEI Credentials. X; requirement in Credential X; asse:ssjment and demonstrz'ltlon of\nGovernance Framework Qualified vLEI Issuer compliance\n3.\nGLEIF MUST update the list of vLEI Credentials on the LEI page of the Legal Entity to reflect vLEI credential revocations that have X; requirement in Credential X; assessment and demonstration of\nbeen reported by QVIs. Governance Framework GLEIF compliance\nThe QAR SHOULD remove the LEI of the Legal Entity from the process to monitor the status of LEls used within vLEls. X; requirement in Credential X; asse:ssjment and demonstrz'ltlon of\n5. Governance Framework Qualified vLEI Issuer compliance\n9 Credential\nDefinition\nThe Legal Entity vLEI Credential MUST be an Authentic Chained Data Container (ACDC) that MUST use for its schema at the time . . .\n, N X; requirement in Credential . .\nof issuance, the JSON Schema found in: X; Credential format in KERI code\n) . L Governance Framework\n9.1 Schema 1. https://github.com/WebOfTrust/vLEl/blob/dev/schema/acdc/legal-entity-vLEIl-credential.json\nThe field values in the credential MUST be as follows: X; requirement in Credential X; Credential format in KERI code\n2. Governance Framework\n\"LEI\" field value MUST be the LEI of Legal Entity Holder. X; requirement in Credential X; Credential format in KERI code\nGovernance Framework\nThe Sources section MUST contain a source reference to the Qualified vLEl Issuer vLEI Credential of the QVI that issued this Legal X; requirement in Credential . .\n3 N X; Credential format in KERI code\n3. Entity vLEI Credential. Governance Framework\n","contentLength":5143,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:17:43.095Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-trust-assurance-framework_v1.1_final.pdf","content":"GLEIF verifiable LEI (vLEI) Ecosystem Governance Framework 1.0 Trust Assurance Framework Document Version 1.1 Final 2023-04-03\nVersion Date: 2023-04-03\nStatus: Final\ne 1 I e e O\n6.1 The Issuer MUST be a LAR of a Legal Entity that holds a valid Legal Entity vLEI Credential that was issued by the QVI with which X; requirement in Credential\nQualifications 1. the Legal Entity has contracted to issue vLEI Role Credentials. Governance Framework\n6.2 Credential The Issuer MUST: - v 0 000000\nuse the QVI AUTH VLEI Credential schema defined in sections 9.1 and 9.2 for authorizing the associated OOR vLEIl or ECR VLE| X; requirement in Credential\n1. AUTH credentials respectively. Governance Framework\ninclude the Claims marked as Required in the schema indicated in 9.1 and 9.2. X; requirement in Credential\n2. Governance Framework\n6.3 Identity 1. Identity\nVerification Assurance\nA LAR MUST perform identity assurance of an OOR Person or ECR Person designated by the Legal Entity to receive vLEl Role\nCredentials to at least Identity Assurance Level 2 (IAL2) as defined in NIST 800-63A (https://pages.nist.gov/800-63-3/sp800- X; requirement in Credential\n63a.html). Even when IAL2 is used for Identity Assurance, a real-time OOBI session is required as specified in 2.b. below Governance Framework\n(essentially including the IAL3 requirement for a Supervised Remote In-person session).\n2. Identity\nAuthentication\n. X; requirement in Credential\nA credential wallet MUST be set up for the OOR Person or ECR Person.\nGovernance Framework\nA LAR and the OOR Person or ECR Person MUST establish a real-time OOBI session in which the LAR and the OOR Person or ECR X; requirement in Credential\nPerson are present. An example is a continuous web meeting attended by all parties on both audio and video. Governance Framework\nThe following steps MUST be performed in this order and completed during this OOBI session. X; requirement in Credential\nC. Governance Framework\nThe LAR MUST perform manual verification of the OOR Person’s or ECR Person’s legal identity for which the LAR has already . . .\n\nB i A A ) X; requirement in Credential\nperformed Identity Assurance. An example, the OOR Person or ECR Person visually presenting one or more legal identity Governance Framework\ncredentials and the LAR compares the credentials verified during Identity Assurance to the OOR Person or ECR Person.\n\nThe LAR MUST use an OOBI protocol (such as a QR code or live chat) to share its Autonomic Identifier (AID) with the OOR Person X; requirement in Credential\nor ECR Person. Governance Framework\nThe OOR Person or ECR Person MUST use an OOBI protocol (such as a QR code or live chat) to share its AID with the LAR. X; requirement in Credential\nGovernance Framework\nThe LAR MUST send a Challenge Message to the OOR Person’s or ECR Person’s AID as defined in the Technical Requirements Part . . .\nA o B B X; requirement in Credential\n1 for the purposes of cryptographic authentication of the OOR Person’s or ECR Person’s AID. The Challenge Message MUST be\n. N Governance Framework\niv. unique to the OOBI session.\nThe OOR Person or ECR Person MUST use its Private Key Store to sign and return the response to the Challenge Message, after X; requirement in Credential\nV. which the OOR Person or ECR Person MUST acknowledge that this action has been completed. Governance Framework\nThe LAR MUST verify in real time that the response to the Challenge Message was received from the OOR Person or ECR Person. X; requirement in Credential\nVi. Governance Framework\nWhen the response to the Challenge Message has been received by the LAR, the LAR MUST verify the OOR Person’s or ECR X; requirement in Credential\nvii. Person’s signature. Governance Framework\nThe LAR MUST include the OOR Person’s or ECR Person’s AID obtained during Identify Verification of the OOR Person or ECR . . .\no A X; requirement in Credential\nPerson, as well as the name and role of the OOR Person and ECR Person, as elements within the appropriate QVI AUTH vLEI\nh A . N Governance Framework\n6.4 Issuance 1. Credential for the issuance of the associated vLEI Role Credential.\nA LAR MUST issue QVI AUTH vLEI Credential explicitly authorizing the QARs of a QVI to issue each vLEI Role Credential. The QVI X; requirement in Credential\n3. AUTH VLEI Credential will become part of the chain of the vLEI Role Credentials. Governance Framework\n","contentLength":4377,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:17:43.095Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-trust-assurance-framework_v1.1_final.pdf","content":"To revoke a previously issued vLEI Role Credential, the LAR(s) MUST revoke the QVI AUTH vLEI Credential related to a specific X; requirement in Credential X; covered as part of the Credential\n6.5 Revocation |[1. issuance of a vLEI Role Credential Governance Framework revocation process with KERI\nThe QAR then MUST revoke the VLEI Role Credential. X; requirement in Credential X; asse:ssjment and demonstrz'ltlon of X; covered 'as part of the'CredentlaI\n2. Governance Framework Qualified vLEI Issuer compliance revocation process with KERI\nGLEIF MUST monitor the QVI Transaction Event Logs (TELs) to detect revocations of QVI AUTH vLEI Credentials by LARs. This will . . . .\nA A , A N X; requirement in Credential X; assessment and demonstration of\nadvise GLEIF in the case of a terminated QVI or QVI leaving the VLEI Ecosystem to follow up on revocation of any OOR vLEI .\ni Governance Framework GLEIF compliance\n6.7 Monitoring [1. Credentials.\n10 Credential\nDefinition\n10.1 Schema The QVI OOR AUTH vLEI Credential MUST be an Authentic Chained Data Container (ACDC) that MUST use for its schema at the . . .\nA . , X; requirement in Credential . .\nQVI OOR AUTH time of issuance, the JSON Schema found in: X; Credential format in KERI code\n) o . L Governance Framework\nVLEI Credential |1. https://github.com/WebOfTrust/vLEIl/blob/dev/schema/acdc/ecr-authorization-vlei-credential.json\nThe field values in the credential MUST be as follows: X; requirement in Credential\n2. Governance Framework\nThe \"AID\" field value MUST be the AID of OOR Person. X; requirement in Credential X; Credential format in KERI code\nGovernance Framework\nThe \"LEI\" field value MUST be the LEI of Legal Entity Holder. X; requirement in Credential X; Credential format in KERI code\nGovernance Framework\nThe \"personLegalName\" field value MUST be the Legal Name of the Person in the Official Organizational Role at the Legal Entity. X; requirement in Credential X; Credential format in KERI code\nGovernance Framework\nThe \"officialRole\" field value MUST be the Official Role to be assigned in the vLEI OOR Credential. X; requirement in Credential X; Credential format in KERI code\nGovernance Framework\n10.2 Schema The QVI ECR AUTH VLEI Credential MUST be an Authentic Chained Data Container (ACDC) that MUST use for its schema at the . . .\nA . A X; requirement in Credential . .\nQVI ECR AUTH time of issuance, the JSON Schema found in: X; Credential format in KERI code\nf L . - Governance Framework\nVLEI Credential |1. https://github.com/WebOfTrust/vLEIl/blob/dev/schema/acdc/ecr-authorization-vlei-credential.json\nThe field values in the credential MUST be as follows: X; requirement in Credential X; Credential format in KERI code\n2. Governance Framework\nThe \"AID\" field value MUST be the AID of ECR Person. X; requirement in Credential X; Credential format in KERI code\nGovernance Framework\nThe \"LEI\" field value MUST be the LEI of Legal Entity Holder. X; requirement in Credential X; Credential format in KERI code\nGovernance Framework\nThe \"personLegalName\" field value MUST be the Legal Name of the Person in the Engagement Context Role at the Legal Entity. X; requirement in Credential X; Credential format in KERI code\nGovernance Framework\nThe \"engagementContextRole\" field value MUST be the Engagement Context Role to be assigned in the vLEI ECR Credential. X; requirement in Credential X; Credential format in KERI code\nGovernance Framework\nThe Sources section MUST contain a source reference to the Legal Entity vLEI Credential (via SAID) held by the Legal Entity issuer X: requirement in Credential\nof this credential. The Issuer of the referenced Legal Entity vLEI Credential MUST be the target holder of this QVI ECR AUTH vLEI i red X; Credential format in KERI code\n3 Credential Governance Framework\n. redential.\n","contentLength":3796,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:17:43.095Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-trust-assurance-framework_v1.1_final.pdf","content":"GLEIF verifiable LEI (VLEI) Ecosystem Governance Framework 1.0 Trust Assurance Framework Document Version 1.1 Final 2023-04-03\nVersion Date: 2023-04-03\nStatus: Final\n6 Issuer\nPolicies\n6.1 The Issuer MUST be a Qualified vLEI Issuer (QVI) that has been contracted by a Legal Entity holding a valid Legal Entity vLEI Credential X; requirement in Credential X; assessment and demonstration of\nQualifications |1. to issue OOR VLE| credentials. Governance Framework Qualified vLEI Issuer compliance\nThe Issuer MUST:\n6.2 Credential\nuse the OOR VLEI Credential schema defined in section 8.1. Additional schema elements may be added depending on the requirement| X; requirement in Credential X; assessment and demonstration of . .\ne N X; Credential format in KERI code\n1. of a use case. Governance Framework Qualified vLEI Issuer compliance\n. . . . X; assessment and demonstration of . .\ninclude the Claims marked as Required in section 8.1. e N X; Credential format in KERI code\n2. Qualified vLEI Issuer compliance\n6.3 Legal\nEntity Identity |1. Identity\nVerification |Assurance\nA QVI Authorized Representative (QAR) MUST verify that the LEI supplied for the Credential is the LE| of the Legal Entity for which the X; requirement in Credential X; assessment and demonstration of\nissuance request for the Credential has been made. Governance Framework Qualified vLEI Issuer compliance\nA QAR MUST verify the Legal Entity Identifier (LEI) of the Legal Entity has a LEI Entity Status of Active and a LEI Registration Status of X; requirement in Credential X; assessment and demonstration of\nIssued, Pending Transfer or Pending Archival in the Global LEI System. Governance Framework Qualified VLEI Issuer compliance\n6.5 OOR\nPerson\nIdentity 1. Identity\nVerification |Assurance\nIdentity Assurance of a person serving in an Official Organizational Role (OOR Person) MAY be performed either by a QAR, directly or X; requirement in Credential X; assessment and demonstration of\nthrough the use of Third-Party Services, or by a LAR. Governance Framework Qualified VLEI Issuer compliance\nWhen the Identity Assurance is performed by a QAR, the Identity Assurance MUST be in the same Supervised Remote In-person X; requirement in Credential X; assessment and demonstration of\nsession as the Identity Authentication by the QAR. Governance Framework Qualified VLEI Issuer compliance\nA QAR MUST perform identity assurance of an OOR Person at least Identity Assurance Level 2 (IAL2) as defined in NIST 800- . . . :\nR N i N L X; requirement in Credential X; assessment and demonstration of\n63A (https://pages.nist.gov/800-63-3/sp800-63a.htm!). Even when IAL2 is used for Identity Assurance, a real-time OOBI session is . \"\nN ™ N N \" ~ ~ = Governance Framework Qualified vLEI Issuer compliance\n¢ required as specified 6.d. below (essentially including the IAL3 requirement for a Supervised Remote In-person session).\nIf Identity Assurance and Identity Authentication to generate the AID of the OOR Person is performed by the LAR, then Identity X; requirement in Credential X; assessment and demonstration of\nAssurance and Identity Authentication can be performed by a separate Supervised Remote In-person session. Governance Framework Qualified VLEI Issuer compliance\n2. Ildentity\nAuthentication\nby a QAR\nX; i it in Credential\nA credential wallet MUST be set up for the OOR Person. requirement in tredentia\nGovernance Framework\n. . L . L . X; requirement in Credential X; assessment and demonstration of\nA QAR MUST validate the name and the Official Organizational Role of an OOR Person using one or more official public sources. . .\nGovernance Framework Qualified VLEI Issuer compliance\nIf the name and the Official Organizational Role of the OOR Person cannot be validated using one or more official public sources, the . . . :\n. A R R X; requirement in Credential X; assessment and demonstration of\nQAR MUST request from the LAR(s) copies of documents of the Legal Entity, such as Board minutes or resolutions, statutes or . \"\nN . . Governance Framework Qualified vLEI Issuer compliance\narticles, which would validate the name and the role of the OOR Person. .\nc.\nThe QAR MUST call the GLEIF API to look up the OOR code for the OOR Person role provided by the Legal Entity to be used in the OOR X: requirement in Credential X; assessment and demonstration of\nVLEI Credential (when the lists of OOR codes and reference data are accessible using the API). In the interim, a text string will be 4 G q r K GLEIF and Qualified vLEI Issuer\nused for the OOR in the OOR VLEI Credential. overnance Framewor! compliance\nIn all cases, a QAR and the OOR Person MUST establish a real-time OOBI session in which the QAR and the OOR Person are present. X; requirement in Credential X; assessment and demonstration of\nAn example is a continuous web meeting attended by all parties on both audio and video. Governance Framework Qualified VLEI Issuer compliance\nX; requirement in Credential X; assessment and demonstration of\nThe following steps MUST be performed in this order and completed during this OOBI session. N . .\n£, Governance Framework Qualified VLEI Issuer compliance\n","contentLength":5140,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:17:43.095Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-trust-assurance-framework_v1.1_final.pdf","content":"The QAR MUST send a Challenge Message to the OOR Person’s AID as defined in the Technical Requirements Part 1 for the purposes X; requirement in Credential X; assessment and demonstration of X; covered as part of the Credential\nof cryptographic authentication of the OOR Person’s AID. The Challenge Message MUST be unique to the OOBI session. Governance Framework Qualified VLEI Issuer compliance issuance process with KERI|\nThe OOR Person MUST use its Private Key Store to sign and return the response to the Challenge Message, after which the OOR X; requirement in Credential X; covered as part of the Credential\nPerson MUST acknowledge that this action has been completed. Governance Framework issuance process with KERI|\nX; i it in Credential X; t and di tration of\nThe QAR MUST verify in real time that the response to the Challenge Message was received from the OOR Person. requirement In trecentia asss{s‘smen anddemons r‘a lono\nGovernance Framework Qualified VLEI Issuer compliance\nX; i it in Credential X; t and di tration of X; d rt of the Credential\nWhen the response to the Challenge Message has been received by the QAR, the QAR MUST verify the OOR Person’s signature. requirement In trecentia asss{s‘smen anddemons r‘a lono C[.Nere as part o ? recentia\niv. Governance Framework Qualified VLEI Issuer compliance issuance process with KERI\nThe Legal Entity and OOR Person Identity Verification process outlined in sections 6.3 and 6.5 MUST be completed before OOR VLEI X; requirement in Credential X; assessment and demonstration of\n6.6 Issuance |1 Credential issuance can begin. Governance Framework Qualified vLEI Issuer compliance\nThe LAR(s) MUST issue a QVI AUTH OOR vLEI Credential and present this VLEI credential to the QVI to request issuance of a OOR VLEI X; requirement in Credential X; assessment and demonstration of X; covered as part of the Credential\n2 Credential. Governance Framework Qualified VLEI Issuer compliance issuance process with KERI\nA workflow MUST be implemented in the operations of the QVI which requires two QARs to be involved in the issuance and signing X A t in Credential X: tand d rati §\nan OOR vLEI Credential. The first QAR will perform the required above-mentioned Identity Authentication and out-of-band validations 4 é?::::g:]i: FI:a rr::wi:r:'l!a 'Cij:f!i:iser;]ir:;l:sueerr:grr: Ir;”']i: o\n3 and then signs the credential. Another QAR then approves the issuance and signs the OOR vLEI Credential. P\nX: requirement in Credential X; assessment and demonstration of\nA QAR MUST call the vLEI Reporting APl with each issuance event of OOR vLEI Credentials. red GLEIF and Qualified vLEl Issuer\nGovernance Framework .\n4 compliance\nGLEIF MUST update the list of vLEI Credentials on the LEI page of the Legal Entity to reflect OOR VLEI credential issuances that have X; requirement in Credential X; assessment and demonstration of\n5 been reported by QVIs. Governance Framework Qualified vLEI Issuer compliance\n67 To revoke an OOR VLEI Credential:\nRevocation 1.\nThe Legal Entity MUST notify the QU t k OOR VLEI Credential X; requirement in Credential X; assessment and demonstration of\ne Legal Entity notity the O revoke an v redential. Governance Framework Qualified vLEI Issuer compliance\nTo revoke a previously issued OOR VLEI Credential, the LAR(s) MUST revoke the QVI AUTH OOR VLEI Credential related to a specific X; requirement in Credential X; covered as part of the Credential\nissuance of an OOR VLEI Credential. Governance Framework revocation process with KERI\nX; i it in Credential X; t and di tration of\nThe QAR then MUST revoke the OOR VLEI Credential. requirement in bredentia assessment and demonstration o\n. Governance Framework Qualified vLEI Issuer compliance\nX; i it in Credential X; t and di tration of\nA QAR MUST perform the revocation within the timeframe specified in Appendix 5, Service Level Agreement (SLA). requirement In trecentia asse‘ss‘men and demons m. lon o\nGovernance Framework Qualified vLEI Issuer compliance\n. 5 . 3 - - . X; requirement in Credential X; assessment and demonstration of\nA QAR MUST call the OOR Reporting API with each revocation event of Legal Entity Official Organizational Role vLEI Credentials. e .\n2. Governance Framework Qualified vLEI Issuer compliance\n-- e QVI has been terminatect: _—_—\n3.\nAt the end of the Grace Period for the Qualified vLEI Issuer vLE| Credential that has been revoked by GLEIF, the QVI MUST revoke all of X; requirement in Credential X; assessment and demonstration of\nthe OOR VLEI Credentials that the QVI has issued. Governance Framework Qualified vLEI Issuer compliance\nX; i it in Credential X; t and di tration of\nThen, the terminated QVI MUST transfer a copy of its revocation log to GLEIF. requirement in tredentia asse‘ss‘men and demons ra‘ ‘on o\nGovernance Framework Qualified vLEI Issuer compliance\nGLEIF MUST update the list of OOR VLEI Credentials on the LEI page of the Legal Entity to reflect vLEI credential revocations that have X; requirement in Credential X; assessment and demonstration of\n4. been reported by QVIs. Governance Framework GLEIF compliance\nGLEIF MUST monitor the QVI Transaction Event Logs (TELs) to detect the issuance or revocation of OOR VLEI Credentials which were X; requirement in Credential X; assessment and demonstration of\n6.9 Monitoring|1. not reported using the vLE| Reporting API. Governance Framework GLEIF compliance\n9 Credential\nDefinition\nThe OOR VLEI Credential MUST be an Authentic Chained Data Container (ACDC) that MUST use for its schema at the time of issuance, . . .\n. X; requirement in Credential . .\nthe JSON Schema found in: X; Credential format in KERI code\n. . . - . Governance Framework\n9.1 Schema 1 https://github.com/WebOfTrust/vLE|/blob/dev/schema/acdc/legal-entity-official-organizational-role-vLEI-credential json\nN N X; requirement in Credential . .\nThe field values in the credential MUST be as follows: X; Credential format in KERI code\nGovernance Framework\n2.\nX; requirement in Credential\nThe \"LEI\" field value MUST be the LEI of Legal Entity Holder. 9 X; Credential format in KERI code\nGovernance Framework\n. . . ) X; requirement in Credential . .\nThe \"personLegalName\" field value MUST be the Legal Name of the Person in the Official Role at the Legal Entity. X; Credential format in KERI code\nGovernance Framework\nThe \"officialRole\" field value MUST be the Official Organizational Role itself. X; requirement in Credential X; Credential format in KERI code\nGovernance Framework\nThe Sources section of the OOR vLE| Credential MUST contain a source reference to the QVI AUTH vLE| Credential (via SAID) that the\nissuing QVI received authorizing the issuance of this OOR vLEI Credential. The Sources section of that QVI AUTH vLE| Credential X; requirement in Credential X: Credential f ¢ in KERI cod\nMUST contain a source reference to the Legal Entity vLE| Credential that was issued by the QVI to the Legal Entity and contain the Governance Framework » Credential format in code\n3. same value for the “LEI” field as the Legal Entity vLEI Credential.\n","contentLength":7051,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:17:43.095Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-trust-assurance-framework_v1.1_final.pdf","content":"GLEIF verifiable LEI (VLEI) Ecosystem Governance Framework 1.0 Trust Assurance Framework Document Version 1.1 Final 2023-04-03\nVersion Date: 2023-04-03\nStatus: Final\n6 Issuer\nPolicies\n. . . X; assessment and demonstration of\nL X; requirement in Credential A o\n6.1 The Issuer MUST ensure that the Issuer of the QVI vLEI Credential is GLEIF. Governance Framework compliance for Qualified vLEI Issuer and\nQualifications |1. GLEIF\n62Credential | [The lssuer MUST: e e\n. . . X; assessment and demonstration of\n. . . . X; requirement in Credential \" . . .\nuse the QVI vLEI Credential schema defined in section 10.1. Governance Framework compliance for Qualified vLEI Issuer and X; Credential format in KERI code\n1. GLEIF\n. . . X; assessment and demonstration of\n. . . . . X; requirement in Credential A \" . .\ninclude the Claims marked as Required in section 10.1. compliance for Qualified vLEI Issuer and X; Credential format in KERI code\nGovernance Framework\n2. GLEIF\n6.3 QVl\nIdentity 1. Identity\nVerification |Assurance\nAn Externa I' GLEIF Authorlzeq Representative (Externa I' GAR) MUST perform identity asst'Jranc'e of a person serving in the role of X; requirement in Credential X; assessment and demonstration of\nQVI Authorized Representative (QAR) to at least Identity Assurance Level 2 (IAL2) as defined in NIST 800-63A R\ni Governance Framework compliance for GLEIF\n(https://pages.nist.gov/800-63-3/sp800-63a.html).\nA minimum of two QARs MUST form the QVI multi-sig group. X; requirement in Credential X; asse'ssment and dt'er'nonstratlon of X; co'vered as part of tht'e Credential\nGovernance Framework compliance for Qualified vLEI Issuer issuance process with KERI\nAn External GAR MUST lead for the anchoring action for the QVI External Delegated AID described below. X; requirement in Credential X; assessment' and demonstration of\nC. Governance Framework compliance for GLEIF\n2. |dentity\nAuthentication\nA credential wallet MUST be set up for the QVI. X; requirement in Credential X; asse'ssment and dt'er'nonstratlon of\nGovernance Framework compliance for Qualified vLEI Issuer\nThe QVI MUST designate a QAR to act on its behalf. X; requirement in Credential X; asse'ssment and dt'er'nonstratlon of\nGovernance Framework compliance for Qualified vLEI Issuer\nAn External GAR and the QAR MUST establish a real-time OOBI session in which the External GAR and the QAR are present. An X; requirement in Credential X as'sessment and'd'emonstratlon of\n. . . . . . compliance for Qualified vLEI Issuer and\nexample is a continuous web meeting attended by all parties on both audio and video. Governance Framework GLEIF\n[\n. . . X; assessment and demonstration of\n. . . . . . X; requirement in Credential A o\nThe following steps MUST be performed in this order and completed during this OOBI session. Governance Framework compliance for Qualified vLEI Issuer and\nGLEIF\nThe External GAR MUST perform manual verification of the QAR’s legal identity for which the External GAR has already i . . .\n. . . . . . . X; requirement in Credential X; assessment and demonstration of\nperformed Identity Assurance. An example is the QAR visually presenting one or more legal identity credentials and the External i\n. . . . Governance Framework compliance for GLEIF\nGAR compares the credentials verified during Identity Assurance to the QAR Person.\nThe External GAR MUST use an OOBI protocol (such as a QR code or live chat) to share the GLEIF External Delegated AID (GEDA) X; requirement in Credential X; assessment and demonstration of\nwith the QAR. Governance Framework compliance for GLEIF\n. . X; requirement in Credential X; assessment and demonstration of\nAn QAR MUST use an OOBI protocol (such as a QR code or live chat) to share the QVI AID with the External GAR. A .\nGovernance Framework compliance for Qualified vLEI Issuer\nThe External GAR MUST send a Challenge Message from the GEDA to the QVI AID as defined in the Technical Requirements Part . . . . .\nA . ) X; requirement in Credential X; assessment and demonstration of X; covered as part of the Credential\n1 KERI Infrastructure for the purposes of cryptographic authentication of the QVI AID. The Challenge Message MUST be unique to R . .\n. the 0OBI . Governance Framework compliance for GLEIF issuance process with KERI\niv. e session.\n","contentLength":4283,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:17:43.095Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-trust-assurance-framework_v1.1_final.pdf","content":"The QAR MUST use its Private Key Store to sign and return the response to the Challenge Message, after which the QAR MUST X; requirement in Credential X; assessment and demonstration of X; covered as part of the Credential\nV. acknowledge that this action has been completed. Governance Framework compliance for Qualified vLEI Issuer issuance process with KERI\nThe External GAR must verify in real time that the response to the Challenge Message was received from the QAR. X; requirement in Credential X; assessment' and demonstration of X; cc'>vered as part of th? Credential\nVi. Governance Framework compliance for GLEIF issuance process with KERI\nWhen the response to the Challenge Message has been received, the External GAR must verify the signature of the QAR. X; requirement in Credential X; assessmen\"c and demonstration of\nvii. Governance Framework compliance for GLEIF\n6.4 Creation X; assessment and demonstration of\nof the QVI The creation of the QVI Delegated AIDs follows the successful completion of Identity Verification by the External GAR Lead of X; requirement in Credential s o\ncompliance for Qualified vLEI Issuer and\nDelegated each QAR. Governance Framework GLEIF\nAlIDs 1.\nThe following steps MUST be performed in the order listed and completed during an OOBI session for a given QVI Delegated AID. X; requirement in Credential X; asse'ssment and d'er\"nonstratlon of\n2. Governance Framework compliance for Qualified vLEI Issuer\nEach Delegated AID QVI Authorized Representative (QAR) that is a participating member in the group of AIDs MUST generate its X; requirement in Credential X; assessment and demonstration of\nown individual single signature AID that will be used to create the QVI Delegated AID. Governance Framework compliance for Qualified vLEI Issuer\nEach QAR MUST use an OOBI protocol (such as a QR code or live chat) to share its own AID with the other QAR s. For each QAR, X; requirement in Credential X; assessment and demonstration of\nthis provides the participating AID and the service endpoint whereby the other QARs may obtain the KEL of its participating AID. Governance Framework compliance for Qualified vLEI Issuer\nEach QAR MUST send a Challenge Message tc'> every oth'er QAR as de'f|r'1ed'|r'1 the T'echnlc'al Requirements Part 1 KERI X; requirement in Credential X; assessment and demonstration of\nInfrastructure for the purposes of cryptographic authentication of their individual single signature AID. The Challenge Message R o\nA N Governance Framework compliance for Qualified vLEI Issuer\nC. MUST be unique to the OOBI session.\nEach QAR must verify in real time that a response to the Challenge Message was received from every other QAR. X; requirement in Credential X; asse'ssment and d'er\"nonstratlon of\nGovernance Framework compliance for Qualified vLEI Issuer\nEach QAR must verify the signature of every other QAR. X; requirement in Credential X; asse'ssment and d'er\"nonstratlon of\nGovernance Framework compliance for Qualified vLEI Issuer\nOne of the QARs must be designated as the Delegated AID QVI Authorized Representative (QAR Lead). X; requirement in Credential X; asse'ssment and d'er\"nonstratlon of\nf. Governance Framework compliance for Qualified vLEI Issuer\n. . . . . X; requirement in Credential X; assessment and demonstration of\nThe QAR Lead MUST either configure or select the AIDs and Service Endpoints for the QVI Delegated AID Witness Pool. i o\nGovernance Framework compliance for Qualified vLEI Issuer\nThe QAR Lead MUST select the AIDs from the set of QARs for the ordered set of authorized participant members in the multi-sig i . . .\n) . . X; requirement in Credential X; assessment and demonstration of\ngroup and configure and approve the weight threshold and ordered set of participants for both the current and next set and R o\n. Governance Framework compliance for Qualified vLEI Issuer\nh. threshold of participants.\nUs.'lng the current public key and the next public key digest from each of the participating {-\\ID Inception Even\"cs, the' Delegated X; requirement in Credential X; assessment and demonstration of\nWitness AIDs, and the GEDA, the QAR Lead MUST generate the QVI Delegated AID Inception Event and publish this to the other R .\n) N A Governance Framework compliance for Qualified vLEI Issuer\nQARs and to the Delegated AID Witnesses designated by that Inception Event.\nEach QAR MUST verify the set of public keys, the next public key digest, the Witness identifiers, the threshold, the next threshold, X; requirement in Credential X; assessment and demonstration of\nand the GEDA in the Delegated AID Inception Event. Governance Framework compliance for Qualified vLEI Issuer\nEach QAR MUST verify the set of Witness endpoints for the QVI Delegated AID. X; requirement in Credential X asse'ssment and d'er\"nonstratlon of\nk. Governance Framework compliance for Qualified vLEI Issuer\nEach QAR MUST sign and publish to the Delegated AID Witnesses their signature on the Delegated AID Inception Event. X; requirement in Credential X asse'ssment and d'er\"nonstratlon of\nGovernance Framework compliance for Qualified vLEI Issuer\nEach QAR MUST verify that the Delegated AID Inception Event is fully witnessed by every Witness. X; requirement in Credential X asse'ssment and d'er\"nonstratlon of\nm. Governance Framework compliance for Qualified vLEI Issuer\nGLEIF MUST designate one of the External Delegated AID GLEIF Authorized Representative (External GARs) as the External X; requirement in Credential X aisessr:en;an(li'gedmolls.ltlratlon Ofd\nDelegated AID GLEIF Authorized Representative (External GAR Lead). Governance Framework compliance tor ;T_IL_IIFe v ssueran\n6.5\nDelegation of Unless otherwise pre-approved by the GLEIF Root GARs, GLEIF External AID MUST use an Interaction Event to approve the X; requirement in Credential X; as.'sessment and'd'emonstratlon of\nthe QVI . compliance for Qualified vLEl Issuer and\ndelegation of the QVI Delegated AlDs. Governance Framework\nDelegated GLEIF\nAlIDs 1.\nThe following steps MUST be performed in the order listed and completed during this OOBI session for the GLEIF External X; requirement in Credential X; as.'sessment and'd'emonstratlon of\ncompliance for Qualified vLEI Issuer and\nDelegated AID (GEDA). Governance Framework\n2. GLEIF\nThe QAR Lead initiates a set of QARs to create a multi-sig group and the QARs mutually are authenticated. X; requirement in Credential X asse'ssment and d'er\"nonstratlon of\nGovernance Framework compliance for Qualified vLEI Issuer\n","contentLength":6497,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:17:43.095Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-trust-assurance-framework_v1.1_final.pdf","content":"The QAR Lead initiates the creation of the Inception Event using the published GLEIF External AID as the Delegator. X; requirement in Credential X asse'ssment and d'er\"nonstratlon of\nGovernance Framework compliance for Qualified vLEI Issuer\nThe External GAR Lead verifies that the set of QARs in the multi-sig group in this Inception Event to delegate the QVI External AID X; requirement in Credential X as.'sessment and'd'emonstratlon of\ne . . compliance for Qualified vLEI Issuer and\nmatch those that the External GAR Lead verified according to section 6.3 above. Governance Framework GLEIF\nc.\nThe External GAR Lead submits request to the External GAR multi-sig group to anchor the Interaction event. All members of the X: requirement in Credential X; assessment and demonstration of\nExternal GAR multi-sig group trust External GAR Lead to anchor because the External GARs already have trusted the External GAR ! ch/ernance Framework compliance for Qualified vLEl Issuer and\nLead to perform Identity Assurance on the QARs. GLEIF\nThe External GAR Lead then submits a request to issue the Qualified VLEI Issuer VLEI Credential to QVI vLEI to the External GAR X; requirement in Credential X; as.'sessment and'd'emonstratlon of\nN . compliance for Qualified vLEI Issuer and\nmulti-sig group as an Interaction Event. Governance Framework GLEIE\n6.6 QVI vLEI The External GAR MUST approve issuance of a QVI vLEI Credential after the completion of QVI Identity Verification in section 6.3 X; requirement in Credential X; as.'sessment and'd'emonstratlon of\nCredential compliance for Qualified vLEI Issuer and\nabove. Governance Framework\nIssuance 1. GLEIF\n6.7 QVI VLEI\nCredential 1. Voluntary\nRevocation Revocation\nAn External GAR MUST revoke a Legal Entity vLEI Credential upon receipt of a Fully Signed revocation request by the QAR(s ) of X; requirement in Credential X; as.'sessment and'd'emonstratlon of X; covered as part of the Credential\n. . . . . . compliance for Qualified vLEI Issuer and . .\nthe Legal Entity, e.g., if the Legal Entity chooses to no longer be the Holder of this Credential using the vLEI software. Governance Framework GLEIF revocation process with KERI\n. . . X; assessment and demonstration of\n. L . o . . X; requirement in Credential A o\nAn External GAR MUST perform the revocation within the timeframe specified in Appendix 5, Service Level Agreement (SLA). compliance for Qualified vLEI Issuer and\nGovernance Framework\nGLEIF\n. . . X; assessment and demonstration of\nX; requirement in Credential A o\n2. Involuntary compliance for Qualified vLEl Issuer and\nGovernance Framework\nRevocation GLEIF\nInvoluntary revocation of vLEI Credentials MUST follow the process specified in Appendix 5, Service Level Agreement (SLA). X; requirement in Credential X; assessmen\"c and demonstration of\nGovernance Framework compliance for GLEIF\n7 QVI Self- . . . X; assessment and demonstration of\n. L X; requirement in Credential A \"\nissuance of GLEIF MUST oversee the assignment of these vLEI Credentials issued by QVIs to themselves. compliance for Qualified vLEI Issuer and\nGovernance Framework\nVLEIs 2. GLEIF\n9 Verifier When part of a chain, each chained vLEI MUST include a reference to one or more preceding VLEls in its provenance chain. X; requirement in Credential\nPolicies 2. Governance Framework\nIf any preceding vLEls in the provenance chain or a given VLEI is revoked, then that given vLEI MUST not verify. X; requirement in Credential\n3. Governance Framework\nThe schema for each type of vLEI defines what type or types of vLEIs MUST or MAY be referenced in its provenance section. X; requirement in Credential\nGovernance Framework\n10 Credential\nDefinition\nThe OOR VLEI Credential MUST be an Authentic Chained Data Container (ACDC) that MUST use for its schema at the time of . . .\nA A X; requirement in Credential\nissuance, the JSON Schema found in: Governance Framework\n10.1 Schema |1. https://github.com/WebOfTrust/vLEl/blob/dev/schema/acdc/qualified-vLEI-issuer-vLEI-credential .json\nThe field values in the credential MUST be as follows: X; requirement in Credential\n2. Governance Framework\nR X; requirement in Credential\nThe \"LEI\" field value MUST be the LEI of the QVI.\nGovernance Framework\nThe \"gracePeriod\" field value MUST be at least 90 (ninety) Days. X; requirement in Credential\nGovernance Framework\n","contentLength":4327,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:17:43.095Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-trust-assurance-framework_v1.1_final.pdf","content":"GLEIF verifiable LEI (VLEI) Ecosystem Governance Framework 1.0 Trust Assurance Framework Document Version 1.1 Final 2023-04-03\nVersion Date: 2023-04-03\nStatus: Final\nX; although GLEIF will not be able\n2. VLEI Ecosystem stakeholders MUST comply with any governmental regulations for information security to which their activities to determine compliance by\nwithin the vLEI Ecosystem will be subject. This includes International or trans-national governance authorities (e.g., ISO/IEC Ecosystem stakeholders other\n3 Regulatory 27001 — Information Security Management, EU General Data Protection Regulation (GDPR)). than itself and Qualified vLEI\nCompliance Issuers\nX; although GLEIF will. not be able\n4 Vel The VLEI Ecosystem Credential Governance Frameworks MUST specify the information to be protected by the applicable privacy to determine compliance by\nEcosystem olicy in the jurisdiction of the Legal Entity Ecosystem stakeholders other\nStakeholder policy J g : than itself and Qualified vLEI\nPrivacy Policies |2. Issuers\n5 VLEI X; although GLEIF will. not be able\nEcosystem VLE| Ecosystem stakeholders MUST confirm that they respect and comply with data protection legislation as applicable and in to determine compliance by X; confirmation during Annual vLEI Issuer\nStakeholder force. Ecosystem stakeholders other Qualification\nData Protection than itself and Qualified vLEI\nPolicies 1. Issuers\nX; although GLEIF will. not be able\nW here no such legislation is in force, and as a material minimum standard, vLEI Ecosystem stakeholders MUST comply with the to determine compliance by X; confirmation during Annual vLEI Issuer\nL . . e i . . Ecosystem stakeholders other P\nprovisions of the Swiss Federal Data Protection Act specified in the Appendix to this policy document. i o Qualification\nthan itself and Qualified vLEI\n2. Issuers\nQualified vLEI Issuers MUST annually review and document that the provisions are implemented and enforced. X; confirmation dur'lr'1g l-\\'nnual VLELIssuer\nQualification\nX; although GLEIF will. not be able\nWhen a privacy breach is suspected, the involved VvLEI Ecosystem stakeholders MUST inform each other about actual or potential to determine compliance by . . .\n. A ) ) o N X; confirmation during Annual vLEI Issuer\ndisclosure(s) of Personal Data and promptly take appropriate measures to address the situation and to limit the risk of such Ecosystem stakeholders other Qualification\ndisclosure(s) from reoccurrence. than itself and Qualified vLEI\n5. Issuers\nQualified vLEI Issuers MUST document privacy breaches in an Incident Report . X; Incident reports flléd by Qualified vLE|\nIssuers for all privacy breaches\nVLE| Ecosystem stakeholders MUST publish, review annually, maintain, and comply with IT security policies and practices X; atlth(;)utgh G,LEIF W|II.|'not bebable\n6 VLEI sufficient to protect all services that a vLEI Ecosystem stakeholder provides in conformance with this Ecosystem Governance 0 determine compliance by i . X; confirmation during Annual vLEI Issuer\nEcosystem . R — Ecosystem stakeholders other X; audit of GLEIF compliance P\nFramework and meets the minimum elements of the following recommendations: than itself and Qualified vLEI Qualification\nStakeholder https://resources.infosecinstitute.com/topic/key-elements-information-security-policy/#gref an ltsell and Luafitied v\nSecurity Policies [1. Issuers\nThese policies MUST be mandatory for all employees of the VvLEI Ecosystem stakeholder involved with vLEI Transactions or vLEI X; although G,LEIF will. 'not beable| X; adherer'\\c'e to' VLEI Inft')rmatlon X; adherence to vLEI Information Trust\n. . . . . . . to determine compliance by Trust Policies into services and L .\nData. The VLEI Ecosystem stakeholder MUST designate its Information Security Manager or another officer to provide executive . Policies into services and processes for\n. I . L . . Ecosystem stakeholders other processes for which GLEIF . o .\noversight for such policies, including formal governance and revision management, employee education, and compliance 3 o A 5 ) . which Qualified vLEI Issuer Information\nthan itself and Qualified vLEI Information Security Officer is . ) . A\nenforcement. . Security Officer is responsible\n2. Issuers responsible\n","contentLength":4245,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:17:43.095Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-trust-assurance-framework_v1.1_final.pdf","content":"X; although GLEIF will. not be able |, . . . . . .\nto det . i b X; inclusion of required employment X; inclusion of required employment\nVLE| Ecosystem stakeholder employment verification policies and procedures MUST include, but may not be limited to, criminal 0 determine compliance by verification policies and procedures | verification policies and procedures into\n. . s Ecosystem stakeholders other . L o\nbackground check and proof of identity validation . i o into GLEIF Human Resources hiring | Qualified vLEI Issuer Human Resources\nthan itself and Qualified vLEI L\nprocess hiring process\n3. Issuers\nQualified vLEI Issuers MUST recertify annually that they maintain a law abiding and ethical status in the business community as X; confirmation during Annual vLEI Issuer\nevidenced in the Annual vLEI Issuer Qualification. Qualification\nIf a Qualified VLEI Issuer performs handling of vLEI Data in its own data center, the Qualified vLEIl Issuer’s security policies MUST X; confirmation during Annual vLEI Issuer\n5. also adequately address physical security and entry control according to industry best practices. Qualification\nIf a Qualified VLEI Issuer uses third-party providers in functions that involve the handling of vLEI Data, the Qualified vLEI Issuer X: i tion during A | VLEl 1\nMUST ensure that the security, privacy, and data protection policies of the third-party providers meet the requirements in this s contirma |o(nl ulr'lfr'\\g t'nnua Vil lIssuer\ndocument. ualification\nQualified vLEI Issuers MUST make available evidence of stated compliance with these policies and any relevant accreditations\nheld by the Qualified vLEI Issuer during Annual vLEI Issuer Qualification, including certificates, attestations, or reports resulting X; confirmation during Annual vLEI Issuer\nfrom accredited third-party audits, such as ISO 27001, Statement on Standards for Attestation Engagements Service Organization Qualification\n7. Controls 2 (SSAE SOC 2), or other industry standards.\nQualified vLEI Issuers MUST maintain and follow documented incident response procedures and guidelines for computer security\n7 Security incident handling and will comply with data breach notification terms of the vLEl Issuer Qualification Agreement. ITIL (Information X; confirmation during Annual vLEI Issuer\nIncidents Technology Infrastructure Library) Incident Management is followed by GLEIF and is certified as part of GLEIF’s ISO 20000 Qualification\nPolicies 1. certification.\nX; appropriate response plan provided to\n. . . . . . GLEIF during vLEl Issuer Qualification and\nQualified vLEI Issuers MUST define and execute an appropriate response plan to investigate suspected unauthorized access to VLE| confirmed during Annual VLEI lssuer\ndata. This plan MUST include procedures and forms that GLEIF and the Qualified vLEI Issuers use responsively to communicate e g .\n. o . Qualification; existence of forms\nsecurity events and their disposition. - . .\ncommunicating security events and their\n2. disposition\n8 Availability GLEIF and Qualified vLEI Issuers MUST maintain defined availability targets as part of the vLEI Ecosystem Governance Framework. X; defined GLEI,F availability targets | X; confirmation dur'lr'1g A'nnual VLELIssuer\nPolicies 1. in SLA Qualification\n. S . - . A . . X; confirmation during Annual vLEl Issuer\nGLEIF and Qualified vLEI Issuers MUST maintain records to evidence the availability of their services. X; audit of GLEIF compliance e\n2. Qualification\n9 Developer . . . . .\n. . GLEIF MUST provide technical changes/upgrades to the VLEl software to Qualified vLEl Issuers. X; audit of GLEIF compliance\nSecurity Policies 1\n- Qualified vLEI Issuers MUST successfully install, test and implement the GLEIF-supplied vLEI software within stated timeframes. _— X; softwatr'e w]?rklng by stated _\n. imeframes\n","contentLength":3824,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:17:43.095Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-trust-assurance-framework_v1.1_final.pdf","content":"GLEIF verifiable LEI (VLEl) Ecosystem Governance Framework 1.0 Trust Assurance Framework Document Version 1.1 Final 2023-04-03\n\nVersion Date: 2023-04-03\n\nStatus: Final\n\n- v ]\ne e e\nI e e e e\nI I e e\nI e\ne e e\nI e e e e\nI I e e\nI e\ne e e\nI e e e e\nI I e e\nI e\ne e e\nI e e e e\nI I e e\nI e\ne e e\nI e e e e\nI I e e\nI e\ne e e\nI e e e e\nI I e e\nI e\ne e e\nI e e e e\nI I e e\nI e\ne e e\nI e e e e\nI I e e\nI e\ne e e e\n","contentLength":407,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:17:43.095Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-trust-assurance-framework_v1.1_final.pdf","content":"GLEIF verifiable LEI (VLEI) Ecosystem Governance Framework 1.0 Trust Assurance Framework Document Version 1.1 Final 2023-04-03\nVersion Date: 2023-04-03\nStatus: Final\n1 Business There MUST be availability targets defined for all vLEI services included in Appendix 5 of the vLEI Issuer Qualification Agreement, X X X\nRequi Qualified VLEI Issuer Service Level Agreement (SLA).\nequirements |3.\nThe QVI MUST be solely responsible for managing the revenue that is produced and costs that are incurred in the running of its X X\n5. VLEI operations.\n\ne [The VI MUST cnsure that s operations regarding VIEis are sustaimably financed. S S\n17 [GLEIF MUST not contribute funds of any form whatsoever for QUi operations. S S\n","contentLength":711,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:17:43.095Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-trust-assurance-framework_v1.1_final.pdf","content":"GLEIF verifiable LEI (VLEI) Ecosystem Governance Framework 1.0 Trust Assurance Framework Document Version 1.1 Final 2023-04-03\nVersion Date: 2023-04-03\nStatus: Final\n1. KERI\nSpecifications\n1.2\n\\S/pec!flcatlon Previous versions explicitly cited by policies in this document MUST be supported for a period 18 months . X\nersion\nUpgrades 1.\nNew versions MUST be implemented within a period 12 months after final approval of the new version, unless otherwise superseded by revised policies X\nin a new version of the vLEI Ecosystem Governance Framework.\n2.\nAfter upgrading to a new version, implementers MUST NOT begin using any breaking changes until the end of the time period required to adopt new X; assessment and demonstration of\nversions. For example, v2.0 must be compatible with v1.0 until the end of the v2.0 adoption period. So v2.0 must be used in a v1.0 compatible mode. compliance\n3.\n2. Endorser\n(Backer)\nManagement\n2.1 Witness MUST use KERI Agreement Algorithm for Control Establishment (KAACE) sufficient majority threshold on a minimum pool of 5 Witnesses. X; assessment and 'demonstratlon of X; covered by KEBI Key Management\nPool: 1. compliance Architecture\nMUST publish Witnesses to at least one ecosystem discovery mechanism: X; assessment and 'demonstratlon of X; covered by KEBI Key Management\n3. compliance Architecture\nWell-Known URI IETF RFC-8615 on a web site(s)associated with entity. The value of the /well-known/oobi resource is a OOBI (out-of-band-introduction) X; assessment and demonstration of\nto witness or witnesses compliance\n| |b. [publish OOBIs for witnesses on web site(s) discoverable by search engines. -]\nKERI Distributed Hash Table (DHT) X; assessment and 'demonstratlon of X; covered by KEBI Key Management\nC. compliance Architecture\nDID method resolvers X; assessment and 'demonstratlon of X; covered by KEBI Key Management\ncompliance Architecture\nX; assessment and demonstration of\nLedgers A\ncompliance\n2.2 Registrar MUST use a GLEIF Approved DID Method (one for each authorized ledger): X; assessment and demonstration of X; covered by KERI Key Management\n(Ledger): 1. compliance Architecture\nSecurity guarantees are based on the particular ledger X; assessment and 'demonstratlon of X; covered by KEBI Key Management\ncompliance Architecture\nA DID method MUST be approved down to the ledger-specific level X; assessment and 'demonstratlon of X; covered by KEBI Key Management\ncompliance Architecture\n2.3 Hybrid\n(Witness Pool MUST | tvoe f KEL X; covered by KERI Key Management\nand Ledger use only one type for any L. Architecture\nRegistrar): 1.\n4 Key\nManagement\n4.1 Key-pair\ncreation and All key-pairs MUST be generated using a cryptographic algorithm with at least 128 bits of cryptographic strength. This includes using a source of entropy X; covered by KERI Key Management\nstorage of at least 128 bits of cryptographic strength for the salt or seed used to generate the private key of the key pair. Architecture\ninfrastructure [4.1.1 Strength\n4.1.2\ni X; covered by KERI Key Management\nAutohqmlc Both Authentic Chained Data Container (ACDC) Issuer and Issuee AIDs MUST be transferable. v N v 8\nIdentifiers Architecture\n(AIDs)\n","contentLength":3170,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:17:43.096Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-trust-assurance-framework_v1.1_final.pdf","content":"4.1.3 Key Pre-\nRotation for The next or pre-rotated set of keys MUST be protected with the highest level of protection. This level of protection should be commensurate with the X; confirmation during Annual vLEI Issuer\nTransferable |value of the assets these keys are protecting. Qualification\nAIDs 1.\nNon-delegated pre-rotated keys are at the root level of a delegation hierarchy and MUST have the very highest level of protection. There is no recovery\nmechanism within KERI to regain control over a non-delegated AID once its pre-rotated keys have been captured. The only recourse is to abandon the AID X; confirmation during Annual vLEI Issuer X; covered by KERI Key Management\nand stand up a new AID and reestablish the reputation and associations of the new AID. This re-establishment process is ecosystem dependent and is Qualification Architecture\n2. not part of KERI.\n4.3 Signature Best practices for code delivery and library usage MUST be observed for signature verification infrastructure. Because the signature verification X; confirmation during Annual vLEI Issuer\nVerification infrastructure need never be publicly disclosed an attacker must first discover what computing devices are being used to verify signatures. Qualification\nInfrastructure |1.\n5 GLEIF KERI\nProfile\n5.1 GLEIF Root X; assessment and demonstration of\nAID Inception GLEIF compliance\nEvent 1. 1. GLEIF MUST hold a recorded GLEIF Root AID Genesis Event with at least a minimum of three Notaries as witnesses.\n| Ja [The OOBIfor the KEL for the GLEIF Root AID Genesis Event: - 0 000000O]\nMUST be stored on the following GLEIF servers protected by extended validation HTTPS certificates: X; assessment and demonstratlon of\nGLEIF compliance\n. [Furimizo1e521253.010 rod 1 el -\n| i [NA-CAOVH-0151.79.54.121Prod 1 Canada e e\n[ i [AF7AAZR0110237159.99 Prod 1 South Africa -]\nv [sABRAWS 0154233109129 Prod 1Braai I S A\nv |rscvAuOis210213.18 ProddChina -\n[ [0CAUOVA0I5116113060 Prog 2 Sydney -\ni [NAUSHIZ0151614939 Prod 2 Ashium I S A\ni [AsIr-AzR01207861.227 Prod 2 Japan -\n[ lx. [AF7AAWS 0113204115106 Prod 2 South Afic -\n[ x |FU-UKAU01520827.153 Prod 2 United Kingdom I S A\nMUST be stored at HTTPS URLs of the following affiliated organizations: X; assessment and demonstratlon of\nGLEIF compliance\nQualified vLEI Issuers X; confirmation duntlr?g Annual VLEI Issuer\nQualification\nMUST be stored as a file on a public GLEIF GitHub repository. X; assessment and demonstratlon of\nC. GLEIF compliance\nMUST be shared on the following social media: X; assessment and dernonstranon of\nGLEIF compliance\ni [ukednonatwier I S A\n5.2 GLEIF Root\nAID 1. Non-delegated pre-rotated keys are at the root level of the delegation hierarchy and MUST have the very highest level of protection\nX; covered by KERI Key Management\nMUST be a threshold multi-sig with weighting requirements that have been determined by GLEIF. X v N v g\n5 Architecture\nKey Pair Creation and Storage Infrastructure MUST be within a TEE. X; covered by KEBI Key Management\nArchitecture\n3.\nX; d by KERI Key M: it\nEach key-pair in a thresholded multi-sig MUST use a non-co-located TEE. s covered by . €y Managemen\nArchitecture\nX; covered by KERI Key Management\n5.3 GLEIF Root The Witness Pool configuration MUST include a minimum of 5 with the sufficient threshold as per KAACE. Z«rchitectl:/re g\nWitness Pool |1.\nThe number of Witnesses on any single web host provider MUST be less than the sufficient threshold as per KAACE (NOTE: this prevents a single web X; covered by KERI Key Management\n2. host provider from hosting a majority of Witnesses.) Architecture\n","contentLength":3587,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:17:43.096Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-trust-assurance-framework_v1.1_final.pdf","content":"The number of Witnesses in any single political jurisdiction MUST be less than the sufficient threshold as per KAACE. X; covered by KEBI Key Management\nArchitecture\nGLEIF Root Witness Signing Key Pair key store MAY reside on the Witness Service host but MUST use dedicated user only permissions on the key store X; covered by KERI Key Management\ndirectory and its contents. The secrets in the key store MUST be encrypted with the key loaded dynamically whenever the Witness service is started. The Architecture\n5. key store MUST reside on a different device or host from that of the Witness service.\nést GLE:F GLEIF MUST set the Do Not Delegate configuration property on Qualified vLE| Issuer AIDs. NOTE: This may change in the future to enable horizontal X; covered by KERI Key Management\nxterna scalability. Architecture\nDelegate AID 1.\n5.7 GLEIF\nX; d by KERI Key M: it\nWatcher Larger pool sizes MUST use KAACE sufficient majority thresholds. s covered by N ey Managemen\nArchitecture\nNetwork 2.\nThe GLEIF Watcher Signing Key Pair key store MAY reside on the Watcher Service host but MUST use dedicated user only permissions on the key store X; covered by KERI Key Management\n3. directory and its contents. Architecture\nWhen used, the encryption key store MUST reside on a different device or host from that of the Watcher service. X; covered by KEBI Key Management\n5. Architecture\n5.8 GLEIF Ke ; i\nMa nagemen\\t/ The specifc holders of cryptographic keys MUST be kept confidential and shall be determined by GLEIF internal policy. _— é’;;:i?r:]?::;d demonstration of _\nSigning keys MUST be rotated whenever there is a likelihood of key compromise. X; covered by KEBI Key Management\n3. Architecture\nThe time and place of key rotation MUST be kept confidential among the key holders until after the rotation has been completed. %; assessmerfit and demonstration of\nGLEIF compliance\nGLEIF policies for approving rotation of the issuing keys for the GLEIF-Delegated issuing identifier: X; covered by KEBI Key Management\nArchitecture\nMUST use an OOB (out-of-band) MFA (multi-factor authorization) mechanism to approve Delegated AID rotation. X assessmerfit and demonstration of\nGLEIF compliance\n6. Qualified\nVLEI Issuer\nKERI Profile\n6.2 Delegated For added security, Qualified VLEI Issuers:\nAlIDs 1.\nMUST use Delegated AIDs from GLEIF for issuing VLEs or all types. X; confirmation duntlr?g Annual VLEI Issuer X; covered by KEBI Key Management\nQualification Architecture\nMUST use at least multi-sig scheme of at least 3 signers with a threshold of 2. X; confirmation duntlr?g Annual VLEI Issuer X; covered by KEBI Key Management\nQualification Architecture\nEach key-pair in a thresholded multi-sig MUST use a non-co-located key store. X; confirmation duntlr?g Annual VLE Issuer X; covered by KEBI Key Management\n3 Qualification Architecture\n6.3 Qualified\nVLEI Issuer\nncorser An Endorser MUST use either a Witness Pool or a Ledger Registrar for Endorsement X; confirmation during Annual VLEl lssuer X; covered by KERI Key Management\nSu}pport. 8 8 Qualification Architecture\nWitness Pool\nor Ledger\nRegistrar 1.\n6.3.1 Witness The Witness Pool configuration MUST include a minimum of 5 with the sufficient threshold as per KAACE. X; confirmation duntlr?g Annual VLEI Issuer X; covered by KEBI Key Management\nPool 1. Qualification Architecture\nThe Witness Signing Key Pair key store MAY reside on the Witness Service host but MUST use dedicated user only permissions on the key store directory X; confirmation during Annual vLEI Issuer X; covered by KERI Key Management\n2. and its contents. Qualification Architecture\nThe encryption key store MUST reside on a different device or host from that of the Witness service. X; confirmation duntlr?g Annual VLEI Issuer X; covered by KEBI Key Management\nQualification Architecture\n6.3.2 Ledger Registrar Signing Key Pair key store MAY reside on the Registrar Service host but MUST use dedicated user only permissions on the key store directory X; confirmation during Annual vLEI Issuer X; covered by KERI Key Management\nRegistrar 1. and its contents. Qualification Architecture\nThe encryption key store MUST reside on a different device or host from that of the Registrar service. X; confirmation duntlr?g Annual VLEI Issuer X; covered by KEBI Key Management\n3. Qualification Architecture\nLarger pool sizes MUST use KAACE sufficient majority thresholds. X; confirmation duntlr?g Annual VLEI Issuer X; covered by KEBI Key Management\n6.4 Watchers |2. Qualification Architecture\nWatcher Signing Key Pair key store MAY reside on the Watcher Service host but MUST use dedicated user only permissions on the key store directory X; confirmation during Annual vLEI Issuer X; covered by KERI Key Management\n3. and its contents. Qualification Architecture\nWhen used, the encryption key store MUST reside on a different device or host from that of the Witness service. X; confirmation duntlr?g Annual VLEI Issuer X; covered by KEBI Key Management\n5. Qualification Architecture\n","contentLength":4997,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:17:43.096Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-governance-requirements_v1.0_final.pdf","content":"O:GLEIF, Protecting digital st\nverifiable LEI (vLEI)\nEcosystem Governance Framework v1.0\nGovernance Requirements\nPublic\nDocument Version 1.0\n2022-12-16\n@ \"flg ’ e\nK . fib.\\\\.‘ - / . by —\n: jy-° N B s\n. ‘ fi . ‘\\'o o ’f' .. . .\n.\\‘ \" : d’.. r 7 :.n - : { . o’ ) .. .° ... ’ .. .o\n.“- .‘ h (‘-\\\\ }\" {{ { .' . : : . o\ns - 2\nP\n.\n","contentLength":322,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:17:58.539Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-governance-requirements_v1.0_final.pdf","content":"verifiable LEI (VLEI) Ecosystem Governance\nFramework Technical Governance Requirements\nThis Controlled Document specifies the governance of GLEIF in its role in the Global LEI System\nincluding the the regulatory oversight of GLEIF by the Regulatory Oversight Committee. Every LEI\nmust be managed according to this governance which places GLEIF in the management role for the\nGlobal LEI System.\n\nThe DID URL for this Controlled Document is: did:keri:EINmHd5g7iV-UldkkkKyBIHO52blyxZNBn9pqg-\nzNrYoS?service=vlei-documents&relativeRef=/egf/docs/2022-12-16_verifiable-LEI-(VLEI)-Ecosystem-\nGovernance-Framework-Governance-Requirements_v1.0 fina\n\n1 Governance Requirements Documentation\n\nGiven this strong governance, GLEIF thinks that this reinforces the role that GLEIF would take as the\nRoot of Trust for the VLEI system, that the strong governance of the LEI would add strength to the\ninclusion of the LEl in vLEls.\n\n1. The governance of the Global Legal Entity Identifier Foundation (GLEIF) can be found at\nhttps://www.gleif.org/en/about/governance#\n\n2. The Memorandum of Understanding between the GLEIF and the Regulatory Oversight\nCommittee (ROC) can be found at https://www.gleif.org/en/about/governance/mou-\nbetween-gleif-and-lei-roc#\n\n3. The Charter of the Regulatory Oversight Committee (ROC) can be downloaded as a pdf, LEI\nRegulatory Oversight Committee Charter\n\n4. The Statutes of GLEIF can be downloaded as a pdf, GLEIF Statutes\n\n5. The By-laws of GLEIF can be downloaded as a pdf, GLEIF By-laws\n\n6. GLEIF has a Board of independent directors,\nhttps://www.gleif.org/en/about/governance/board-of-directors#\n\n7. The LEl standard, ISO 17442-1:2020 Financial services — Legal entity identifier (LEI) — Part 1:\nAssignment can be found here: https://www.iso.org/standard/78829.html\nThe LEI standard, 1SO 17442-2:2020 Financial services — Legal entity identifier (LEI) — Part 2:\nApplication in digital certificates can be found here:\nhttps://www.iso.org/standard/79917.html\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 2 of 2\n\nGovernance Requirements\n\nPublic Document Version 1.0\nGLEIF 2022-12-16_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2022-12-16\n\nGovernance-Requirements_v1.0_final\n","contentLength":2219,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:17:58.539Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-business-requirements_v1.0_final.pdf","content":"O:GLEIF, Protecting digital st\nverifiable LEI (vLEI)\nEcosystem Governance Framework v1.0\nBusiness Requirements\nPublic\nDocument Version 1.0\n2022-12-16\n. . - I!Q ry\n- . F . ‘ -\n- O - g“\\“ _{:. S ~=\ni 389,60 | :/ ; Soe— f.‘.\n. 2 . 4 _/ — T R ‘3?_.’ ’d b . o. . . . :\n: .' .‘ v’ Y?:\\\\ \"“ {{‘({ . o.o’ . . .-\n.‘__,, .. J ° ‘ A ° ®s O R . 3\n' . \" - ’ o\nN\n| Y\n","contentLength":353,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:18:12.888Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-business-requirements_v1.0_final.pdf","content":"verifiable LEI (VLEI) Ecosystem Governance\nFramework Technical Business Requirements\nThis Controlled Document specifies certain business requirements for the vLEI services of GLEIF and\nQualified vLEI Issuers (QVIs).\nThe DID URL for this Controlled Document is: did:keri:EINmHd5g7iV-UldkkkKyBIHO52blyxZNBn9pqg-\nzNrYoS?service=vlei-documents&relativeRef=/egf/docs/2022-12-16_verifiable-LEI-(VLEI)-Ecosystem-\nGovernance-Framework-Business-Requirements_v1.0_final\n1 Business Requirements\n1. QVIs MAY charge fees for the issuance, verification and/or revocation of Legal Entity vLEI\nCredentials and for Legal Entity Official Organizational Role vLEI Credentials.\n2. QVIs MAY offer ancillary services to Legal Entities regarding vLEls.\n3. There MUST be availability targets defined for all vLEI services included in Appendix 5 of the\nVLEI Issuer Qualification Agreement, Qualified vLEI Issuer Service Level Agreement (SLA).\n4. The QVI MAY review its fee schedule annually and unilaterally determine new fees.\n5. The QVI MUST be solely responsible for managing the revenue that is produced and costs\nthat are incurred in the running of its vLEIl operations.\n6. The QVI MUST ensure that its operations regarding vLEls are sustainably financed.\n7. GLEIF MUST not contribute funds of any form whatsoever for QVI operations.\n8. A Legal Entity MAY terminate its agreement with a QVI and contract with a new QVI at any\ntime in accordance with the terms of their contract with the QVI.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 2 of 2\nBusiness Requirements\nPublic Document Version 1.0\nGLEIF 2022-12-16_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2022-12-16\nBusiness-Requirements_v1.0_final\n","contentLength":1707,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:18:12.888Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-technical-requirements-part1-keri-infrastructure_v1.1_final.pdf","content":"O:GLEIF, Protecting digital st\nverifiable LEI (vLEI)\nEcosystem Governance Framework v1.0\nTechnical Requirements Part 1:\nKERI Infrastructure\nPublic\nDocument Version 1.1\n2023-04-03\nS A\n' £ N/ . e\n' U0, e . .\n° \" 5 SR 0’*’. \"‘ 4 B e .. g R :\n.\\‘ ; f ) ro ’{z‘({ ,_ . .O\" o * .o' ’ .. B\no' ‘.f 4 2 ° ° + » “ . .\nS ‘ , ‘ y - '. N\n2\n-\n","contentLength":329,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:18:51.200Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-technical-requirements-part1-keri-infrastructure_v1.1_final.pdf","content":"verifiable LEI (VLEI) Ecosystem Governance\nFramework Technical Requirements\nPart 1: KERI Infrastructure\nThis Controlled Document specifies the technical requirements for KERI (Key Event Receipt\nInfrastructure) Infrastructure for use by GLEIF and Qualified vLEI Issuers (QVIs) within the vLElI\nEcosystem Governance Framework.\nThe DID URL for this Controlled Document is: did:keri:EINmHd5g7iV-UldkkkKyBIHO52blyxZNBnSpg-\nzNrYoS?service=vlei-documents&relativeRef=/egf/docs/2023-04-03_verifiable-LEI-(VLEI)-Ecosystem-\nGovernance-Framework-Technical-Requirements-Part1-KERI-Infrastructure_v1.1 Final.docx\n1 KERI Specifications\n1.1 Specification References\nThe draft specifications for KERI family of capabilities can be found at:\nhttp://github.com/WebOfTrust/keri\n1.2 Specification Version Upgrades\nThese policies govern migrating to revisions of the KERI specifications.\n\n1. Previous versions explicitly cited by policies in this document MUST be supported for a\nperiod of 18 months.\n\n2. New versions MUST be implemented within a period of 12 months after final approval of the\nnew version, unless otherwise superseded by revised policies in a new version of the vLEI\nEcosystem Governance Framework.\n\n3. After upgrading to a new version, implementers MUST NOT begin using any breaking\nchanges until the end of the time period required to adopt new versions. For example, v2.0\nmust be compatible with v1.0 until the end of the v2.0 adoption period. So v2.0 must be\nused in a v1.0 compatible mode.\n\n2 Endorser (Backer) Management\n\nAn Endorser provides a secondary root-of-trust for a KEL (Key Event Log). Two types of Endorsers will\nbe supported initially: Witnesses and Registrars.\n\n2.1 Witness Pool\n\n1. MUST use a KERI Agreement Algorithm for Control Establishment (KAACE) sufficient majority\n\nthreshold on a minimum pool of 5 Witnesses.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 2 of 12\nTechnical requirements Part 1: KERI Infrastructure\nPublic Document Version 1.1\nGLEIF 2023-04-03_verifiable-LEI-(vLEI)-Ecosystem-Governance-Framework- 2023-04-03\nTechnical-Requirements-Part1-KERI-Infrastructure_v1.1_Final\n","contentLength":2126,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:18:51.200Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-technical-requirements-part1-keri-infrastructure_v1.1_final.pdf","content":"3. GLEIF External GARs MUST approve a QVI Rotation Event that occurs no less than six months\nfrom the last QVI Rotation Event.\n\n4. Qualified vLEI Issuer Authorized Representatives (QARs) MUST contact GLEIF External GARs\nfor approval of any QVI Rotation Event that occurs less than six months from the last QVI\nRotation Event.\n\n5. Signing keys MUST be rotated whenever there is a likelihood of key compromise.\n\n6. The time and place of key rotation MUST be kept confidential among the key holders until\nafter the rotation has been completed.\n\n7. Encryption keys protecting private keys SHOULD be rotated prophylactically at least quarterly\nand MUST be rotated whenever the associated signing key store host configuration changes.\n\n6.6 Delegation\n\n1. The Delegated AID of a Qualified vLEI Issuer MUST set the Do Not Delegate configuration\ntrait to True. (NOTE: This may change in future versions in order to accommodate horizontal\nscalability of the vLEl signing infrastructure.)\n\n6.7 Key Compromise Monitoring\nQualified vLEl Issuers:\n\n1. MUST monitor their public Witnesses for their vLEl issuance and revocation registry for\nerroneous or malicious issuances and revocations (primarily issuances) in order to inform\ntheir key management process that a key recovery may be required.\n\n2. SHOULD provide a capability for challenging the issuance, revocation or data contained\nwithin vLEls.\n\n6.8 Key Compromise Recovery\nIn case of key compromise:\n\n1. A Qualified vLEI Issuer MUST:\n\na. Report to GLEIF all key compromise recovery operations within 24 hours of gaining\nknowledge of the key compromise.\n\nb. Investigate as expeditiously as possible at its own expense the source of the key\ncompromise and make a full report of the investigation to GLEIF.\n\nc. Make arecovery rotation event that forks their KEL and submit the recovering\nrotation event and signatures to GLEIF in order that GLEIF may anchor a confirmation\nseal in its KEL.\n\nd. Send a key recovery event explanation to GLEIF for publication in GLEIF’s public\nregistry of Qualified vLEI Issuer recovery events.\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 11 of 12\n\nTechnical requirements Part 1: KERI Infrastructure\n\nPublic Document Version 1.1\nGLEIF 2023-04-03_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2023-04-03\n\nTechnical-Requirements-Part1-KERI-Infrastructure_v1.1_Final\n","contentLength":2362,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:18:51.200Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-technical-requirements-part1-keri-infrastructure_v1.1_final.pdf","content":"2. GLEIF MAY at its sole discretion:\na. Publicly disclose the compromise.\nb. Reissue all compromised vLEI Credentials at the sole expense of the Qualified vLEI\nIssuer regardless of any contractual terms to the contrary.\n6.9 vLEl Issuance and Revocation Policies\n\n1. Qualified vLEI Issuers MUST monitor their public Witnesses for their vLEl issuance and\nrevocation registry for erroneous or malicious issuances and revocations (primarily\nissuances) in order to inform their key management process that a key recovery may be\nrequired.\n\n6.10 Challenge Message Policies\nIn various policies throughout this Governance Framework, Challenge Messages are required for\ncryptographic authentication during real-time Out of Band Introduction (OOBI) sessions.\n\n1. The Challenge Message MUST include a cryptographic once generated in real time.\n\n2. The Challenge Response Message MUST be Fully Signed by the Responder.\n\n3. The Challenger MUST verify that:\n\na. The Fully Signed Response contains the same cryptographic once as the Challenge\nMessage.\nb. The signatures of the Responders were generated by the private keys that control\nResponder’s AID.\n6.11 Policies for Sharing Authenticated AIDs\nWhen new GARs of the GLEIF External AID or GLEIF Internal AID or QARs of the a Qualified vLEI Issuer\nAID are rotated into the the GAR or QAR group multisig AID, it will be necessary for the the new\nGARs/QARs to prepopulate their local database with contact information for authenticated AIDs\nfrom the existing GARs /QARs database.\n\n1. Contact sharing with new members of a group multisig AID MUST be performed by a\nthreshold satisfying number of existing members.\n\n2. New members MUST be able to Spot Check through Identity Authentication and the\nChallenge Response process any new authenticated AID they receive from existing members\nor their new group multisig AID.\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 12 of 12\n\nTechnical requirements Part 1: KERI Infrastructure\n\nPublic Document Version 1.1\nGLEIF 2023-04-03_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2023-04-03\n\nTechnical-Requirements-Part1-KERI-Infrastructure_v1.1_Final\n","contentLength":2147,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:18:51.200Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-technical-requirements-part1-keri-infrastructure_v1.1_final.pdf","content":"2. SHOULD use access control independent of the Controller keys for configuring the Witness\nhost and accepting events for witnessing. (NOTE: this avoids poisoning of Witnesses by\nController key compromise and adds an extra layer of security.)\n\n3. MUST publish Witnesses to at least one ecosystem discovery mechanism:\n\na. Well-Known URI IETF RFC-8615 on a web site(s)associated with entity. The value of\nthe /well-known/oobi resource is a OOBI (out-of-band-introduction) to witness or\nwitnesses\n\nb. Publish OOBIs for witnesses on web site(s) discoverable by search engines.\n\nc. KERI Distributed Hash Table (DHT)\n\nd. DID method resolvers\n\ne. Ledgers\n\n2.2 Registrar (Ledger)\n\n1. SHOULD use only one Registrar at a time for a given KEL;\n\n2. MUST use a GLEIF Approved DID Method (one for each authorized ledger):\n\na. Security guarantees are based on the particular ledger\n\nb. A DID method MUST be approved down to the ledger-specific level.\n\n2.3 Hybrid (Witness Pool and Ledger Registrar)\n\n1. MUST use only one type for any KEL;\n\n2. MAY use different types for each Delegated KEL at any level of a delegation hierarchy.\n3 Watcher Management\nValidators need to be protected by their Watcher network.\n\n1. Validators SHOULD choose Watchers carefully or else the integrity of the network will be\naffected.\n\n2. Validators MAY choose any number of Watchers.\n\n3. Ifa Validator is managing its own Watcher pool:\n\na. The Validator SHOULD use a minimum pool of three with a threshold of sufficient\nmajority threshold of 2 for consensus establishment.\n\nb. If using more than three Watchers, Validators SHOULD use a KAACE sufficient\nmajority threshold pool size greater than three.\n\n4. |If using a Watcher service, Validators SHOULD use a Watcher service that at a minimum self-\nasserts compliance with the GLEIF vLEI EGF.\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 3 of 12\n\nTechnical requirements Part 1: KERI Infrastructure\n\nPublic Document Version 1.1\nGLEIF 2023-04-03_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2023-04-03\n\nTechnical-Requirements-Part1-KERI-Infrastructure_v1.1_Final\n","contentLength":2102,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:18:51.200Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-technical-requirements-part1-keri-infrastructure_v1.1_final.pdf","content":"4 Key Management\nUnless otherwise specified, the term key-pair refers to an asymmetric (public, private) key-pair for\ndigital signatures. The private key is used to generate signatures and the public key is used to\nvalidate signatures. Ecosystem key management policies are grouped into three sets of policies for\nprotecting three different infrastructures:\n1. Key-pair creation and storage infrastructure;\n2. Signature creation infrastructure;\n3. Signature verification infrastructure.\n4.1 Key-Pair Creation and Storage Infrastructure\n4.1.1 Strength\nAll key-pairs MUST be generated using a cryptographic algorithm with at least 128 bits of\ncryptographic strength. This includes using a source of entropy of at least 128 bits of cryptographic\nstrength for the salt or seed used to generate the private key of the key pair.\nNOTE: Well known libraries provide cryptographic strength pseudo random number generators\n(CSPRNGs) sufficient to meet this condition. When practical, a true random number generator is\npreferable to a CSPRNG. In general, the codes in the CESR (Composable Event Streaming\nRepresentation) tables only support cryptographic operations with a minimum strength of 128 bits.\nExamples of compliant asymmetric digital signature algorithms include Ed25519 and\nEcDSASecp256kl. Unless otherwise specified, all key management policies assume use of the KERI\nprotocol for managing the authoritative key state for any Autotomic ldentifier (AID).\n4.1.2 Autonomic Identifiers (AIDs)\nAlIDs are self-certifying identifiers that are imbued with self-management capabilities via the KERI\nprotocol. There are two main classes of AIDs in KERI: 1) transferable AIDs, and 2) non-transferable\nAIDs. Key management policies are different for the two classes of AlDs.\n1. Both Authentic Chained Data Container (ACDC) Issuer and Issuee AIDs MUST be transferable.\n4.1.3 Key Pre-Rotation for Transferable AIDs\nIn KERI, the authoritative key state of a transferable AID consists of two sets of key-pairs. The first set\nis the current set of signing keys and the second set is the pre-committed set of one-time rotation\nkeys that after rotation will become the next or pre-rotated set of signing keys. These two sets\nprovide the basis for KERI’s pre-rotation mechanism.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 4 of 12\nTechnical requirements Part 1: KERI Infrastructure\nPublic Document Version 1.1\nGLEIF 2023-04-03_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2023-04-03\nTechnical-Requirements-Part1-KERI-Infrastructure_v1.1_Final\n","contentLength":2552,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:18:51.200Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-technical-requirements-part1-keri-infrastructure_v1.1_final.pdf","content":"1. The next or pre-rotated set of keys MUST be protected with the highest level of protection.\nThis level of protection should be commensurate with the value of the assets these keys are\nprotecting.\n\n2. Non-delegated pre-rotated keys are at the root level of a delegation hierarchy and MUST\nhave the very highest level of protection. There is no recovery mechanism within KERI to\nregain control over a non-delegated AID once its pre-rotated keys have been captured. The\nonly recourse is to abandon the AID and stand up a new AID and re-establish the reputation\nand associations of the new AID. This re-establishment process is ecosystem dependent and\nis not part of KERI.\n\n3. Delegated pre-rotated keys MAY have a lower level of protection because the Delegator may\nrecover the loss or compromise of delegated pre-rotated keys. Valid KERI delegations are\ncooperative in that they require verified signatures from both the Delegator and Delegate\nthus requiring an attacker to compromise both sets of keys.\n\n4.1.4 Non-Transferable AIDs\n\nNon-transferable AIDs are self-certifying but are not meant for long term persistent use and hence\ntheir key-pair(s) are not rotatable. Instead, the identifier is abandoned and replaced with a new\nidentifier with a new set of key-pair(s). These may also be called ephemeral AIDs. Within KERI, the\nprimary use for non-transferable (ephemeral) AIDs are for the Witness identifiers. Because Witnesses\nare used in a pool, the pool forms a threshold structure which provides protection from the exploit of\na minority of the key-pairs of the ephemeral Witness AIDs in the pool. If a given Witness AID has its\nkey(s) compromised, then the Witness AID itself is abandoned and replaced. Thus, the Witness pool\nmanagement policy protects Witness ephemeral AlDs.\n\n4.2 Signature Creation Infrastructure\n\nWhen statements are signed by the private key(s) for a given AID, the private key becomes exposed\nin the sense that it must be used in some computing device in order to compute the signature.\nComputing devices used to create a signature of, or sign, a statement are part of the signature\ncreation infrastructure. A typical attack on signing infrastructure would be to observe or capture the\nprivate key while in the memory of the computing or signing device.\n\nAnother layer of protection is provided by the Witness pool which must endorse all events.\n\n1. The signature creation or signing infrastructure for AIDs SHOULD be protected within some\nform of a TEE (Trusted Execution Environment).\n\n2. Aseparate layer of access control SHOULD be imposed on a Controller’s Witnesses with\nMulti-factor Authentication (MFA) such that a Witness will only endorse events with MFA.\nThis provides a threshold structure where an attacker must also compromise the access\nintegrity of a sufficient number of Witnesses.\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 5 of 12\n\nTechnical requirements Part 1: KERI Infrastructure\n\nPublic Document Version 1.1\nGLEIF 2023-04-03_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2023-04-03\n\nTechnical-Requirements-Part1-KERI-Infrastructure_v1.1_Final\n","contentLength":3126,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:18:51.200Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-technical-requirements-part1-keri-infrastructure_v1.1_final.pdf","content":"4.3 Signature Verification Infrastructure\n\nAn attack against signature verification infrastructure typically requires replacing the signature\nverification code with malicious code that falsely reports signature verification on signed statements.\nKERI provides a specific protection mechanism for signature verification via a Watcher pool where an\nevent is only accepted as verified if a sufficient majority of the Watchers in a pool agree on the\nverification status of the signature(s) on that event. This provides a threshold structure where an\nattacker must compromise the code integrity of a sufficient number of Watchers for successful\nattack. Because the composition of a Watcher pool does not need to be publicly disclosed, an\nattacker must also discover that composition to ensure a successful attack.\n\n1. Best practices for code delivery and library usage MUST be observed for signature\nverification infrastructure. Because the signature verification infrastructure need never be\npublicly disclosed an attacker must first discover what computing devices are being used to\nverify signatures.\n\n2. Either a TEE or a Watcher pool or both SHOULD be used to protect a signature verification\ninfrastructure. The entity harmed primarily by a compromise of a signature verification\ninfrastructure is the Verifier, not the Controller, and the degree of protection should be\ncommensurate with the degree of risk associated with faulty verification.\n\n5 GLEIF KERI Profile\nThis section specifies policies for GLEIF’'s own use of KERI.\n5.1 GLEIF Root AID Inception Event\n\n1. GLEIF MUST hold a recorded GLEIF Root AID genesis event with at least a minimum of three\n\nWitnesses.\nThe OOBI for the KEL for the GLEIF Root AID: (https://www.gleif.org/.well-\nknown/keri/oobi/EDP1vHcw wc4M Fj53-cJaBnZZASd-aMTaSyWEQ-PC2)\na. MUST be stored on the following GLEIF servers protected by extended validation\nHTTPS certificates:\ni. EU-FI-HTZ-01 65.21.253.212 Prod 1 Helsinki\nii. NA-CA-OVH-0151.79.54.121 Prod 1 Canada\niii. AF-ZA-AZR-01 102.37.159.99 Prod 1 South Africa\niv. SA-BR-AWS-01 54.233.109.129 Prod 1 Brazil\nv. AS-CN-ALI-01 8.210.213.186 Prod 1 China\nvi. OC-AU-OVH-0151.161.130.60 Prod 2 Sydney\nvii. NA-US-HTZ-015.161.49.239 Prod 2 Ashburn\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 6 of 12\nTechnical requirements Part 1: KERI Infrastructure\nPublic Document Version 1.1\nGLEIF 2023-04-03_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2023-04-03\nTechnical-Requirements-Part1-KERI-Infrastructure_v1.1_Final\n","contentLength":2520,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:18:51.200Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-technical-requirements-part1-keri-infrastructure_v1.1_final.pdf","content":"viii. AS-JP-AZR-01 20.78.61.227 Prod 2 Japan\nix. AF-ZA-AWS-01 13.244.119.106 Prod 2 South Africa\nX. EU-UK-ALI-01 8.208.27.153 Prod 2 United Kingdom\nb. MUST be stored at the HTTPS URLs of the following affiliated organizations:\ni. Qualified vLEI Issuers\nc. MUST be stored as a file on a public GLEIF GitHub repository.\nd. MUST be shared on the following social media:\ni. Linkedln and Twitter\n5.2 GLEIF Root AID\n\n1. Non-delegated pre-rotated keys are at the root level of the delegation hierarchy and MUST\nhave the very highest level of protection.\n\n2. MUST be a threshold multisig with weighting requirements that have been determined by\nGLEIF.\n\n3. Key Pair Creation and Storage Infrastructure MUST be within a TEE.\n\n4. Each key-pair in a thresholded multi-sig MUST use a non-co-located TEE.\n\n5. Signature Creation Infrastructure SHOULD be within a TEE.\n\n6. Signature Verification Infrastructure SHOULD be within a TEE.\n\n5.3 GLEIF Root Witness Pool\n\n1. The Witness Pool configuration MUST include a minimum of 5 with the sufficient threshold\nas per KAACE.\n\n2. The number of Witnesses on any single web host provider MUST be less than the sufficient\nthreshold as per KAACE (NOTE: this prevents a single web host provider from hosting a\nmajority of Witnesses.)\n\n3. The number of Witnesses on any single continent MUST be less than the sufficient threshold\nas per KAACE.\n\n4. The number of Witnesses in any single political jurisdiction MUST be less than the sufficient\nthreshold as per KAACE.\n\n5. GLEIF Root Witness Signing Key Pair key store MAY reside on the Witness Service host but\nMUST use dedicated user only permissions on the key store directory and its contents. The\nsecrets in the key store MUST be encrypted with the key loaded dynamically whenever the\nWitness service is started. The key store MUST reside on a different device or host from that\nof the Witness service. The Witness encryption key store SHOULD be a Hardware Security\nModule (HSM). The Witness signing key store MAY be a TEE.\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 7 of 12\n\nTechnical requirements Part 1: KERI Infrastructure\n\nPublic Document Version 1.1\nGLEIF 2023-04-03_verifiable-LEI-(vLEI)-Ecosystem-Governance-Framework- 2023-04-03\n\nTechnical-Requirements-Part1-KERI-Infrastructure_v1.1_Final\n","contentLength":2295,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:18:51.200Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-technical-requirements-part1-keri-infrastructure_v1.1_final.pdf","content":"5.4 GLEIF Internal Delegated AIDs (GIDASs)\nThe GLEIF Internal AID is the identifier used by GLEIF to be able to participate in the vLEl Ecosystem\nand Infrastructure as a vLEI Holder. They are identical to the policies for the GLEIF Root AID except:\n1. Key Pair Creation and Storage Infrastructure SHOULD be within a TEE.\n2. Each key-pair in a thresholded multi-sig SHOULD use a non-co-located TEE.\n5.5 GLEIF External Delegated AIDs (GEDAs)\nThese policies are used by GLEIF to issue the Qualified vLEl Issuer vLEI Credentials and Qualified vLElI\nIssuer Delegated AlIDs. They are the same as GLEIF Internal Delegated AID policies except:\n1. GLEIF MUST set the Do Not Delegate configuration property on Qualified vLEI Issuer\nDelegated AlDs.\nNOTE: This may change in the future to enable horizontal scalability.\n5.6 GLEIF Witness Network\nThese policies are for issuance and revocation state of vLEls.\n1. GLEIF SHOULD use the same Witness pools as the vLEI or QVIs.\n5.7 GLEIF Watcher Network\n1. The GLEIF Watcher Network SHOULD be protected by a Watcher pool of at least 3 members\nwith a threshold of 2.\n2. Larger pool sizes MUST use KAACE sufficient majority thresholds.\n3. The GLEIF Watcher Signing Key Pair key store MAY reside on the Watcher Service host but\nMUST use dedicated user only permissions on the key store directory and its contents.\n4. The secrets in the key store SHOULD be encrypted with the key loaded dynamically\nwhenever the Watcher service is started.\n5. When used, the encryption key store MUST reside on a different device or host from that of\nthe Watcher service.\n6. The Watcher encryption key store MAY be an HSM.\n7. The Watcher signing key store MAY be a TEE.\n5.8 GLEIF Key Management\n1. The specific holders of cryptographic keys MUST be kept confidential and shall be\ndetermined by GLEIF internal policy.\n2. Signing keys SHOULD be rotated prophylactically no more often than once every six months\nand no less often once every two years but on an unpredictable schedule.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 8 of 12\nTechnical requirements Part 1: KERI Infrastructure\nPublic Document Version 1.1\nGLEIF 2023-04-03_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2023-04-03\nTechnical-Requirements-Part1-KERI-Infrastructure_v1.1_Final\n","contentLength":2286,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:18:51.200Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-technical-requirements-part1-keri-infrastructure_v1.1_final.pdf","content":"3. Signing keys MUST be rotated whenever there is a likelihood of key compromise.\n4. The time and place of key rotation MUST be kept confidential among the key holders until\nafter the rotation has been completed.\n5. Encryption keys protecting private keys SHOULD be rotated prophylactically at least quarterly\nand MUST be rotated whenever the associated signing key store host configuration changes.\n6. GLEIF policies for approving rotation of the issuing keys for the GLEIF-Delegated issuing\nidentifier:\na. MUST use an OOB (out-of-band) MFA (multi-factor authorization) mechanism to\napprove Delegated AID rotation.\nb. SHOULD use an off-the-shelf MFA tool.\n6 Qualified vLEI Issuer KERI Profile\nThis section specifies the KERI policies that apply to Qualified vLEI Issuers.\n6.1 Qualified vLEI Issuer Distribution\n1. GLEIF SHOULD encourage and promote a diverse distribution of Qualified vLEI Issuers across\npolitical jurisdictions and geographies.\n6.2 Delegated AIDs\n1. For added security, Qualified vLEI Issuers:\na. MUST use Delegated AlIDs from GLEIF for issuing vLEls or all types.\nb. MUST use at least multi-sig scheme of at least 3 signers with a threshold of 2.\nc. MAY use a TEE to protect their Delegated pro-rotated AID keys.\n2. Key Pair Creation and Storage Infrastructure SHOULD be within a TEE.\n3. Each key-pair in a thresholded multi-sig MUST use a non-co-located key store.\n4. Signature Creation Infrastructure SHOULD be within a TEE.\n5. Signature Verification Infrastructure SHOULD be within a TEE.\n6.3 Endorser Support: Witness Pool or Ledger Registrar\n1. An Endorser MUST use either a Witness Pool or a Ledger Registrar for Endorsement\n6.3.1 Witness Pool\n1. The Witness Pool configuration MUST include a minimum of 5 with the sufficient threshold\nas per KAACE.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 9 of 12\nTechnical requirements Part 1: KERI Infrastructure\nPublic Document Version 1.1\nGLEIF 2023-04-03_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2023-04-03\nTechnical-Requirements-Part1-KERI-Infrastructure_v1.1_Final\n","contentLength":2068,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:18:51.200Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-technical-requirements-part1-keri-infrastructure_v1.1_final.pdf","content":"2. The Witness Signing Key Pair key store MAY reside on the Witness Service host but MUST use\ndedicated user only permissions on the key store directory and its contents.\n3. The secrets in the key store SHOULD be encrypted with the key loaded dynamically\nwhenever the Witness service is started.\n4. The encryption key store MUST reside on a different device or host from that of the Witness\nservice.\n5. The Witness encryption key store SHOULD be an HSM.\n6. The Witness signing key store MAY be a TEE.\n6.3.2 Ledger Registrar\n1. The Registrar Signing Key Pair key store MAY reside on the Registrar Service host but MUST\nuse dedicated user only permissions on the key store directory and its contents.\n2. The secrets in the key store SHOULD be encrypted with the key loaded dynamically\nwhenever the Registrar service is started.\n3. The encryption key store MUST reside on a different device or host from that of the Registrar\nservice.\n4. The Registrar encryption key store SHOULD be an HSM.\n5. The Registrar signing key store MAY be a TEE.\n6.4 Watchers\n1. Watchers SHOULD be protected by a Watcher pool of at least 3 members with a threshold of\n2.\n2. Larger pool sizes MUST use KAACE sufficient majority thresholds.\n3. Watcher Signing Key Pair key store MAY reside on the Watcher Service host but MUST use\ndedicated user only permissions on the key store directory and its contents.\n4. The secrets in the key store SHOULD be encrypted with the key loaded dynamically\nwhenever the Watcher service is started.\n5. When used, the encryption key store MUST reside on a different device or host from that of\nthe Witness service.\n6. The Watcher encryption key store MAY be an HSM.\n7. The Watcher signing key store MAY be a TEE.\n6.5 Key Management\n1. The specific holders of cryptographic keys MUST be kept confidential and shall be\ndetermined by Qualified VvLEI Issuer internal policy.\n2. Signing keys SHOULD be rotated prophylactically no more often than once every six months\nand no less often once every two years but on an unpredictable schedule.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 10 of 12\nTechnical requirements Part 1: KERI Infrastructure\nPublic Document Version 1.1\nGLEIF 2023-04-03_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2023-04-03\nTechnical-Requirements-Part1-KERI-Infrastructure_v1.1_Final\n","contentLength":2334,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:18:51.200Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-technical-requirements-part2-vlei-credentials_v1.0_final.pdf","content":"OGLEIF’ Protecting digital st\nverifiable LEI (vLEl)\nEcosystem Governance Framework v1.0\nTechnical Requirements Part 2: vLEl Credentials\nPublic\nDocument Version 1.0\n2022-12-16\nS L\no - ” AN 4\n' S N . e\n' ey . F . .\n\ni - - \".‘-‘.}:3 ‘.' ¥ e .o o 2 :\no . el ’o.,{{-r(f,,...‘g e . .\no“ .' .. \" ° ‘ A ® » L » . 3\n\no B\n.\n","contentLength":314,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:19:12.011Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-technical-requirements-part2-vlei-credentials_v1.0_final.pdf","content":"verifiable LEI (vLEI) Ecosystem Governance\nFramework Credential Technical Requirements\nThis Controlled Document will cover all policies regarding the technical requirements for the vLEI\nfamily of Authentic Chained Data Container (ACDC) Credentials, v0.1.\nThe DID URL for this Controlled Document is: did:keri:EINmHd5g7iV-UldkkkKyBIHO52blyxZNBn9pg-\nzNrYoS?service=vlei-documents&relativeRef=/egf/docs/2022-12-16_verifiable-LEI-(VLEI)-Ecosystem-\nGovernance-Framework-Technical-Requirements-Part2-vLEI-Credentials_v1.0_final.docx\n1 Credential Specifications\nThe following policies are necessary to achieve, in order of priority, the security, performance and\nusability requirements for the vLEI Ecosystem.\n1.1 Specification References\nVLEI credentials rely on the following specifications.\n1. JSON Required\nhttps://datatracker.ietf.org/doc/html/rfc7159\n2. JSON Schema Version 2020-12\nhttps://json-schema.org/draft/2020-12/json-schema-core.html\n3. KERI Decentralized Identifiers (AlDs) did:keri Specification\nhttps://github.com/WebOfTrust/did-keri\n4. Autonomic Identifiers (AIDs)) for Issuers and Holders using the KERI protocol\nhttps://github.com/WebOfTrust/ietf-keri\n5. Self Addressing Identifiers (SAIDs)\nhttps://github.com/WebOfTrust/ietf-said\n6. TolP Authentic Chained Data Container (ACDC) Specification\nhttps://github.com/trustoverip/tswg-acdc-specification\n7. Composable Event Streaming Representation (CESR) Specification\nhttps://github.com/WebOfTrust/cesr\n8. Composable Event Streaming Representation (CESR) Proof Format\nhttps://github.com/WebOfTrust/cesr-acdc-proof\n9. Issuance and Presentation Exchange Protocol Specification (IPEX)\nhttps://github.com/WebOfTrust/ietf-ipex\n10. Public Transaction Event Log (PTEL) Specification\nhttps://github.com/WebOfTrust/ietf-ptel\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 2 of 5\nTechnical Requirements Part 2: vLEI Credentials\nPublic Document Version 1.0\n@ 2022-12-16_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2022-12-16\nTechnical-Requirements-Part2-vLEI-Credentials_v1.0_final.docx\n","contentLength":2061,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:19:12.011Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-technical-requirements-part2-vlei-credentials_v1.0_final.pdf","content":"1.2 Specification Version Upgrades\nThese policies govern migrating to revisions of the vLEI credential specifications.\n\n1. Previous versions explicitly cited by policies in this document MUST be supported for a\nperiod 18 months.\n\n2. New versions MUST be implemented within a period 12 months after final approval of the\nnew version, unless otherwise superseded by revised policies in a new version of the VLElI\nEcosystem Governance Framework.\n\n3. After upgrading to a new version, implementers MUST NOT begin using any breaking\nchanges until the end of the time period required to adopt new versions. For example, v2.0\nmust be compatible with v1.0 until the end of the v2.0 adoption period. So v2.0 must be\nused in a v1.0 compatible mode.\n\n2 Security and Privacy\nRequired Cryptographic Suites and Security\n\n1. All signatures for the vLEI credentials MUST use Ed25519 Signatures CESR Proof Format.\n\n2. All vLEI credential schema MUST be SIS compliant.\n\n3. Allinstantiated vLEI credentials MUST be ACDC compliant.\n\n4. All SAIDs MUST use the cryptoBlake3-256 digest.\n\nThe Legal Entity Engagement Context Role vLEI Credentials MAY include PII (personal identifying\ninformation) and may therefore require some form of privacy protection which is defined in the Legal\nEntity Engagement Context Role vLEI Credential Framework.\n\n3 Requirements for vLEI ACDCs\n\nThe ACDC specification is provided here: hhttps://github.com/trustoverip/tswg-acdc-specification\n\n1. Issuer and Holder Identifiers MUST be KERI AIDs that use the did:keri Method.\n\n2. Al vLEI credentials MUST include an ACDC version string field.\n\n3. AllvLEI credentials MUST support JSON serialization.\n\n3.1 Additional serializations MAY be introduced at a later time.\n4. AllvLEI credentials MUST include a SAID (as evidence of immutability).\n5. The following ACDC sections MUST include a SAID.\no Attribute (data payload) section\no Schema section\no Rules section\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 3 of 5\nTechnical Requirements Part 2: vLEI Credentials\nPublic Document Version 1.0\nGLEIF 2022-12-16_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2022-12-16\nTechnical-Requirements-Part2-vLEI-Credentials_v1.0_final.docx\n","contentLength":2205,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:19:12.011Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-technical-requirements-part2-vlei-credentials_v1.0_final.pdf","content":"6. Subsections of the preceding sections MAY include a SAID.\n\n7. All source links MUST include the SAID of the referenced ACDC.\n\n8. ACDCs have three primary forms that MUST be supported separately by Issuers, Holders and\nVerifiers using the following rules.\n\nForm 1 — the Fully-expanded Form in which the schema, attributes and rules are fully\nexpanded and embedded.\n\nForm 2 —the Fully-compressed Form in which only the SAID of each major section is\nincluded.\n\nForm 3 — Schema-compressed Form so the only SAID of the schema section is\nincluded.\n\n9. Issuers MUST support the issuance of vLEI credentials in any or all three forms.\n\n10. Issuers MUST provide the SAIDs at issuance to Holders when issuing forms 2 and 3, by either\nincluding the SAID in the presentation or including a reference to the highly-available service\nendpoint from which the SAID can be retrieved.\n\n11. Verifiers SHOULD support the verification at presentation of vLEI credentials in any of the\nthree forms.\n\n12. Holders SHOULD provide the SAIDs to Verifiers when presenting forms 2 and 3, by either\nincluding the SAID in the presentation or including a reference to the highly-available service\nendpoint from which the SAID can be retrieved.\n\n13. vLEl credential Issuers SHOULD use the Rules section of the credential in accordance with the\nACDC specification to impose restrictions on the use of the credential or its attributes.\n\n14. vLEl credential Issuers SHOULD use the Sources section of the credential in accordance with\nthe ACDC specification to impose delegated authorization restrictions on the use of the\ncredential and/or in conjunction with policy statement 13 above.\n\n4 vLEIl Credential Schema\n\n1. vLEl credential schema MUST be compliant the SAID and SIS specifications.\n\n2. AllvLEI credential schema MUST include a SAID (as evidence of immutability).\n\n3. Each vLEI credential MUST be in compliance with its specific vLEI Credential Governance\nFramework.\n\n3.1. Each vLEI Credential MUST be chained to its source(s), if any, as required by the\napplicable vLEI Credential Governance Framework in accordance with the ACDC\nspecification.\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 4 of 5\n\nTechnical Requirements Part 2: vLEI Credentials\n\nPublic Document Version 1.0\nGLEIF 2022-12-16_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2022-12-16\n\nTechnical-Requirements-Part2-vLEI-Credentials_v1.0_final.docx\n","contentLength":2416,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:19:12.011Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-technical-requirements-part2-vlei-credentials_v1.0_final.pdf","content":"5 Composable Event Streaming Representation\n1. The Proof Format for vLEI credentials MUST comply with the Composable Event Streaming\nRepresentation (CESR) Proof Format specification.\n1.1. Additional proof formats MAY be introduced at a later time.\n6 Credential issuance and Revocation Registry\nrequirements\n1. Each vLEl credential Issuer MUST maintain a highly-available issuance and registration\nregistry in compliance with the Public Transaction Event Log (PTEL) Specification.\n2. Infrastructure for the available issuance and registration registries MAY be shared.\n3. Support for privacy-preserving issuance and revocation MAY be supported at a later time.\n7 Exchange Protocols\n1. vLEl credential Issuers MUST comply with the Issuance Exchange Protocol Specification for\nACDC and KERI.\n2. VLEl credential Holders SHOULD comply with the Issuance Exchange Protocol Specification\nfor ACDC and KERI.\n3. VvLEl credential Holders and Verifiers SHOULD comply with the Presentation Exchange\nProtocol Specification for ACDC and KERI.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 5 of 5\nTechnical Requirements Part 2: vLEI Credentials\nPublic Document Version 1.0\nGLEIF 2022-12-16_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2022-12-16\nTechnical-Requirements-Part2-vLEI-Credentials_v1.0_final.docx\n","contentLength":1318,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:19:12.011Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-technical-requirements-part_3-vlei-credential-schema-registry_v1.pdf","content":"O:GLEIF, Protacting digial st\nverifiable LEI (vLEI)\nEcosystem Governance Framework v1.0\nTechnical Requirements Part 3:\nVLEI Credential Schema Registry\nPublic\nDocument Version 1.0\n2022-12-16\nS e A\no - ” AN 4\n' S N . e\n' T & = .\n\ni - - Wt '}s/. ‘.' ¥ e .o o 2 :\nN ’o.,{{-r(f,,...‘g EmeS . .\no“ .' .. \" ° ‘ A ® » L » . 3\n\no B\n-\n","contentLength":325,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:19:31.698Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-technical-requirements-part_3-vlei-credential-schema-registry_v1.pdf","content":"verifiable LEI (VLEI) Ecosystem Governance\nFramework Technical Requirements Part 3:\nVLEI Credential Schema Registry\nThis Controlled Document specifies all policies regarding the publication of the official JSON Schema\nfor the vLEI credentials.\nThe DID URL link for this Controlled Document is: did:keri:EINmHd5g7iV-\nUldkkkKyBIHO52blyxZNBn9pg-zNrYoS?service=vlei-documents&relativeRef=/egf/docs/2022-12-\n16_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework-Technical-Requirements-Part 3-vLEI-\nCredential-Schema-Registry_v1.0_final.docx\n1 Related Specifications\nJSON Schema\nJSON Schema 2020-12\nhttps://ison-schema.org/draft/2020-12/release-notes.html\nACDC\nIETF ACDC (Authentic Chained Data Containers) Internet Draft\nhttps://github.com/trustoverip/tswg-acdc-specification\nSAID\nIETF SAID (Self-Addressing IDentifier) Internet Draft\nhttps://github.com/WebOfTrust/ietf-said\nCESR\nIETF CESR (Composable Event Streaming Representation) Internet Draft\nhttps://github.com/WebOfTrust/ietf-cesr\nSemantic Versioning\nSemantic Versioning Specification 2.0\nhttps://semver.org\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 2 of 5\nTechnical Requirements Part 3 vLEI Credential Schema Registry\nPublic Document Version 1.0\n2022-12-16_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2022-12-16\nGLEIF Technical-Requirements-Part 3-vLEI-Credential-Schema-\nRegistry_v1.0_final\n","contentLength":1379,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:19:31.698Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-technical-requirements-part_3-vlei-credential-schema-registry_v1.pdf","content":"2 Official vLEI Credential Schema\n\n2.1 Requirements\n\nA SAID (Self-Addressing Identifier) is an encoded agile cryptographic digest of the contents of the\nschema. Any change to the schema results in a new SAID. Therefore each and every version of any\nschema has a universally unique SAID across all schema and all versions of all schema. Any copy of a\nschema that verifies against the SAID published in the following table can be assumed to be identical\nto any other copy that verifies to the same SAID by virtue of the strong collision resistance of the\ndigest employed.\n\n1. The digest algorithm employed for generating schema SAIDs MUST have an approximate\ncryptographic strength of 128 bits.\n\n2. The SAID MUST be generated in compliance with the IETF-SAID internet draft specification\nand MUST be encoded using CESR. The CESR encoding indicates the type of cryptographic\ndigest used to generate the SAID.\n\n3. The schema MUST be JSON-Schema 2020-12 compliant. The table in 2.3 below provides the\nnormative SAIDs for each of the official schema.\n\n2.2 Versioning\n\nAs ACDCs (Authentic Chained Data Containers), the vLEI schema uses composition operators from\nJSON Schema. This allows extensibility in schema such that in many cases, newer schema versions\nmay be backward compatible with older schema versions. A new schema version is considered\nbackward incompatible with respect to a previous version of a schema when any instance of a vLEl\ncredential that validates against the previous version of the schema may not be guaranteed to\nvalidate against the new version.\n\n1. As perthe semantic versioning rules, a backward incompatible schema MUST have a higher\nMAJOR version number than any backward incompatible version.\n\n2.3 Schema Table\nThe following table provides, in descending order, row-by-row, the latest version, the SAID, and the\ntype of each official schema, along with a URL. The URL is a network location where a copy of the\nschema may be obtained. Updated versions will be added to the top of the table upon designation by\nGLEIF as official Governing Body of the vLEI Ecosystem. The version number for each schema follows\nthe Semantic Versioning 2.0.0 specification.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 3 of 5\nTechnical Requirements Part 3 vLEI Credential Schema Registry\nPublic Document Version 1.0\n2022-12-16_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2022-12-16\nGLEIF Technical-Requirements-Part 3-vLEI-Credential-Schema-\nRegistry_v1.0_final\n","contentLength":2495,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:19:31.699Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-technical-requirements-part_3-vlei-credential-schema-registry_v1.pdf","content":"ELariXX1 https://github.com/WebOfTrust/\nrl -\na . . vLEIl/blob/dev/schema/acdc/qual\n1.0.0 IbV9zgXP4BXxqllpZTgF | QualifiedvLElIssuervLEICredential | ;\ni ) ified-vLEl-issuer-vLEI-\nchll3cyjaCyVKiz L\ncredential.json\nEKOjwjlbtYLlynGtmXXL https://github.com/WebOfTrust/\n1.0.0 05MGJ7BduX2vr2_Mh | LegalEntityvLEICredential vLEIl/blob/dev/schema/acdc/legal\nM9QjAXZ -entity-vLEl|-credential.json\nEdqjl80uPOr_SNSp- https://github.com/WebOfTrust/\n1.0.0 ylmpLGgITEbOwg077 | OORAuthorizationvLEICredential vLEIl/blob/dev/schema/acdc/oor-\nwsOPjyRVKy authorization-vlei-credential.json\nEIL- https://github.com/WebOfTrust/\n10.0 Rwno8cEnkGTi9cr7- LegalEntityOfficialOrganizationalR | vLEI/blob/dev/schema/acdc/legal\no PFg_IXTPx9fZ0r9snFFZ | olevLEICredential -entity-official-organizational-\nOnm role-vLEI-credential.json\nED_PcIn1wFDe0OGBOW https://github.com/WebOfTrust/\n1.0.0 7Bk914Q_c9bQJZCM2 | ECRAuthorizationvLEICredential vLEIl/blob/dev/schema/acdc/ecr-\nW7Ex9PIsta authorization-vlei-credential.json\nhttps://github.com/WebOfTrust/\nEohcE9MVIO0LrygJuYN .\nLegalEntityEngagementContextRol | vLEI/blob/dev/schema/acdc/legal\n1.0.0 INOC5XXNFkzwFxUBf . .\nevLEICredential -entity-engagement-context-role-\nQ24v7qgeEY -\nvLEl-credential.json\nEJEMDhCDi8gLgtaXrb3 https://github.com/WebOfTrust/\n1.0.0 6DRLHMfC1c08PqirQv | iXBRLDataAttestation vLEIl/blob/dev/schema/acdc/verif\ndPPSG5u iable-ixbrl-report-attestation.json\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 4 of 5\nTechnical Requirements Part 3 vLEI Credential Schema Registry\nPublic Document Version 1.0\n2022-12-16_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2022-12-16\nGLEIF Technical-Requirements-Part 3-vLEI-Credential-Schema-\nRegistry_v1.0_final\n","contentLength":1712,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:19:31.699Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-technical-requirements-part_3-vlei-credential-schema-registry_v1.pdf","content":"3 Informative Notes\nAt some time in the future, this registry document may be augmented with a live registry that follows\nthe future Trust over IP (TolP) Trust Registry Protocol specification. The current in progress draft may\nbe found here: https://docs.google.com/document/d/1ZGXUB0oODHO66PQk0O66-\nfbAu6f7sVVTo0z3Q8RNGOfs/edit\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 5 of 5\n\nTechnical Requirements Part 3 vLEI Credential Schema Registry\n\nPublic Document Version 1.0\n\nO 2022-12-16_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2022-12-16\n@ Technical-Requirements-Part 3-vLEI-Credential-Schema-\nRegistry_v1.0_final\n","contentLength":647,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:19:31.699Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-vlei-ecosystem-information-trust-policies_v1.0_final.pdf","content":"@’ Protecting digital rust\nverifiable LEI (vLEI)\nEcosystem Governance Framework v1.0\nVLEI Ecosystem Information Trust Policies\nPublic\nDocument Version 1.0\n2022-12-16\nB ~ -,: o S —\n| '60 e e ew\nVLl SR oy .. . - :\n.\\‘ ’ f ¢ \" ‘T-n\\ ; ’ {:{{ ,. - o’ o * ..4 : .. B\n.“- e (\"’ \\ { A .oo. : . : '\no - 2\nP\nLY\n","contentLength":302,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:19:54.160Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-vlei-ecosystem-information-trust-policies_v1.0_final.pdf","content":"verifiable LEI (vLEI) Ecosystem Governance Framework\nvLEI Ecosystem Information Trust Policies\ndid:keri:EINmHd5g7iV-UldkkkKyBIHO52blyxZNBn9pq-\nzNrYoS?service=vlei-documents&relativeRef=/egf/docs/2022-12-\n16_verifiable-LEI-(vLEl)-Ecosystem-Information-Trust-\nPolicies_v1.0_final.docx\n_ Global Legal Entity Identifier Foundation (GLEIF)\nThe verifiable LEI (vLEI) Ecosystem Governance Framework is published\non the GLEIF website. All documents published on the GLEIF website are\npublished under the Creative Commons Attribution license.\n1 Introduction\nThis is a Controlled Document of the GLEIF vLEI Ecosystem Governance Framework (VLEI Ecosystem\nGovernance Framework). The document defines the information security, privacy, availability and\nconfidentiality policies that apply to all vLEI Ecosystem stakeholders regardless of their particular role\nor the particular type of vLEI being exchanged. Policies that apply to the issuance, holding, or\nverification of a specific type of vLEI are defined in the vLEI Credential Governance Framework for\nthat credential type.\n2 Terminology\nAll terms in First Letter Capitals are defined in the vLEI Glossary.\n3 Regulatory Compliance\nVLEI Ecosystem stakeholders MUST comply with any governmental regulations for information\nsecurity to which their activities within the vLEI Ecosystem will be subject. This includes International\nor trans-national governance authorities (e.g., ISO/IEC 27001 — Information Security Management,\nEU General Data Protection Regulation (GDPR).\n4 vLEl Ecosystem Stakeholder Privacy Policies\n1. Legal Entities that receive VLEI Legal Entity Credentials SHOULD ensure that their privacy\npolicies adequately protect the persons to whom the Legal Entity requests Legal Entity\nOfficial Organizational Role VLEIl Credentials and Legal Entity Engagement Context Role VLEI\nCredentials.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 2 of 5\nVLEI Ecosystem Information Trust Policies\nPublic Document Version 1.0\nGLEIF 2022-12-16_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2022-12-16\nVLEI-Ecosystem-Information-Trust-Policies_v1.0_final\n","contentLength":2120,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:19:54.161Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-vlei-ecosystem-information-trust-policies_v1.0_final.pdf","content":"2. The vLEIl Ecosystem Credential Governance Frameworks MUST specify the information to be\nprotected by the applicable privacy policy in the jurisdiction of the Legal Entity.\n\n5 VLEI Ecosystem Stakeholder Data Protection\n\nPolicies\n\n1. VLEI Ecosystem stakeholders MUST confirm that they respect and comply with data\nprotection legislation as applicable and in force.\n\n2. Where no such legislation is in force, and as a material minimum standard, vLEIl Ecosystem\nstakeholders MUST comply with the provisions of the Swiss Federal Data Protection Act\nspecified in the Appendix to this policy document.\n\n3. VLEI Ecosystem stakeholders MAY use Personal Data for the purpose of performing their\nobligations and rights under this Agreement. vLEI Ecosystem stakeholders MUST comply\nwith:\n\na. the material applicability of the provisions of the Swiss Federal Data Protection Act\nor\n\nb. about local data protection legislation applicable to the vLEI Ecosystem stakeholder if\nsuch legislation is equivalent or more rigorous.\n\n4. Qualified vLEl Issuers MUST annually review and document that the provisions are\nimplemented and enforced. Other vLEI Ecosystem stakeholders SHOULD undertake to\nregularly review and ensure that the provisions of this Section 5 are implemented and\nenforced.\n\n5. When a privacy breach is suspected, the involved vLEI Ecosystem stakeholders MUST inform\neach other about actual or potential disclosure(s) of Personal Data and promptly take\nappropriate measures to address the situation and to limit the risk of such disclosure(s)\nfrom reoccurrence.\n\n6. Qualified vLEI Issuers MUST document privacy breaches in an Incident Report.\n\n6 VLEI Ecosystem Stakeholder Security Policies\n\n1. VLEI Ecosystem stakeholders MUST publish, review annually, maintain, and comply with IT\nsecurity policies and practices sufficient to protect all services that a vLEIl Ecosystem\nstakeholder provides in conformance with this Ecosystem Governance Framework and\nmeets the minimum elements of the following recommendations:\nhttps://resources.infosecinstitute.com/topic/key-elements-information-security-\npolicy/#gref\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 3 of 5\n\nVLEI Ecosystem Information Trust Policies\n\nPublic Document Version 1.0\nGLEIF 2022-12-16_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2022-12-16\n\nVLEI-Ecosystem-Information-Trust-Policies_v1.0_final\n","contentLength":2387,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:19:54.161Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-vlei-ecosystem-information-trust-policies_v1.0_final.pdf","content":"2. These policies MUST be mandatory for all employees of the vLEI Ecosystem stakeholder\ninvolved with vLEI Data. The vLEI Ecosystem stakeholder MUST designate its Information\nSecurity Manager or another officer to provide executive oversight for such policies,\nincluding formal governance and revision management, employee education, and\ncompliance enforcement.\n\n3. VLEI Ecosystem stakeholder employment verification policies and procedures MUST include,\nbut may not be limited to, criminal background check and proof of identity validation.\n\n4. Qualified vLEIl Issuers MUST recertify annually that they maintain a law abiding and ethical\nstatus in the business community as evidenced in the Annual vLEI Issuer Qualification.\n\n5. If a Qualified vLEI Issuer performs handling of vLEI Data in its own data center, the Qualified\nVLEI Issuer’s security policies MUST also adequately address physical security and entry\ncontrol according to industry best practices.\n\n6. If a Qualified VvLEI Issuer uses providers of Third-Party Services in functions that involve the\nhandling of vLEI Data, the Qualified vLEI Issuer MUST ensure that the security, privacy, and\ndata protection policies of the third-party providers meet the requirements in this\ndocument.\n\n7. Qualified vLEI Issuers MUST make available evidence of stated compliance with these\npolicies and any relevant accreditations held by the Qualified vLEI Issuer during Annual vLEI\nIssuer Qualification, including certificates, attestations, or reports resulting from accredited\nthird-party audits, such as ISO 27001, Statement on Standards for Attestation Engagements\nService Organization Controls 2 (SSAE SOC 2), or other industry standards.\n\n7 Security Incidents Policies\n\n1. Qualified vLEI Issuers MUST maintain and follow documented incident response procedures\nand guidelines for computer security incident handling and will comply with data breach\nnotification terms of the vLEl Issuer Qualification Agreement. ITIL (Information Technology\nInfrastructure Library) Incident Management is followed by GLEIF and is certified as part of\nGLEIF’s ISO 20000 certification.\n\n2. Qualified vLEI Issuers MUST define and execute an appropriate response plan to investigate\nsuspected unauthorized access to vLEI data. GLEIF and the Qualified vLEl Issuers will handle\nthrough the Incident Management process.\n\n8 Availability Policies\n\n1. GLEIF and Qualified vLEl Issuers MUST maintain defined availability targets as part of the\nVLEI Ecosystem Governance Framework.\n\n2. GLEIF and Qualified vLEI Issuers MUST maintain records to evidence the availability of their\nservices.\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 4 of 5\n\nVLEI Ecosystem Information Trust Policies\n\nPublic Document Version 1.0\nGLEIF 2022-12-16_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2022-12-16\n\nVLEI-Ecosystem-Information-Trust-Policies_v1.0_final\n","contentLength":2894,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:19:54.161Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-vlei-ecosystem-information-trust-policies_v1.0_final.pdf","content":"9 Developer Security Policies\n1. GLEIF MUST provide technical changes/upgrades to the vLEI software to Qualified vLEI\nIssuers.\n2. Qualified vLEI Issuers MUST successfully install, test and implement the vLEI software within\nstated timeframes.\n3. Developers of Qualified vLEI Issuers SHOULD follow the security recommendations in\nsection 8 of the W3C Verifiable Credentials Data Model 1.0 specification and the Trust over\nIP Authentic Chained Data Containers (ACDC) specification when designing software or\nservices for use with vLEI Credentials and the vLEIl Ecosystem.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 5 of 5\nVLEI Ecosystem Information Trust Policies\nPublic Document Version 1.0\nGLEIF 2022-12-16_verifiable-LEI-(vLEl)-Ecosystem-Governance-Framework- 2022-12-16\nVLEI-Ecosystem-Information-Trust-Policies_v1.0_final\n","contentLength":845,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:19:54.161Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_vlei-issuer-qualification-agreement_v1.0_final.pdf","content":"OGLEIF’ Protecting digital st\nverifiable LEI (vLEI)\nEcosystem Governance Framework v1.0\nVLEI Issuer Qualification Agreement\nPublic\nDocument Version 1.0\n2022-12-06\n. - 1! : 8 i\n@ J‘g P el s\ni 389, ‘ L e \" s : : .~.\n> ‘ ' - — o w 'y . f' o N = .\nN e o - | -.‘g’ . {,. '.o. ®) 5 : .\n® \\ \" o ) A .’ . : .\n.b- . ) t.\\‘ r {{ { o... ® . 4 |\no 3 . .\nP\n.\n","contentLength":346,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:21:22.754Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_vlei-issuer-qualification-agreement_v1.0_final.pdf","content":"verifiable LEI (vLEI) Ecosystem Governance Framework\nVLEI Issuer Qualification Agreement\nbetween\nGlobal Legal Entity Identifier Foundation\nSt. Alban-Vorstadt 5, 4052 Basel/Switzerland\n\"GLEIF\"\nand\n**Name of Qualified vLEI Issuer**\n**Address of Qualified vLEI Issuer**\n\"Qualified vLEIl Issuer”\neach also \"a Party\", together \"the Parties\"\n**Basel,** **Place, Date**\n**Signature**\nBy: Stephan Wolf Sven Schumacher By: Designated Authorized Representative of\nFunction(s): CEO General Counsel the QVI\nFunction(s): **Title**\nmade in two originals, one for each Party\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 2 of 31\nvLEI Issuer Qualification Agreement\n@ Public Document Version 1.0\n2022-12-06_vLEl-issuer-qualification-agreement_v1.0_final.docx 2022-12-06\n","contentLength":771,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:21:22.754Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_vlei-issuer-qualification-agreement_v1.0_final.pdf","content":"12.1 If the Qualified vLEI Issuer intends to change any part of what has been\nsubmitted and accepted with the vLEI Issuer Qualification Program Checklist\n(Appendix 3), the Qualified vLEI Issuer must formally and in writing request\nnotify GLEIF for a change in its Qualification.\n\n12.2 The Qualified vLEI Issuer must make every effort to notify GLEIF in advance of a\nchange (or else notify GLEIF as soon as reasonably possible) and to supply to\nGLEIF all pertaining information, documents and provide reasons for the\nchange.\n\n12.3 GLEIF shall review the submission of the Qualified vLEI Issuer and shall\ndetermine in its sole but reasonable discretion whether the Qualified vLEI\nIssuer still meets all requirements for Qualification.\n\n12.4 GLEIF shall either acknowledge the updates to the vLEl Issuer Qualification\nProgram Checklist (Appendix 3) or shall refuse such amendment, giving\nsummary reasons for its refusal. In the event of refusal, the Qualified vLEI\nIssuer can either accept this decision, or not accept and terminate this\nAgreement, or not accept and take recourse to the remedies available to it\nunder Chapter XV Appeals and Complaints or ultimately request mediation and\narbitration pursuant to Chapter XVI.\n\n12.5 Changes which consist merely of updates to the Qualified vLEI Issuer Contact\nDetails List (Appendix 4) need no prior approval of GLEIF. GLEIF shall publish,\nfrom time to time, guidance on similar administrative changes or changes\nwhich are not relevant for Qualification, which need no prior notification to\nGLEIF.\n\n13. For the avoidance of doubt, any change of control at the Qualified vLEl Issuer, be it a\nchange in ownership, voting power, or factual power of a third party over the\nQualified vLEl Issuer, is only one example of a change that must be notified to GLEIF\nin advance, or if that is not possible as soon as reasonably possible. GLEIF has the\noption to terminate the Agreement with the Qualified vLEl Issuer according to the\nterms of clause 87 of the Agreement.\n\nIV. Core Duties of the Qualified vLEI Issuer\nA. Compliance with the verifiable LEI (vLEI) Ecosystem Governance Framework\n\n14. The Qualified vLEI Issuer agrees to follow the requirements pertaining to the\noperations of Qualified VLEI Issuers as specified in the vLEI Ecosystem Governance\nFramework.\n\n15. The Qualified vLEl Issuer is aware that issuance, maintenance, and revocation of vLEI\nCredentials as set out in Appendix 5 — Qualified vLEI Issuer Service Level Agreement\n(SLA) are all important parts of the Qualified vLEI Issuer’s obligations under this\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 11 of 31\nvLEI Issuer Qualification Agreement\n\n@ Public Document Version 1.0\n2022-12-06_vLEl-issuer-qualification-agreement_v1.0_final.docx 2022-12-06\n","contentLength":2782,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:21:22.754Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_vlei-issuer-qualification-agreement_v1.0_final.pdf","content":"Agreement and their breach being a breach of an important provision of this\nAgreement.\n\n16. Whenever in doubt as to how a provision in this Agreement should be observed and\nperformed, the Core Duties, with guidance from the vLEI Ecosystem Governance\nFramework, shall govern its interpretation.\n\nB. Records Management\n\n17. For the purposes of this Sub-Chapter B, records are defined as \"documents, internal\nprocedures and practices documentation, and data, regardless of type and regardless\nof whether such items are in written (paper) form, pdf, in the form of electronic or\noptical data, or in any other non-hardcopy form, and other supporting evidence to\nsatisfy GLEIF record retention requirements\" (each of them a \"Qualified vLEI Issuer-\nRecord\", in their entirety the \"Qualified VLEI Issuer-Records\"), insofar as related to\nthis Agreement and to its performance by the Qualified vLEl Issuer, and as set out in\nChapter XI. For the avoidance of doubt, essential hardcopy documents such as an\nincorporation certificate qualify as a Qualified vLEI Issuer-Record and must be kept as\nsuch.\n\n18. The Qualified vLEI Issuer will make available to GLEIF Qualified vLEI Issuer-Records\nwhich encompass for any specific Qualified vLEI Issuer-Record a period of at least 10\nyears after the most recent update to such Qualified vLEI Issuer-Record, during the\nentire term of the Agreement and for five years thereafter.\n\n18.1 Itis the Qualified VvLEI Issuer's responsibility to ensure that Qualified vLEI\nIssuer-Records can be viewed, printed, and copied, and that the required\ntechnical equipment is available.\n\n18.2 If and to the extent this is technically and reasonably possible, the Qualified\nVLEI Issuer shall enable inspection of the Qualified vLEI Issuer-Records by GLEIF\nat GLEIF's premises or by remote-access.\n\n18.3 Access to Qualified vLEI Issuer-Records must be possible without undue\nexpenditure of cost, time, or other resources.\n\n19. The Qualified vLEI Issuer is free in its choice of a data retention system for Qualified\nVLEI Issuer-Records, provided that (i) the system is demonstrably reliable and secure,\nand (ii) the Qualified vLEI Issuer has editorial access to the system, (iii) the system\nmaintains and retains an audit trail about any changes including in particular copies,\ndiscards, deletions and write-overs of data, and (iv) no information whatsoever\ncontained in or on the original Qualified vLEI Issuer-Record is lost. Original Qualified\nVLEI Issuer-Records need not be maintained or produced for an audit if the Qualified\nVLEI Issuer’s data retention system can prove that the stored data are an authentic,\ntrue, and accurate copy of the original Qualified vLEI Issuer-Records.\n\n20. If the Qualified vLEI Issuer-Records are not retained as a hardcopy, but stored\notherwise, particularly electronically or optically, the Qualified vLEI Issuer must (i) use\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 12 of 31\nvLEI Issuer Qualification Agreement\n\n@ Public Document Version 1.0\n2022-12-06_vLEl-issuer-qualification-agreement_v1.0_final.docx 2022-12-06\n","contentLength":3093,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:21:22.754Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_vlei-issuer-qualification-agreement_v1.0_final.pdf","content":"highly reliable media, (ii) always keep a backup copy, and (iii) check all media at least\nannually for accessibility, integrity, and legibility.\nV. Financials\nA. Business Model for Qualified vLEIl Issuers\n\n21. Qualified VLEI Issuers may charge fees for the issuance, verification and/or revocation\nof Legal Entity vLEI Credentials issued to Legal Entities and Legal Entity Official\nOrganizational Role vLEI Credentials (OOR Credentials) issued to persons in OORs.\nThe Qualified vLEI Issuer is solely responsible for managing the revenue that is\nproduced and costs that are incurred in the running of its vLEl operations.\n\n22. Qualified vLEl Issuers also may offer ancillary services to Legal Entities regarding\nvLEls. This can include the management of the Legal Entity’s vLEI credentials wallet as\nan example.\n\n23. The Qualified vLEI Issuer must ensure that its operations regarding vLEls are\nsustainably financed and the Qualified vLEl Issuer takes note, acknowledges, and\naccepts that no funds of any form whatsoever for Qualified vLEI Issuer operations\nshall be contributed by GLEIF.\n\n24, GLEIF has designed the Qualified vLEI Issuer model to encourage competition of\nservices among Qualified vLEI Issuers. Therefore, GLEIF will not set fees charged by\nQualified vLEl Issuers for vLEI services.\n\nVI. Ancillary Duties\n\n25. So as to meet and implement the vLEI Ecosystem Governance Framework, the Parties\nacknowledge that they have, in particular but explicitly without any limitation,\ncertain ancillary duties.\n\n26. The Qualified VvLEI Issuer cooperates with GLEIF in the event of termination of a\nQualified VLEI Issuer ceasing its operations or experiencing a major or serious break\nin operations. This includes the requirement for the Qualified vLEI Issuer to notify its\nLegal Entity clients of its termination as a Qualified vLEI Issuer or otherwise ceasing\nQualified VLEl Issuer operations.\n\n27. The Qualified vLEI Issuer cooperates with all other Qualified vLEI Issuers and with\nGLEIF to resolve any problems with the maintenance of vLEls (examples: invalid vLEls\ndue to duplicate LEls).\n\n28. The Qualified VLEI Issuer cooperates with all other Qualified vLEI Issuers in the event\nof assumption of responsibility for vLEls which have been issued and maintained by a\ndifferent Qualified vLEI Issuer to ensure that these vLEls can be replaced with vLEls of\nthe new Qualified vLEI Issuer.\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 13 of 31\nvLEI Issuer Qualification Agreement\n\n@ Public Document Version 1.0\n2022-12-06_vLEl-issuer-qualification-agreement_v1.0_final.docx 2022-12-06\n","contentLength":2608,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:21:22.754Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_vlei-issuer-qualification-agreement_v1.0_final.pdf","content":"29. Both Parties are in agreement that further ancillary duties may become applicable,\ndue to specific situations or circumstances that require the Parties' attention in the\ncontext of the vLEI Ecosystem Governance Framework.\n\nVIl. Services\n\n30. Services and service levels of a Qualified VLEI Issuer pursuant to this Agreement are\n\ngoverned by Appendix 5 — Qualified VLEI Issuer Service Level Agreement (SLA).\nVIll. Languages and Documentation Format\nA. Language for Communicating\n\n31. The primary language to be used when GLEIF and the Qualified vLEI Issuer\ncommunicate by whatever means (written, electronic, messaging, phone,\nconferences) shall be English.\n\n32. Nothing in this Agreement prevents the Parties to use a different language, chosen in\nmutual agreement, for day-to-day or informal communication (such as matters of\nday-to-day business or related inquiries and responses). But, for the avoidance of\ndoubt, formal communication must be in English.\n\n33. For the purposes of this Sub-Chapter VIII.A, \"formal communication\" shall mean any\ncommunication which is relevant for the contractual relationship between GLEIF and\nthe Qualified vLEI Issuer, such as the entire vLEl Issuer Qualification Program\nChecklist (Appendix 3), GLEIF requests related to Annual vLEI Issuer Qualification and\nthe Qualified vLEI Issuer’s responses, change notifications, all matters regarding\ntermination (Chapter XIl), the Agreement Change Process (Chapter 1.1.C), Appeals\nand Complaints (Chapter XV) and Mediation and Arbitration (Chapter XVI) and the\nmethods of formal communication are specified in clause 31 above.\n\nB. Language of Documentation\n\n34. All documentation that is to be shared with GLEIF under this Agreement, in particular\nthe Qualification Documentation shall be in English language. Where documents are\nnot available in English, they must be accompanied by an English translation. Either\nParty may request a certified English translation. Translation and Qualification costs\nare borne by the Qualified vLEl Issuer if the documents are provided by the Qualified\nVLE! Issuer and are borne by GLEIF if the documents are provided by GLEIF.\n\n35. Parts of documents, in particular information which cannot be translated to the\nEnglish language, or which can only be represented by a vocal assimilation substitute,\nshall be clearly characterized as such, and the graphic representation and/or\nmeaning of any such parts of documents shall be identified and explained to the best\nextent reasonably possible.\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 14 of 31\nvLEI Issuer Qualification Agreement\n\n@ Public Document Version 1.0\n2022-12-06_vLEl-issuer-qualification-agreement_v1.0_final.docx 2022-12-06\n","contentLength":2723,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:21:22.754Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_vlei-issuer-qualification-agreement_v1.0_final.pdf","content":"36. In the event of a contradiction between the foreign-language original and the English\ntranslation or representation, the foreign-language original shall always prevail if that\noriginal is a document issued by a governmental agency or authority, and the English\ntranslation or representation shall prevail in all other cases. The Parties will\nundertake any reasonable effort to avoid such contradictions. For the avoidance of\ndoubt, it is the full and sole responsibility of the party providing the English\ntranslation to provide true, complete, and correct English translations.\n\n37. For the avoidance of doubt, the above clauses 34 - 36 apply only between GLEIF and\nthe Qualified vLEI Issuer. These clauses do not apply to documents exchanged\nbetween the Qualified vLEI Issuer and a Legal Entity, as this is up to the Qualified vLEI\nIssuer to determine.\n\nIX. Intellectual Property\nA. Intellectual Property Rights in vLEIls\n\n38. Both Parties take note and agree that vLEls are not covered by intellectual property\nrights under the Revised Berne Convention.\n\n39. To protect the GLEIS against the possibility that, under the copyright legislation or\nany other legislation applicable (whether now existing or later created), an vLEI might\nenjoy intellectual property rights of whatever type, extent, and legal nature, the\nQualified VvLEI Issuer\n\n39.1 ascertains, in its contractual agreement with applicants for a vLEI (Appendix 7,\nQualified vLEI Issuer-Legal Entity Required Contract Terms), that any such\nrights are fully and irrevocably transferred (or, if not legally possible under\napplicable legislation, irrevocably licensed) to the Qualified vLEl Issuer;\n\n39.2 herewith fully and irrevocably, and at no cost to GLEIF, transfers those rights\n(whether now existing or later created) to GLEIF.\n\n40. The status of all LEls can be found on GLEIF's website using the GLEIF API.\nB. Intellectual Property Rights in vLEI Role Credentials\n\n41. Given that the vLEI Role Credentials (as defined and agreed in Legal Entity Official\nOrganizational Role vLEI Credential Governance Framework) are comprised of only\npublicly available data, both Parties take note and agree that the vLEI Role\nCredentials are not covered by copyrights under the Revised Berne Convention, and\nneither by any other intellectual property rights.\n\n42, However, and for the avoidance of doubt, the Parties agree that the Legal Entity or\nperson in an official or functional role will have, as a rule, certain protective rights in\nits name which is included, for inevitable reference purposes, in the vLEI Role\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 15 of 31\nvLEI Issuer Qualification Agreement\n\n@ Public Document Version 1.0\n2022-12-06_vLEl-issuer-qualification-agreement_v1.0_final.docx 2022-12-06\n","contentLength":2794,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:21:22.754Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_vlei-issuer-qualification-agreement_v1.0_final.pdf","content":"Credentials as defined by the Legal Entity Official Organizational Role and Legal Entity\nEngagement Context vLEI Credential Frameworks.\n\n43, To protect the GLEIS against the possibility that, under the copyright legislation or\nany other legislation applicable (whether now existing or later created), any part of\nthe vLEI Role Credentials might enjoy copyrights, or any other intellectual property,\ndata protection or other protective rights of whatever type, extent, and legal nature,\nthe Qualified vLEI Issuer\n\n43,1 ascertains, in its contractual agreement with applicants for vLEI Credentials\n(Appendix 7, Qualified vLEI Issuer-Legal Entity Required Contract Terms), that\nany and all rights are fully and irrevocably transferred (or, if not legally possible\nunder applicable legislation, irrevocably licensed) to the Qualified vLEI Issuer,\nwith the sole exception of the protective rights of the Legal Entity in its legal\nname and the natural person’s rights;\n\n43.2 herewith fully and irrevocably, and at no cost to GLEIF, transfers those rights\n(whether now existing or later created) to GLEIF.\n\nC. Publication of field values of Legal Entity vLEIs and vLEI Role Credentials\n\n44, The field values of Legal Entity vLEI Credentials and Legal Entity Official\nOrganizational Role vLEI Credentials that have been issued by the Qualified vLEI\nIssuer will be published by GLEIF on the LEI page of the Legal Entity. GLEIF will\nimplement a vLEI Reporting API to be advised of the issuance of Legal Entity vLEI\nCredentials and Legal Entity Official Organizational Role vLEI Credentials for\npublication of the field values. The vLEI Reporting API also will be used to inform\nGLEIF of updates for vLEI Credentials that have been revoked.\n\n45, Quialified VLEI Issuers must call the vLEI Reporting APl with each issuance and\nrevocation event of Legal Entity vLEI Credentials and Legal Entity Official\nOrganizational Role vLEI Credentials.\n\n46. It is understood and agreed that the purpose of the transfer, or license, of rights\npursuant to clauses 38 through 43.2 is only to eliminate any obstacle to the\npublication of vLEI Role Credentials in the GLEIS and/or to their use by anybody,\nincluding to eliminate (by way of example, but for the avoidance of doubt without\nany limitation whatsoever) any obstacles to the free transfer of data from the\nQualified vLEl Issuer to the Global LEI Repository, to the publishing, and to the\ndownload and use of vLEI Role Credentials by anybody for whatever purpose,\nwhether commercial or not and whether alone or in combination with other data.\n\n47. This applies particularly in the event that data protection or other privacy rights\nmight be claimed, or any similar protection right (whether now existing or later\ncreated).\n\n48. The Qualified vLEI Issuer is responsible and liable for any failure of obtaining where\nnecessary and transferring to GLEIF any and all rights which confirm beyond any\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 16 of 31\nvLEI Issuer Qualification Agreement\n\n@ Public Document Version 1.0\n2022-12-06_vLEl-issuer-qualification-agreement_v1.0_final.docx 2022-12-06\n","contentLength":3142,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:21:22.754Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_vlei-issuer-qualification-agreement_v1.0_final.pdf","content":"reasonable doubt that the vLEIl and vLEIs Role Credentials may be used as set out in\nclause 44.\n\n49, GLEIF shall not make any inappropriate use of the rights transferred to it. The sole\nreason and purpose for the transfer to GLEIF is to ensure that LEls and vLEI Role\nCredentials may be freely and unrestrictedly transferred to the Global LEI Repository,\nmade available for use by anybody, such as download from that source and use as\ndescribed in clause 44.\n\n50. The Parties explicitly agree that the provisions of this Chapter A are critical and\nfundamental for the proper functioning of the GLEIS. Any violation of the obligations\ndesigned to ensure the free availability of LEls and vLEls Role Credentials is deemed\nto be a violation of an important provision of this Agreement.\n\nD. Qualified vLEl Issuer Qualification TrustMark\n\n51. Upon successful Qualification of a Qualified vLEI Issuer, GLEIF will provide the\nQualified vLEI Issuer with a TrustMark (Appendix 6) and grant the Qualified vLEI\nIssuer the right to use and display the TrustMark as follows:\n\n51.1 The Qualified vLEI Issuer must display the Qualified vLEI Issuer Qualification\nTrustMark on its website in an appropriate location, for no other purpose than\nindicating that the Qualified vLEl Issuer is a Qualified vLEl Issuer.\n\n51.2 The Qualified vLEl Issuer also may display the Qualified vLEI Issuer Qualification\nTrustMark on related documentation for Qualified vLEI Issuer services.\n\n51.3 The Qualified vLEl Issuer must not provide the Qualified vLEI Issuer\nQualification TrustMark to any third-party for use by the third party.\n\n52. Any other use of the Qualified vLEI Issuer TrustMark is strictly prohibited.\nE. Trademarks registered by the Qualified vLEl Issuer\n\n53. The Qualified vLEI Issuer may register additional trademarks to represent its services.\nIn the event of any such trademark is confusingly similar to the Qualified vLEI Issuer\nTrustMark, regardless of whether simply used or applied for by registration or\nregistered, GLEIF may request cessation of use of such trademark and use any legal\nremedies available to it.\n\nX. Liability\nA. Liability in General\n\n54. Both Parties agree that in the interest of complying with the vLEI Ecosystem\nGovernance Framework, they have a duty of care in all aspects of performing this\nAgreement, and to operate in good faith.\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 17 of 31\nvLEI Issuer Qualification Agreement\n\n@ Public Document Version 1.0\n2022-12-06_vLEl-issuer-qualification-agreement_v1.0_final.docx 2022-12-06\n","contentLength":2565,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:21:22.754Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_vlei-issuer-qualification-agreement_v1.0_final.pdf","content":"55. The Qualified vLEI Issuer agrees that it has an essential and all-important duty of care\nregarding the services and service levels set out in Appendix 5 - Qualified vLEI Issuer\nService Level Agreement (SLA).\n\n56. Either Party is liable for acts and omissions of any auxiliary person such as (without\nany limitation) employees and third-party service providers as if those acts or\nomissions were its own.\n\n57. Liability for trivial damages is waived by both Parties. The claiming party must\ndemonstrate the existence of a non-trivial damage.\n\n58. For the avoidance of doubt, liability as set out in this Chapter X only governs the\nrelationship between GLEIF and the Qualified vLEI Issuer.\n\n59. The Qualified vLEI Issuer will be liable for the verification that the representative of\nthe Legal Entity requesting the issuance any vLEI Credentials is authorized to request\nVLEI Credentials on behalf of the Legal Entity as well as validating the identity and\nofficial role of Legal Entity Official Organizational Role vLEI Credential Holders.\n\n60. The Qualified vLEI Issuer also will be liable for the issuance, maintenance, and timely\nrevocation of vLEI Credentials. This includes revocation of the vLEI Legal Entity\nCredential when instructed by a Legal Entity that has terminated its agreement with\nthe Qualified vLEI Issuer and has contracted with a new Qualified vLEI Issuer.\n\n61. Neither GLEIF or Qualified vLEI Issuer will be liable for inappropriate use of Legal\nEntity vLEI Credentials once issued to Legal Entities or Legal Entity Official\nOrganizational Role vLEI Credential issued to OOR Credential Holders issued in\naccordance with the vLEI Ecosystem Governance Framework.\n\n62. In addition, neither GLEIF or Qualified vLEI Issuer will be liable for inappropriate use\nof Legal Entity Engagement Context Role VLEI Credentials issued and revoked entirely\nat the discretion of a Legal Entity.\n\n63. Payment of damage claims, be they liquidated damages or not, does not relieve (i)\nthe damaging Party of redressing the situation to comply with the Agreement, nor (ii)\nof further compliance with the Agreement. A waiver or voluntary reduction of\ndamage claims by the damaged Party, in the event, and for whatever reason, never\nconstitutes a waiver of compliance with the breached provision.\n\n64. For the avoidance of doubt, the general principles of Swiss law regarding tort and\ncontractual liability for damages do apply. In particular, the damaged Party is obliged\nto take any reasonable mitigation measures, and the burden of proof lies (under\nreserve of clause 65 ss) with the Party claiming a damage.\n\nB. Liability for Damage caused by Willful Intent or Gross Negligence\n65. The Parties are aware that under mandatory Swiss law, damage caused by wilful\nintent or gross negligence can be neither waived nor capped.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 18 of 31\nvLEI Issuer Qualification Agreement\n@ Public Document Version 1.0\n2022-12-06_vLEl-issuer-qualification-agreement_v1.0_final.docx 2022-12-06\n","contentLength":3037,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:21:22.754Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_vlei-issuer-qualification-agreement_v1.0_final.pdf","content":"66. The Parties acknowledge and agree that it may be difficult for the damaged Party to\nguantify the damage amount. Therefore, the Parties agree on an amount in USD as\nliguidated damages which is equal to the monetary amount of legally recognized and\nprovable claims of the damaged Party which is calculated according to clause 67\nbelow. Notwithstanding this,\n\n(i) the damaged Party shall bear the burden of proof and associated costs in\npursuing the entire claimed sum, and\n\n(ii) the violating Party is free to prove that actual damage was lower than the\namount of the entire claimed sum, and\n\n(iii) both Parties are aware and acknowledge that pursuant to Swiss substantive\nlaw, liquidated damages which are excessively high compared with the actual\ndamages shall be reduced by a deemed-competent judge (see Chapter XVI on\nMediation and Arbitration) at the judge's fair and just discretion, in particular\nupon evidence submitted by the liable Party showing that the actual damage is\nconsiderably lower compared to the amount of the higher damages claimed,\nor that even no or only trivial damage has been caused, as set out in Article\n163 para. 3 of the Swiss Code of Obligations.\n\n67. Liquidated damages are calculated as follows: If a Party is in breach: USD 1.00 (one\nUSD) multiplied by the number of active vLEI Credentials for the last 12 months by\nthe Qualified vLEI Issuer as documented in the Key Event Receipt Infrastructure\n(KERI) logs.\n\nC. Liability for Damage caused by Simple Negligence\n\n68. Breaches caused by simple negligence that do not cause liability claims will be\nsubject to the escalation management outlined in Appendix 5 - Qualified vLEI Issuer\nService Level Agreement (SLA).\n\n69. For all other violations of the Agreement caused by simple negligence, the Parties\nagree on and calculate liquidated damages as set out in above clause 67.\n\n70. However, damage claims shall be capped as follows:\n\n70.1 If the Party in breach is the Qualified vLEI Issuer: 150% (one hundred and fifty\npercent) of the amount calculated pursuant to clause;\n70.2 If the Party in breach is GLEIF: 150% (one hundred and fifty percent) of the\namount calculated pursuant to clause.\nD. Liability Insurance for Claims\n\n71. For violations of this Agreement caused by wilful intent, gross negligence or simple\nnegligence that do result in liability claims, the Parties are obliged to maintain\nsufficient insurance coverage with Professional Liability/Errors and Omissions\ninsurance.\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 19 of 31\nvLEI Issuer Qualification Agreement\n\n@ Public Document Version 1.0\n2022-12-06_vLEl-issuer-qualification-agreement_v1.0_final.docx 2022-12-06\n","contentLength":2691,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:21:22.754Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_vlei-issuer-qualification-agreement_v1.0_final.pdf","content":"E. Obligation of the Parties to Keep each other Free from Harm\n\n72. Either Party shall keep the other free from harm and from any third-party claims\nwhich result from any and all of its acts or omissions which are improper, unlawful,\nor a breach of this Agreement.\n\n73. In the event of a third party raising a claim against one of the Parties (for the purpose\nof this Sub-Chapter \"the Prosecuted Party\") which may be attributable to the other\nParty (for the purpose of this Sub-Chapter \"the Liable Party\"), the Prosecuted Party\nshall immediately inform the Liable Party in writing and provide all facts and\ndocuments to enable the Liable Party to assess the claim.\n\n74. The Prosecuted Party shall not acknowledge any allegations and shall not negotiate\nwith the third party on its own, but shall, in its sole but reasonable discretion, either\nleave the matter to the Liable Party or deal with the matter on the Liable Party's\ninstructions.\n\n75. In the event of litigation (civil, criminal, or administrative) or government\ninvestigation, the Parties shall cooperate, within the boundaries set by the applicable\nprocedural rules of such litigation or investigation, where guidelines shall be that due\nto the Liable Party's liability, the Liable Party should have the best possible influence\non written submissions, hearings, evidence, settlement talks, and negotiations.\n\nXl. Verification and Audits\nA. Verification of Qualified vLEI Issuer Internal Controls\n\n76. In order to maintain the Qualified vLEl Issuer’s Qualification, the Qualified vLEI Issuer\nis required to complete Annual vLEI Issuer Qualification.\n\n77. GLEIF may request Extraordinary vLEl Issuer Qualification where exceptional\ncircumstances give GLEIF reason to believe that the Qualification Documentation is\nno longer current or adhered to.\n\nB. Oversight of Audit Activity at the Qualified vLEI Issuer\n\n78. In order to execute its oversight responsibilities, GLEIF requires that any Audit\nReports from any source received by the Qualified vLEI Issuer that relate to vLElI\nprocessing be provided to GLEIF for information purposes at the latest within 30 Days\nafter receipt thereof. Any exceptions of this provision must explicitly be agreed\nduring vLEl Issuer Qualification or Annual vLEI Issuer Qualification.\n\n79. GLEIF is entitled to have any Audit Report submitted by the Qualified vLEI Issuer as\nnoted in above clause, reviewed by GLEIF’s Audit function and/or by a reputable\nauditing firm of its choice, and to request additional information or analysis,\nincluding vLEl issuance and revocation activity logs, from the Qualified vLEI Issuer.\nThe cost of provision of additional information or analysis shall be borne by the\nGLEIF.\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 20 of 31\nvLEI Issuer Qualification Agreement\n\n@ Public Document Version 1.0\n2022-12-06_vLEl-issuer-qualification-agreement_v1.0_final.docx 2022-12-06\n","contentLength":2916,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:21:22.754Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_vlei-issuer-qualification-agreement_v1.0_final.pdf","content":"Table of Contents\n\nI. Purpose and Scope................................................................................. 6\nII. Definitions 000000000 RN RRRRRRRRRRRRRRRRRRRRRRNRRRRRRRRRRRRRRRRRRRRRRNNRRNRRNRRRRRRRRRRRRORRRRRRERRRRORRRTOTS 6\nlll. Qualification for the Candidate VLEI ISSUEr .........cccceeeerrvnnnicriennicreennncenees 9\nA.The VLEI Issuer Qualification Program .........cccecceeiveesiiissiiecseiesceee e eseessviessee e sneeseeens 9\nB.Use Of Third-Party SEIVICES ......uveiveeeiie et ettt e ste st e rte s aessnaeennne e O\nC.No Sublicensing of QUAlIfication ..........ccceevvieecie e er e e seeesseeesseeeeeneees 10\nD.Change Process Qualification Program.........cccoccueevceeceieseeeciesseiecceeeeeesvessseeseseneenns 10\nIV. Core Duties of the Qualified VLEI ISSUETr ........cccceerrrueniiirnnnciierenniiennnnenn 11\nA.Compliance with the verifiable LEI (vLEI) Ecosystem Governance Framework............. 11\nB.ReCOrds ManagemeNnt.......cueeiieciiiiiiiieeeeeitieeeestieeessstiesssstteeesssreeeesssseesssssesssnsssesssssseessnsss L2\nV. Financials............................................................................................. 13\nA.Business Model for Qualified VLEI ISSUEIS.......ccceeevieeiieeiiieeciiieceeeseestieesseeessnesneeeeenns 13\nVI. Ancillary Duties.................................................................................... 13\nVII. Services 0000000000 RNRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRNRRERRN0RRORRRRRRRRRRORORORERRRCRCRORORCRORTOTS 14\nVIIl. Languages and Documentation Format........ccccceciieeirnecieciienninecreecnenn. 14\nA.Language for ComMmMUNICAtING ......c.eevuiiiiieecie et eestteestessree e sesaeesree s eaesnaeennes 1\nB.Language of DOCUMENTAtioN.......cccveeiiieceeece ettt e ste e teeeee e sveeesrsesssnaesneeennes 1\nIX. Intellectual Property 00000000000 RRRRRNRRRRRRRRRRRRRRRRRRRRORRRRRRRRNRRRRRRRRRRRRRRRRRRRRORRRRRTRTS 15\nA.Intellectual Property Rights in VLEIS.......c..coiiviiiiiiiiin et sie s seie e seee e eeeees 15\nB.Intellectual Property Rights in VLEI Role Credentials........ccccceeeevievieiiivieeniisieeeiiieen e 15\nC.Publication of field values of Legal Entity vLEls and vLEI Role Credentials.................... 16\nD.Qualified vLEI Issuer Qualification TrustMark .........cccoccveeveeeveeesceeesieesieeseeeseeesveennns 17\nE.Trademarks registered by the Qualified VLEI ISSUET .......ccccveecveeeceeeiieesie e sennn 17\nX. Liability................................................................................................ 17\nALLIability in GENEIAl ... .viii ettt sste e snae e s snaaessenees 1T\nB.Liability for Damage caused by Willful Intent or Gross Negligence............ccceceueneen..... 18\nXI. Verification and Audits......................................................................... 20\nXill. Term and Termination .......cccccrvuiireiiiinniiineiinnniinreenreees 22\nXIll. Agreement Change ProCess.....ccccciveiereneirrennceennsrrnnscernnsseenscesnnsssnnscenenss 24\nXIV. confidentiality 00000000000 RNRRRRRRRRERRRRRRRRRRORRRRRERRRRRRRRRRRRRNRN0RRRRRRRRRRRRRRRRRRRORCRRRRTRTS 25\nXV. Appeals and Complaints......ccccceceeieeerenireeiireecinceeeseenerneceenssensenscsenceesees 20\nA.BASIC PriNCIPIE ittt ettt st sttt st re e sssrae s s sraeeesssaeeesssnseessnveessnnsees 20\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 3 of 31\n\nvLEI Issuer Qualification Agreement\n@ Public Document Version 1.0\n2022-12-06_vLEl-issuer-qualification-agreement_v1.0_final.docx 2022-12-06\n","contentLength":3478,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:21:22.754Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_vlei-issuer-qualification-agreement_v1.0_final.pdf","content":"80. If such review or additional investigations result in GLEIF requiring remedial action(s)\nto be undertaken by the Qualified vLEI Issuer to meet the relevant requirements in\nthe VLEI Ecosystem Governance Framework, the Qualified vLEI Issuer shall do so\npromptly and shall inform GLEIF about the progress and finalization of such\nmeasures. The cost of remedial actions shall be borne by the Qualified vLEI Issuer.\n\nC. Audits at Qualified vLEl Issuer Locations\n\n81. GLEIF may conduct financial, operational and/or information technology audits\nrelating to VLEI operations at Qualified vLEI Issuer locations at GLEIF's sole but\nreasonable discretion. To provide for a reasonable scheduling opportunity, GLEIF will\nmake every effort to provide at least four weeks’ notice to the Qualified vLEI Issuer.\nShould the Qualified vLEI Issuer not be in a position or not willing to undergo an audit\nas requested by GLEIF, GLEIF is explicitly entitled to request to have an audit\nperformed by a qualified firm of its choice. Any refusal of this request shall be\ndeemed to be a violation of the Agreement. The following provisions shall govern on-\nsite audits:\n\n81.1 Anaudit shall take place during the Qualified vLEl Issuer's normal business\nhours, and, to the extent practicable, shall be conducted with minimal\ndisruption to the Qualified vLEI Issuer’s business.\n\n81.2 An audit shall not give rights to access any information other than that directly\nrelating to the provision of the services and service levels as set out in\nAppendix 5 - Qualified VLEI Issuer Service Level Agreement (SLA) and/or to\nother contractual obligations of the Qualified vLEI Issuer under this Agreement,\nand the right of GLEIF to review the Qualified vLEI Issuer shall be limited to the\nspecific access reasonably needed to perform the audit, and shall not include\nthe right to install, add or execute software, or install, add or attach hardware,\non the Qualified vLEI Issuer's systems.\n\n81.3 At all times while on site at the Qualified vLEI Issuer’s premises GLEIF's\npersonnel (or GLEIF's delegates, as the case may be) shall comply with the\nQualified VvLEI Issuer’s standard written security policies and procedures\napplicable to its general visiting user population to the extent that such policy\nhas been notified in writing by the Qualified vLEI Issuer to GLEIF or has been\nclearly verbally brought to the attention of GLEIF's personnel (or GLEIF's\ndelegates) visiting the Qualified vLEI Issuer's premises at that time.\n\n81.4 The Qualified vLEI Issuer reserves the right to deny GLEIF's personnel (or\nGLEIF's delegates) access to any part of the Qualified VvLEI Issuer's premises\nwhere such access may reasonably pose a risk to compromise the proprietary\nnature of the Qualified vLEI Issuer's systems or the confidentiality of it, or its\ncustomers' data or their confidentiality.\n\n82. The scope and timing of all such audits will be discussed in advance, observing above\nprovisions, except in case of suspected fraudulent behavior.\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 21 of 31\nvLEI Issuer Qualification Agreement\n\n@ Public Document Version 1.0\n2022-12-06_vLEl-issuer-qualification-agreement_v1.0_final.docx 2022-12-06\n","contentLength":3223,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:21:22.754Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_vlei-issuer-qualification-agreement_v1.0_final.pdf","content":"83. The costs of all such audits, excluding Qualified vLEI Issuer preparation and\nparticipation in the audit, shall be borne by GLEIF alone, provided the audit does not\nproduce any findings. If the audit results in findings, the costs shall be borne by the\nQualified vLEl Issuer.\n\n84. The resultant audit report shall be addressed to GLEIF, and report distribution will be\ndetermined by GLEIF on a ‘need to know’ basis consistent with GLEIF’s transparency\nprinciples.\n\nXll. Term and Termination\nA. Initial Agreement Term\n\n85. Upon completion of Qualification, this Agreement is entered into for an initial term\nuntil the end of a 12-month period after the date of Qualification (the \"Initial Term\").\n\n86. After the Initial Term, this Agreement is automatically renewed by additional 12\nmonths upon successful completion of Annual vLEI Issuer Qualification unless the\nAgreement is terminated by a Party by giving 90 days prior to the end of the 12\nmonths term written termination notice.\n\nB. Termination for Cause\n\n87. If either Party believes that the other Party is not fully compliant with the terms of\nthis Agreement, or that the other Party continually violates a specific obligation, the\nfollowing rules shall apply:\n\n87.1 The aggrieved Party shall inform the other in writing, giving the full facts and\nexact references to the provisions of this Agreement which it believes have\nbeen violated, providing reasons for its position, and shall give the other Party\nthe opportunity to present its reply within a reasonable term which shall in no\nevent be longer than 30 Days from said notification.\n\n87.2 The accused party shall submit its reply, also giving the full facts and exact\nreferences to the provisions of this Agreement, either concurring with the\naggrieved Party's views, or providing reasons for its dissenting position.\n\n87.3 Tothe extent that the accused Party agrees with the aggrieved Party’s\nallegations, it shall set out in its response the steps it will take to rectify the\nissue, indicating a reasonable time frame for cure.\n\n87.4 To the extent that the accused Party does not agree with the allegations, the\naggrieved Party shall inform the accused Party about the continued areas of\ndisagreement providing the accused Party a further opportunity to remediate,\nwhich shall not exceed 15 Days from the communication above.\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 22 of 31\nvLEI Issuer Qualification Agreement\n\n@ Public Document Version 1.0\n2022-12-06_vLEl-issuer-qualification-agreement_v1.0_final.docx 2022-12-06\n","contentLength":2561,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:21:22.755Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_vlei-issuer-qualification-agreement_v1.0_final.pdf","content":"87.5 If the accused Party does not cure the issues noted within the stated period(s),\nthe aggrieved Party may terminate this Agreement with immediate effect; it\nmust do so in writing and by registered letter / receipt confirmation requested.\n\n88. In the event of a violation of Core Duties of this Agreement, whereupon the\naggrieved party cannot proceed without relief, and which in good faith prevents the\naggrieved Party to continue in this Agreement, the following rules apply:\n\n88.1 The aggrieved Party may inform the accused Party of its allegations relating to\ncompliance with this Agreement as set out in clause 87.1, demanding a cure\nwithin five Days.\n\n88.2 If the accused Party does not cure within that cure term, the aggrieved Party\nmay terminate this Agreement with immediate effect; it must do so in writing\nand by registered letter / receipt confirmation requested. If the aggrieved\nParty does not terminate the Agreement immediately after the five Days, it\nmay still proceed as set out under clause 87.\n\n89. For the avoidance of doubt, any termination is subject to mediation and arbitration\nas set out in Chapter XVI, and the Parties are particularly aware of the remedies\navailable to them set out in Chapter XV (Appeals and Complaints), particularly\nobserving the culture of communication.\n\n90. If termination for cause is triggered by GLEIF, the Qualified vLEl Issuer is no longer\nallowed to issue any new Legal Entity vLEI Credentials. In case the Qualified vLElI\nIssuer issues any new Legal Entity vLEI Credentials, this Agreement ends without\nprior mediation and arbitration as set out in Chapter XVI and clauses 92 to 94 and 96\nto 96.4 apply.\n\n91. GLEIF reserves the right to proceed to less drastic measures if GLEIF believes, in its\nsole but reasonable discretion, that a termination is not (or not yet) necessary to\npreserve the GLEIF's rights and the principles of the vLEI Ecosystem Governance\nFramework. For the sole purpose of examples, GLEIF may determine that the\nQualified vLEI Issuer can issue VLEIs only under certain conditions, or that agreements\nwith third parties must be suspended or amended, or that certain protective\nmeasures for the GLEIF must be implemented.\n\nC. Consequences of Termination\n\n92. The covenants and terms contained in this Agreement that contemplate their\nperformance after the expiration or termination of this Agreement shall be\nenforceable notwithstanding the expiration or termination of this Agreement.\n\n93. Upon expiration of this Agreement, the Qualified vLEl Issuer is no longer a Qualified\nVLEI Issuer which means in particular (but specifically without any limitation) that it is\nno longer part of the vLEI Ecosystem, and may no longer use the Qualified VLEI Issuer\nTrustMark, and must follow the process by which the Legal Entity vLEI Credentials\nissued by the terminated vLEl Issuer are revoked. This includes the requirement for\nthe Qualified vLEI Issuer to notify its Legal Entity clients of its termination as a\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 23 of 31\nvLEI Issuer Qualification Agreement\n\n@ Public Document Version 1.0\n2022-12-06_vLEl-issuer-qualification-agreement_v1.0_final.docx 2022-12-06\n","contentLength":3202,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:21:22.755Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_vlei-issuer-qualification-agreement_v1.0_final.pdf","content":"Quialified VLEI Issuer or otherwise ceasing Qualified vLEI Issuer operations. The\naffected Legal Entities must contract with a new Qualified VvLEI Issuer of their choice\nto replace the terminated vLEl Issuer and request issuance of vLEI Credentials from a\nnew Qualified vLEI Issuer.\n\n94, To enable GLEIF's coordination with Legal Entities as a result of the termination of a\nVLEI Issuer or otherwise ceasing of Qualified vLEI Issuer operations, Qualified vLElI\nIssuers must provide to GLEIF the email address contact details corresponding to the\ncurrent list of the Legal Entity’s Designated Authorized Representatives (DARs).\n\n95. The Parties are aware and acknowledge that an expiration or termination that is later\nheld invalid or unenforceable by a binding and final award of the arbitration court\n(see Chapter XVI) shall mean that this Agreement continued to be valid, effective,\nand enforceable.\n\n96. In order to avoid any damage arising from expiration or termination:\n\n96.1 the terminating Party may request the other Party to commence mediation\nproceedings within two months after receipt of the termination letter, where\nfailure to do so shall mean that the termination is valid; and/or\n\n96.2 the terminating Party may request the other Party to commence arbitration\nproceedings within two months after the mediation has ended, where failure\nto do so shall mean that the termination is valid; and/or\n\n96.3 the Parties may agree in writing, after one Party has issued a disputed\ntermination letter, that they shall continue to follow this Agreement fully or in\ncertain areas until either the termination is agreed by the Parties to be valid or\ninvalid, or a final award is handed down;\n\n96.4 where it is agreed and understood that by agreeing on terms under above\nclause 96.3 there is no prejudice regarding the validity or invalidity of the\ntermination letter.\n\nXlll. Agreement Change Process\n\n97. Both Parties agree that the requirements for implementing the vLEI Ecosystem and\nthus complying with the requirements of the vLEI Ecosystem may change over time,\nand that with increasing experience in the performance of this Agreement some of\nits provisions may require certain changes.\n\n98. For the avoidance of doubt, the following provisions regarding the Agreement\nchange process do not apply where this Agreement reserves GLEIF's right to change\nthe Agreement.\n\n99. To the extent that changes to this Agreement are of administrative nature, such as\nupdates to the contact details without deviating from the spirit of the original\nprovision, the Qualified vLEI Issuer takes note of, and accepts, that GLEIF may change\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 24 of 31\nvLEI Issuer Qualification Agreement\n\n@ Public Document Version 1.0\n2022-12-06_vLEl-issuer-qualification-agreement_v1.0_final.docx 2022-12-06\n","contentLength":2846,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:21:22.755Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_vlei-issuer-qualification-agreement_v1.0_final.pdf","content":"provisions of this Agreement without prior consultation of the Qualified vLEI Issuer\nand without needing the Qualified VLEl Issuer’s consent.\n\n100. In the event of change requirements as outlined in below clause, the provisions set\nout in clause 100.1 through 100.3 apply.\n\n100.1 The Qualified vLEI Issuer acknowledges and accepts that GLEIF may change\nprovisions of this Agreement to reflect changes\n\n(i) resulting from amendments to the vLEI Ecosystem Governance Framework,\nincluding those required by the Trust over IP Foundation, or\n\n(i) resulting from changes in applicable standards (regardless of whether\nbeing established by GLEIF or by a recognized third party such as Trust over\nIP Foundation (TolP) and World Wide Web Consortium (W3C), or\n\n(iii) resulting from major changes in the market and particularly in the\nrequirements of the General Public, or\n\n(iv) resulting from technical developments, or\n\n(v) resulting from changes in the legal framework or landscape.\n\n100.2 Itis understood that GLEIF shall make most judicious use of the above. In\naddition, whenever GLEIF decides that such changes are required, GLEIF\ncommits to community review with the Qualified vLEl Issuers and shall grant\nthe opportunity for Qualified vLEI Issuer to comment on the planned changes\nand on the timeframe proposed by GLEIF for operational implementation. The\ncomment period will be 30 Days.\n\n100.3 Following the close of the community review, GLEIF shall provide a summary of\nthe comments and their disposition and notify the Qualified vLEI Issuers about\nGLEIF’s decision and the change(s) that will be made, and the timeframe for\noperational implementation, if applicable. Those changes shall become\neffective within 30 Days after receipt of such change notice.\n\n101. GLEIF shall inform the Qualified vLEI Issuers about technical changes/upgrades to the\nGLEIF Controller/Qualified VvLEI Issuer software at least 90 days prior to expected\nimplementation. The Qualified vLEI Issuer will be responsible for the cost of the\nsuccessful installation, testing and implementation of the GLEIF Controller/Qualified\nVLEI Issuer software.\n\nXIV. Confidentiality\nA. Confidential Information\n102. Each Party acknowledges that the other Party may provide confidential information\nto the other both during Qualification and later on.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 25 of 31\nvLEI Issuer Qualification Agreement\n@ Public Document Version 1.0\n2022-12-06_vLEl-issuer-qualification-agreement_v1.0_final.docx 2022-12-06\n","contentLength":2531,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:21:22.755Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_vlei-issuer-qualification-agreement_v1.0_final.pdf","content":"103. To protect confidential information required during Qualification, the Parties will sign\na Non-Disclosure Agreement, Appendix 1.\n104. The template of this Agreement will not be confidential and is a Controlled\nDocument of the vLEI Ecosystem Governance Framework.\nB. Data Protection\n105. The Qualified vLEI Issuers must comply with the Data Protection provisions contained\nin the vLEI Ecosystem Information Trust Policies document.\nXV. Appeals and Complaints\nA. Basic Principle\n106. GLEIF's goal is to resolve issues between GLEIF and the Qualified vLEI Issuer amicably.\nHence, before taking resort to steps like lodging an appeal or complaint or mediation\nor arbitration, or steps towards termination, or before formally raising a claim for\ndamages, the affected Party shall whenever possible take the issue up openly and in\ngood faith with the other Party, giving a mutual opportunity to understand and to\nremove misunderstandings, to cure amicably, and to resolve the issue in mutual trust\nand co-operation.\n107. GLEIF is particularly aware that during vLEI Issuer Qualification or Annual vLEI Issuer\nQualification, views of GLEIF and the Candidate or Qualified vLEI Issuer might differ,\nand that taking recourse to mediation and arbitration as set out in Chapter XVI\nshould be confined as well as reasonably possible.\n108. Further, GLEIF wishes to establish a mechanism for both itself and for the Qualified\nVLE!l Issuer, LOUs, as well as for third parties to submit complaints of whatever nature\nrelating to the Qualified vLEI Issuer or GLEIF, respectively.\n109. The following Sub-Chapters set out the rules that shall govern.\nB. Reconsideration of GLEIF Decisions Regarding vLEI Issuer Qualification or Annual\nvLEl Issuer Qualification\n110. The vLEl Issuer Qualification Program Manual (Appendix 2) governs the process by\nwhich appeals may be submitted by the Candidate or Qualified vLEl Issuer.\nC. Reconsideration and Complaints\n111. The Qualified vLEI Issuer may submit to GLEIF a request for reconsideration, or\ncomplaints against GLEIF, or complaints against another Qualified vLEl Issuer or a\nLOU, as well as inform GLEIF about complaints it has received from another Qualified\nVLE! Issuer, a LOU or from third parties, e.g., any Legal Entity. Further, GLEIF may also\nprovide to the Qualified vLEI Issuer complaints from outside parties submitted to\nGLEIF relative to the Qualified vLEI Issuer.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 26 of 31\nvLEI Issuer Qualification Agreement\n@ Public Document Version 1.0\n2022-12-06_vLEl-issuer-qualification-agreement_v1.0_final.docx 2022-12-06\n","contentLength":2627,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:21:22.755Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_vlei-issuer-qualification-agreement_v1.0_final.pdf","content":"112. Either GLEIF or the Qualified vLEl Issuer, as the case may be, shall respond to the\nParty submitting the case relative to the reconsideration request or to the complaint\nwithin 30 Days of receipt.\n\n113. The Parties shall thereafter take up talks in the spirit of clause 106 and 107 in order\nto find a solution taking into consideration all relevant facts, and the mutual interests\nof GLEIF, the Qualified VvLEI Issuer (or other Qualified vLEI Issuers) or LOUs and of the\ngeneral public.\n\nXVI. Mediation and Arbitration\nA. Principles\n\n114. Both Parties agree that any disputes, controversies, or claims arising out of, or in\nrelation to, this Agreement, including (explicitly without limitation) the validity,\ninvalidity, breach, or termination thereof, should be solved whenever possible\namicably.\n\n115. To that end, both Parties shall seek to proactively establish confidence in each other,\nparticularly (but explicitly without any limitation whatsoever) by using the remedies\navailable to them under Chapter XV.\n\n116. A Party formally alleging that the other Party breaches this Agreement shall inform\nthe other in writing, by registered letter / return receipt requested, giving the full\nfacts and exact references to the provisions of this Agreement which it believes to be\nin violation, providing reasons for its position, including documentation and its\narguments so as to enable the other Party to consider the issue in all relevant\naspects.\n\n117. If the issue cannot be resolved immediately or in the process set out in clauses 87\nand 88, the Parties shall first attempt to resolve the matter informally through\ndiscussions and/or meetings attended by staff of an appropriate hierarchy level,\nseeking to settle diverging views in fair and positive-minded personal contacts.\n\n118. If the dispute cannot be resolved, or if the parties disagree about the validity of a\ntermination notified pursuant to the process set out in clauses 87 and 88, Parties\nmay agree to seek mediation pursuant to the following Sub-Chapter B and/or\narbitration pursuant to the following Sub-Chapter C.\n\n119. While nothing in this Chapter XVI prevents either Party to seek relief at ordinary\ncourts for urgent provisional measures such as provisional injunctions or the\nsafeguarding of evidence, the Parties are prevented from lodging ordinary court\naction at ordinary courts, i.e. they both submit bindingly to the exclusive jurisdiction\nof the arbitration court as agreed in Sub-Chapter C of this Chapter.\n\n120. The Parties are aware and agree that cost of mediation and arbitration (including\nreasonable cost of legal representation), as determined by the mediator or the\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 27 of 31\nvLEI Issuer Qualification Agreement\n\n@ Public Document Version 1.0\n2022-12-06_vLEl-issuer-qualification-agreement_v1.0_final.docx 2022-12-06\n","contentLength":2880,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:21:22.755Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_vlei-issuer-qualification-agreement_v1.0_final.pdf","content":"arbitration tribunal, respectively, shall be borne by the Party losing the case, and that\nin the event of both winning to some extent and losing to some extent cost shall be\nshared proportionally.\n\nB. Mediation\n\n121. If the Parties are unable to resolve the matter themselves within 60 Days after the\nformal notification according to clause 116, either Party may submit the matter to\nmediation, by written notification to the other Party.\n\n122. GLEIF shall appoint a single independent mediator who seeks to reconcile the Parties,\nand who shall make a recommendation to the Parties.\n\n123. The language of the mediation proceedings shall be English.\n\n124. The place of the mediation shall be Basel/Switzerland, except if both Parties agree in\na written and signed instrument on a different place.\n\n125. A mediation request and ongoing mediation prevent the Parties to commence\narbitration proceedings, except if the other Party can show clear evidence that the\nmediation request was submitted in bad faith such as, for instance, for the sole\nreason of delaying the matter.\n\n126. If a mediation has not resulted, for whatever reasons, within two months after the\nmediation request, in a reconciliation, or if either Party is not prepared to accept the\nmediator's recommendation, then either Party is free to initiate arbitration\nproceedings. Alternatively, both Parties may agree in writing to extend mediation for\na three-month period.\n\nC. Arbitration\n\n127. All disputes arising out of or in connection with this Agreement shall be exclusively\nand finally settled under the Rules of Arbitration of the International Chamber of\nCommerce by three arbitrators appointed in accordance with the said Rules, where,\nfor the avoidance of doubt, the Emergency Arbitrator Provisions apply as well.\n\n128. The language of the arbitration proceedings shall be English.\n\n129. The place of arbitration shall be Basel/Switzerland, except if both Parties agree in a\nwritten and signed instrument on a different place.\n\n130. The number of arbitrators shall be three, except if both Parties agree in advance and\nin a written and signed instrument on a sole arbitrator.\n\nD. Mediation and Arbitration for Disputes Among Qualified vLEIl Issuers\n131. Inthe event of disputes between the Qualified vLEI Issuer and any other Qualified\nvLEI Issuer, the Qualified vLEI Issuer agrees to seek a solution and amicable\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 28 of 31\nvLEI Issuer Qualification Agreement\n@ Public Document Version 1.0\n2022-12-06_vLEl-issuer-qualification-agreement_v1.0_final.docx 2022-12-06\n","contentLength":2602,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:21:22.755Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_vlei-issuer-qualification-agreement_v1.0_final.pdf","content":"agreement by negotiating the issue in good faith with the other Qualified vLEI Issuer\nin the spirit of Chapter XV.\n\n132. Inthe event such negotiations fail, the Qualified VLEI Issuer and the other Qualified\nVLEl Issuer, are obliged to first seek mediation before applying for arbitration. GLEIF\nshall appoint a mediator of its own choice. The cost of the mediator is borne equally\nby both the Qualified vLEI Issuer and the other Qualified VLEI Issuer.\n\n133. Inthe event that the dispute cannot be resolved amicably, the Qualified vLEI Issuer\nand the other Qualified VvLEl Issuer, irrevocably and bindingly agree to submit their\ndispute to the International Chamber of Commerce for Arbitration as set out in\nabove Sub-Chapter C.\n\nXVIl. Miscellaneous\nA. Applicable Law\n\n134. This Agreement shall in all respects be governed by, and construed and interpreted in\naccordance with, the substantive laws of Switzerland, without regard to Switzerland's\nconflict of laws rules. GLEIF maintains on its website a list with links to some online\nresources to Switzerland's federal and cantonal law as well as federal court practice,\nwhich list for the avoidance of doubt shall however not, on any account, be\nconstrued as limiting in whatever way the scope of the applicable substantive laws of\nSwitzerland.\n\n135. Notwithstanding the above choice of Law, both Parties acknowledge that certain\nareas and issues may be mandatorily governed by a different law, such as by the local\nlaw at the Qualified vLEI Issuer’s domicile, and national trademark law regarding the\nTrustMark issued to a Qualified vLEl Issuer or the Qualified vLEl Issuer’s additional\ntrademarks.\n\nB. No Agency\n\n136. The relationship between GLEIF and the Qualified vLEI Issuer does not constitute a\njoint venture or partnership in the meaning of Art. 530 et seq. of the Swiss Code of\nObligations or any similar form of cooperation under any other applicable laws.\n\nC. Severability\n\n137. The invalidity of individual parts of this Agreement shall have no impact on the\nvalidity of the Agreement as a whole. The Parties agree that if any provision or part\nof a provision of this Agreement shall, for whatever reason, be deemed invalid,\ninoperative, or otherwise not enforceable, the Agreement as a whole shall remain\nvalid, and the invalid or inoperative provision or part of a provision shall be\nconsidered replaced by the provision which the Parties would have agreed on in good\nfaith if they had been aware of the invalidity of the respective provision.\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 29 of 31\nvLEI Issuer Qualification Agreement\n\n@ Public Document Version 1.0\n2022-12-06_vLEl-issuer-qualification-agreement_v1.0_final.docx 2022-12-06\n","contentLength":2726,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:21:22.755Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_vlei-issuer-qualification-agreement_v1.0_final.pdf","content":"D. Assignment\n\n138. The Qualified vLEI Issuer is not entitled to transfer this Agreement or any rights or\nobligations under this Agreement to any third party.\n\n139. The Qualified vLEI Issuer is entitled to delegate or sub-contract services as defined in\nSub-Chapter B.\n\n140. GLEIF is entitled to delegate or sub-contract the exercise of its rights or obligations to\nanother entity, provided that GLEIF remains responsible to the Qualified vLEI Issuer\nfor the performance and the observance of this Agreement.\n\n141. If the functions of GLEIF are transferred to another entity, GLEIF is entitled to transfer\nits rights and obligations to such successor entity.\n\nE. Written Form, Entire Agreement\n\n142. This Agreement, including this clause, may only be amended, waived,\nrescinded, or terminated in writing.\n\n143. This Agreement contains the entire understanding of the Parties with respect\nto the subject matter hereof and substitutes and merges any previous\nagreement, be it written or oral, among the Parties hereto concerning the\nsubject matter hereof.\n\nF. Contact Persons, Address, Phone, Website, Mail\n\n144. The primary contact persons of either Party, such as Designated Authorized\nRepresentatives (DARs), as well as specialized contact persons (such as technical\nstaff), are listed in Appendix 4 vLEI Issuer Contact Details.\n\nG. Cost\n\n145. Subject to provisions herein containing agreements to the contrary, each Party bears\nits own costs in relation to the drafting, conclusion, closing and performance of this\nAgreement.\n\nH. Formal Notifications\n\n146. Notifications to be made under this Agreement are only validly made by registered\nmail, return receipt requested, or by e-mail followed by a duly dated and signed copy\nof that e-mail within 5 Days (sent by registered mail, return receipt requested), or by\ntelefax (explicitly confirmed by the recipient), to the addresses listed in Appendix 4.\n\n147. Address changes have to be notified without delay to the other Party; as long as no\nsuch notification of change of address is received, notifications hereunder are validly\nmade to the last valid address in accordance with Appendix 4. Time limits are\ndeemed complied with if a notification is (i) handed over for delivery to the recipient\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 30 of 31\nvLEI Issuer Qualification Agreement\n\n@ Public Document Version 1.0\n2022-12-06_vLEl-issuer-qualification-agreement_v1.0_final.docx 2022-12-06\n","contentLength":2464,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:21:22.755Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_vlei-issuer-qualification-agreement_v1.0_final.pdf","content":"B.Reconsideration of GLEIF Decisions Regarding vLEI Issuer Qualification or Annual vLEI\nIssuer QUAlIfICAtION........ceiecie et et ee et aeerraesenneeees 20\nC.Reconsideration and Complaints ........ccccerieiieiriiviiieiiceee e sree e seee e seeeen. 20\nXVI. Mediation and Arbitration ......ccccccoirrueiiiiiinniiiiiniiiniinnnini. 27\nALPTINCIPIES 1.ttt e st e e st ae e s rae e e stae e e snaeaesnnneaesnnnans 2\n2V =T L= d o o [ SUPPTPUPUPRPRD2\n(O AY g o111 -1 i o [P UPPPPPRRRPPRPRRRRPPRRD.L -\nD.Mediation and Arbitration for Disputes Among Qualified vLEl Issuers......................... 28\nXVIL.MiSCellan@OuUS .......ccevuuriiiiinnniiiiinniiiinaiiiieiaiiiinaiammsnesnse 29\nALAPPHCADIE LAW 1eetiiiiiiiee ettt sttt srte e st ste e snae s s sneassnnens 20\nB.NO AZEBNCY oiiiiiiiieie ettt ettt e st re e e e s s rrreee e s e s s nraeteeeassnnnaeaeaeessnsnreneaeenaes 2O\nC.SEVEIADIITY .eeiiiieieeiieie e s sr e s snae e s snneaesnnees 2\nDLASSIBNMENT ...ciiiiiiiiie ettt ee et re e e e ss st e te e s es s sarteaeaeessesneseaeeeesssnnsnneesessanssssnseseesans 30\nE.Written Form, Entire ABreement ........ccoiviiiiiiiiiiiiiniceie ettt ee e ssineieee e s e sneeeeeenees 30\nF. Contact Persons, Address, Phone, Website, Mail......cccccccvvvveeiiiiiiiiccccc. 30\nLG 60 1] O PO P PP PP PPPPPRUPUPPPPPPRPRC 1O\nH.Formal NOtifiCations.........ccceeeiieeiie et s stve e ssnee e e e sssessseessneeenes 30\nL. NO WV ittt et te e e s e e st eeee e s essearaeteeeaessnssnneaeessassseneaeensns DL\nJ. FOICE IMIQJUBIE ...ttt ettt ettt ettt ee e ettt te e e e es s arbeteeeesssnrbeneaeessasnnseneeeenans D1\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 4 of 31\n\nvLEI Issuer Qualification Agreement\n\nGLEIF Public Document Version 1.0\n@ 2022-12-06_vLEl-issuer-qualification-agreement_v1.0_final.docx 2022-12-06\n","contentLength":1799,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:21:22.755Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_vlei-issuer-qualification-agreement_v1.0_final.pdf","content":"to an international courier service, or (ii) sent by telefax or e-mail no later than the\nlast Day of the relevant time limit.\nl. No Waiver\n148. No act, delay, or omission on a Party's part in exercising any right or remedy shall\noperate as a waiver of such or any other right or remedy. No single or partial waiver\nby a Party of any provision of this Agreement, or of any breach or default by the\nother Party, or of any right or remedy, shall operate as a waiver of any other\nprovision, breach, default, right or remedy or of such provision, breach, default, right\nor remedy on a future occasion.\nJ. Force Majuere\n149. In the event of force majeure, such as floods, tsunamis, earthquakes, fires, storms\nsuch as hurricanes or typhoons, war, pandemic crisis, strikes, riots, volcanic\neruptions, or any other similar extraordinary situation, event, or circumstance\nbeyond the control of either Party, the obligations of the Parties are suspended to\nthe extent force majeure prevents their reasonable performance, and no damage\nclaims shall arise for that reason.\n150. Once the force majeure ceases, the Parties shall seek in good faith to resume orderly\nbusiness.\n151. If the force majeure persists for more than three months, the Parties shall convene to\nfind an acceptable intermediate agreement.\nsksksk\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 31 of 31\nvLEI Issuer Qualification Agreement\n@ Public Document Version 1.0\n2022-12-06_vLEl-issuer-qualification-agreement_v1.0_final.docx 2022-12-06\n","contentLength":1517,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:21:22.755Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_vlei-issuer-qualification-agreement_v1.0_final.pdf","content":"List of Appendices -\n\nAppendix 1: Non-Disclosure Agreement (NDA)\n\nAppendix 2: vLEIl Issuer Qualification Program Manual\n\nAppendix 3: vLEl Issuer Qualification Program Checklist\n\nAppendix 4: vLEl Issuer Contact Details\n\nAppendix 5: Qualified vLEI Issuer Service Level Agreement (SLA)\n\nAppendix 6: Qualified VvLEI Issuer TrustMark Terms of Use\n\nAppendix 7: Qualified vLEI Issuer-Legal Entity Required Contract Terms\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 5 of 31\nvLEI Issuer Qualification Agreement\n\n@ Public Document Version 1.0\n\n2022-12-06_vLEl-issuer-qualification-agreement_v1.0_final.docx 2022-12-06\n","contentLength":627,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:21:22.755Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_vlei-issuer-qualification-agreement_v1.0_final.pdf","content":"I. Purpose and Scope\n\n1. The verifiable LEI (vLEI) Ecosystem Governance Framework vLEI Issuer Credential\nQualification Agreement (\"this Agreement\") sets out the rights and obligations of\nGLEIF and of the Qualified vLEI Issuer regarding the Qualified vLEI Issuer’s\nparticipation in the vLEI Ecosystem and infrastructure, including in particular (but for\nthe avoidance of doubt without limitation) the Qualification of the Qualified vLElI\nIssuer, the issuance of new vLEls and maintenance of vLEls, revenue and business\nmodel, services provided by GLEIF and by the Qualified vLEI Issuer, adherence to and\ncompliance with the vLEI Ecosystem Governance Framework, ensuring competition\nand avoiding anti-trust at global and local levels, and the binding rules regarding\ndispute resolution and court competence.\n\n2. In the event of a contradiction between this Agreement and any of its Appendices,\nthat Appendix shall prevail, provided that in such Appendix (i) this preference\nappears clear and unambiguous, and (ii) except where stipulated otherwise. More\nrecent Appendices shall prevail, in the event of contradictions with older Appendices.\n\nIl. Definitions\nAgreement The VLEI Ecosystem Governance Framework vLEI Issuer\nQualification Agreement as signed by both Parties, where for the\navoidance of doubt any reference to \"Agreement\" includes all\nAppendices\nAnnual vLEI Issuer A formal annual evaluation process performed by GLEIF to ensure\nQuialification that the Qualified vLEI Issuer continues to meet the requirements\nof the vLEI Ecosystem Governance Framework\nAudit Report An audit report provided to the Qualified vLEl Issuer by its internal\nor external auditors or comparable function\nCandidate vLEl Issuer An organization that has applied to become a Qualified vLElI\nIssuer\nCore Duties Duties of the Qualified vLEI Issuer set forth in Chapter IV of this\nAgreement\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 6 of 31\nvLEI Issuer Qualification Agreement\n@ Public Document Version 1.0\n2022-12-06_vLEl-issuer-qualification-agreement_v1.0_final.docx 2022-12-06\n","contentLength":2080,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:21:22.755Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_vlei-issuer-qualification-agreement_v1.0_final.pdf","content":"Day A business day, provided that a given day only counts as such if it is\na business day both at GLEIF's legal domicile in the operating office\nin Frankfurt/Germany, and at the Qualified vLEI Issuer’s domicile\n\nDesignated Authorized | A representative of a Legal Entity who is authorized by the Legal\n\nRepresentative (DAR) Entity to act officially on behalf of the Legal Entity. A DAR can\nauthorize vLEl Issuer Qualification Program Checklists, execute the\nvLEI Issuer Qualification Agreement and provide designate/replace\nLegal Entity Authorized Representatives (LARs)\n\nEffective Date The later of the dates of signing shown on the first page after the\ncover page of this Agreement\n\nExtraordinary vLEI Qualification conducted under exceptional circumstances which\n\nIssuer Qualification give GLEIF reason to believe that the Qualification Documentation\nis no longer current or being adhered to\n\nfor example, e.g., such | \"For example,\", \"e.g.,\", \"such as\", \"including\", \"in particular\" and\n\nas, including, in similar expressions consistently denote that the following are\n\nparticular examples, without any limitation and/or without limiting the\ngenerality of requirements, given for illustrative or highlighting\npurposes, except where explicitly stated otherwise\n\nGLEIF Global Legal Entity Identifier Foundation\n\nGLEIF Website http://www.gleif.org\n\nGLEIS Global Legal Entity Identifier System\n\nGlobal LEI Repository A database managed by GLEIF containing all current and historical\nLEls and LEI reference data\n\nIT Information Technology, encompassing application software,\ncomputer and network systems and suitable equipment for the\nimplementation and support of such systems\n\nLegal Entity A representative of a Legal Entity who is authorized by a DAR of a\n\nAuthorized Legal Entity to request issuance and revocation of vLEI Legal Entity\n\nRepresentative (LAR) Credentials, Legal Entity Official Organizational Role VLElI\nCredentials (OOR vLEI Credentials), and Legal Entity Engagement\nContext Role vLEI Credentials (ECR vLEI Credentials)\n\nLegal Entity As defined in ISO 17442:2020, includes, but is not limited to,\nunique parties that are legally or financially responsible for the\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 7 of 31\nvLEI Issuer Qualification Agreement\n\n@ Public Document Version 1.0\n2022-12-06_vLEl-issuer-qualification-agreement_v1.0_final.docx 2022-12-06\n","contentLength":2396,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:21:22.755Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_vlei-issuer-qualification-agreement_v1.0_final.pdf","content":"performance of financial transactions or have the legal right in\ntheir jurisdiction to enter independently into legal contracts,\nregardless of whether they are incorporated or constituted in\nsome other way (e.g., trust, partnership, contractual). It includes\ngovernmental organizations and supranational and individuals\nwhen acting in a business capacity but excludes natural persons. It\nalso includes international branches\nLegal Entity Official vLEI Role Credentials issued to persons acting officially on behalf of\nOrganizational Role a Legal Entity. These persons and their roles can be validated by\nVLEI Credentials the Legal Entity as well as by one or more external official sources\nLEI, LEIs Legal Entity Identifier(s)\npdf, pdf-document A document in the standard portable document format \"pdf\"-\nformat\nQualification The formal evaluation process performed by GLEIF to ensure that\nan organization which has applied for Qualification (a Candidate\nVLEI Issuer) meets the requirements of the vLEI Issuer Qualification\nProgram\nQualification The documentation to be provided by the Candidate vLEl Issuer to\nDocumentation GLEIF for evaluation for Qualification, where the final\ndocumentation becomes binding upon successful Qualification\nQualified vLEl Issuer The contracting party to the Agreement that has been qualified by\nQv GLEIF as a Qualified vLEI Issuer\nRegulatory Oversight An organization of regulators from multiple jurisdictions charged\nCommittee (ROC) by the G-20 with oversight of the GLEIS; http://www.leiroc.org\nSwiss law A set of rules, orders, regulation, and court decisions which\nconstitutes the law in Switzerland. The source of Swiss law can be\nfederal or cantonal. GLEIF will host a list of links where Swiss law\ncan be found\nTrustMark A TrustMark for a Qualified vLEI Issuer provided by GLEIF to the\nQuialified VLEl Issuer (see Appendix 7)\nverifiable LEI (VLEI) A specific Ecosystem Governance Framework for governing the\nEcosystem entire Trust over IP (TolP) layer 4 trust ecosystem for the vLEI\nGovernance\nFramework (EGF)\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 8 of 31\nvLEI Issuer Qualification Agreement\n@ Public Document Version 1.0\n2022-12-06_vLEl-issuer-qualification-agreement_v1.0_final.docx 2022-12-06\n","contentLength":2261,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:21:22.755Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_vlei-issuer-qualification-agreement_v1.0_final.pdf","content":"VLEI Issuance The process beginning with the request of a Legal Entity to assign a\nvLEI containing the entity’s LEI\n\nvLEl Issuer Appendix 3 to the vLEl Issuer Qualification Agreement which\n\nQualification Program | details the control and process requirements for Qualification\n\nChecklist\n\nvLEl Issuer Appendix 2 to the vLEl Issuer Qualification Agreement which\n\nQualification Program | describes the requirements and steps towards Qualification and\n\nManual the sections of Qualification Program Checklist\n\nvLEl Maintenance All steps taken to ensure that the vLEIl continues to be based on\nthe existence of a LEI with a LEI Entity Status of Active and a LEI\nRegistration Status of Issued, Pending Transfer or Pending Archival\nin the Global LEI System\n\nVvLEI Revocation Action taken to invalidate a vLEI if it is determined that the LEIl no\nlonger has a LEI Entity Status of Active and a LEI Registration Status\nof Issued, Pending Transfer or Pending Archival in the Global LEI\nSystem, or upon revocation of a Qualified vLEI Issuer Authorization\nVLEI Credential received from a LAR in accordance with a vLEl\nCredential Framework\n\nlll. Qualification for the Candidate vLEI Issuer\nA. The vLEl Issuer Qualification Program\n\n3. The details of the Qualification program are described in the vLEI Issuer Qualification\nProgram Manual (Appendix 2).\n\n4, GLEIF shall be obliged to grant Qualification to the Candidate vLEl Issuer if and when\nall components of the vLEl Issuer Qualification Program Checklist (Appendix 3) and\nthe review of the Qualification Documentation have been completed in due time and\nall criteria for successful Qualification have been met.\n\nB. Use of Third-Party Services\n\n5. The Qualified vLEI Issuer may use Third-Party Services running portions of or its IT,\noperational infrastructure, and administrative functions (e.g., finance, HR) unrelated\nto vLEI services.\n\n6. However, the Qualified vLEI Issuer may not use Third-Party Services to partly or fully\nperform its Core Duties as set out in Chapter IV, even if such third party should be\nanother Qualified vLEI Issuer but may use Third-Party Services to assist in the\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 9 of 31\nvLEI Issuer Qualification Agreement\n\n@ Public Document Version 1.0\n2022-12-06_vLEl-issuer-qualification-agreement_v1.0_final.docx 2022-12-06\n","contentLength":2348,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:21:22.755Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_vlei-issuer-qualification-agreement_v1.0_final.pdf","content":"performance of Core Duties. As an example, the Qualified vLEI Issuer may use Third-\nParty Services for the Identity Assurance of Legal Entity Authorized Representatives\n(LARs) and persons to which Legal Entity Official Organizational Role vLEI Credentials\nare to be issued long as proper security access controls are put in place between the\nQuialified VLEl Issuer and the third-party provider and the third-party provider follows\nthe requirements of the vLEI Ecosystem Governance Framework.\n\n7. The Qualified vLEI Issuer may use the services of a qualified third party for\nassessment of its financial, operational and/or information technology practices and\nfor independent audit purposes. Reports from such third parties will be accepted for\nconsideration by GLEIF as part of the Qualification process, provided the report and\npertaining documentation specifically addresses, and meets or exceeds the\nrequirements of the vLEl Issuer Program Qualification Checklist (Appendix 3).\n\n8. Even when and to the extent which Third-Party Services shall be permitted, the\nQualified vLEI Issuer remains fully and unrestrictedly responsible and liable for\ncomplying with, and acting in the spirit of, all of the requirements for Qualification.\nThis applies to going concern issues, quality, security, and compliance as specified in\nthe vLEI Ecosystem Governance Framework.\n\nC. No Sublicensing of Qualification\n\n9. The Qualified vLEI Issuer is prohibited from sublicensing its Qualification to any third\nparty, even if and to the extent it controls such licensee, and even if and to the\nextent such sublicensee might be another accredited local operating unit. Likewise,\nthe Qualified vLEl Issuer is prohibited from otherwise making its Qualification status\navailable for use to any third party.\n\nD. Change Process Qualification Program\n\n10. For the avoidance of doubt, the vLEI Issuer Qualification Program Checklist (Appendix\n3) upon which the Qualification is based, and which lead to the issuance of a\nQuialified vLEl Issuer vLEI Credential and the TrustMark, constitutes a binding and\nenforceable agreement regarding any and all technical details agreed or mentioned\ntherein, such as the validation and verification requirements before issuing a vLEl.\n\n11. Throughout the Qualification process, the Candidate vLEI Issuer is obliged to inform\nGLEIF without undue delay about (i) any changed facts which form part of the\ncompleted vLEI Issuer Qualification Program Checklist (Appendix 3) that has been\nsubmitted by the vLEI Issuer, in particular about events or developments which\nconcern its legal status such as form of incorporation, change of signatory power of\nits officers and the like, and/or about (ii) other facts or events or developments\nwhich actually or potentially significantly influence the Qualification and/or the\nagreed time schedule.\n\n12. The same obligation to inform applies to Qualified vLEI Issuers.\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 10 of 31\nvLEI Issuer Qualification Agreement\n\n@ Public Document Version 1.0\n2022-12-06_vLEl-issuer-qualification-agreement_v1.0_final.docx 2022-12-06\n","contentLength":3130,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:21:22.756Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2023-04-03_appendix-1-non-disclosure-agreement_v1.1_final.pdf","content":"O:GLEIF’ Protecting diltaltrust.\nverifiable LEI (vLEl)\nEcosystem Governance Framework v1.0\nVLEI Issuer Qualification Agreement\nAppendix 1 Non-Disclosure Agreement\nDocumel:ml:t\\)llzecrsion 11\n2023-04-03\ne - : “! \" ‘ . '\nO | %‘? - o8 5\n60 N . e\n\" e T ‘!e/’ (‘ z i .o . = : -\n- }\";{“\"\"\".i - -\n}* ..‘.‘ > P ‘ A ° . O N . 3\nN\n","contentLength":321,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:21:43.047Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2023-04-03_appendix-1-non-disclosure-agreement_v1.1_final.pdf","content":"Non-Disclosure Agreement\nBetween\nGlobal Legal Entity Identifier Foundation\nSt. Alban-Vorstadt 5, 4052 Basel/Switzerland\n“GLEIF”\nand\n**Name of Qualified vLEI Issuer\n**Address of Qualified vLEI Issuer\n“Qualified vLEI Issuer”\neach also “a Party”, together “the Parties”\nregarding Confidential Information\nBasel, **Date **Place, Date\nBy: Stephan Wolf Sven Schumacher By\nFunction(s): CEO General Counsel Function(s):\nmade in two originals, one for each Party\n","contentLength":454,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:21:43.047Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2023-04-03_appendix-1-non-disclosure-agreement_v1.1_final.pdf","content":"Whereas\n\nA. The Parties plan to enter into the vLEI Issuer Qualification Agreement regarding the Qualified vLEI\nIssuer’s (Candidate vLEI Issuer until successful completion of the vLEI Issuer Qualification\nProgram)\n\nB. Definitions set out in the VLEI Issuer Qualification Agreement are valid for this Non-Disclosure\nAgreement as well, and both Parties confirm to be aware of those.\n\nC. Already before, but as well in the course of, performance of their respective rights and\nobligations under the vLEI Issuer Qualification Agreement, the Parties will disclose to each other\nand, in the event, to their respective affiliates, employees, advisors and representative’s certain\nconfidential information, and will contact employees of those.\n\nD. Both Parties are interested in strict confidence with regard to certain disclosed information.\n\nNow, therefore, the Parties agree as follows:\n\nl. Confidentiality Undertaking\n\nA. Disclosure of Information\n\n1. The Parties will disclose certain information to each other, and for each occurrence of such\ndisclosure, the Party disclosing the information is herein referred to as the Disclosing Party,\nwhereas the Party receiving the information is referred to as the Receiving Party.\n\n2. Forthe avoidance of doubt, a reference to a Disclosing or a Receiving Party, respectively, shall\ninclude its respective affiliates, employees, auxiliary persons such as freelancers, advisors, and\nrepresentatives.\n\nThe Qualified vLEI Issuer is aware that GLEIF eventually has to disclose certain information on\nrequest. Hence, regarding GLEIF a reference to the Receiving Party shall further include (i) the\nChairperson and (ii) the Vice-Chairperson of ROC, and (iii) the Supervisor (member of ROC) if\nsuch Supervisor has been formally designated.\n\nB. Confidential Information\n\n3. \"Confidential Information\" shall mean all information furnished to the Receiving Party by the\nDisclosing Party, whether furnished before the signing, or Effective Date, of the VLEl Issuer\nQualification Agreement in the context of negotiations or during the term of the vLEl Issuer\nQualification Agreement,\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 3 of 5\nPublic Document Version 1.1\n2022-04-03_appendix-1-non-disclosure-agreement_v1.1_Final 2023-04-03\n","contentLength":2278,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:21:43.047Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2023-04-03_appendix-1-non-disclosure-agreement_v1.1_final.pdf","content":"i. if transmitted in text form, namely in hardcopy such as a letter or an agreement, or\nelectronically such as a pdf- or Word-document, or by e-mail, and the like,\n\nii. and if clearly marked as \"CONFIDENTIAL\".\n\n4. Confidential Information does not include, however, information which\n\ni. is already publicly known or becomes publicly known other than as a result of either Party's\nbreach of the confidentiality undertaking;\n\nii. was or will be disclosed to the Receiving Party without confidentiality reservation prior to\n\ndisclosure to the Receiving Party, provided that such disclosure did not constitute a breach of\na Non-Disclosure-Agreement of the Disclosing Party with either GLEIF or any local operating\nunit (including Applicant and Candidate local operating units) or was obtained by the\nDisclosing Party in breach of laws;\n\niii. the Receiving Party is required to disclose due to applicable laws, a judgement or an order of\na competent authority. In such case, the Receiving Party will notify the Disclosing Party\nwithout delay of such disclosure obligation (except if prohibited by law, judgement or order)\nin order to enable the Disclosing Party to seek an appropriate protective order or other\nappropriate remedy. In any case, the Receiving Party will limit such disclosure to the legally\nrequired minimum.\n\n5. The Disclosing Party shall not unduly mark information provided as \"Confidential\". The Receiving\nParty may inquire, from time to time, whether some specific information is still confidential.\n\n6. The Receiving Party is aware and acknowledges for each occurrence of disclosure of Confidential\nInformation that the Disclosing Party has a significant interest that all its Confidential Information\nbe kept confidential, in particular because such Confidential Information may contain know-how\nand business secrets of the Disclosing Party or may be subject to banking secrecy or similar\nmandatory restrictions.\n\n7. The Receiving Party agrees\n7.1. to keep all Confidential Information confidential and not to disclose, or allow access to, any\n\nConfidential Information to any person other than its affiliates, employees, advisors and\nrepresentatives who are actively and directly participating in the performance of the vLElI\nIssuer Qualification Agreement, or who otherwise need to know the Confidential\nInformation;\n\n7.2. to procure that any such affiliates, employees, advisors and representatives will observe the\nterms of this Non-Disclosure Agreement as if such persons were a party hereto, which\nincludes for the avoidance of doubt the ROC-members mentioned in Section 2 2nd\nparagraph;\n\n7.3. to assume responsibility and to be held liable for any disclosure or use of the Confidential\nInformation other than expressly permitted in this Non-Disclosure Agreement, pursuant to\nthe vLEI Issuer Qualification Agreement’s provisions regarding warranty and liability.\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 4 of 5\n@ Public Document Version 1.1\n2022-04-03_appendix-1-non-disclosure-agreement_v1.1_Final 2023-04-03\n","contentLength":3057,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:21:43.047Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2023-04-03_appendix-1-non-disclosure-agreement_v1.1_final.pdf","content":"8. The Receiving Party undertakes to use best efforts to protect and maintain the confidentiality of\nthe Confidential Information and to prevent access of unauthorized persons to the Confidential\nInformation.\n\n9. Upon the termination of the vLEIl Issuer Qualification Agreement, each party shall upon request\nreturn to the other Party, or destroy, all copies and other records of Confidential Information,\nexcept if and to the extent mandatory provisions of law or of professional codes of conduct may\nrequire the keeping of records, which requirements shall be communicated to the other Party.\n\n10. This Non-Disclosure Agreement remains valid and binding upon both Parties for an indefinite\nperiod also after termination of the vLEI Issuer Qualification Agreement.\n\nIl. Applicable Law and Jurisdiction\n\n11. This Non-Disclosure Agreement is subject to the law and the jurisdiction agreed in the vLEl Issuer\nQualification Agreement. Both Parties explicitly confirm to having had access to the vLEl Issuer\nQualification Agreement before signing this Non-Disclosure Agreement.\n\nIll. Miscellaneous\n\n12. For the avoidance of doubt, the following provisions of the vLEI Issuer Qualification Agreement\napply to this Non-Disclosure Agreement as well:\n\nXII. Agreement Change Process\nXIV. Confidentiality\nXV. Appeals and Complaints\nXVI. Mediation and Arbitration\nXVIl. Miscellaneous\nkK sk\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 5 of 5\n@ Public Document Version 1.1\n2022-04-03_appendix-1-non-disclosure-agreement_v1.1_Final 2023-04-03\n","contentLength":1549,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:21:43.047Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2023-04-03_appendix-2-vlei-issuer-qualification-program-manual_v1.1_final.pdf","content":"OGLEIF’ protecting digital rust\nverifiable LEI (vLEI)\n\nEcosystem Governance Framework v1.0\nVLEI Issuer Qualification Agreement\nAppendix 2 VLEI Issuer Qualification Program\n\\ERIE]\n\nPublic\nDocument Version 1.1\n2023-04-03\n\nv S e\n| 60 w7/ B s\n- i {1 < .\n\np— %y . - 5 . -\n8 e AR\n\".,..,.' 4 o ‘ 1 - s 0 . © .\n\n4 -\n| .\n","contentLength":312,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:22:20.123Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2023-04-03_appendix-2-vlei-issuer-qualification-program-manual_v1.1_final.pdf","content":"Table of Contents\n1 vLEl Issuer Qualification Program Requirements ........ccccceereencerencreennenn. 4\n1.1 Qualification Program Eligibility .......ccccooevvieriiiiiiiiiiie e 4\n1.2 FUNDAMENTAIS cciiiiiie ittt ae s srae e s ssnaeessnssnnnesnsnens B\nG I = o o | Tor= 1 o [ ] [ O R T PPRRUPPPRRRPY”\n1.4 Organizational Reputation ......cccccceieiiiiiiiiniiiiiece et srie e sseneeessseveee e snns &\n1.5 CoNflicts Of INTEIEST .cciiiiiiie it sabeae e e see D\n1.6 VLEI Issuer ReqQUIrEMENTS ....ccouiiiiiiiiiiiiiiiieieieietitieieiere e re e e e resenereee D\n1.7 Qualification Program Processing Order......occuveeviiviieeeiiiieeeisseie s siiieeesssiieeesssens D\n1.8 Confidentiality .oceeueeeee i e ae e D\n1.9 Continuous Improvement of Qualification .........cccceeeveeiiiiiiiniciiviciec e 6\n1.10 Use of Third-Party Assessment Reports In Qualification ...........cccccevvivviieiiiieeenn. 6\n1.11 Use of Third-Party Service Providers as a Qualified VLEI Issuer..........ccccceevvvvveeenn. 6\n1.12 Letters Of ASSUMANCE....ccuuiii ittt siae e s sr e e s sraeeesnssseaesnsans ©\n2 Roles and Responsibilities...ccccccceereieeeiienierencienceennrennceenceenneeneeeeceesseencees 7\n3 The vLEl Issuer Qualfication Program Process.......ccccceeveuerrenncrennnceenncreanes 7\n0 R O 1Y =T VAT P OPUPPRRRRRSPUPPPRY\n3.2 Qualification Program SUPPOIt ......ccovuiiiiriiiiiiee e cssieee e ee s snaeee e &\n4 Overview of the VLEl Issuer Qualification Program Checklist................... 9\n5 Annual vLEl Issuer Qualification .........ccceeeiriineiirinnniiirnennicnneenienneennnenne. 12\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 2 of 13\nvLEI Issuer Qualification Agreement Appendix 2 vLEI Issuer\nQualification Program Manual\nPublic Document Version 1.1\n@ 2023-04-03_appendix-2-vlei-issuer-qualification-program-manual 2023-04-03\n_v1.1_Final\n","contentLength":1837,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:22:20.123Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2023-04-03_appendix-2-vlei-issuer-qualification-program-manual_v1.1_final.pdf","content":"Section E Pricing Model\nThis section requests information from the Candidate VLEl Issuer regarding the fees that the\nCandidate vLEl Issuer would intend to charge for certain vLEI Issuer services.\nSection F VLEIl Issuer Services\nThis section consists of questions regarding the operation of the services detailed in Appendix 5 to\nthe vLEl Issuer Qualification Agreement, the vLEl Issuer Service Level Agreement (SLA).\nSection G Records Management\nThe purpose of this section is to outline the Candidate vLEI Issuer’s obligations regarding historical\nvLEl information so that the Candidate vLEI Issuer understand the requirements in this area. Records\nretention and management is critical to the effectiveness of vLEI Operations\nSection H Website Requirements\nThis section confirms the requirements for display of the Qualified vLEI Issuer TrustMark on the\nwebsite of the Qualified vLEl Issuer if the Candidate vLEI Issuer successfully completes the\nQuialification Program.\nSection | Software, Section J Networks and Key Event Receipt Infrastructure (KERI)\nThe purpose of these sections is to provide GLEIF with an understanding of certain IT operational\npractices and technical environment that the Candidate vLEI Issuer maintains on its own or\noutsources to third parties.\nTo satisfy the technical requirements for Qualification, a Candidate vLEI Issuer must demonstrate the\nability to receive a Qualified vLEI Issuer vLEI credential and issue the Legal Entity, Official\nOrganization Role and Engagement Context Role VLEI credentials, as well the revocation of these\ncredentials, in dry-run sessions with members of GLEIF’s vLEI technical team. In addition, a\nCandidate vLEl issuer must conduct a test key rotation of the Autonomic Identifier (AID) holding the\nQualified vLEI Issuer vLEI credential.\nPrior to participating in these sessions, the Candidate vLEl Issuer should have integrated the vLEl\nsoftware into their infrastructure, launched two (2) separate witness networks (one for testing\npurposes and one for production deployment) and instantiated two (2) Qualified vLEI Issuer wallets\n(one for testing and one for production). The Candidate vLEI Issuer will use their test witnesses and\nwallets to complete the required tasks listed above.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 11 of 13\nVLEI Issuer Qualification Agreement Appendix 2 VvLEI Issuer\nQualification Program Manual\nPublic Document Version 1.1\nGLEIF 2023-04-03_appendix-2-vlei-issuer-qualification-program-manual 2023-04-03\n_v1.1_Final\n","contentLength":2531,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:22:20.123Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2023-04-03_appendix-2-vlei-issuer-qualification-program-manual_v1.1_final.pdf","content":"This qualification will be scheduled by GLEIF with the Candidate VvLEI Issuer with timing to be agreed\nby GLEIF and the Candidate vLEIl Issuer. GLEIF will confirm successful completion of the technical\nrequirements.\nSection K Information Security\nIf a Candidate vLEI Issuer has current third-party controls assessment report (e.g., SAS70, SSAE16\nSOC2), this report can be submitted in place of responding to the questions in the section.\nSection L Compliance\nThis section contains questions regarding Legal Compliance and General Compliance with the terms\nof the vLEI Issuer Qualification Agreement and more broadly, the vLEI Ecosystem Governance\nFramework requirements.\n5 Annual vLEl Issuer Qualification\nAnnual vLEI Issuer Qualification will be initiated by GLEIF on or after the anniversary date of the vLEI\nIssuer’s date of Qualification.\nUsing the template provided by GLEIF, the Qualified vLEI Issuer verifies the status of each processing\narea as mentioned in the Qualification Program Checklist. For areas where significant changes have\noccurred, the Qualified vLEI Issuer documents the nature and extent of the changes and how it/they\naffected Qualified vLEI Issuer processing. Supporting documentation must be provided as additional\ninformation regarding the change(s).\nGLEIF reviews this information and assesses the overall impact of any changes noted in the internal\ncontrols. GLEIF determines if the changed internal controls still meet the required control standard\nand advises the Qualified VvLEI Issuer as to whether any remediation action is required.\nGLEIF Essential Tasks:\n= Provides qualified vLEI Issuer annual qualification questionnaire and other review\nmaterials;\n= Reviews qualified vLEI Issuer submission within 45 calendar days of receipt of a complete\nset of materials;\n= Confirms adequate levels of compliance with expected controls exist and/or document\nrequired remediation activities;\n= Ensures that any remediation activities are completed in a timely and complete manner\n* Maintains on GLEIF website the most up to date list of all qualified vLEI Issuers.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 12 of 13\nvLEI Issuer Qualification Agreement Appendix 2 vLEI Issuer\nQualification Program Manual\nPublic Document Version 1.1\nGLEIF 2023-04-03_appendix-2-vlei-issuer-qualification-program-manual 2023-04-03\n_v1.1 Final\n","contentLength":2371,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:22:20.123Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2023-04-03_appendix-2-vlei-issuer-qualification-program-manual_v1.1_final.pdf","content":"Candidate vLEl Issuer Essential Tasks:\n= Downloads the designated annual qualification materials from the Communications\nportal;\n= Provides completed annual qualification questionnaire (self-assessment) noting all\nchanges to its internal controls within its vLEI operations;\n= Provides supporting documentation for any process changes noted;\n= Provides all required materials within 45 calendar days of GLEIF request to initiate the\nannual qualification;\n= Reviews GLEIF evaluation results with GLEIF;\n= Completes any required remediation actions based upon a mutually agreed schedule.\nGlobal Legal Entity Identifier Foundation (GLEIF) St. Alban-Vorstadt 5, PO Box\n4002 Basel Switzerland\nqualificationrequest@gleif.org\nwww.gleif.org\nChairman of the Board: Steven Joachim\nChief Executive Officer: Stephan Wolf\n© 2022 All rights reserved\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 13 of 13\nvLEI Issuer Qualification Agreement Appendix 2 vLEI Issuer\nQualification Program Manual\nPublic Document Version 1.1\n@ 2023-04-03_appendix-2-vlei-issuer-qualification-program-manual 2023-04-03\nv1.1 _Final\n","contentLength":1112,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:22:20.123Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2023-04-03_appendix-2-vlei-issuer-qualification-program-manual_v1.1_final.pdf","content":"Appendix 2: vLEI Issuer Qualification Program\nManual\nThis vLEI Issuer Qualification Program Manual is provided to Candidate VLEI Issuers as supplemental\nuser guide in support of the Qualification process.\nAbout this Manual\nThe purpose of this document is to provide an overview of the Qualification Program, which is\nrequired for all Candidate VLEI Issuers seeking to become Qualified vLEI Issuers of the verifiable LEI\n(VLEI) Ecosystem. In order to support the integrity of the vLEI Ecosystem, Qualified VLEI Issuers must\nincorporate the vision and requirements of the verifiable LEI (vLEl) Ecosystem Governance\nFramework (VLEI Ecosystem Governance Framework) within their operations.\nCandidate VLEI Issuer are responsible for reviewing the Qualification Program materials posted by\nGLEIF on its website and determining if they wish to proceed and be evaluated for qualified status.\nQualification Program Tools\nCandidate vLEl Issuers can start the Qualification Program by sending an e-mail to\nqualificationrequest@gleif.org attaching a signed NDA, Appendix 1 to the vLEI Issuer Qualification\nAgreement, which can be obtained at www.gleif.org.\nPrior to requesting to start the Qualification Program, Candidate vLEI Issuers and their relevant\nparents must have a LEI Entity Status of Active, and a LEI Registration Status of Issued, Pending\nTransfer or Pending Archival in the Global LEI System, to be able to provide on Appendix 3, the VLEI\nIssuer Qualification Program Checklist.\nThe vLEI Issuer Qualification Program Checklist, contains questions that must be answered and\ndocuments and other information that must be submitted to GLEIF by the Candidate vLEl Issuer in\norder to be considered for Qualification.\nGLEIF will grant access to authorized representatives and other key contacts of the Candidate vLEI\nIssuers specified in the vLEI Issuer Qualification Program Checklist. Authorized users also are\nprovided access to a communications portal for the uploading of all materials and documentation\nwhich must be submitted to the communications portal, as well as all written communications, to\nmaintain a proper audit trail during Qualification.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 3 of 13\nVLEI Issuer Qualification Agreement Appendix 2 VvLEI Issuer\nQualification Program Manual\nPublic Document Version 1.1\nGLEIF 2023-04-03_appendix-2-vlei-issuer-qualification-program-manual 2023-04-03\n_v1.1_Final\n","contentLength":2433,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:22:20.123Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2023-04-03_appendix-2-vlei-issuer-qualification-program-manual_v1.1_final.pdf","content":"1 vLEl Issuer Qualification Program\nRequirements\n1.1 Qualification Program Eligibility\nAny organization in any geographic location may apply to become a Qualified vLEI Issuer with the\nexception of a sole proprietorship or “natural person”.\nAn organization which does not successfully complete the Qualification Program due to timing\ndeadlines or a decision of GLEIF may re-apply for Qualification at a future date of its choosing.\n1.2 Fundamentals\nEvery Candidate VLEl Issuer is required to complete successfully the Qualification Program in order to\nachieve Qualified vLEI Issuer status. The Qualification Program evaluates a Candidate VLEI Issuer’s\nfinancial, operational, and informational technology capabilities using the self-assessment\nguestionnaire provided by GLEIF which is referred to as the vLEl Issuer Qualification Program\nChecklist. The specific areas of review are documented in this Manual.\nGLEIF believes, as part of its founding principles, that every Candidate vLEl Issuer shall be treated in a\nfully transparent manner with consistent processes and evaluation criteria.\n1.3 Certifications\nOrganizations that hold any of the certificates specified in section B of the vLEI Issuer Qualification\nProgram Checklist may be subject to a simplified Qualification Program, which would allow skipping\ncertain sections of the vLEl Issuer Qualification Program Checklist document, where applicable.\nThe decision to all Candidate vLEI Issuers to skip sections of the VLEI Issuer Qualification Program\nChecklist is at the sole discretion of GLEIF.\n1.4 Organizational Reputation\nGLEIF expects all vLEI Issuers to maintain a law abiding and ethical status in the business community.\nConcerns or comments brought to GLEIF’s attention regarding Qualified vLEI Issuers will be\naddressed as well as will be considered during Annual vLEI Issuer Qualification.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 4 of 13\nVLEI Issuer Qualification Agreement Appendix 2 VvLEI Issuer\nQualification Program Manual\nPublic Document Version 1.1\nGLEIF 2023-04-03_appendix-2-vlei-issuer-qualification-program-manual 2023-04-03\n_v1.1_Final\n","contentLength":2141,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:22:20.123Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2023-04-03_appendix-2-vlei-issuer-qualification-program-manual_v1.1_final.pdf","content":"1.5 Conflicts of Interest\nGLEIF defines a Conflict of Interest (COI) as:\n“A set of circumstances that creates a risk that professional judgement or actions regarding a primary\ninterest will be unduly influences by secondary interest. Primary interest refers to the principal goals\nof the profession or activity, such as the protection of clients or duties of public office. Secondary\ninterest includes not only financial gain but also such motives as the desire for professional\nadvancement and the wish to do favours for family and friends.”\nGiven the value and sensitivity of the services that Qualified vLEIl Issuers provide, GLEIF will not\naccept any degree of COIl given the irredeemable reputational harm it could cause. The Candidate\nVLEI Issuer is requested to report any potential COI situation to its GLEIF contact for the VvLEI Issuer\nQualification Program of explain the circumstances, actions, and remediation implemented to\naddress COI.\n1.6 VLEl Issuer Requirements\nThe vLEl Issuer requirements which Qualified vLEI Issuers must meet are defined in the vLEI\nEcosystem Governance Framework and in the vLEI Issuer Qualification Agreement and its\nAppendices. Key topics GLEIF considers critical to be overall integrity of Qualified vLEI Issuer\noperations have been included. These are reflected in the questions in the vLEI Issuer Qualification\nProgram Checklist.\nWhen developing the vLEI Issuer Qualification Program Checklist, GLEIF considered and incorporated\ngenerally accepted control standards referring to generally accepted from models such as ISO, COSO,\nand COBIT.\n1.7 Qualification Program Processing Order\nQualification Program processing order is based on a FIFO (First in First Out) principle depending on\nthe timeliness and completeness of the Candidate VLEI Issuer submissions. Applications which are\nincomplete and/or require additional documentation may be impacted with significantly delayed\nprocessing times which can affect the precedence of the application.\n1.8 Confidentiality\nConfidentiality is set out in the non-disclosure agreement.\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 5 of 13\n\nvLEI Issuer Qualification Agreement Appendix 2 vLEI Issuer\n\nQualification Program Manual\n\nPublic Document Version 1.1\n\n@ 2023-04-03_appendix-2-vlei-issuer-qualification-program-manual 2023-04-03\nv1.1 _Final\n","contentLength":2350,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:22:20.123Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2023-04-03_appendix-2-vlei-issuer-qualification-program-manual_v1.1_final.pdf","content":"1.9 Continuous Improvement of Qualification\nGLEIF will evaluate Qualification Program criteria and process for best practices at least annually. Any\nmaterial changes to this Manual or the vLEI Issuer Qualification Checklist will be managed per the\nterms of the vLEl Issuer Qualification Agreement, Section VIII, Agreement Change Process.\n1.10 Use of Third-Party Assessment Reports in Qualification\nThe Candidate vLEI Issuer may integrate the control assessment and reporting requirements for\nbecoming a Qualified vLEI Issuer with independent auditing activity that is carried out with respect to\nits organization(s). If a Candidate vLEI Issuer has a current third-party opinion/report from\nindependent, qualified internal auditors, external auditors or, regulatory auditors or independent\nconsultants with respect to the subjects included in the Qualification Program Checklist, these\nreports may be submitted as evidence as the adequacy and effectiveness of internal controls. The\nCandidate vLEI Issuer must cross-reference such opinions/reports to the appropriate Qualification\nProgram Checklist item and provide direct responses to questions about areas not included in these\nopinions/reports.\n1.11 Use of Third-Party Service Providers as a Qualified vLEl Issuer\nThe Qualified vLEI Issuer may utilize third-party service providers for certain functions such as\nrunning portions of or its IT, operational infrastructure, and administrative functions (e.g., finance,\nHR) unrelated to VLEI services. The terms and conditions for this are detailed in the vLEI Issuer\nQualification Agreement Section IIl. B, Use of Third-Party Services.\n1.12 Letters of Assurance\nIt is critical that a Qualified vLEI Issuer maintain its financial viability both in practical terms as well as\nwith respect to the reputation of the Global Legal Entity Identifier System (GLEIS) as a whole. When\nperforming its financial assessment, GLEIF will evaluate both independent information, such as audit\nreports, as well as unverified information from these reports. This information may be considered as\nevidence as to the adequacy and effectiveness of internal controls of the Candidate vLEI Issuer, such\nas operating budgets.\nGLEIF, at its sole discretion, may require a Candidate vLEl Issuer to provide a letter of assurance,\nguarantee or confirmation of financial sources and/or support from the Candidate vLEI Issuer’s\nparent organization(s) indicating its ultimate responsibility for the Candidate vLEl Issuer’s financial\nsoundness. If such a document is not provided upon request, GLEIF, at its sole discretion may\nterminate the qualification program of the Candidate VLEl Issuer.\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 6 of 13\n\nvLEI Issuer Qualification Agreement Appendix 2 vLEI Issuer\n\nQualification Program Manual\n\nPublic Document Version 1.1\n\n@ 2023-04-03_appendix-2-vlei-issuer-qualification-program-manual 2023-04-03\nv1.1_Final\n","contentLength":2939,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:22:20.123Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2023-04-03_appendix-2-vlei-issuer-qualification-program-manual_v1.1_final.pdf","content":"2 Roles and Responsibilities\n1. Candidate VvLEIl Issuer\n® |ssues a Qualification request\n= Signs a Non-Disclosure Agreement (NDA)\n= Prepares and submits a completed vLEI Issuer Qualification Program Checklist along with\nrequired information and documentation\n2. GLEIF\n= Processes all Qualification requests\n= Reviews and evaluates vLEI Qualification Program Checklist, required information\ndocumentation\n* Communicates Qualification decisions\n= Publishes Qualified vLEI Issuers on GLEIF website\n* Monitors Qualified vLEI Issuers’ activities and performance\n3 The vLEl Issuer Qualfication Program Process\n3.1 Overview\nThe Qualification Program is in place to ensure that all Candidate vLEIl Issuers meet the minimum\nfinancial, operational, and technical requirements of the GLEIF and that a Qualified vLEI Issuer’s\ncontrol environment has reasonable risk mitigation to protect the integrity of the vLEI operations.\nThroughout the Qualification Program, the Candidate vLEl Issuer is obliged to inform GLEIF without\nundue delay about any events or developments which affect the accuracy of information provided to\nGLEIF such as changes in legal status e.g., form of incorporation, change of signatory power of its\nofficers and the like. Such changes could impact the Qualification Program and/or any agreed time\nschedule.\nCandidate vLEl Issuers submit all Qualification Program materials via a communications portal\nprovided by GLEIF. All documents received are date stamped and receipts sent to the representative\nof the submitting Candidate vLEI Issuer. Once information and documentation are designated as\n‘FINAL’, the communications portal is restricted to read-only for users and any proposed changes will\nneed to be discussed with and approved by GLEIF before taking any action.\nThe Qualification Program is comprised of the steps.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 7 of 13\nVLEI Issuer Qualification Agreement Appendix 2 VvLEI Issuer\nQualification Program Manual\nPublic Document Version 1.1\nGLEIF 2023-04-03_appendix-2-vlei-issuer-qualification-program-manual 2023-04-03\n_v1.1 Final\n","contentLength":2116,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:22:20.123Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2023-04-03_appendix-2-vlei-issuer-qualification-program-manual_v1.1_final.pdf","content":"The Candidate vLEl Issuer:\n* Issues a Qualification request;\n= Signs a Non-Disclosure Agreement (NDA);\n= Prepares and submits a completed vLEI Issuer Qualification Program Checklist\nalong with required information and documentation within sixty calendar days of\nsubmitting the NDA,;\n= Completes a successful test run of vLEI Issuer operations and use of GLEIF-supplied vLElI\nsoftware.\nGLEIF:\n= Receives a valid Qualification request;\n= Assigns dedicated GLEIF Qualification Program staff to the Candidate VLEI Issuer\nQualification request;\n= Reviews the Candidate’s vLEI Issuer’s submission and has ten calendar days to provide\nfeedback on the completeness of the documentation;\n® Once the submission is considered complete, GLEIF has sixty calendar days to assess the\nsubmission and to provide the Candidate vLEI Issuer with the status of its application;\n= Communicates Qualification decisions;\n= Executes the vLEIl Issuer Qualification Agreement with all Qualified vLEl Issuers (Note: the\nvLEI Issuer Qualification Agreement will be the same for all Qualified vLEI Issuers);\n= Provides Qualified vLEI Issuers with the GLEIF-supplied vLEI software, the Qualified vLEI\nTrustMark, access to the communications portal and other requirements specified in the\nVLEI Issuer Qualification Agreement necessary to begin Qualified vLEI Issuer operations.\n3.2 Qualification Program Support\nIn order to provide for fairness to all Candidate vLEl Issuers, GLEIF does not provide consultative\nadvice to Candidate VLEI Issuers regarding their response to the vLEl Issuer Qualification Program\nChecklist, information and/or documents. GLEIF expects that the definitions and information on its\nwebsite serve this purpose. However, a Candidate VvLEl Issuer may, upon request, schedule up to two\n(2) review sessions with GLEIF during the Qualification Program process for the purpose of clarifying\nprogram issues and requirements. Each call will be planned for a maximum of one hour's duration.\nGLEIF reserves the right to request and schedule review meetings for clarification and will follow the\nsame procedure of providing the Candidate VLEI Issuer with a list of questions in advance depending\non the subject and circumstances and setting a mutually agreeable schedule.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 8 of 13\nvLEI Issuer Qualification Agreement Appendix 2 vLEI Issuer\nQualification Program Manual\nPublic Document Version 1.1\n@ 2023-04-03_appendix-2-vlei-issuer-qualification-program-manual 2023-04-03\nv1.1 _Final\n","contentLength":2532,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:22:20.123Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2023-04-03_appendix-2-vlei-issuer-qualification-program-manual_v1.1_final.pdf","content":"4 Overview of the vLEI Issuer Qualification\nProgram Checklist\nThe vLEl Issuer Qualification Program Checklist is comprised of the following sections:\nSection A Contact Details\nSection B Entity Structure\nSection C Organization Structure\nSection D Financial Data, Audits & General Governance\nSection E Pricing Model\nSection F VLEl Issuer Services\nSection G Records Management\nSection H Website Requirements\nSection| Software\nSectionJ Networks and Key Event Receipt Infrastructure (KERI)\nSection K Information Security\nSection L Compliance\nFor initial Qualification and each Annual vLEI Issuer Qualification, the documentation sent by the\nCandidate or Qualified vLEI Issuer will be added as an annex to each Checklist.\nSection A Contact Details\nThis section requires specific information regarding the Candidate vLEI Issuer’s authorized and key\ncontacts for this process. This includes the preparer and approver of the documents and key\nreference resources (Operations and Finance) who may need to be contacted for additional\ninformation and clarification. It most importantly requests information about the Designated\nAuthorized Representative of the Candidate vLEI Issuer who will be the sponsor of the Qualification\nRequest. This person needs to be authorized by the Candidate vLEl Issuer’s organization to represent\nthe organization as well as serve as the key senior management sponsor throughout the Qualification\nProgram process.\nSection B Entity Structure\nThis section requires specific information regarding the entity structure of the Candidate vLEl Issuer.\nThe Candidate VLEI Issuer may be a stand-alone organization or part of a larger organization. GLEIF\nrequire basic organizational structure information about parent-child relationships, in general, if\napplicable background information however, the main focus will be on the Candidate vLEl Issuer\norganization.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 9 of 13\nVLEI Issuer Qualification Agreement Appendix 2 VvLEI Issuer\nQualification Program Manual\nPublic Document Version 1.1\nGLEIF 2023-04-03_appendix-2-vlei-issuer-qualification-program-manual 2023-04-03\n_v1.1_Final\n","contentLength":2154,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:22:20.123Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2023-04-03_appendix-2-vlei-issuer-qualification-program-manual_v1.1_final.pdf","content":"For purposes of clarity,\n“Government” refers to a Candidate vLEl Issuer which is, or is part of, an administrative agency,\nnation state or state-owned company.\n“Private” is a privately controlled legal entity which is not listed on stock exchange.\n“Public-listed” is an entity which is listed on a stock exchange and has shareholders.\n“Public-Non-Listed” is an entity which is funded from public sources but does not have stockholders.\n“Account Framework” and “Internal Controls Framework” refer to commonly recognized business\nmodels in use globally. This is helpful but not essential information.\nThe Candidate VLEI Issuer is asked to identify any beneficiary ownership associated with their\norganization.\nThis section asks the Candidate vLEI Issuer to describe its current audit activities from a variety of\nsources. This may aid the Candidate VLEI Issuer in identifying any current report from a third-party\nthat could be used to confirm the adequacy of internal controls independent of the organization.\nThese reports may be accepted by GLEIF in lieu of other documentation if current and relating to vLEI\nIssuer services.\nSection C Organization Structure\nThe purpose of this section is to inform the Candidate VLEl Issuer as to the types of\ninformation/reports which will either be required or may be helpful during the Qualification Process.\nA key point to note is that distinctions are made as to what reports would generally be expected to\nbe in place for certain types of organization. See the “Applicability” columns.\nSection D Financial Data, Audits & General Governance\nThe purpose of this section is to provide GLEIF with an overview of certain financial and operational\naspects of the Candidate VLEI Issuer.\nA key point to note is that the Candidate vLEI Issuer must explain clearly how its intended vLEI Issuer\noperations will be structured within an organization. For example, it could be a stand-alone entity\nwith no other affiliations. It could also be a department/function within another organization.\nThis section applies to the Candidate vLEI Issuer in the context of its parent/owner/controlling entity,\nif applicable. All relevant entities need to be represented in the Candidate vLEI Issuer’s answers.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 10 of 13\nvLEI Issuer Qualification Agreement Appendix 2 vLEI Issuer\nQualification Program Manual\nPublic Document Version 1.1\nGLEIF 2023-04-03_appendix-2-vlei-issuer-qualification-program-manual 2023-04-03\n_v1.1 Final\n","contentLength":2508,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:22:20.123Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2023-04-03_appendix-3-vlei-issuer-qualification-program-checklist_v1.2_final.pdf","content":"OGLEIF’ Protecting digita trst.\nverifiable LEI (vLEI)\nEcosystem Governance Framework v1.2\nVLEI Issuer Qualification Agreement\nAppendix 3 VLEI Issuer Qualification Program\nChecklist\nPublic\nDocur;(()ezn;_\\éi(s)l;n 1.2\n-~ | e et\n.60 \" . ] .\n-~ -«r'\\\\”. = (\":. e :, . \" .\n2 f.. : .:?Azo‘/f’ . N \" e S ik S\noo L ot el R\n-\nd .\n-\n","contentLength":323,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:22:54.912Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2023-04-03_appendix-3-vlei-issuer-qualification-program-checklist_v1.2_final.pdf","content":"Contents 2\nA ContactDetdils........c.coiiiiiiiiiiiiiiiiiiiiieiiettereeneeacnnnnenees B\nB EntityStructure .........ccciiiiiiiiiiiiiiiiieeenneneennennennnannnanas i\nC OrganizationStructure...........coiiiiiiiiiiiiiiiiiiiiiiiieineneneene 7\nD Financial Data, Audits & General Governance ............ccovveeieeee.... 8\nE PricingModel........cciiuiuiiiiiiiiiiiiiiiiiiiiiiiinennnnnensesnenss.. 10\nF VLEIISSUEIr SErviCesSs ....uuiuieiiiiiienneenenneneencencncnnnnnsnnssnanasssdl\nG GRecordsManagement.........cciiiiiiiiiiiiiiiiiiiiiiieineeneenn.. 12\nH Website Requirements ..........cciiiiiiiiiiiiieiinneneennenneennannnas. 13\nI S o o | = P [\nJ Networks & Key Event Receipt Infrastructure (KERI)..................... 16\nK InformationSecurity .......coiiiiiiiiiiiiiiiiiiiiinreeennenennnnnnennas 17\nL ComplianCe.....cciiiiiiiiiiiiiiiitineeeeeenneeeennsaassnnacassnnaannnes 18\nGLEIF 2022/05\n","contentLength":879,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:22:54.912Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2023-04-03_appendix-3-vlei-issuer-qualification-program-checklist_v1.2_final.pdf","content":"General Information for vLEI Issuer Qualification Program Submission 1\n> Required Documentation to be Submitted\nF vLEI Issuer Services\nMetrics\nYes No Not Applicable\n\n1. Will /do you have a process to monitor compliance with the Service\n\nLevels as defined in the VLEI Service Level Agreement (Appendix 5)?\nRevocation Legal Entity VLEIs\n\nYes No Not Applicable\n\n1. Will/do you have followed the policies for revocation of vLEI Credentials\n\nspecified in VLEI Ecosystem Governance Framework?\n2. Will/ldo you have a process to check the status of the LEls for which vLEls\n\nhave beenissued for those LEIs with renewal dates of 30 days or less?\n3. How will/do you inform the Legal Entity of potential revocation of their\n\nVLEls if their LEI lapses?\n4. Will/ldo you have a process to trigger the revocation of\n\na Legal Entity vLEI?\n5. Will/do you check your public Witnesses for vLEI\n\ncredential issuance and revocation registry for erroneous or malicious\n\nissuances and revocations (primary issuances) in order to inform your\n\nmanagement process that a key rotation/recovery may be required?\n6. Will you notify GLEIF to revoke your Qualified vLEI Issuer vLEI Credential\n\nif you choose to no longer operate as a Qualified vLEl Issuer?\n\nGLEIF 2022|05\n","contentLength":1241,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:22:54.912Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2023-04-03_appendix-3-vlei-issuer-qualification-program-checklist_v1.2_final.pdf","content":"General Information for vLEI Issuer Qualification Program Submission 12\n> Required Documentation to be Submitted\nG Records Management\nRecords Management\nAdditional Documentation Requested\nPlease provide a brief narrative and copies of all relevant policies.\n\n1. Is a particular function responsible for all aspects of records\n\nretention as per your established internal policies? What is your testing\n\nprocess and periodicity?\n2. Isaperiodic training provided to all relevant personnel (including\n\nemployees, contractors, and temporary staff) to make them aware of\n\nyour Records Management Procedures?\n3. Will/do you ensure indexing, scanning, retrieval, storage, and\n\ndestruction processes are documented, communicated, and tested at\n\nleast annually?\n4. Will/ldo you ensure access to relevant records is restricted to only those\n\nemployees who are appropriately authorized and need access to\n\nperform their duties?\n5. Will/do you ensure control procedures relating to the physical and\n\nenvironmental protection of relevant records, including archived data is\n\nin place and functioning properly?\n6. Will/do you ensure relevant records are only destroyed in compliance\n\nwith your procedures and any local or legal requirements?\n\nGLEIF 2022|05\n","contentLength":1242,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:22:54.912Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2023-04-03_appendix-3-vlei-issuer-qualification-program-checklist_v1.2_final.pdf","content":"General Information for vLEI Issuer Qualification Program Submission 13\n> Required Documentation to be Submitted\nH Website Requirements\nWebsite Requirements\nYes No Not Applicable\n\n1. Will/do you display your vLEl Issuer Qualification TrustMark on your\n\nQualified vLEl Issuer homepage?\n2. Willldoes your VLEI Issuer website display applications, contracts and\n\nrequired documents for Legal Entities to apply for vLEI Legal Entity\n\nCredentials and Role Credentials?\n\nGLEIF 2022|05\n","contentLength":479,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:22:54.912Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2023-04-03_appendix-3-vlei-issuer-qualification-program-checklist_v1.2_final.pdf","content":"General Information for vLEI Issuer Qualification Program Submission 14\n> Required Documentation to be Submitted\nI Software - Part A\nSoftware\nYes No Not Applicable\n1. Will/do you have a standard IT service management process in place? (\\ (_\\ (\\\n2. Will/do you have a document that describes the software development tools\nenvironment in place for vLEI operations? C C C\n3. Will/do you have a formal process for installing, testing, and approving new software? (\\ (\\ (~\n4. Will/do you have any outsourced software arrangements relating to vLEI operations?\n5. Will/do you have a process in place for identifying, tracking, and correcting software\nerrors/bugs?\nGLEIF 2022|05\n","contentLength":672,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:22:54.912Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2023-04-03_appendix-3-vlei-issuer-qualification-program-checklist_v1.2_final.pdf","content":"General Information for vLEI Issuer Qualification Program Submission 15\n> Required Documentation to be Submitted\nI Software - Part B\nSoftware\nYes No Not Applicable\n6. Will/do your developers follow the security recommendations in the vLEI Ecosystem\nGovernance Framework when designing software or services for the use with vLEI\nCredentials and the vLEI Ecosystem?\n7. Will/do you have a process in place to manage the security of your cryptographic keys?\n8. WIll specific holders of cryptographic keys kept confidential and determined by your\nQualified vLEI Issuer internal policy ?\n9. WIll signing keys rotated whenever there is a likelihood of key compromise?\n10. WIll the time and place of the key rotation kept confidential\namong the key holders until after the rotation has been completed?\n11. In the case of the key compromise, will key\ncompromise recovery operations be reported to GLEIF within 24 hours of gaining\nknowledge of the key compromise?\n12. WIll all key compromise cases investigated as expeditiously as possible at your\nown expense to determine the source of the key compromise and a full report of the\ninvestigation will be made to GLEIF?\n13. Will/do you use best practices for code delivery and observe library usage for signature\nverifiable infrastructure?\n14. Foryour QVI Delegated AID, will you use at least 2 or 3 thresholded multi-signature\nscheme for added security, and for each key-pair in a thresholded multi-signature\nscheme, will you use a non-co-located key store for adding security?\n15. For your QVI witness services will you provide a Witness Pool or a Ledger Registrar?\n16. If your answer to question 15 is a Witness Pool, Will/do your KERI Witness Pool have a\nminiumum pool of five (5) Witnesses?\n17. If your answer to question 15 is a Witness Pool, Will/do you publish your Witnesses to at\nleast one ecosystem discovery mechanism: KERI Distributed Hash Table (DHT), DID\nmethod resolvers or Ledgers?\n18. If your answer to question 15 is a Witness Pool, for your Witness Pool, will the\nencryption key store reside on a different device or host from that of the Witness\nservice?\n19. If your answer to question 15 is a Ledger Registrar, for your Ledger Registrar, if the\nRegistrar Signing Key Pair Key store resides on the Registrar Service host, will dedicate\nuser-only permissions be used on the key store directory and its contents? L4\n20. If your answer to question 15 is Ledger Registrar, for your Ledger Registrar, will the\nencryption key store reside on a different device or host from that of the Registrar\nservice?\n21. Also, when used, will the encryption key store reside on a different device or host from\nthat of the Witness service? (\\ (« («\n22. Will/do you successfully install, test and implement the vLEI Issuer software within the\nstated time frames and will you use the vLEI software package for hosting Witnesses, (‘ (“ (‘\nDiscovery and Oracles for Key Management?\nGLEIF 2022|05\n","contentLength":2933,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:22:54.912Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2023-04-03_appendix-3-vlei-issuer-qualification-program-checklist_v1.2_final.pdf","content":"General Information for vLEI Issuer Qualification Program Submission 16\n\n> Required Documentation to be Submitted\n\nJ Networks & Key Event Receipt Infrastructure (KERI)\n\nNetworks & Key Event Receipt Infrastructure (KERI)\n\nYes No Not Additional\nApplicable Documentation Requested\n1. Please describe the current service/hosting environment. Is it hosted, Relevant process documents\nin-house, via a third-party, etc.? Describe the use of any cloud-based and technical diagrams\nresources such as Amazon Web Services or Microsoft Azure.\n\n2. Will/do you perform any monitoring over the vLEI Issuer-related Relevant process documents\nIT infrastructure?\n\n3. Are there any redundancies built into the hosting platform and hardware? Copies of the related\n\nagreements\n\n4. Has there been any unscheduled downtime of your own network or Relevant process documents\nsystem in the past twelve (12) months?\n\n5. Will you have a current disaster recovery and/or business continuity plan in place? Relevant process documents\n\nHow often is it tested? Has the continuity plan needed to be invoked during the\npast 3 operating years?\n\n6. Will/do you have structured backup policies and practices? Relevant process documents\n\nand technical diagrams\n\n7. Will/are third party services (e.g., augmented staff, cloud services, Relevant process documents\ndata centers) utilized in order to provide Qualified vLEI Issuer services? and technical diagrams\n\n8. If your answer to question 7 is Yes, will you have a formal vetting process for Relevant process documents\nevaluating the reliability of third-party service providers?\n\n9. If your answer to question 7 is Yes, will this process evaluate: Relevant process documents\nFinancial stability, Market reputation, Ability to meet vLEI Ecosystem and technical diagrams\nGovernance Framework requirements, Evaluating the potential risks\nof utilizing the services provided?\n\nGLEIF 2022|05\n","contentLength":1901,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:22:54.912Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2023-04-03_appendix-3-vlei-issuer-qualification-program-checklist_v1.2_final.pdf","content":"General Information for vLEI Issuer Qualification Program Submission 17\n\n> Required Documentation to be Submitted\n\nK Information Security\n\nInformation Security\n\n1. Have any IT operational or security audits (i.e., SSAE 16, SOC2, SAS70,\n1SO27001) been performed, and certification achieved for Qualified\nVLEI services, in the past?\n\n2. Do you operate an information security policy or policies that meet the\nVLEI Ecosystem Stakeholder Security Policies requirements and which is/\nare mandatory for all employees of the VLEI Ecosystem Stakeholder\ninvolved with vLEI transactions or vLEI data?\n\n3. How do you ensure executive oversight and accountability for such\npolicies, including formal governance and revision management?\n\n4. How do you ensure vLEI Issuer systems personnel maintain an\nappropriate level of security awareness?\n\n5. How do you protect physical access to critical company assets such\n\nas servers and data?\n\n6. What internal security processes will/do you have in place for\nVLEI Issuer Operations personnel — criminal background checks,\nproof of identity validation, others?\n\n7. How do you prevent unauthorized access to, or modification of, critical\n\ndata assets?\n\n8. How do you ensure unauthorized access to critical data assets can be\n\ndetected and investigated?\n\n9. How do you prevent unauthorized network intrusion?\n\n10. Have you performed or engaged a third party to test system\nvulnerability, intrusion prevention and/or detection or perform\npenetration testing?\n\n11. How do you ensure that, once vulnerabilities are discovered,\nthese are remediated within appropriate time frames?\n\n12. Will you have procedures in place to identify, document in an\n\nIncident Report and remediate any security breaches?\nGLEIF 2022|05\n","contentLength":1739,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:22:54.912Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2023-04-03_appendix-3-vlei-issuer-qualification-program-checklist_v1.2_final.pdf","content":"General Information for vLEI Issuer Qualification Program Submission 18\n> Required Documentation to be Submitted\nL Compliance\nLegal Compliance\nYes No Not Applicable\n1. Will you execute a vLEI Issuer Qualification Agreement\nwith GLEIF?\n2. Will you execute a formal contract either physically or\nelectronically with a Legal Entity for prior to the Initial issuance of a\nLegal Entity vLEI?\n3. Will/does your Legal Entity contract template include all required\ncontract terms specified in Appendix 7 of the vLEI Issuer\nQualification Agreement?\nGeneral Compliance\nYes No Not Applicable\n1. Will you keep your vLEI Issuer Qualification up to date?\n2. Will you confirm annually that you maintain a law abiding and\nethical status in the business community as evidenced in the Annual vLEI\nIssuer Qualification?\n3. Will/have you been accountable to other vLEI Ecosystem Stakeholders\nfor conformance to the purpose, principles, and policies of the vLEI\nEcosystem Governance Framework? Will/have you been responsible for and\nbeen able to demonstrate compliance with any other requirements of\napplicable law?\n4. Wil/have you informed GLEIF of updates to the vLEI Issuer\nContact Details List (Appendix 4)?\n5. Will/have you informed GLEIF prior to or as soon as reasonably possible\nof any change of control at the Qualified vLEI Issuer, be it a change in\nownership, voting power, or factual power of third party over the Qualified\nVLEI Issuer, is only one example of a change?\n6. Will/have you used English as the primary language in your formal\ncommunications with GLEIF as a Qualified vLEI Issuer which includes all\nwritten, electronic, messaging, phone, conferences, communications?\n7. Will/have you complied with the Intellectual Property and Confidentiality requirements\nin the Qualification Agreement?\n8. Will/have you ensured that third parties comply with the vLEI\nEcosystem Governance Framework when providing vLEI services to you\nas a Qualified vLEI Issuer?\n9 . For third-party services, will’lhave you ensured that you remain fully\nand unrestrictedly responsible and liable to complying with, and acting in the\nspirit of, all the requirements for Qualification?\n10. Do you ensure that the provisions of the vLEI Ecosystem Stakeholder Data\nProtection Policies are implemented and enforced? (Please explain)\nGLEIF 2022|05\n","contentLength":2315,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:22:54.912Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2023-04-03_appendix-3-vlei-issuer-qualification-program-checklist_v1.2_final.pdf","content":"G LE I F Enabling global identity\nProtecting digital trust\nGlobal Legal Entity Identifier Foundation (GLEIF)\nSt. Alban-Vorstadt 5, PO Box\n4002 Basel\nSwitzerland\naccreditation@gleif.org\ngleif.org\nChairman of the Board: Steven Joachim\nChief Executive Officer: Stephan Wolf\n© 2022 All rights reserved\nGLEIF 202205\n","contentLength":311,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:22:54.912Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2023-04-03_appendix-3-vlei-issuer-qualification-program-checklist_v1.2_final.pdf","content":"General Information for vLEI Issuer Qualification Program Submission 3\n> Required Documentation to be Submitted\nA Contact Details\nLegal Name of vLEI Issuer | Note:\nThis name must match your LEI reference Data VAT No. if applicable\nURL of VLEI Issuer Organization Other Tax ID Number, If applicable\nLEI of VLEI Issuer Organization Submission Date (YYYY-MM-DD)\nDirect Parent/Grandparent/Owner/Governing Organization if applicable First Submission Revised Submission\nLEI of Direct Parent/Grandparent/Governing Organization if applicable\nInternal Project Manager Designated Authorized Representative\nName Name\nTitle Title\nEmail Email\nPhone Phone\nKey Contact Operations Key Contact Finance\nName Name\nTitle Title\nEmail Email\nPhone Phone\nThe Checklist can be signed with the digital certificate of the Designated Authorized Representative\nor a Notarized Copy of the signature of the Designated Authorized Representative.\nIn submitting this vLEI Issuer application, | confirm that, to the best of my knowledge, my organization is in compliance\nwith or is able to become compliant with the requirements reflected in the VLEI Issuer Credential Qualification Agreement,\nits appendices and the VLEI Ecosystem Governance Framework, as of the date of this document unless otherwise noted.\nDesignated Authorized Representative Signature Date (YYYY-MM-DD)\nE-Signature\nName\nTitle\nEmail\nPhone\nThis document summarizes the information required to apply to the vLEI Qualification Program which will\nbe submitted through an online tool provided by GLEIF at the launch of the VLEI Issuer Qualification Program.\nGLEIF 2022|05\n","contentLength":1603,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:22:54.912Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2023-04-03_appendix-3-vlei-issuer-qualification-program-checklist_v1.2_final.pdf","content":"General Information for vLEI Issuer Qualification Program Submission 4\n> Required Documentation to be Submitted\nOrganizations that hold any of the following certificates - eIDAS ETSI EN 319 401, ETSI X-Ref, WEB-TRUST, ISO 20001 OR ISO 27001\n- may be subject to a simplified Qualification Program, which would allow skipping certain sections of the vLEI Issuer Qualifications\nProgram Checklist document, where applicable.\nB Entity Structure\nOrganization Structure\nFor Parent and vLEI Issuer Applicant\nGovernment\nPrivate - For Profit\nPrivate - NonProfit\nPublic-Listed\nPublic-Non-Listed\nNot Applicable - there is no parent/owner\nOther\nAccounting Framework Check as many as applicable Internal Controls Framework Check as many as applicable\nUS GAAP COSsO\nIFRS COBIT\nOther - Please specify* ISO*\nUnknown/Not Applicable Other - Please specify**\n*Comments (if any) Unknown/Not Applicable\n* Please note the applicable standard and provide the certificate if you have been certified\n**Comments (if any)\nFISCAL YEAR (Please provide your business calendar)\nDate (YYYY-MM) Date (YYYY-MM)\nGLEIF 2021|01\n","contentLength":1090,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:22:54.912Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2023-04-03_appendix-3-vlei-issuer-qualification-program-checklist_v1.2_final.pdf","content":"General Information for vLEI Issuer Qualification Program Submission 5\n> Required Documentation to be Submitted\nB Entity Structure\nExternal Audit Firm (if applicable)\nFirst Name Comments (if any)\nYes No Not Applicable\nAre annual financial statements issued?\nParent Level\nVLEl Issuer Level\nGovernmental/Regulatory Auditors (if applicable)\nOrganization Comments (if any)\nYes No Not Applicable\nAre annual financial statements issued?\nParent Level\nVLEl Issuer Level\nAre periodic management letters/reports issued which could relate to\nVLEI Issuer services?\nParent Level\nVLEl Issuer Level\nif yes, are these reports public record?\nInternal Audit Group (if applicable)\nDepartment Comments (if any)\nYes No Not Applicable\nAre financial/operational/IT scope audits performed?\nParent Level\nVLEl Issuer Level\nAre periodic management letters/reports issued which could relate to\nVLEI Issuer services?\nParent Level\nVLEl Issuer Level\nif yes, are these reports public record?\nGLEIF 2022|05\n","contentLength":974,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:22:54.913Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2023-04-03_appendix-3-vlei-issuer-qualification-program-checklist_v1.2_final.pdf","content":"General Information for vLEI Issuer Qualification Program Submission 6\n> Required Documentation to be Submitted\nB Entity Structure\nExternal Consultants (if applicable)\nYes No Not Applicable\nHave you engaged a third party to evaluate your business and/or IT Parent VLEI Issuer Level Both\noperations/controls?\nAre any of these reports SSAE16 SOC Type 1 or equivalent? Parent VLEI Issuer Level Both\nAre any of these reports SSAE16 SOC Type 2 or equivalent? Parent VLEI Issuer Level Both\nAre any of these reports ISAE3402 or equivalent? Parent VLEI Issuer Level Both\nAre any of these reports public record? Parent VLEI Issuer Level Both\nPlease specify the provider of service(s):\nComments (if any)\nPlease indicate to which area business, IT operations, IT controls on any\ncopies of reports submitted.\nGLEIF 2022|05\n","contentLength":811,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:22:54.913Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2023-04-03_appendix-3-vlei-issuer-qualification-program-checklist_v1.2_final.pdf","content":"General Information for vLEI Issuer Qualification Program Submission 7\n> Required Documentation to be Submitted\nC Organization Structure\nPrivate Private Public- Public\nOrganization Structure Government For Profit Non Profit Listed Non-Listed\nType of Document Applicability\n1. Prior Year Financial Statements (Parent/Owner) N Y Y Y Y\n2. Auditor/Regulator Letter(s)/Rep?n(s) v N N v v\n(Parent/Owner and vLEI Operations)\n3. Most Recent Annual Report — vLEI Issuer N Y Y Y Y\n4. Current Organization Chart for all vLEI Operations and v v v v v\ncomplete list of all relevant third party service providers.\nComments\nPlease note:\nAll documents should be provided as part of the vLEI Issuer\nQualification Program Submission.\nGLEIF 2022|05\n","contentLength":730,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:22:54.913Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2023-04-03_appendix-3-vlei-issuer-qualification-program-checklist_v1.2_final.pdf","content":"General Information for vLEI Issuer Qualification Program Submission 8\n> Required Documentation to be Submitted\nD Financial Data, Audits & General Governance\nFinancial Data, Audits & General Governance\nType of Document Xref to Docs Provided Yes No N/A Additional Documentation Requested\nPlease cite document Please check one\nand page number\n\nGeneral Questions - Going Concern - VLEI Issuer\n\n1. Has an independent audit of your financial Audited financial statements (income\nstatements been performed for your last statement, balance sheet, cash flows\ncompleted fiscal year? statement) for prior year.\n\nIf your organization does not have audited\nstatements, please provide your prior and\ncurrent financials as maintained. Please\nexplain how these statements are validated and\nreported.\n\n2. Has an audit firm/government regulatory agency Final Management Letters with management\nissued any management letters relating to vLEI responses as applicable.\n\nIssuer Operations over the past three years/ - This\nwould include commentary relating to internal\ncontrols, accounting controls and methods of\nprocedures.\n\n3. Do you have an internal audit function?\n\n4. Have you been subject to any regulatory Relevant comment letters, audit reports\naudits/reviews in your current year's (qualified and unqualified opinions) and man-\noperations? agement responses as applicable\n\n5. Do you have a formal vLEI Issuer Operations Please provide budgets and explain financial\nBudget for this year and next year's assumptions, volume estimations, operating\noperations? budget, expenses etc. — soft copies should be\n\nsubmitted wherever possible.\n\n6. Are you currently involved with any litigation\nmatters which could affect vLEI Issuer\nservices?\n\n7. Are you subject to regulatory compliance\nrequirements which could affect vLEI Issuer\noperations?\n\n8. Do you clearly understand the requirements\nof the Annual vLEI Issuer Qualification?\n\nGLEIF 2022|05\n","contentLength":1926,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:22:54.913Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2023-04-03_appendix-3-vlei-issuer-qualification-program-checklist_v1.2_final.pdf","content":"General Information for vLEI Issuer Qualification Program Submission 9\n> Required Documentation to be Submitted\nE Pricing Model\nPricing Model\nYes No Not Applicable\n\n1. Do you intend to/do you charge fees for vLEI issuance?\n2. Do you intend to/do you charge fees for vLEI revocation?\n3. Does your agreed business plan include transparent financial\n\ninformation and assumptions regarding the vLEI Issuer Services\n\ndescribed in Section F?\n4. Will/can you confirm that your organization will be/is solely\n\nresponsible for managing the revenue that is produced and costs that\n\nare incurred in the running of your vLEI operations?\n5. Can you ensure that your operations regarding vLEls will be/are\n\nsustainably financed?\n6. Based on your VLEI business model, plans and volume estimates for\n\ntarget vLEI customers, please provide your estimates of LEI's (for target\n\ncustomers that do not have LEIls) and vLEI volumes for this year and the next\n\ntwo years’ operations (if you are answering the question in the 4th quarter of\n\nthis year, then please indicate for the estimate of the next three years’\n\noperations) and a short description of the reason.\n\nGLEIF 2022|05\n","contentLength":1160,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:22:54.913Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2023-04-03_appendix-3-vlei-issuer-qualification-program-checklist_v1.2_final.pdf","content":"General Information for vLEI Issuer Qualification Program Submission 10\n> Required Documentation to be Submitted\nF vLEI Issuer Services\nVLEI Issuer Services\nAdditional Documentation Requested\nPlease provide brief narrative.\n1. If you will charge for vLEI Issuance and/or revocation will/do you have\na standard process for receiving payments from a Legal Entity?\n2. How will/do you ensure processing applications for issuance and\nrevocation of vLEIls without delay?\n3. Will/do you have a process in place to verify that the Legal Entity\nIdentifier (LEI) of the Legal Entity has an entity status of = \"Active\" and\nRegistration status = \"ISSUED\", \"PENDING_TRANSFER\" or\n\"PENDING_ARCHIVAL\" in the Global LEI System?\n4. How will/do you inform the Legal Entity of needed amendments\nto their instructions or refusal to issue VLEIs?\n5. In the case of VLEI Credential Issuance, will/lhave you implemented\nthe necessary Identity Verification requirements?\n6. Will/do you validate the name of the person and the Official\nOrganizational Role of the Legal Entity Official Organizational Role vLEI\nCredential using one or more official public sources or by requesting from the\nLAR(s) copies of documents of the Legal Entity, such as Board minutes or\nresolutions, statutes or articles, which would validate the name and the role of\nthe OOR Person?\n7. Will/do you access, using the GLEIF API, the lists of Official\nOrganizational Roles maintained by GLEIF to choose the correct OOR\ncode to be embedded in OOR vLEI Credentials?\n8. Will/do you have processes and procedures to manage, research\nand validate incoming challenges regarding the name of a person and/\nor their Official Organizational Role in a Legal Entity OOR vLEI\nCredentials?\n9. Will’/have you complied with the requirements defined for all vLEI\nservices included in the Appendix 5 to the vLEI Issuer Qualification\nAgreement — Service Level Agreement (SLA)?\n10. Will/do you call the vLEI Reporting API with each issuance of a Legal\nEntity vLEI Credential and for each Legal Entity Official Organizational\nRole vLEI for which the Legal Entity has confirmed the consent of the\nOOR person?\nGLEIF 2022|05\n","contentLength":2147,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:22:54.913Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-4-vlei-issuer-contact-details_v1.0_final.pdf","content":"OGLEIF’ Protecting digital rust\nverifiable LEI (vLEI)\nEcosystem Governance Framework v1.0\nVLEI Issuer Qualification Agreement\nAppendix 4 vLE| Issuer Contact Details\nDocumel:\\l:k\\)llzacrsion 1.0\n2022-12-06\n3 N O\n2 - Vfé\\ . ‘}/ .. -\n‘ 389.60 ‘ ::/ . - '. _‘ : : .,‘.\nS . «'3*39’., (‘ e T e . e e\n\\ B ‘,\\ f}_{{ ’ . e on% s - : :\n) - v - : .\n.b e p ‘,. .{ ..‘. s . .\ni . . .,. ‘ . 0’ | 2\n.,\n' -\n","contentLength":391,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:23:09.318Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-4-vlei-issuer-contact-details_v1.0_final.pdf","content":"Contact Details of the Parties\nGLEIF Candidate/Qualified vLEI Issuer\nBasic Contact Details\nLegal domicile:\nGlobal Legal Entity Foundation (GLEIF)\nSt. Alban-Vorstadt 5\nCH-4052 Basel (Switzerland)\nCommerce-Register ID: CHE-200.595.965\nFrankfurt Office:\nBleichstrasse 59\nDE-60313 Frankfurt/Main (Germany)\nPhone (Switchboard):\nBasel: +41 61 5087045\nGeneral E-Mail Address:\ninfo@gleif.org\nAuthorized Signatory/Signatories\nStephan Wolf\nCEO (joint signature of two)\nMail: Stephan.wolf@gleif.org\nMobile: +49 151 52753557\nSven Schumacher\nGeneral Counsel (joint signature of two)\nMail: sven.schumacher@gleif.org\nMobile: +49 151 1710509\nRelationship Managers\nGLEIF Qualified vLEI Issuer Relationship\nManager\nTo be assigned upon successful Qualification\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 2 of 3\nAppendix 4 vLEl Issuer Contact Details\n@ Public Document Version 1.0\n2022-12-06_Appendix-4-vlei-issuer-contact-details _v1.0_final.docx 2022-12-06\n","contentLength":959,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:23:09.318Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-4-vlei-issuer-contact-details_v1.0_final.pdf","content":"Responsible for Qualification Program\nAntonia Christoforidi\nAccreditation and Audit Services\nMail: Antonia.christoforidi@gleif.org\nMobile: +49 151 17120527\nResponsible for Service Management\nAnja Lechner\nHead of Service Management\nMail: anja.lechner@gleif.org\nMobile: +49 151 171120502\nSLA Escalation Level Responsibilities\nLevel One: GLEIF vLEl Issuer Relationship\nManager\nLevel Two: GLEIF Head of Service Management\nLevel Three: GLEIF CEO\nVLEI Issuer Qualification Agreement Change Management\nGLEIF Qualified vLEI Issuer Relationship\nManagement\nTermination of Qualified vLEI Issuer Qualification\nGLEIF Qualified vLEI Issuer Relationship email addresses of current Designated\nManagement Authorized Representatives (DARs) of the Legal\nEntity to be provided to GLEIF by the Qualified\nVLEI Issuer which may be used in the event of\ntermination of the Qualified VvLEI Issuer\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 3 of 3\nAppendix 4 vLEl Issuer Contact Details\n@ Public Document Version 1.0\n2022-12-06_Appendix-4-vlei-issuer-contact-details _v1.0_final.docx 2022-12-06\n","contentLength":1088,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:23:09.318Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-5-qualified-vlei-issuer-service-level-agreement_v1.2_final.pdf","content":"@> Protecting digital trust\nverifiable LEI (vLEI) Ecosystem\nGovernance Framework v1.0\nVLEI Issuer Qualification Agreement\nAppendix 5 Qualified vLEI Issuer\nService Level Agreement\nPublic\nDocument version 1.2\n2022-12-06\n. . — ’ A é | /\ne p- *\\” « -\n. ~ fié\\‘ B / Vi — -\nI g, S S\n’ . . o TR TN S @ o. F. .. :\n=\\ : _’ ¢ ' ‘u‘\\ \" {F({ ’d N | ey k .\n.i . p (. b \" e - o.... ° . - :\ng » € i\nA » J ‘ y - * »\nYo 3\n-\n","contentLength":406,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:24:47.569Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-5-qualified-vlei-issuer-service-level-agreement_v1.2_final.pdf","content":"Table of Contents\n1 Service Level Agreement GlOSSary.....c.ccceeecerreirieenierenecrrencreenenranesennnees 3\n2 GLEIF Services — Service DesCriptions ........cccceeeeeerreeencrenceecrencresencsnsenees 0\n2.1 vLElIssuer QUalification ........ccoccoiiiiiieiieieee e e sseaaens O\n2.2 Annual vLEI Issuer QUalification .......cccceeeeeeeiieiie e enenenn D\n2.3 Termination of Qualified vLEI Issuer Qualification........ccccoocvvevreeeeeeieninniniiiiiiienn 11\n2.4 VLEIREPOITING APl ..ot ee e e e ereee et s s e e eesesaseseseeeeess 13\n2.5 Challenge Legal Entity Data.....ccccccovvviiiiiiiniiiieeiesciiieee e essvieeeessssiiineesesssiinneseesnnns 14\n2.6 Communications Portal.........ccoccooiiiiiiieiiee e ee e eeseeenens 1D\n3 VLEl Issuer Services — Service Descriptions.....ccccceeeuereeencrereecrencennrencenna 17\n3.1 Issue Legal Entity VLEI Credentials .......cccccovuiiiiiiiiiiiiiiiie e essieeee e sieieeeen 18\n3.2 Issue Legal Entity Official Organizational Role vLEI Credentials........................... 19\n3.3 Manage Legal Entity vLEI Credentials and Legal Entity Official Organizational Role\nVLEI Credentials......cooo ettt ee e e eennnnsneeneenens 21\n4 Monitoring and Service Level Breaches........ccceeeereeniiirenccreeiceennccreeneennn23\n4.1 Maintenance windows at GLEIF.............cccooiiiiiieeiie e eeeecrcccrierreeeeee e 25\n4.2 Service LeVel BreaChes ... uiiiiii ettt ee e e errrnrsnraesseeeseeeaeeeees 2D\n4.3 Escalation Management.....ccceciviieiiiniiiiieee st eee s sineae e e snnaeeeesnnnneees 2D\nT N XY or- | =1 o o T =LY P SUPUUR DY 1o\n4.3.2 ESCAlAtiON LEVEI 2 ..ottt ee e e e ssrtrrrae e e e s e e e s snnnnneaeens 2D\nT I Y or- | = o o =LY T I SR UPSPPUDY) o3\nO =T o o 11 - L o] o (RPN PUUUPPPRRRRPPRR o\n4.5 EScalation CoNtAcES .......uiiiiiiiiiiieiie et eee e e et resaeeeeeeeaeeeees 20\n5 Incident Management......c.ccccoiieiieeiiinniieeiiieniinnineiinnesesssesnenssseneess 2 7\n5.1 MaJor INCIAENT...ciiiiiiiiieeee e e e e s saaeeae e e s sinaaeeeees 28\n6 complaints............................................................................................29\n7 GLEIF Code of Conduct in case of a disaster......cccccceeeereenirrnnncreenncnenee... 30\n8 SLA Reports...........................................................................................31\n9 Change of Service LeVels .......ccueeeiiieiireeiiieniiieeirrencernnesenneesnnsesranseees 32\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 2 of 32\nPublic Version 1.2\nGLEIF 2022-12-06_appendix-5-Qualified-vlei-issuer-service-level- 2022-12-06\nagreement_v1.2_final.docx\n","contentLength":2561,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:24:47.569Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-5-qualified-vlei-issuer-service-level-agreement_v1.2_final.pdf","content":"2.3 Termination of Qualified vLEIl Issuer Qualification\nTermination of Qualified vLEIl Issuer Qualification\nRevoke the Qualified vLEI Issuer VLEI Credential and migrate\nimpacted vLEI Credentials\nGLEIF will terminate the Qualification of any Qualified vLEI Issuer\nthat does not successfully complete Annual vLEI Issuer\nQualification, does not address of qualification issues\ndocumented as a result of Annual vLEI Issuer Qualification, does\nnot remediate breach of requirements documented in the\nQualified vLEl Issuer Agreement or its appendices, if the LEl of a\nQuialified vLEl Issuer does not meet the required entity and LEI\nregistration requirements or if the Qualified vLEI Issuer chooses\nto cease VLEI Issuer operations.\nGLEIF will revoke the Qualified vLEI Issuer vLEI Credential of the\nterminated vLEl Issuer and will remove the terminated vLEI Issuer\nfrom the list of Qualified vLEI Issuers on GLEIF’s website which\nwill result in a change in status of the TrustMark on gleif.org.\nThe leaving Qualified vLEl Issuer notifies the Designated\nAuthorized Representatives of each managed Legal Entity,\ninforming them that all their vLEI certificates will be revoked and\nbecome invalid by the date provided and therefore they must\nfind a new Qualified VLEI Issuer before that date.\nIn case the leaving Qualified vLEl Issuer fails or refuses to notify\nthe Designated Authorized Representatives of each managed\nLegal Entity, GLEIF will take the ownership of the notification and\nmay additionally held the leaving Qualified vLEI Issuer liable for\ndamages according to Qualification Agreement, Chapter X.\nLiability.\no GLEIF\no Terminated vLEl Issuers\no Other Qualified VLEI Issuers\no Revoke qualified vLEI Issuer vLEI Credential\no If the termination notification has not been managed by the\nleaving Qualified vLEI Issuer, GLEIF notifies the Designated\nAuthorized Representatives of Legal Entities\no Cooperate in termination\n¢ Notify all the Designated Authorized Representatives of the\nmanaged Legal Entities\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 11 of 32\nPublic Version 1.2\nGLEIF 2022-12-06_appendix-5-Qualified-vlei-issuer-service-level- 2022-12-06\nagreement_v1.2_final.docx\n","contentLength":2197,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:24:47.569Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-5-qualified-vlei-issuer-service-level-agreement_v1.2_final.pdf","content":"60 calendar days\n2 concurrent Terminated vLEl Issuers\nIn case the Continuity process is invoked (ref. chapter 7)\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 12 of 32\nPublic Version 1.2\nGLEIF 2022-12-06_appendix-5-Qualified-vlei-issuer-service-level- 2022-12-06\nagreement_v1.2_final.docx\n","contentLength":306,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:24:47.569Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-5-qualified-vlei-issuer-service-level-agreement_v1.2_final.pdf","content":"2.4 vLEI Reporting API\nVLEI Reporting API\nLegal Entity vLEI credentials and Legal Entity Official\nOrganizational Role VLEI credentials must be reported by the\nQuialified vLEl Issuer to GLEIF in order to be published by GLEIF on\nthe reference data page of the respective LEI\nGLEIF provides the vLEI Reporting API for Qualified vLEI Issuers to\nnotify GLEIF of the issuance of Legal Entity vLEI Credentials\nand/or Legal Entity Official Organizational Role vLEI Credentials.\nThese Legal Entity vLEI Credentials and Legal Entity Official\nOrganizational Role vLEI Credentials, issued by the Qualified vLElI\nIssuer, are published by GLEIF on the LEI page of the Legal Entity.\nThe vLEI Reporting API also will be used by the Qualified VLElI\nIssuers to inform GLEIF of updates for these vLEI Credentials that\nhave been revoked.\nQuialified vLEl Issuers must call the vLEI Reporting APl with each\nissuance event of Legal Entity vLEI Credentials and Legal Entity\nOfficial Organizational Role vLEI Credentials and for every\nrevocation event of these vLEI Credentials.\no GLEIF\n¢ Qualified vLEl Issuers\no Provide vLEI Reporting API\no Report all Legal Entity vLEI credentials and Legal Entity Official\nOrganizational Role VLEI credentials to GLEIF (Issuance,\nRevocation)\n99,9 % (Monday — Sunday 00:00 — 24:00)\n60 requests / minute\nIn case the Continuity process is invoked (ref. chapter 7)\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 13 of 32\nPublic Version 1.2\nGLEIF 2022-12-06_appendix-5-Qualified-vlei-issuer-service-level- 2022-12-06\nagreement_v1.2_final.docx\n","contentLength":1567,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:24:47.569Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-5-qualified-vlei-issuer-service-level-agreement_v1.2_final.pdf","content":"2.5 Challenge Legal Entity Data\nChallenge Legal Entity Data\nFacility to challenge Legal Entity related data\nThis service provides the Qualified vLEI Issuers with the\nchallenges triggered by the public or even directly by GLEIF to\nassess Legal Entity related data. The Qualified vLEI Issuers shall\nreview, and respond to the submitted challenges.\nThe Qualified vLEI Issuers shall ensure the pertaining data is\nadjusted given the challenge is justified, to provide the adjusted\nrecord to GLEIF.\n¢ Provide a mechanism for any third party to challenge Legal\nEntity related data\n¢ Provide the technical means to the Qualified vLEl Issuers to\nrespond accordingly to the challenger\n* Review and respond to all challenges transmitted by GLEIF\n¢ Research the content of the challenge and verify the\nchallenge is valid and justified\no Update the vLEl data (if justified) and provide the updated\ninformation to GLEIF via the vLEl Reporting API\n¢ Inform the challenger about the result of the research and\njustify possible actions or the lack of these\n¢ Inform the Legal Entity, associated with the challenged vLEI\ndata, about verified challenges and of challenges which have\nfailed Verification\n¢ The Qualified vLEl Issuer shall provide GLEIF with their contact\nperson(s) assigned to manage the vLEI Challenges\n97,7 % (Monday — Sunday 00:00 — 24:00) for Customer Portal\n10 challenges/day\nIn case the Continuity process is invoked (ref. chapter 7)\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 14 of 32\nPublic Version 1.2\nGLEIF 2022-12-06_appendix-5-Qualified-vlei-issuer-service-level- 2022-12-06\nagreement_v1.2_final.docx\n","contentLength":1629,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:24:47.569Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-5-qualified-vlei-issuer-service-level-agreement_v1.2_final.pdf","content":"2.6 Communications Portal\nCommunications Portal\nA central web-based communication portal for all\ncommunications between GLEIF and business partners\nA centralized communication platform to support the exchange\nof information between GLEIF and business partners, supporting\nGLEIF’s Relationship Management function.\nThis communications platform facilitates:\no Regular messaging among GLEIF and business partners\no Master Data of business partners (e.g., contact management)\no Other necessary exchanges\no GLEIF\n¢ Candidate and Qualified vLEI Issuers\n* Enable vLEl Issuer to register an account\no Provide Calendar & Events\no Provide a repository for vLEl Issuer related information like:\ne Sharing information for Qualification and Annual vLEI\nIssuer Qualification\no Collecting vLEI Issuer information in the portal\ne Sharing GLEIF contact information with vLEI Issuers\n¢ Exchanging certain information among vLEl Issuers\n* Enable to other operational portals as necessary\n¢ Enter valid registration information\no Periodically review list of Authenticated users for the\nQualified vLEl Issuer and confirm Authenticated users’ access\nand access roles.\no Deliver upcoming events to GLEIF\no Subscribe to the vLEI calendar updates and numbered\nmessages\no Unsubscribe as necessary\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 15 of 32\nPublic Version 1.2\nGLEIF 2022-12-06_appendix-5-Qualified-vlei-issuer-service-level- 2022-12-06\nagreement_v1.2_final.docx\n","contentLength":1464,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:24:47.569Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-5-qualified-vlei-issuer-service-level-agreement_v1.2_final.pdf","content":"o Conduct activities related to service level reporting as\nnecessary\n¢ Provide other data requests or information filings as\napplicable\n97,7 % (Monday — Sunday 00:00 — 24:00)\nTo register an account within one GLEIF business day\n20 requests per GLEIF business day\nIn case the Continuity process is invoked (ref. chapter 7)\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 16 of 32\nPublic Version 1.2\nGLEIF 2022-12-06_appendix-5-Qualified-vlei-issuer-service-level- 2022-12-06\nagreement_v1.2_final.docx\n","contentLength":515,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:24:47.569Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-5-qualified-vlei-issuer-service-level-agreement_v1.2_final.pdf","content":"3 VLEl Issuer Services — Service Descriptions\nThe VLEI Issuer services set out in this Service Level Agreement all are related to the management of\nthe Legal Entity vLEI Credential and the Legal Entity Official Organizational Role vLEI Credential by the\nVLEI Issuer, and also to the transmission of all related information to GLEIF. The credibility and trust of\nthe public in the vLEls is deeply anchored to the credibility and trust in the information the vLEl Issuer\nprovides to GLEIF and to the effective management of the listed services by the Qualified vLEI Issuer.\nTo ensure compliance with its Core Duties, the Qualified vLEl Issuer shall also provide means and\nprocesses for improving operational quality and performance.\nThe vLEl Issuer is responsible that any third party involved in these services is aware of this document,\nof the related obligations and that has in place the requested processes for improving operational\nquality and performance as well.\nThe following table shows the service levels and related targets that are applicable for all the vLElI\nIssuer services.\nChallenge vLEI Data 15 calendar days\nProcessing time\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 17 of 32\nPublic Version 1.2\nGLEIF 2022-12-06_appendix-5-Qualified-vlei-issuer-service-level- 2022-12-06\nagreement_v1.2_final.docx\n","contentLength":1335,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:24:47.569Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-5-qualified-vlei-issuer-service-level-agreement_v1.2_final.pdf","content":"3.1 Issue Legal Entity vLEI Credentials\nIssue Legal Entity vLEI Credentials\nQualified vLEl Issuer issues a Legal Entity vLEI Credential to a\nLegal Entity\nQualified vLEl Issuers provide the means for Legal Entities to\nrequest vLEI Credentials at the entity level, Legal Entity vLElI\nCredentials.\nQualified vLEl Issuers verify that a Legal Entity’s LEl has an\nEntityStatus = “ACTIVE” and a RegistrationStatus = “ISSUED”,\n“PENDING_TRANSFER” or “PENDING_ARCHIVAL”, as well as\ncertain ldentity Verification requirements, such as the\nrepresentative of the Legal Entity applying for the vLEl is\nauthorized to act on behalf of the Legal Entity and that the\ncredential wallet is controlled by this representative of the Legal\nEntity.\nThe Qualified vLEl Issuer then can issue a Legal Entity vLEl\nCredential to the Legal Entity’s credential wallet.\nLists of Legal Entity vLEI Credentials are published on gleif.org so\nthat the existence of Legal Entity vLEI Credentials issued for Legal\nEntities will be discoverable.\no Legal Entities via the contract with Qualified vLEl Issuers\n¢ By using the GLEIF API, Qualified vLEI Issuers must verify that\neach new Legal Entity Credential is related to a Legal Entity\nhaving an LEI with EntityStatus = “ACTIVE” and\nRegistrationStatus = “ISSUED”, “PENDING_TRANSFER” or\n“PENDING_ARCHIVAL”\ne Qualified vLEI Issuers must follow the Identity Verification\nrequirements specified in the Legal Entity vLEI Credential\nFramework document which is part of the verifiable LEI (vLEIl)\nEcosystem Governance Framework\no Qualified vLEI Issuer shall maintain the list of all the\nDesignated Authorized Representatives and Legal Entity\nAuthorized Representatives’ email addresses, that shall be\nshared with GLEIF and managed as for GLEIF requirements\nAll Legal Entity Credentials are issued to Legal Entities having an\nLEI with EntityStatus = “ACTIVE” and RegistrationStatus =\n“ISSUED”, “PENDING_TRANSFER” or “PENDING_ARCHIVAL”\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 18 of 32\nPublic Version 1.2\nGLEIF 2022-12-06_appendix-5-Qualified-vlei-issuer-service-level- 2022-12-06\nagreement_v1.2_final.docx\n","contentLength":2131,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:24:47.569Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-5-qualified-vlei-issuer-service-level-agreement_v1.2_final.pdf","content":"3.2 Issue Legal Entity Official Organizational Role vLEI Credentials\nQualified vLEl Issuer issues Legal Entity Official Organizational\nRole vLEI Credentials to an Official Organizational Role Person of\nthe Legal Entity\nQualified vLEl Issuers can issue Legal Entity Official Organizational\nRole VLEI Credentials (OOR Credentials) at the request of the\nLegal Entity Authorized Representatives (LAR) holding valid Legal\nEntity vLEI Credential. A LAR MUST issue Qualified vLEl Issuer\nAuthorization vLEI Credential explicitly authorizing the Qualified\nVLEI Issuer Authorized Representatives (QARs) to issue each VLEI\nRole Credential. The Qualified vLEI Issuer Authorization vLEl\nCredential will become part of the chain of the vLEI Role\nCredentials.\nQuialified vLEl Issuers ensure that the LEI embedded in the OOR\nCredential is the LEI of the Legal Entity requesting the OOR\nCredential, verify that a Legal Entity’s LEIl has an EntityStatus =\n“ACTIVE” and a RegistrationStatus = “ISSUED”,\n“PENDING_TRANSFER” or “PENDING_ARCHIVAL”, and conduct\ncertain ldentity Verification requirements, such as verifying that\nthe representative of the Legal Entity applying for the OOR\nCredential is authorized to act on behalf of the Legal Entity,\nvalidating the name and the Official Organizational Role of the\nOOR Person using one or more official public sources or in official\ndocuments of the Legal Entity requested from the Legal Entity\nAuthorized Representative, and verifying that the OOR Person is\nin control of its credential wallet.\nAs an added governance and security measure, Qualified vLEI\nIssuers are required to implement a workflow that separates the\nfunctions of performing the above verifications and validations\nand the checking/approval that these verifications and\nvalidations have been done prior to issuing an OOR Credential.\nOnce approval has been given, the Qualified vLEI Issuer can issue\nthe Legal Entity Official Organizational Role vLEI Credential to the\nOOR Person’s credential wallet.\nLists of OOR Credentials will be published on gleif.org (LEl,\nperson’s name and OOR) so that the existence of OOR Credentials\nissued for Legal Entities will be discoverable (the Legal Entity is\nrequired to confirm to the Qualified vLEIl Issuer that the OOR\nPerson has given consent for field values to be published)\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 19 of 32\nPublic Version 1.2\n@ 2022-12-06_appendix-5-Qualified-vlei-issuer-service-level- 2022-12-06\nagreement_v1.2_final.docx\n","contentLength":2501,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:24:47.569Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-5-qualified-vlei-issuer-service-level-agreement_v1.2_final.pdf","content":"¢ By using the GLEIF API, Qualified vLEI Issuers must verify that\neach new Legal Entity Official Organizational Role VLElI\nCredentials is related to a Legal Entity having an LEI with\nEntityStatus = “ACTIVE” and RegistrationStatus = “ISSUED”,\n“PENDING_TRANSFER” or “PENDING_ARCHIVAL”\no Qualified vLEl Issuers must follow the Identity Verification\nrequirements specified in the Legal Entity Official\nOrganizational Role vLEIl Credential Framework document\nwhich is part of the verifiable LEI (vLEI) Ecosystem\nGovernance Framework\nissued to Legal Entities having an LEIl with an EntityStatus =\n“ACTIVE” and a RegistrationStatus = “ISSUED”,\n“PENDING_TRANSFER” or “PENDING_ARCHIVAL”\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 20 of 32\nPublic Version 1.2\n@ 2022-12-06_appendix-5-Qualified-vlei-issuer-service-level- 2022-12-06\nagreement_v1.2_final.docx\n","contentLength":867,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:24:47.569Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-5-qualified-vlei-issuer-service-level-agreement_v1.2_final.pdf","content":"1 Service Level Agreement Glossary\nNote: All definitions of terms in the vLEI Issuer Qualification Agreement also apply to this Service Level\nagreement and prevail in case of inconsistency.\n\nAllowed customers of the service.\n\nAttended Service Operating | Time of reachability of GLEIF support on business days.\n\nTime\n\nAvailability Property of being accessible and usable on demand by an\nauthorized entity.\n\nBreach When the measure of a Service Level (i.e. the Service Level Result)\nhas exceeded the respective Service Level Target.\n\nCalendar days Calendar days means every day on the calendar, including\nweekends and public holidays.\n\nComplaint A written, formal expression of dissatisfaction from an vLEl Issuer’s\nRelations Manager/Authorized Signatory related to GLEIF services\nand relevant requirements.\n\nCustomer Portal Portal for Qualified vLEI Issuers to perform defined processes.\n\nDescription Detailed description that also identifies the service interface and its\noutcomes.\n\nDisaster Extraordinary situation where widespread human, material,\neconomic or environmental losses have occurred which exceeded\nGLEIF’s ability to respond and recover using its own resources.\n\nEssential Tasks Essential Tasks that are required to be performed by the Service\nProvider to deliver the agreed service.\n\nEssential tasks excluded Essential tasks that must not be delegated to a Third-Party Service\n\nfrom Third Party Services provider, unless otherwise agreed in any specific agreement.\n\nException Extraordinary situations, that will not be considered for the\ncalculation of a service level.\n\nFailure Each event that has not been performed as committed, that\ncontribute to the evaluation of a Service Level.\n\nGLEIF Business Day Business day in Frankfurt am Main, Germany (Monday — Friday\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 3 of 32\nPublic Version 1.2\n\nGLEIF 2022-12-06_appendix-5-Qualified-vlei-issuer-service-level- 2022-12-06\nagreement_v1.2_final.docx\n","contentLength":1976,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:24:47.569Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-5-qualified-vlei-issuer-service-level-agreement_v1.2_final.pdf","content":"3.3 Manage Legal Entity vLEI Credentials and Legal Entity Official\nOrganizational Role vLEI Credentials\n\nManage Legal Entity vLEI Credentials and Legal Entity Official\n\nOrganizational Role vLEI Credentials\n\nQuialified vLEl Issuers management of Legal Entity VLEI\n\nCredentials and Legal Entity Official Organizational Role VLElI\n\nCredentials\n\nQualified vLEl Issuers are required on a regular basis to check the\n\nstatus of LEls for which Legal Entity vLEI Credentials have been\n\nissued. These LEIs must maintain an EntityStatus = “ACTIVE” and\n\na RegistrationStatus = “ISSUED”, “PENDING_TRANSFER” or\n\n“PENDING_ARCHIVAL”.\n\nA process to notify a Legal Entity that the Legal Entity’s Legal\n\nEntity vLEI Credential would be in danger of being revoked if its\n\nLEl is not renewed as required annually also must be put in place.\n\nQualified vLEl Issuers revoke a Legal Entity vLEI Credential if the\n\nLEI check shows that the Legal Entity’s LEl is not in compliance\n\nwith the above entity and LEI registration status requirements.\n\nRevocation of the vLEI Legal Entity Credential causes verification\n\nto fail for all the Legal Entity Official Organizational Role VLElI\n\nCredentials issued by a Qualified VLEI Issuer and the Legal Entity\n\nEngagement Context Role VLEI Credentials that the Legal Entity,\n\nor the Qualified VLEl Issuer, have issued. For the avoidance of\n\ndoubt, digital signatures previous to the revocation of the Legal\n\nEntity vLEI Credential will retain their validity.\n\nQualified vLEl Issuers maintain Legal Entity Official Organizational\n\nRole VvLEI Credentials until notified by the Legal Entity that OOR\n\nCredentials need to be revoked due to a change in role or status\n\nof OOR Persons. The Legal Entity Authorized Representatives\n\nmust use the Qualified VvLEI Issuer Authorization vLEI Credential\nthat authorized the issuance of the OOR vLEI Credential as\nauthorization to the Qualified vLEl Issuer to revoke the OOR vLEI\n\nCredential.\n\nQuialified vLEl Issuers manage their public and private keys\n\naccording to Key Event Receipt Infrastructure (KERI) technical\n\nrequirements for key management and for credential\nmanagement according to KERI technical requirements.\n\no Qualified vLEI Issuers are required on a regular basis to check\nthe status of LEls for which Legal Entity vLEI Credentials have\nbeen issued. All Legal Entity Credentials shall be always\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 21 of 32\nPublic Version 1.2\n\n@ 2022-12-06_appendix-5-Qualified-vlei-issuer-service-level- 2022-12-06\nagreement_v1.2_final.docx\n","contentLength":2554,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:24:47.569Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-5-qualified-vlei-issuer-service-level-agreement_v1.2_final.pdf","content":"related to Legal Entities having an LEI with EntityStatus =\n“ACTIVE” and RegistrationStatus = “ISSUED”,\n“PENDING_TRANSFER” or “PENDING_ARCHIVAL”\no Qualified vLEI Issuers are required to put in place a process to\nnotify a Legal Entity that the Legal Entity’s Legal Entity vLEI\nCredential would be in danger of being revoked if its LEl is not\nrenewed as required annually. Qualified vLEI Issuers revoke a\nLegal Entity vLEI Credential if the LEI check shows that the\nLegal Entity’s LEl is not in compliance with the above entity\nand LEI registration status requirements\n¢ Qualified vLEIl Issuers must revoke vLEI Credentials to Legal\nEntities having an LEI with EntityStatus other than “ACTIVE” or\nRegistrationStatus other than “ISSUED”,\n“PENDING_TRANSFER” or “PENDING_ARCHIVAL”\no Qualified vLEIl Issuer shall maintain the list of all the\nDesignated Authorized Representatives and Legal Entity\nAuthorized Representatives’ email addresses, that shall be\nshared with GLEIF and managed as for GLEIF requirements\nLegal Entity Credentials are revoked within 24 hours after the\nrelevant change of LEI status is available on the GLEIF API (that\ngets updated 3 times per calendar day)\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 22 of 32\nPublic Version 1.2\n@ 2022-12-06_appendix-5-Qualified-vlei-issuer-service-level- 2022-12-06\nagreement_v1.2_final.docx\n","contentLength":1363,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:24:47.569Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-5-qualified-vlei-issuer-service-level-agreement_v1.2_final.pdf","content":"4 Monitoring and Service Level Breaches\nThe Service Levels and the established Service Level targets ensure the required high quality of the\nservice GLEIF and the vLEI Issuer shall provide to customers and the public. It is therefore essential to\nclosely monitor the achievement of the agreed Service Levels; GLEIF and the VLEI Issuer are therefore\nresponsible to monitor closely their own services and to put in place any needed remediation to\nprovide “state of art” experience to customers and the public.\nGLEIF Service Level Result Calculations\nAvailability Tmonth - T non availability® GLEIF’s systems\n—— )x100\nTmonth®\n(1) Minutes in the month\n(2) Minutes in the month when the service was not available (excluding planned\nmaintenances)\nThe difference is calculated considering calendar days\nProceSSing Time Z(EndResponse(l) - Sta‘rtRequest(z)) GLEIF’'s Customer\nZ(Requests)m) Portal\n(1) Time stamp when the task has been accomplished\n(2) Time stamp when the task has been submitted\n(3) Number of tasks accomplished in the month\nProcessing Time for (Z(EndResponse(l) - Sta‘rtRequest(z))> GLEIF’s Customer\nInci d ents Z Closed incidents priority Porta I\n(1) Time stamp when incident has been remediated or a workaround has been put in place\n(2) Time stamp when the incident has been classified\n(3) Number of requests received in the month\nPI‘OCGSSing Time for Z(EndResponseBD(l) - Sta‘rtRequestBD(z)) GLE”:'S\n“Communications Z(R ® Communications\nequests)\nPortal”, Register an Portal\n(1) Time stamp when the request has been accomplished\nAccount (2) Time stamp when the request has been submitted\n(3) Number of closed requests in the month\nProceSSing Time for (Z(EndResponseBD(l) - Sta‘rtRequestBD(z))> GLEIF’s vLEI\nu. . - - .\nVLEI Reporting Z(Requests)(s) Reporting API\nAPI” Facility\n(1) Time stamp when the request has been accomplished\n(2) Time stamp when request has been submitted\n(3) Number of requests received in the month\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 23 of 32\nPublic Version 1.2\nGLEIF 2022-12-06_appendix-5-Qualified-vlei-issuer-service-level- 2022-12-06\nagreement_v1.2_final.docx\n","contentLength":2126,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:24:47.569Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-5-qualified-vlei-issuer-service-level-agreement_v1.2_final.pdf","content":"Update Frequency (Z (StartDate® — QuulificationDute(z))> GLEIF’s Customer\n\" - -\nfor “Annual vLEI Z Anmual Qualifications ® Portal\nIssuer\ne . ” (1) Time stamp when the Annual Qualification started\nQuallflcatlon (2) vLEI Issuer Qualification Agreement execution date\n(3) Number of Annual Qualifications started in the month\nVLEI Issuers Service Level Result calculations\nCha”enge VLEI Z(EndResponse(l) - Sta‘rtRequest(z() GLEIF\n—_— S ] £15\nData: Z(Requests)(3) Customer\nPortal\nProcessing T|me (1) Time stamp when the task has been accomplished\n(2) Time stamp when the task has been submitted\n(3) Number of tasks accomplished in the month\nIssue LeQaI Entlty Z (L.E.vLEI Credentials with LEI in incorrect EntityStatus or RegistrationStatus™® VLEI SyStem\nvLEl Credentials:\n(1) Newly issued Legal Entity Credentials related to Legal Entities having an LEI with EntityStatus\nother than “ACTIVE” or RegistrationStatus other than “ISSUED”, “PENDING_TRANSFER” or\nIssuance “PENDING_ARCHIVAL”\nCompliance\nIssue LeQaI Entlty Z (L.E.OOR vLEI Credentials with LEI in incorrect EntityStatus or RegistrationStatus® VLEI SyStem\nOfficial\n. . (1) Newly issued Legal Entity Official Organizational Role Credentials related to Legal Entities having\nOrganlzatlonal ROIe an LEI with EntityStatus other than “ACTIVE” or RegistrationStatus other than “ISSUED”,\n. “PENDING_TRANSFER” or “PENDING_ARCHIVAL”\nVLEI Credentials:\nIssuance\nCompliance\nManage LeQaI Z [ (Current Time(® - Time the LEI Changed status @) > 24 hours | VLEI SyStem\nEntity vLEl\n. (1) Time when the Legal Entity Credential revocation is detected\nCredentlals and (2) Time when, on GLEIF API the information the LEI has been updated with EntityStatus other than\ni P~ “ACTIVE” or RegistrationStatus other than “ISSUED”, “PENDING_TRANSFER” or\nLegal Entity Official “PENDING_ARCHIVAL”\nOrganizational Role\nvLEl Credentials:\nRevocation\nProcessing Time\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 24 of 32\nPublic Version 1.2\nGLEIF 2022-12-06_appendix-5-Qualified-vlei-issuer-service-level- 2022-12-06\nagreement_v1.2_final.docx\n","contentLength":2077,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:24:47.569Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-5-qualified-vlei-issuer-service-level-agreement_v1.2_final.pdf","content":"4.1 Maintenance windows at GLEIF\n\nGLEIF’s website and Global LEI Repository operate 24/7/365 without regular maintenance windows. In\n\ncase of exceptional maintenance windows GLEIF will announce them, whenever possible and on a best\n\neffort’s basis, two weeks ahead via email and/or via Communications Portal.\n\n4.2 Service Level Breaches\n\nIn case of Service Level breaches, finding timely a sustainable remediation is of predominant\n\nimportance for GLEIF and the Qualified vLEl Issuers.\n\nBased on the monthly achievement the Qualified vLEI Issuer can gather on-line from the SLA\n\nDashboard, if a breach on any Service Level Target is detected then the steps below listed should be\n\ninitiated.\n\n4.3 Escalation Management\n\n4.3.1 Escalation Level 1\n\nIn case a breach is detected, i.e., a Service Level Target is not achieved, then an Escalation Level 1 is\n\ntriggered for the Qualified vLEI Issuer to implement the needed countermeasures.\n\nThe SLA Dashboard shall show the remediation occurred latest on the second month after the\n\nescalation notification.\n\nGLEIF can exceptionally extend the remediation time in its sole but reasonable discretion.\n\nIf the SLA Dashboard does not show any more breaches on the target month as well as on the following\n\none, the Escalation Level 1 is closed.\n\nEscalation Level 2 will be triggered:\n\n1. If the Escalation Level 1 has not been remediated as required.\n2. Whena breach, that has been already managed via an Escalation Level 2 or higher, occurs again\nwithin the following 2 months after the escalation closure.\n\n4.3.2 Escalation Level 2\n\nWhenever an Escalation Level 2 is triggered, GLEIF’s Escalation Level 2 contact (or deputy) notifies the\n\nEscalation Level 2 counterpart.\n\nThe SLA Dashboard shall show the remediation occurred by the next available month after the\n\nescalation notification.\n\nGLEIF can exceptionally extend the remediation time in its sole but reasonable discretion.\n\nIf the SLA Dashboard does not show any more breaches on the target month as well as on the following\n\none, the Escalation Level 2 is closed.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 25 of 32\nPublic Version 1.2\n\nGLEIF 2022-12-06_appendix-5-Qualified-vlei-issuer-service-level- 2022-12-06\nagreement_v1.2_final.docx\n","contentLength":2261,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:24:47.569Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-5-qualified-vlei-issuer-service-level-agreement_v1.2_final.pdf","content":"Escalation Level 3 will be triggered in case Escalation Level 2 is not remediated as required.\n4.3.3 Escalation Level 3\nWhenever an Escalation Level 3 is triggered, GLEIF’s Escalation Level 3 contact notifies the Escalation\nLevel 3 counterpart requesting the breach root cause is understood and a final effective remediation\nplan.\nThe counterpart implements a sustainable remediation and GLEIF’'s Escalation Level 3 contact (or\ndeputy) closes the Escalation when the SLA Dashboard shows the remediation occurred on the agreed\nmonth as well as on the following one.\nIf the remediation has not occurred within the expected timeframe and stability, GLEIF may trigger\nsection 4.4 “Termination”.\n4.4 Termination\nIf neither GLEIF nor the vLEI Issuer can reach the definited Service Levels as liste din this document\nwithin an adequate period of time to implement any related recommendations, the parties may\nterminate the Agreement according to section XXII B. of the vLEI Issuer Qualification Agreement.\nDuring the Termination process, the Qualified vLEI Issuer is not allowed to issue any new Legal Entity\nVLEI Credentials.\n4.5 Escalation Contacts\nThe escalation contacts are listed in the relevant section of the Communications Portal.\nIt is expected the Escalation Level 2 contacts to be at managerial level, and the Escalation Level 3\ncontacts at “C” level or equivalent (e.g., President, General Director). Each escalation contact shall\nmention an assigned deputy.\nThe Qualified vLEI Issuer has the responsibility to keep their escalation contacts up to date.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 26 of 32\nPublic Version 1.2\nGLEIF 2022-12-06_appendix-5-Qualified-vlei-issuer-service-level- 2022-12-06\nagreement_v1.2_final.docx\n","contentLength":1753,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:24:47.569Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-5-qualified-vlei-issuer-service-level-agreement_v1.2_final.pdf","content":"5 Incident Management\nGLEIF has implemented the incident management process based on ISO 20000 standard to be able to\nrestore disrupted services back to normal operations to meet service levels.\nThe disrupted service is required to be back to normal operation as quickly as possible with minimal\nimpact on business operations.\nIn the event that an incident on any GLEIF service occurs, the incidents are processed by GLEIF’s\nservice desk, and specialists are assigned to restore agreed services. When the service is fully\nrecovered, the incident is closed.\nIncidents are to be reported via an email to servicedesk@gleif.org .\nIncidents are prioritized based on the Impact-Urgency Matrix_depending on the service affected.\nProcessing time is targeted as service level for the following priorities:\ne Priority 1: 24 hours (during GLEIF business days)\no Priority 2: 2 GLEIF business days\no Priority 3: 3 GLEIF business days\nAttended service operating time is Mo-Fr: 09.00 — 17.00 CET/CEST on GLEIF business days.\nImpact-Urgency Matrix\nThe Impact-Urgency Matrix shows which services are treated with which Priority.\nImpact — measures the effect of an incident based on the functionality of the service.\nUrgency - measures the criticality, which indicates the speed of resolving an incident.\nPriority - is derived from Impact and Urgency.\n3 - Low 2 — Medium 1 - High\nSupporting Services Enhancing Services Core Services\n3 Specific\n] functionality\non unavailable\nPartial Service\nunavailable\n& | Full Service\n\" unavailable\n[\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 27 of 32\nPublic Version 1.2\nGLEIF 2022-12-06_appendix-5-Qualified-vlei-issuer-service-level- 2022-12-06\nagreement_v1.2_final.docx\n","contentLength":1711,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:24:47.569Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-5-qualified-vlei-issuer-service-level-agreement_v1.2_final.pdf","content":"Urgency classification\nVLEI Issuer Qualification Annual VLEI Issuer Application: Customer Portal\nQualification\nVLEI Reporting API Communications Portal _\nChallenge vLEI Data Termination of Qualified vLEI _\nIssuer Qualification\nPriority Level Definition\nThe following table shows the priority level definition for an incident. A resolution target is set for\neach Priority.\n1 High Core Services are inaccessible, interrupted, or 24 hours (during GLEIF\nunusable. business days)\n2 Medium Enhancing Services are unusable or hard to use. | 2 GLEIF business days\n3 Low Support Services are unusable or hard to use. 3 GLEIF business days\n5.1 Major Incident\nA “Major Incident” is a type of incident, that occurs when all or major parts of the core services are\naffected by disruption.\nThe resolution time in case of a major incident is 1 hour during GLEIF business days.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 28 of 32\nPublic Version 1.2\nGLEIF 2022-12-06_appendix-5-Qualified-vlei-issuer-service-level- 2022-12-06\nagreement_v1.2_final.docx\n","contentLength":1055,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:24:47.569Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-5-qualified-vlei-issuer-service-level-agreement_v1.2_final.pdf","content":"6 Complaints\n\nComplaints are handled via the defined process “Feedback”.\n\nThe vLEl Issuer can submit their complaints by communicating with their Business Relations\n\nManager.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 29 of 32\nPublic Version 1.2\n\nGLEIF 2022-12-06_appendix-5-Qualified-vlei-issuer-service-level- 2022-12-06\nagreement_v1.2_final.docx\n","contentLength":369,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:24:47.569Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-5-qualified-vlei-issuer-service-level-agreement_v1.2_final.pdf","content":"7 GLEIF Code of Conduct in case of a disaster\nIn the extraordinary circumstances GLEIF is affected by a disaster:\n\n1. GLEIF informs the vLEl Issuer in the shortest possible time via Communication Portal (if\navailable, or by using any other possible means e.g., email or telephone) and invokes the Service\nContinuity Process\n\n2. Insuch asituation and until full recovery occurred, the following RTOs and targets are effective\n\nvLEI Issuer Qualification < 1 calendar Availability: 95 % (Customer Portal)\nmonth Availability: 97.5 % (GLEIF Website)\nProcessing Time Documentation Completeness: 20\ndays\nProcessing Time Documentation Review: 90 days\nAnnual vLEl Issuer < 1 calendar Availability: 95 % (Customer Portal)\nQualification month Update Frequency: Yearly, on or within 4 months\nTermination of Qualified <2 GLEIF Processing time: 90 calendar days\nVLEI Issuer Qualification business days\nVLEI Reporting API <2 GLEIF Availability: 97.5 %\nbusiness days Processing Time: < 5 sec\nCommunications Portal <2 GLEIF Availability: 95 %\nbusiness days Processing time: 4 GLEIF business days\nChallenge vLEIl Data <1 calendar Availability: 95 % (Customer Portal)\nmonth\nSame workload limits as during business as usual apply.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 30 of 32\nPublic Version 1.2\nGLEIF 2022-12-06_appendix-5-Qualified-vlei-issuer-service-level- 2022-12-06\nagreement_v1.2_final.docx\n","contentLength":1404,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:24:47.569Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-5-qualified-vlei-issuer-service-level-agreement_v1.2_final.pdf","content":"_ excluding public Germany/Hessen holidays).\nGLEIF supplied vLEI Open source developed software sponsored by GLEIF with the\nsoftware capabilities for vLEI Credential Issuance, vLEI Credential\nPresentation, Identifier and Key Management and vLEI Credential\nRevocation and supporting functions.\nLegal Entity VvLEI Credential | The entity level credential issued by a Qualified vLEI Issuer to a\nLegal Entity which contains the LEI of the Legal Entity.\nLegal Entity Official A person that represents the Legal Entity in an official\nOrganizational Role Person | organizational role and has a Legal Entity Official Organizational\n(OOR Person) Role VLEI Credential.\nLegal Entity Official VLEI Role Credentials issued to persons acting officially on behalf of\nOrganizational Role VLEI a Legal Entity. These persons and their roles can be validated by the\nCredential (OOR Legal Entity as well as by one or more external official sources.\nCredentials)\nProcessing Time Time of all involved parties (if not stated otherwise) to fulfill a\nservice request.\nQualified vLEl Issuer A VLEI credential that enables simple, safe, secure instruction and\nAuthorization VLEI authorization by a Legal Entity Authorized Representative (LAR)\nCredential sent to a QVI for the issuance and revocation of vLEI Role\nCredentials.\nRecovery Time Objective The maximum amount of time allowed to resume an activity,\n(RTO) recover resources, or provide products and services after a disaster\nhas occurred.\nDefines the maximum time to respond to a service request.\nService Level Commitment based on Service Level requirements. Ensures that\nthe service is able to meet the GLEIS objectives.\nService Level Result Measure of the characteristic of a service committed to by the\nparties.\nService Level Target (SLT, Specific measurable characteristic of a service that an organization\nalso Service Target) commits to\nService Continuity Process | The process responsible for recovery of GLEIF vital business\nfunctions in the event of a disaster.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 4 of 32\nPublic Version 1.2\nGLEIF 2022-12-06_appendix-5-Qualified-vlei-issuer-service-level- 2022-12-06\nagreement_v1.2_final.docx\n","contentLength":2194,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:24:47.569Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-5-qualified-vlei-issuer-service-level-agreement_v1.2_final.pdf","content":"8 SLA Reports\nGLEIF provides monthly SLA Reports to the Qualified vLEI Issuer by the 10\" GLEIF business day of the\nfollowing month.\nService Reports Definition\nContents Report parameters according to SLA\nReporting period Monthly\nReporting Reports are made available through the Communications Portal\nObligation According to SLA\nLanguage English\nFiling 10 years\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 31 of 32\nPublic Version 1.2\nGLEIF 2022-12-06_appendix-5-Qualified-vlei-issuer-service-level- 2022-12-06\nagreement_v1.2_final.docx\n","contentLength":553,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:24:47.569Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-5-qualified-vlei-issuer-service-level-agreement_v1.2_final.pdf","content":"9 Change of Service Levels\n\nChapter XlIl “Agreement Change Process” of the Qualification Agreement applies.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 32 of 32\nPublic Version 1.2\n\nGLEIF 2022-12-06_appendix-5-Qualified-vlei-issuer-service-level- 2022-12-06\nagreement_v1.2_final.docx\n","contentLength":302,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:24:47.569Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-5-qualified-vlei-issuer-service-level-agreement_v1.2_final.pdf","content":"Service Provider An organization which could provide, operate and/or supports\nServices to one or more customers.\nService Transfer Point The definition of the system where the service is delivered to\nmeasure the accordant Service Level.\nA short description that summarizes the service.\nTechnical Note A note, describing GLEIF processes already identified in this\nAgreement which have an impact on the Qualified vLEIl Issuers.\nUpdate Frequency How often a request for service will occur in a given period of time.\nWorkload Limit A measure of the volume of work the parties are committed to\nassure each service shall achieve the respective Service Level\nTarget.\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 5 of 32\nPublic Version 1.2\nGLEIF 2022-12-06_appendix-5-Qualified-vlei-issuer-service-level- 2022-12-06\nagreement_v1.2_final.docx\n","contentLength":851,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:24:47.569Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-5-qualified-vlei-issuer-service-level-agreement_v1.2_final.pdf","content":"2 GLEIF Services — Service Descriptions\nThe following services are performed by GLEIF. For all of them, the attended service operating time\nwill be during GLEIF’s Business Days between 09.00 — 17.00 Germany/Hessen local time.\n2.1 vLEl Issuer Qualification\nVLEI Issuer Qualification\nEntities desiring to become Qualified vLEI Issuers must seek\nQuialification by GLEIF\nIn order to support the integrity of the vLEI Ecosystem, a vLEl\nIssuer Qualification Program is required for all Candidate vLEI\nIssuers seeking to become Qualified vLEI Issuers of the vLEI\nEcosystem.\nEvery Candidate VLEI Issuer is required to complete the\nQualification Program successfully in order to achieve Qualified\nVLEI Issuer status. The Qualification Program evaluates a\nCandidate vLEl Issuer’s financial, operational, and informational\ntechnology capabilities using the self-assessment questionnaire\nprovided by GLEIF which is referred to as the VLEI Issuer\nQuialification Program Checklist.\nThe vLEI Issuer requirements which Qualified vLEI Issuers must\nmeet are defined in the vLEI Ecosystem Governance Framework\nand in the vLEI Issuer Qualification Agreement and its\nAppendices, which can be downloaded from GLEIF's website.\nUpon successful completion of the Qualification Program, GLEIF\nissues Qualified vLEI Issuer vLEI Credentials to Qualified vLEI\nIssuers as well as TrustMarks and publishes and maintains a list of\nQualified vLEl Issuers on the GLEIF website.\nIt is expected that, on average, the qualification process takes\nroughly 3 months to be completed.\no Candidate vLEl Issuers\no Provide vLEl Issuer Qualification Program Manual and\nChecklist as well as other supporting materials and forms\n» Set up of Non-Disclosure Agreement / vLEIl Issuer\nQualification Agreement\no Provide support calls to Candidate vLEIl Issuer as required\no After the requested set of Candidate vLEI Issuer qualification\nmaterials is provided, GLEIF has 10 calendar days to assess\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 6 of 32\nPublic Version 1.2\nGLEIF 2022-12-06_appendix-5-Qualified-vlei-issuer-service-level- 2022-12-06\nagreement_v1.2_final.docx\n","contentLength":2136,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:24:47.569Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-5-qualified-vlei-issuer-service-level-agreement_v1.2_final.pdf","content":"the documentation completeness and to revert back to the\ncandidate with feedback\no After the candidate VLEl Issuer qualification documentation is\nconsidered complete, GLEIF has up to 60 calendar days to\nprovide the candidate with the status of their application\n¢ Provide GLEIF supplied vLEI software\no Evaluate and confirm readiness of Candidate vLEI Issuer\nbased on Qualification Documentation provided and test run\nof VLEI Issuer operations performed by the Candidate\ne Issue Qualified vLEl Issuer vLEI Credential\no Issue TrustMark\ne Provide and maintain on GLEIF website a list of all Qualified\nVLEI Issuers\no Read vLEl Issuer Qualification Program Manual and other\nsupporting materials\no Sign Non-Disclosure Agreement and submit the same to\nqualificationrequest@gleif.org to initiate the vLElI\nQualification Program\no Fillin vLEI Issuer Qualification Program Checklist and develop\nsupporting documentation as required\no Participate in support calls with GLEIF\no Deliver all necessary Qualification Documentation\ne Provide all Candidate materials no later than 60 calendar days\nfrom the date the request to begin qualification has been\nsubmitted\no Install vLEI software and perform testing of vLEIl Issuer\noperations\no Remediate areas of non-compliance as required\ne Sign vLEl Issuer Qualification Agreement\no Publish Qualified vLEI Issuer vLEI Credential and TrustMark on\nown website\n99.9 % (Monday — Sunday 00:00 — 24:00) for GLEIF Website\n97,7 % (Monday — Sunday 00:00 — 24:00) for Customer Portal\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 7 of 32\nPublic Version 1.2\nGLEIF 2022-12-06_appendix-5-Qualified-vlei-issuer-service-level- 2022-12-06\nagreement_v1.2_final.docx\n","contentLength":1698,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:24:47.569Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-5-qualified-vlei-issuer-service-level-agreement_v1.2_final.pdf","content":"10 calendar days\n60 calendar days\nIn case the Continuity process is invoked (ref. chapter 7)\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 8 of 32\nPublic Version 1.2\nGLEIF 2022-12-06_appendix-5-Qualified-vlei-issuer-service-level- 2022-12-06\nagreement_v1.2_final.docx\n","contentLength":285,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:24:47.569Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-5-qualified-vlei-issuer-service-level-agreement_v1.2_final.pdf","content":"2.2 Annual vLEI Issuer Qualification\n\nAnnual vLEl Issuer Qualification\n\nGLEIF’s process of re-verification of the qualified vLEI Issuer’s\n\ncompliance with expected internal controls and standards within\n\nits vLEI operations\n\nAnnual vLEl Issuer Qualification is GLEIF’s process of regular\n\nverification of the Qualified vLEI Issuer’s compliance with its\n\nexpected requirements within its vLEl operations.\n\nGLEIF reviews information submitted by the Qualified vLEl Issuer,\n\nconsiders the performances scored during the last operational\n\nperiod, assesses the information against vLEl Ecosystem\n\nGovernance Framework and the Qualified vLEI Issuer\n\nQualification Agreement requirements and determines whether\n\nany remedial action is required in order to maintain status as a\n\nQualified vLEl Issuer.\n\nThe Annual vLEl Issuer Qualification is performed on or after the\n\nanniversary date of the qualified vLEI Issuer’s date of\n\nqualification, based on the vLEI Issuer Qualification Agreement\nexecution date.\n\nGLEIF maintains the Qualified vLEl Issuer vLEI Credentials as well\n\nas renews the TrustMarks of Qualified vLEI Issuers successfully\n\ncompleting Annual vLEI Issuer Qualification.\n\ne Qualified vLEI Issuers\n\ne Provide qualified vLEI Issuer annual qualification\nguestionnaire and other review materials\n\n¢ Review qualified vLEI Issuer submission within 45 calendar\ndays of receipt of a complete set of materials.\n\no Confirm adequate levels of compliance with expected\ncontrols exist and/or document required remediation\nactivities\n\no Ensure that any remediation activities are completed in a\ntimely and complete manner\n\n¢ Maintain on GLEIF website the most up to date list of all\nqualified vLEI Issuers\n\n¢ Download the designated annual qualification materials from\nthe Communications portal\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 9 of 32\nPublic Version 1.2\n\nGLEIF 2022-12-06_appendix-5-Qualified-vlei-issuer-service-level- 2022-12-06\nagreement_v1.2_final.docx\n","contentLength":1982,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:24:47.569Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-5-qualified-vlei-issuer-service-level-agreement_v1.2_final.pdf","content":"¢ Provide completed annual qualification questionnaire (self-\nassessment) noting all changes to its internal controls within\nits vLEI operations\n¢ Provide supporting documentation for any process changes\nnoted\n¢ Provide all required materials within 45 calendar days of\nGLEIF request to initiate the annual qualification\no Review GLEIF evaluation results with GLEIF\no Complete any required remediation actions based upon a\nmutually agreed schedule\n97,7 % (Monday — Sunday 00:00 — 24:00) for Customer Portal\nYearly\nOn or within 3 months from the anniversary date of the qualified\nVLEI Issuer’s date of qualification, based on the vLEl Issuer\nQualification Agreement execution date. The scope of the Annual\nVLEI Issuer Qualification will always be the last 12 months form\nthe anniversary date\nIn case the Continuity process is invoked (ref. chapter 7)\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 10 of 32\nPublic Version 1.2\nGLEIF 2022-12-06_appendix-5-Qualified-vlei-issuer-service-level- 2022-12-06\nagreement_v1.2_final.docx\n","contentLength":1043,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:24:47.569Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-6-terms-of-use-qualified-vlei-issuer-trustmark_v1.0_final.pdf","content":"O:GLEIF, Protacting digial st\nverifiable LEI (vLEI)\nEcosystem Governance Framework v1.0\nVLEI Issuer Qualification Agreement\nAppendix 6 Qualified vLEI Trustmark Terms of Use\nDocumel:\\l:k\\)lltlacrsion 1.0\n2022-12-06\no A YTl\no 7 R T e\n— w % N s W . . - :\n. bo o '?{J{,f A . . e\n'b., .°7 \" 4 .{‘ 1 - o.‘O » . . '\n’ -\n| .\n","contentLength":317,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:25:06.163Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-6-terms-of-use-qualified-vlei-issuer-trustmark_v1.0_final.pdf","content":"Qualified vLEI Issuer TrustMark\nTerms of Use\nof the\n\nGlobal Legal Entity Identifier Foundation (GLEIF),\n\nSt. Alban-Vorstadt 5, 4052 Basel, Switzerland\n\nRegarding the use of the Qualified vLEI Issuer TrustMark\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 2 of 4\nVLEI Issuer Qualification Agreement Appendix 6 Qualified vLEI\nTrustMark Terms of Use\nPublic Document Version 1.0\n@ 2022-12-06_appendix-6-terms-of-use-qualified-vlei-issuer-trustmark_ 2022-12-06\n\nv1.0_final.docx\n","contentLength":490,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:25:06.163Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-6-terms-of-use-qualified-vlei-issuer-trustmark_v1.0_final.pdf","content":"1 Introduction\n\nA GLEIF is a not-for-profit foundation incorporated by the Financial Stability Board under the\nlaws of Switzerland.\n\nB. GLEIF qualifies VLEI Issuers to receive Qualified vLEI Issuer Credentials and for vLEI Issuers\nto issue Legal Entity vLEI Credentials and Legal Entity Official Organizational Role VLElI\nCredentials to Legal Entities holding LEls having a LEI Entity Status of Active and a LEI\nRegistration Status of Issued, Pending Transfer or Pending Archival in the Global LEI\nSystem.\n\nI. Definitions\n\"Qualified vLEI Issuer TrustMark and Logo\" shall mean the trustmark and logo issued by\nGLEIF to Qualified vLEI Issuers\n\"You\", \"your\" or equivalent terms refer to you as a Qualified vLEI Issuer.\n\"LEIs\" shall mean one or many Legal Entity Identifiers issued by GLEIF and the LOUs.\nIl. Conditions of Use\n\n1. By using the Qualified vLEI Issuer TrustMark, you acknowledge that you do not have, and\nwill not acquire, any intellectual property or other proprietary rights in the vLEls and that\nyou do not, and will not, claim such rights.\n\n2. You agree that upon receiving vLEI Issuer Qualification that you promptly will display the\nQualified vLEl Issuer TrustMark on your Qualified vLEI Issuer website. You also agree that\nyou promptly will remove the vLEI Issuer TrustMark from your Qualified vLEI Issuer\nwebsite should you fail to complete Annual vLEI Issuer Qualification or are otherwise\nterminated as a Qualified vLEl Issuer.\n\n3. You agree that you shall refrain from creating, in whatever way, the impression that data\nand/or services, except the services provided in accordance with Appendix 5 —Qualified\nVLEI Issuer Service Level Agreement (SLA), are provided or supported or authorized or\ngranted or otherwise associated by or with GLEIF.\n\n4, You further agree to refrain from any actions or statements which may mislead the public\nand/or your customers to believe that any products or services provided by you, except\nthe services provided in accordance with Appendix 5 —Qualified vLEI Issuer Service Level\nAgreement (SLA), are services or products of GLEIF, or that you are part of, or in a special\nrelationship to, GLEIF and/or the GLEIS.\n\n5. You agree that GLEIF may take any appropriate steps, including but not limited to court\naction and to preliminary injunctions, if you do not comply with these Terms of Use, and\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 3 of 4\n\nVLEI Issuer Qualification Agreement Appendix 6 Qualified vLEI\n\nTrustMark Terms of Use\n\nPublic Document Version 1.0\nGLEIF 2022-12-06_appendix-6-terms-of-use-qualified-vlei-issuer-trustmark_ 2022-12-06\n\nv1.0_final.docx\n","contentLength":2638,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:25:06.163Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-6-terms-of-use-qualified-vlei-issuer-trustmark_v1.0_final.pdf","content":"that you are liable to a payment of liquidated damages in the amount of CHF\n100'000.- for any single case of non-compliance.\nlll. Applicable Law and Jurisdiction\n1. These Terms of Use shall in all respects be governed by, and construed and interpreted in\naccordance with, the substantive laws of Switzerland without regard to Switzerland's\nconflict of law rules.\n2. The Parties submit to the exclusive jurisdiction of the competent courts in Basel,\nSwitzerland, for all disputes arising out of, or in connection with, these Terms of Use.\n%k %k k\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 4 of 4\nVLEI Issuer Qualification Agreement Appendix 6 Qualified vLEI\nTrustMark Terms of Use\nPublic Document Version 1.0\nGLEIF 2022-12-06_appendix-6-terms-of-use-qualified-vlei-issuer-trustmark_ 2022-12-06\nv1.0_final.docx\n","contentLength":830,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:25:06.163Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-7-qualified-vlei-issuer-legal-entity-contract-terms_v1.0_final.pdf","content":"@, Protecting digital rust\nverifiable LEI (vLEI)\nEcosystem Governance Framework v1.0\nVLEI Issuer Qualification Agreement\nAppendix 7 Qualified vLEl Issuer — Legal Entity\nRequired Contract Terms\nPublic\n<..; | L \"IN\n* o S E = ('-.. ('3 I\n2 'e = % i ” ERere . o | o\n+ el -?\\f\"/{’ g e\no.‘. .0 4 ,‘ .{‘ A ® o.‘O » . 5 '\ni\n3\n.\n","contentLength":320,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:25:27.329Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-7-qualified-vlei-issuer-legal-entity-contract-terms_v1.0_final.pdf","content":"Each contract between the Qualified vLEI Issuer and a Legal Entity shall include provisions at least\n\nregarding:\n\n1. the contract remains in force until terminated by either the Legal Entity or the Qualified vLEI\nIssuer, according to the terms of the contract;\n\n2. termination, which shall be possible in the event of (i) the Legal Entity ceases to exist or\noperate, and the LE| of the Legal Entity is retired, (ii) the LEI of the Legal Entity lapses due to\nnon-compliance of the Legal Entity subject to requirements established by GLEIF to renew its\nLEl and validate its LEl reference data;\n\n3. termination with immediate effect for cause in the event of severe or repeated violation of\ncontractual duties, for which no cure is possible, or cure has been refused despite a\nreasonable cure period;\n\n4, a Legal Entity may terminate its agreement with a Qualified vLEI Issuer and contract with a\nnew Qualified vLEI Issuer at any time in accordance with the terms of their contract with the\nQualified VvLEl Issuer;\n\n5. termination with immediate effect by the Qualified vLEl Issuer, and without any liability of\nthe Qualified vLEI Issuer for any damages caused by such termination, in the event that the\nvLEI Issuer Qualification Agreement of the Qualified vLEI Issuer with GLEIF is terminated;\n\n6. contractual language to be observed for any formal notices;\n\n7. applicability of the Qualified vLEl Issuer’s fee schedule and obligations for the Legal Entity to\nmake payment for services outlined in the fee schedule of the Qualified vLEI Issuer;\n\n8. the provision that the Qualified vLEI Issuer may review its fee schedule annually and\nunilaterally determine new fees;\n\n9. a statement that the Qualified vLEl Issuer must not charge Legal Entities for the re-issuance\nof credentials resulting from key compromise recovery by the Qualified vLEI Issuer;\n\n10. the Legal Entity is required to request revocation of the Legal Entity vLEI Credential issued by\nits former Qualified vLEl Issuer (which will cause in all chained vLEI Role Credentials to fail\nverification for signings made after the revocation of the Legal Entity vLEIl Credential) once\nthe Legal Entity received its Legal Entity vLEI Credential and newly issued vLEI Role\nCredentials from its Qualified vLEl Issuer;\n\n11. obligation of the Legal Entity to supply true, full, and authentic information;\n\n12. awareness of the Legal Entity that only one single LEI may be requested for a Legal Entity and\nsubsequently be used to issue its Legal Entity vLEI Credential, i.e., prohibition to request a\nsecond LEI at either the same LEI Issuer or any other local operating unit (LOU);\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 2 of 4\n\nVLEI Issuer Qualification Agreement Appendix 7 Qualified vLEI\n\nIssuer — Legal Entity Required Contract Terms\n\nPublic Document Version 1.0\nGLEIF 2022-12-06_appendix-7-qualified-vlei-issuer-legal-entity-contract-terms 2022-12-06\n\n_v1.0_final\n","contentLength":2945,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:25:27.329Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-7-qualified-vlei-issuer-legal-entity-contract-terms_v1.0_final.pdf","content":"13. obligation of the Legal Entity to review the LEIl reference data of its LEI and to verify its\naccuracy, in accordance with the requirements for LEIl renewal, specifically, the Legal Entity’s\nLElI must maintain a LEI Entity Status of Active, and a LEI Registration Status of Issued,\nPending Transfer or Pending Archival in the Global LEI System;\n\n14. obligation of the Legal Entity to submit promptly any changes regarding any aspect having an\nactual or potential influence on the LEI and/or its reference data;\n\n15. reference to the Qualified vLEI Issuer’s communication policy regarding the maintenance of\nthe Legal Entity vLEI Credential of the Legal Entity;\n\n16. Legal Entity Official Organizational Role VLEI Credentials may be issued by the Qualified vLElI\nIssuer with which the Legal Entity has contracted to issue its Legal Entity vLEI Credential;\n\n17. attestation of the authority of the Designated Authorized Representative(s) executing the\ncontract on behalf of the Legal Entity;\n\n18. prior to the issuance of any Legal Entity Official Organizational Role vLEI Credentials, that a\nDesignated Authorized Representative (DAR) of the Legal Entity must designate Legal Entity\nAuthorized Representatives (LARS) that have the authority to request the issuance and\nrevocation of the Legal Entity vLEI Credential and the Legal Entity Official Organizational Role\nVLEI Credentials. The DAR of the Legal Entity also will be required to designate and maintain\nat least three (3) LARs, except in the case of a sole proprietor with less than two employees;\n\n19. data regarding issuance and revocation of Legal Entity vLEI Credentials and Legal Entity\nOfficial Organizational Role vLEI Credentials shall be sent to GLEIF by the Qualified vLEI Issuer\nfor publication on the LEI page of the Legal Entity on gleif.org and for monitoring credential\nregistry service levels;\n\n20. the LAR(s) of the Legal Entity is required to issue a QVI AUTH vLEI Credential for the issuance\nof each OOR vLEI Credentials (and ECR vLEI Credentials, if the Legal Entity has contracted\nwith the QVI for the issuance of ECR vLEI Credentials). The terms of the QVI AUTH vLEI\nCredential include confirmation that the Legal Entity has obtained consent from an Official\nOrganizational Role Person (OOR Person) for their name and OOR to be published on the on\nthe LEI page of the Legal Entity on gleif.org. The Legal Entity ECR vLEI Credential MAY be\nissued upon receipt by the QVI of a QVI AUTH vLEI Credential for the issuance of a ECR VvLElI\nCredential from the LAR(s) of the Legal Entity using the GLEIF-supplied vLEl software.\n\n21. the LAR(s) of the Legal Entity is required to revoke the QVI AUTH vLEI Credentials issued to\nauthorize each OOR vLEI Credentials (and ECR vLEI Credentials, if the Legal Entity has\ncontracted with the QVI for the issuance of ECR vLEI Credentials) to direct the QVI to revoke\nOOR VLEI Credentials (and ECR vLEI Credentials);\n\n22. notice to the Legal Entity that GLEIF reserves the right to coordinate with the Legal Entity’s\nDAR(s) should the Qualification Agreement between the Qualified vLEI Issuer and GLEIF be\nterminated, which includes the requirement for the Legal Entity to contract with a new\nQualified vLEI Issuer to ensure continued use of vLEI Credentials;\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 3 of 4\nvLEl Issuer Qualification Agreement Appendix 7 Qualified vLEI\nIssuer — Legal Entity Required Contract Terms\nPublic Document Version 1.0\n@ 2022-12-06_appendix-7-qualified-vlei-issuer-legal-entity-contract-terms 2022-12-06\nv1.0 final\n","contentLength":3576,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:25:27.329Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-7-qualified-vlei-issuer-legal-entity-contract-terms_v1.0_final.pdf","content":"23. to support the above coordination, a requirement for the Legal Entity email address contact\ndetails for its current DAR(s) to be forwarded to GLEIF by the Qualified vLEI Issuer;\n\n24. the Qualified vLEI Issuer is prohibited from transferring on its own initiative the Legal Entity’s\nLegal Entity vLEI Credential and the Legal Entity Official Organization Role vLEI Credentials to\nany other Qualified vLEl Issuer;\n\n25. must include confirmation that the Legal Entity will respect and comply with data protection\nlegislation as applicable and in force;\n\n26. the transfer of rights (see Chapter IX Intellectual Property of the vLEl Issuer Qualification\nAgreement) from the Legal Entity, its DARs, LARs, and any other persons, relating to any data\nbecoming part of the Legal Entity vLEI Credential and the vLEI Role Credentials, to the\nQualified VvLEl Issuer;\n\n27. exclusive place of jurisdiction (only under exceptional circumstances being somewhere else\nthan the legal residence of the Qualified VLEI Issuer);\n\n28. exclusive court competence either of the ordinary courts at the place of jurisdiction or an\nacknowledged and trusted arbitration court.\n\nverifiable LEI (vLEI) Ecosystem Governance Framework v1.0 Page 4 of 4\n\nVLEI Issuer Qualification Agreement Appendix 7 Qualified vLEI\n\nIssuer — Legal Entity Required Contract Terms\n\nPublic Document Version 1.0\nGLEIF 2022-12-06_appendix-7-qualified-vlei-issuer-legal-entity-contract-terms 2022-12-06\n\n_v1.0_final\n","contentLength":1464,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:25:27.329Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-06-09_gleif_ceviant_kyc_onboarding_v1.0_approved_final.pdf","content":"@’ Protecing digta rust\nCeviant on the Power of the LEI in KYC & Customer Onboarding\nIntroducing Ceviant\nCeviant is a UK-based financial technology company that delivers a broad range of\ntreasury and trade solutions to our large and diversified client base, including\ncorporates & multinationals, SMEs, importers, and exporters. Our goal is to provide\ntreasurers with a unified view that encompasses their bank account data, payment\nrequirements and trade finance functions. Ceviant gives them the tools to help\nmanage their financial resources, all from one portal.\nWe capture LEls as part of our KYC documentation and, as a Registration Agent in the\nGlobal LEI System, we can help our clients access the network of LEl Issuers, if they do\nnot yet have an LEI.\nThe Challenge\nAll our clients must pass through standard client onboarding procedures before we can\noffer them financial products. Our Know Your Customer (KYC) process - a key part of\nthese procedures - requires a level of due diligence determined by a combination of\nthe client's risk profile and that of the product(s) being offered. Our client onboarding\nis strictly digital and automated.\nClient onboarding times vary depending on the client and the product. If clients have\nall documents at hand, it may take them 30 minutes to complete. For large corporates\nor offshore clients, however, it can take us up to 48 hours to complete the required\ndocumentation review. Nonetheless, this automated, digital KYC processing and\nonboarding is much faster than traditional, manual processing.\nIt is often difficult to find an up to date and verified source of company and/or\nindividual data, especially relative to emerging markets, which is our key focus. This\nmakes automated onboarding especially difficult, as we rely on up to date, accurate\ndata to eliminate the need for manual checks. 75% of our customers are multinational\ncorporates who do business globally, and they often run into KYC related issues when\nacquiring new businesses in these markets. The LEI presents a ready-made solution to\nthis problem.\nThe core of this challenge is that we require several data points for each client, and\nthese points are not available from a single source. Complexity is also a major\nchallenge. Identifying the beneficial ownership of the legal entity, for example, can be\nboth difficult and time consuming. The job of identifying organizational structures,\nwhich can be inclusive of complex ownership hierarchies, for example, can also be a\nsignificant drain on resources.\n","contentLength":2531,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:25:36.413Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-06-09_gleif_ceviant_kyc_onboarding_v1.0_approved_final.pdf","content":"@’ Erotactng dighal st\nThe Power of the LEI\nAlready, the LEI plays an important role in demonstrating an entity can be trusted. For\nexample, when Ceviant worked with a Nigeria based entity, it was able to supply its LEI\nwhich offered a level of trust and confidence rarely seen in the region.\nCeviant recognizes that industry-wide use of the LEI can bring maximal benefits in KYC\nand client onboarding processes, but this can only be achieved if regulators mandate\nits use. Without such a mandate, no financial institution will want to take the first step\nto require the LEI for its clients.\nFuture value at Ceviant\nWe strongly advocate use of the LEI, as it helps to optimize KYC processing by\nproviding greater transparency and access to detailed identifying data. This\ncommitment to delivering increasing detail and transparency has recently been\ndemonstrated through the mapping of the LEI to the OpenCorporates database. As\nwe facilitate cross border activities as well as trade finance activities, the Global LEI\nSystem is a foundational starting point with the globally unique identifier and open\ndata.\nThe LEI will also save a significant amount of processing time especially when deployed\nin holding company structures. We estimate that we could easily save 25% of the time\nrequired to onboard a client simply by structuring the information via the holding\ncompany, with all related companies having an LEI. As the LEI becomes more\nwidespread, the time saving capabilities offered by the LEl are only set to increase.\nUltimately, we believe the LEI should be mandated for all businesses when they are\nincorporated. Alongside this, networks for payments transactions, such as SWIFT,\nshould require all entities to have an LEI and reference the LEIl in their network\ntransactions to ensure LEl use is spread even more broadly across the world.\nWidespread use of the LEI, supported by a regulatory mandate, will help Ceviant\nonboard clients in a more efficient manner, improve overall KYC and client onboarding\nprocesses, and improve the overall client experience.\nO Y jn BLOG NEWSLETTER\n","contentLength":2095,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:25:36.413Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-06-28_moodys_kyc-onboarding_gleif_v1.0_approved_final.pdf","content":"O:GLEIF’ Protecing digta rust\nMoody's Analytics on the power of the LEl in KYC and corporate\nonboarding\nThe challenge\nThe majority of Moody's Analytics KYC customers choose our global business\nverification and know your business (KYB) solutions to manage ongoing risk and anti-\nmoney-laundering (AML) compliance. Our leading data, advanced APIs, and\ncollaborative web-based tools provide the insight, efficiency, and automation needed\nfor audit-proof compliance. Using our solutions, customers can connect to the latest,\nmost accurate official data sources to understand risks and can make decisions with\nconfidence about whom they work with.\nA core challenge for customers is to efficiently access the data they need for robust\ndue diligence and ongoing risk monitoring - therefore we bring this together for them\nfrom disparate sources. Connectivity to business registries, for example, varies greatly\nfrom jurisdiction to jurisdiction. In some countries automated access is supported by\nthe register. In others, data can only be retrieved via a user interface. The data\navailability itself also varies significantly. Some commercial registers offer access to\nfully structured and rich datasets, whereas others only make limited sets of data points\navailable in an unstructured way within documents.\nThese variations shine a light on the inherent complexity of providing the data needed\nfor entity verification and onboarding, together with the importance of accessing\naccurate, up-to-date, risk-relevant information.\nIn a typical onboarding process, customers search Moody's Analytics databases and\nreal-time access network for relevant information and data on an entity, analyze it\nand then make a decision about onboarding. To assist this process, customers can set\nrules based on the information they retrieve, which provides further refinement on risk\nindicators to complete a profile.\nOur customers report that onboarding times for corporate customers significantly\ndiffers based on the information that needs to be collected. If it is a basic merchant,\nonboarding could take just a few minutes. For larger customers or suppliers who, for\nexample, may have complex ownership hierarchies, onboarding can be more\nprotracted.\nToday, Moody’s Analytics KYC uses the LEl in its real-time entity verification service for\ncertain use cases. Where the LEl is assessed, customers are also typically keen to see if\nan onboarding entity’s LEI renewal date is updated, so it can be factored into their risk\nassessments. We offer customers the ability to search the Global LEI Index and if the\n","contentLength":2588,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:25:47.469Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-06-28_moodys_kyc-onboarding_gleif_v1.0_approved_final.pdf","content":"@’ Protecing digta rust\nentity has an LElI we ensure it is added to our reference table. Since not all entities\nhave an LEl its use as a global identifier system is currently limited.\n\nThe power of the LEI\n\nResearch conducted by McKinsey on behalf of GLEIF has concluded that broader\nadoption of LEls could save the global banking sector between 2 billion and 4 billion\nUSD annually in onboarding costs. This represents a saving of between 5 percent and\n10 percent of the industry’s overall spend of more than 40 billion USD on the practice.\nIf all entities had LEls, compliance checks would be easier. Today, most of the KYC\nonboarding process is based on entity names, which is liable to human error and\nmisrepresentation and relies on the understanding of different languages and\ncharacter sets. This would be solved if entities had a standardized, alpha-numeric,\nmachine-readable LEI code that links to their corresponding record in the Global LE|\nIndex.\n\nFuture value from Moody's Analytics KYC solutions\n\nSo-called \"perpetual KYC\" or pKYC is the key to ensuring onboarding data and risk\nprofiles are kept up-to-date. If the LEI were mandated consistently across jurisdictions\nin onboarding and risk monitoring processes, it could play a pivotal role in automating\nthe KYC industry - saving time and money for all stakeholders, including financial\ninstitutions, supply chain organizations, large corporates, and other regulated firms.\nThe LEI would provide significant efficiency gains when onboarding complex\nmultinational companies since their ownership hierarchies are trackable via the Global\nLEI Index. This especially holds true for offshore entities for whom real-time access to\ndata via business registries is not available in all jurisdictions, meaning it can take\nweeks to obtain the necessary entity information.\n\nMoody’s Analytics acknowledges that ISO20022 is an important development for the\nfuture of payments and is already structuring its data into the appropriate format.\nHere, the mandated use of the LEI in ISO20022 payments messaging would greatly\nincrease efficiency, help with sanctions screening, and improve correspondent banking\nrelationships.\n\nMoody’s Analytics follows the development of AML regulations closely and supports\nthe EU's AML regulatory proposal to include the LEI Therefore, the LEI is a significant\npart of our product strategy. We also support broader use of the LElI and LEI reference\ndataq, as it has the potential to increase efficiencies and straight-through-processing\nacross other use cases in the financial sector and beyond.\n","contentLength":2581,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:25:47.469Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-06-28_moodys_kyc-onboarding_gleif_v1.0_approved_final.pdf","content":"@’ Protecing digta rust\n“Moody’s Analytics recognizes the value the LEI can provide, if included in ISO20022\npayment messaging as a mandatory data element and therefore fully supports this.” -\nJohanna Konrad, Managing Director, Kompany, Moody’s Analytics.\nAbout Moody's\nMoody's is a global integrated risk assessment firm that empowers organizations to\nmake better decisions. Moody's Analytics is a separate and independent entity from\nMoody’s Investors Service within the Moody’s organization. Moody’s data, analytical\nsolutions and insights help decision-makers identify opportunities and manage the risks\nof doing business with others. Moody's believe that greater transparency, more\ninformed decisions, and fair access to information open the door to shared progress.\nWith over 13,000 employees in more than 40 countries, Moody's combines global\npresence with local expertise and over a century of experience in financial markets.\n© ¥ in BLG NEWSLETTER\n","contentLength":958,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:25:47.469Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-07-04_japan-eseal_gleif_v1.0_approved-final.pdf","content":"@’ Protecing digta rust\nBoosting Trust and Interoperability in Japan - EU Invoice\nReconciliation\nThe challenge\nThe need to harmonize cross-border trust services continues to grow in line with the\never-increasing volume of trade and commerce taking place across digital platforms,\nglobally.\nThe use of the eSeal - an electronic signature associated with a legal entity - is a popular\nmeans of confirming the authenticity of a digital document, like an e-invoice, shared\nbetween trading entities. Outside of the EU (where member states must comply with\nthe region's elDAS regulations), however, there is no international uniformity in eSeal\nformat or requirements. Consequently, there is no mutually recognized way for the\nrecipient of a sealed document to verify the authenticity of the sender’s identity beyond\nnational borders.\nThe value of the LEI\nTo address this problem, GLEIF has initiated a proof-of-concept (POC) to demonstrate\nhow embedding the sender's LEI within an eSeal used to digitally seal an e-invoice can\nbring significant international gains in both interoperability and counterparty trust. The\ninitiative was undertaken to support a Japanese consortium program which aims to\ndevelop entity-level trust services that are mutually recognizable by Japanese and\nEuropean organizations.\nThe POC enables the authenticity of both the e-invoice document (via the eSeal) and\nthe sending organization (via their LEl, embedded in the eSeal credential), to be\nconfirmed simultaneously, together with the exact time of the document's sealing. The\ninitiative shows how the process can be undertaken reciprocally, with the digitally sealed\ninvoice issued by a Japanese organization to a European organization and vice versa.\nThe authenticity of the LEl-embedded eSeal has been confirmed thanks to the\nrecognition by both regions of the underlying proof-of-concept trust framework.\nThrough this proof-of-concept we demonstrated the benefits the LEI can bring in\nhelping to establish an additional trust layer and the international interoperability of\ntrust services. The nature of the LEI, globally accepted and trusted ID, is critical because\nit will support the realization of Data Free Flow with Trust (DFFT) - a G20 endorsed\nguiding principle for international cooperation on data flows at G20 Osaka summit 2019.\nJapanese participants in the proof-of-concept, included: Hitachi, Ltd.; Secom Trust\nSystems Co., Ltd.; Seiko Solutions Co., Ltd.; Keio University; TEIKOKU DATABANK, LTD.\nEuropean-based participants included: GLEIF; InfoCert S.p.A; and Société\nInternationale de Télécommunications Aéronautique.\n","contentLength":2614,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:25:57.520Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-07-04_japan-eseal_gleif_v1.0_approved-final.pdf","content":":GLEIF’ Protectng dital st\nFollowing POC for the G7 Digital and Tech Minister’'s Meeting in Takasaki, Japan in\nApril 2023\nBased on the results of the POC implementation using the e-invoice as a use case, which\nwas implemented mainly by private companies, Professor Tezuka of Keio University and\nhis team conducted a POC with the EU Commission from January 2023.\nAt that time, it was implemented with the following contents as a business use case.\n« Exchange of carbon offset certificates / CO2 emissions data, certificates of origin\nbetween participants in the supply chain\n+ With these certificates or data issued under the form of sealed documents\nJapan side prepared the CFP (Carbon footprint) Mgmt. application, sample data, and\nAPI (API#1, #2) .\nE-Seal were generated and verified by both side (Japan and EU) in each environment\nand tools.\nE-sealed JSON data were exchanged by connector in data space.\nBut JSON raw data and e-Sealed data were transmitted to/from by the other method\n(ex. e-mail).\nJapan EU and Japan\nsupplier(Japan)\nCFP Mgmt. App @v::;::tzn @ CFP Mgmt. AP\nT NN o p— N\nAT & et\n—ff wes W29 Trust service Platform Data Space Trust Service Platform [R¥= Wes\n_ e\nDB Server Client JSON Data Server client pl:] JSON Data\nL B e | o B o [IEEAN Cc, | , I s\nTrust Service Platform Data Space — Trust Service Platform\nE-seal for CFP Req. Verify the E-seal and Transmission of CFP\ndata. Create CFP response. data\nThe result of the POC was showcased at the digital and tech exhibition which held at\nthe site of the G7 Digital and Tech Minister’'s Meeting in Takasaki, Japan in April 2023.\n","contentLength":1596,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:25:57.520Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-07-04_japan-eseal_gleif_v1.0_approved-final.pdf","content":"@’ Erotactng dighal st\nFuture outlook\nThe successful POC has now led to further exploration of the use of the LEI in the eSeal\nsystem in digital interactions between Japanese and European organizations.\nFor more information on this initiative, download the press release.\n© ¥ jn BLOG NewseTTER\n","contentLength":295,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:25:57.520Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-06-01_gleif_bloomberg_sanctions_screening_v1.0_bloomberg_approved_final.pdf","content":"@’ Protecing digta rust\nBloomberg on Using the LEI for Sanctions Screening\nContributers: Charles Gorman, Rohan Mishra - Bloomberg\nIntroducing Bloomberg\nBloomberg is a global leader in business and financial information, delivering trusted\ndata, news, and insights that bring transparency, efficiency, and fairness to markets.\nThe company helps connect influential communities across the global financial\necosystem via reliable technology solutions that enable our customers to make more\ninformed decisions and foster better collaboration.\nAs an accredited Local Operating Unit of the Global LEI System, Bloomberg has over\n180,000 LEls under its management. The firm is accredited to issue LEls for entities,\nincluding funds, in 228 jurisdictions, making it one of the most versatile LEI providers\nworldwide. Through its extensive corporate hierarchy database, Bloomberg identifies\nexplicitly stated sanctions as well as implicitly sanctioned entities and instruments.\nBloomberg's sanctions data provides the sanctioned status of tradable securities, legal\nentities, and certain public funds in a timely and consistent manner, enabling pre-trade\nscreening and post-trade compliance checks.\nThe Challenge\nSanctions Authorities publish lists of entities and natural persons to modify undesirable\nbehavior. However, these authorities do not always provide details on the business\nregistration ID, tax ID or other identifying information in their lists, making it difficult to\nvalidate targeted entities.\nThis is only part of the challenge. Financial institutions may also need to identify\nimpacted subsidiaries and securities that aren’t explicitly listed, in a timely manner.\nComplicating matters are scenarios where convertible bonds or other securities may\nbe impacted by sanctions even when the issuer isn’t.\nAs a result, data vendors like Bloomberg must complete a significant amount of\nresearch to establish relationships between companies and links to financial\ninstruments to understand the scope of sanctions.\nThe Power of the LEI\nGiven that name matching processes for sanctions are both arduous and time-\nconsuming, a significant opportunity exists to promote broader adoption of the LEI. An\nLEl is a unique 20-character alphanumeric code based on the ISO 17442 standard that\nis assigned to legal entities that are counterparties to financial transactions or\nsomehow are involved in the markets.\nLEls play an important role in understanding the counterparties engaged in a financial\ntransaction, which makes them very useful for sanctions compliance purposes; it means\n","contentLength":2576,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:26:07.061Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-06-01_gleif_bloomberg_sanctions_screening_v1.0_bloomberg_approved_final.pdf","content":"@’ Protecing digta rust\nthat transacting parties can be unambiguously identified, preventing the generation of\nfalse positives that may be created during name matching processes.\n\nWider adoption of LEIs could enhance identity-based screening systems, making\nsanctions compliance faster, more effective, and less expensive to administer for all\nstakeholders.\n\nTo correctly identify the legal entity affected by sanctions it would also be beneficial if\nSanctions Authorities could add the LEI, where applicable, to the legal entities subject\nto sanctions. This should also reduce the risk of false positives and add transparency.\nBy embracing an LEI-based system where legal entity identification can be\nunequivocally assured, in an open, interoperable, and instant digital format, all\nstakeholders would be able to transact with far greater confidence and efficiency.\nFuture value at Bloomberg\n\nBloomberg utilizes name matching engines to compile an initial list of companies\npotentially impacted by sanctions. Entity names not found as part of the initial\nscreening are manually reviewed against Bloomberg's database, and any entity that\nisn't already included in the database is then added.\n\nThe LEI opens the possibility to greatly streamline the entity identification process and\nallow for straight through processing. As a result, Bloomberg sees the value in\nsanctions authorities providing the LEI of sanctioned entities in their lists. The LEl is a\nunique and non-transferable validation point which would make the accurate\nidentification of sanctioned entities faster, cheaper, and simpler.\n\nThe LEI can also help identify subsidiaries that are impacted as part of a corporate\nhierarchy. And because the LEI dataset showcases the entity's country of operation, it\nwould also make it easier to tag entities in sanctioned countries and regions.\n\n“As an accredited issuer, we are proud to be a part of the global effort to adopt LEI/s.\nBy enhancing financial data quality and bringing more transparency and consistency to\nthe capital markets, LEIs are an important piece of the puzzle when it comes to\nscreening sanctions in an efficient, thorough manner.” - Steve Meizanis, Global Head\nof Symbology and LEI Services, Bloomberg\n\n© ¥ N BLOG NEWSLETTER\n","contentLength":2256,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:26:07.061Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-06-06_gleif_element-22_sanctions_screening_v1_approved_final.pdf","content":"@’ Protecing digta rust\nElement22 on the Power of the LEIl in Sanctions Screening\nIntroducing Element22\nElement22 provides data consultancy services and software solutions to financial\ninstitutions and the broader industry supply chain including rating agencies, exchanges,\nand data providers.\nThe Element22 team has extensive experience with LE|I codes and related entity data.\nIt helped to create the first active Local Operating Unit (LOU) in the Global LEI\nSystem, and also assisted in the development and advancement of the ISO 17442\nstandard for LEI. LEI codes and entity data from GLEIF feeds are embedded in\nElement22’'s ESGi software product, used for ESG data collection and reporting.\nThe Challenge\nTo combat fraud and other illicit transactions, publicly available sanctions and\nwatchlists are maintained by a variety of supervisory authorities around the world.\nThese lists typically comprise the names of persons and legal entities whose\ntransactions are deemed to warrant further investigation. In some cases sanctions are\napplied for all counterparties in an entire country or those who operate in an industry\nsector within a country.\nConfidently identifying the entities listed in sanctions lists is a major challenge for\nfinancial institutions, as most are published simply as lists of names and aliases. This\nlack of verified identifiers can make it very difficult for firms to identify the right\nindividual or entity. As these lists change regularly, often monthly, the tracking and\nreview overhead is substantial, requiring multiple steps and requiring close\ncoordination with external parties.\nCurrently, the compliance process requires financial institutions to match names only;\nlimiting its effectiveness. The current system of using keywords to search extensive\nentity and transaction databases creates ambiguity in the form of false positives and\nnear matches, each of which requires costly and inefficient manual investigation.\nThis is only part of our challenge. Financial institutions may also need a way to identify\nimpacted subsidiaries and securities that aren’t explicitly listed, in a timely manner. The\nlack of identification in sanction lists make it difficult to tie subsidiaries to their parent\ncompanies unless the subsidiary has a similar name. The process relies on firms running\ntheir own searches and having high quality and well-maintained parent-subsidiary links\nin place in their internal databases, which is often not the case.\nAs aresult, to identify relationships between companies and links to financial\ninstruments these organizations must complete a significant amount of manual\nresearch which can be costly, inefficient, and prone to human error.\n","contentLength":2701,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:26:18.184Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-06-06_gleif_element-22_sanctions_screening_v1_approved_final.pdf","content":"@’ Protecing digta rust\nThe Power of the LEI\nGiven that current sanctions compliance processes are both expensive and inefficient,\na significant opportunity exists to replace the name-based system with one based on\nidentity - the LEI - thereby making it faster, more effective, and less expensive to\nadminister for all stakeholders.\nLEls play an important role in understanding the counterparties engaged in a financial\ntransaction and are already well embedded across the industry, which makes them\nvery useful for sanctions compliance purposes; it means that transacting parties can\nbe unambiguously identified, greatly reducing the number of false positives that the\nmatching process generates today.\nBy embracing an LEI-based system where legal entity identification can be\nunequivocally assured, in an open, interoperable, and instant digital format, all\nstakeholders would be able to transact with far greater confidence and faith. Most\nimportantly, however, the opportunities for financial criminals to cheat the system will\nbe dramatically reduced on a global scale.\nFuture value at Element22\nThe LEI already greatly streamlines our entity identification process. As the LE|\nprovides unambiguous identification, it is particularly valuable for identifying ownership\nhierarchies (such as the overseas subsidiaries of sanctioned legal entities) and linked\ninstruments, as well as for generating new sector and geographic insights. As entity\ndata is siloed in many repositories across large financial institutions at present, the LEI\noffers the opportunity to connect across these silos, and then to sanctions lists.\nWe contend that sanctions authorities should provide the LEIs of sanctioned entities in\ntheir lists to make the accurate identification of sanctioned entities faster, cheaper,\nand simpler. But still there needs to be some driver that obliges sanctioned entities to\nbe issued with LEls. How can we fill this gap? We volunteer how the LEI could be\nimplemented across the financial ecosystem to fill this gap:\n1. Regulators: Require the LEI in all financial transactions, making it an obligatory\nelement when corporates engage in marketplaces or networks.\n2. Business registries: Provide all legal entities with an LEI at the point of\nregistration.\n3. Financial institutions: Incorporate the LEI into their standard customer\nonboarding practices.\n4. Networks, utilities, and other data service providers to utilize LElI data in their\noperations and services.\n\"ldedally, the LEI would be tagged to all named legal entities by the sanctioning\nauthorities and published alongside the names and aliases. This could be further\nenhanced by collecting valuable information back from the financial institutions, so\nthat where firms identify related parties (additional LEl's matching names, subsidiaries,\n","contentLength":2816,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:26:18.184Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-06-06_gleif_element-22_sanctions_screening_v1_approved_final.pdf","content":": GLEIF , Protectng dital st\nand parent companies), these could be fed back and added to the register, for the\nnetwork to benefit from. This would result in more efficient sanctions screening, better\nuse of public and private resources and greater accuracy in sanction monitoring and\nreporting.\" - Mark Davies, Partner, Element22\nO ¥ in BLOG NEWSLETTER\n","contentLength":354,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:26:18.184Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-06-5_gleif_lse_sanctions_screening_v1.0_approved_final.pdf","content":"@’ Protecing digta rust\nLondon Stock Exchange Group (LSEG) on the Power of the LEl in\nSanctions Screening\nIntroducing London Stock Exchange Group (LSEG)\nLondon Stock Exchange Group (LSEG) is a leading global financial markets\ninfrastructure and data provider that operates connected businesses to serve\ncustomers across the entire financial markets value chain. It owns the London Stock\nExchange (on which it is also listed), Refinitiv, LSEG Technology, FTSE Russell, and has\nmajority stakes in LCH and Tradeweb.\nThe LSE is also a GLEIF-accredited Local Operating Unit (LEI Issuer).\nThe Challenge\nTo combat fraud and other illicit transactions, publicly available sanctions and watch\nlists are maintained by a variety of supervisory authorities around the world. These lists\ntypically comprise the names of persons and legal entities whose transactions are\ndeemed to warrant further investigation.\nFinancial institutions responsible for enabling financial flows must ensure compliance\nwith these lists by checking, sometimes manually, that the names published do not\ncorrespond with the names displayed on the transactions they perform with clients.\nOur KYC team goes through the sanction screening process every time a new client\nmakes an International Securities Identification Number (ISIN) application (an ISIN can\nonly be allocated after the KYC of the applicant is completed). The KYC process needs\nto be efficient and swift in order to minimize delays, however, as a National Numbering\nAgency, LSEG must also be particularly vigilant that no fraud is being undertaken. As a\nresult, the current KYC process can last anywhere between two days and two weeks.\nCurrently, the LEIl is mapped to the entity after the KYC process is complete, meaning\nchanges in the LEI reference data do not feed into the ISIN updates as there are no\ncentralized feeds. The KYC team also does not utilize the ISIN to LEI mapping facility in\nits sanctions screening process.\nThere is room to streamline our processes and cross-check reference data with the\nISIN, SEDOL and LEI should we get the support from the regulators. This will also,\nultimately, benefit the client’s experience too. Given that the current processes are\nexpensive and inefficient, a significant opportunity exists to replace the current\nprocess with one based on the LEI as a key identifier, thereby making it faster, more\neffective, and less expensive to administer for all stakeholders.\nThe Power of the LEI\nThe LEl is an international standard; a unique identifier linked to a legal identity and\nissued by an accredited organization. This means that when it is used in financial flows,\ncompliance verification can be based on actual identities instead of just names. In\nreference to sanctions and watch lists, this means that transacting parties can be\n","contentLength":2810,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:26:28.036Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-06-5_gleif_lse_sanctions_screening_v1.0_approved_final.pdf","content":"@’ Protecing digta rust\nunambiguously identified, greatly reducing the number of false positives that the\nmatching process generates today.\n\nBy embracing a system where legal entity identification can be unequivocally assured,\nin an open, interoperable, and instant digital format, all stakeholders will be able to\ntransact with far greater confidence and faith. Most importantly, however, the\nopportunities for financial criminals to cheat the system will be dramatically reduced\non a global scale.\n\nFuture value at London Stock Exchange Group (LSEG)\n\nAs the LSE is an LEl issuer, in the event a sanctioned entity is encountered, we can issue\nthat organization with an LEI, adding transparency to the market (under these\nconditions an ISIN cannot be applied). As LSEG's KYC team does not currently use ISIN\nto LEI mapping during the sanction screening process, there is an opportunity to\nstreamline KYC processes and offer greater transparency through the LEI. This would\nmean using the LEI earlier in the process to support ISIN applications, rather than\nassigning them after the application has been processed.\n\nMoreover, current sources of sanctions are difficult to understand. Using one single\nsource, the LEl, in sanctions publications would greatly simplify client identification and\nmake sure that an ISIN applicant is not under sanctions.\n\nMoving forward, a regulatory need for all issuers (ISIN requestor) to have an LEI, would\nmake It simpler, more efficient, and cost effective to combine both the LEI and ISIN\nallocation processes. Some examples are the EU Prospectus Regulation LEI\nrequirement for issuers or the Securities and Exchange Board of India introduction of\nthe LEI for issuers. If both the ISIN and LEI are mandated in sanctions listing and\nutilized in parallel, both KYC and sanction screening would be more efficient and\naccurate, as there would be one unique, reputable identifier for all parties involved.\n\n© ¥ in BLOG NEWSLETTER\n","contentLength":1961,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:26:28.037Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-06-08_moodys_sanctions_screening_gleif_v1.0_approved.pdf","content":"@’ Protecing digta rust\nMoody's on the Power of the LEI in Sanctions Screening\nIntroducing Moody's\nMoody's is a global integrated risk assessment firm that empowers organizations to\nmake better decisions. Moody's data, analytical solutions and insights help decision-\nmakers identify opportunities and manage the risks of doing business with others.\nMoody's believe that greater transparency, more informed decisions, and fair access\nto information open the door to shared progress. With over 13,000 employees in more\nthan 40 countries, Moody’s combines global presence with local expertise and over a\ncentury of experience in financial markets.\nThe Challenge\nIdentifying individuals and companies accurately is of critical importance when it\ncomes to sanction screening services. As a data vendor, we strive to offer the most\naccurate data and particularly to avoid incorrectly marking a company as sanctioned.\n‘Sanctions by extension' also pose a significant challenge, as this requires an accurate\nanalysis of the corporate structure of a sanctioned entity to ensure all elements of a\ncompany are sanctioned correctly.\nIn recent years, the unique and unambiguous identification of sanctioned parties has\nremained a major challenge. Publicly available sanctions and watch lists are\nmaintained by a variety of supervisory authorities around the world. These lists\ntypically comprise the names of persons and legal entities whose transactions are\ndeemed to warrant further investigation, however, sanctions authorities do not always\nprovide details on the business registration ID, tax ID or other identifying information\nin their lists.\nMarket volatility and an increase in sanctions activity resulting from geopolitical\ntensions are additional challenges that we data vendors currently face, and the onus is\non us to adapt very quickly, in line with changing circumstances. Today, political\nconflicts are creating black holes within sanctions screening regimes. As a result of this\ninternational inconsistency, data vendors now need to look for alternative data\nsources. The frequency of the updates to these data sources also plays an essential\nrole; updates to sanction lists on an annual or monthly basis are no longer sufficient\nand more frequent ‘delta’ updates are becoming ever more important.\nThe net result of these challenges is that a significant part of our sanctions screening\nprocess must be performed manually, consuming both time and resource capacity.\n","contentLength":2471,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:26:37.452Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-06-08_moodys_sanctions_screening_gleif_v1.0_approved.pdf","content":"@’ Protecing digta rust\nThe Power of the LEI\nAn opportunity exists to replace today's name-based list system with one based on\nidentity - the LEI. If all sanctions authorities were to add the LEI into their sanctions\nlists, it would immediately increase the utility of these lists and greatly facilitate the\nscreening process, removing ambiguity in entity identification and providing easy,\nmachine-readable access to verified data held in the entity’s LEI record. Moody'’s can\nmatch the LEI information based on its aggregated entity identity data, and useitina\nvariety of screening requirements, automatically disqualifying false-positive matches\nand enabling faster verification of true matches, together with the easy determination\nof the entity’s ownership hierarchy as well as providing additional sector and\ngeographic insights.\nAdding the LEIl in sanctions publications and integrating it into broader sanctions\necosystems could help improve back-end operations and drive new efficiencies in\ntransaction-based screening systems. The LEI can also help us to reduce false positive\nalerts and identify sanctioned entities more accurately and unambiguously.\nFuture value at Moody's\nFuture ISO 20022 implementation is a crucially important step for the industry and will\ngreatly impact the task of screening structured data. Adding the LEI in ISO 20022\npayment messages would be hugely beneficial in this regard. Moody's believes with the\ntransition to the ISO20022 payment messaging format, payment screening will\nbecome more important as there will be more fields to scan and match. The market will\nattempt to move to more perpetual monitoring and further standardization of data\nfields within 1ISO20022 messaging format can help to achieve this objective.\n“Moody’s support the inclusion of the LEI in ISO20022 payment messaging as a\nmandatory data element.” — Ted Datta, Senior Director - Head of Financial Crime\nCompliance Practice, Europe, Africa & Americas, Moody's Analytics\nBeyond ISO 20022, by embracing an LEI-based sanctions screening system where legal\nentity identification can be unequivocally assured, Moody's can mitigate the risk for\nour clients with better data accuracy and greater efficiency. For example, if Moody's\nclients tag suspicious activity with the LEI in their Suspicious Activity Reports (SARs), it\nwould be very beneficial both for our clients and for public authorities, enabling them\nto showcase their effectiveness in screening outcomes.\n© ¥ in BLOG NEWSLETTER\n","contentLength":2500,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:26:37.452Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-06-22_gleif_wmd_sanctions_screening_v1.0_final_approved.pdf","content":"@’ Erotactng dighal st\nWM Datenservice on the Opportunities of the LEI in Sanctions\nScreening\nIntroducing WM Datenservice\nWM Datenservice provides financial expertise with data solutions, integrated data and\ninformation along the entire process chain of securities. WM Datenservice offers\nsanctions services to support the enforcement of sanctions against Russia and plans to\nextend these services to other sanctioned jurisdictions soon.\nThe Challenge\nTo combat fraud and other illicit transactions, publicly available sanctions and watch\nlists are maintained by a variety of supervisory authorities around the world. These lists\ntypically comprise the names of persons and legal entities whose transactions are\ndeemed to warrant further investigation. Financial institutions responsible for enabling\nfinancial flows must ensure compliance with these lists by checking, sometimes\nmanually, that the names published do not correspond with the names displayed on\nthe transactions they perform with clients.\nIn recent years, unique and unambiguous identification of sanctioned parties has\nbecome a major challenge. In the delivery product (International Sanctions\nMonitoring), WM Datenservice currently uses ISIN and other additional Identifiers as\nwell as the LEI, where available. In the absence of a unique identifier in the sanctions\nlists provided by the authorities, WM Datenservice works with so-called name\nmatching. Widespread and mandated use of the LEl in existing sanctions lists would\nsimplify sanctioned entity tagging substantially. According to our estimates, it is\ncurrently possible to tag up to 15% of the sanctioned Russian issuers with the LELI If this\ntagging were done centrally by the authority, we would know with certainty the\nsanctioned issuers with the LEI.\nSanctions authorities do not provide details on the business registration ID, tax ID or\nother identifying information in their lists, making it difficult for us to accurately\nidentify these entities. This is especially difficult in regions where our database is less\ncomplete. In jurisdictions where we do not have direct business relationships (e.g. in\nLatin America), we do not have a complete overview of issuers.\nAdditional challenges we face include the identification of issuers and products in\nportfolios (e.g. Funds and structured Products) as well as identification of relevant\nrelationships and dependencies between entities. This is important because making\nclients aware of all relationships guarantees they will not accidentally invest in a\nsecurity of a sanctioned entity. The use of a consistent identifier such as the LEI would\nhelp resolve these issues.\n","contentLength":2654,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:26:46.765Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-06-22_gleif_wmd_sanctions_screening_v1.0_final_approved.pdf","content":"@’ Protecing digta rust\nThe net result of these challenges is that a significant part of our sanctions screening\nprocess must be performed manually, consuming both time and resource capacity.\nThe Opportunity of the LEI\nThe LEl is an international standard; a unique identifier linked to a legal identity and\nissued by an accredited organization. This means that when it is used in financial flows,\ncompliance verification can be based on actual identities instead of just names. For\nsanctions and watch lists, this means that transacting parties can be unambiguously\nidentified, greatly reducing the amount of time that the matching process takes\ntoday.\nBy embracing a system where legal entity identification can be unequivocally assured,\nin an open, interoperable, and instant digital format, all stakeholders will be able to\ntransact with far greater confidence and faith. Most importantly, however, the\nopportunities for financial criminals to cheat the system will be reduced significantly on\na global scale.\nFuture value at WM Datenservice\nAdding the LEI as a mandatory identifier in sanction lists would greatly accelerate our\nidentification of sanctioned entities. We believe that the LEI could be a good solution\nto this problem, due to the increasing number of sanctioned issuers and products and\nthe need to identify these sanctioned securities fast.\nIf the authorities mapped an LEI to every sanctioned legal entity, it would also greatly\nassist in the identification of related legal entities in ownership hierarchies and linked\ninstruments.\nIn an ideal sanctions screening world, the screening of free form names would evolve\ninto the screening of LEIs, creating huge cost and time efficiencies across the whole\nindustry as a result.\n© ¥ in BLOG NEWSLETTER\n","contentLength":1772,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:26:46.765Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/p070722.pdf","content":"FINANCIAL\nSTABILITY\nBOARD\nOptions to Improve Adoption of The LEI, in\nParticular for Use in Cross-border Payments\n,/\";,-f\":\" ;r. I\\‘ : - ™\"\no T L.\ngrie 4 »*\n/'y e\ni @\n/\nY ]\n,\"\\) o °\n5 '/?\\g .\\‘\\., !\n¥\nY\nel\nX \\\\\\\\“ /\n§ \\\\ \\ “ ;\\\\\"\"m\\\\ \\‘ .‘\\\\\n1 S ~QE{, L\neSS\n7 July 2022 S = F\n","contentLength":275,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:28:12.427Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/p070722.pdf","content":"The Financial Stability Board (FSB) coordinates at the international level the work of national\nfinancial authorities and international standard-setting bodies in order to develop and promote\nthe implementation of effective regulatory, supervisory and other financial sector policies. Its\nmandate is set out in the FSB Charter, which governs the policymaking and related activities of\nthe FSB. These activities, including any decisions reached in their context, shall not be binding\nor give rise to any legal rights or obligations.\nContact the Financial Stability Board\nSign up for e-mail alerts: www.fsb.org/emailalert\nFollow the FSB on Twitter: @FinStbBoard\nE-mail the FSB at: fsb@fsb.org\nCopyright © 2022 Financial Stability Board. Please refer to the terms and conditions\n","contentLength":776,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:28:12.427Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/p070722.pdf","content":"= Improving data quality to avoid legal risks for the financial institutions which rely on that\ndata for KYC purposes. The extent to which organisations can rely on LEI data in KYC\nis a subject that raises compliance considerations, and responsibility for accuracy\ncannot simply be passed to the original data source. Financial institutions need to have\nconfidence in the information they acquire from an outside source;\n\nm Achieving reduced LEI fees by achieving economies of scale via expanded roll-out;\n\nm Reducing complexity of retrieving and verifying information. For example, suggestions\nto develop an application programming interface (API) to facilitate the implementation of\nautomated queries came from respondents both from the public and private sector.\nAccess to identifiers should be easily scalable and imply low costs and administrative\neffort. Another participant suggested including the LEI within decentralised ID systems\nwhose use is encouraged by the EU; and\n\nm Increasing knowledge about the LElI among cross-border industry players to help raise\nawareness of potential benefits.\n\nThe solutions envisaged by the private sector mirror the challenges identified. Those include:\n\n= Allowing for the interoperability of identifiers and coupling adoption of the LEI with ISO\n20022 implementation to enhance cross-border payments;\n\nm Introducing more verifiable versions, strong forms of authentication, and tiered\nassurance levels, as well as educating corporates about the security that using the LEI\nadds to cross-border payments, since firms support mechanisms to reinforce the\nsecurity of payments;\n\nm Developing compelling use cases beyond payments that can add value to businesses,\nsuch as the LEI’s original function as a tool to aid firms in tracking and managing their\nexposures or the use for e-invoicing; and\n\n= Working with legal authorities to clarify the legal scope of using LEI for KYC procedures.\n\nFinally, in the context of the work of BB6 of the roadmap, which seeks to assess frictions to\ncross-border payments arising from data frameworks, some private sector respondents to the\npublic outreach conducted by the FSB highlighted the importance of having a unique global\nidentifier for legal entities, such as the LEI, in cross-border payment transactions to address data\nsharing issues.\n\n1.3. GLEIF survey\n\n= Inasurvey conducted by GLEIF among business partners and LOUs, respondents also\nstressed how the LEI for payments’ originators and ultimate beneficiaries would provide\nbenefits to due diligence activities. By facilitating and accelerating the matching of\naccount holder and account number as well as the sanctions checks of payments’\noriginator or beneficiary, the LEI would make due diligence activities quicker and more\n\n7\n","contentLength":2773,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:28:12.427Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/p070722.pdf","content":"efficient and ultimately enhance the safety of payments.'® Some respondents suggested\nthat initial costs of introducing the LEIl in cross-border payments (such as costs to\nintroduce the LEI as a new field in payments messages, to include the LEI in databases,\nto clarify payment processing practices whenever the LEI would not be provided or\nincorrect) would be outweighed by the savings in due diligence activities and enhanced\ntrade competition.'” Some organizations highlighted that there is an opportunity for wider\nadoption of the LEI with the migration to the 1SO20022 messaging standard, bringing\nfundamental changes to the legacy systems of the financial institutions. Some\nrespondents emphasized that the LEI can play a positive role in reducing de-risking by\nproviding a credible global identity to the entities, particularly small and medium-sized\nenterprises (SMEs) or non-profit organisations in developing countries or conflict zones,\nwhich are excluded from payments and financial transactions due to increasingly\nstringent KYC/AML requirements. One organization confirmed that validation of client\nidentity in international payments will likely be faster with the LEI. Currently without a\nform of global legal entity identifier, some transactions, particularly for new players, may\ntake up to 14 days to complete due to compliance checks.\n= When surveyed by the GLEIF about the role they could play to support broader LEI\nadoption, one LEI issuing institution mentioned that it could enhance the outreach to its\ncorporate clients by offering training on the benefits of the LEl. Two other respondents\nrecommended that banks get an LEIl for any new corporate client and arrange for\nrenewals. One respondent mentioned that the LEI could provide benefits in free trade\nareas, such as the African Continental Free Trade Area (AfCFTA) or the Association of\nSoutheast Asian Nations Free Trade Area (AFTA), to enhance the overall cross-border\nexchange of goods, both to simplify customs procedures as well as to facilitate the\nconnected cross-border payments. Finally, another respondent suggested that software\nthat requires an LEI in order to access and execute transactions could provide an\nincentive for entities involved in cross-border payments to adopt an LEI. Finally, another\nrespondent urged that FATF recommendations, in particular recommendations 16 and\n10, provide options on how to identify a company, presenting the LEIl as a potential\nsolution.\n2. Rationale for the LEI and recent progress\nIn 2011 G20 Leaders supported \"the creation of a global legal entity identifier (LEI) which\nuniquely identifies parties to financial transactions” and mandated the FSB to “prepare\nrecommendations for the appropriate governance framework, representing the public interest,\nfor such a global LEI\".\"8\n16 Organisations responding to the GLEIF survey also mentioned that the LEI could be used to provide globally accepted credit\nscoring profiles: in this way small businesses that currently do not engage in international trade due to the lack of a globally\naccepted risk profile could be facilitated in competing with large players, creating a more level playing field.\n7 The respondents noted that the LEI has the potential to improve the efficiency and lower the cost of vendor vetting, electronic\ncontract signing and supply chain automation, thus facilitating the digitalisation of cross-border trading and associated payments.\n18 520 2011 Cannes Summit Final Declaration. The absence of a system that uniquely identified parties to financial transactions\nwas considered an obstacle to a number of financial stability objectives such as the improvement of risk management in firms,\nbetter assessment of micro and macroprudential risks, facilitation of orderly resolution, containing market abuse, curbing financial\nfraud and enabling higher quality and accuracy of financial data overall. Already in the aftermath of the 2008-09 financial crisis\n8\n","contentLength":3963,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:28:12.427Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/p070722.pdf","content":"The LEI federated system has been in operation since 2012. The not-for-profit Global LEI\nFoundation (GLEIF) was created as the central operating unit, directly overseen by the\nRegulatory Oversight Committee (ROC), and a variety of organisations have been accredited by\nthe GLEIF as LEIl issuing organisations. As of end of first quarter 2022, 38 LEI issuing\norganisations are serving 226 jurisdictions.'® LEI| issuing organisations can be any type of\norganisation. For example, LEIl issuers are also stock exchanges, numbering agencies,?®\ncertification authorities,?! national statistical offices, business registries, etc. The majority serve\nmultiple jurisdictions?? and are accredited to provide an LEI to a variety of legal entity types.?®\nBox 1 briefly summarises the main characteristics of the LEI.\nBox 1: Legal Entity Identifier\nThe LEI is a 20-character reference code, based on a standard of the International Organisation for\nStandardisation (ISO 17442), that uniquely and exclusively identifies legally distinct entities. An LEl is\nassigned uniquely to an entity; the same code cannot be reassigned to another entity. Once a legal\nentity has obtained an LEI it cannot obtain another one.\nThe LEI is associated with core reference data, that provide primary information on the legal entity\n(Level 1 data) that respond to the question “Who is who?”:\nm The official name of the legal entity as recorded in the official registers.\nm The registered address.\n= The country of incorporation.\nm The legal form of the entity (its Entity Legal Form Code, ISO 20275:2017).\nm The date of the first LElI assignment; the date of last update of the LEI information; and the\ndate of expiry, if applicable.\nBesides that, an LEIl is connected to information on the relationships it has with other legal entities it is\nconnected to (Level 2 data), responding to the question “WWho owns whom?”. In particular, if the direct\nand/or ultimate parents of a legal entity with an LEI| have obtained an LEI, these are included in the\nLevel 2 data of the child entity. Likewise, the LEI of child entities — if available — is included in the\nreference data of their direct or ultimate parent’s LEI.\nIn order to enhance LEI| data quality, both ROC and GLEIF are constantly defining and\nimplementing various mechanisms as setting the obligation of annually reviewing the reference\ndata, adding enhancements to the LEI issuing process or making available for any person to\nsend a challenge to review the data associated to the LEI.\nit was recognised that a unique global system for legal entity identification “would reduce operational risks within firms by\nmitigating the need for tailored systems to reconcile the identification of entities and to support aggregation of risk positions and\nfinancial data, which impose substantial deadweight costs across the economy. It would also facilitate straight through\nprocessing”.\n19 See GLEIF's statistics available here.\n20 National numbering agencies in some jurisdictions are in charge of assigning ISIN (ISO 6166) codes for the identification of\nfinancial instruments.\n21 Certification authorities are entities that issue digital certificates.\n2 Only 6 LEI issuing organisations serve just one jurisdiction, whereas 50% of the LEI issuing organisations serve 16 or more\ncountries.\n2 g issuing organisations need a dedicated accreditation to provide LEIs to mutual funds devoid of legal personality.\n9\n","contentLength":3430,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:28:12.427Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/p070722.pdf","content":"2.1. Progress in LEI adoption\nThe number of active LEIs?* had reached 1.9 million at the end of January 2022, from 400,000\nin 2015 and 1.4 million in 2019 (+30%) (see Graph 1 upper panel). The European Union\ncontinues to be the jurisdiction with the highest number of active LEIls, with an increase of 26%\nsince the end of 2019 (see Graph 1 lower panel). A similar growth rate has been experienced\nby Brazil (+22%), Canada (+21%), Hong Kong (+28%), South Africa (+26%), the UK (+23%) and\nthe US. Jurisdictions with a limited number of active LEls in 2019 have experienced high growth\nrates in the past few years, such as China (+433%), India (+135%), Saudi Arabia (+77%) and\nTurkey (+109%).\nNumber of active LEls Graph 1\nTotal\n1,954,436\nLRR1I9 1,500,000\n491,458\n1,305,886\n1,000,000\n52,851\n500,000\n464,579\n1 | | | I | o\n2016 2017 2018 2019 2020 2021\nBy Jurisdiction\n500 1,000,000\n400 ® 800,000\n300 600,000\n200 400,000\n100 . ° ; 200,000\n] = ¥ :\n0 | @ |oml ® iwlmi o wli BN ® | ® ullil o | ® | o i ..H‘Ill III . |!|II| o\nAR AU BR CA CH CN EU HK ID IN JP KR RU SA SG TR UK US ZA Other\n0 Dec.19 I Dec20 M Dec.21 @ Increase 2019-2021 (lhs, in %)\nSource: GLEIF, GLEIF dashboard.\nInitially the use and adoption of the LElI was predominantly in the financial markets and for\nsecurities, mainly driven by regulatory requirements. In May 2019 the FSB LEIl Peer Review\nnoted that LEls identify reporting entities for close to 100% of the gross notional outstanding for\nover-the-counter (OTC) derivative trades and identify securities issuers for around 78% of the\noutstanding amount of debt and equity securities. However, LEl adoption was low outside\nsecurities and derivatives markets and uneven across jurisdictions, with several FSB\n24 An active LEl is an LEI whose entity status indicates that the legal entity is legally registered and operating (“Active”). If the legal\nentity is no longer registered or operating, its entity status will appear as “Inactive”. An LEI's entity status is “Inactive” if its\nregistration status is either “Merged” (no longer exists as an operating legal entity due to merger) or “Retired” (ceased operation\nfor reason other than merger).\n10\n","contentLength":2165,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:28:12.427Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/p070722.pdf","content":"jurisdictions — particularly in Asia and emerging market economies — not yet taking steps to\nmandate use of the LEI in any area, at that time.\n\nIn the meantime, regulatory use of the LE| has been expanded to other industries and business\ncases. Overall, since 2019 27 additional rules implementing the LEI have been issued.?® New\nregulations introduced the LEI into banking supervision (Australia and China), for credit rating\nagencies (China), in the insurance sector, corporate credit and non-derivatives sectors (India),\nfor asset management and market surveillance (in the EU), in securities markets (in China for\ncertain securities issuers, investors and in order to open a securities custody account) and\nsecuritisation (in the EU), for statistical purposes (in China for reporting loans and foreign assets\nand liabilities for statistical purposes) and for foreign exchange and physical trade (China). Some\ncountries have also issued a roadmap for the implementation of the LEI in the coming years,\nsuch as China (see Box 2 for its impact on cross-border payments). While the UK and the EU\nremain to be the jurisdictions with the highest number of regulations implementing the LEI (58\nand 44 respectively),?® the new regulations since 2019 have been introduced not only in the UK\n(+10) and the EU (+2), but also in the Asia-Pacific region, including China (+9), India (+3) and\nAustralia (+1).\n\nA few more regulations are currently under consultation or discussion that in future may increase\nthe number of LEls:\n\nm The US Bureau of Consumer Financial Protection is currently proposing that financial\ninstitutions providing credit to small businesses?’ be required to report data on credit\napplications, including a unique alphanumeric identifier composed of their LElI and a\nunique code internally assigned to the credit extension.?®\n\n= Also in the US the Financial Transparency Act (FTA), currently under discussion in\nCongress,?° proposes to amend securities, commodities, and banking laws to make the\ninformation reported to financial regulatory agencies electronically searchable, to further\nenable the development of RegTech and artificial intelligence applications, and reduce\nthe private sector's regulatory compliance burden, while enhancing transparency and\naccountability. To these ends, the FTA proposes to require the adoption of an open,\nnon-proprietary legal entity identifier — such as the LEIl — across the major financial\nregulatory reporting regimes, to allow easy matching of filings from the same legal entity\nwith multiple regulators.\n\nm The European Systemic Risk Board (ESRB) recommended in December 2020 to the\nEuropean Commission (EC) to consider introducing a union-wide legal framework\ngoverning the identification of legal entities involved in financial transactions by way of\nan LEI, to require legal entities to identify themselves with an LElI when reporting\nfinancial information and to require authorities to identify with the LEI any legal entity\n\n25 see ROC, Regulatory uses of the LEI.\n26 33 EU regulations have been preliminarily considered on-shored by the UK. All the EU on-shored regulations that were in force\n\nin the EU in 2019 were considered also UK LEI regulations in 2019.\n\n2T The Equal Credit Opportunity Act regulates financial institutions providing credit to small businesses, pursuant to section 1071\nof the Dodd-Frank Act.\n28 CFPB 2021 Small Business Lending Data Collection under the Equal Credit Opportunity Act.\n2% Ppassed by the House of Representatives on the 25 October 2021, the FTA will be discussed by the Senate in 2022.\n11\n","contentLength":3594,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:28:12.427Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/p070722.pdf","content":"about which they publicly disclose information and which has an LEI.3° By June 2023,\nthe EC is requested to deliver a report on the implementation of this recommendation.\nThe ESRB has also recommended that, in the meantime, relevant national and\nEuropean authorities — to the extent permitted by law and subject to the principle of\nproportionality — require an LEl from legal entities that are involved in financial\ntransactions under the authorities’ supervisory remit or are subject to reporting\nobligations or public disclosure. In response to this second ESRB recommendation, the\nEuropean Insurance and Occupational Pension Authority (EIOPA) revised at the end of\n2021 its Guidelines on the LEI and recommended that national competent authorities\nrequire a broader set of legal entities to have an LEL.3'\" The revised Guidelines also\nforesee that competent authorities include the LEI in the non-aggregated information\nthey report to EIOPA. EIOPA expects to include rules on the use of the LEI in reporting\nand disclosure requirements in a new or amended legislative act.®? The European\nBanking Authority (EBA) highlighted that it supports the introduction of an EU-level\nlegally binding requirement for the use of the LEIl. EBA also supports any effort in an\nextensive use of the LEl and expects an enhancement in the use of the LEI in areas\nsuch as payment related reporting.** The European Securities and Markets Authority, in\nturn, has suggested to the European Commission expanding the obligation to apply for\nthe LEI under the Alternative Investment Fund Managers Directive.3*\n\nm The European Commission added the LEI in its AML Regulation proposal. Reference to\nthe LEl is made in Article 18, which is titled ‘ldentification and Verification of the\nCustomer’s Identity’. The text makes clear that, where available, an LEl should be\nobtained by obliged entities, to identify a legal entity customer. In parallel to the AML\nRegulation proposal, the LElI has been added to the revised Transfer of Funds\nRegulation as a new requirement: “Complete information on the payer and the payee\nshould include the Legal Entity |dentifier (LEIl) when this information is provided by the\npayer to the payer’s service provider, since that would allow for better identification of\nthe parties involved in a transfer of funds and could easily be included in existing\npayment message formats such as the one developed by the International Organisation\nfor Standardisation for electronic data interchange between financial institutions”. The\nRevised Transfer of Funds Regulation is being discussed at the European Parliament\nat the time of writing of this report.\n\nm The European Parliament adopted the European Commission’s proposal regarding the\nMarkets in Crypto-assets (MiCA) Regulation in March 2022. In MiCA Regulation, there\nis an LEI requirement for the issuer of asset-referenced tokens and crypto-asset service\nproviders. MiCA Regulation is a good example of extending the LEI requirement to\nvirtual asset issuers and providers.\n\n30 ESRB 2020 Recommendation of the European Systemic Risk Board of 24 September 2020 on identifying legal entities.\n\n31 Not only insurance and reinsurance undertakings and Institutions for Occupational Retirement Provision should be required to\nhave an LEI, but also relevant branches and intermediaries operating cross-border.\n\n32 Some jurisdictions of the European Unions have also taken steps to introduce the LEI in the national business register. For\nexample, in Germany since July 2021 the LEI - if available - can be connected to newly established federal uniform business\nnumber assigned nationwide for firms in a federal business register.\n\n33 European Banking Authority’s (EBA) response to the European Systemic Risk Board’s (ESRB) first LE| Recommendation.\n\n34 See here.\n\n12\n","contentLength":3819,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:28:12.427Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/p070722.pdf","content":"3. Furthering the adoption of the LEI\n3.1. Potential benefits of greater LEI adoption for market participants and\nauthorities\nA globally unique identification system for legal entities may benefit market participants and\nauthorities in several ways, once it is broadly adopted.\nTransparency requirements for financial institutions to publish information with their own LEI\nmakes it easier for market participants, including investors, to retrieve the information and match\nit with other information in their own risk analysis. The use of the LEI could, as well, enhance\nbanks’ management of information across legal entities, facilitate a comprehensive assessment\nof risk exposures at the global consolidated level and improve the speed at which information is\navailable internally, especially after a merger or acquisition.3®\nAs suggested by the overview of LEI uses for authorities included in the 2018 ROC progress\nreport,*® global adoption of the LEI would also facilitate authorities’ ability to monitor financial\nrisks. Where the LEI does not exist, manual reconciliation and mapping efforts may be required\nto perform such financial stability oversight in domestic markets. Contagion risk analysis may be\nincomplete when assessing the stress from a particular counterparty in a given market if\nexposures are accidentally omitted because of incorrect counterparty identification.\nThe need to reconcile legal entities’ identities that are not uniquely identified at global level can\nslow down market surveillance and resolution of financial institutions. If the matching of\ntransactions involving the same legal entity is incomplete, abusive behaviours and market\nmanipulations could be undetected. Recordkeeping of financial contracts that do not include the\ncounterparty’s LEI can require significant efforts and resources in case of resolution, in particular\nin case of cross-border business with foreign counterparties. Finally, many authorities may face\nsignificant challenges in their statistical analysis and to map foreign subsidiaries of domestic\nentities if these entities and subsidiaries do not have an LEI.\n3.2. Obstacles to LEI adoption\nLEI adoption, whether driven either by regulatory requirements or by voluntary actions by the\nprivate sector, faces obstacles. Based on ROC and GLEIF analyses, the most relevant barriers\nto increasing the adoption are the fees for adoption and renewals and other costs, the existence\nof legacy technological systems relying on previously existing or local identifiers, a lack of clearly\narticulated benefits and use cases, and some quality issues concerning the LEI reference data,\nin part due to out-of-date data resulting from non-renewals (lapsed LEIs).\n35 See Basel Committee on Banking Supervision “Progress in adopting the Principles for effective risk data aggregation and risk\nreporting”, April 2020 (available here).\n3 Rroc (2018), Progress report by the Legal Entity Identifier Regulatory Oversight Committee (LEI ROC): The Global LEI System\nand requlatory uses of the LEI, April.\n13\n","contentLength":3050,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:28:12.427Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/p070722.pdf","content":"Fees and other costs\nLegal entities are charged a fee to register an LEl and, on a regular basis, to renew it. A core\ncomponent of the LEI fees covers GLEIF costs to vet LEI issuing institutions’ compliance with\nthe service level agreement, to run data quality checks, to maintain the central database, and to\npublish it for free access. Each LEIl issuing institution adds a fee component to cover its own\noperating costs, depending on its business model and level of automation. The overall cost to\nregister for an LEI therefore depends on the LEI issuing institution that is used.\n\nThe total cost charged for registering and annually renewing®’ an LEI was on average $70 in\n\n2021, down from $86 in 2018 (see Graph 2). In the years 2018-2021 it ranged between $56 and\n\n$220.8 The component of the overall issuance fee requested by the GLEIF has been reduced\n\nover time but has been stable at $11 since 2019.\n\nAverage Fee for LEl issuance Graph 2\n\nIn USD\n70\n60\n40\n20\ne 11 11\n| | | O\n2019 2020 2021\n— Total LOU fee (weighted average, LEl issuances and renewals)\n= GLEIF fee component\n\nNotes: weighted average LEI issuance and renewal pricing as published on websites of LEI issuing institutions at year-end. The price is\n\nweighted by the number of issuances and renewals. Exchange rate as of December 2018 has been applied. LEI issuing institutions may\n\napply customised prices to certain customers, so the prices published on their website may represent an upper bound of the total average\ncost for LE| users\n\nSource: GLEIF analysis, websites of LEI issuing institutions.\n\nThe reduction so far in the GLEIF component of the LEI fee is the result of the steady expansion\n\nof the GLEIS. It can be expected that it will continue its decline in particular if demand for LEI\n\nissuance and renewals continues to rise. Also, portability of LEls from one issuing organisation\nto another allows LEI registrants to move to more competitive LEI issuers, exerting competitive\npressures on the remaining component of the overall LEI cost.\n\nDespite the reduction, the costs of getting an LEI can be perceived by legal entities that would\n\nnot use the LEI often as too high compared to the expected benefits, considering also the costs\n\n37 LEI renewals have the goal to confirm that all previously registered information is still up to date or to update information that\nhas changed in the meanwhile.\n\n38 During the period 2018 to 2021, the minimum fee for new issuance was 56 USD and for renewal 34 USD. The maximum fee for\nnew issuance was 220 USD and for renewal 145 USD. This range remained mostly stable across the years. This analysis\nexcludes the LOU based in China who charges no fee for its LEI services.\n\n14\n","contentLength":2703,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:28:12.427Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/p070722.pdf","content":"of other identifiers that the entity is obliged to purchase for other reasons and the costs to embed\nthe LEI into their own systems and processes.\nThe survey conducted among FSB authorities for this Report confirmed that several members\nconsidered fees associated with the issuance and renewal of the LE| as obstacles for its wider\nadoption, with one authority noting that the costs of getting an LEI should be at a minimum or\neven zero. Participants in the outreach event also mentioned high fees as a barrier to wider\nadoption of the LEI.\nIn this regard, and as illustrated in Section 3.3, the GLEIF is studying a differentiated cost\napproach for entities that decide to register all their own clients or partners for an LEI and bear\nthe costs of such registration (such as via a validation agent), possibly leading to very limited\nresidual costs for the legal entities.\nLegacy technological systems and requirements for other identifiers\nEntities that use legacy technological systems relying on previously existing or local identifiers\nmust consider the costs associated with adding to, or transitioning away from, existing corporate\nidentifiers. Embedding the LEI into legal entities’ own systems might requires investments that\nmay include mapping the LEI to existing system identifiers and possibly update the entities’\nsystems and processes.\nSome surveyed FSB member authorities highlighted that the interlinkage of the LEI with existing\nnational identifiers is an important issue and stressed the current burden of managing multiple\nlegal entity identifiers. At the same time, several FSB members recognised that adapting existing\nsystems and message standards entails efforts and costs, and that a broader LEI adoption\nrequires appropriate implementation lead times.\nThe private sector echoed the inconvenience of a fragmented landscape of identifiers. Yet,\nwhereas some industry members favoured the development of a unique identifier system, others\nvoiced a preference for interlinking the LEI and the other existing identifiers. Regarding the costs\nof updating legacy systems for use with the LEI, some participants expressed the view that these\nmay be overstated, as most systems are capable of managing multiple identifiers.\nWhile interlinking the LEI with existing national identifiers is still pending and there are challenges\nin adapting existing systems to encompass the LEI, freely available mapping services between\nthe LEI and other existing identifiers allow entities to use the LEI without changing immediately\ntheir own technological system. Examples of these services are the freely available mapping of\nthe LEI to the BIC and to the ISIN.*®\nMoreover, COVID-19 has accelerated the trend towards digitalisation of retail financial\nservices.“? Digital innovation is creating pressures for traditional firms and financial market\nparticipants to modernise their legacy core systems and applications, to meet clients’\n39 The BIC to LEI mapping process is established by SWIFT & certified by the GLEIF (see here). Both the GLEIF and the\nAssociation of National Numbering Agencies (ANNA) publish daily open-source mapping files that link newly issued ISINs and\nLEls (see here). Private vendors offer identifier listing and comparison data that can potentially be helpful to entities seeking to\nharmonize LEI and existing identifiers.\n40 FSB, forthcoming FIN report on “FinTech and market structure in the COVID-19 pandemic: implications for financial stability”.\n15\n","contentLength":3485,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:28:12.427Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/p070722.pdf","content":"expectations in terms of service features and customer care that they receive from high-tech\n\nfirms. Renewals of obsolete legacy systems can offer the right opportunity to implement\n\ninnovations such as a new identifier.\n\nPerceived lack of benefits\n\nMany legal entities may not see clear and immediately tangible benefits from adopting the LEI.\n\nSome FSB member authorities suggested that more clarity should be provided on such benefits\n\nor cautioned that fees and implementation costs may balance benefits for private participants.\n\nSeveral private sector participants in the outreach agreed, emphasising the lack of network\n\neffects and the weaker incentives for non-financial companies to sign up than for banks. They\n\nalso supported providing more information about the benefits of LEI use both in cross-border\npayments and other activities. GLEIF partners also supported referencing the LEI in relevant\n\nFATF recommendations regarding customer due diligence, sanction screening, and wire\n\ntransfers.\n\nRaising awareness of the usefulness of the LEI in different contexts and creating new incentives\n\nto adopt the LEI can help entities recognize the benefits as well as the costs. GLEIF has\n\nconducted research and informed the public about potential benefits of the LEI for a variety of\nfinancial activities and in several nonfinancial industries. For example, McKinsey has estimated,\non behalf of the GLEIF, that with the LEI the global banking sector could save up to $4 billion\nannually in client onboarding costs.#! In trade financing, the savings for banks that use the LEI\nin the issuance of letters of credit could amount overall to $500 million annually.4?> GLEIF and\n\nMcKinsey also identified a number of steps in the commercial credit lifecycle where the LEI would\n\nallow efficiency gains, such as rating and onboarding of customers, or invoicing.** They note\n\nthat use of the LEI could assist in addressing the following frictions: 1) manual linking of entity\ndata from disparate internal and external sources; 2) difficulty in assessing entities’ legal\nownership structure; 3) limited transparency into entities’ key officers; and 4) poor customer\n\nexperience due to having to make multiple round trips to gather client data and documents. 4\n\nThe B20 2021 policy paper Trade and Investment recommended exploring the LEI as a mutually\n\nrecognised credential for counterparty identification and verification among financial\n\nintermediaries, as it could help lowering the cost of cumbersome requirements.“® And lastly the\n\nAsian Development Bank and African Development Bank have both published surveys\n\ndemonstrating the LEI could address the unintended consequences of AML requirements\n\ncontributing to financing gaps or de-risking.4®\n\n41 GLEIF McKinsey & Company and GLEIF: LEIs and Client Lifecycle Management in Banking - a U.S.$4 Billion Beginning.\n\n42 GLEIF LEl in Trade Finance - McKinsey & Company and GLEIF: Creating Business Value with the LEI.\n\n43 GLEIF LEI in Commercial Credit - McKinsey & Company and GLEIF: Creating Business Value with the LEI.\n\n44 See GLEIF eBook: LEls and Client Lifecycle Management in Banking - a U.S.$4 Billion Beginning.\n\n45 See B20 ltaly, Trade and Investment Policy Paper 2021. For a more focused analysis of the benefits of the LEI in this context,\nsee B20 ltaly, Trade Finance, a Flywheel Effect to Boost the Economic Recovery Post COVID-19 Pandemic. A specific focus\non the benefits of the LEI in this context is in the B20 paper on Trade Finance. (available here)\n\n46 2021 Trade Finance Gaps, Growth, and Jobs Survey and More Transparency for Better Business — the Potential of Legal Entity\nIdentifiers for African Economies\n\n16\n","contentLength":3688,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:28:12.427Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/p070722.pdf","content":"Table of Contents\n\nEXECULIVE SUMMAIY ... ]\nINtrOAUCHION ... e eeneeennneenenneeee D\n1. Survey of member authorities and outreach with market participants.............................. 5\n1.1. Survey of member authorities ................ccoooeiiiiiiiiiiiii . B\n1.2, OUtreaCh @VEeNL .........oooiiii et a 000, O\n1.3 GLEIF SUMVEY ...ooeieeee e\n2. Rationale forthe LEl and recent progress............cooeveviiiiii i 8\n2.1. Progressin LEl adoption..................oiiiiiiiiiiiiie i 10\n\n3. Furthering the adoptionofthe LEl................ccoooii i 13\n3.1. Potential benefits of greater LEI adoption for market participants and authorities\n3.2. Obstacles to LEI @dOption ................oovviiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiieiiiiieeees 13\n\n3.3. Ongoing efforts to support LEI growth.............cccccovvviiiiiiiiiiiiiiiiiiiinnnn 17\n\n4, LEIINPayments ..o 20\n4.1. Initiatives adopting the LEI for payments.............c....cccoieiiiiiiiiiiiieeeeennn . 20\n4.2. Assessment of specific challenges to the use of the LEI for cross-border payments\n\nTS =T L.\n\n4.3. Options for encouraging use of LEI for cross-border payments......................... 25\nAnnex 1: BB16 — Establishing unique identifiers with proxy registries....................cccccooooeeooen...... 28\nANNEX 2: SUMVEY r€SPONAENTS .........uviiiiiiiiiiiiiiiiiiiiiiieieieeieeesaassaessasesssnsssnssnnnnnsnnnes 2O\nANNEX 3: SUMNVEY QUESTIONS .......oiiiiiiiiiiiiiiiiiiiiiiiiiieeeeeeesssssssssssasssssnssssssnnsnssnnnes SO\n\niii\n","contentLength":1482,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:28:12.427Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/p070722.pdf","content":"Finally, GLEIF is pursuing a digital strategy for the LEI. Embedding the LEI in digital verifiable\ncredentials*’ (VLEN“® and in digital certificates* creates incentives to adopt the LEl by\ncryptographically binding the LEI to an organisation in order to allow a smoother access to digital\nservices (see Section 3.3 Ongoing efforts to support LEl ). Some participants at the outreach\nevent noted that vLEI is a welcome innovation to help address challenges in LEI use, including\nincentives for entities to provide timely and accurate updates.\nSome FSB members suggested that the LEI — if not coupled with a dedicated solution to uniquely\nlink individuals acting in a business capacity such as beneficial owners — may have limited\nbenefits in KYC due diligence processes.* The forthcoming FSB report exploring the scope for,\nand obstacles to developing, a global digital unique identifier for cross-border payments also for\nnatural persons will consider the scope to address this limitation and more fully unlock the\nbenefits of the LEI for due diligence processes.\n\nFinally, several FSB member authorities noted that the current low level of LEI coverage —\n\nparticularly outside of the financial sector - is in itself a barrier to its further expansion. The\n\nbroader collective action problem in the LEI adoption applies also to the cross-border payments\ncontext. some FSB member authorities pointed to the fact that cross-border payments could be\nenhanced through universal adoption in payment messages but market participants do not show\n\na great desire in voluntarily adopting the LEI for cross-border payments needs.\n\nQuality issues concerning the reference data\n\nOne of the reasons for lower-than-expected LEI adoption may be due to issues with the quality\n\nof LEI reference data, in particular out-of-date reference data resulting from the non-renewal of\n\nexisting LEls. While the LEI currently needs to be renewed annually to ensure that the reference\ndata remains up-to-date, still a non-negligible proportion of entities with an LEI do not renew it\nregularly, which creates a risk that the data behind those LEIs might be outdated or incorrect.\n\nWeaknesses in the quality of the LEI reference data may create lack of trust in the LEI by public\n\nauthorities, contributing to the reasons why jurisdictions are refraining from mandating its use.\n\n3.3. Ongoing efforts to support LEI growth\n\nThe GLEIF, the ROC and national authorities are committed to foster further adoption of the LEI.\n\nThe GLEIF is pursuing in particular the following three strategies.\n\n4T A verifiable credential can represent all of the same information that a physical credential represents. The addition of\ntechnologies, such as digital signatures, makes verifiable credentials more tamper-evident and more trustworthy than their\nphysical counterparts (see Verifiable Credentials Data Model v1.1 W3C Recommendation 03 March 2022).\n\n48 GLEIF Introducing the Verifiable LEI (vLEI) - GLEIF’s Digital Strategy for the LEI.\n\n49 See GLEIF, The LEI in Digital Certificates - GLEIF’s Digital Strateqy for the LEI - LEI Solutions — GLEIF.\n\n50 Note in the KYC domain there are two areas for attention, 1. Commercial accounts by legal entities and their employees (e.g.\nindividuals acting in a business capacity) and 2. Individual accounts. The KYC activities would include both and 1 would use LEI\nwhereas 2 may need a natural person identifier.\n\n17\n","contentLength":3420,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:28:12.427Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/p070722.pdf","content":"Engaging banks to get an LEI for all their clients, exploiting synergies between the\nonboarding of clients and the validation of the information necessary to register for an\nLEI. >\nThe data collection and verification procedures performed by the LEI issuing organisations are\nto a great extent also performed by financial institutions as part of identity checking and\nonboarding of clients. By becoming “Validation Agents”, banks can use their client's LEI\nreference data as part of their existing KYC, anti-money laundering or other regulated\nonboarding processes via liaising with the LEI issuing organisation. It is designed to remove the\nduplication of processes across a financial institution’s client onboarding and LEI issuance,\nresulting in a simpler, faster and more convenient experience for financial institutions and their\nclients, enabled by a more efficient LE| issuance process. %2\nValidation Agents streamline their internal data standardization, reduce onboarding costs and\ntiming and generate efficiencies through straight through processing enabled with the LEI. The\nopen, publicly available GLEIF API allows financial institutions to receive updates regarding their\nclients on a timely basis and support their continuous KYC refresh programs. And some financial\ninstitutions took the Validation Agent path to provide LEls to their SME client base and increase\nthe visibility of their clients, thereby contributing to financial inclusion efforts.\n\nThe Validation Agent operating model is open to any related organisation that performs relevant\n\nvalidation and verification practices which are overseen by an independent legal authority, such\n\nas certification authorities. It supports the vision highlighted in the B20 paper, which aims to\nsolve fragmented KYC data landscape that creates burden on entities through the “global value\nchain passport”.®® If LEIs were used by all financial institutions at the time of onboarding to tag\nlegal entity clients, this could significantly minimize the burden of KYC, AML and other processes\nrequiring validation of identity for both firms and financial institutions, by:\nm Avoiding duplicative identification verification procedures for clients.\nm Ensuring maximum transparency, interoperability and clear communication with\ninvestors and supervisory authorities.\nm Allowing for easier information exchange between financial institutions and with\nsupervisory authorities.\nm Helping to prevent fraud with regards to financial transactions and misidentification.\n\nST GLEIF Introducing the LE| Validation Agent - Validation Agents.\n\n52 As of end-March 2022, eight organisations have completed the Validation Agent on-boarding process. This includes large\nfinancial institutions such as JP Morgan and FinTechs such as Finclusive. It also includes organisations from emerging markets\nfor the LEI such as NMB Bank of Zimbabwe and Rubix of India. There are nine institutions actively engaging with GLEIF to\ncomplete the Validation Agent on-boarding process and seven additional in contact with GLEIF and considering participating in\nthe Validation Agent onboarding process. In total, 16 organisations are actively interested or engaged in the Validation Agent\nonboarding process.\n\n%3 B20 ltaly Trade Finance, a flywheel effect to boost the economic recovety post COVID-19 pandemic\n\n18\n","contentLength":3340,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:28:12.427Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/p070722.pdf","content":"Discussing the possibility that business registries get an LEI for all the entities registered\nwith them.\nSeveral business registries are already LEI issuing organisations for individual legal entities that\nseek an LEI issuance and renewal services. Issuing an LEIl in bulk to all the companies\nregistered with a given business registry in a jurisdiction (bulk registration) would allow very low\nissuance costs and could help extend adoption among SMEs.\nBusiness registries already register, depending on national legislation, either all or the majority\nof all economic relevant entities, but always at least all limited liability companies. And these are\nthe type of entities that would typically have international operations. Being registered in a\nnational business registry with a national unique identifier would allow for a sufficient way of\nuniquely identifying entities within a country, whereas having an LEI would enhance this status\nto being uniquely identified on a global scale. Given registries are experts in handling large data\nvolumes with fully automated processes and proper procedures in place to check information\nprovided by registering entities, they likely could add the LEI as an attribute for their registered\nentities in a low-cost manner.\nHaving the business registries issuing LEIs in bulk to all registered entities would increase the\nnumber of available LEls dramatically and this would make the use of the LElI much more\nattractive for many use cases, both within and outside the financial reporting area.\nEnhancing the benefits of the LEI for legal entities to boost voluntary adoption.\nAs part of its digital strategy, the GLEIF is working to embed the LEI in digital credentials and to\nestablish a network of trusted partners to issue digital verifiable credentials based on the LEI\n(verifiable LEI or vLEI).>* The vLEI ecosystem is intended to create a standardised, digitised\nservice capable of enabling instant, automated trust between legal entities and their authorised\nrepresentatives, and the counterparty legal entities and representatives with which they interact.\nAn example of the LEI in digital credentials has been developed by the GLEIF to enable the use\nof the LEI for digitally signing firms’ financial reporting in electronic format. The GLEIF is also\ndeveloping the vLEI to allow LEI registrants to provide decentralised verification of their own\nidentity without having to disclose identity details.®® The vLEI would be accepted as a reliable\nidentity verification tool because of the trust in the GLEIS. As it is expected that more and more\nlegal entities will engage in transactions and services in which digital identity verification is\nneeded, the vLEI could create additional demand for LEls from those legal entities that are not\nsubject to regulatory requirements to have an LEI\n\nThe GLEIF has also joined the DANIE project, a consortium of banks and data vendors that uses\n\nthe LEI for distributed and cryptographic reconciliation of members’ data to enhance data quality.\n\nBy securely and anonymously sharing the own data and comparing them with the values\n\nsubmitted by others, members identify incorrect and anomalous data. The LEI allows automated\n\n54 See GLEIF Introducing the Verifiable LEI (vLEI) - GLEIF’s Digital Strategy for the LEI.\n\n55 The VLEI is based on self-sovereign identity (SSI), a concept that natural persons should have control over the personal\ninformation contained in their credentials and can choose to prove their identity and certain facts about themselves in a controlled\nand safe manner. (See GLEIF Introducing the Verifiable LEI (vLEI) - GLEIF’s Digital Strategy for the LEI).\n\n19\n","contentLength":3675,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:28:12.427Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/p070722.pdf","content":"matching of the data provided by different DANIE members. The consortium is planning to\n\nextend the data set to AML and KYC areas and to use the LEI also to match those data sets.®®\n\nThe ROC, as described in its 2019-2021 Progress Report,® is also taking actions to address the\n\nrecommendations of the FSB Peer Review and boost LEI adoption.\n\nMore specifically, the ROC has provided clarity on how the LEI should be assigned to specific\n\ntypes of legal entities (funds, government entities®®), paving the way for a broader LEI adoption\n\nby those entities. It has also elaborated a vision for the GLEIS and strategically explored potential\nevolutions of the GLEIS business model that could boost LEI adoption. As part of that work the\n\nROC has identified the long-term goal of Global, Universal coverage and Real-Time accuracy\n\nfor the LEI and its Level 1 reference data (the GURT goal). This goal would allow any user\n\n(human or machine) to be able to rely on LEI data without any further verification, and to retrieve\n\nLEI data on any legal entity addressed in any user’s process.\n\nMoreover, to enhance the usefulness of the LEI for users, the ROC is working with the GLEIF to\n\nimprove the GLEIS data quality and is exploring innovative ways to enhance the scope and\n\nusability of the Level 2 parent relationship data. For example, a data quality indicator has been\ndeveloped (the conformity flag) to label those LEls that fulfil a set of quality criteria.>® While the\n\nGLEIF has introduced in 2021 substantial enhancements for LEI issuing organisations to check\n\nthe quality of each LEI individually before it is issued,® the ROC has focused on identification of\n\nquality issues that become evident by focusing on a population of LEls rather than on individual\n\nLEls.\n\nFinally, the ROC supports the GLEIF’s outreach and educational activities to explain the benefits\n\nof the LEI, such as the GLEIF’'s 2021 educational workshops on the use of the LEI for\n\nmultinational corporates or in the context of virtual assets, and in other areas of potential\napplicability.\n\n4. LEl in payments\n\n4.1. Initiatives adopting the LEI for payments\n\nIn recent years, both the private and public sectors have taken steps to promote the adoption of\n\nthe LEI for cross-border and domestic payments.\n\n56 Société Générale, November 2020, Privacy Enhancing Technologies (P.E.T), or how to improve overall efficiency and reduce\nmanagement costs for many use cases in the financial sector.\n\n5T ROC (2022), Progress Report 2019-2021, January.\n\n%8 RoC May 2019 Policy on Fund Relationships; ROC December 2020 Guidance on LEI eligibility for General Government Entities.\nThe ROC is also currently considering whether and how to capture in the Global LEI System group structures based on\nrelationships that do not fit in the traditional “group” definition in their jurisdiction (Unconventional Group Structures). The ROC\nhas decided not to extend the LEI eligibility to individuals other than the individuals acting in a business capacity and, more\nbroadly to discontinue any work on individuals, in light of the decision of the ISO Technical Committee 68 on financial services\n(ISO/TC 68) to work on an ISO standard for an identifier for natural persons.\n\n5% The rollout of the conformity flag is yet to be determined.\n\n80 The GLEIF has introduced in August 2021 a data quality application programming interface (API) that LOUs must use when\npopulating the GLEIS database.\n\n20\n","contentLength":3451,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:28:12.427Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/p070722.pdf","content":"m As of October 2022, the Reserve Bank of India (RBI) will require national legal entities\nto provide an LEI to their bank in order to undertake cross-border capital or current\naccount transactions above a certain value (INR 500 million, approximately $6.7\nmillion). Though the mandate is for transactions of INR 500 million and above, it has\nbeen decided that once the reporting institution has obtained the LElI number of an\nentity, it must be reported in all cross-border transactions of that entity, irrespective of\ntransaction size.®' Already in 2021, the RBI had introduced the LEI requirement for\nentities which undertake large value domestic payments (in this case also above INR\n500 million) in Centralised Payment Systems run by the RBI (i.e. the National Electronic\nFund Transfer (NEFT), for retail payments, and the RTGS system).®? Between April\n2021, when the requirement came into force, and January 2022, approximately 204,000\ntransactions have been processed in the NEFT and RTGS system with an LEI, either\nof the payer or of the payee or of both, representing approximately 73% of transactions\nabove the $6.7 million threshold.®3\n\n= Inthe UK, the Bank of England announced that, as part of its adoption of ISO 20022,\nLEls will be mandatory for certain payment messages between financial institutions in\nthe CHAPS payment systems from summer 2024.%* The Bank has also said that this\nrequirement will be extended to more users of CHAPS as LEls become more prevalent.\nIn 2020/21, 37 banks were direct participants of CHAPS, with a total volume of\nprocessed payments of £92 trillion.\n\nm The Federal Reserve Board announced in October 2021 that Federal Reserve Banks\nwill adopt the ISO 20022 message format for the Fedwire Funds Service, to enhance\nthe efficiency of domestic and cross-border payments, and to facilitate market\nparticipants’ compliance with sanctions and AML requirements. \\When consulting on the\nmigration plan,® the Board proposed to include the LEI as one of many new and specific\nvoluntary fields in the ISO 20022 messages for Fedwire. In 2020, Fedwire processed\npayments totalling $840 trillion, with an average value of $4.5 million.®® In the same\nyear it had 5,700 directly connected participants. ¢’\n\n= Hong Kong plans to introduce the LEI field in the payment messages of its wholesale\npayment system after ISO 20022 adoption in 2023.\n\nm The European Commission, in its proposal for a revision of the Transfer of Funds\nRegulation,®® has placed a requirement for payment service providers to include the LEI\nin payment messages, in cases where they have collected such information.\n\n61 RBI/2021-22/1 37, A.P. (DIR Series) Circular No. 20 Introduction of Legal Entity Identifier for Cross-border Transactions.\n\n62 RBI/2020-21/82 DPSS.CO.OD No.901/06.24.001/2020-21 Introduction of Legal Entity Identifier for Large Value Transactions in\nCentralised Payment Systems.\n\n63 For the remaining 27% of the transactions above this threshold, it is difficult to ascertain whether they involve legal entities and\nhence some of the transactions may between individuals.\n\n64 Bank of England Policy Statement: Implementing ISO 20022 Enhanced data in CHAPS . As mentioned, adopting a harmonised\nISO 20022 version for message formats is the subject of Building Block 14 of the G20 Cross-Border Payments Roadmap.\n\n65 Federal Register (2021), New Message Format for the Fedwire® Funds Service, October.\n\n66 cpmI https://stats.bis.org/statx/srs/table/PS3?c=&p=2020.\n\n67 cpmi https://stats.bis.org/statx/srs/table/PS4?c=&p=2020.\n\n68 Available at: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A52021PC0422.\n\n21\n","contentLength":3643,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:28:12.427Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/p070722.pdf","content":"m Inthe Eurosystem, participants in the forthcoming payments and settlement system T2\nwhich is expected to replace TARGET2 in November 2022,%° will be obliged to provide\ntheir LEI during the registration process.\n\nm |n addition, private sector participants included the use of LElI among the best practices\nin payments. For example, in its September 2021 White Paper’® SWIFT’s Payment\nMarket Practice Group (PMPG)’\" provided information on existing market practices\nregarding the LEI as an identifier in payments and illustrated use cases of the LEI in\npayments, with benefits for participants in terms of more transparent, efficient and\nsecure payments. The White Paper provides LEI use cases for market participants in\nsanctions screening, KYC processes, corporate invoice reconciliation, fraud detection\nand account to account owner validation. Benefits include:\n\ne Sanctions screening: avoiding false positive matches\n\ne KYC and customer onboarding: making KYC processes quicker and more efficient,\nreducing costs, improving client experience, and industry level re-use of KYC data\nacross financial institutions\n\ne Corporate invoice reconciliation: automation, full transparency of parties to the\ntransaction from start to end and interoperability across platforms\n\ne Fraud detection: exact matching criteria for account-to-account owner validation\n\nThe paper encourages financial institutions to engage with GLEIF in the validation agent\n\noperating model and regulators to support the LEI by using it in sanctions lists.\n\nm The PMPG has also issued in October 2021 guiding principles for an effective and\nefficient screening of ISO 20022 payments’ to address sanctions-related frictions in\nthe payment chain. The PMPG notes that the global nature of LEIs and BICs makes\nthem particularly suited to identify sanctioned entities matching information from public\nsanctions lists. Also the Wolfsberg Group endorsed these guiding principles.\n\nAs cross-border payments are the backbone of cross-border financial markets, cross-border\ntrade and cross-border service provision, initiatives to introduce the use of the LElI more\ngenerally in cross-markets result in LEIs being created for both the payer and payee in cross-\nborder payments. In that context, the US Custom and Border Protection (CBP) has launched in\n2021 an Evaluative Proof of Concept for a Global Business Identifier (GBI) that includes the\nLEI,™ along with the Global Location Number (GLN) and the Data Universal Numbering System\n89 ECB, T2-T2S consolidation: what s it?\n7 PMPG (2021), Global adoption of the LEI in SO 20022 Payment Messages, September.\n™ The SWIFT PMPG is a global discussion forum of private sector payments experts which takes stock of payments market\npractices across regions, discusses market practice issues, and recommends market and best practices related to payments\nmessages.\n72 PMPG (2021), Guiding Principles for Effective Screening of ISO 20022 V1, October.\n3 Federal Register (2021), Global Business Identifier, October.\n22\n","contentLength":3021,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:28:12.428Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/p070722.pdf","content":"(DUNS).™ The CBP will in the end determine whether to mandate the GBI solution as an\nalternative to the Manufacturer/Shipper Identification Code.\nBox 2: LEl in cross-border payments: use case in China\n\nIn December 2020, the People’s Bank of China, together with China Banking and Insurance Regulatory\nCommission, China Securities Regulatory Commission and the State Administration of Foreign\nExchange, released the “Roadmap to Implement Legal Entity Identifier in China (2020-2022)” which put\nforward the use of LEI in Cross-border Interbank Payment System (CIPS) for customer identification,\nincluding adding LEI to CIPS financial messages and launching the cross-border legal entity information\nplatform pilot project.\nDrawing from global LE| use case experiences, CIPS has incorporated LEI into financial messages and\nactively explored the application of LEI in cross-border scenarios with the combination of LEI and digital\ncertificates.\nInternational consensus has formed that information exchange standards are to transition to ISO 20022\nstandards. Major payment messages such as pacs.008 have already incorporated LEI as an optional\nfield in customer identification. CIPS is among the few financial market infrastructures that has adopted\nthe ISO 20022 standard since its launch. To maximize the value of LEI in cross-border entity\nidentification, CIPS has also mapped LEI to other applicable identifiers such as BIC, CIPS ID (a unique\nidentifier generated by CIPS) and researched an inclusive identification system that supports LEI, BIC\nand CIPS ID.\nIn order to further the use of LEI in cross-border transactions and facilitate cross-border trade and\ninvestment, CIPS designed an innovative product “CIPS Connector”, which provides an integrated “one-\nstep” service for a variety of cross-border RMB transactions between banks and enterprises. Every\nCIPS Connector user is assigned with an LEI, which is used for activating the tool as well as a\nmandatory business element in their business transaction. By incorporating financial data exchange\nstandards such as LEIl and ISO 20022, CIPS Connector specifically addresses the challenges that\nbusiness entities face when making overseas RMB remittances, including lengthy chains of\nintermediaries, slow speed, and low efficiency. By the end of 2021, more than 1,500 financial\ninstitutions have signed the intent form to use the product. Since its launch, the CIPS Connector has\nenhanced the straight-through processing rate and achieved full coverage of LEI for domestic CIPS\nConnector users. According to feedback from users, the installation of CIPS Connector shortens the\ntime, reduces the costs, and improves the efficiency of cross-border payment.\n“LEI + digital certificates” is another attempt to weave LEI into today’s cross-border RMB payment\nprocess. In October 2021, the Register Authority (RA) System in CIPS was upgraded, with LEI\ninformation embedded in every newly issued digital certificate. In this way, more business scenarios\nare developed to apply both digital certificates and LEI for entity identification. As of January 2022, more\nthan 1,100 new digital certificates with LEI information have been issued to CIPS users. Meanwhile,\nCIPS continuously encourages new users to apply for LEl when joining CIPS.\n\n7 The GLN is owned and managed by GS1, the DUNS by Dun & Bradstreet.\n\n23\n","contentLength":3361,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:28:12.428Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/p070722.pdf","content":"4.2. Assessment of specific challenges to the use of the LEI for cross-\n\nborder payments needs\n\nAs with all use cases of the LEI, ensuring that the information on the legal entity embedded in\nthe LEI is complete, correct and up-to-date is key for the use of the LEI in cross-border payments.\nThe ROC and the GLEIF’s ongoing efforts to improve the data quality within the GLEIS are\nvaluable contributions in such efforts.\nThe data quality necessary for cross-border payment needs may differ from the quality needed\nfor other use cases of the LEI, such as systemic risk analysis. For the use of the LEI in cross-\nborder payments, it may be particularly important that the information on the legal form of an\nentity and on its country of incorporation are correct. While these are usually verified by the LEI\nissuers, which double check the information provided by the registering legal entity against other\nreliable sources such as business registries, some issues may need further investigation within\nand possibly beyond the GLEIS.\"\nData quality is achieved not only when the relevant LEI reference data are correctly assigned to\na new LEI code but also when this is timely updated whenever some information changes. For\nthe use of the LEI in cross-border payments, it may be particularly important that the information\non the country of incorporation of the legal entity is up to date and that the LEI correctly reflects\ncorporate actions that have occurred to the legal entity, such as the merger with another legal\nentity or its dissolution. One FSB member jurisdiction surveyed pointed to inconsistencies in\nexisting repositories and mapping between LEI numbers as obstacles to LEI expansion, though\nit is considered that the mapping between LEI and existing repositories would be the\nresponsibility and task of that repository owner (not the GLEIF).\nSome of the surveyed FSB member authorities highlighted the importance of ensuring a timely\nupdate of such reference information. To address this, jurisdictions could request legal entities\nwith an LEI to revalidate it regularly within the GLEIS: one FSB member authority suggested that\nthe mandatory revalidation of the LEI could be foreseen only for those legal entities that engage\nin cross-border payments. As a more cumbersome alternative, as a non-revalidated LEI could\nstill be connected to reference data that is up to date, different updating mechanisms could be\nlocally explored in case of corporate events relevant for cross-border payments that presumably\nneed in any case notification or authorisation by local authorities.\n\nIn this regard, the introduction of the vLEI could be an opportunity to address such challenges\n\nby formalising certain protocols regarding legal entity verification such as the maximum period\n\nsince last verification and validation. In fact, according to the vLEI ecosystem policies, the LEI\nof the Legal Entity may not be in the registration status of “lapsed”. It should be noted, however,\nthat GLEIF’s work on the vLEI is ongoing and the product has not yet been finalised.\n\n7 For example, a preliminary Federal Reserve analysis shows that, for LEIs of US incorporated entities, in 8-10% of the instances\nthe legal entity’s name and its legal form do not match exactly with business registry records. The analysis also shows that some\nbasic address information (city, state and postal code) may not accurately reflect the address of the legal entity. For example,\nthe LEI reference data may reflect the address of professionals (“registration agents”) that were involved in the establishment of\nthe legal entity, such as their legal representative. However, such discrepancies may reflect the LEI's governing policies, under\nwhich a company’s address is where it can be contacted, rather than where it may be formally situated.\n\n24\n","contentLength":3829,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:28:12.428Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/p070722.pdf","content":"Models could be considered that link revalidation of LEls to identity checking within domestic\ndigital identity frameworks, for example in those cases where an LEI is linked to an individual\nrepresenting the organisation. Finally, as discrepancies between these specific core reference\ndata of the LEI and information available to the payment service provider could create delays or\nrepresent obstacles in payments processing, payment service providers could cross-check LEI\nreference data with information provided by new clients during onboarding and they could remind\nto update the LEI whenever a client notifies them a change in some core identification data.”\nLEI issuing organisations have indicated that there is a greater need for clear practices in using\nthe LEI in the payment chain rather than pointing to specific concerns regarding LEI attributes\nor validation process. For example, they stressed the importance of determining in which step\nof the payment chain to request the LEI. They also noted that it is easier for an intermediary to\nask for and/or provide an LEI for their clients but it is not possible for them to have control over\nthe beneficiary’s LEI: they would need clarity on what intermediaries should do in case the\nbeneficiary’s LEI is not provided or is incorrect.\n\nFinally, solutions should be explored to favour an efficient interoperability between LEI and\n\nexisting identifiers, which can help to decrease the complexity as well as possible costs for the\n\nLEI adoption.\n\n4.3. Options for encouraging use of LEI for cross-border payments\n\nBased on the inputs gathered from authorities, ROC, GLEIF, market participants and other\n\nstakeholders, options to enhance adoption of the LEI, with a focus on its use in cross-border\n\npayments, may include the following:\n\nm ROC, GLEIF and national authorities’ continued effort to promote the quality of LEI\nreference data, including keeping the attributed information up to date. In this context,\nthe FSB CPDI may contribute to explore which attributes are essential for LEI use in\ncross-border payments;\n\nm GLEIF’s efforts to reduce obstacles to LEI adoption, including the validation agent\nmodel and digital strategy as initiatives that can address certain obstacles to the\nadoption of the LEI (costs, administrative burden, perceived lack of benefits) and can\ncreate incentives to timely updates of the LElI when necessary:\n\ne Models could be explored where — similar to the validation agent model - the LEl is\ngenerated as a by-product of other cross-border payment-related processes.\n\ne GLEIF could consider inviting banks to become Validation Agents for those of their\nclients who are more active in cross-border payments, e.g. those that meet a certain\nthreshold in terms of value and/or yearly number of cross-border payments;\n\n76 Payment service providers could also create an automated process to challenge the LEI record via the public challenge facility.\nGLEIF continues to improve its challenge service to make it easier for public users of the LEI data to trigger validation/verification\nof LEI reference data.\n\n25\n","contentLength":3106,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:28:12.428Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/p070722.pdf","content":"e GLEIF could engage in specific pilot projects with relevant stakeholders regarding\nstandards for including the LEIl in payment messages and guidance to financial\ninstitutions on possible uses of the LEI when transmitted in payment messages.\n\nm The use of LEI for the onboarding process and, possibly, for the purpose of strong\ncustomer authentication could be explored by public and private sector stakeholders\nalong the lines indicated in this report.”” As noted by the PMPG, the LEI can enable\nfinancial institutions to move to an environment where information on KYC performed\nat different financial institutions can be used to improve the onboarding process.\nAccording to GLEIF, their private sector business partners consistently identify FATF\nrecommendations 6, 10 and 16 as the important recommendations where the LEI\nshould be incorporated. The Financial Action Task Force (FATF) highlighted in its\nCross-Border Payments Survey Results on Implementation of the FATF Standards’\nthat many respondents supported increased cooperation between regimes to\nstandardise sanction list formats, interpretation of contents, expected response\nassociated with listings and list distribution approaches. According to respondents,\nincreasing uniformity in the list entries and greater use of structured identifiers such as\nLegal Entity Identifiers (LEIs), Business Identifier Codes (BICs) and digital identities and\nlinkage of list entries between UN and country lists would simplify the screening process\nand improve detection performance. They also indicated that wider adoption of the LEI\nfor entity client identification and identifying beneficiary and originator in payment\nmessages would support widespread interoperability between systems and reduce\ncosts and increase precision and transparency. Based on the dialogue with FATF, it\nwas concluded that issuing guidance on how the LElI may be used as standardised\nidentifying information for sanctions lists or the primary means of identification of legal\nentities would be a more reasonable approach than to upgrade relevant FATF\nrecommendations. As FATF recommendations are principle-based and their\nimplementation is left to the discretion of each jurisdiction, it would be inappropriate to\nchampion a particular identifier such as the LEI.\n\nm Public communication and promotion to raise the visibility of the LEI, particularly among\nnon-financial sectors involved in cross-border payments. This should involve\ndeveloping and publishing use cases in cross-border payments for non-financial\ncorporates, and ways in which they can directly benefit from adopting the LEI.\n\nm FSB members to consider including an optional field for the LEI in routing message\nformats for wholesale payment systems, and possibly migration to 1SO 20022\nmessages, and as appropriate, explore the scope to mandate use of the LEI for certain\npayment message types.” While wholesale payment systems usually process high-\nvalue domestic payments, the most sophisticated payers and payees in the national\npayment spaces would, in this way, gather an LEIl and could use it also in their cross-\n\nT The reference in the text regards the work the GLEIF is conducting with the DANIE consortium and to the request of the private\nsector for Authorities to clarify the role that LEI could play in KYC. Authorities also mentioned this aspect.\n8 Cross-Border Payments — Survey Results on Implementation of the FATF Standards; FATF (October 2021).\n® This option would allow to achieve the expected results independently from the decision of the respective wholesale payments\nsystems operator/regulator to shift to ISO 20022. As mentioned, Building Block 14 of the roadmap considers the adoption of a\nharmonised ISO 20022 version for message formats, including rules for conversion/mapping.\n26\n","contentLength":3809,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:28:12.428Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/p070722.pdf","content":"iv\n","contentLength":3,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:28:12.428Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/p070722.pdf","content":"border payments. Two surveyed FSB members expect that the adoption of the LEI will\nincrease when SWIFT and the major wholesale payment systems shift to ISO 20022\n(in 2022 and 2023), as banks will be required to get an LEI to continue participating in\nsuch systems (Germany, India).\n\nm FSB members to consider linkage of LEl to domestic identifiers in their digital\ninfrastructures, to promote interoperability of LElI and other identifiers to facilitate\nautomated reconciliation and validation.\n\n27\n","contentLength":500,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:28:12.428Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/p070722.pdf","content":"Annex 1: BB16 — Establishing unique identifiers with proxy registries\nActions and milestones (as revised in the First consolidated progress report)\nAction 1\nReview the scope, technical and operational requirements of existing and proposed global\ndigital Identifiers for both legal entities and natural persons and analyse the need for a\ndecentralised proxy registry.\nFSB, in consultation with CPMI, IMF, WB, GLEIF, ISO and other October 2020 - October 2022\nstakeholders, to explore the scope for, and obstacles to develop, a\nglobal digital Unique Identifier (Ul) for cross-border payments, and\npotentially other financial transactions, that takes into account\nexisting identifiers, including the LEI for legal entities and identifiers\nfor individuals The review would also:\ne consider mechanisms to match Uls with payment information,\nsuch as via a proxy registry®,\no take into account the work of relevant standard setting bodies,\nincluding the FATF, on technical, governance, or policy issues,\ne and analyse how to map to existing identifiers.\nAction 2\nDetermine the next steps to promote the use of a (global) digital Ul framework and\ndecentralised proxy registry in jurisdictions\nFSB in close coordination with GLEIF, the LEI ROC and national June 2021 - June 2022\nauthorities to explore the options to improve adoption of the LEI.\nIf there is consensus that a new identifier is necessary, FSB, in October 2022 — June 2023\nconsultation with CPMI, IMF, WB, ISO and other stakeholders, to\nassess existing proxy databases for personal identifiers, propose\nstandard design principles for these databases, and define minimum\nrequirements for personal identifiers.\nAction 3\nIf necessary: Implementation and progress monitoring.\nIf consensus is achieved on a possible new Ul and new interoperable June 2023 — June 2024\nproxy databases, FSB to create an appropriate governance for the\nUl and for the interlinking of databases (based on the data sharing\nprinciples developed in BB 8). However, the decision to implement it\nshould lie with the individual countries (that may have to adjust\nregulation accordingly).\nUl-Governance body that is established to begin registering of June 2024 - October 2024\nparticipants. Start of the voluntary scheme.\nNational authorities to explore the processes involved in a possible October 2022 - June 2023\nadoption of a global digital unique identifier on a national level or the\ninterlinking of existing identifiers.\n80 A proxy registry is a database which matches an identifier and payment information to help route the payment correctly\n28\n","contentLength":2574,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:28:12.428Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/p070722.pdf","content":"Annex 2: Survey respondents\n\nArgentina\n\nAustralia\n\nBrazil\n\nFrance\n\nGermany\n\nHong Kong\n\nIndia\n\nIndonesia\n\nItaly\n\nJapan\n\nMexico\n\nNetherlands\n\nSaudi Arabia\n\nSingapore\n\nSpain\n\nSwitzerland\n\nTurkey\n\nUnited Kingdom\n\nUnited States\n29\n","contentLength":226,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:28:12.428Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/p070722.pdf","content":"Annex 3: Survey questions\n\nStocktake of existing payments identifiers\n\ni) Please list existing global, regional or national identifiers®' that are widely used in your\njurisdiction for payments to specify the sender or recipient (SWIFT and BIC codes are\nexcluded in this context because they do provide information on the PSP, not the sender or\nrecipient).\n\nThe information to be provided includes at least, but is not necessarily limited to, targeted\n\ncoverage (universal/sectoral), access® (e.g., only for public authorities, only for resident\n\nentities, only for banks), costs for queries and other costs (including for PSPs, particularly\nthose operating services for individuals across borders), issuer/governance of the identifier\n\n(e.g., public/private), possible standards (e.g., ISO) adopted for building the identifiers.\n\na) Please list any other global, regional or national identifiers that (although not yet widely\nused) are emerging or growing in usage in your jurisdiction (e.g., distributed ledger\ntechnologies such as blockchain) and indicate how widely they are used.\n\nExisting identifier characteristics\n\n(Please answer separately for each identifier)\n\ni) What is the current use for payment purposes of the identifiers listed in your answer to the\nprevious question (e.g. enabling payment routing, reconciliations, KYC checks, sanctions\nscreening)?\n\ni) What characteristics of such identifiers would need to be enhanced/changed to enable their\nuse by both counterparties in cross-border payments (e.g. in terms of access and\nattributes)?\n\niv) For those identifiers used for payment purposes, please indicate if there is (or there is\nplanned) any mapping to other existing identifiers (even if not used for payment purposes).\n\nv) Is there any plan to require or promote the use for payments, or for wider purposes, of digital\nidentities/identifiers in your jurisdiction? If yes, which characteristics will the respective\nidentifiers have?\n\nvi) With what type of personal identification information (e.g. name, gender, date of birth,\naddress, mobile phone number, email address) are the identifiers listed in the answer to\nquestion (i)® associated?\n\n8 This includes not only identifiers such as IBAN code, but also digital/physical IDs to identify individuals and legal entities for\n\npayment purposes.\n\n8 |t would be useful to distinguish between domestic resident and cross-border access, where relevant.\n\n8 A global identifier could be underpinned by a basket of reference data/identifiers enabling flexibility but ensuring compliance and\n\ninteroperability without going above and beyond jurisdictional redlines/preferences.\n30\n","contentLength":2647,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:28:12.428Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/p070722.pdf","content":"vii) Is the personal identification information embedded in the identifier information used for\npayments purposes, or is it separate, and the identifier as such contains no embedded\nintelligence about the individual/entity?8+\na) In case the personal identification information is separate, can the identifier information\n\nbe accessed on a timely basis if so requested?\n\nGeneral questions\n\nviii) The whole process that leads to digital identity certainty is supported under several\nframeworks by specific Level of Assurance (LoA)® typically associated with each stage of\nthe process (proofing, verification, and binding). Please describe the situation in your\njurisdiction.\n\nix) As mentioned in the Stage 2 Report for BB16, “the goal is that jurisdictions introduce digital\n\nunique identifiers and proxy registries, which are ultimately connected globally. The\nidentification of payer/payee will be more efficient, and less costly since straight through\nprocessing (STP) could be more easily adopted in each link of the transaction chain.”\nIf possible, you may wish to reach out to selected PSPs in your jurisdictions to ascertain (at\nleast in preliminary form) whether they would benefit from a global identifier to facilitate STP,\nhow they would benefit (less costs related to reconciliation, simplified data compliance\nprocess, etc) and, on the other hand, whether they see significant disadvantages or\nobstacles. Please provide any information from such outreach here.\n\nX) Please indicate any existing or ongoing specific piece of work of relevant standard setting\nbodies on technical, governance, or policy issues that in your view would be relevant when\nconsidering the scope for, or obstacles to develop, a global unique identifier?\n\nxi) Which mechanisms could be used to match unique identifiers with payment information (e.g.\nvia a proxy registry)?\n\na) Could you mention any concrete example (for example, a mechanism such as that\nforeseen for the Nexus gateway)?8®\nb) What operational requirements do you envisage for a decentralised proxy registry?\n\nxii) Would the data frameworks in place in your jurisdiction allow the sharing of information\nconcerning unique identifiers?\n\na) Would sharing identifiers with no embedded intelligence about the individual/entity (see\n\nfootnote 6) but simply used to retrieve the decentralized proxy register (i.e. to retrieve\n\n8|SO 24366 - Identification of Natural Persons - Briefing note. Work by this standard 1SO is going in this direction (identifiers\nattached to Digital ID but with no embedded intelligence).\n\n8 Please refer to eIDAS, ISO/IEC 29115 or NIST 800-63-3 standards. In the ID4D Initiative (https://id4d.worldbank.org/) it refers\nto the “certainty with which a claim to a particular identity during authentication can be trusted to actually be the claimant's “true”\nidentity”.\n\n8 See “Nexus - A blueprint for instant cross-border payments”, available at https://www.bis.org/publ/othp39.pdf.\n\n3\n","contentLength":2956,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:28:12.428Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/p070722.pdf","content":"the payment account information needed for the transfer of funds) be allowed in your\njurisdiction?\n\nb) Would sharing identifiers with embedded intelligence (e.g., date of birth) about the\nindividual/entity be allowed in your jurisdiction?\n\nc) If no information sharing is currently allowed, what changes would be needed to allow\nsuch sharing (e.g.,, changes to a domestic legal framework, to a supranational\nregulation, to regulatory rules)? Is any work is being undertaken in this regard?\n\nLegal Entity Identifier (LEI)\nxiii) In your view, could cross-border payments be enhanced with a widespread adoption of the\n\nLEI? If yes, how (e.g. including LEI within payment messages)?\n\nXiv) In your opinion, are there any gaps in the attributes/validation of the LEI that might hinder\nits use for cross-border payments?\n\na) If yes, do you have in mind possible solutions?\n\nb) Do you have a view on what role GLEIF’s validation agency model, vLEI and bulk\nregistration could play in supporting enhanced use of the LEI in a payments context?\n\nxv) What obstacles do you see to an increased adoption of the LEI for use in cross-border\npayments in your jurisdiction and worldwide? What solutions would you envision to\novercome these obstacles and why?\n\nxvi) Is there any plan to require or promote the use of LEI for some payments purposes in your\njurisdiction?\n\n32\n","contentLength":1355,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:28:12.428Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/p070722.pdf","content":"Executive summary\nThe G20 roadmap to enhance cross-border payments’ has launched several initiatives to reduce\nfrictions in the data processes connected with payments by promoting the use of common\nmessage formats, data exchange protocols, conversion and mapping approaches from legacy\nformats and standardised data. To address data handling issues and improve compliance\nprocesses, it also aims to examine the scope for a global unique identifier that links to the account\ninformation in payment transactions. This would facilitate straight through processing (STP),\nreducing costs, enhancing accuracy and increasing speed in transactions, and could as well assist\nmarket participants in meeting Know-Your-Customer (KYC) requirements.\nIn exploring the potential for, and the challenges to develop, a global digital unique identifier for\ncross-border payments, the FSB has been requested by the G20 to take into account existing\nidentifiers including the Legal Entity Identifier (LEI) and to explore options to improve the LEI’s\nadoption.\nThis report explores benefits that could accrue from the use of the LEI in cross-border payment\nsystems and, in close coordination with the Global LEI Foundation (GLEIF), the Regulatory\nOversight Committee (ROC) and national authorities, explores options to promote broader LEI\nadoption. It builds on a survey among FSB authorities and an outreach event with market\nparticipants, both held in the first half of 2022. It also extensively benefitted from inputs provided\nby GLEIF and ROC, including the ROC’s 2018 and 2019-2021 Progress Reports.\nBoth authorities and market participants recognise the potential benefits of the LEI in strengthening\ndata standardisation as well as assisting and supporting STP, KYC processes and sanction\nscreening. The main obstacles to wider LEI adoption identified by authorities were not specific to\nthe payment domain but pertained to general challenges already known to both GLEIF and ROC,\ni.e. costs, legacy issues and lack of perceived incentives for voluntary adoption of LEI by market\nparticipants and end-users. The timely update of the information contained within the LEI was also\nstressed as an important prerequisite for LEI use.\nMarket participants broadly agreed with the identified obstacles but considered legacy systems\nless of an issue. They underscored the need to provide use cases to better inform market\nparticipants of the benefits of the LEI, which would help to explain why the cost of adapting legacy\nsystems would be warranted. They also pointed out the importance of easy access to LEI for cross-\nborder payment purposes and stressed that its wider use would by itself provide incentives for\nvoluntary adoption.\nGLEIF, in cooperation with the ROC, has several initiatives to promote LEI adoption more broadly,\nincluding bulk LEI registration by intermediaries and business registries — which could both lead to\na significant reduction of per capita fees and increase network effects — and additional LEI features\nthat could incentivise voluntary adoption, such as the verifiable LEI (vLEI), i.e. a digitally verifiable\ncredential containing the LEI. Further improvement in the quality of LEI data remains a GLEIF and\nROC priority to enhance the effective use of the LEI and broaden adoption.\n1 FSB (2020), Enhancing Cross-border Payments: Stage 3 roadmap, October\n\n1\n","contentLength":3367,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:28:12.431Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/p070722.pdf","content":"Building on these initiatives, this report sets out recommendations (summarised below) for\npromoting the use of the LEI in cross-border payments, providing use cases to highlight the\npotential benefits of the LEI in supporting STP and contributing to the KYC process.\n\nThe report also sets out, in addition to these recommendations, some specific options for\nencouraging use of the LEIl in cross-border payments, based on the inputs gathered from\nauthorities, ROC, GLEIF, market participants and other stakeholders, that can be considered by\nrelevant bodies.\n\nRecommendations\n\nThe FSB remains committed to promoting broader use of the LEI globally, in line with its\nThematic Review on Implementation of the Legal Entity Identifier in 2019. This report sets out\nrecommendations and options for improving adoption of the LEI in cross-border payments in\norder to assist in achieving the goals of the G20 roadmap. Achieving these goals will depend on\npromoting uptake of the LEI among non-financial corporates, as well as financial institutions.\nThe following recommendations are addressed to FSB member jurisdictions, the FSB itself,\nROC and GLEIF, relevant standard-setting bodies (e,g. the Committee on Payments and Market\nInfrastructures (CPMI), the International Organization of Securities Commissions (I0OSCO), the\nBasel Committee on Banking Supervision (BCBS), and the Financial Action Task Force (FATF))\nand international organisations (IMF, World Bank).\n\n1) FSB member jurisdictions should:\n\nm Explore ways to promote LEI adoption, particularly outside the financial sector, for\ninstance by fostering nationwide implementation strategies to maximise the cross-\nsectoral benefits of the LEI; increase knowledge on the LEI to raise awareness of\npotential benefits and increase the visibility of LEI through public outreach initiatives;\nand consider the use of LEI before exploring the possibility of introducing other\nidentifiers locally.\n\nm Consider mapping the LEI to domestic identifiers in their digital infrastructures to\npromote interoperability of LEI and other identifiers to facilitate automated reconciliation\nand validation.\n\nm Consider including an optional field for the LEI in routing message formats, including\nfor those migrating to ISO 20022 messages, and where appropriate, explore the scope\nto mandate use of the LEI for certain payment message types.\n\nm Consider adding, where appropriate, the LEIl as a requirement in newly created or\namended regulations, directives and legislation relevant to cross-border payments\nwhere entity identification is needed.\n\nm Consider providing guidance on using the LEI in the payment chain, including how\nintermediaries should address challenges in obtaining the LEIls for cross-border\npayment beneficiaries (which are often more difficult to obtain than the LEls for cross-\nborder payment originators).\n\n2\n","contentLength":2870,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:28:12.431Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/p070722.pdf","content":"2) The FSB should:\n\nm Explore synergies with the work of other building blocks in the roadmap (e.g. BB6 on\nreviewing the interaction between data frameworks and cross-border payments, BB8\non fostering KYC and identity information sharing, BB14 on adopting a Harmonized ISO\n20022 version for message formats, including rules for conversion/mapping, and BB15\non APIs).\n\n3) The FSB and member jurisdictions should:\n\nm Support, as appropriate, ROC’s and GLEIF’s initiatives to address obstacles to broader\nLEI adoption (e.g. costs, lack of awareness of incentives and data quality), including\nthe validation agent model, bulk registration and vLEl in continuing the work of the G20\nroadmap.\n\n4) The ROC members and GLEIF should, according to their respective mandates:\n\nm Continue their efforts to increase adoption of the LEl (including by non-financial\ncorporates), promote timely update of the LEI reference data and ensure their quality,\nand explore further, with national regulators and others, the role the LEI might play in\nassisting entities with due diligence for KYC, as well as other use cases.\n\nm Set up pilot projects among relevant stakeholders regarding standards for including the\nLEl in payment messages and provide examples to financial institutions on possible\nuses of the LEIl when transmitted in payment messages.\n\nm Increase the visibility of the LEI through public outreach initiatives, particularly outside\nthe financial sector, and increase knowledge on the LEI to help address any perceived\nlack of benefits in cross-border payments. This should involve developing and\npublishing use cases in cross-border payments for non-financial corporates, and ways\nin which they can directly benefit from adopting the LEI.\n\n5) Relevant standard-setting bodies (e.g. BCBS, CPMI, I0SCO, FATF) and international\norganisations (IMF, OECD, World Bank) should:\n\nm Consider ways to embed or enhance references to the LEI in their work, in line with\nrecommendation 3 of the 2019 FSB Thematic Review on Implementation of the Legal\nEntity Identifier (LEI peer review). This could facilitate the implementation of relevant\nLEI uses for authorities and market participants, including for cross-border payments.\n\nm Consider issuing guidance and carrying out further outreach regarding sanctions,\ncustomer due diligence and wire transfers on how the LElI may be used as a\nstandardised identifier for sanctions lists or as the primary means of identification of\nlegal entity customers or beneficiaries, (in line with suggestions made in the FATF\nSurvey of October 2021 and consistent with existing FATF Recommendations).\n\nThe FSB will review progress in implementing these recommendations and publish a progress\nreport by end-2024, together with a review of progress in implementing the recommendations of\nthe LEI peer review.\n\n3\n","contentLength":2830,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:28:12.431Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/p070722.pdf","content":"Introduction\nThe G20 has made enhancing cross-border payments a priority, with the goal to make such\npayments faster, cheaper, more transparent and more inclusive, while maintaining their safety\nand security. In October 2020 the FSB published the G20 roadmap to enhance cross-border\npayments? to address the key challenges often faced by cross-border payments and the frictions\nin existing processes that contribute to these challenges.\nPoor data quality, fragmentation in data sources and limited standardisation of data exchange\ncause complexity when processing cross-border payments, which increases their cost, limits\nspeed and impacts transparency. To address data handling issues and improve compliance\nprocesses, the roadmap has prompted several initiatives to promote the use of common\nmessage formats, data exchange protocols, conversion and mapping approaches from legacy\nformats and standardised data. One of these initiatives is the consideration by the FSB of the\nscope to establish unique identifiers with proxy registries (Building Block 16 of the roadmap,\nBB16). In exploring the potential for, and the challenges to develop, a global digital unique\nidentifier for cross-border payments, the FSB agreed to take into account existing identifiers,\nincluding the LEI developed by the FSB in 2012.3\nThe LEIl was developed to uniquely identify counterparties to financial transactions across\nborders, and thereby to improve and standardise financial data for a variety of purposes; for\ninstance, to support a more accurate and timely aggregation of data on the same entity from\ndifferent sources, especially on a cross-border basis. The LEI is a 20-digit alphanumeric code\nbased on the ISO 17442 standard that uniquely identifies legally distinct entities.* It has no\nembedded intelligence but is connected to reference data that enables unique identification of\nlegal entities and provides some information on their ownership structure. The LEI and its\nassociated reference data are freely available open data.\n\nThis report explores the options to improve adoption of the LEI, as requested under the first\n\nmilestone of Action 2 of BB16 (see Annex 1 for the BB16 Actions and timeline). In preparing this\n\nreport, the FSB CPDI (Cross-border Payments Data and |dentifiers Group) has worked in close\ncoordination with GLEIF,5 the ROC® and national authorities. The ROC and GLEIF regularly\nassess the use and adoption of LEIl. This report includes examples of their work and is not\nintended to stand in the place of the ongoing broader work of ROC and GLEIF. In order to avoid\nduplication with the work of the ROC and within the Global LEI System (GLEIS),” this report\n\n2 FSB (2020), Enhancing Cross-border Payments: Stage 3 roadmap, October\n\n% see Global Legal Entity Identifier for Financial Markets (FSB, 2012)\n\n4 See ISO 17442; “legal entity” includes but is not limited to unique parties that are legally or financially responsible for the\nperformance of financial transactions or have the legal right in their jurisdiction to enter independently into legal contracts,\nregardless of whether they are incorporated or constituted in some other way (e.g. trust, partnership, contractual). It includes\ngovernmental organisations, supranationals and individuals when acting in a business capacity 1), but excludes natural persons.\nIt also includes international branches.\n\n5 For further information about GLEIF see here.\n\n6 The ROC, a group of approximately 65 public sector authorities, was established in November 2012 to oversee the GLEIS’s\nresponsibility of issuing and maintaining LEls. For further information about ROC see here\n\n7 In June 2012 the FSB issued recommendations to set up the GLEIS, comprised of a central unit, the not-for-profit GLEIF, and\nseveral local LEI issuing organisations (so-called Local Operating Units) that provide an LEI code to registrants at local level.\nThe GLEIS was set up to allow legal entities from all around the world to register for an LEI and as safekeeper of the uniqueness\nand exclusivity of LEI codes.\n\n4\n","contentLength":4063,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:28:12.431Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/p070722.pdf","content":"focuses on governance and technical aspects only to the extent that these are relevant for\nbroader adoption of the LEI in markets that are cross-border, whose participants usually engage\nin cross-border payments and that directly impact entities connected to cross-border payments.\nThe report takes account of the 2019 FSB Thematic Review on Implementation of the Legal\nEntity Identifier (LEl peer review)® and will also inform future FSB follow-up on the\nrecommendations set out in the peer review.\nWhile the LEI is designed to identify legal entities (and individuals acting in a business capacity),\nit does not contain attributes to identify natural persons or link a legal entity to a natural person.\nUnder Action 1 of BB16, the FSB CPDI is reviewing the scope and technical and operational\nrequirements of existing and proposed digital identifiers® for both legal entities and natural\npersons and analysing the need for a decentralised proxy registry. ° It plans to finalise a separate\nreport by October 2022\"\" to explore the scope for, and obstacles to developing, a global digital\nunique identifier for cross-border payments, and potentially other financial transactions, that\ntakes into account existing identifiers, including the LEI for legal entities and identifiers for\nindividuals. If there is consensus that a new identifier is necessary specifically for the purpose\nof cross-border payments, other actions will follow, such as to propose standard design\nprinciples for proxy databases and define minimum requirements for personal identifiers.\n\n1. Survey of member authorities and outreach with market\n\nparticipants\n\nThe potential benefits of the use of the LEI in cross-border payments have been explored in\n\nseveral jurisdictions, as explained later, albeit to a lesser extent than in some other use cases\n\n(e.g. derivatives markets).'? Standardisation of data, data sharing and more efficient\n\nreconciliation and compliance processes — all issues that could potentially be addressed by a\n\nglobal identifier such as the LEI — are aspects that were prominent in the design of the roadmap\n\nand that came up strongly also in the stocktaking exercises conducted in the initial phase of the\nwork under the roadmap.\n\nTo shed more light on such potential benefits, and to relate them more directly with the specific\n\ncharacteristics of the LEI, the FSB carried out a survey among its member authorities in early\n\n2022, followed by an outreach event in April 2022 with representatives from banks, financial\n\nmarket infrastructures (FMIs), mobile money operators, international credit card companies and\n\nnon-bank payment service providers engaged in cross-border e-commerce and remittance\nactivities as well as industry bodies. Participation was balanced to ensure a mix of industry and\nregional representation. In both cases, the goal was to explore whether and how broader\nadoption of the LEI across jurisdictions could provide benefits for the processing of cross-border\n\n8 FsB (2019), Thematic Review on Implementation of the Legal Entity Identifier, May.\n\n® An identifier is an attribute or set of attributes that uniquely characterises an identity in a domain (See: Final Report of JFSA\nMultilateral Joint Research on Digital Identity, Nomura Research Institute, June 2020). One such identifier currently under\ndevelopment is the ISO Natural Person Identifier (NPI). See here.\n\n10 Proxy registries are decentralised structures linking digital unique identifiers with the account information of the payer and the\npayee. (see CPMI 2020 Enhancing cross-border payments: building blocks of a global roadmap. Stage 2 report to the G20 —\ntechnical background report).\n\n11 FSB 2021 G20 Roadmap for enhancing cross-border payments: First consolidated progress report.\n\n12 A recent example of increased attention is SWIFT's PMPG, Global adoption of the LEl in ISO 20022 Payment Messages 2021.\n\n5\n","contentLength":3902,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:28:12.431Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/p070722.pdf","content":"payments, including related to customer due diligence, facilitating greater STP, reducing\n\npayment fraud, improving transparency in the payment chain, and enabling faster and simpler\n\nreconciliation. Participants were invited to share views on ways to improve the adoption of the\n\nLEI and identify main challenges to the broader adoption of the LEI and to its use in cross-border\n\npayments. A dedicated outreach was also conducted by the GLEIF to explore these themes\n\namong business partners, including Local Operating Units (LOUS).\n\n1.1. Survey of member authorities™\n\nSeveral surveyed FSB member authorities highlighted the potential benefits of including LEI\n\nwithin cross-border payment messages to improve the efficiency of the payment process and\n\npromote STP: by including the LEI in a dedicated payment message field that processing\nsystems can capture, legal identities involved in the transaction can automatically be identified.\n\nChina has also expressed support outside the survey for widening the adoption of the LEI in\n\ncross-border payments. 14\n\nA few members pointed to operational efficiencies that could be gained in the KYC due diligence\n\nprocess, suggesting that the LEI could help in streamlining the monitoring and onboarding\n\nprocesses. Such automated reconciliation and validation could be achieved by including the LEI\nboth in payment messages and KYC utilities, provided that banks map the LEI with proprietary\ncustomer identification numbers.'® Similarly, a member noted that a widespread adoption of the\n\nLEI in cross-border payments would support compliance monitoring and also reduce the risk of\n\npayments being delayed, making LEI benefits tangible for legal entities of all sizes.\n\nSeveral members noted that, for the benefits of LEI use in cross-border payments to be realised,\n\nadoption of the LEI would need to be widespread. In this regard, some members noted that\n\nissues such as cost and data validity and protection should be considered as well as the\nawareness of business cases for voluntary adoption by market participants. These aspects are\n\nfurther explored in Section 3.2.\n\n1.2. Outreach event\n\nIndustry representatives echoed the perceptions of the official sector regarding the benefits that\n\na wider adoption of the LEI could bring to cross-border payments in terms of efficiency and\n\nsecurity, as well as the attendant challenges and potential solutions to achieving that goal.\n\nIt was recognised that the adoption of unique identifiers such as the LEI could streamline\n\npayment flows and be an important element for enabling the KYC and sanction screening\n\nprocesses. Participants cited the following as the goals to be achieved to facilitate wider use of\nthe LEI beyond the financial sector:\n\n3 The list of survey respondents is in Annex 2.\n\n4 In Promote LEI in RMB Cross-border Payment Ecosystem, China’s Cross-border Interbank Payment System has introduced its\nuse case for use of LEI in cross-borders payments as well as its perspective on the relevant benefits and challenges.\n\nS Two FSB members noted that in the future a broader availability of the information on the direct and/or ultimate parent entity\nencompassed in the more advanced reference data of the LEI (the Level 2 data, see Box 1) could help compliance check\nprocedures and the analysis of inter-group payments.\n\n6\n","contentLength":3337,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:28:12.431Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/swift_global_adoption_of_the_lei_finaldraftv1.pdf","content":"2, PMPG\n- A\n(f | § Payments Market Practice Group\nS\\\nWhite paper\nNote:\nThe Payments Market Practice Group (PMPG) is an independent body of payments subject matter\nexperts from Asia Pacific, EMEA and North America. The mission of the PMPG is to:\n. Take stock of payments market practices across regions\n. Discuss, explain, and document market practice issues, including possible commercial\nimpact\n. Recommend market practices, covering end-to-end transactions\n. Propose best practice, business responsibilities and rules, message flows, consistent\nimplementation of ISO messaging standards and exception definitions\no Ensure publication of recommended best practices\n. Recommend payments market practices in response to changing compliance\nrequirements\nThe PMPG provides a truly global forum to drive better market practices, which, together with\ncorrect use of standards, will help in achieving full STP and improved customer service.\n1|Page\n","contentLength":942,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:28:50.526Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/swift_global_adoption_of_the_lei_finaldraftv1.pdf","content":"Table of Contents\nTable Of CONTENES ...ttt et ettt ettt e bt e st aesbtesbtesnbesnbesnbeenbeanneansenss 2\n1 EXECULIVE SUMIMAIY . .uiiiiiiiiiee ettt teee et ee e e e ee ettt beeeeses s st bt teeees s sssntbeaeaeessasassnnseaeaeassnsnssnaeeeenes 3\n2 Status and UpPtake Of the LE|........ecceir ettt e et te st ae s e eate e e tae s aaeennaesneeennes 3\n2.1 RTGS INIQ ettt ettt et ettt et e et st e et e e b e e st e e sabe e s b beeneeesaneeesnbe e nseannseesneeesanees\nA =¥ 1o QoY il X o T={ T o o ST TOUPSSRPRSY\n2.3 ESRB (European Systemic Risk BOArd) ........cccveecuieeieieiieiesiie e tie et sssteseee e e stee s naesneeenees D\n2.4 EUrOPEAN COMIMISSION «..ueiiiiiiieieeeeisiitieteeeeseesiarteteeeessesubarteteeeassasnnsreteeessasssssnssseeeeesanssssnsseeeseenans O\n2.5 Financial Stability BOArd (FSB)........cccuiiiiieiiiieceeestie e stie et eestte s s steessteeeteeesttessssaesnnessssessnsaesnasens O\nO U - 11O P PR PUPURPPRPRPPPRR -\n3.1 Use €ase 1 - SANCLIONS SCrEENINEG .....uuuiiiiiieie ettt e ettt te e e ee et rete e s esseabrr e eeesessssnrreaeeeenens &\n3.1.1 Use case 1 - Sanctions SCreening — diagram ......cocvueieiiiieieiiiieie e esrieee e ee s ee s ee e seees &\n3.2 Use case 2 — Know Your Customer (KYC), Screening for Customer on-boarding...........c.cccvee...nr. 9\n3.2.1 Use case 2 — KYC, Screening for Customer on-boarding - diagram .........cccccceeevvevvenciieeneeen... 10\n3.3 Use Case 3 — Corporate Invoice Reconciliation..........cccceevveeiiiiieieiinieie e e cssieeeessieeeanns 10\n3.3.1 Use Case 3 — Corporate Invoice Reconciliation — diagram .......ccccccveeveevieeeicvieencesieeesesienn e 11\n3.4 Use Case 4 — Corporate Treasurer - Fraud detection and fight against vendor scams .............. 12\n3.4.1 Use Case 4 — Corporate Treasurer - Fraud detection and fight against vendor scams —\nLo =Y ={ =1 1. [T K\n3.5 Use case 5 — Account to account owner Validation.........coccceeveriieinnieiiiie e 14\n3.5.1 Use case 5 — Account to account owner Validation 2 Scenarios:- a) Conformation Of Payee\nand b) Creditor Agent Validation - diagram.........ccccccueeciieciiisie e ceesseesvee e e e s sveesseee e 14\n4 Becoming @ Validation AGENt.........uuiii ittt sttt s tte s st te e s srte e s s nae e s snnaeassnnneees 1D\n4.1 FI's acing as Validation Agents can benefit from ........ccccccveceie s 15\n5 Summary of Benefits that the LEI Bring ........cccuve et stte e se e s stteaseae e 16\nB N XL SEOPS 1ot iieiiieit ettt ettt e e e e e st b e teeees st bt beteeees e sanbntaeteeseneasnnrnnteeeeeanensnsanaeseesanaass 1T\n2|Page\n","contentLength":2537,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:28:50.526Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/swift_global_adoption_of_the_lei_finaldraftv1.pdf","content":"The Creditor Agent can proceed with the payment to creditor — no need to\nlose time to re-verify the creditor identity.\nOnce the creditor is paid, the notification of payment status is sent to the\ndebtor\nBenefits e Automation - no need for manual name reconciliation\ne Trust, authenticity and reliability of documents\ne Better client user experience\ne Flag possible fraud attempts — strengthen existing KYC procedures\ne Full transparency of parties to the transaction from start to end\ne LEI, BIC can be obtained with single call to open GLEIF API\ne Standardize customer reference data and provide richer datain a\nstructured format\n¢ Increase comprehensiveness of the 1ISO 20022\ne Encompassing coverage- no limitation of jurisdiction or operating system\ne Interoperability across various platforms/systems\nChallenges / The Debtor Agent must verify the debtor/creditor LEIs before initiating the\nImplications payment to the Creditor Agent\nMarket Practice Not Applicable\n3.3.1 Use Case 3 — Corporate Invoice Reconciliation — diagram\nAn elnvoice is signed\nwith the Debtor LEI The Debtor Verifies Debtor sends Payment Debtor sends Payment\nand an embedded the Supplier to the Debtor Agent to the Debtor Agent\ndigital certificate\nThe Digital certificate The Debtor can verify The Debtor Agent can The Creditor Agent\nenables data to be the supplier by verity the Creditor can proceed with the\nautomatically parsed. utilising the GLEIF API Agent and Creditor payment without\nagainst the LEl and the Party by a single call having to re-verify the\nsuppliers identity. using the LEI. Creditor identity.\nThe parties to a\npayment transaction\ncan be consistently\nverified and validated\nfrom very start to the\nend, which means less\noperational and\ncompliance costs for\nall parties to the\ntransaction\n11| Page\n","contentLength":1793,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:28:50.526Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/swift_global_adoption_of_the_lei_finaldraftv1.pdf","content":"3.4 Use Case 4 — Corporate Treasurer - Fraud detection and fight against vendor\nscams\n\nDescription Today, vendor scams happen very often as suppliers and vendors mainly use\n\nemails for exchanging information regarding payments. Using emails as the\nmain instrument for bank account information provides a convenient basis for\nfraudsters. Fraudsters contacts the supplier acting as an accounting officer of\nthe vendor and asks about information relating to the current payment of\ninvoices. Second, they contact the vendor, acting as your supplier. The\nfraudster notifies a bank account change, and sends the vendor real invoices,\nwith modified account number and bogus telephone numbers.\n\nMost of the times fraudulent activity occurs due to the fact that the buyer\ndoes not notice very small differences in the email address. This fraud is\ngenerally detected too late to expect a fund recall.\n\nIf a secure mechanism is established between the vendor and supplier, the\nfraud detection can be maximized and vendor scams can be reduced.\nVendors will ask their suppliers:\n\n- to provide their LEI\n\n- to own a elDAS legal representative or business stamp, or a digital\ncertificate with LEl embedded\n\nStarting from the first time, whenever a supplier wants to communicate its\nbank account number for payments, it will be done using a secure mechanism\nbased on the LEI.\n\nBenefits e The vendor shifts the responsibility of correct information to the supplier\nby bringing the requirement that the document submitted to be signed\nwith the LEI embedded digital certificate.\n\ne The vendor and supplier have a secure and digital way of information\nexchange which the LEl is the common denominator.\n\ne When the LEl and the bank account does not match in the Enterprise\nResource Planning (ERP) of the vendor, vendor gets a notification that this\ncan be a fraud attempt. The LEI helps to detect fraud attempts in an early\nstage.\n\ne Ifthe LElis included in the payment order from vendor to the bank and\nbank checks the IBAN and LEI, the fraud can be totally avoided.\n\nImplications certificate.\n\n12| Page\n","contentLength":2084,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:28:50.526Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/swift_global_adoption_of_the_lei_finaldraftv1.pdf","content":"3.4.1 Use Case 4 — Corporate Treasurer - Fraud detection and fight against vendor\nscams —diagram\nSupplier sends Vendor extracts the .\nAccount number to Certificate Vendor Validates Cred|t9r Agent\n: : Validates\nVendor information\nThe supplier The vendor’s ERP The vendor’s ERP When Bank receives\ngenerates a parses the document, using extracted LEI the payment order, it\ndocument (according extracting the code checks (using checks if the IBAN of\nto the format certificate GLEIF’s API) that this th.e sypplier matches\nexpected by the information including LEI matches with the with its LEI.\nvendor’s Enterprise the LEI code and IBAN supplier’s LEI.\nResource Program number\n(ERP)) containing the\nbank account number\nfor payments. If the LEl code\nmatches the\nprovider’s data, the\nThe supplier signs the g s> bank .\n. account number is\ndocument by using a .\n- e . considered correct as\ndigital certificate with gy . .\n) it is contained in a\nits LEl embedded g .\ndigitally signed\ndocument and it is\nadded to the ERP’s\nThe supplier sends valid records for\nthe document to the further payments.\nvendor\n13| Page\n","contentLength":1104,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:28:50.526Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/swift_global_adoption_of_the_lei_finaldraftv1.pdf","content":"3.5 Use case 5 — Account to account owner Validation\nDescription When matching a name of a client to an account on an incoming payment\nor as part of Confirmation of Payee, as there are so many permutations for\nhow a name can be written, the matching criteria must allow for a certain\nlevel of mismatch and the validation between the name and account\nnumber can take longer than necessary. If LEl is provided, then this is an\nexact identifier that can provide a 100% match and validation in\nmilliseconds. This can also identify fraudulent payments or money\nlaundering by ensuring that the account being credited matches the LEI\nprovided for the Creditor. This validation can be performed by the\nCreditor Agent.\nBenefits e Exact matching criteria for account to account owner.\ne Speeds up the matching process to milliseconds\ne Helps the Creditor Agent perform a level of validation when receiving a\npayment, to ensure that the Creditor LEI matches the account number\nthat they hold for that client / Legal entity.\nChallenges / e The Uptake of LEIl across the Industry\nImplications\nMarket Practice Not applicable\n3.5.1 Use case 5 — Account to account owner Validation 2 Scenarios:- a) Conformation\nOf Payee and b) Creditor Agent Validation - diagram\nConfirmation of Match of Name to LEl provided Client A, Bank A — Client B, Bank B —\nPayee Inititated Account instead of name payment initiated payment received\nWhen a Client When a name is If an LEI was Client A initiates a When Bank B\ninitiates a provided by a provided instead payment from Bank receives the\npayment, there is client, to match of orinsurplus to Ain order to Pay payment a\nan opportunity to this against the the name, this is Client B in Bank B. validation check can\nutilise the KYC name held is an exact Id, there Bank A will populate be performed\nConfirmation of not always an can be no Client A’s LEl into against the LEI\nPayee exact science. interpretations of the Debtor provided for Client\nfunctionality. This Thereis a format/spelling information B and the KYC\nproduct will matching and therefore a element from their information that\nmatch the tolerance which match can be KYC data held on they hold on Client\ncreditor name to may be applied made in their client and B. If thereis a\nthe account and and the process millisecond and Client A should mismatch, they can\nconfirm if there is can take some no tolerance provide the LEI for reject the payment.\na match. time matching is Client B within the If there is a match,\nrequired. Creditor then the payment\ninformation within can be completed.\nthe payment\ninstruction\n14| Page\n","contentLength":2599,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:28:50.527Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/swift_global_adoption_of_the_lei_finaldraftv1.pdf","content":"4 Becoming a Validation Agent\nThis section of the document explains what a validation agent is and what benefits can be realised\nby Financial institutions becoming Validation Agents.\nThe information that FI's gather in order to KYC and on-board clients is the same information that is\nrequired in order to issue an LEl (Document, Data collection and Verification procedures) by an LEI\nIssuing Organization. Therefore (as mentioned in use case 4) there is an opportunity for FI's to\nbecome Validation Agents which means they can provide LEI’s to their corporate clients in\ncollaboration with LEI Issuer Organization(s).\nFor clients and LEI Issuers, the processes to issue an LEI requires time and effort to complete. The\ncollection and validation and delivery of data can require several exchanges and incur periods of\nprocessing between each and multiple rounds of communication. This can cause duplication\nbetween Fl and LEl issuer and cause frustration for the client due to the additional processing time\nand an inconvenient customer experience.\nNow that LEl is becoming a mandatory data element to be provided in payments in some Countries\nthere will be some clients that need an LEl in order to fully on-board. In this case an FI’s own time to\nrevenue is impacted as the Onboarding process cannot be completed until the client obtains an LEI.\nA significant opportunity therefore exists to address these issues by de-duplicating the entity\nidentification procedures that are currently shared between the Fl and the LEl issuer.\nThe creation of the Validation Agent framework empowers FI's to leverage their existing “Know your\ncustomer” (KYC), anti-money laundering (AML) and other regulated business as usual Onboarding\nprocesses, to obtain an LEI for their client when verifying their identity during the initial Onboarding\nor stand client refresh update procedures. FlI's acting as Validation Agents can liaise with the LEI\nissuer on its client’s behalf to validate that these key data checks and processes have been\nundertaken.\n4.1 FI’s acing as Validation Agents can benefit from\ne Agreatly streamlined LEl issuance process for clients, resulting in an enhanced client\nexperience for Onboarding and lifecycle management.\ne Digitisation of its Onboarding processes based on standardised Legal entity data instead of\nsiloed information and legacy systems.\ne Additional opportunities to add client value and achieve market differentiation\ne Enhanced Internal data management processes and therefore reduced costs\ne Auniquely powerful foundation upon which to innovate and develop new digital services\nand revenue opportunities.\n15|Page\n","contentLength":2641,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:28:50.527Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/swift_global_adoption_of_the_lei_finaldraftv1.pdf","content":"5 Summary of Benefits that the LEI bring\nCorporate invoice reconciliation e Automation - no need for manual name reconciliation\n\ne Trust, authenticity and reliability of documents\n\ne Better client user experience\n\ne Flag possible fraud attempts — strengthen existing KYC\nprocedures\n\ne Full transparency of parties to the transaction from\nstart to end\n\ne LEI, BIC can be obtained with single call to open GLEIF\nAPI\n\ne Standardize customer reference data and provide\nricher data in a structured format\n\ne Increase comprehensiveness of the I1SO 20022\n\ne Encompassing coverage- no limitation of jurisdiction\nor operating system\n\ne Interoperability across various platforms/systems\n\nFraud detection and fight against e The vendor shifts the responsibility of correct\n\nvendor scams information to the supplier by bringing the\nrequirement that the document submitted to be\nsigned with the LEl embedded digital certificate.\n\ne The vendor and supplier have a secure and digital way\nof information exchange which the LEl is the common\ndenominator.\n\ne When the LEl and the bank account does not match in\nthe Enterprise Resource Planning (ERP) of the vendor,\nvendor gets a notification that this can be a fraud\nattempt. The LEI helps to detect fraud attempts in an\nearly stage.\n\ne If the LEl is included in the payment order from vendor\nto the bank and bank checks the IBAN and LEI, the\nfraud can be totally avoided.\n\nSanctions screening e By adding an LEl into exclusion / white lists, false\npositive matches can be prevented.\n\ne Requests for information can be supported with\ninformation held at GLEIF again Legal Entities quoted\nin a payment\n\nKYC, Screening for Customer e Makes KYC processes quicker and more efficient for\nOnboarding FI's\n\ne Reduces Onboarding costs 5-10%\n\ne Reduces the risk of AML fines\n\ne Improves the Client experience\n\ne Reducing the risk of clients being misidentified\n\ne Improves internal data management processes at the\nFl and ensures, greater consistency with standardized\nentity reference data\n\n16|Page\n","contentLength":2023,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:28:50.527Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/swift_global_adoption_of_the_lei_finaldraftv1.pdf","content":"e Industry level re-use of KYC data across Fl’s can be\n_\nAccount to Account Owner e Exact matching criteria for account to account owner.\n\nValidation e Speeds up the matching process to milliseconds\ne Helps the Creditor Agent perform a level of validation\nwhen receiving a payment, to ensure that the Creditor\nLEl matches the account number that they hold for\nthat client / Legal entity.\nLEIl in digital trade finance e The LEl can play a role in facilitating interoperability\ndocumentation across trade platforms. For example, in a digital letter\nof credit, Fls can easily verify counterparties thanks to\nthe LEl in a few seconds instead of lengthy paperwork\n-\nGeneral e Improves Straight Through Processing / Fast tracks\npayments\ne Data Management in Fls: Improved quality and\naccuracy of data\ne Use of LEIl for ordering party in outbound payment for\nprecision and full transparency\ne Use of LEI for beneficiary in outbound for precision\nand full transparency\ne Use of mapping of BIC to LEI via GLEIF APl or SWIFTRef\nBIC-LEI Relationship File https://www.swift.com/our-\nsolutions/compliance-and-shared-\nservices/swiftref/swiftref-bic-lei-relationship-file\ne Unique identifier for FI's that can be used across\nmultiple applications\n6 Next Steps\nWith the LEI being a mandatory identifier that is already required within certain payments, the scope\nof the Payment messages that mandate LEI will increase across the communities and Industry. The\nLEl is part of the FSB’s approach to improving Cross Border Payments and is being adopted across\nMarket Infrastructures at a fast pace. As outlined within this paper there are true benefits that the\nLEI can bring to both Financial Institutions and Corporate / Business Banking clients. It is imperative\nthat FI’'s communicate to their clients which payments will require LEI to be present and also the\nbenefits that they can realise once they utilise the LEI’s such as increased STP and faster more\nefficient payments. In order to unlock the full benefits, Financial Institutions should take up the\nopportunity to become Validation Agents which will not only improve the KYC processes across the\nindustry but will also provide their clients with the ability to use their Fl as a one stop shop when\nwanting to open accounts and obtain LEI's. The LEI should be embraced across the industry and\nlooked at as a great opportunity to improve rather than any type of burden for Financial institutions\n17 |Page\n","contentLength":2447,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:28:50.527Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/swift_global_adoption_of_the_lei_finaldraftv1.pdf","content":"or their Corporate / Business Banking Clients and a strong request for regulators to support the LEI\nby adding it into the Sanctions lists.\n18| Page\n","contentLength":149,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:28:50.527Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/swift_global_adoption_of_the_lei_finaldraftv1.pdf","content":"1 Executive Summary\n\nThe Payment Market Practice Group (PMPG) have previously published three papers on the use of\n\nLEI.\n\ne LElin the Payments Market 2017 - https://www.swift.com/swift-resource/39741/download\n\ne LEl in the Payments Market 2017- https://www.swift.com/swift-resource/139861/download\n\ne The Adoption of LEl in Payment Messages in 2019 - https://www.swift.com/swift-\nresource/229631/download\n\nWhen these white papers were written, the SWIFT FIN MT ! format was still in use which meant that\n\nthe ability to utilize the LEI was limited.\n\nWith the implementation of ISO 20022 across multiple Market Infrastructures and Cross Border\n\nmessaging, the benefits of the LEI can be fully realised.\n\nThis paper sets out to provide Market Practices on the LEIl as an identifier in payments and to\n\nprovide clear use cases, with benefits for participants, for more transparent, efficient and secure\n\npayments.\n\nLEI provides improvements across numerous use cases, this paper provides an overview of how the\n\nLEI can be used in the Sanctions screening space (with even more potential improvements once the\n\nregulators come on board and add the LEl into the sanctions screening lists) reducing fraud for\n\nCorporate Treasurers, account to account owner validation and also improvements across the\n\nindustry for Know your Customer (KYC) processes.\n\n2 Status and Uptake of the LEI\n\nCountries are moving to adopt LEI as a mandatory requirement in their ISO 20022 messages. So\n\nmarket participants will need to be prepared for this even if there are countries that don’t mandate\n\nthe LEI. This section outlines the current status of the update of the LEI across the globe.\n\n2.1 RTGS India\n\nEffective from April 1, 2021 issued under Section 10 (2) read with Section 18 of Payment and\n\nSettlement Systems Act, 2007 (Act 51 of 2007) States that all non-individual customers initiating or\n\nreceiving transactions of X50 crore and above through RTGS and / or NEFT must provide an LEI\n\nwithin the payment message.\n\nTechnical guidance on how the LEI should be carried:\n\nIn NEFT payment messages, the field 7495 is a free format optional field consisting of 6 lines with 35\n\ncharacters each with alphanumeric options. The first two lines of this field shall be used for capturing\n\nsender and beneficiary customer LEl information, in that order, where applicable and available.\n\n1The SWIFT MT message standard is split into four areas, Payments, Trade Services, Securities and Trading. A complete inventory of available SWIFT MT messages\n\ncan be found on SWIFT's website\n\n3|Page\n","contentLength":2564,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:28:50.527Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/swift_global_adoption_of_the_lei_finaldraftv1.pdf","content":"When LEl information is captured, narration, remarks, etc., shall be part of last 4 lines of the field.\nThe sender and beneficiary information shall be captured in following format:\n\n7495: line 1 -> SL/20 digit sender LEI/\n\nline 2 -> BL/20 digit beneficiary LEI/\n\nii. In RTGS customer payment and inter-bank messages, the optional field “<-RmtInf->\" has 4 repeat\ntags with each having 140 characters. The first two loops of this field shall be used for capturing\nsender and beneficiary customer LEl information, in that order, where applicable and available.\nWhen LEl information is captured, narration, remarks, etc., shall be part of last two repeating loops\nof the field. The sender and beneficiary information shall be captured in following format:\n<-RmtInf->loop 1 -> /SL/20 digit sender LEI/\n\nloop 2 -> /BL/20 digit beneficiary LEI/\n\n2.2 Bank of England\n\nFrom Phase 2.1 (February 2023):\n\nAlong with Purpose Codes, LEIs will be introduced into ISO 20022 standard CHAPS payment\nmessages from February 2023 on an ‘optional to send’ basis. The Bank of England encourages all\nCHAPS Direct Participants (DPs) to start using LEls as early as possible, once the DP is capable of\nsending enhanced data. However, this will not be made mandatory until spring 2024. This allows DPs\ntime to introduce LEls and capabilities based on this data gradually, without the risk of incorrect LEI\nusage. The Bank of England will however monitor the use of LEls in payments during this optional\nsend period.\n\nFrom Phase 4 (Spring 2024):\n\nThe Bank of England will start mandating LEIs to be used in by certain circumstances, with a vision to\nwiden out the requirement to all participants over time. The Bank of England will mandate the use of\nthe LEl where the payment involves a transfer of funds between Financial Institutions. This will be\ndefined by a CHAPS payment made via a pacs.009 payment message or via a pacs.008 payment\nmessage where the ultimate sender and ultimate beneficiary are both Prudential Regulation\nAuthority (PRA) authorised deposit-takers or broker-dealers, or a Financial Market Infrastructure\nsupervised by the Bank of England.\n\nMost institutions that make these payments already possess LEls. Although not mandatory for\nothers at this stage, the Bank of England strongly encourages other institutions to apply for an LElI,\nand to prepare and implement necessary changes, particularly where firms may already be planning\nsystem changes, in anticipation of the Bank of England extending its LEl mandate. The Bank of\nEngland notes that the earlier firms adopt the LEl, the sooner they will derive its benefits. The Bank\nof England will monitor the use of LEI for all transactions and will keep under review whether the\nmandatory requirement to include LEI data should be extended to all CHAPS payments.\n\nAs LEIs become more prevalent, the Bank of England will expand their requirement in CHAPS\npayment messages to more users. As mentioned above, the Bank of England is working with all\nrelevant stakeholders to progress the uptake and implementation of LEls in the UK. The Bank of\nEngland also recognises CHAPS as a useful mechanism to extend the uptake of LEls in the UK. The\nBank of England will monitor the uptake and use of LEls for CHAPS payments and the rate of\nadoption across the wider UK economy and will use this information to review and determine how\nthe mandatory requirements to include Purpose Code data should be extended to all CHAPS\n4|Page\n","contentLength":3464,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:28:50.527Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/swift_global_adoption_of_the_lei_finaldraftv1.pdf","content":"payments. The Bank of England will provide industry with at least 18 months’ notice in advance of\nextending any mandatory requirements for LEls.\n\n2.3 ESRB (European Systemic Risk Board)\n\nThe ESRB has published a Recommendation on identifying legal entities which holds 2\nrecommendations: -\n\nRecommendation A — Introduction of a Union framework on the use of the legal entity identifier\n1. The Commission is recommended to propose that Union legislation incorporates a common Union\nlegal framework governing the identification of legal entities established in the Union that are\ninvolved in financial transactions by way of a legal entity identifier (LEl), paying due regard to the\nprinciple of proportionality, taking into account the need to prevent or mitigate systemic risk to\nfinancial stability in the Union and thereby achieving the objectives of the internal market.\n\n2. The Commission is recommended to propose that Union legislation that imposes an obligation on\nlegal entities to report financial information, while paying due regard to the principle of\nproportionality, include the obligation to identify by way of an LEI: (a) the legal entity subject to the\nreporting obligation; and (b) any other legal entity about which information must be reported and\nwhich has an LEL.\n\n3. The Commission is recommended to propose that Union legislation incorporates an obligation on\nauthorities to identify by way of its LEl any legal entity about which they publicly disclose\ninformation and which has an LEl, paying due regard to the principle of proportionality, as expressed\nin the Recommendation.\n\nBy 30 June 2023, the Commission is requested to deliver to the European Parliament, to the Council\nand to the ESRB a report on the implementation of Recommendation A.\n\nRecommendation B — Use of the legal entity identifier until the possible introduction of Union\nlegislation\n\nPending any action taken by the Commission to comply with Recommendation A and the possible\nintroduction of corresponding Union legislation, it is recommended that to the extent permitted by\nlaw and subject to the principle of proportionality:\n\n1. the relevant authorities require or, where applicable, continue to require, all legal entities\ninvolved in financial transactions under their supervisory remit to have an LEl;\n\n2. the authorities, when drafting, imposing, or amending financial reporting obligations include or,\nwhere applicable, continue to include, in such obligations an obligation to identify by way of an LEI:\n(a) the legal entity subject to the reporting obligation; and (b) any other legal entity about which\ninformation must be reported and which has an LEl;\n\n3. the authorities identify or, where applicable, continue to identify, by way of its LEI, any legal entity\nabout which they publicly disclose information and which has an LEI.\n\nBy 31 December 2021, the addressees of Recommendation B are requested to deliver to the\nEuropean Parliament, to the Council, to the Commission and to the ESRB a report on the\nimplementation of Recommendation B.\n\n5|Page\n","contentLength":3059,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:28:50.527Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/swift_global_adoption_of_the_lei_finaldraftv1.pdf","content":"2.4 European Commission\n\nOn July 20™, the European Commission (EC) released its AML Package. Within the package, the EC\nofficially recognized the value of the Legal Entity Identifier (LEI) as a unique mechanism capable of\nsupporting transparency within any ecosystem, by formalizing it as an important component of\nfuture AML/CFT efforts:\n\n(A) Under the AML Regulation, Article 18 - Identification and verification of the customer’s\n\nidentity, the LEl is required, where available, for the identification of a legal entity; for a trustee of an\nexpress trust or a person holding an equivalent position in a similar legal arrangement and for other\norganizations that have legal capacity under national law.\n\n(B) The Revision of the 2015 Regulation on Transfers of Funds ensures that EU AML/ CFT rules are\nextended beyond their current remit, to fully apply to the crypto sector. This will ensure full\ntraceability of crypto-asset transfers and allow the prevention and detection of their potential use\nfor money laundering or terrorism financing.\n\nIn section (25), which outlines that transfers of funds or crypto-assets from the Union to outside the\nUnion should carry complete information on the payer and payee, a new requirement has been\nintroduced: “Complete information on the payer and the payee should include the Legal Entity\nIdentifier (LEI) when this information is provided by the payer to the payer’s service provider, since\nthat would allow for better identification of the parties involved in a transfer of funds and could\neasily be included in existing payment message formats such as the one developed by the\nInternational Organisation for Standardisation for electronic data interchange between financial\ninstitutions.”\n\nIn a later section that outlines the obligations on the payment service provider of the payer, Article 4\nof the Revision proposal sets out the requirements for information that must accompany transfers of\nfunds. In the latest revision, a new requirement for the payer’s current LEl has been added, “subject\nto the existence of the necessary field in the relevant payments message format, and where provided\nby the payer to the payer’s payment service provider....”.\n\n2.5 Financial Stability Board (FSB)\n\nThe Committee on Payments and Market Infrastructure (CPMI) created a set of 19 building blocks to\nhelp enhance cross border payments.\n\nBuilding block 16:- Establish unique identifiers with proxy registries - Providing a globally\nstandardised approach supporting the global Legal Entity Identifier for legal entities and a similarly\nstandardised identifier for individuals.\n\nThe following actions have been recorded within the Road map issued by the FSB\n\nAction 1 - October 2020 - December 2021 - Review the scope, technical and operational\nrequirements of existing and proposed global digital Identifiers for both legal entities and natural\npersons and analyse the need for a decentralised proxy registry.\n\nFSB, in consultation with CPMI, IMF, WB, GLEIF, ISO and other stakeholders, to explore the scope for,\nand obstacles to develop, a global digital Unique Identifier (Ul) for cross-border payments, and\n6|Page\n","contentLength":3154,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:28:50.527Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/swift_global_adoption_of_the_lei_finaldraftv1.pdf","content":"potentially other financial transactions, that takes into account existing identifiers, including the LEI\nfor legal entities and identifiers for individuals.\n\nThe review would also consider mechanisms to match Uls with payment information, such as via a\nproxy registry, take into account the work of relevant standard setting bodies, including the FATF, on\ntechnical, governance, or policy issues, and analyse how to map to existing identifiers.\n\nAction 2 - June 2021 - June 2022 - Determine the next steps to promote the use of a (global) digital\nUl framework and decentralised proxy registry in jurisdictions\n\nFSB in close coordination with GLEIF, the LEI ROC and national authorities to explore the options to\nimprove adoption of the LEI.\n\nDecember 2021 - October 2022 - If there is consensus that a new identifier is necessary, FSB, in\nconsultation with CPMI, IMF, WB, ISO and other stakeholders, to assess existing proxy databases for\npersonal identifiers, propose standard design principles for these databases, and define minimum\nrequirements for personal identifiers.\n\nAction 3 - December 2021 - October 2022 - If necessary: Implementation and progress monitoring.\nIf consensus is achieved on a possible new Ul and new interoperable proxy databases, FSB to create\nan appropriate governance for the Ul and for the interlinking of databases (based on the data\nsharing principles developed in BB 8). However, the decision to implement it should lie with the\nindividual countries (that may have to adjust regulation accordingly). October 2022 - October 2023\nUl-Governance body that is established to begin registering of participants. Start of the voluntary\nscheme. October 2023 - October 2024 National authorities to explore the processes involved in a\npossible adoption of a global digital unique identifier on a national level or the interlinking of existing\nidentifiers.\n\n7|Page\n","contentLength":1887,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:28:50.527Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/swift_global_adoption_of_the_lei_finaldraftv1.pdf","content":"3 Use Cases\nThis section of the document will outline various use cases where the LEI can be used. A description\nand flow diagram for each use case is present with associated benefits and any challenges or\nimplications that they bring.\n3.1 Use case 1 - Sanctions Screening\nDescription LEl being present on a payment can ensure that the processing of the\npayment is “fast-tracked”. The presence of an LEl can ensure that any\nSanctions hits can be resolved in a far more efficient manner. Utilization of\nthe GLEIF database can provide validation of data and provide rich\ninformation back to an operator regarding the legal entity within a\npayment.\nBenefits e By adding an LEl into exclusion / white lists, false positive matches can\nbe prevented.\ne Requests for information can be supported with information held at\nGLEIF again Legal Entities quoted in a payment\nChallenges / e The Regulators support is required in order to get the LEl added into\nImplications the sanctions lists\nMarket Practice Not applicable\n3.1.1 Use case 1 - Sanctions Screening — diagram\nPayment Initiated There is a\nby a Client with Deb'tor Agent will Sanctions Hit on GLEIF Database The Creditor LEI\nLEI present for the Sanctions screen the . can be used as\nthe Creditor check\nDebtor and outbound payment part of the RFI\n. Name\nCreditor\nThe Debtor LEI Currently, sanctions “ [ An API to GLEIF or The GLEIF\nwill be the KYC screening is based on ‘ alocally stored Databased holds\ninformation held legal entity names ‘ download of the rich data against\nwithin the client only. With nearly 1.5 GLIEF information each Legal Entity\nrecord. Million LEl issued, it can be used to and can help\nis possible to create/ search against the Compliance\nimprove “white lists” 7 9 LEI, validate the operators with\nThe Creditor LEI with the names and BIC code if Requests for\nwill be captured L {where N If LEI was added provided, name Information by\nat the point of gratlavle)of entities into the Sanctions and / or address. searchir}g against\npayment i okt Lists, then this can the LEl in the\ninitiation. sanctioned; whereby e Screening GLEIF Database\nthe use of the LEI ,\nL and increase\neliminates the N\nB effeciency\ngeneration of false\npositives that can\noccur by matching on\nname only.\n8|Page\n","contentLength":2253,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:28:50.527Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/swift_global_adoption_of_the_lei_finaldraftv1.pdf","content":"3.2 Use case 2 — Know Your Customer (KYC), Screening for Customer on-boarding\nDescription KYC / Onboarding has lots of limitations today. When onboarding clients\nthat may be part of the same legal entity or sub entity of the parent legal\nentity, there is nothing today which can confirm a group structure,\nrelationship between the legal entities of hierarchy. As the relationship to\nthe Legal Entity is unknown, onboarding can therefore need to be done\nfrom scratch and duplicated.\nCurrently there is no ability for FI’s to share KYC information. LEIl can\nprovide an Fl clear sight of the legal entity relationships and hierarchy and\nthis can ensure that clients are not misidentified. The LEI can provide FI's\nwith rich information about the legal entity instantly. The LEI can enable\nFI's to move to an environment where KYC information performed at\ndifferent Fls can be utilised and used to improve the onboarding process.\nThis can be done by FI's becoming Validation Agents.\nA Validation Agent is an Fl that has the ability to issue LEIs. The KYC\ninformation required for being issued an LEl, is the same information that\nis captured in order to onboard clients (KYC) at FI’s.\nBenefits e Makes KYC processes quicker and more efficient for FlI's\ne Reduces onboarding costs 5-10%?2\ne Reduces the risk of AML fines\ne Improves the client experience\ne Reduces the risk of clients being misidentified\ne Improves internal data management processes at the Fl and ensures,\ngreater consistency with standardized entity reference data\ne Industry level re-use of KYC data across Fl’s can be utilised\nChallenges / e Policy changes require for FI’s to be able to utilise the KYC performed\nImplications by other FI's across the industry\ne Fl uptake to become Validation Agents\ne The format of the Structured Address held at GLEIF does not match\nexactly to the 1ISO 20022 Structured Address format.\nAgent model)\n2 McKinsey Research is calculation is based on the FTE productivity gain of (10% to 15% [~2-4 hours] of ~25 hours per onboarding case) multiplied by percentage of total onboarding\ncosts attributable to FTEs (~57%) then multiplied by the estimated to industry spend on client onboarding ($40 billion per year). FTE productivity was based on “voice of customer” and\nexpert interviews and includes both the estimated reduction and FTE hours per onboarding case. Percentage of total client onboarding costs attributable to FTEs based on the average\ncost of FTEs in the client onboarding function at 10 tier-1 banks (McKinsey Cost Per Trade Survey) divided by total client onboarding cost (European Association of Corporate Treasurers).\nFor more details, please see: https://www.gleif.org/en/lei-solutions/mckinsey-company-and-gleif-leis-and-client-lifecycle-management-in-banking-a-u-s-4-billion-beginning\n9|Page\n","contentLength":2809,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:28:50.527Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/swift_global_adoption_of_the_lei_finaldraftv1.pdf","content":"3.2.1 Use case 2 — KYC, Screening for Customer on-boarding - diagram\nKYC — On- Client A .request Clie‘nt Bis a S‘ub— ! Client C is already on-\n: : on-boarding for a Entity/subsidiary Bank 2is a :\nboarding carried : Bank 1 becomes a o boarded at Bank 2, it\n: new branch or company of Client A o Validation\nout for Client A at o : Validation Agent now wants to on-board\napplication at and is on-boarded Agent : :\nBank 1 Bank 1 at Bank 1 as a client with Bank 1\nBank 1 }Nill carry Today, some FI’s There is no way for As the KYC When there are FI's\nout their K.YC may have FI’s to establish the performed by FI’s that are validation\nprocesses in or:der limitations or Legal Entity to on-board Agents, it means that\nto on—b.oard Client difficulties on- structure, clients is the same other Validation Agents\nA. If Client A boarding clients relationships or information used can utilise their KYC\nalrea(.iy hasan for different hierarchy today. to issue LEI, there information.\nassouatefi LEI, the applications or The GLIEF Database is an opportunity As the KYC in order to\non—boallll'dlng team branches and provides rich for Fi’s to become issue an LEl is carried\ncan utilise the . therefore KYC information about Validation Agents out formally by the\nGLIEF Databa§e in may need to be the Legal Entity and and have the Validation Agents and\nO.Fde.\" to Obta.'” carried out again all of their ability to issue the same due diligence\nrich information against the client subsidiaries / Sub LEl's. is carried out by those\nabo.ut the Legal in order to on- entities. This helps validation agents it\nEntity. board them to improve the KYC means their KYC data\nagainst new for the Fland the can be utilised between\nbranches/ client as the each other. The more\napplications. The relationship to a Validation agents that\npresence of the Legal entity that has there are, the more\nLEI can be used to already be KYC'd opportunity for FI’s to\nprovide assurance can be considered. share KYC information\nacross an entire Fl between each other\nthat the client is across the industry.\nwho they say they\nare and provide a\nconsistent\nidentifier against\nthe client.\n3.3 Use Case 3 — Corporate Invoice Reconciliation\nDescription Use of elnvoices (e.g., in UBL format) signed with debtor’s LEI embedded\ndigital certificates enables data to be automatically parsed and match the\nperson authorizing the payment with the entity.\nThe Debtor can verify the supplier by a single call using the supplier’s LEl and\nverify the supplier’s identity via GLEIF APl within milliseconds\n- if verified proceed with the payment order\n- if not stop the payment order\nThe Debtor Agent can easily verify the Creditor Agent and creditor by a single\ncall using the creditor agent’s and creditor’s LEl and retrieve the BIC for the\nCreditor Agent.\n10| Page\n","contentLength":2803,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:28:50.527Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/validation-agents/gleif-ebook-introducing-the-lei-validation-agent/2020-09-29_gleif-ebook-lei-validation-agent-framework_v1.1-final.pdf","content":"Introducing the LEI Validation Agent Framework\nA new role in the Global LEI System enabling financial\ninstitutions to simplify and accelerate LEl issuance\n0 LEGAL\nOy LE| .\n","contentLength":172,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:29:16.146Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/validation-agents/gleif-ebook-introducing-the-lei-validation-agent/2020-09-29_gleif-ebook-lei-validation-agent-framework_v1.1-final.pdf","content":"Introduction\nLegal entities that perform financial transactions in capital markets In its drive to encourage voluntary adoption and use of LEls across a\nare mandated by various regulatory bodies across the world to have broader portfolio of non-regulatory banking business lines, the Global\na Legal Entity Identifier (LEI). LEI Foundation (GLEIF) has reviewed these procedures and identified an\nopportunity to introduce efficiencies by creating a new operating role\nUntil now, the process of obtaining an LEI is most commonly within the Global LEI System. The goal is to streamline the LE| issuance\nundertaken when an entity is onboarded by a financial institution process and deliver a multitude of benefits, for legal entities,\n(F1), and usually occurs in the latter stages of this process. Alongside LE| Issuers and the Fls that serve legal entities as clients.\nan entity’s dealings with their FI during this process, the traditional\napproach to LEl issuance has required the entity to liaise directly with The role is called the Validation Agent.\nan LEl Issuing Organization, also known in the Global LEI System as\na Local Operating Unit (LOU). Depending on the complexity of the This eBook, the first in a series of publications exploring the Validation\nentity’s organizational structure, this liaison can require a number of Agent Framework’, defines the role and discusses the challenges it\nlabor intensive and time-consuming legal document and data collection addresses, together with the far-reaching benefits it promises to deliver\nprocedures to be performed to validate the entity’s identity before an to Fls, other stakeholders in the Global LEI System and the wider global\nLEI can be issued. Many of these are the same procedures that must financial ecosystem.\nalso be performed by the Fl at the point of onboarding\ntheir new client. This results in a level of process repetition for\nboth LEl Issuers and Fls, and often a extended, duplicative\nprocess for the legal entities themselves. b i\nIGLEIF invites enquiries and dialogue from the LEI ecosystem immediately and is seeking to :EEEE:..:-: ’\nengage with financial institutions wishing to participate in the Validation Agent trials. EEEE:’:'\n2\n","contentLength":2210,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:29:16.146Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/validation-agents/gleif-ebook-introducing-the-lei-validation-agent/2020-09-29_gleif-ebook-lei-validation-agent-framework_v1.1-final.pdf","content":"Next steps:\nL L L L L\n\nGLEIF invites Fls to trial the Validation Agent role\n\nGLEIF is actively engaging with\n\nthe global banking community to\n\nsupport trials of the Validation Agent oo\n\nFramework and to ensure that the :\n\nGlobal LEI System continues to : GLEIF is committed to supporting the banking industry’s @ %/\n\nmeet the sector’s needs. GLEIF is : widespread implementation of the LEI beyond = °\n\nnow inviting Fls to enquire about mandated requirements. The Validation Agent role -\n\nparticipation within the trial phase and helps financial institutions to improve their operations\n\nencourages immediate dialogue from and enable their customers to achieve their desired\n\ninterested parties. : financial transactions more quickly. By becoming\n: Validation Agents financial institutions can streamline,\naccelerate and diversify their use of the LEIl, and ensure\ntheir autonomy as they look to digitize their business\nprocesses. Considering that from a macro level, broader l ‘\nLEIl usage and increasing volumes translate into more 4 > N\\\n\n| | efficient financial transactions — from digitally signing ol N - . ™\n: contracts to financial markets participation. In this way, | il\nValidation Agents contribute to growth across the entire ~j;, ’;2 k4\necosystem, which will benefit all financial ecosystem 1\n: stakeholders, as well as the global economy !\n: °0 4\\\n-\nStephan Wolf,\n: CEO, GLEIF.\n% Like to learn more? Contact us at info@gleif.org\n11 >\n","contentLength":1447,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:29:16.146Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/validation-agents/gleif-ebook-introducing-the-lei-validation-agent/2020-09-29_gleif-ebook-lei-validation-agent-framework_v1.1-final.pdf","content":"About the Legal Entity . About the Global Legal Entity . History of the Global\nIdentifier (LEI) . Identifier Foundation (GLEIF) : LEI System\nThe Legal Entity Identifier (LEl) is a Established by the Financial Stability Board In 2011, the Group of Twenty (G20)\n20-character, alpha-numeric code based : in June 2014, the Global Legal Entity called on the Financial Stability Board\non the ISO 17442 standard developed : Identifier Foundation (GLEIF) is a not-for- (FSB) to provide recommendations for\nby the International Organization for : profit organization created to support the a global Legal Entity Identifier (LEI) and\nStandardization (ISO). The LEI connects © implementation and use of the Legal Entity asupporting governance structure. This\nto key reference information that : Identifier (LEl). GLEIF is headquartered in led to the development of the Global LEI\nenables clear and unique identification : Basel, Switzerland. © System which, through the issuance of\nof legal gn‘u‘ues parhupahng in .finanuall GLEIF services ensure the operational LEls, now p.r(.)wdes u.nllque. |d§nhf|cah9n\ntransactions. Each LEI contains information . . : of legal entities participating in financial\no ) : integrity of the Global LEI System. GLEIF also : ;\nabout an entity’s ownership structure, : . o © transactions across the globe. The FSB\n) . , ) , : makes available the technical infrastructure : ) .\nanswering the questions of ‘who is who : ) . . : emphasized that global adoption of the\n) , ) : toprovide, via an open data license, access : ) e . o\nand ‘who owns whom'. It provides a : . : LEl underpins multiple “financial stability\n) ) i o ) ) : to the full global LEI repository free of : B P ;\nuniversally recognized identifier paired with : : © objectives” and also offers “many benefits\n. . . e . charge to users. GLEIF is overseen by the : , ”\nessential entity data, rigorous verification : ) ) . © tothe private sector”.\nrocesses and high data lit : LEI Regulatory Oversight Committee, which :\nP 8 quatity. : is made up of representatives of public\n: authorities from across the globe.\nFor more information, visit the GLEIF\n© website at https://www.gleif.org/en.\nKR * :\n‘@, —> GLEIF Blog : 5\nSource:\nGlobal Legal Entity Identifier Foundation, St. Alban-Vorstadt 5, 4052 Basel, Switzerland \"’ GLOBAL\nChairman of the Board: Steven Joachim, CEO: Stephan Wolf :‘ ‘ IEEIGI'{-'\\I'LY\nCommercial-Register-No.: CHE-200.595.965, VAT-No.: CHE-200.595.965MWST g O IDENTIFIER\nLEI: 506700GE1G29325QX363 FOUNDATION\nThe content of this eBook is the property of GLEIF. Reproduction and/or sharing of this content is encouraged and\nmust be accompanied by a clear attribution to GLEIF.\n","contentLength":2678,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:29:16.146Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/validation-agents/gleif-ebook-introducing-the-lei-validation-agent/2020-09-29_gleif-ebook-lei-validation-agent-framework_v1.1-final.pdf","content":"L L L\n\nEnhancing Fls client experience:\nConsolidating duplicative onboarding and LEIl issuance processes\nWhen a legal entity liaises with an LEI Issuer to obtain an LEI, it must Perhaps unsurprisingly, it is the Fl that usually finds itself on\nsource and submit legal documentation pertaining to its legal status the receiving end of this frustration, despite the LEl issuance\nand ownership structure. process occurring independently and without their\n\ninvolvement. Added to that, an FI's own time to revenue\nIn the vast majority of cases, the document and data collection and is impacted by the parallel LEI issuance process, as client\nverification procedures performed by the LEI Issuer are also completed onboarding cannot be completed until an LEI has been\nby the entity’s FI, as part of its processes when validating a client’s issued. And, despite the range of future benefits enabled\nidentity during initial onboarding or subsequent refresh. by the LE| across several use cases, from digital onboarding\nFor both entity and LEI Issuer, these processes require time and effort to to digital signatures, S',”C? the factors'dnvmg LEl issuance are )\ncomplete. The LEI Issuer must receive these documents, review and verify currer?tly >0 narroyv - limited prgdommantly to regulato'ry compllan.ce )\nthem, and deliver the relevant data into the Global LEI Index before it may the're '? currently little oppgrtumty for the Fi to offset client frustration by\nissue the LEI. Depending on the nature of the legal entity, the completion delivering value elsewhere in the process.\nof these procedures may require several exchanges and incur an inevitable Together these issues can negatively impact the FI's customer experience\nperiod for processing between each round of communication. delivery at what is perhaps the most fragile time in the client lifecycle:\nConsidering that legal entities engaged in capital markets are legally right a't the beginning. A significant op.po'rtunit.y.thgrefore exists to address\nrequired to obtain an LEI, this ‘process duplication’ between Fl and these issues by de-duplicating the entity identification procedures that are\nLEI Issuer, together with the additional processing time it creates, currently shared between the Fl and the LEl Issuer.\ncan cause frustration among an FI’s clients resulting in an\ninconvenient customer experience.\n\nD,\n","contentLength":2372,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:29:16.146Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/validation-agents/gleif-ebook-introducing-the-lei-validation-agent/2020-09-29_gleif-ebook-lei-validation-agent-framework_v1.1-final.pdf","content":"L L L\nIntroducing the Validation Agent Framework\nValidation Agent:\nA definition and purpose\nThe creation of the Validation By shar'ir?g with the LEI Issuer By simplifying and accelerating\nAgent Framgwork empowers Fls to the vgrlfi?d data ne'ede.d by the LEI issuance process, the\n.o leverage t.helr know your c.ustomer the <':I|ent s LE'I appllca‘uon, new Framework also paves the\n. (KYC), anti-money laundering aFlin the Valuflatlon Agent way for Fls to expand their\nThe Valndah?n Agent (AM L) and other regulateq role can benefit from: usage of the LEI beyond capital\nFrame\\./vork isa nevy business as usual gnboardlng . « A greatly streamlined LE] markets to encompass all\noperational model in the : processes, to obtain an LEI for their . . : p .\nSl L1 i : A by ent’ issuance process for clients, banking business lines, an\noRat ™ ystter.n, WAL : .custo.mers when venilying a c |.ent s resulting in an enhanced client ~ opportunity anticipated to\nallows financial institutions : identity during initial onboarding . . . .\n. . : ) ) experience in onboarding and save the industry\nto obtain and maintain : or during a standard client refresh . i .\n. s : ) o lifecycle management. U.S.52-4 billion annually in\nLegal Entity If:len.tlfiers update. Fls alicftlng as Validation O ' ' client onboarding costs alone. ~\n(LEls) for their clients in : Agents can liaise with the LEl Issuer © Digitization of its onboarding\ncooperation with accredited © onits client’s behalf to ‘validate’ processes based on Widespread usage of the\nLEI Issuer Organizations by : that these key data checks and standardized legal entity data, ~ LEl also t?e'tt.er prepares the Fl\nleveraging their business as © processes have been undertaken. instead of siloed information for the digitization of customer\nusual client identification : and legacy systems. onboarding, payments,\ni : transactions, and contract\n2ro:edures|(|$cKnov: Ylt?ur e Additional opportunities to signing\nustomer (KYC) and client : add client value and achieve ’\nonboarding processes. : market differentiation.\n29 e Enhanced internal data\nmanagement processes, @\nreduced costs. —\n* A uniquely powerful foundation\nupon which to innovate and\ndevelop new digital services\nand revenue opportunities.\n\\4)\n","contentLength":2243,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:29:16.146Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/validation-agents/gleif-ebook-introducing-the-lei-validation-agent/2020-09-29_gleif-ebook-lei-validation-agent-framework_v1.1-final.pdf","content":"L\nWhat benefits does the\nL L L\nValidation Agent role deliver?\nBenefits to FIs becoming Validation Agents . Benefits for clients\n. (legal entities) of a FI\nPrimary / Immediate: Secondary / Future opportunities: in the Validation Agent role\n Faster and more efficient customer ¢ A uniquely powerful foundation upon\nexperience offering when onboarding which to innovate and develop new L. Reduced duplicative processes across\nclients and performing refresh updates. digital efficiencies, services and revenue Fl onboarding and LEI issuance.\nAn end to client frustration due to opportunities: :\nprocess duplication. ) ) o : e Less time and resource investment\n- Pioneer new, revenue-generating digital : needed; FI deals directly with the\n* Additional opportunities to add client services in areas enabled by the LEI: : LEI Issuer on key data checks during\nvalue and achieve market differentiation. corporate identity management, digitized : LE| issuance.\n. cross border supply chain relationships,\n* Enhanced internal data management legal assurance level e-signing with digital : * Faster and more efficient service.\nprocesses, greater consistency, . ;\nreduced costs. certificates. © « Reduced time to trading revenue.\no Accelerated digital transformation. i 'Create readmessfgr significant f’p”fl i ¢ Collaboration with a Fl to evolve\nin demand from clients for LEls in the : their LEI usage.\nnear future as use-cases evolve beyond )\ncompliance in capital markets. : - Evaluate trading partners, execute\n: e-documents in trade finance, legal\n¢ Autonomous control over your digitization : assurance level e-signing with\nof business processes. The LEl is a non- § digital certificates, explore new\nproprietary global standard that enables § use-cases for client’s unique\n— commercial and operational independence § identifier (e.g. in payments,\n— from vendors. compliance, or due diligence).\n\\9\n","contentLength":1891,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:29:16.146Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/validation-agents/gleif-ebook-introducing-the-lei-validation-agent/2020-09-29_gleif-ebook-lei-validation-agent-framework_v1.1-final.pdf","content":"Validation Agent role deliver? (cont) ,\n\\ /\nS 7\nBenefits to LEI Issuers engaging . Benefits to all LEI _ _|—\nwith Validation Agents . ecosystem participants -\n: 7 S\n* Streamlined and accelerated * The faster, more efficient LEl issuance / | \\\noperations: Validation Agents now : processes enabled by the Validation Agent\ntake over key elements of identity : role creates readiness in the Global LEI\nverification of legal entities applying : System to support significantly increased\nfor LEls. : demand for LEls. As LEIl usage evolves\n- Validation Agents provide access beyond regulatory compliance |n. capital\n: markets and voluntary LEI adoption\nto new markets beyond regulatory : . .\n. . : gains traction around the world, the LEI\ncompliance. Promotion of broader : . . . .\n- : ecosystem will benefit from the agility gains\nLEI usage by Validation Agents, : . P N\n: made possible by the ‘third party’ entity\nsupported by a faster, more : . . e . .\n. . . : identity verification services provided by\nconvenient LEIl issuance process, will : Validation Agents\npotentially deliver a higher number : gents. —\nof LEI applications. : e This readiness will also allow innovation ——\nin LEl use-case development to continue\nuninhibited by constraints in process,\nand will ensure the financial ecosystem\ncan adapt quickly and smoothly to\nchanges in regulation.\n\\9\n","contentLength":1356,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:29:16.146Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/validation-agents/gleif-ebook-introducing-the-lei-validation-agent/2020-09-29_gleif-ebook-lei-validation-agent-framework_v1.1-final.pdf","content":"How it works:\n[ ]\nWhat will Validation Agents do?\nThe responsibilities of FIs that become Validation Agents begin with a check to establish whether\ntheir client has an LEI. If the client does not, the agent will validate the following during the LEI\nIssuer’s entity verification process, in accordance with the LEI ISO 17442 standard:\nLegal name Authorized Business registry Headquarters Legal Branch Direct and\nsignatory information address address address ultimate parents\nN\\ ooo N\nM = e /A ki Q0\n[170) 1O N\nValidation Agents\nwill partner and Aside from accepting data\ninterface with one or records from Validation\nmore LEl Issuers to Agents, LEI Issuers\nobtain LEls for their will continue in their\nlegal entity clients. conventional roles:\n\\D\n","contentLength":747,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:29:16.146Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/validation-agents/gleif-ebook-introducing-the-lei-validation-agent/2020-09-29_gleif-ebook-lei-validation-agent-framework_v1.1-final.pdf","content":"L L L L L\nWho is eligible to become a Validation Agent?\nThat said, the Validation Agent Framework has been designed to foster\nbroader appeal among Fls, in line with GLEIF’s objective to encourage\nvoluntary LEI adoption outside of capital markets. By expanding LEI\nAny Fl that serves issuance beyond legal entity clients that require an LEI for financial\nlegal entity clients compliance, a Validation Agent can equip its whole business client base\nmay apply to become N with globally recognized identities, which can be used across borders with\na Validation Agent. any legally registered counterparty or supplier around the world. In this\n== way, the LEI can solve the problem of trust for legal entities worldwide.\nIt is the only open, commercially neutral, standardized and regulatory\nendorsed system capable of establishing digitized trust between all legal\nentitles, everywhere. As awareness of these enabling attributes increases\namong Fls, GLEIF expects the Validation Agent role also to be assumed\nToday, legal entities operating in derivatives by Fls seeking to become recognized leaders in identity management and\nand many capital markets are required by law position themselves as facilitators of global trade.\n:zac:o::l: ;;tfl;fi:fl;::::;tt ::;hs(:z:it:; Looking ahead, any related organization that performs relevant validation\nto streamline regulatory compliance and verification practices which are overseen by an independent\nprocesses for their clients will be among the legal authority, may also apply for Validation Agent status. Certificate\nfirst to apply for Validation Agent status. Authorities, for example, which undergo annual audit procedures to\nmaintain their legal capacity to issue, say, extended validation certificates\nor eIDAS products, may also be eligible.\nN\nel\nL _) GLEIF welcomes exploratory dialogue from any\nstakeholder group that conforms to one or more\nof these descriptions. Initial enquiries should be\nmade to 0O O O\n\"‘\nD,\n","contentLength":1959,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:29:16.146Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/validation-agents/gleif-ebook-introducing-the-lei-validation-agent/2020-09-29_gleif-ebook-lei-validation-agent-framework_v1.1-final.pdf","content":"How does a Validation Agent interact with o+ S\nother roles within the Global LEI System? &\nO\n\nThe Validation Agent is an entirely new role in the Mutually supportive:\nGlobal LEI System. It complements and interoperates : . . i\nwith the other related roles listed below: Validation Agents and LEl Issuers LEl Issuers bring local\n\n: knowledge to the Global LEI\nRegistration Agent - an organization that helps : The Validation Agent role integrates System and understand the\nlegal entities access the network of LEI Issuers. The : seamlessly into the operations of LE| Issuers ..\nRegistration Agent may choose to partner with one : and has the potential to expand their needs of small and mid-sized\nor more LEl Issuers to ensure its clients’ needs for : business opportunities by creating access Fls in the jurisdictions in\nLEl services are met. © tonew markets, as LE| usage grows beyond which they operate.\n\n: regulatory use cases. Validation Agents can . .\nLEl Issuers (also known as Local Operating Units) © also accelerate and streamline operations for Their efforts, combined\n- an organization accredited by GLEIF to issue LEls to LEI Issuers, since they allow the responsibility with Validation Agents and\nlegal entities. L.EI Issuers supply regls.trat'lor?, renewal . for entity identity verification processes, GLEIF, will help to establish\nand other services, and act as the primary interface : which are needed ahead of LEI issuance, to ’ ] .\nwith legal entities for LEls. © be performed and validated by a Fl, as part of the pilot projects that will be\nValidation Agent - an organization that obtains their ‘business-as-usual’ onboarding process. critical to the advancement\nand maintains Legal Entity Identifiers (LEls) for its _ _ of voluntary LEl adoption\nclients in cooperation with accredited LEI Issuers GLE_IF also mteno!s that the.more streamlined, across broader banking\nby leveraging their business as usual client rapid and user—fnepdly LEl issuance prqcess tfoli\nidentification procedures in Know Your Customer enabled by the Validation Agent role will he.Ip portiofios.\n(KYC) and client onboarding processes. to power the growth of voluntary LEI adophon.\n\n: A greater overall demand for LEIs should, in\n\n© turn, result in greater demand for the services\n\n: of LEl Issuers in the future. @\n\n2\n","contentLength":2317,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:29:16.146Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/validation-agents/gleif-ebook-introducing-the-lei-validation-agent/2020-09-29_gleif-ebook-lei-validation-agent-framework_v1.1-final.pdf","content":"Supporting a growing LEl ecosystem\nThe Validation Agent Framework, .\nintroduced by GLEIF in September .The Validation Agent Framgwork has be.en\n2020, is designed to remove the introduced following extensive consultation\nduplication of processes across Fl wi.th §LEIF’s Globally !mportant Financiafl\nclient onboarding and LEI issuance, Ins‘utu‘ugns (GIFI) Relan(?nshlp Group, which\nresulting in a simpler, faster and comprises representatives f)f Iarge banks,\nmore convenient experience for global asset management firms, insurance\nFi i) s, crE s el companies, and other Fls. The group facilitates\nby a more efficient LEI communication between GLEIF, banks, FIs and\nissuance process. other key LEI stakeholders and has given its full\nsupport to the Framework.\nIn addition to delivering\nprocess and experiential\nbenefits to Fls and their clients,\na more streamlined Global\nLEI System also supports\nGLEIF’s vision for increased\nvoluntary adoption of LEIs by\nthe banking sector across non-\nregulatory use cases.\n10 >\n","contentLength":1013,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:29:16.146Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/validation-agents/gleif-ebook-introducing-the-lei-validation-agent/2020-09-29_gleif-announces-new-va-role-for-fis_v1.0-final-clean.pdf","content":"\\ @’ |_E | RN ER\nPress Release\nGLEIF Defines new Validation Agent Role for Banks & Financial Institutions to Simplify and Accelerate\nClient Lifecycle Management\nNew operating model enables financial institutions to improve customer experience, facilitate digital\ntransformation and reduce client lifecycle management costs by utilizing their ‘business-as-usual’\nonboarding processes to obtain LEIs for their clients\n29 September 2020 - The Global Legal Entity Identifier Foundation (GLEIF) has today announced that\nfinancial institutions (FIs) worldwide can realize a variety of cost, efficiency and customer experience\nbenefits by assuming a new ‘Validation Agent’ role within the Global LEI System. FIs acting as Validation\nAgents simplify LEIl issuance for their clients, reduce time-to-revenue, and future proof their institutions\nfor digital innovation. The Validation Agent Framework is a new operational model in the Global LEI\nSystem.\nBy leveraging their know-your-customer (KYC), anti-money laundering (AML) and other regulated\n‘business-as-usual’ onboarding processes, Validation Agents can now obtain an LEI for their customers\nwhen verifying a client’s identity during initial onboarding or during a standard client refresh update.\nUntil now, labor intensive and time consuming legal document and data collection procedures, which\nare conducted as standard to verify the identity of a client entity within a bank’s onboarding process,\nhave been replicated within the Global LEI System by a Local Operating Unit (LOU), as part of the LEI\nissuance process.\nBy becoming Validation Agents, Fls can spare their clients from these duplicative processes and deliver\na faster and more convenient customer experience. Validation Agents can also capitalize on additional\nopportunities to add client value and achieve market differentiation. By expanding their LEl issuance\nbeyond those that require an LEI for financial compliance, a Validation Agent can equip its whole\nbusiness client base with globally recognized identities, which can be used across borders with any\ncounterparty or supplier around the world.\nIn addition to these client benefits, the new operating model will allow FIs to enhance their internal\ndata management capabilities and reduce costs. It also paves the way for Fls to expand their usage of\nthe LEI beyond capital markets to encompass all banking business lines, an opportunity anticipated to\nsave the industry U.S.$2-4 billion annually in client onboarding costs alone. Furthermore, widespread\nusage of the LEI better prepares the Fl for the digitization of customer onboarding, payments,\ntransactions, and contract signing. This new level of efficiency created by the Validation Agent role will\nremove numerous points of redundancy from the LEl issuance process, resulting in a more streamlined\nGlobal LEI System which supports GLEIF’s vision for increased voluntary adoption of LEIs by the banking\nsector across non-regulatory use cases.\nThe Validation Agent Framework has been introduced following extensive consultation with GLEIF’s\nGlobally Important Financial Institutions (GIFI) Relationship Group, which comprises representatives of\nlarge banks, global asset management firms, insurance companies, and other Fls. The group facilitates\ncommunication between GLEIF, banks, Fls and other key LEI stakeholders and has given its full support\nto the Framework.\n1\n","contentLength":3396,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:29:28.648Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/validation-agents/gleif-ebook-introducing-the-lei-validation-agent/2020-09-29_gleif-announces-new-va-role-for-fis_v1.0-final-clean.pdf","content":"\": LEGAL\n\n\\ @’ |_E |\n“GLEIF is committed to supporting the banking industry’s widespread implementation of the LEI beyond\nmandated requirements,” comments Stephan Wolf, GLEIF CEO. “The Validation Agent role helps\nfinancial institutions to improve their operations and enable their customers to more quickly achieve\ntheir desired financial transactions. By becoming Validation Agents financial institutions can streamline,\naccelerate and diversify their use of the LEI, and ensure their autonomy as they look to digitize their\nbusiness processes. Considering that from a macro level, broader LEI usage and increasing volumes\ntranslate into more efficient financial transactions — from digitally signing contracts to financial markets\nparticipation — Validation Agents contribute to growth across the entire ecosystem, which will benefit\nall financial ecosystem stakeholders, as well as the global economy.\n“As a next step, GLEIF is actively engaging with the global banking community to support trials of the\nValidation Agent Framework and to ensure that the Global LEI System continues to meet the sector’s\nneeds. Our LEI issuer network plays an important role in supporting financial institutions to easily\nconnect to the global financial ecosystem. LEl issuers, also known as Local Operating Units (LOUs) bring\nlocal knowledge to the Global LEI System and understand the needs of small and mid-sized financial\ninstitutions in the jurisdictions in which they operate. Their efforts, combined with GLEIF’s, will\nundoubtedly generate some interesting pilot projects over the next twelve months, and these will be\ncritical to the advancement of LEI adoption across banking portfolios.”\nFor more information on the Validation Agent role, please visit the GLEIF website.\n\n-ENDS -\nFull resolution images and logos can be downloaded via this link\nhttps://www.gleif.org/en/newsroom/gleif-graphics-images\nContact\nElisabeth Dean / Ellie Bokros, iseepr\nelisabeth@iseepr.co.uk / ellie@iseepr.co.uk\n+44 (0) 113 350 1922\nRelevant link\nhttps://www.gleif.org/en\nGlossary of terms\nLegal Entity Identifier (LEI)\nThe Legal Entity Identifier (LEI) is a 20-character, alpha-numeric code based on the I1SO 17442 standard\ndeveloped by the International Organization for Standardization (ISO). The LEIl connects to key reference\ninformation that enables clear and unique identification of legal entities participating in financial\ntransactions. Each LEl contains information about an entity’s ownership structure, answering the\nquestions of 'who is who’ and ‘who owns whom'. It provides a universally recognized identifier paired\nwith essential entity data, rigorous verification processes and high data quality.\n2\n","contentLength":2692,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:29:28.648Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/validation-agents/gleif-ebook-introducing-the-lei-validation-agent/2020-09-29_gleif-announces-new-va-role-for-fis_v1.0-final-clean.pdf","content":"\": LEGAL\n\n\\ @’ |_E |\nAbout the Global Legal Entity Identifier Foundation (GLEIF)\nEstablished by the Financial Stability Board in June 2014, the Global Legal Entity Identifier Foundation\n(GLEIF) is a not-for-profit organization created to support the implementation and use of the Legal Entity\nIdentifier (LEI). GLEIF is headquartered in Basel, Switzerland.\nGLEIF services ensure the operational integrity of the Global LEI System. GLEIF also makes available the\ntechnical infrastructure to provide, via an open data license, access to the full global LEI repository free\nof charge to users. GLEIF is overseen by the LElI Regulatory Oversight Committee, which is made up of\nrepresentatives of public authorities from across the globe. For more information, visit the GLEIF website\nat https://www.gleif.org/en.\nHistory of the Global LEI System\nIn 2011, the Group of Twenty (G20) called on the Financial Stability Board (FSB) to provide\nrecommendations for a global Legal Entity Identifier (LEl) and a supporting governance structure. This led\nto the development of the Global LEI System which, through the issuance of LEls, now provides unique\nidentification of legal entities participating in financial transactions across the globe. The FSB emphasized\nthat global adoption of the LEI underpins multiple “financial stability objectives” and also offers “many\nbenefits to the private sector”.\nSource:\nGlobal Legal Entity Identifier Foundation, St. Alban-Vorstadt 5, 4052 Basel, Switzerland\nChairman of the Board: Steven Joachim, CEO: Stephan Wolf\nCommercial-Register-No.: CHE-200.595.965, VAT-No.: CHE-200.595.965MWST\nLEl: 506700GE1G29325QX363\nm . (] . 3 .\n\n+ http://bit.ly/10XTYLo | : http://bit.ly/1Me7uZx | = GLEIF Blog: http://bit.ly/1LyIXkn\nTo unsubscribe from future GLEIF news, reply ‘unsubscribe’ to this email.\nClick here to read our privacy policy.\n3\n","contentLength":1859,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:29:28.648Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/validation-agents/gleif-ebook-a-closer-look-at-the-validation-agent-trial-process/2021-03-03_gleif-validation-agent-trial-ebook_v1.0-approved-public.pdf","content":"Become a Validation Agent:\nA Closer Look at The Trial Process\n9, El i\n","contentLength":70,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:29:51.561Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/validation-agents/gleif-ebook-a-closer-look-at-the-validation-agent-trial-process/2021-03-03_gleif-validation-agent-trial-ebook_v1.0-approved-public.pdf","content":"Introduction\nIn its drive to encourage voluntary adoption and use of LEls across a broader\nportfolio of non-regulatory use-cases, the Global LEI Foundation (GLEIF)\nintroduced in 2020 a new role in the Global LEI System. It is called the\nValidation Agent. @\nThe goal of the Validation Agent role is to streamline the LEI issuance process I — °\nand deliver a multitude of benefits for legal entities, LEI issuers and the financial -\ninstitutions (Fls) that serve legal entities as clients.\nAny Fl or other organization that performs relevant validation and verification\npractices that are overseen or audited by an independent authority may apply\nfor Validation Agent status.\nGLEIF is inviting FIs to participate in the Validation Agent trial phase and establish\nfirst-mover status in the market. This eBook shines a light on the seven-step\ntrial process for Fls seeking to develop a clearer picture of the operational\nrequirements and the support available from GLEIF.\nClick here to learn more. z ( - a : w'\n\\9\n","contentLength":1010,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:29:51.561Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/validation-agents/gleif-ebook-a-closer-look-at-the-validation-agent-trial-process/2021-03-03_gleif-validation-agent-trial-ebook_v1.0-approved-public.pdf","content":"About the Legal Entity . About the Global Legal Entity . History of the Global\nIdentifier (LEI) . Identifier Foundation (GLEIF) : LEI System\nThe Legal Entity Identifier (LEl) is a Established by the Financial Stability Board In 2011, the Group of Twenty (G20)\n20-character, alpha-numeric code based : in June 2014, the Global Legal Entity called on the Financial Stability Board\non the ISO 17442 standard developed : Identifier Foundation (GLEIF) is a not-for- (FSB) to provide recommendations for\nby the International Organization for : profit organization created to support the a global Legal Entity Identifier (LEI) and\nStandardization (ISO). The LEI connects © implementation and use of the Legal Entity asupporting governance structure. This\nto key reference information that : Identifier (LEl). GLEIF is headquartered in led to the development of the Global LEI\nenables clear and unique identification : Basel, Switzerland. © System which, through the issuance of\nof legal gn‘u‘ues parhupahng in .finanuall GLEIF services ensure the operational LEls, now p.r(.)wdes u.nllque. |d§nhf|cah9n\ntransactions. Each LEI contains information . . : of legal entities participating in financial\no ) : integrity of the Global LEI System. GLEIF also : ;\nabout an entity’s ownership structure, : . o © transactions across the globe. The FSB\n) . , ) , : makes available the technical infrastructure : ) .\nanswering the questions of ‘who is who : ) . . : emphasized that global adoption of the\n) , ) : toprovide, via an open data license, access : ) e . o\nand ‘who owns whom'. It provides a : . : LEl underpins multiple “financial stability\n) ) i o ) ) : to the full global LEI repository free of : B P ;\nuniversally recognized identifier paired with : : © objectives” and also offers “many benefits\n; - ) o : charge to users. GLEIF is overseen by the : i .\nessential entity data, rigorous verification : ) ) . © tothe private sector”.\nrocesses and high dat lit : LEI Regulatory Oversight Committee, which :\nP 8 a quality. : is made up of representatives of public\n: authorities from across the globe.\n‘@ \\ For more information, visit the GLEIF\nN : website at https://www.gleif.org/en. ~\nv | |\nGLEIF Blog : :\nSource:\nGlobal Legal Entity Identifier Foundation, St. Alban-Vorstadt 5, 4052 Basel, Switzerland \"’ GLOBAL\nChairman of the Board: Steven Joachim, CEO: Stephan Wolf :‘ ‘ IEEIGI'{-'\\I'LY\nCommercial-Register-No.: CHE-200.595.965, VAT-No.: CHE-200.595.965MWST g O IDENTIFIER\nLEI: 506700GE1G29325QX363 FOUNDATION\nThe content of this eBook is the property of GLEIF. Reproduction and/or sharing of this content is encouraged and\nmust be accompanied by a clear attribution to GLEIF.\n11 >\n","contentLength":2685,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:29:51.561Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/validation-agents/gleif-ebook-a-closer-look-at-the-validation-agent-trial-process/2021-03-03_gleif-validation-agent-trial-ebook_v1.0-approved-public.pdf","content":"Validation Agent:\no0\nBenefits for Financial Institutions 40% of existing costs that our\ncustomers experience in their KYC\nprocesses is around public data\ncollection. The ability to standardize\nToday v this via the LEI is significant.\nThe second wave of savings is in\n0 Faster, more efficient client onboarding experience the technology costs reduction\nand subsequent client refresh cycles given the use of a standardized\nidentifier for corporates.\n0 Increase opportunities to add value and create %9\ndifferentiation\nPreeti Malk,\n° Enhance internal data management processes, Head of Global -\nincrease consistency, reduce cost Risk and Financial Crime\nCompliance, Capgemini.\nAccelerate digital transf t o\nQ@ Aoceeste il enfomation Capgomini@d The adoptin of L\nallows us to associate an\n- alphanumeric identifier\nto a client so we know precisely\nwho we are dealing with.\n/\\ It sounds basic but it enables all\nthese other benefits around new\ndigital services and improved\nPaul Maley, data management.\nManaging Director 0\nI | | | Deutsche Bank.\nDeutsche Bank\n\\9\n","contentLength":1058,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:29:51.561Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/validation-agents/gleif-ebook-a-closer-look-at-the-validation-agent-trial-process/2021-03-03_gleif-validation-agent-trial-ebook_v1.0-approved-public.pdf","content":"L L\n[ ]\nValidation Agent:\nL L L L L\nBenefits for Financial Institutions\n0 Platform for innovation and new service development, (14 (14\nincluding: Although the Validation The Validation Agent role is also\ne Corporate Identity Agent Framework will initially likely to be assumed by banks\n« Digital x-border supply chain relationships appeal to Fls seeking to seeking to become recognized\n« Legal assurance level e-signature services via streamline regulatory compliance leaders in identity management,\ndigital certificates processes for their clients, the positioning themselves as\nrole is designed to foster broader facilitators of global trade. By\ne appeal among banks and to expanding LEl issuance beyond\nReadiness for uplift in LEls as use-cases encourage voluntary LEI adoption legal entity clients that require\n0 evolve beyond capital markets outside of capital markets. an LEI for financial compliance,\nValidation Agents can leverage a Validation Agent can equip its\ne the LEI and eliminate manual whole business client base with\nAutonomous control over digitization of business linking of entity data from globally recognized identities,\n0 processes. The LEI is a non-proprietary global standard disparate internal and external which can be used across borders\nthat enables commercial and operational independence sources. McKinsey estimates that with any legally registered\nfrom vendors. this alone would save the global counterparty or supplier around\nbanking industry $2-4 billion per the world. In this way, FIs can use\ne annum by improving full time the LEI to solve the problem of\nFuture proof your organization for upcoming regulations employee productivity in client cross border trust for their\nQ and policy implementations requiring the LEI* onboarding. clients worldwide.\ne ===~ = %) %9 Y S\nIn 2021 the Financial Stability Board is exploring scope to include the LEI in forthcoming 4 »\npayments regulations, in accordance with the roadmap presented in its Stage 3 Report Stephan WOIf;\ninto Enhancing Cross-Border Payments (p29). CEO, Global LEI Foundation .\nD,\n","contentLength":2082,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:29:51.561Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/validation-agents/gleif-ebook-a-closer-look-at-the-validation-agent-trial-process/2021-03-03_gleif-validation-agent-trial-ebook_v1.0-approved-public.pdf","content":"Assessing Participation: ?\n[ ]\nCommon Questions Answered ’\nWhat are the goals What value does GLEIF What does it cost and how\nof the trial? bring to the trial? long will it take?\nTriallists will benefit from deep engagement There is no monetary cost required.\nwith GLEIF’s experts, who will help to Only the time of the Fl’s personnel is\nBy working with Validation Agent define hqw the VaIu?atl.or} Agent .prm':ess nrj:etljed to understand gnq engage in the\n. - . can be tailored to triallist’s organization. trial’s processes. The trial is expected to\ntriallists, GLEIF aims to: . . .\nGLEIF assigns an account manager to each successfully complete in four to six months.\nEnable smooth and efficient participating organization to support them No technology investment is anticipated\nearly adoption of the Validation throughout the whole trial. This includes for the trial. If the Fl chooses to establish\nAgent role among first mover Fls. support with performing a gap analysis and permanent Validation Agent status after the\n. engagement with the LEI Issuer network. trial, some technical investment is likely to\nSupport the creation of a ) . . .\n. . e Here, several key points of negotiation exist be required.\nbusiness case by identifying, A\nipe , i regarding, for example, who manages LEI\nspecific to each FI's organization, , -\n. . . challenges and renewals. GLEIF’s experience\nthe efficiency gains that can be . [ .\n. s in facilitating this dialogue has proven\nrealised through the Validation . -\ninvaluable to Fls whose trials are already\nAgent role.\nunderway. l l\nExplore and provide support\nfor the technical, legal and\noperational adjustments within GLEIF provides templates, training and\nthe triallist’s organization education on the LEI System and its\nrequired by the role. processes. GLEIF also acts as a channel\nthrough which to outreach to LEl issuers\nfor bids.\n\\9\n","contentLength":1879,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:29:51.561Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/validation-agents/gleif-ebook-a-closer-look-at-the-validation-agent-trial-process/2021-03-03_gleif-validation-agent-trial-ebook_v1.0-approved-public.pdf","content":"About the Trial:\nA Seven Step Process\nA customized, \\\npartnership approach\n\n. Sign Commitment Introduction Gap\nWhile every effort has been made NDA Statement of GLEIF analysis\nto standardize the trial engagement standards\nprocess, GLEIF acknowledges that the\neach Fl employs unique processes and\norganizes its departmental functions\ndifferently. GLEIF is committed to\nworking closely with each triallist to /\nexplore and define the procedural\nadjustments needed to enable the\nValidation Agent role and to help Il:filla}nac?gl Walk\nidentify the opportunities to drive Institution a\nprocess efficiencies in client onboarding reement through\nand lifecycle management. G LS\n\n@\n","contentLength":672,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:29:51.561Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/validation-agents/gleif-ebook-a-closer-look-at-the-validation-agent-trial-process/2021-03-03_gleif-validation-agent-trial-ebook_v1.0-approved-public.pdf","content":"touns : tous :\nSign NDA Commitment statement\nTo enable preparatory discussions between GLEIF and This non-binding document To assist interested parties in\nthe triallist to evolve beyond a theoretical framework, confirms that both GLEIF and the securing internal approvals to\nboth parties sign NDAs. This action permits open FI will commit their personnel time participate in the trial, GLEIF has\ncollaboration while protecting each party’s intellectual to the trial. Both parties cover their published Introducing the LEI\nproperty and commercially sensitive data. costs of participation. It does not, Validation Agent Framework\nhowever, require the Fl to complete which provides an executive\nthe trial should its priorities or level overview of the new role\ncircumstances change. In respect of together with its benefits\nthe time and efforts of all parties, to FIs and the broader\nGLEIF requests that participating LEl ecosystem.\nFls needing to withdraw from the\n@ trial do so prior to concluding\n| = ° agreements with\nLEI Issuers.\n\\D\n","contentLength":1035,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:29:51.561Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/validation-agents/gleif-ebook-a-closer-look-at-the-validation-agent-trial-process/2021-03-03_gleif-validation-agent-trial-ebook_v1.0-approved-public.pdf","content":"v : v\n1 2 : 4 : 1 2 3\nIntroduction : Gap\ns\n6 : 6\nIntroduction of GLEIF standards . Perform gap analysis\nThrough a series of regular calls, It also offers a chance to explore GLEIF assists the Fl in performing identified, the Fl and GLEIF then\nGLEIF and the FI review the LEI whether GLEIF’s Validation : a gap analysis based on its create a change management\nIssuer services in the Global LEI Agent to LEI Issuer protocol : understanding of the Fls plan to adjust processes or\nSystem and explore the processes can be leveraged to facilitate : procedures and processes in documentation to achieve parity.\nthat the Fl can assume from the interoperability during the : identity verification. This step . .\n. . . . . . e : . . At this point, the Fl assumes\nissuer during client onboarding shared identity data verification : involves comparing the reference :\n: control of the trial and proceeds\nand standard refresh updates. processes. : data sources that are used o\no : . . to engage with its LEI Issuer(s) to\nThis includes how the Fl can : in the Global LEI System with . ) .\n), . : . agree and design the interaction\nleverage GLEIF’s public API to : those the Fl uses in its standard and negotiate pricing\ndiscover whether their legal entity : client onboarding and refresh ’\ncustomer already has an LEI. q § updates. Once commonalities\n: and differences have been\n\\9\n","contentLength":1368,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:29:51.561Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/validation-agents/gleif-ebook-a-closer-look-at-the-validation-agent-trial-process/2021-03-03_gleif-validation-agent-trial-ebook_v1.0-approved-public.pdf","content":"LOU and : LOU and : LOUand\nE S\n\nagreements . agreements E agreements\n\n- a -\nLEI Issuer & Fl agreements . Walk through . Issuing LEls\nWith the processes explored and designed, Once legal agreements have been Once final approval has been granted by\nthe FI now moves to establish agreements. established, the FI demonstrates to GLEIF GLEIF, the FI holds official Validation Agent\nThe FI can engage with the LEI Issuer(s) that : the process of issuing an LEI. Here, the Fl status and may begin obtaining LEls on\nit would like to work with by leveraging the : and the LEl Issuer demonstrate that the behalf of its corporate clients.\nGLEIF’s Request for Proposal template. : cooperative information flows and processes\nThe key areas that require negotiation are : established adhere to the framework of\ncommonly identified in the gap analysis, . the Global LEI System. This step allows for\nso the development of the agreement : refinement of the established system,\nbetween the Fl and its LEl Issuer(s) - : ahead of GLEIF’s final\nwhich forms the blueprint : approval of Fl as a\nfor their data exchange © Validation Agent. !\nprocesses, services —\nand pricing - occurs — (_O R Q\nprivately, without T\nGLEIF’s involvement. N C J\n\n\\9)\n","contentLength":1227,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:29:51.561Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/validation-agents/gleif-ebook-a-closer-look-at-the-validation-agent-trial-process/2021-03-03_gleif-validation-agent-trial-ebook_v1.0-approved-public.pdf","content":"During the Trial:\n[ ]\nOperational Questions Answered\nIf an Fl becomes a : Does a Validation Agent : How many entities i Should an Fl target\nValidation Agent, will . have to work with the . should an Fl target . entities that will\nGLEIF or the public be : same LEl issuer for all . inthe trial? . need an LElin the\nable to discover who i jurisdictions that it has § i trial phase?\nits clients are? . KYC procedures in? : :\nNo, neither GLEIF nor the public © No, Validation Agents do not have ' This depends on the : Again, this depends on the FI.\ncan know who the FI’s clients © to work with a single LEI Issuer. : organization’s client base © By issuing the LEI to regulated\nare. All LEI records contain a © They can choose to cooperate © and preference. However, : entities (who are mandated to\n“Managing LOU” field, which © with various issuers operating © for testing the usefulness of © obtain one) the FI will create more\nwill be populated with the LEI ©in different jurisdictions. For the : the LEI, GLEIF recommends © satisfied clients, as they will benefit\nIssuer(s) that the FI chooses to :© purposes of the trial, FIs may Fls target at least 50 clients © from the newly streamlined process.\nwork with. Participation by the © choose to engage with a single © during the trial phase. © By issuing the LEI to the non-\nFl in a Validation Agent trial is issuer. financial corporations, however, the\nanonymous unless the Fl chooses © Flwill demonstrate excellence in its\nto disclose its participation. The : : client servicing, as corporates will\nconfidentially of the client datais : © then be equipped with an LEI for\nensured in the legal agreement § : © use in future cross-border trade and\nwith the LEl Issuer. : digital transactions use cases.\nGLEIF is actively engaging with the global banking community and is inviting Fls to @\ne participate in the trial phase. Interested to learn more? Contact us on\n10 >\n","contentLength":1921,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:29:51.561Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies_v1.2-final.pdf","content":"{m E i\n» E - :': i\nN . | :\nThe LEI: The Key to Unlocking Financial - '\n° ° ° ° *\"\" & % 7 » ¥ ; K\nInclusion in Developing Economies et G g\nPlus: A Spotlight on Africa ; | ; ‘\nHow LSEG (London Stock Exchange Group), T & . 4\nZimbabwe’s NMB Bank Limited, GLEIF, Cenfri and | o - :\nCornerstone Advisory Plus are unlocking access to s ., ,_ \" e\ntrade finance and boosting economic potential for . G E a8’\nAfrican businesses. 5 \"\n6\\3 e “\n‘ '& ‘ L E | ENTITY - \\’\n\\M pETEER\ny »\n- B |\n","contentLength":476,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:30:41.509Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies_v1.2-final.pdf","content":"Introduction\nA 2017 report from the International Finance Corporation (IFC) contends that million firms Ciie\n65 million firms around the world, including 45 per cent of small to medium sized globally RO\nenterprises (SMEs) in developing countries, have an unmet annual total financing need ssassiaiae | ) )\nof $5.2 trillion.* Today’s African economies, for example, suffer from a severe trade\nfinance gap currently estimated to be more than US$81bn.? BHHHE\nincluding R\nThe root of the problem, both for banks seeking to expanding trade finance portfolios o\nand international businesses looking for supply chain partnerships, lies in the need for (0]\ngreater transparency among SMEs. Too many do not possess the business credentials of SMEs in\nneeded to support counterparty due diligence processes and their associated risk developing\nassessments. countries\nThis is a major obstacle impeding global economic growth. It is felt most acutely in\ndeveloping economies where it prevents capital from flowing into SMEs, through both - :‘Qmet annual dof\ntrade finance and domestic and international partnerships. otal financing need o\nS5.2\n[ [\ntrillion\n\nThe Legal Entity Identifier (LEI) can solve this problem as it enhances transparency\n\nin the marketplace and builds greater trust between market participants.\n\nThis e-book explores how financial institutions and SMEs in developing economies across the world\n\ncan use the LEI, a globally recognized and standardized form of business ID, to address these problems ‘\n\nhead-on. By equipping SMEs with LEls, developing economies everywhere can dramatically increase Tr:d?nfizg?;e\n\nfinancial inclusion, enable broader participation in both domestic and international markets and, gsgmated at\n\nultimately, increase the flow of inbound capital needed to fuel their economic development. $ 8 1\n1The MSME Finance Gap, IFC 2017\n?Trade Finance in Africa: Trends Over the Past Decade and Opportunities Ahead - Policy Research Document 3, September 2020\n\n2 )\n","contentLength":1990,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:30:41.509Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies_v1.2-final.pdf","content":"L L L L\nThe LEI and financial inclusion:\nLooking to the future\nWhile the LEI cannot claim ‘silver\nbullet’ status, it remains a uniquely\npowerful proposition for enabling oo\nfinancial inclusion in developing\neconomies. The advent of the The LEI has the potential to create a more\nValidation Agent role for financial § transparent, efficient cross-border exchange of\ninstitutions is building significant § goods and data under the African Continental\nmomentum toward the realization § Free Trade Area. This is the first step toward\nof this goal and, at the same time, greater financial inclusion and overcoming the\ndelivering myriad benefits to both challenges associated with access to trade finance\nparticipating banks and their business : in Africa. Considering the high pace of digitization\nclients. and regulatory development across the African\ncontinent, the LEl is a great natural fit. It is a\nAs LEl issuance increases in developing : compelling, ready-to-go cross-border solution for\nregions, so does the world’s confidence : entity identification that is open, reliable and\nto trade with the businesses that : easily integrated into regulatory frameworks.\ncollectively drive their economies. 00\nSuccess here will, in turn, increase B\nthe flows of international, inbound Stephan Wolf, 57 ) m -\ncapital that enable faster economic CEO, GLEIF. ey ‘:9 ‘ E’E\\‘GT{*TLY\ndevelopment. i fi A~ | & ’ IDENTIFIER\nGLEIF continues to seek dialogue with governments, \\\nNGOs, banks, and other stakeholders interested o . . .\nin either expanding the LEI initiative in Africa or in % Please email info@gleif.org for more information.\nreplicating the model in other developing economies. /\n11 )\n","contentLength":1683,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:30:41.509Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies_v1.2-final.pdf","content":") El & fri W L Aragex,\nN 4 e centri ornerstone r /2\n\nEstablished by the Financial © Cenfriis an independent not for © Cornerstone Advisory Plus is © NMB Bank Limited is a registered\nStability Board in June 2014, © profit economic impact agency ©an advisory firm based in Cote © commercial bank in Zimbabwe\nthe Global Legal Entity Identifier © based in Cape Town, South Africa. © d’Ivoire- West Africa with an office © (formerly National Merchant Bank\nFoundation (GLEIF) is a not-for- © Cenfri works on financial integrity © In Dakar Senegal as well. The © of Zimbabwe Limited) which was\nprofit organization created to ©and has extensive experience in © firm is specialized in advisory and © established in October 1992. The\nsupport the implementation and © conducting research; training and © training services towards the private © Bank’s vision is to be the leading\nuse of the Legal Entity Identifier © capacity building; development of © institutions as well as the public © financial services group in its\n(LEIl) worldwide. : guidelines and modules, targeted © sector including regulators and © chosen market and its mission is to\nGLEIF enables smarter, less costly engagement and advice on financial sector supervisors. The provide financial services to high\nand more reliable decisions about i Corresponding banking relations, : areas of expertise of the : net worth individuals, businesses\nwho to do business with. It © AML-CFT implementation, Risk : firm are Compliance AML (Anti :and uniquely branded technology\nservices ensure the operational : Based Approach, Bisk Based : Money Laundering), terrorist : enabled products to SMEs and\nintegrity of the Global LEI Supervision and Flnar\\cial Inclusion, finahcing, enterprise'wide AMIT/TF the broa'der. market. The Bank’s\nSystem, providing free access : ampng others. Cenfri mgstly : (Ann mongy laundering/Terrorist : strategy is firmly focu;gd on thg\nto the full global LEI repository. : assists gove.rnme'nt mInI'StI’IES, : financing risk assessments, (Know : enhancement of its d|g|‘FaI offerings\nGLEIF is overseen by the LEI 5 regu!ators, finanu'al service 5 your'cus\"comer)', Corrgspondent ©oto gnsure seamless serV|'ce.\nRegulatory Oversight Committee, : providers (bgnks, msuran;e, among : banking issues m;ludmg the ' : delivery Fo the 'Ba'nk's e>'<|.st'|ng and\na group of public authorities : othgrs), designated noryfinanual § global problematjc of De-risking. § future ;Ilent's yla its excmng and\nand observers from more than ¢ businesses and professions . Cornerstone Advisory Plus was . refreshing digital touch points.\n50 countries around the world. . (DNFBPs) and other stakeholders . founded by a specialist in the : NMB Bank Limited also continues\nit is headquartered in Basel, : atnational and regional and global . financial sector with 20 years © with its financial inclusion drive\nSwitzerland. i levels (including ESAAMLG, GIABA, : experience in the financial sector :and has intensified the adoption of\n\n: Alliance for Financial Inclusion ©in West Africa and in the context of : different technologies to improve\nFor more information visit: countries). multinational institutions. © on-boarding experience to the\nwww.gleif.org : For more information visit: : For more information visit: Bank’s future customers.\n\n© www.cenfri.org © www.cornerstoneadvisoryplus.com © For more information visit:\n\n© www.nmbz.co.zw\n\n12 )\n","contentLength":3395,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:30:41.509Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies_v1.2-final.pdf","content":"@ e ’. ‘ O\nv\nGLEIF Blog\n\nSource:\n\nGlobal Legal Entity Identifier Foundation,\n\nSt. Alban-Vorstadt 5, 4052 Basel, Switzerland\n\nChairman of the Board: Steven Joachim, CEO: Stephan Wolf\n\nCommercial-Register-No.: CHE-200.595.965, Q) GLOBAL\n\nVAT-No.: CHE-200.595.965MWST ‘.~ ‘ LEGAL\n\nLEI: 506700GE1G293250X363 O NN,\n\nFOUNDATION\n\nThe content of this e-book is the property of GLEIF. Reproduction and/or sharing of this content\nis encouraged and must be accompanied by a clear attribution to GLEIF.\n","contentLength":491,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:30:41.509Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies_v1.2-final.pdf","content":"Th en eed fo rg | (0] ba | |y Reasons for African banks rejecting SME\n. . . 5\nrecognised business identity prode finance applications\ni, Reasons ... %\nSMIEs play a crucial role in / ‘ Client credit worthiness 35\ni K t KYC) and anti-\nfhe glob'al econo-my, f c?stermg nowy qur customer ( . ) an ar-r mor.rey Insufficient collateral 30\ninnovation andfinanaa[ Iaundermg (AML) requirements, in pamcular,\ndevelopment and providing have emerged as a new and growing 2013 Single obligor limit 11\ntwo thirds of the world’s jobs.? challenge for SMEs. Over the 2013-14 period, imited liauidi\nAccording to the World Bank, less than one per cent of African banks cited to Limited forex liquidity 10\nSMEs represent around 90 per regulatory compliance as the primary reason 2014 Insufficient limits with\ncent of businesses worldwide.* for rejecting trade finance applications. corresponding banks 8\nVet desoite the critical rol Between 2015 and 2019, however, as Bank balance sheet\net, despite the crmca. roe compliance requirements have increased, this a t qc; ce shee 6\nthey play, many SMEs in : . . constrain\ndeveloni o5 lack figure has grown to circa 16 per cent. This\net\\)/e opgng economcljes ?CI shows that stringent KYC/AML regulations are\nrodust usmelss?re e.ntla?fis having two unintended consequences on the et eiiieiiiiieiiiiiiiiiiiiiiiiiie.... Reasons ... %\nan ’ asa result, a.ce sgm cant trade finance sector. They are:\nbarrlers to growth. their access Client credit worthiness 30\nto finance, particularly to trade 1\nfinance, is either severely Insufficient collateral 25\nlimited gr denlgd altogethe.r, / Know your customer\nand their capacity to establish 2015 requirements 16\ncontractual domestic ' to B o )\nand international trading Insufficient limits with\npartnerships is constrained. \\ 2019 corresponding banks 7\nEven gaining access to payment 2 Single obligor limit 6\nservices is a challenge. \\\n\\ Limited forex liquidity 6\nOthers 6\nBank balance sheet\n3Setting up small and medium-size enterprises for restart and recovery’ McKinsey, June 2020 constraint 4\n“Small and Medium Sized Enterprise Finance section, World Bank website\n>African Development Bank’s Report Trade Finance in Africa: Trends Over the Past Decade and Opportunities Ahead\n\\9\n","contentLength":2244,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:30:41.509Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies_v1.2-final.pdf","content":"The LEI and financial inclusion\nA crucial step to increasing In this way, any SME holding\nfinancial inclusion in an LEI can demonstrate the\ndeveloping economies is level of transparency needed\nto encourage broad SME for it to establish a trusted . \" . . . .\nadoption of a trusted relationship with any third- The Legal Entity Identifier (LEI) is Adoption of this proven system is\nglobally recognized s;/stem party organization at home or an alpha-numeric code that links now expanding to overcome a range\nfor business identity. across borders. to a system in which the identity of new identity-related challenges\nof a legally registered organization, facing organizations across different\nThis is what is offered by the Put simply, it is the key that or ‘legal entity’, can be verified market sectors as they engage in\nGlobal LEI System. It gives enables any business to unlock quickly and efficiently by anyone, global digital commerce.\nbanks, financial institutions, i : .\npotential business partners access to both finance and anywl.1ere i can b? thougl]t of The Global LEI System is the perfect\ntrade. as a kind of digital international luti helo brid de fi\nand other regulated institutions ; q d solution to help bridge trade finance\noty [ el et LA fizsad aps and promote financial inclusion\neasy access to an SME’s key For financial institutions and contains high quality business card 2P th N lobe. It is the onl\nlegal reference data. Once regulators, the LEI improves information. across _ € g.o €. Sh e.o \\\nregistered, an SME can be risk management by enhancing - system m.emstence that is open,\nrecognized universally, since assessments of micro and There are currently 1.87 million LEls commercially neutral, standardized\nits data is openly avail:able macro prudential risk. In this in circulation, each one containing and carries the endorsement of\nelectronically, free of charge, way, it also promotes market mformal?on about an e\"t::_/ s financial regulators.\nto anyone, anywhere. integrity while containing owmiirsnlp s;tir:c::irte, ficvi |in gwho’) This makes it the only system\nmarket abuse and combating q:gs vtnsrohi e(’why ownz vflhom’) capable of establishing digitized\nfinancial fraud. and ownership o o\\ trust between all legal entities,\nto be answered unambiguously.\neverywhere.\nThe LEl is already widely\nmandated by regulators for use\nin capital markets and has been\n—_— embraced in over 200 jurisdictions\n— Q around the world. r\\\nO\n9,\n\\ '@, LEI\n\\D\n","contentLength":2474,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:30:41.509Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies_v1.2-final.pdf","content":"The positive impact of the LEI:\nBenefits for SMEs\n© m\\o (=) ° L\nBusiness ID: p— Q . More trade :{()} . Fast-track support \\ @\nCredible digital - : finance, . for national business\nidentity leads to . less red tape . digital ID schemes\ntrustworthy business § §\nSMEs can both prove who they are and © The LEI can improve an SME’s - As c'ountrie'zs'loo'k to a.dvance their own\nknow precisely who they are doing © risk profile in the eyes of lenders and - business 'dlgltal |dent1t.y schemes, the !_EI can\nbusiness with, globally, saving time and © investors, increasing its chances of accessing - ease the implementation and integration\nmoney, enabling new opportunities for © finance and securing more attractive rates. - burden on SMEs. In a globalized digital\ndomestic and cross-border trade, and . By creating the foundational step of identity, . economy, verifying the identity of legal\ncombatting financial fraud and market . the LEl also has the potential to dramatically - entities such as customers, partners and\nabuse. The Global LEI System is fast, - reduce the compliance burden and costs . suppliers is becoming an |ncreasmgl}/ Cmep|EX\nefficient and the data is free to use. All LEI - associated with stringent AML and KYC - and costly challenge. Only by establishing\ndata is verified and validated by LEl issuing - regulations. ;o trust betwgen Iegal' cpunterparties can the\norganizations and accredited by GLEIF. : - true benefits of a digitally enabled world be\n\n: © realized. The LEl is uniquely powerful in its\n\n: © ability to enable digital transformation in a\n\n§ © way that is truly interoperable for everyone.\n\n5 )\n","contentLength":1633,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:30:41.509Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies_v1.2-final.pdf","content":"The positive impact of the LEI:\nBenefits for SMEs continued... ‘e\nThe LEl is one of the few initiatives with\nreal potential to meaningfully address\nthe challenges of de-risking in developing\n. markets. The high costs of institutional due\n‘(( : diligence and information asymmetries is\n° : e a core element of the exclusion of small\n: and medium enterprises, and even some\nTrust and E Enhanced corporates, from regional and international\n: markets. A robust global enterprise identity\ntransparency ’L.}’ : cross-border opens an under-represented large base\nin supply chain . trade of SMEs and women-owned businesses to\npartnerships . : trade across Africa as well as across the\nThe SME digitalization journey has The LEI creates more transparent global n-varkets. Cenfri looks forwcfrd to the\n. . - : . deepening of LEI usage across Africa and\naccelerated dramatically during the L . and efficient cross-border exchanges the inclusion of SME and women-owned\nCOVID-19 crisis. Their successful B - of goods and data. Particularly in N\ntransition to e-commerce and free trade areas, such as the African GO AR T\nonline business is now crucial. : Continental Free Trade Area (AfCTA) LL)\nThis is the area where the LEI : . orthe Association of Southeast Asian\nshines by enabling accurate and : Nations Free Trade Area (AFTA),\nfast digital identification in supply : . the LEI can help to simplify customs °\nchains, building both transparency : procedures, accelerating @ Cenfrl\nand trust into commercial : the flow of goods. vz\npartnerships. : v 3\n) =\n- Barry Cooper,\nN \\ g Technical Director\n‘ at Cenfri\nO,\n","contentLength":1601,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:30:41.509Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies_v1.2-final.pdf","content":"k.\n® ® ) ,E \" . >\n° N = b=\nSpotlight on Africa: How the LEl is @ | = A\n° ° ° ° ° a g d \"'\\\\ 5\nboosting financial inclusion for SMEs - o W\n. _ . Impetus oo\nAn international flagship ) ) S . . ) ) . =\nS . SMEs across Africa contribute significantly to job creation and economic growth, Ve face trade financing\nproject is now underway in O L ) . :\nAfrica, designed to help SMEs yet their financial inclusion rates remain low. ~ challenges not only because\n1eE e L e tileEk sreRse According to the Reserve Bank of Zimbabwe, Zimbabwean SMEs contribute ~ weare a small company, but\ntrade finance and create new more than 60 per cent of the country’s GDP, yet only 3.8 per cent of the banking because we are unknown from\ndomestic and international sector’s loans and advances are extended to these businesses.® Zimbabwe. While we are not\ntrading opportunities. The same is true of international finance; global banks are also hesitant to provide d'lrectly excludedfrom.trade\ncredit. These conditions revealed a strong opportunity for the LEI to make a finance, wzloften recelvi \" 1\nsignificant impact, in Zimbabwe specifically and across the broader region. unf.avoura e. re?pa.ymen ern:ns\n_ _ which result in indirect exclusion. ;\nThe collaborative, multi- The LEI, as a globally recognized\nZtakeholcli.er Z\"\"_\";\"VZ has What is happening? form of business ID, will give\neen realized with the il\nsupport of the German NMB Bank Limited, Zimbabwe, is undertaking a flagship initiative to equip its = greater.credlblllty wherz wes\nderal G hroudh SME client base with LEls. apply for finance, engage in\ne e o NMB was selected on grounds of its well aligned principles to the project: international trade G\nthe Deutsch.e Gesellschaft g g p p project: new supplier relationships.\nfiir Internanona!e e A focus on enabling and deepening its SME client base. manufacturing process.\nZusammenarbeit (GIZ) GmbH. e Capacity to conduct this initiative within the given timeframe. o0 g Sl\nBetween April and June 2020, e An interest in innovating on SME identification. i\nGIZ conducted a survey® e A financial inclusion mandate. Second Muguyo,\nrevealing that LEls are Participating SMEs are already beginning to realize the benefits of LEI adoption. Flngnce and Admin Manager\nattractive for companies of all Businesses in possession of an LEI can access greater international trade, escrow at' Opperwares\nsizes and types in the region, and guarantee facilities which bolster their ability to negotiate and trade in larger\nwhich led to the development volumes, more frequently, and with less cost. NMB has also noted that the LEI d\nof the initiative.” holds the potential to reduce compliance bottlenecks SMEs experience when P\nexecuting international transactions. i\nrwy\n®More Transparency for Better Business — The Potential of Legal Entity Identifiers for African Economies, GIZ, 2020 A4\n’Promoting the Legal Entity Identifier to foster transparency and trade in African markets, January, 2021 y N\n8Re-igniting SMIE Development in Zimbabwe — Learning from Global Experiences, Governor, Reserve Bank of Zimbabwe, 2017 7 SN\n|\n","contentLength":3103,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:30:41.509Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies_v1.2-final.pdf","content":"B LEE\nDRmAER\nLSEG joined this initiative to\n%%% London facilitate wider LEI adoption\n3% Stock Exchange across Africa. By demonstrating\nthe uses and benefits of Legal\nEntity Identifiers, our aim is that\nthis project will encourage more\nentities across Africa to obtain\nLEIs. We started the project with a\n. . .\npartnership approach, which\n@ Cenfrl we intend to continue beyond\nthe pilot.\nSRR \\ = fi’i [ } Harare,\nel e icel! ‘ i @ \\’.1.: - ] Zimbabwe cornerStAo‘“Qwe*\nA R AMETEEE\nA -\nfiio SS2SS32RRRRRSEN AU AVAR Al\n| e W RN = . — ey\n\" fl?‘% oy B Ry : _; fi% = | —— LEI Analyst, N\n. s (= e @ N £ e -y |\nTl = .-g--‘ ¥ ; EL .,.. = 7 ATET Data & Analytics, LSEG\nST g i . T | T gy : R ——\nW e B iy N S e I e g9 London\n, p‘—:': ‘-:gj“v:\\\\\\\\\\‘ EV% ANV o ;’——\"' = = g e ! B T %fi StOCk EXChange\n) - N & WR&%M«! v ; ! XS = RS E S T\nL 6 g O b ih JEE ;J;e%?%‘;f '\nP e e o L ;E!;fig;;m\"’.é{l S o<, T T \"‘M\\EZ%;- b H )\nL g i ‘_._.H'SJL, TR \"rg!ffimlf‘ll;] i . Y iy o, \";f‘ sl\n2 v‘/,; ;v,\"‘,'l [ X ;7 =z “tll?t‘i;g“ 0] i i ] S £ ;: g .‘.“ \"“_»_.L\"’v»n,‘, o 3 3 A\n’( G‘- ‘FJ1 -7/‘1; i “\"ullhin:‘,‘l N oy - A s Eal v & ;i 4’4%: f :?, [:Jg, ‘\n= ;.v .')\\k\\.(fi“i\"\\v q: ‘t @ e, \\l' \\ \\é : R == z =~ — &\n= A R e i N i AR s S s\n","contentLength":1199,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:30:41.509Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies_v1.2-final.pdf","content":"Spotlight on Africa: continued...\no0\nThe increasingly stringent customer due\ndiligence requirements of the evolving\n6 6 international regulatory environment\nhas, over the past years, contributed\nHaving more African-based LEl issuers to an increase in SME trade finance\nwould contribute to promoting the LEI rejections by banks. This is an important\nconcept and facilitate LEI applications for limitation to the growth potential and\nAfrica-based entities. Forging strategic global outreach of African SMEs. The LEI\npartnerships could also bolster awareness can significantly contribute to reversing\nraising efforts among African Fls, real this trend by decreasing the cost of\nsector companies, national supervisory compliance and reshaping international\nand regulatory authorities about the LEI, trade and growth for African SMEs.\nits potential benefits and the application\nprocess. Finally, it is worthwhile to 9 9\nexplore the potential synergies between\nAfrican initiatives that facilitate client\ndue diligence and promote market\ntransparency.\n®9\n[\nSarah Weiss, Hugues Kamewe Tsafack, Yann Desclercs,\nFinancial Sector Development Advisor, Financial Sector Advisor, Managing Director at\nDeutsche Gesellschaft fir Internationale Making Finance Work Cornerstone Advisory Plus\nZusammenarbeit (GIZ) GmbH\nH >\\ Making Finance c\ng I Z Q Work for Africa ornerStgvirs‘oryeq-\n2\n","contentLength":1368,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:30:41.509Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies_v1.2-final.pdf","content":"NMB Bank Limited:\n° »\nL L L L L\nThe first Validation Agent in Africa\nThe LEl initiative has been made possible e Streamline client Within just three months, NMB Bank\nthanks to the introduction of a new onboarding. Limited has been onboarded and trained\nLEI operating model for banks, called « Improve its customer as the first Validation Agent in Africa\nthe Valldghon Agent. Afte.r working experience. ar.1d has begun to issue LEIs to |ts-SME\nclosely with GLEIF and project partners clients. NMB Bank also has obtained\nto complete the required qualification e Facilitate digital an LEl for itself which will allow it )\nprocess, NMB Bank Limited is now serving transformation. to establish its identity with other § oo\nas the first Validation Agent in Africa. o Reduce client lifecycle correspondent banks quickly In view of the emergence of a digital\nBy leveraging its KYC, AML and other management costs. and seamlessly. era and the rapid increase in demand\nregulated ‘business-as-usual’ onboarding « Open the door to the Although the full benefits of the LEI are § for gre'ate.r trar!spare'ncy by all\nprocesses, NMB Bank Limited can now development of new fully realized in the long-term, NMB . organizations, l\"ClUdl\"q regulators\nobtain LEls for its customers when verifying identity-based services Bank Limited has already begun to note - across the world, securing an LEI\ntheir identity during initial onboarding. ’ initial benefits for its day-to-day business - has become a powerful tool that\nThis new capability creates a significant * Contribute to the operations, establishing itself as the - organizations can rely on in fulfilment\nrange of strategic and operational benefits fulfilment of broader ‘first mover’ in the region, and taking - of know your customer/business\nfor the bank itself, as well as for its SME financial inclusion goals advantage of its ability to fully onboard - principles.\nclients. It enables the bank to: of the country. clients to the LEI platform. : o0\né\nB Head of Compliance,\n\nInterested to find out more Interested in obtaining an LEI for your business? B \\ V1B Bank Limited\n\nabout the Validation Agent \\L Validation Agents are just one source. LEI Issuing Organizations :\n\nframework and its benefits | | also support this process for businesses around the world.\n\nfor financial institutions? On the African continent, there are three LEl issuers in\n\noperation, with a list of global providers available\n10 )\n","contentLength":2450,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:30:41.509Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/le-lei_la-cle-qui-deverrouillera-linclusion-financiere-dans-les-pays-en-developpement_v1.2-final.pdf","content":"3:?;;;:%1 ‘ \\\nR . | B\n\nLe LEI : La clé qui déverrouillera I'inclusion - i1 '\n\n° e\\ V4 \"3 73 y 'i’ ’ / ¥ 5 ‘\nfinanciere dans les pays en développement . Ry & s !\nPlus : Coup de projecteur sur I'Afrique ; J’;\"-]'.’\" ‘ A 4 |\nComment la LSEG (London Stock Exchange Group), ! ~“ ' B : 2\nla NMB Bank Limited (Zimbabwe), la GLEIF, le Cenfri et hi 1” - o 4\nCornerstone Advisory Plus débloquent 'accés au financement ' k.\ndes transactions et dopent le potentiel économique e % * f-;g',; R\ndes entreprises africaines. \\ 0 A ? <\nAN FEEAL \"\n| @ ‘ LEl ENTITY — \\’\n\\ ’ R\n\n'4 .\n- B |\n","contentLength":569,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:31:32.660Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/le-lei_la-cle-qui-deverrouillera-linclusion-financiere-dans-les-pays-en-developpement_v1.2-final.pdf","content":"Introduction 6 5\nmillions passsiiiioaiass’\nd’entreprise dans EH TR N\nle monde Bl\nUn rapport publié en 2017 par la Société financiére internationale affirme que 65 millions BHHH N\nd’entreprises dans le monde, notamment 45 % des petites et moyennes entreprises (PME)\nsituées dans les pays en développement, accusent un déficit de 5 200 milliards de dollars en termes de :55555}5555535\nfinancement annuel total.’ Les économies africaines d’aujourd’hui, par exemple, souffrent d’un profond déficit dont s\nen matiére de financement des transactions, que 'on estime actuellement a plus de 81 milliards de dollars.? 4 5 %\nLa cause profonde de ce probleme, tant pour les banques cherchant a élargir leurs portefeuilles de de PME dans\ntrade finance que pour les multinationales cherchant a acquérir des partenaires au sein de leur chaine les pays en\nd’approvisionnement, est liée a un besoin de renforcer la transparence parmi les PME. Ces entreprises sont en développement\neffet trop nombreuses a ne pas posséder les identifiants commerciaux nécessaires a la due diligence envers\nles contreparties et a I'évaluation des risques associés.\nIl sagit d’un obstacle majeur qui freine la croissance économique mondiale. Cela se fait sentir principalement besoin de financemenF\n. N e A . . . annuel total non satisfait:\ndans les pays en développement, ou la défaillance empéche les capitaux de parvenir aux PME, que ce soit par\nle biais du trade finance ou par le biais de partenariats nationaux ou internationaux. 5 : ! 00\nmilliards\nLidentifiant d’entité juridique (LEl) peut résoudre ce probleme car il renforce la transparence\nsur le marché et engendre une plus grande confiance entre les différents intervenants.\nCe livre numérique explique comment les institutions financiéres et les PME des pays en développement,\ntoutes régions du monde confondues, peuvent utiliser le LEI (une forme d’identifiant d’entreprise reconnu et\nstandardisé) pour aborder ces problémes de front. En fournissant un LEl aux PME, les pays en développement ~ Deficit de\n. ). . . \" c . .. L financement des\ndu monde entier peuvent fortement renforcer I'inclusion financiére, permettre une participation plus étendue transactions estimé 3\naux marchés nationaux ou internationaux et, a terme, stimuler les entrées de capitaux nécessaires a leur\ndéveloppement économique. 8 1\nmilliards\n‘Rapport de la Société financiére internationale intitulé « The MSME Finance Gap » (Déficit de financement chez les micro, petites et moyennes entreprises), 2017 en Afrique\n?Trade Finance in Africa: Trends Over the Past Decade and Opportunities Ahead - Policy Research Document 3, September 2020\n","contentLength":2641,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:31:32.660Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/le-lei_la-cle-qui-deverrouillera-linclusion-financiere-dans-les-pays-en-developpement_v1.2-final.pdf","content":"Le LEIl et l’inclusion fi iere :\nI’inclusion financiere :\nCap sur l'avenir\nBien que le LEI ne soit pas une solution\nmiracle, il représente néanmoins une\nsolution particulierement puissante pour e\nfaciliter I'inclusion financiére dans les\npays en développement. Lintroduction de Le LEI est en mesure de créer des échanges de biens et\nla fonction d’agent de validation auprés § de données plus transparents et plus efficaces au travers\ndes institutions financiéres a permis de § des frontiéres dans la Zone de libre-échange continentale\nbeaucoup avancer dans la réalisation § africaine. C’est une premiére étape vers une plus grande\nde cet objectif, tout en conférant de inclusion financiere et vers la résolution des difficultés\nnombreux avantages a la fois aux banques inhérentes au financement des transactions en Afrique.\nparticipantes et a leurs entreprises Compte tenu du rythme rapide de la numérisation et\nclientes. : de I'évolution de la réglementation sur ’'ensemble du\ncontinent africain, le LEI est l'outil idéal. C’est une solution\nAutant les émissions de LEl augmentent : transfrontaliére attrayante et préte a 'emploi en matiére\ndans les régions en developpement, autant : d’identification. Elle est ouverte, fiable et facile a intégrer\nle reste du monde fait confiance aux : dans les cadres réglementaires.\nentreprises qui stimulent les économies °0\nconcernées. Les progres réalisés en la '\nmatiére feront alors augmenter les entrées Stephan Wolf, 7 m o\nde capitaux internationaux qui alimentent PDG de la GLEIF F ‘? yo | @ L E I LEGAL\nun développement économique rapide. & IDENTIFIER\n: E N FOUNDATION\n: N J\nLa GLEIF cherche continuellement a dialoguer avec les \\\ngouvernements, les ONG, les banques et d’autres parties . . . .\nprenantes souhaitant élargir l'initiative LEI en Afrique ou > Veuillez ecr.l re a l'adresse mfc?@glelf.o.rg\nreproduire le modéle dans d’autres pays en développement. / pour obtenir de plus amples informations.\n11 )\n","contentLength":1957,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:31:32.660Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/le-lei_la-cle-qui-deverrouillera-linclusion-financiere-dans-les-pays-en-developpement_v1.2-final.pdf","content":"R GLOBAL . ® . :\n9, LEGAL : : t : \"n\nD, LEl . (©Ocenfri ©rnerstone = B0\nFOUNDATION : : Advisory+ : /\nEtablie par le Conseil de stabilité : Cenfri est une agence indépendante et & © Cornerstone Advisory Plus est un © NMB Bank Limited (anciennement\np . . .\nfinanciére en juin 2014, la Global : but non lucratif pour I'impact économique, : cabinet de conseil implanté en Cote : National Merchant Bank of\nJ N N N\nLegal Entity Identifier Foundation : implantée au Cap, en Afrique du Sud. : d’Ivoire (Afrique de I'Ouest), qui : Zimbabwe Limited) est une banque\n(GLEIF) est une organisation a but i Cenfri ceuvre pour l'intégrité financiere . aégalement un cabinet a Dakar : commerciale fondée en octobre\nnon lucratif créée pour soutenir la * etjouit d'une grande expérience de © (Sénégal). Le cabinet se spécialise i 1992et enregistrée au Zimbabwe. La\nmise en ceuvre et l'utilisation de ¢ larecherche, de la formation, du : dans les services de conseil et de : vision de la banque est de devenir le\nI'identifiant d’entité juridique (LEI) © développement des compétences, de la : formation aupres des institutions : premier groupe de services financiers\ndans le monde. ¢ définition d’orientations et de modules, de : privées, ainsi que dans le secteur : surson marché cible. Sa mission est\nLa GLEIF permet de prendre des : l'engagement ciblé et du conseil dans les . public, y compris aupres des : de fournir des services financiers\ndécisionsp lus intellipentes moins * domaines des relations avec les banques * régulateurs et des superviseurs du *aux particuliers fortunés et aux\ncoUteusespet lus fiagbles (Jant AUx : correspondantes, de la mise en ceuvre : secteur financier. Ses domaines : entreprises, ainsi que des produits\nentités avec I(—E)s uelles faiqre des : delaréglementation de lutte contre le : dexpertise sont la conformité a la :uniques, facilités par la technologie,\naffaires. Ses ser(\\q/ices arantissent : blanchiment dargent et le financementdu ~ : réglementation sur la lutte contre le : aux PME et a l'ensemble du marché.\nVinté ri.té o érationngelle du ¢ terrorisme, des approches fondées sur les ¢ blanchiment d’argent, le financement : Lastratégie de la banque vise en\nGIobagI LE| Spstem Ui fournit * risques, de la supervision fondée sur les * duterrorisme, I'évaluation des * premier lieu l'optimisation de son\nUn acess r;/tuit éll’qensemble du : risques et de I'inclusion financiére, entre © risques a I\"échelle des entreprises, : offre numérique afin d’assurer une\n& ertoirg mondial des LEI. La : autres. Cenfri ceuvre principalement auprés : les processus de connaissance du . prestation de service homogéne\nGLpEIF est supervisée par Ie. Comité : des ministeres publics, des régulateurs, . client et les questions relatives aux : auprés de ses clients existants et\nde surveillanpce e Ien':entaire : des fournisseurs de services financiers : banques correspondantes, y compris ;. futurs, par le biais de points de\ndes LEI un grou frassemblant ¢ (banques et compagnies d’assurance, entre : la problématique mondiale de la * contact innovants et stimulants. NMB\ndes autloritéi uFl;Ii Les et des © autres), des entreprises et professions : réduction des risques. Cornerstone : Bank Limited continue également de\nobservateurs (Fj)e Ijs 46 50 pavs : non financiéres désignées et d’autres : Advisory Plus a été fondé par un : promouvoir I'inclusion financiére et\ndans le monde SF;n sicee sopciZI ost : parties prenantes, aux niveaux régional, : spécialiste jouissant de plus de 20 ans : aintensifié 'adoption de différentes\nsitué 3 Bale en.Suisse g * national et mondial (y compris dans les i d’expérience du secteur financier en i technologies permettant d'améliorer\n' * pays du Groupe anti-blanchiment de * Afrique de I'Ouest et dans le contexte : l'expérience d’intégration pour les\n¢ I'Afrique orientale et australe, du Groupe : des multinationales. ¢ futurs clients de la banque.\n) ) : intergouvernemental d’action contre le : ) . : ) )\nPour de plus amples informations, : 8 i . f . Pour de plus amples informations, . Pour de plus amples informations,\ni ) : blanchiment en Afrique de I'Ouest et de : . ) : ) )\nveuillez consulter le site E . S o . veuillez consulter le site . veuillez consulter le site\n. * I'Alliance pour l'inclusion financiere). : f :\nwww.gleif.org : : www.cornerstoneadvisoryplus.com : www.nmbz.co.zw\n: Pour de plus amples informations, : :\n: veuillez consulter le site\n: www.cenfri.org\n","contentLength":4442,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:31:32.660Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/le-lei_la-cle-qui-deverrouillera-linclusion-financiere-dans-les-pays-en-developpement_v1.2-final.pdf","content":"020\nv\nBlog de la GLEIF\n\nSource:\n\nGlobal Legal Entity Identifier Foundation,\n\nSt. Alban-Vorstadt 5, 4052 Basel, Switzerland\n\nPrésident du Conseil d’administration: Steven Joachim, PDG: Stephan Wolf\n\nNuméro d’inscription au Registre du commerce: CHE-200.595.965, ,\"’ GLOBAL\n\nNuméro de TVA : CHE-200.595.965MWST o) Ry\n\nLEl : 506700GE1G29325QX363 \\ ‘ ’ IDENTIFIER\n\nFOUNDATION\n\nLe contenu de ce livre électronique est la propriété du GLEIF. La reproduction et/ou le partage de ce\ncontenu est encouragé et doit étre accompagné d’une attribution claire au GLEIF.\n","contentLength":556,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:31:32.660Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/le-lei_la-cle-qui-deverrouillera-linclusion-financiere-dans-les-pays-en-developpement_v1.2-final.pdf","content":"’ e, 7 ) ° o, 7 ) ° . ..\nLa nécessité d’une identité d’entre prise Raisons pour lesquelles les banques africaines\nT . refusent les demandes de trade finance des PME®\nreconnue a I’échelle mondiale\ne eeteeeiiiiieiiiiiiiiiiiiiiiieeee.... Raisons ..o %\nLes PME jouent un réle crucial ‘ Solvabilité du client 35\ndans I'’économie mondiale. Les exigences de connaissance du client (KYC) et G te i cant 30\nElles facilitent I'innovation et de lutte contre le blanchiment d’argent (AML), arantie insuffisante\nle développement financier et notamment, sont un nouveau défi de plus en De Limite d’un seul débiteur 11\nreprésentent deux tiers de tous plus important pour les PME. Entre 2013 et 2014, 2013\nles emplois créés dans le monde’ moins de 1% des banques africaines citaient la 3 Liquidité limitée des devises 10\nSelon la Banque mondiale, les conformité réglementaire comme raison principale o , .\nPME représentent environ'90% de les poussant a refuser des demandes de trade 20 14 Limites insuffisantes aupres\nP . des banques correspondantes 8\ntoutes les entreprises du monde.* finance. Entre 2015 et 2019, en revanche, alors\n’ que les exigences liées a la conformité avaient Contrainte liée au bilan\nPourtant, malgré leur importance été renforcées, ce chiffre est passé a environ de la banque 6\ncruciale, les PME des pays en 16% . Cela montre que le resserrement de la\ndéveloppement sont nombreuses réglementation KYC/AML a eu deux conséquences\na ne pas avoir d’identifiant inattendues sur le secteur de la trade finance. e eeeiieiiiiiiciiiciiiiciceceeo... Raisons ..o %\ncommercial robuste et sont donc Ces conséquences sont les suivantes:\nconfrontées a de fortes barriéres i Solvabilité du client 30\na la croissance: leur accés au Garantie insuffisante 25\nfinancement (plus particulierement\nen trade finance) est sévérement / De Ex:gelr?ces’ CI?;'C\"“’\"‘? 16\nlimité, voire totalement fermé, ' 2015 son client’ (KYC)\net elles ont du mal a établir x Limites insuffisantes auprés\ndes partenariats commerciaux \\ a des banques correspondantes 7\ncontractuels a I'échelle nationale L.\n. ) R 2019 Limite d’un seul débiteur 6\nou internationale. Il leur est méme 2 \\\ndifficile d’accéder aux services de \\ Liquidité limitée des devises 6\npaiement.\nAutres 6\nContrainte liée au bilan\n3‘Setting up small and medium-size enterprises for restart and recovery’ McKinsey, June 2020 dela banque 4\n“Section du site Web de la Banque mondiale consacrée au financement des petites et moyennes entreprises\n>African Development Bank’s Report Trade Finance in Africa: Trends Over the Past Decade and Opportunities Ahead\n","contentLength":2587,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:31:32.660Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/le-lei_la-cle-qui-deverrouillera-linclusion-financiere-dans-les-pays-en-developpement_v1.2-final.pdf","content":"Le LEI et 'inclusion financiere\nUne étape cruciale pour renforcer Ainsi, toute PME possédant\nPinclusion financiére dans les un LEI démontre le niveau de\néconomies en développement transparence requis pour établir\nconsiste @ enc.ourager une plus’ une relatlon. de.conf.'lance avec Lidentifiant d’entité juridique (LEI) L'adoption de ce systeme avéré se\ngran‘de ac-iop tion par Ies. PME d'un - toute orgaln’lsahon tierce, dans son est un code alphanumérique relié a généralise afin de répondre a de\nsystéme fiable ?t mo.nfhalement pays ou a fétranger. un systeme au sein duquel P'identité nouveaux problemes en matiere\nreconnu pour I'identité des Le LE] imol Ia clé d’une organisation légalement d’identité, auxquels les organisations\nentreprises. e. q ’est tou.'|c|5||rr1p e‘mzf\\t acle enregistrée, appelée ‘entité juridique’, font face dans différents secteurs\nClest ce quioffre le Global LEI ::'Icreevr?sr:;tfl fi?naancccee;entfcnei AU peut étre vérifiée rapidement et de fnaltché dans le cadre de Ietfrs?\nSystem. Il permet aux banques P efficacement par tout le monde et opérations de commerce numérique,\nT ’ commerce. partout. On pourrait le comparer a a I’échelle mondiale.\naux institutions financieres, o ) . une carte d’identité professionnelle .\naux partenaires commerciaux Pour les institutions financieres numérique et internationale, !.e'GIobaI LEI System est la s'olutlon\npotentiels et a d’autres institutions et les régulateurs, le LEI améliore car chaque LEI ‘enregistre’ des idéale P?ur con.1bler le fossé\nréglementées de facilement la gestion des risques en T en matiere de financement dfs )\naccéder aux principales données optimisant 'évaluation des risques qualité. ;’:::i;?:';saii‘I’éo:oonu(;’:'::!(;;dus'on\njuridigues de. refererTce d une pruden‘ue’ls mlcrqeconomlques Il existe actuellement 1,87 million de actuellement le seul systeme ouvert,\nPME. Une tO'S enregistrée, la et mac.roeconomlo]ues. De cette LEI en circulation, qui contiennent commercialement neutre, normalisé\nPME peut étre reconnue dans le fagon, il promeut également chacun des informations sur la et approuvé par les régulateurs\nmonde entier car quiconque, a I'intégrité du marché tout en structure de propriété d’une entité e\ntout endroit, peut consulter ses maitrisant les abus de marché et répondent sans ambiguité aux . . .\ndonnées gratuitement par voie et en luttant contre la fraude questions relatives a I'identité Csla el set{l systeme (Ea.pa'ble\nélectronique. financiére. (‘qui est qui’) et a la propriété RS Ue confia'nc.e r.1u'mer|see\n[‘qui appartientt A qur), entre toutes les entités juridiques,\npartout dans le monde.\nLe LEI est déja largement imposé par\nles régulateurs sur les marchés des\ncapitaux et a été adopté dans plus de\nP 200 juridictions a travers le monde.\n— oK\n® ‘ ¥, LEI\nD,\n","contentLength":2789,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:31:32.660Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/le-lei_la-cle-qui-deverrouillera-linclusion-financiere-dans-les-pays-en-developpement_v1.2-final.pdf","content":"’ [ [ .f d\nL'impact positif du LEI :\nO O] N ‘$_—| N :_ _—C...C\nIdentité — Q . Plus de %:C‘é} . Soutien plus \\\nd’entreprise : : financement . rapide aux\nune identité . des transactions, : programmes\nnumérique crédible engendre des . moins de démarches . nationaux d’identité\nq g : .\n\nopérations commerciales fiables :administratives © numérique des entreprises\nLes PME peuvent a la fois prouver qui elles Le LEI peut améliorer le profil de risque Alors que différents pays cherchent a\nsont et savoir précisément avec qui elles - d’'une PME aux yeux des préteurs et des g développer leur propre programme d’identité\ntraitent dans le monde, ce qui permet . investisseurs, ce qui augmente leurs chances . humerique des entreprises, le LEI peut alléger\nd’économiser du temps et de I'argent, . d'accéder au financement et d’obtenir des la charge de mise en ceuvre et d'intégration\ncrée de nouvelles opportunités © taux plus intéressants. En posant les bases - pour les PME. Au sein d’une économie\ncommerciales nationales et del'identité, le LEI peut aussi fortement . humerique mondialisée, vérifier I'identité\ntransfrontaliéres et favorise la lutte contre ¢ réduire la charge de mise en conformité et § d’entités juridiques, comme celle de clients,\nla fraude financiére et les abus de marché. © les colits associés a une réglementation - de partenaires et de fournisseurs, constitue\nLe Global LEI System est rapide et efficace, ~ © AML et KYC plus stricte. - un défi toujours plus complexe et coliteux. Ce\net I'utilisation des données est gratuite. : - Nestqu'en instaurant la confiance entre les\nToutes les données LEI sont vérifiées et contreparties juridiques que I'on peut profiter\nvalidées par les organisations émettrices : - des réels avantages d’'un monde numérise.\nde LEI, puis accréditées par la GLEIF. : - LeLElest d'une puissance unique dans\n\n: : sacapacité a permettre la transformation\n\n: © numérique d’une maniére qui soit réellement\n\n: © interopérable pour tous.\n\n\\FD\n","contentLength":1984,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:31:32.660Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/le-lei_la-cle-qui-deverrouillera-linclusion-financiere-dans-les-pays-en-developpement_v1.2-final.pdf","content":"’ L L L\nL'impact positif du LEI :\nAvantages pour les PME a continué... ‘e\nLe LEI est l'une des rares initiatives pouvant\nréellement répondre aux enjeux de la\n‘(( réduction des risques sur les marchés en\ndéveloppement. Les colits élevés de la\ndue diligence institutionnelle, ainsi que\nFasymétrie de I'information, sont I'une des\n: principales raisons pour lesquelles les petites\n... et moyennes entreprises - et méme quelques\nDes partenariats . Optimisation grandes - sont exclues des marchés régionaux\nfiables et transparents : . des transactions et internationaux. Une lfienute d’entreprise :\n\nB : s robuste reconnue mondialement permettra a de\nau sein de la chaine ot ansfrontaliéres trés nombreuses PME et entreprises détenues\nd’appro visionnement par des femmes, jusqu’ici sous-représentées,\n\nR : , d’effectuer des transactions dans toute I’Afrique\n\nLa numerisation des PME s'est - LeLEl permet des échanges et sur les marchés internationaux. Cenfri se\nfortement accélérée durant la crise : - transfrontaliers de biens et de données réjouit a I'idée de renforcer I'utilisation du\nde la COVID-19. Il est maintenant - plus transparents et plus efficaces. LEI sur 'ensemble du continent africain,\nessentiel qu’elles réussissent : . En particulier, dans les zones de libre- ainsi que d’inclure les PME et les\nleur transition vers le commerce : échange telles que la Zone de libre- entreprises détenues par des\nélectronique et les activités en : : échange continentale africaine et la femmes dans I’économie\nligne. C’est 1a que le LEI peut avoir H (zjone de Iibrz—étl:hangz de I:jAssociation mondiale.\nle plus d’impact, en instaurant . des nations de I'Asie du Sud-Est, °\nune identification numérique - le LEl peut simplifier les procédures °° @ Cenfrl\nexacte et rapide dans les chafnes :douanieres, ce qui facilite la vz\nd’approvisionnement et en © circulation des biens. W\nrenforcant a la fois la : | .\nconfiance et la : / i\ntransparence dans — I &\nles partenariats « e — Barry Cooper,\ncor:merciaux. I\\,r«] \\@ Directeur technique\n\n‘ chez Cenfri\n\n5\n","contentLength":2049,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:31:32.660Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/le-lei_la-cle-qui-deverrouillera-linclusion-financiere-dans-les-pays-en-developpement_v1.2-final.pdf","content":"..\n\\ /]\nde proj I'Afrique : | N\no \\\\>\nCoup de projecteur sur I'Afrique : Comment le e\nLEI renforce l'inclusion financiere pour les PME\n=\n! g/ 1)\n_ . . » LUimpulsion oo\nUn projet phare international a été . . N - , . . . p B s\nlancé en Afrique afin d’aider les Bien que les PME contribuent fortement a la création d’emplois et a la croissance ~ Nous rencontrons des difficultés\nPME 3 utiliser le LEI pour débloquer économique dans toute I'Afrique, leur taux d’inclusion financiére reste faible. , :n mat:;rende,{n;,ancelm;n;:lesr\ne sEass A FReneamEn: des Selon la banque centrale du Zimbabwe, les PME du pays sont responsables de plus ‘ qr::;‘:)usososr’nr:essjr‘r‘eeenirep,:;:e\ni 5 de 60% du PIB national mais ne se voient accorder que 3,8% des préts et avances A A . A\ntransactions et créer dg nouyelles Ofi o ! a odesp de petite taille mais aussi parce que\nopportumte; com meFCIaIes a consentis par les banques. nous sommes peu connues et venons\nI'échelle nationale et internationale. Il en est de méme pour le financement international, les banques mondiales hésitant du Zimbabwe. Bien que nous ne\na accorder des crédits. Ces conditions ont mis une opportunité considérable en soyons pas directement exclues du f\nlumiéere: le LEI peut avoir un impact significatif, au Zimbabwe en particulier mais fir'mr’n:_e{nent des transactions, HES\négalement dans I'ensemble de la région. béneficions souvent de conditicliSiy\n.. . de remboursement défavorables qui p\nCette initiative collaborative, . % e\n) ble plusi 4 Que se pa sse-t-il? entrainent une exclusion indirecte. Le\nCED GBS EUTETELTES [P o . o LEI, en tant qu’identifiant d’entreprise\nprenantes, a été réalisée avec NMB .Bank le\\lted, une balnque du Zimbabwe, lance une initiative phare pour reconnu dans le monde, renforce\nle soutien du gouvernement fournir un LEl a ses PME clientes. notre crédibilité lorsque nous voulons\nfédéral allemand, par le biais NMB a été choisie car ses principes correspondent parfaitement au projet: demander un crédit, effectuer des\nCRI S R sl I e Priorité donnée a la responsabilisation de ses PME clientes et a transactions internaticii.\nT TR PR A U I laugmentation du nomIlJ:re de clients. des relations avec SRl\n(GIZ) GmbH (agence de coopération g . : fournisseurs dans-le cad:_' X\ninternationale allemande pour le e Capacité a mener cette initiative dans un laps de temps prédéfini. processus de fabric ation.\ndéveloppement). e Désir de faire avancer I'innovation en matiére d’identification des PME. 'YL '\nEntre avril et juin 2020, la GIZ a * Un mandat d’inclusion financiére. \"\nmené une enquéte® qui a révélé que Les PME participantes commencent déja a réaliser les avantages du LEl. Les Second Muguyo,\nle LEI est attrayant aux yeux des entreprises qui possédant un LEI ont accés a de plus nombreuses fonctionnalités de Responsable du financement\nentreprises de tqutes taillles'et de commerce internat‘ional,.dg séquestre et de garantie, qui renforcent leur capacité et de 'administration chez\ntm{s types au sein d'e_la région, ce anégocier et’a ccammeruahser <’:1e plus gros volumes, plus SOL’,Ivent et pour des Copperwares\nqui a abouti sur l'initiative.” colts moins élevés. NMB note également que le LEI peut atténuer les goulets )\nd’étranglement en matiére de conformité, auxquels les PME font face dans le cadre ~ ‘i\nde I'exécution de transactions internationales. ‘\nSl\n®More Transparency for Better Business — The Potential of Legal Entity Identifiers for African Economies, GIZ, 2020 A4\n’Promoting the Legal Entity Identifier to foster transparency and trade in African markets, January 2021 3 N\n8Re-igniting SMIE Development in Zimbabwe — Learning from Global Experiences, Gouverneur de la banque centrale du Zimbabwe, 2017 7 ) \\\n)\n","contentLength":3727,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:31:32.660Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/le-lei_la-cle-qui-deverrouillera-linclusion-financiere-dans-les-pays-en-developpement_v1.2-final.pdf","content":"[ (EGAL\n& LEl &\nLe LSEG s’associe a cette\ninitiative afin de faciliter une plus\n&35 London 1 j\n%‘%g London range grandle adoption du LEl en {\\fnque.\nEn démontrant les utilisations et\navantages de l'identifiant d’entité\njuridique, nous voulons que ce projet\nencourage les entités de toute I’Afrique\na obtenir un LEI. Nous avons démarré le\nprojet dans une optique de partenariat\n° hY\n@ cenffl et comptons le poursuivre au-dela\nde la phase pilote.\n- B q : Harare, @©rnerstone\ne il N e 7 Zimbabwe Vo\nYR v R\nB s WCORT AN\n/ i | W ecaisaeeeee NANANG |\n| ] 1% (W ==sEEREEEEaEEEE I | > b s = =\ne o (W ssemazesaazeae: \\ el — Alberta Abbey,\n= I ) ([ =22amanmeanzans) gy S L analyste LEI, N\ne o e ST il 2 : ‘- S e — — Donzées et Analyse, LSEG '\ns il = B b ~ ol o = , [V /4 .\ne - e e | E— et 8 T P —T— SVED\nW e B iy b =y L ] e %”f\"“ London\nR mfiw AL el 1 e = e BEX Stock Exchange\nR = S v~ B “\"“\"myml S Y ey T e S =‘a\\§4‘—.] |\nil whih R T | T NS\nA S W Sl RO ] iy 5 g ',‘ F B —\n‘,r é‘: : di\"agi‘z ‘-1ll‘iq1|iilihi‘;ll e asl . ‘\\ J:i J'L'j:,,r ‘ -, Ny | - | a ! =\n==k V22 MY 7;.;;- e ) ; vt \" iy ot 31’:_,,4 ~_’)‘ i TG &\nA S s T N . : ! b{ki . o9 =\n2 . oahhe TREEE = s~\nB G T RO RN - —r\nEs o > &Q‘ s (~ SN LU g : M\nP oSS i@ = % =y W AL N ,\\\\1; 2 N P T s\n","contentLength":1236,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:31:32.660Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/le-lei_la-cle-qui-deverrouillera-linclusion-financiere-dans-les-pays-en-developpement_v1.2-final.pdf","content":"Coup de projecteur sur I’Afrique : a continué... o0\nLa réglementation internationale\névolue et les exigences de due diligence\na I’égard du client sont de plus en plus\n6 6 strictes, de sorte que, ces derniéres\n. ) » ) ’ années, les banques ont été de plus en\ns'ily c_\"’a' t plus d'émetteur. s de LEl implantés plus nombreuses a refuser les demandes\nen Afrl.q.ue, c.ela renfor.cerc_:ut le concept du LEI de trade finance des PME. Cela limite\net_f ‘,’C' I{ ter, ait les app Ilcaf-:ons d',‘,LE’ p our les fortement le potentiel de croissance et la\nentités s:tu?es sur ce,cc?ntment. L etc.belssement portée mondiale des PME africaines. Le LEI\nde partenariats stratégiques p o.ur. r i c_—zgal S peut véritablement aider a renverser cette\n- r e\"]_c orcer les efj\" EES de_sefm bilisation des ) tendance, en réduisant le coit de mise en\ninstitutions fina,nc:eres afnca.m,es, de_s entreprises conformité et en remodelant le commerce\ndu.secteur réel, ¢,1es autorlte_s nanonc-lles de I G G\nsurveillance et de réglementation au sujet du LEl, PME africaines.\nde ses avantages potentiels et du processus de\ndemande. Pour finir, il serait judicieux d’explorer 9 9\nles potentielles synergies entre différentes\ninitiatives dafricaines facilitant la due\ndiligence a I’égard du client et promouvant\nla transparence du marché.\n°9\n[\nSarah Weiss, Hugues Kamewe Tsafack, Yann Desclercs,\nConseillére pour le développement du Conseiller financier, Initiative Directeur général chez\nsecteur financier, Deutsche Gesellschaft « Making Finance Work for Africa » Cornerstone Advisory Plus\nfur Internationale Zusammenarbeit (GIZ)\ni )\\ Making Finance c\ng I Z O Work for Africa ornerStgvirs‘oryeq-\n9 )\n","contentLength":1667,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:31:32.660Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/le-lei_la-cle-qui-deverrouillera-linclusion-financiere-dans-les-pays-en-developpement_v1.2-final.pdf","content":"NMB Bank Limited : —.-.—@' ‘\n° »\nLe premier agent de validation en Afrique\nUinitiative LEl a vu le jour grace a un nouveau e Rationaliser 'intégration En seulement trois mois, NMB Bank\nmodéle opérationnel d’émission de LEI pour des nouveaux clients. Limited a été intégrée puis formée en sa\nles banques: 'agent de validation. Ayant o Perfecti qualité de premier agent de validation\ntravaillé en étroite collaboration avec la GLEIF erfectionner son d'Afrique, et a commencé 3 émettre des\net avec les partenaires du projet pour suivre le €xpérience client. ' ;\nd lification. NMB Bank Limited LEI pour ses PME clientes. NMB Bank a\n\nprocessus de quafincation, ank LUMIed o raciliter la transformation également obtenu son propre LEI, ce qui\nest maintenant le premier agent de validation L. . . .. | \" e@\nd'Afrique numerique. lui permet de prouver son identité aupres :\n\n. . : o Réduire les colits de gestion d al.Jt.rels banques correspon‘dantes, avec Nous sommes a I'ére numérique et\nEn tirant parti de ses processus de connaissance . rapidité et de facon homogeéne. \" toutes | isations d d\ndu client, de lutte contre le blanchiment du cycle de vie client. _ _ . tou es les organisations au monde, y\nd’argent et d’autres processus réglementés o Faciliter le développement Blle.n que les avantages du LEI ne puissent . compr is les régulateurs, demandent\nordinaires de I'intégration du client, NMB de nouveaux services véritablement se manifester que sur le . une plus grande transparence. Dans\nBank Limited peut désormais obtenir un LEI fondeés sur identité long terme, NMB Bank Limited a déja - cecontexte, le LEI est devenu un outil\npour ses clients lors de la vérification de leur ’ remarqué de premiers bienfaits dans ses : puissant auquel les organisations\nidentité, dans le cadre de I'intégration initiale. e Contribuer a la réalisation opérations commerciales quotidiennes et peuvent se fier pour s’acquitter de\nCette nouvelle capacité confere de nombreux des objectifs globaux s’est position née comme un précu rseur leurs oingations de connaissance\navantages s‘trateglques et c?peranp‘r\\nels, non d’inclusion financiére dans la région, en tirant parti de sa du client ou respecter leurs principes\nsgulement ala banqu‘e mais aussi a ses PME du pays. capacité d’intégration totale des clients . commerciaux.\nclientes. Elle permet a la banque de: :\n\nsur la plateforme LEI. Y\nil Viola Pamela Ndlovu,\n\nVous voulez en savoir plus sur le Vous voulez obtenir un LEI pour votre entreprise? Responsgkfle de la\n\ncadre d’agent de validation et \\L Les agents de validation ne sont qu’une facon parmi d’autres conformite, i\n\nsur les avantages qu’il offre | | de le faire. Les organisations émettrices de LEl appuient S B Bank Limited\n\naux institutions financiéres? également ce processus pour les entreprises du monde entier.\n\nTéléchargez le livre numérique Il existe trois émetteurs de LEI sur le continent africain.\n\nde la GLEIF La liste des fournisseurs internationaux est fournie\n","contentLength":2978,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:31:32.660Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/2021-08-10-global-digital-business-identity-initiative-launches-to-boost-financial-inclusion-for-african-businesses_v.1.1-final.pdf","content":"I N (Eoh\n\n&y LE| .\nPress release\n\nGlobal Digital Business Identity Initiative Launches to Boost Financial Inclusion for African\nBusinesses\nLSEG (London Stock Exchange Group), Zimbabwe’s NMB Bank Limited, GLEIF, Cenfri and Cornerstone\nAdvisory Plus unlock access to trade finance and boost economic potential for SMEs\n10 August 2021 - Basel - An international flagship project designed to expand financial inclusion among\nsmall to medium sized enterprises (SMEs) especially on the African continent has launched today. The\nproject has been financed with the support of the German Federal Government through the Deutsche\nGesellschaft fiir Internationale Zusammenarbeit (GIZ) GmbH.\nThe collaborative initiative is designed to equip SMEs across Africa with globally recognized business\nidentities, in the form of Legal Entity Identifiers (LEls). The initiative was launched in Zimbabwe with\nNMB Bank Limited, which is working to equip local SMEs with LEls. This project has the potential to be\nscaled across other countries within Africa. The LEl is comparable to an international company ID card;\nit contains good quality business card and ownership structure information about a legal entity which\ncan be verified quickly and efficiently by anyone, anywhere, enabling organizations to know precisely\nwith whom they are doing business. The verifiable company data results in transparency in the\nmarketplace and builds greater trust between market participants.\nSupplying LEIs to African SMEs aims to strengthen financial inclusion in the region by enabling them\nto apply for trade finance and establish contractual, regulated agreements with banks, payment\nnetworks and trading partners, leading to broader access to financial services and greater\nparticipation in both domestic and international markets. Ultimately, the intention of the initiative is\nto strengthen Africa’s SME base and increase the flow of inbound capital needed to fuel the\ncontinent’s economic development.\nToday, Africa’s heterogeneous economies suffer from a severe trade finance gap, which is currently\nestimated to be more than US$81bn.! The limited availability of transparent key reference information\nfor African businesses, together with the perceived risk of trading with them, is a major challenge both\nto banks seeking to expanding trade finance portfolios on the continent and to international business\npartners seeking to engage this underutilized, but nascent sector.\nBy working with African banks to enable them to issue LEls, the initiative not only addresses this\nchallenge, but also aims to reduce the compliance burden associated with stringent anti-money\nlaundering (AML) and know your customer (KYC) regulations. Today, this overhead routinely prevents\nbanks from lending to new African SMEs due, in large part, to ID validation and verification difficulties.\nOver the 2013-14 period, less than one per cent of African banks cited regulatory compliance as the\nprimary reason for rejecting trade finance applications. Between 2015 and 2019, however, as\ncompliance requirements have increased, this figure has grown to circa 16 per cent.?\nUsing the LEI for identifying legal entities in cross-border trade could also enable banks to significantly\nreduce both cost and effort in data reconciliation.\n1 African Development Bank’s Report Trade Finance in Africa: Trends Over the Past Decade and Opportunities\nAhead\n2 As above.\n1\n","contentLength":3414,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:31:47.694Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/2021-08-10-global-digital-business-identity-initiative-launches-to-boost-financial-inclusion-for-african-businesses_v.1.1-final.pdf","content":"I N (Eoh\n\n&y LE| .\nWho is involved?\nThe LEl initiative is a collaborative effort between:\n- The Global Legal Entity Identifier Foundation (GLEIF), a not-for-profit founded by the G20 and\nFinancial Stability Board which manages the global network of LEI issuing organizations and supports\nthe availability of the Global LEI System;\n- LSEG (London Stock Exchange Group), which is the initiative’s LEl issuing organization;\n- Zimbabwe’s NMB Bank Limited, which is equipping local SME customers with LEls;\n- The Centre for Financial Regulation and Inclusion (Cenfri), an independent, not-for-profit think tank\nwhich works on African financial sector development;\n- Cornerstone Advisory Plus, which specializes in financial sector advisory and training services.\nScope of opportunity\nTo gain insights into the accessibility and potential benefits of introducing LEls in African markets, the\nDeutsche Gesellschaft fiir Internationale Zusammenarbeit (GIZ) GmbH conducted a survey between\nApril and June 2020.3 The survey showed that LEls are attractive for companies of all sizes and types\nin the region and led to the development of the initiative. “By acting as a reliable, proof of existence\nto business partners in their value chain, the LEl can support companies in engaging in trading activities\nfor cross-border commerce. Given the global nature of the LEI, the greatest benefit may appear in\ncross-border transactions. [...] LEIs may improve companies’ access to financial services by enabling\npreviously un(der)served clients such as SMEs to make their ownership structure and credible identity\naccessible to banks,” 4 the authors concluded.\nThe Validation Agent (VA): A new operating model for LEl issuance / NMB Bank Limited first VA in\nAfrica\nThis global digital business identity initiative has been made possible thanks to the introduction of a\nnew LEI operating model for banks known as the Validation Agent.> NMB Bank Limited serves as the\nfirst Validation Agent in Africa.\nBy leveraging their KYC, AML and other regulated ‘business-as-usual’ onboarding processes, NMB\nbank can now obtain LEIs for its customers when verifying their identity during initial onboarding. This\nenables the bank to improve its customer experience, facilitate digital transformation and reduce\n3 Deutsche Gesellschaft fur Internationale Zusammenarbeit (GIZ) GmbH: More Transparency for Better\nBusiness — the Potential of Legal Entity Identifiers for African Economies 2020.\n4 Extract taken from Deutsche Gesellschaft fiir Internationale Zusammenarbeit (GIZ) GmbH: More\nTransparency for Better Business — the Potential of Legal Entity Identifiers for African Economies 2020.\n5 The Validation Agent Framework is a new operational model in the Global LEI System, which allows financial\ninstitutions to obtain and maintain LEls for their clients in cooperation with accredited LEI Issuer Organizations.\n\n2\n","contentLength":2889,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:31:47.694Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/2021-08-10-global-digital-business-identity-initiative-launches-to-boost-financial-inclusion-for-african-businesses_v.1.1-final.pdf","content":"I N (Eoh\n\n&y LE| .\nclient lifecycle management costs, while opening the door to the development of new identity-based\nservices.\nStakeholder quotes\nAlberta Abbey, LEI Analyst, Data & Analytics, LSEG:\n“LSEG joined this initiative to facilitate wider LEI adoption across Africa. By demonstrating the uses\nand benefits of Legal Entity Identifiers, our aim is that this project will encourage more entities across\nAfrica to obtain LEls. We started the project with a partnership approach, which we intend to continue\nbeyond the pilot.”\nStephan Wolf, CEO, GLEIF:\n“The LEI has the potential to create a more transparent, efficient cross-border exchange of goods and\ndata under the African Continental Free Trade Area. This is the first step toward greater financial\ninclusion and overcoming the challenges associated with access to trade finance in Africa. Considering\nthe high pace of digitization and regulatory development across the African continent, the LEl is a\ngreat natural fit. It is a compelling, ready-to-go cross-border solution for entity identification that is\nopen, reliable and easily integrated into regulatory frameworks.”\nSecond Muguyo, Finance and Admin Manager at Copperwares, a Zimbabwean copper and silver\ngiftware manufactuer, participating in this initiative:\n“We face trade financing challenges not only because we are a small company, but because we are\nunknown from Zimbabwe. While we are not directly excluded from trade finance, we often receive\nunfavourable repayment terms which result in indirect exclusion. The LEI, as a globally recognized\nform of business ID, will give us greater credibility when we apply for finance, engage in international\ntrade and establish new supplier relationships for our manufacturing process.”\nViola Pamela Ndlovu, Head of Compliance, NMB Bank Limited:\n“In view of the emergence of a digital era and the rapid increase in demand for greater transparency\nby all organisations including regulators across the World, securing a LEl has become a powerful tool\nthat organisations can rely on in fulfilment of know your customer/business principles.”\nBarry Cooper, Technical Director, Cenfri:\n“The LEl is one of the few initiatives with real potential to meaningfully address the challenges of de-\nrisking in developing markets. The high costs of institutional due diligence and information\nasymmetries is a core element of the exclusion of small and medium enterprises, and even some\ncorporates, from regional and international markets. A robust global enterprise identity opens up an\nunder-represented large base of SMEs and women-owned businesses to trade across Africa as well as\nacross the global markets. Cenfri looks forward to the deepening of LEI usage across Africa and the\ninclusion of SME and women-owned enterprises in the global economy.”\nYann Desclercs, Managing Director, Cornerstone Advisory Plus:\n“The increasingly stringent customer due diligence requirements of the evolving international\nregulatory environment has, over the past years, contributed to an increase in SME trade finance\nrejections by banks. This is an important limitation to the growth potential and global outreach of\n\n3\n","contentLength":3162,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:31:47.695Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/2021-08-10-global-digital-business-identity-initiative-launches-to-boost-financial-inclusion-for-african-businesses_v.1.1-final.pdf","content":"I N (Eoh\n\n&y LE| .\nAfrican SMEs. The LEI can significantly contribute to reversing this trend by decreasing the cost of\ncompliance and reshaping international trade and growth for African SMEs.”\nSarah Weiss, Financial Sector Development Advisor, Deutsche Gesellschaft fiir Internationale\nZusammenarbeit (GlZ) GmbH, and Hugues Kamewe Tsafack, Financial Sector Advisor, Making\nFinance Work for Africa:\n“Having more African-based LEIl issuers would contribute to promoting the LEI concept and facilitate\nLEI applications for Africa-based entities. Forging strategic partnerships could also bolster awareness\nraising efforts among African Fls, real sector companies, national supervisory and regulatory\nauthorities about the LEI, its potential benefits and the application process. Finally, it is worthwhile to\nexplore the potential synergies between African initiatives that facilitate client due diligence and\npromote market transparency.” ©\nGLEIF welcomes dialogue with governments, NGOs, banks and other stakeholders interested in either\nexpanding the LEl initiative in Africa or in replicating the model in other developing economies. Please\nemail info@gleif.org for more information.\n\n- ENDS -\nFull resolution images and logos can be downloaded via this link\nhttps://www.gleif.org/en/newsroom/gleif-graphics-images\nContact\nLucy Bristow / James Kemp\nlucy.b@iseepr.co.uk / james.k@iseepr.co.uk\n+44 (0) 113 350 1922\nRelevant link\nhttps://www.gleif.org/en\nGlossary of terms\nLegal Entity Identifier (LEI)\nThe Legal Entity Identifier (LEl) is a 20-character, alpha-numeric code based on the ISO 17442\nstandard developed by the International Organization for Standardization (ISO). The LEI connects to\nkey reference information that enables clear and unique identification of legal entities participating\nin financial transactions. Each LEI contains information about an entity’s ownership structure,\nanswering the questions of 'who is who’ and ‘who owns whom'. It provides a universally recognized\nidentifier paired with essential entity data, rigorous verification processes and high data quality.\n6 Quoted from: Promoting the Legal Entity Identifier to foster transparency and trade in African markets\n4\n","contentLength":2202,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:31:47.695Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/2021-08-10-global-digital-business-identity-initiative-launches-to-boost-financial-inclusion-for-african-businesses_v.1.1-final.pdf","content":"3, Fl .\nAbout the Global Legal Entity Identifier Foundation (GLEIF)\nEstablished by the Financial Stability Board in June 2014, the Global Legal Entity Identifier\nFoundation (GLEIF) is a not-for-profit organization created to support the implementation and use of\nthe Legal Entity Identifier (LEI). GLEIF is headquartered in Basel, Switzerland.\nGLEIF services ensure the operational integrity of the Global LEI System. GLEIF also makes available\nthe technical infrastructure to provide, via an open data license, access to the full global LEI\nrepository free of charge to users. GLEIF is overseen by the LEI Regulatory Oversight Committee,\nwhich is made up of representatives of public authorities from across the globe. For more\ninformation, visit the GLEIF website at https://www.gleif.org/en.\nSource:\nGlobal Legal Entity Identifier Foundation, St. Alban-Vorstadt 5, 4052 Basel, Switzerland\nChairman of the Board: Steven Joachim, CEO: Stephan Wolf\nCommercial-Register-No.: CHE-200.595.965, VAT-No.: CHE-200.595.965MWST\nLEl: 506700GE1G29325QX363\nu m u @Blog @Newsletter\n\n5\n","contentLength":1073,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:31:47.695Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/2021-08-10-foerderung-finanzieller-inklusion-von-unternehmen-in-afrika-globale-initiative-zur-digitalen-identifizierung-von-unternehmen-gestartet_v.1.1-final.pdf","content":",,:\\ LEGAL\n9, LE| &.\n\nPressemitteilung\n\nFoérderung finanzieller Inklusion von Unternehmen in Afrika: Globale Initiative zur digitalen\n\nIdentifizierung von Unternehmen gestartet\n\nLSEG (London Stock Exchange Group), Simbabwes NMB Bank, GLEIF, Cenfri und Cornerstone\n\nAdvisory Plus erméglichen Zugang zu Handelsfinanzierungen und steigern wirtschaftliches Potenzial\nfiir kleine und mittelgrof8e Unternehmen auf dem afrikanischen Kontinent\n10. August 2021 — Basel — Ein internationales Leuchtturmprojekt ist heute ins Leben gerufen\nworden, mit dem die finanzielle Inklusion von kleinen und mittelgroRen Unternehmen (KMU)\ninsbesondere auf dem afrikanischen Kontinent geférdert werden soll. Die Pilotphase wurde mit\nUnterstiitzung der deutschen Bundesregierung iiber die Deutsche Gesellschaft flr Internationale\nZusammenarbeit (GIZ) GmbH finanziert.\nDie gemeinsame Initiative stattet KMUs auf dem gesamten afrikanischen Kontinent mit weltweit\nanerkannten digitalen Unternehmensidentitdten — den sogenannten Legal Entity Identifiers (LEls) —\naus. Die internationale Initiative wurde in Simbabwe gestartet, wo die NMB Bank Limited (die lokale\nKMU-Kunden mit LEIs ausstattet) ihren Hauptsitz hat. Diese |Initiative fiir digitale\nUnternehmensinitiativen kann auf andere Lander auf dem afrikanischen Kontinent ausgeweitet\nwerden. Der LEl ist mit einem internationalen digitalen Pass vergleichbar: Er enthélt relevante\nInformationen Uber ein Unternehmen, so dass Fragen zur ldentitdt und zu den Eigentums-\nverhaltnissen eindeutig beantwortet werden kénnen. Diese Daten lassen sich schnell und effizient von\njedem weltweit verifizieren. Durch die sofortige und automatisierte Identitatsiiberprifung wissen\nUnternehmen zweifelsfrei, mit wem sie Geschafte tatigen. Die Gberprifbaren Unternehmensdaten\nermoglichen mehr Transparenz am Kapitalmarkt und erhdhen das Vertrauen zwischen den\nMarktteilnehmern.\nMit der Bereitstellung von LEIs fir KMUs auf dem afrikanischen Kontinent soll die finanzielle Inklusion\nvon Unternehmen in der Region gestdrkt werden, indem sie transparente Handelsfinanzierung\nbeantragen und vertragliche, sichere Vereinbarungen mit Banken, Zahlungsnetzwerken und\nHandelspartnern eingehen kdnnen. Hierdurch soll ihnen ein besserer Zugang und mehr Teilhabe an\nden nationalen und internationalen Finanzmarkten ermdglicht werden. Letztlich verfolgt die Initiative\ndas Ziel, die KMU-Basis auf dem afrikanischen Kontinent zu starken und die fiir die wirtschaftliche\nEntwicklung dieser Region erforderlichen Investitionen und Kapitalfliisse zu erhéhen.\nAktuell leiden die heterogenen Volkswirtschaften in Afrika unter einer immensen Handels-\nfinanzierungsliicke, die sich derzeit auf schiatzungsweise mehr als 81 Mrd. USD bel3uft. ! Die geringe\nTransparenz bei Unternehmensidentitdten auf dem afrikanischen Kontinent und das ihnen gegeniber\nwahrgenommene Geschéftsrisiko sind eine groRe Herausforderung, sowohl fiir Banken, die ihre\nHandelsfinanzierungsportfolios auf dem Kontinent erweitern wollen, als auch fiir internationale\nGeschéftspartner, die sich in diesen unzureichend erschlossenen, aber aufstrebenden und\npotentiellen Markten beteiligen wollen.\nDurch die Zusammenarbeit mit Banken des afrikanischen Kontinents bei der Vergabe von LEls geht die\nInitiative diese Herausforderung an. Sie zielt auch darauf ab, den durch Regulierung verbundenen\nAufwand bei der Bekdmpfung von Geldwasche (AML)) und der Identitatstiberprifung von Kunden\n1 African Development Bank’s Report Trade Finance in Africa: Trends Over the Past Decade and Opportunities\nAhead\n1\n","contentLength":3558,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:32:04.519Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/2021-08-10-foerderung-finanzieller-inklusion-von-unternehmen-in-afrika-globale-initiative-zur-digitalen-identifizierung-von-unternehmen-gestartet_v.1.1-final.pdf","content":"m LEGAL\n9, LE| &.\n\n(KYC) zu reduzieren. Derzeit hélt dieser routinemaRige (oft auch manuelle) Aufwand die Banken haufig\ndavon ab, Kredite an neue KMUs zu vergeben. Dies liegt auch daran, dass es zeit- und kostenaufwendig\nist, die Identitaten der Unternehmen zu validieren und zu verifizieren. Im Zeitraum 2013 bis 2014\ngaben zwar weniger als ein Prozent der Banken auf dem afrikanischen Kontinent die Einhaltung von\nregulatorischen Vorschriften als Hauptgrund fiir die Ablehnung von Antrdgen auf\nHandelsfinanzierungen an. Zwischen 2015 und 2019 stieg die Zahl jedoch aufgrund der strengeren\nCompliance-Anforderungen auf ca. 16 Prozent.2\nDie Verwendung des LEls zur Identifizierung von Rechtstragern im grenziiberschreitenden Handel wird\nfur die Banken zudem sowohl die Kosten als auch den Arbeitsaufwand beim Datenabgleich erheblich\nverringern.\nWer ist beteiligt?\nDiese Initiative ist ein Zusammenschluss von:\n- der Global Legal Entity Identifier Foundation (GLEIF), einer gemeinnitzigen Organisation, die von den\nG20 und dem Financial Stability Board ins Leben gerufen wurde. Sie managt das globale Netzwerk von\nLEI-Vergabestellen und unterstitzt die Verfligbarkeit des Global LEI System.\n- der LSEG (London Stock Exchange Group), die die LEI-Vergabestelle bei dieser Initiative ist;\n- der NMB Bank Limited aus Simbabwe, die lokale KMU-Kunden mit LEls ausstattet;\n- dem Centre for Financial Regulation and Inclusion (Cenfri), einem unabhédngigen, gemeinniitzigen\nThink Tank, dessen Schwerpunkt auf der Entwicklung des Finanzsektors in Afrika liegt;\n- Cornerstone Advisory Plus, einer auf Beratungs- und Fortbildungsdienste im Finanzsektor\nspezialisierten Organisation.\nUmfang und Status\nUm Erkenntnisse Uber den Zugang und potenziellen Nutzen bei der Einfiihrung von LEls an den\nMarkten des afrikanischen Kontinents zu erhalten, fiihrte die Deutsche Gesellschaft fir Internationale\nZusammenarbeit (GIZ) GmbH zwischen April und Juni 2020 eine Umfrage durch. Die Ergebnisse\nzeigten, dass LEls flir Unternehmen jeglicher GréRe und Art in der Region attraktiv sind, und fiihrten\nschlieBlich zur Entwicklung dieser Initiative. ,Der LEI fungiert als verlasslicher ,Existenznachweis’ fr\nGeschiaftspartner entlang ihrer Wertschopfungskette. Somit unterstiitzt diese Kennung die\nUnternehmen bei der Aufnahme von Handelsaktivititen im grenziiberschreitenden Handel. In\nAnbetracht der globalen Beschaffenheit des LEIs besteht der grofte Vorteil wohl bei\ngrenzlberschreitenden Transaktionen. [..] Ein LElI kann den Zugang von Unternehmen zu\nFinanzdienstleistungen verbessern, indem er bisher (unzureichend) bedienten Kunden wie KMUs\nermoglicht, den Banken Informationen zu ihren Beteiligungsstrukturen und vertrauenswirdige\nAngaben zu ihrer Identitat zur Verfluigung zu stellen” 3, so das Fazit der Autoren.\nNMB Bank Limited als erste Validierungsstelle fiir die Vergabe von LEls auf dem afrikanischen\nKontinent\nGLEIF hat vor Kurzem die Rolle der Validierungsstelle fir Finanzinstitute im globalen LEI System\neingefiihrt. Das bedeutet, im bestehenden Onboarding-Prozesse kdnnen sie fir ihre Kunden die\n2 African Development Bank’s Report Trade Finance in Africa: Trends Over the Past Decade and Opportunities\nAhead\n3 Veroffentlicht, Wortlaut aus der Machbarkeitsstudie 2020\n\n2\n","contentLength":3266,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:32:04.519Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/2021-08-10-foerderung-finanzieller-inklusion-von-unternehmen-in-afrika-globale-initiative-zur-digitalen-identifizierung-von-unternehmen-gestartet_v.1.1-final.pdf","content":"m LEGAL\n\\ @’ LEl \\D[N.'_FII'IIER\n\njeweils individuelle, digitale Rechtstragerkennung erhalten. Die NMB Bank Limited in Simbabwe ist\ndas erste Finanzinstitut auf dem afrikanischen Kontinent, das als Validierungsstelle LEls fiir ihre\nKunden beziehen kann. Dies bietet eine Reihe von Vorteilen in Bezug auf Kosten, Effizienz und\nKundenerlebnis. Denn es vereinfacht den Vergabeprozess und die gewonnenen Ressourcen kdnnen\nin die Entwicklung weiterer Services und innovativer Dienstleistungen investiert werden.\nStimmen von den Projektpartnern:\nAlberta Abbey, LEI Analyst, Data & Analytics, LSEG:\n,LSEG hat sich dieser Initiative angeschlossen, um eine breitere Einfilhrung von LEls auf dem gesamten\nafrikanischen Kontinent zu erméglichen. Indem wir den Nutzen und die Vorteile von Legal Entity\nIdentifiers aufzeigen, wollen wir mit diesem Projekt mehr Unternehmen kontinental ermutigen, LEls\nzu erhalten. Wir haben das Projekt mit einem partnerschaftlichen Ansatz begonnen, den wir (iber die\nPilotphase hinaus fortsetzen wollen.”\nStephan Wolf, CEO, GLEIF:\n,Der LEl hat das Potenzial, einen transparenteren und effizienteren grenziiberschreitenden Austausch\nvon Giitern und Daten im Rahmen der panafrikanischen Freihandelszone zu ermoglichen. Dies ist ein\nerster Schritt hin zu einer starkeren finanziellen Teilhabe, indem Herausforderungen liberwunden\nwerden, die sich beim Zugang zu Handel auf dem afrikanischen Kontinent und zu internationalen\nMarkten ergeben. In Anbetracht des hohen Tempos bei der Digitalisierung und der regulatorischen\nEntwicklung auf dem afrikanischen Kontinent bietet sich der LEI als Uiberzeugende Losung fiir die\ndigitale Identifizierung von Unternehmen an. Denn er ist sofort einsatzbereit, grenziiberschreitend,\nauf offenen Standards basierend und zuverldssig. Er lasst sich zudem in die jeweiligen nationalen\ngesetzlichen Rahmenbedingungen integrieren.”\nSecond Muguyo, Leiter Finanzen und Verwaltung bei Copperwares, ein simbabwischer Produzent\nvon Geschenkartikeln aus Kupfer und Seide, der an dieser Initiative auf dem afrikanischen Kontinent\nteilnimmt:\n,Wir haben bei der Handelsfinanzierung Schwierigkeiten, und zwar nicht nur deshalb, weil wir ein\nkleines Unternehmen sind, sondern auch, weil uns auBerhalb von Simbabwe niemand kennt. Obwohl\nwir nicht direkt von Handelsfinanzierungen ausgeschlossen sind, werden uns haufig unattraktive und\nUberteuerte Kreditbedingungen angeboten, die letztlich einen indirekten Ausschluss bedeuten. Der\nLEI als weltweit anerkannte Form der Unternehmensidentifikation wird uns bei der Beantragung von\nKrediten, im internationalen Handel und im Aufbau neuer Lieferantenbeziehungen fiir unsere\nProduktion mehr Glaubwirdigkeit verleihen.”\nViola Pamela Ndlovu, Head of Compliance, NMB Bank Limited:\n,In Anbetracht des aufkommenden digitalen Zeitalters und des rapide zunehmenden Interesses an\nmehr Transparenz seitens aller Beteiligten, einschlieBlich der Aufsichtsbehdrden weltweit, ist ein LEI\nzu einem machtigen Instrument geworden, auf das sich Organisationen bei der Erfiillung der Know-\nYour-Customer/Geschaftsrichtlinien verlassen kénnen.”\nBarry Cooper, Technical Director, Cenfri:\n,Der LEl ist eine der wenigen Initiativen, die wirklich das Potenzial entfalten konnen, die\nHerausforderungen bei der Reduzierung der Risiken in den aufstrebenden Markten zu bewaltigen. Die\nhohen Kosten der institutionellen Due Diligence und Informationsasymmetrien spielen bei dem\n\n3\n","contentLength":3435,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:32:04.519Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/2021-08-10-foerderung-finanzieller-inklusion-von-unternehmen-in-afrika-globale-initiative-zur-digitalen-identifizierung-von-unternehmen-gestartet_v.1.1-final.pdf","content":"m LEGAL\n\\ @’ LEl ‘ \\D[NTII’IIER\nAusschluss kleiner und mittelgroBer Unternehmen und sogar einiger Konzernen von regionalen und\ninternationalen Markten eine groRRe Rolle. Eine robuste globale Unternehmensidentitat eréffnet indes\neiner bisher unterreprasentierten groflen Basis von KMUs und von Frauen gefiihrten Unternehmen\ndie Moglichkeit, sowohl auf dem gesamten afrikanischen Kontinent als auch auf den globalen Markten\nihre Geschéftsaktivitdten zu verfolgen. Cenfri freut sich auf eine sich weiter verbreitende LEI-Nutzung\nauf dem gesamten Kontinent und die damit einhergehende finanzielle Inklusion von KMUs und den\nvon Frauen gefiihrten Unternehmen in der Weltwirtschaft.”\nYann Desclercs, Managing Director, Cornerstone Advisory Plus:\n,Die immer strengeren Anforderungen an die Due Diligence von Kunden in einem sich laufend\nweiterentwickelnden internationalen regulatorischen Umfeld haben in den vergangenen Jahren dazu\ngefiihrt, dass immer mehr Handelsfinanzierungen fir KMUs durch Banken abgelehnt werden. Dies\nkommt einem wesentlichen Hemmnis fiir das Wachstumspotenzial und der globalen Reichweite von\nKMUs des afrikanischen Kontinents gleich. Der LEI kann einen betradchtlichen Beitrag leisten, um\ndiesen Trend umzukehren, indem er die Kosten fiir die Einhaltung von Vorschriften senkt und fiir den\ninternationalen Handel und das Wachstum von KMUs neue Rahmenbedingungen schafft.”\nSarah Weiss, Financial Sector Development Advisor, Deutsche Gesellschaft fiir Internationale\nZusammenarbeit (GIZ) GmbH, und Hugues Kamewe Tsafack, Financial Sector Advisor, Making\nFinance Work for Africa*:\n»Mehr LEI-Vergabestellen auf dem afrikanischen Kontinent wiirden die Beantragung von digitalen\nIdentitdten der in Afrika ansassigen Unternehmen erleichtern und das LEI-System voranbringen. Die\nBildung strategischer Partnerschaften konnte auch das Bewusstsein fiir digitale Unternehmens-\nidentitditen und die potenziellen Vorteile des LEI sowohl bei afrikanischen Finanzinstituten,\nUnternehmen der Realwirtschaft sowie nationalen Aufsichts- und Regulierungsbehérden starken.\nSchlieRlich lohnt es sich, mogliche Synergien zwischen Initiativen auf dem afrikanischen Kontinent zu\nerkunden, die die Sorgfaltspflicht gegenliber Kunden erleichtern und die Markttransparenz férdern.”\nGLEIF begrift den Dialog mit Regierungen, Nicht-Regierungsorganisationen, Banken und anderen\nStakeholdern, die daran interessiert sind, entweder die LEl-Initiative in Afrika auszuweiten oder das\nModell auf andere sich entwickelnden Volkswirtschaften auszuweiten. Bitte senden Sie eine E-Mail an\ninfo@gleif.org fiir weitere Informationen.\n- ENDE -\n\nBilder und Logos in voller Auflésung konnen liber diesen Link heruntergeladen werden\nhttps://www.gleif.org/en/newsroom/gleif-graphics-images\nKontakt\nInes Gensinger\nInes.Gensinger@gleif.org\nPhone: +49 69 907 4999-46\nRelevanter Link\nhttps://www.gleif.org/en\n4 Zitiert aus: Promoting the Legal Entity Identifier to foster transparency and trade in African markets\n\n4\n","contentLength":2986,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:32:04.519Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/2021-08-10-foerderung-finanzieller-inklusion-von-unternehmen-in-afrika-globale-initiative-zur-digitalen-identifizierung-von-unternehmen-gestartet_v.1.1-final.pdf","content":"m LEGAL\n9, LE| &.\n\nGlossar\nLegal Entity Identifier (LEI)\nDer Legal Entity Identifier (LEl) ist ein zwanzigstelliger, alphanumerischer Code, der auf dem von der\nInternationalen Organisation fiir Normung (ISO) entwickelten Standard ISO 17442 basiert. Der LEl ist\nmit wesentlichen Referenzdaten verbunden, die eine klare und eindeutige Identifikation der\nRechtstrager, die an Finanztransaktionen beteiligt sind, ermdglichen. Jeder LEIl enthalt Informationen\nUber die Eigentumsstruktur des Rechtstragers, um die Fragen ,Wer ist wer“ und ,Wer gehort wem®”\nzu beantworten. Er sorgt flir eine universell anerkannte Kennung zusammen mit grundlegenden\nRechtstragerdaten, griindlichen Uberpriifungsprozessen und einer hohen Datenqualitit.\nUber die Global Legal Entity Identifier Foundation (GLEIF)\nDie Global Legal Entity Identifier Foundation (GLEIF) wurde im Juni 2014 vom Financial Stability\nBoard gegriindet und ist eine gemeinniitzige Organisation, die zur Unterstiitzung der\nImplementierung und des Einsatzes der Legal Entity Identifier (LEI) geschaffen wurde. GLEIF hat\nseinen Hauptsitz in Basel in der Schweiz.\nDas Dienstleistungsangebot von GLEIF stellt die operative Integritat des Global LEI Systems sicher.\nGLEIF stellt auBerdem die technische Infrastruktur zur Verfligung, die Nutzern Uber eine offene\nDatenlizenz kostenlosen Zugriff auf die gesamten, weltweiten LEI-Daten bietet. GLEIF untersteht der\nAufsicht des LEI Regulatory Oversight Committee, das sich aus Behdrdenvertretern aus aller Welt\nzusammensetzt. Weitere Informationen sind der GLEIF-Website unter https://www.gleif.org/en zu\nentnehmen.\nQuelle:\nGlobal Legal Entity Identifier Foundation, St. Alban-Vorstadt 5, 4052 Basel, Schweiz\nVerwaltungsratsvorsitzender: Steven Joachim, CEO: Stephan Wolf\nHandelsregisternummer: CHE-200.595.965, MWST-Nr.: CHE-200.595.965MWST\nLEl: 506700GE1G29325QX363\nu m u @Blog @Newsletter\n\n5\n","contentLength":1885,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:32:04.519Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/2021-08-10-lancement-de-initiative-identite-numerique-mondiale-de-l-entreprise-en-soutien-a-l-inclusion-financiere-des-entreprises-africaines_v.1.1-final.pdf","content":"@ | El ‘ &,\ny ENER\n\nCommuniqué de presse\n\nLancement de l'initiative « Identité numérique mondiale de I'entreprise » en soutien a l'inclusion\n\nfinanciéere des entreprises africaines\nLSEG (London Stock Exchange Group), NMB Bank Limited (Zimbabwe), GLEIF, le Cenfri et\nCornerstone Advisory Plus ouvrent I'accées a la trade finance et renforcent le potentiel économique\ndes petites et moyennes entreprises (PME).\n10 Aodt 2021 - Bale — Aujoud’hui est lancé un projet international phare congu pour renforcer\nI'inclusion financiere des petites et moyennes entreprises (PME), notamment sur le continent africain.\nLe projet a été financé avec le soutien du gouvernement fédéral allemand, par le biais de la Deutsche\nGesellschaft fir Internationale Zusammenarbeit (GIZ) GmbH (agence de coopération internationale\nallemande pour le développement).\nCette initiative collaborative fournit aux PME réparties dans toute I'Afrique une identité d'entreprise\nreconnue dans le monde entier, sous la forme d'un identifiant d'entité juridique (LEl). L'initiative a été\nlancée au Zimbabwe avec la NMB Bank Limited, qui s'efforce d'équiper les PME locales de LEI. Le LEI\nfait office de carte d'identité professionnelle internationale. Il contient des informations de carte de\nvisite de qualité, ainsi que la structure de propriété de I'entité juridique concernée, que tout le monde\npeut vérifier rapidement et efficacement partout a travers le monde. Ainsi, les entreprises savent\nexactement avec qui elles traitent. Ces données d'entreprise vérifiables renforcent la transparence\nsur le marché et engendrent une plus grande confiance entre les différents intervenants.\nLa mise a disposition d'un LEI auprés des PME africaines vise a renforcer l'inclusion financiére dans la\nrégion, en permettant a ces entreprises de demander des crédits destinés a la trade finance et d'établir\ndes accords contractuels et reglementés avec des banques, des réseaux de paiement et des\npartenaires commerciaux, élargissant ainsi I'acces aux services financiers et assurant une plus grande\nparticipation aux marchés nationaux comme internationaux. A terme, I'initiative vise a renforcer les\nPME en Afrique et a augmenter les flux de capitaux entrants qui sont nécessaires au développement\néconomique du continent.\nAujourd'hui, les économies hétérogenes d'Afrique souffrent d'un grave déficit de trade finance, que\nI'on estime actuellement a plus de 81 milliards de dollars. Il existe trés peu d'informations de\nréférence qui soient transparentes sur les entreprises africaines, qui par ailleurs ont une réputation\nde partenaire commercial risqué. Cela est tres problématique, tant pour les banques cherchant a\nélargir leurs portefeuilles de trade finance sur le continent que pour les partenaires commerciaux\ninternationaux souhaitant s'engager dans ce secteur émergent pour l'instant sous-utilisé.\nEn travaillant avec les banques africaines afin qu'elles puissent émettre des LEI, l'initiative pourra non\nseulement résoudre ce probléme mais aussi fortement réduire la charge de mise en conformité\ndécoulant d'une réglementation tres stricte sur la lutte contre le blanchiment d'argent et la\nconnaissance du client. Aujourd'hui, cette charge empéche fréquemment les banques de préter aux\nPME africaines, en grande partie en raison de difficultés rencontrées dans la validation et la\nvérification de l'identité. Entre 2013 et 2014, moins de 1% des banques africaines citaient la\nconformité reglementaire comme raison principale les poussant a refuser des demandes de trade\n1 African Development Bank’s Report Trade Finance in Africa: Trends Over the Past Decade and Opportunities\nAhead\n1\n","contentLength":3647,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:32:21.654Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/2021-08-10-lancement-de-initiative-identite-numerique-mondiale-de-l-entreprise-en-soutien-a-l-inclusion-financiere-des-entreprises-africaines_v.1.1-final.pdf","content":"m CEGAL\n‘@' I_E | ENER\n\nfinance. Entre 2015 et 2019, en revanche, alors que les exigences liées a la conformité avaient été\nrenforcées, ce chiffre est passé a environ 16 %.2\nEn utilisant un LEl pour identifier les entités juridiques prenant part a des transactions\ntransfrontaliéres, les banques pourraient fortement réduire a la fois les co(ts et les efforts inhérents\na la vérification des données.\nQui participe?\nL'initiative LEI est un effort commun entre :\n- La Global Legal Entity Identifier Foundation (GLEIF), une organisation a but non lucratif fondée par le\nG20 et le Conseil de stabilité financiere qui gere le réseau mondial des organisations émettrices de LEI\net promeut la disponibilité du Global LEI System ;\n- LSEG (London Stock Exchange Group), I'organisation émettrice de LEI de I'initiative ;\n- La NMB Bank Limited, une banque du Zimbabwe fournissant un LEIl aux petites entreprises locales\nfaisant partie de sa clientele ;\n- Le Centre for Financial Regulation and Inclusion (Cenfri), un groupe de réflexion indépendant a but\nnon lucratif ceuvrant pour le développement du secteur financier en Afrique ;\n- Cornerstone Advisory Plus, une entreprise spécialisée dans le conseil et la formation dans le secteur\nfinancier.\nPortée de I'opportunité\nPour mieux comprendre l'accessibilité et les avantages potentiels de l'introduction du LEI sur les\nmarchés africains, la Deutsche Gesellschaft fir Internationale Zusammenarbeit (GIZ) GmbH a mené\nune enquéte entre avril et juin 20203 . Selon les résultats de cette enquéte, le LEI est intéressant pour\nles entreprises de la région, quelle que soit leur taille et leur nature, ce qui a justifié le développement\nde l'initiative. « Prouvant |'existence des partenaires commerciaux au sein de la chaine de valeur, le\nLEl peut aider les entreprises a s'engager dans des activités commerciales transfrontalieres. Compte\ntenu de la nature mondiale du LEIl, son plus gros avantage pourrait étre dans les transactions\ntransfrontaliéres. [...] Le LEI pourrait améliorer I'acces aux services financiers pour les entreprises, en\npermettant a des clients auparavant mal desservis ou non desservis, comme les PME, de faire\nconnaitre leur structure de propriété et leur identité aupres des banques, de fagon fiable »#, concluent\nles auteurs.\n2 African Development Bank’s Report Trade Finance in Africa: Trends Over the Past Decade and Opportunities\nAhead\n3 Deutsche Gesellschaft fiir Internationale Zusammenarbeit (GIZ) GmbH: More Transparency for Better\nBusiness — the Potential of Legal Entity Identifiers for African Economies 2020.\n4 Extrait tiré de la Deutsche Gesellschaft fiir Internationale Zusammenarbeit (GIZ) GmbH: More Transparency\nfor Better Business — the Potential of Legal Entity Identifiers for African Economies 2020.\n\n2\n","contentLength":2786,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:32:21.654Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/2021-08-10-lancement-de-initiative-identite-numerique-mondiale-de-l-entreprise-en-soutien-a-l-inclusion-financiere-des-entreprises-africaines_v.1.1-final.pdf","content":"m CEGAL\n‘@' I_E | ENER\n\nL'agent de validation : un nouveau modéle opérationnel pour I'émission de LEl / NMB Bank Limited :\nle premier agent de validation en Afrique\nCette initiative mondiale pour l'identité d'entreprise numérique a vu le jour grace a un nouveau\nmodele opérationnel d'émission de LEI pour les banques : I'agent de validation>. NMB Bank Limited\nest le premier agent de validation en Afrique.\nEn tirant parti de ses processus de connaissance du client, de lutte contre le blanchiment d'argent et\nd'autres processus reglementés de I'onboarding du client, NMB Bank peut désormais obtenir un LEI\npour ses clients lors de la vérification de leur identité, dans le cadre de I'onboarding initiale. Cela\npermet a la banque d'améliorer I'expérience client, de faciliter la transformation numérique et de\nréduire les colts de gestion du cycle de vie client, tout en ouvrant la voie au développement de\nnouveaux services fondés sur l'identité.\nDéclarations des parties prenantes\nAlberta Abbey, analyste LEI, Données et Analyse, LSEG :\n« LSEG s'associe a cette initiative afin de faciliter une plus grande adoption du LEIl en Afrique. En\ndémontrant les utilisations et avantages de l'identifiant d'entité juridique, nous voulons que ce projet\nencourage les entités de toute I'Afrique a obtenir un LEl. Nous avons démarré le projet dans une\noptique de partenariat et comptons le poursuivre au-dela de la phase pilote. »\nStephan Wolf, PDG de la GLEIF :\n« Le LEl est en mesure de créer des échanges de biens et de données plus transparents et plus efficaces\nau travers des frontieres, en vertu de la Zone de libre-échange continentale africaine. C'est une\npremiére étape vers une plus grande inclusion financiere et vers la résolution des difficultés inhérentes\nau trade finance en Afrique. Compte tenu du rythme rapide de la numérisation et de I'évolution de la\nréglementation sur I'ensemble du continent africain, le LEl est I'outil idéal. C'est une solution\ntransfrontaliére attrayante et préte a I'emploi en matiere d'identification. Elle est ouverte, fiable et\nfacile a intégrer dans les cadres reglementaires. »\nSecond Muguyo, Responsable du financement et de l'administration chez Copperwares, un\nfabricant d'articles de cadeaux a base de cuivre et d'argent implanté au Zimbabwe, qui participe a\nl'initiative :\n« Nous rencontrons des difficultés en matiére de financement des transactions, non seulement parce\ngue nous sommes une entreprise de petite taille mais aussi parce que nous sommes peu connus et\nvenons du Zimbabwe. On ne nous refuse pas directement de crédits, mais on nous propose souvent\ndes modalités de remboursement défavorables, de sorte que nous sommes indirectement exclus du\nfinancement des transactions. Le LEI, en tant qu'identifiant d'entreprise reconnu dans le monde,\nrenforce notre crédibilité lorsque nous voulons demander un crédit, faire des transactions\n5 Avec le statut d'Agent de validation, les institutions financiéres et les organisations qui effectuent des\nvérifications et des validations d'identités peuvent obtenir et administrer des LEI pour leurs clients en\ncollaboration avec les organisations émettrices de LEI agréées, en appliquant leurs procédures habituelles de\nconnaissance des clients (KYC), d’intégration des clients ou de mise a jour des relations clients.\n\n3\n","contentLength":3316,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:32:21.654Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/2021-08-10-lancement-de-initiative-identite-numerique-mondiale-de-l-entreprise-en-soutien-a-l-inclusion-financiere-des-entreprises-africaines_v.1.1-final.pdf","content":"l@ \\ I_El ‘ s\nENTITY\n\\ ’ \\D[N.'_FII'IIER\ninternationales ou établir des relations avec de nouveaux fournisseurs dans le cadre de nos processus\nde fabrication. »\nViola Pamela Ndlovu, Responsable de la conformité, NMB Bank Limited :\n« Nous sommes a I'ére numérique et toutes les organisations du monde, y compris les régulateurs,\ndemandent une plus grande transparence. Dans ce contexte, le LEl est devenu un outil puissant auquel\nles organisations peuvent se fier pour s'acquitter de leurs obligations de connaissance du client ou\nrespecter leurs principes commerciaux. »\nBarry Cooper, Directeur technique chez Cenffri :\n« Le LEI est I'une des rares initiatives pouvant réellement répondre aux enjeux de la réduction des\nrisques sur les marchés en développement. Les co(ts élevés de la due diligence institutionnelle, ainsi\nqgue l'asymétrie de l'information, sont I'une des principales raisons pour lesquelles les petites et\nmoyennes entreprises - et méme quelques grandes - sont exclues des marchés régionaux et\ninternationaux. Une identité d'entreprise mondiale robuste permettra a de trés nombreuses PME et\nentreprises détenues par des femmes, jusqu'ici sous-représentées, de faire des transactions dans\ntoute I'Afrique et sur les marchés internationaux. Cenfri se réjouit a I'idée de renforcer I'utilisation du\nLEI sur I'ensemble du continent africain, ainsi que d'inclure les PME et les entreprises détenues par\ndes femmes dans I'économie mondiale. »\nYann Desclercs, Directeur général chez Cornerstone Advisory Plus :\n« La reglementation internationale évolue et les exigences de due diligence a I'égard du client sont de\nplus en plus strictes, de sorte que, ces dernieres années, les banques ont été de plus en plus\nnombreuses a refuser les demandes de financement de transactions des PME. Cela limite fortement\nle potentiel de croissance et la portée mondiale des PME africaines. Le LEI peut véritablement aider a\nrenverser cette tendance, en réduisant le colt de mise en conformité et en remodelant le commerce\ninternational et la croissance pour les PME africaines. »\nSarah Weiss, Conseillere pour le développement du secteur financier, Deutsche Gesellschaft fiir\nInternationale Zusammenarbeit (GIZ) GmbH, et Hugues Kamewe Tsafack, Conseiller financier,\nInitiative « Making Finance Work for Africa » :\n« S'il y avait plus d'UOL implantées en Afrique, cela renforcerait le concept du LEI et faciliterait les\napplications du LEl pour les entités situées sur ce continent. L'établissement de partenariats\nstratégiques pourrait également renforcer les efforts de sensibilisation des institutions financiéres\nafricaines, des entreprises du secteur réel, des autorités nationales de surveillance et de\nréglementation au sujet du LEI, de ses avantages potentiels et du processus de demande. Pour finir, il\nserait judicieux d'explorer les potentielles synergies entre différentes initiatives africaines facilitant la\ndue diligence a I'égard du client et promouvant la transparence du marché. »®\nLa GLEIF est favorable au dialogue avec les gouvernements, les ONG, les banques et d'autres parties\nprenantes souhaitant élargir I'initiative LEI en Afrique ou reproduire le modele dans d'autres pays en\ndéveloppement. Veuillez écrire a I'adresse info@gleif.org pour obtenir de plus amples informations.\n-FIN -\n\n6 Citation tirée de: Promoting the Legal Entity Identifier to foster transparency and trade in African markets\n\n4\n","contentLength":3420,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:32:21.654Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/2021-08-10-lancement-de-initiative-identite-numerique-mondiale-de-l-entreprise-en-soutien-a-l-inclusion-financiere-des-entreprises-africaines_v.1.1-final.pdf","content":"m LEGAL\n\n\\ @’ LEl ‘ \\D[N._TII'IIER\nVous pouvez télécharger les images et les logos en haute résolution en suivant ce lien\nhttps://www.gleif.org/en/newsroom/gleif-graphics-images\nCoordonnées\nLucy Bristow / James Kemp\nlucy.b@iseepr.co.uk / james@iseepr.co.uk\n+44 (0) 113 350 1922\nLien pertinent\nhttps://www.gleif.org/en\nGlossaire de termes\nIdentifiant d’entité juridique (LEI)\nL'identifiant d'entité juridique (LEl) est un code alphanumérique de 20 caracteres reposant sur la\nnorme ISO 17442 de I'Organisation internationale de normalisation. Il est relié numériqguement a des\ninformations de référence clés qui permettent d’identifier de facon claire et unique les entités\njuridiques parties aux transactions financieres. Chaque LEI contient des informations sur la structure\nde propriété des entités répondant aux questions ‘qui est qui’ et ‘qui appartient a qui’. Il fournit un\nidentifiant reconnu partout dans le monde, associé a des données essentielles sur I'entité, des\nprocessus de vérification rigoureux et des données de grande qualité.\nAu sujet de la Global Legal Entity Identifier Foundation (GLEIF)\nEtablie en juin 2014 par le Conseil de stabilité financiére, la Global Legal Entity Identifier Foundation\n(GLEIF) est une organisation a but non lucratif créée pour soutenir la mise en ceuvre et |'utilisation\nde I'ldentifiant d'entité juridique (LEl). Le siege de la GLEIF est situé a Bale, en Suisse.\nLes services de la GLEIF garantissent I'intégrité opérationnelle du Global LEI System. La GLEIF met\négalement a disposition l'infrastructure technique pour fournir, via une licence ouverte de données,\nun acceés au répertoire mondial complet des LEI gratuit pour les utilisateurs. La GLEIF est supervisée\npar le Comité de surveillance réglementaire des LEI, composé de représentants des autorités\npubliques issus du monde entier. Pour plus d'informations, consultez le site web de la GLEIF a\nI'adresse https://www.gleif.org/fr/\nSource :\nGlobal Legal Entity Identifier Foundation, St. Alban-Vorstadt 5, 4052 Béle, Suisse\nPrésident du Conseil d'administration : Steven Joachim, PDG : Stephan Wolf\nNumeéro d'inscription au Registre du commerce : CHE-200.595.965, Numéro de TVA : CHE-\n200.595.965MWST\nLEl : 506700GE1G29325QX363\nu m u @Blog @Newsletter\n\n5\n","contentLength":2262,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:32:21.654Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/mckinsey-company-and-gleif-leis-and-client-lifecycle-management-in-banking-a-u-s-4-billion-beginning/2019-10-29_gleif-ebook-leis-and-client-lifecycle-management-in-banking-a-u.s-4-billion-v1.0-approved-public.pdf","content":"The power of LEls to transform\n\nclient lifecycle management in banking:\n\nA U.S.$4 billion beginning\nY \\ o\nBy LE| .\n","contentLength":115,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:32:50.455Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/mckinsey-company-and-gleif-leis-and-client-lifecycle-management-in-banking-a-u-s-4-billion-beginning/2019-10-29_gleif-ebook-leis-and-client-lifecycle-management-in-banking-a-u.s-4-billion-v1.0-approved-public.pdf","content":"e222e°° ®Zeee ssITsRIIANAR G,\no® o P E X X X s..‘\\“\\‘\\\\\\\\“\\\\\\\\\\\nLiss.e25. 22.%232222s, EETELTELRA N\n\"‘o\"':.oo.... ® eoee et slu\\NY\nl\":v’ :.0...... LA X X .‘l‘.“-“‘\\\\\\\n0?,0°2° 00°° 5 00000000 oocee ®o e it N\n2ferlel 00050080 g000000 ® ©° oo T N AN\nl’,”':\"\"\".o'........ ®ee ®eee Say \\\n’,,l’,’l\",-:,al:,.o':....ooo eeeoece S .\n° 700)0020022,000%0 S ge00000 ®eeecee\nIntroduction st tleesildeeecsssites saaetty RN\n0?0 :.0\"..00000....‘. ®®000ceoe CLIR LN\nJee ..00’......000000000. N O TR\n. .00’:.....0000000000.. eece SR\nN ::...ooo.oooooooooo.. ‘\\\\“\\\\\\\\\\‘S\\\\\\\\S\\i\\g\\\nN ‘\\‘ \\‘\\\\\\\\\\\\\\\\\\\\\\ \\\\‘ \\ :\\ S i\\t\\\\\nLY LTI\nLY TALIARN\n* . . . . . L XY AL TRAL TR\nResearch™ conducted by McKinsey on behalf of the Global Legal Entity Taking client lifecycle management (CLM) as one use case, LEls can .,““-\\.‘\\‘\\\\‘Q\\\\‘c\\\\\\\\i};\\\ne . . . . . . . . pe . . . LYTAIIA\nIdentifier Foundation (GLEIF) has concluded that broader adoption dramatically simplify entity identification across different lifecycle : ‘.'. ‘ . \\\\‘\\““g‘\\‘s;\\\\‘\n. e . . . . . [ XY (YT\nof Legal Entity Identifiers (LEIs) could save the global banking sector stages, such as onboarding, transacting, compliance reporting and :..“\"\\“ \\\\.x\\:\\‘\\\\‘f‘ik\\;\nT . . . . . . . . . .. (XY \\ LN\nU.S.$2-4 billion™ annually in client onboarding costs alone. This risk monitoring. This ebook explores conclusions from a joint o ..'.',',‘.:m'..,.\\‘\\\\\\‘,\\\\f;u\n. . . . ope “\" Wy,\nrepresents a saving of between 5 and 10 percent of the industry’s GLEIF and McKinsey study in the context of specific use cases and .::::::0tun:‘.‘.\"\"h‘n\\,'.\"\\\\;\\u\ns . . . . . . 1T} !\nU.S.540 billion annual overall spend on the practice. pain points experienced by banks when performing client 000 nn..:::::'.:'.'.\"\"-'m \\\n. P . e . .........\".\"\" Wy\n' o ' ' N identification and verification. 000000t N\nClient onboarding is just one banking business activity of many where e\n. . . . . . . . . . . 000000000000\nthe LEI has the potential to generate efficiencies. As such, that figure is It also provides a brief overview of other benefits banks can realize 00 sopern\n. . . . . . w00\njust the beginning. through expanded LEI usage, including reduced time-to-revenue, ::uum::\n. . . \"\nimproved customer retention and the delivery of a better, more '::::m:\"\n. .. . . . . \"\nIf banks around the world broaden their utilization of LEls beyond efficient customer experience. \"',',',','u;;,,”\n. . . . . . (L]\nregulatory reporting in capital markets to other banking business lines, 000000000000 o: ,:'.:'o;,‘,/ \"\n. . . . [ ] \"\nsuch as trade financing, corporate banking and payments, resulting eeooo : : : : : : : paps l\"\",':u’\n.. . S . . [ X X J o\nefficiencies would generate significant cost and time savings. eo0o0o000000° :,',’u\n[J o\neo0oo0000000 Iy\ne0o000000\nec0oo000000\neo0oo000000®\neo0oo0o000®\neo0o0o000®\no000 0®\no000 0\no000\nC N N J\n* Source: McKinsey Cost per Trade Survey, Thomson Reuters “KYC Compliance: The Rising Challenge for Financial Institutions” report, GLEIS 2.0 voice [ A A\nof customer and expert interviews. McKinsey conducted a voice of the customer exercise involving interviews of over 70 stakeholders, including market oo -\nparticipants across more than five sectors, current LEI registrants and users, Local Operating Units, regulators and potential Global LEI System partners. - : oo\n** Calculation: FTE productivity gain of (10% to 15% [~2-4 hours] of ~25 hours per onboarding case) multiplied by percentage of total onboarding costs attributable to FTEs (~57%) then multiplied by the estimated total\nindustry spend on client onboarding (540 billion per year). FTE productivity was based on “voice of customer” and expert interviews and includes both the estimated reduction and FTE hours per onboarding case. Percentage\nof total client onboarding costs attributable to FTEs based on the average cost of FTEs in the client onboarding function at 10 tier-1 banks (McKinsey Cost Per Trade Survey) divided by total client onboarding cost (European\nAssociation of Corporate Treasurers). Total industry client onboarding spend based on a Thomson Reuters report: KYC Compliance: The Rising Challenge for Financial Institutions.\n","contentLength":4143,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:32:50.455Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/mckinsey-company-and-gleif-leis-and-client-lifecycle-management-in-banking-a-u-s-4-billion-beginning/2019-10-29_gleif-ebook-leis-and-client-lifecycle-management-in-banking-a-u.s-4-billion-v1.0-approved-public.pdf","content":"LEls: Banking industry feedback\n(Y9\nHere are some of the Different IDs across our\ncomments received different systems and our\nfrom participants of data providers causes a\nignificant burden —\nthe study. >18N!\ny If | had a magic wand,\n| would make every entity\no0 have an LEI.\nFor funds that have 2l\nan LEl, onboarding\nis a breeze because\nwe know what KYC\ndocuments exist.\nL o0\n4 If everyone had an o6\n. . . LEI, it would be very |\nWith jche incredible easy to tie together We cons@er the LEI\nbase mfras_tructu_re external sources and as a key piece of o_ur\nof LEl, nothing exists internal systems. roadmap tf) rec!ucmg\nbetter (than the LEI) onboarding time.\nto track bad actors. 99\n®9\n)L\n11 >\n","contentLength":692,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:32:50.455Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/mckinsey-company-and-gleif-leis-and-client-lifecycle-management-in-banking-a-u-s-4-billion-beginning/2019-10-29_gleif-ebook-leis-and-client-lifecycle-management-in-banking-a-u.s-4-billion-v1.0-approved-public.pdf","content":"[ ] [ ]\nLEls: Banking industry feedback\no0\nQuick access to documentation\nis critical but today this comes\no0 from the sales desk and often\ncomes piecemeal.\nWe have an entire team of\nManual Ilnklng people primarily focused We should be able to onboard a\n. on supporting our sales fund in a day but it typically takes\nO_f entity data teams with entering data much Ionger due t\\:innco:'/rect\n_from disparate from disparate internal documentation.\nsystems, external data\nsources would be o0 providers and paper L)\na”eviated by S s documentation.\nID across external UL\nthe LEI: platforms that [...] the\nbank could use would\nbe very useful.\nL)L)\no0\nHaving a shared identifier with third-\nparty data providers would enable\no0 straight through processing solutions\nWithout a single primary o6 to improve operational efficiency\nkey, we have no ability to Exact name matches while significantly mitigating risk.\nlook at credit exposure are very rare between\nacross multiple parts of reglatory bodies, If everyone adopted and used\nthe bank for the same brokers, and third- LEIs in their SWIFT messages and\nclient and this is causing party [data] vendors. government authorities published\nSR EUE EETEETT e G LEls in suspicious entity list, clearing\nregulators. UL trades would be much easier.\n%9 9\n12 >\n","contentLength":1291,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:32:50.455Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/mckinsey-company-and-gleif-leis-and-client-lifecycle-management-in-banking-a-u-s-4-billion-beginning/2019-10-29_gleif-ebook-leis-and-client-lifecycle-management-in-banking-a-u.s-4-billion-v1.0-approved-public.pdf","content":"Please visit www.gleif.org\nFor financial institutions wishing to join the discussion:\nPlease visit GLEIF Globally Important Financial Institutions (GIFl) Relationship Group\nTo read the Financial Stability Board’s latest Thematic Review on Implementation of\nthe Legal Entity Identifier, please visit https://www.fsb.org/2019/05/thematic-re-\nview-on-implementation-of-the-legal-entity-identifier/\nTo read Swift Payments Market Practice Group’s paper on Adoption of LEl in Payment\nMessages, please visit https://www.swift.com/about-us/community/swift-adviso-\nry-groups/payments-market-practice-group/document-centre/document-centre < GLOBAL\nJ | LEGAL\n| '& L E | ENTITY\nu IDENTIFIER\nFOUNDATION\n","contentLength":690,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:32:50.455Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/mckinsey-company-and-gleif-leis-and-client-lifecycle-management-in-banking-a-u-s-4-billion-beginning/2019-10-29_gleif-ebook-leis-and-client-lifecycle-management-in-banking-a-u.s-4-billion-v1.0-approved-public.pdf","content":"A brief recap\nWhat is the LEI? History of the Global LEI System\nThe LEl is a 20-character, alpha- In 2011, the Group of Twenty In its latest Thematic Review on Implementation of the LEI\nnumeric code based on the I1SO (G20) called on the Financial (May 2019), the FSB commented:\n17442 standard developed by Stability Board (FSB) to provide “The regulatory uses of the LEI retrieval of granular data\nthe International Organization recommendations for a global are multiple and the benefits can on entities from multiple\nfor Standardization (1SO). The LEl and a supporting governance . .\nLE| ts to k P truct This led to th be substantial. The LEl standardises sources, as well as the\n. fconnt?c sfl:) tey rile renlce Z rucl ure. tls f th OGI el; | identification of legal entities at analysis of counterparty risks,\nn ormg on. a ?T‘a 'es clear evelopmen (.) € bloba the global level, to support the interconnectedness and complex\nand unique identification of legal LEI System which, through the . .\nit rticioating in fi ial . £ LEI id management and analysis of group structures. Many in the\nentities ,pa clpating In nar.1C|a |ssEJanc€-3 0 . .s, n'ow provides large datasets. Implementation financial industry are supportive\ntransactions. Each LEI contains unique identification of legal , .\\ .\ninf ti bout ity it rticinating in f ial of the LEI enhances regulators of the LEI, citing substantial\nintorma .on aboutan en ys: entities .pa cipating Ininancia surveillance by tracking market existing and potential benefits\nownership structure, answering transactions across the globe. abuse across institutions stemming from\nthe questions of ‘who is who’ and The FSB emphasized that global S . ”\n. i . ] . products and jurisdictions. its use.\nwho owns whom'. It provides a adoption of the LEI underpins The LEI can also assist requlators’\nuniversally recognized identifier multiple “financial stability and market participants’\npaired with essential entity data, objectives” and also offers aggregation and more flexible\nrigorous verification processes and “many benefits to the\nhigh data quality. private sector”. *\nservices ensure the operational integrity of the Globa ystem. also\nout GLEIF i h i i ity of the Global LEI' S GLEIF al\n' ' ' makes available the technical infrastructure to provide, via an open data license,\nEstablished _bV the ESB in June 2014, GLEIF is a access to the full global LE| repository free of charge to users. GLEIF is overseen by\nnot-for-profit D created to S gpen the LEI Regulatory Oversight Committee, which is made up of representatives of\nthe implementation and use of the LEI. GLEIF is public authorities from across the globe.\nheadquartered in Basel, Switzerland.\nFor more information, visit the GLEIF website at https://www.gleif.org/en.\n\\9\n","contentLength":2773,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:32:50.455Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/mckinsey-company-and-gleif-leis-and-client-lifecycle-management-in-banking-a-u-s-4-billion-beginning/2019-10-29_gleif-ebook-leis-and-client-lifecycle-management-in-banking-a-u.s-4-billion-v1.0-approved-public.pdf","content":"e e\nWhat value can LEIs bring to banking?\n[ ]\nThe U.S.54bn question....\nOf the many sectors that rely on Broadening LEI utilization: Figure 1, below, provides a non-\ncounterparty identification and Client lifecycle management exhaustive list of bank processes\nverification, GLEIF has identified The LEI and its associated entity related to CLM that could be positively\nbanking as a key global sector in reference data has the potential to make impacted by broader LEI adoption,\nwhich scaling adoption of the LEI banks’ counterparty identification and segmented by business activity.\ncould create substantial and verification more efficient and effective\nquantifiable value in the near at all stages of the CLM process.\nto mid-term.\nCsector—Jusecase L ousnes sty susecames L coterparyzgton\nBanking Client lifecycle Client onboarding Bank verifies legitamacy of client prior to onboarding\nmanagement KYC refresh Bank re-verifies legitamacy of client on an ongoing basis\nTransaction Issuing a letter of credit Bank verifies legitimacy of an entity and its trading partner\nZz:fifi;ia:;:;/AML Executing on corporate payment instructions Bank verifies legal entity included in payment instructions is legitimate\nMonitoring transactions for AML Bank filters entities for further AML review and performs enhanced\ndue diligence process on flagged entities\nfinancing as part of a lease agreement\nShipping leased assets Lessor (bank) verifies legitimacy of a leaser prior to good shipment\nprior to accepting a pledged A/R\nNotifying and confirming parties involved in factoring transaction Seller gives buyer and factor each other’s LEI\nProcessing payments made against pledged A/R Bank checks invoices against pledged A/R\nOriginating loan Bank verifies the legitimacy of an entity prior to loan origination\nRisk management Compiling client static reference data Bank reviews relevant business data such as account structure,\nreporting and address, key people etc\nanalytics Monitoring client activity for compliance or risk management Bank monitors entitly and parent entity activity\npurposes (e.g., client credit wortiness monitoring)\nFigure 1: Client lifecycle management use cases that could benefit from early stage LEI deployment. Source: McKinsey, 2019 \\)\n4\n","contentLength":2251,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:32:50.455Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/mckinsey-company-and-gleif-leis-and-client-lifecycle-management-in-banking-a-u-s-4-billion-beginning/2019-10-29_gleif-ebook-leis-and-client-lifecycle-management-in-banking-a-u.s-4-billion-v1.0-approved-public.pdf","content":"e\nUnlocking value:\n[ ]\n[ ] [ ] [ ] [ ]\nAn illustrative quantifiable use-case\nTo help quantify the global potential of * Three to seven fewer days to revenue. Total Impact from internal Impact from external data\nbroader LEI adoption in bank processes, . . onboarding time system connections source connections\n. . e Improved client retention.\nMcKinsey performed an analysis on the\nfirst of the sub-use cases noted in ¢ Delivery of a better customer\nFigure 1: client onboarding. experience. Banks make one fewer. Onboarding\nround trip to request and collect time impact 0 0 0\nToday, banks spend around U.S.540 documenrfcs duricrl\\ onboardin from LEI 100A’ 93 A’ SGA’\nbillion on client onboarding annually, & & -7% -7%\npresenting a clear opportunity for * Mitigated compliance and credit\nincreasing efficiency and reducing risks. Banks would have a more\ncosts. By widely adopting the LEI banks holistic view of clients across\ncould unlock an estimated U.5.$2-4 internal and external data sources. Impact driver * Reduce * Reduce manual\n. . . . duplicative data lookups\nbillion per annum by improving full time data entry « Enable straight\nemployee (FTE) pr‘OdUCthIty in client e Improve data through processing\nonboarding alone. access\nMcKinsey calculated that by using\nthe LEI to streamline processes for\nnnecting with h internal an -109 -\nconnecting with both internal and U.S.$40bn U.S.$54m 5-10% U.S.52-4bn\nexternal data sources, banks could I M P ACT in total banking estimated spend estimated total client per annum of total\nrealize an estimated 14% reduction industry annual per bank on total onboarding savings industry-wide\nin client onboarding times. Figure 2 spend on client client onboarding: driven by 7-15% potential savings,\nillustrates the maior itive im t onboarding U.5.$31m of which reduction in hours per with t?erlbanks\nustrates the major positive Impac is people cost onboarded customer, standing to save\npotential of this efficiency gain on if bank streamlines $2-5m each\nboth the global banking industry and processes using the LEI\nindividual banks.\nThe study also confirmed that broad\nusage of the LEI could generate the Figure 2: Estimated value to be unlocked in client onboarding. Source: McKinsey 2019\nfollowing topline benefits for banks: Source: McKinsey Cost per Trade Survey, Thomson Reuters “KYC Compliance: The Rising Challenge for Financial Institutions” report,\nGLEIS 2.0 voice of customer and expert interviews.\n","contentLength":2448,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:32:50.455Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/mckinsey-company-and-gleif-leis-and-client-lifecycle-management-in-banking-a-u-s-4-billion-beginning/2019-10-29_gleif-ebook-leis-and-client-lifecycle-management-in-banking-a-u.s-4-billion-v1.0-approved-public.pdf","content":"The broader picture: LEl usage before,\nduring and after client onboarding\nRegardless of banking sub-sector, the Post onboarding, it could also be used % N\nLEI could be used to improve the CLM for periodic KYC-refresh requirements, . o\nprocess. Currently, it is mainly used in transaction-level checks (e.g. verification\nthe initial onboarding phase to comply for specific payments) and ongoing :\nwith regulatory mandates. Yet in most monitoring of counterparties’ good :\ncases it is obtained at the end of the standing (e.g., negative news regarding .., . L.\nonboarding phase after most steps for a counterparty’s creditworthiness or the %, E K\nentity identification have already been legitimacy of a counterparty’s business % . c\ncompleted. activities). All of these processes would . . .\nbenefit from significant streamlining. .: S :.\nIf obtained and used at the beginning of \".. : ..\"\nthe onboarding process, the LEI could It is notable that these processes are %, . .\nexpedite counterparty identification applicable across a wide variety of ‘e .*\nand verification, including compliance banking business activities.\nwith Know Your Customer (KYC)\nrequirements.\no0\nFor funds that have\nan LEl, onboarding (44 A\nis a breeze because We consider the LEI ‘e,\nwe know what KYC as a key piece of our o\ndocuments exist. roadmap to reducing : %\nonboarding time. .\nLL) :\n®°\nO,\n","contentLength":1368,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:32:50.455Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/mckinsey-company-and-gleif-leis-and-client-lifecycle-management-in-banking-a-u-s-4-billion-beginning/2019-10-29_gleif-ebook-leis-and-client-lifecycle-management-in-banking-a-u.s-4-billion-v1.0-approved-public.pdf","content":"# o \\ L] [\nDéja vu: Using the LEI to address recurring\n[ ] [ ] [ ] [ ]\npain-points throughout the client lifecycle )\nDifficulty in assessing\nentities’ legal ownership structure.\n\nFrom the ovelr >0 interviews Banks are spending extensive time\ncorppletgd with banks of ) trying to understand an entity’s\nvarious 5|ze§ and geographic 1 structure for compliance and risk\nreach, banking regulaj(o.rs, checks in the assessment of overall\nand other sector participants Manual linking of entity data exposure to affiliated entities, quite\nand experts, four major pain from disparate internal and external sources. often only to discover afterm’/ards\npoints in client identification L ] hat a subsidiary is part of an\nand verification came to light: Th!s includes internal .bank systems as well as tha yisp\n\nthird-party data providers, regulators, and overall parent.\n\npublic registries. Today, banks expend extensive\n\nresources on manually matching data or double-\n\nchecking matches to ensure that deal terms,\n\nregulatory reporting and risk assessments 3\n\nconcerning a legal entity are based on correctly\n\nmatched data. One specific example concerned Limited transparency into\n\nentity names; an interviewee noted that “exact entities’ key officers,\n\nname matches are very rare [among] regulatory such as authorized\n\nbodies, brokers, and third-party vendors.” This signatories, for reasons\n\npain point recurs in nearly all stages of the client similar to the second\n\nlifecycle and banking participants in interviews pain point.\n\nexpressed significant excitement about the\n\nprospect of a solution to overcome this.\n\nPoor customer experience\ndue to having to make multiple\nround trips to gather client\ndata and documents\nrequired for onboarding,\na KYC refresh, reporting,\nor other verification\nprocesses.\n7 >\n","contentLength":1798,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:32:50.455Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/mckinsey-company-and-gleif-leis-and-client-lifecycle-management-in-banking-a-u-s-4-billion-beginning/2019-10-29_gleif-ebook-leis-and-client-lifecycle-management-in-banking-a-u.s-4-billion-v1.0-approved-public.pdf","content":". . Ongoing risk Transaction\nFigure 3, below, illustrates . ; .\nhow commonly these profile review } excecution c\npain-points recur\nthroughout the. cllgnt v Manual Iinkage of entity\nlifecycle, and highlights .\nhow valuable their data from disparate sources\nexpedition using the LEI (internal and external)\nwould be to banks. LEI\nissuance }\nA 4 KYC\nrefresh e\nDifficulty assessing entity\n.‘mfl 5\nA A A A A A Limited transparency into\nClient KYC/credit Legal Account Transaction request AML key officers (e.g. authorized\nrelationship due diligence documentation Opening receipt compliance review signatories)\nstarted\nFigure 3: Recurring pain-points in the client lifecycle, addressable by LE| utilization o\nPoor client experience due\nto multiple back-and-forth\ngathering data\nThe study found that many banks try to resolve these problems by implementing various technical\nsolutions, increasing headcount, or just accepting longer cycle times. Since none of these methods fully\nresolves any of these pain points, many banking interviewees responded enthusiastically to the idea of\nusing LEls to identify and verify counterparties.\n","contentLength":1125,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:32:50.455Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/mckinsey-company-and-gleif-leis-and-client-lifecycle-management-in-banking-a-u-s-4-billion-beginning/2019-10-29_gleif-ebook-leis-and-client-lifecycle-management-in-banking-a-u.s-4-billion-v1.0-approved-public.pdf","content":"[ ] [ ]\nLow barriers to broader adoption\nThere is more cause for optimism.\nBanks are already familiar with the\nLEI thanks to its extensive use in\ncapital markets. Here, banks have seen o\nfirsthand the value the LE| can create - N\nin counterparty identification. @ N\\\nGiven that the LEls initial use case\noriginated from regulatory requirements,\nits compliance-driven adoption has (o]\nalready laid the groundwork for\nbroader, voluntary adoption. The study\nhas revealed that even participants in\nbanking sub-sectors where the LEl is\nnot used today are highly receptive to\nvoluntarily expanding use of the LEI\ninto other banking business lines, such\nas transaction banking and commercial\nlending. ~~ -~\n~ I\nCERITE == .\n-~ ——— 11\noo [ == ooofpnl 3 Y\nI = oo0f vl ——]\n= 1 O ||{[|IE2I=|| © gooees\n= flflflfl E: Dflfl ||||||| 0)\n— — — — — goof\n2\n","contentLength":832,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:32:50.455Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/mckinsey-company-and-gleif-leis-and-client-lifecycle-management-in-banking-a-u-s-4-billion-beginning/2019-10-29_gleif-ebook-leis-and-client-lifecycle-management-in-banking-a-u.s-4-billion-v1.0-approved-public.pdf","content":"[ ] [ ] [ ] [ ]\n[ ]\nGLEIF: Working with the banking industry to\nege o 6 6\nfacilitate broader voluntary LElI adoption e\nThe significant potential savings for\nthe banking industry should compel\nthe sector to sit up and take notice\nGLEIF is evaluating the feasibility of To ensure that the future evolution of O;;:ser:je?r:;tnir::j(\\)/a:: T:Its c:]r;rie\nevolving the Global LEI System, to reduce the Global LEI System is fully informed T SXpagnsion of LEI\npoints of friction currently inhibiting by, and in line with, the banking sector’s usage into other business banking\nbroader LEI adoption. GLEIF will also requirements, GLEIF aims to conduct its lines is the new frontier in progressive\nassess actions it can take to encourage assessment with maximum engagement thinking and can only lead to a win-win\nbanks to voluntarily adopt LEls more from the global banking community. situation for both banks and\nbroadly, such as enhancing the value g slisis.\nproposition of the LEI by making it a L)\ndata connector which links to the most\ncommonly used data sources and b .\n) . y . . . y To support this objective, oo\nincluding a wider range of high priority . s\n. ) financial institutions are strongly . . .\nentity data points. . . We warmly welcome all interaction with\nencouraged to join the financial institutions on this topic and would\nGLEIF has already made progress urge those intereste.d in I?arning more to join\n. . the GLEIF GIFI Relationship Group for deeper\non this front: . . . o S\nto participate in the insight and to ensure their voice is heard as\nq q g we shape the future of the Global LEI System\n* In February 2018, GLEIF and SWIFT ensuing discussion on the together. We are excited that wider use of the\n. ) support needed for banks ) o ; : ) l’\\\nintroduced the first open source to intearate the LEl into CLM LEI brings such significant potential benefits e\nrelationship file that matches a Business g | | to the banking sector and our priority at this '1 [\nIdentifier Code (BIC) assigned to an rr::‘fssizfr:;\":fi:?fi:’; czg‘es stage is to support voluntary adoption of the )\norganization against its LEI. I [o]0] ¢ Yy (i g LEl in ba.nklng use cases beyonq regulatory\nwith banking associations, reporting so that these benefits can be >\nH fully realized.\n¢ In September 2018, the Association of Al sl broac.ier o J\n) . . stakeholders on this matter and ‘ (\nNational Numbering Agencies (ANNA) . . . ®9 R\n- will be pursuing collaboration\nand GLEIF announced the signing of a initiatives on a elobal scale\nnew global initiative to link International g :\nSecurities Identification Numbers (ISINs) Stephan Wolf, CEO, GLEIF.\nand LEls, to improve transparency\nof exposure by linking the issuer and\nissuance of securities.\n","contentLength":2729,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:32:50.456Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/mckinsey-company-and-gleif-leis-and-client-lifecycle-management-in-banking-a-u-s-4-billion-beginning/gleif-infographic-leis-transforming-banks-client-lifecycle-management/2019-10-29_gleif-infographic-leis-transforming-banks-client-lifecycle-management_v1.0-approved-public.pdf","content":"Wide adoption of the Legal Entity Identifier (LEI)\nby banks could unlock an estimated\nacross the global banking sector per annum.\nThe banking sector relies on counterparty identification and verification\nfor client lifecycle management among many use cases.\nBy scaling adoption of the LEI beyond regulatory requirements in capital markets\nto improve customer lifecycle management, the global banking industry could\ncreate substantial and quantifiable value in the near to mid-term.\nImproved productivity /\nonboarding efficiency gains:\nToday, the global banking\nsector spends around\no\n5-10%\non client onboarding annually. cost reduction\nThat's an estimated U.S.$54m per\nbank, U.S.$31m of which is ‘people’\ncost. Productivity improvements\ngained through LEI usage could\ngenerate cross-sector cost reductions\nof between 5-10% annually.\no o\n7% -1%\n- ont;?;recfing ont;?;;fing\n. . e N\nBy using LEIs to streamline . . Gains from reducing\n£ ti Gains from reducing | data look\npr'occ'asses or connecting duplicative data entries manual data lookups\nwith internal and external and improving data and enabiling straight\n: through processing\ndata sources, banks could access across internal across externdl\nrealize an estimated systems data sources\n14% reduction in client\nonboarding time.\nWide adoption of the LEI Q\nby the global banking sector\ncould unlock an estimated\nU.S.$2-Bm\nper annum across each\nthe sector in client\nonboarding\nefficiencies. per annum\n,I' \\\" 66 \\.1 66 ‘\\\\\\\n.’I e cersidar dhe For funds that hgve \\“\n/ LEIl as a key piece an LEIl, onboarding \\\n' of our roadmap is a breeze because .\n'.‘ to reducing we know what KYC A\n. onboarding time ClodulRls s /\n'Y 29\n. 0—(\nShorter time to revenue: 00000\n00000\n00000 @\n-_— [\n- N\nLElI usage could create | v,\nbetween 3 to 7 fewer \\ /\ndays to revenue thanks to ~ o —\nincreased transparency - —_—\ninto available entity — —\ndata, reducing Know Your fewer days\ncollection time.\n/ \\\n|\nBetter customer service @\ndelivery and improved retention: :\n- Streamlined document 0, @ : @\ncollation during onboarding. Ry :\nfor additional client information\nduring onboarding. |:| HH\n+ Improved system connectivity,\nreducing redundant and frustrating @\nclient requests for data or documents.\nImproved compliance\nand credit risk: e\nDifferent IDs across our\nR different systems and our\ndata providers causes\n+ More holistic view of client Slejaliitseluslelife s\nre-onboarding If | had a magic wand,\nP : | would make every\n- Ability to view client data entity have an LE|\nacross business lines and 29\ngeographies, enabling more\neffective risk evaluation and /\navoidance of fines.\n[ J [ ] [ ] [ ]\nMajor pain points in counterparty\n[ ] [ ] [ ] [ ] [ ]\nIdentification and verification\nThe top four pain point identified by banks, which recur repeatedly throughout the client lifecycle, are:\n() o o ()\n@ @ @ @\nManual linkage Difficulty Limited Poor customer\nof entry data assessing transparency into experience due to\nfrom disparate entities’ legal key officers, having to make multiple\nsources ownership such as authorized round trips to gather\nstructure signatories client data and\ndocuments\nIf an LEI was obtained at the start of onboarding, many of these challenges could be resolved,\nwith the net effect being expedited counterparty identification and verification processes.\nKnow Your Customer compliance may also be expedited.\nThe LEI supports business activities at all stages of the\nclient lifecycle management use case, including:\nQo oo s\no % n' 7 '\no = °\ng L@\\\nKnow Your Complian Risk\nOnboarding Customer Transacting :’e gr'tc;nce moni!csorin\nrefresh P g g\nBroader use of the LEI beyond regulatory reporting in capital\nmarkets could generate significantly higher cost and time savings, o6\nwhen utilized across other banking business lines, for example: Wider use of the LEI\nbrings significant potential\nbenefits to the banking sector.\nTo realize these gains, GLEIF\n— $ - — encourages banks to make LEls\n-— -— — foundational to customer\naud— — $ lifecycle management\nJ __\\ o — — — processes across all\nareas of business\nTrade Payments o0\nfinancing\n, [ [ [ [\nGLEIF’s priority is to support voluntary adoption\nof the LEI in banking use cases beyond regulatory\nreporting so that these benefits can be fully\nrealized. GLEIF welcomes engagement from\nfinancial institutions wishing to learn more...\nFor further information on LEls: GLEIF\n. . .\nPlease visit www.gleif.org\nEnabling global identity\nProtecting digital trust\nAbout the Global Legal Entity Identifier Foundation (GLEIF)\nEstablished by the Financial Stability Board in June 2014, the Global Legal Entity Identifier Foundation (GLEIF)\nis a not-for-profit organization created to support the implementation and use of the Legal Entity Identifier\n(LEI. GLEIF is headquartered in Basel, Switzerland.\nFind out more here: www.gleif.org\n*Calculation: FTE productivity gain of (10% to 15% [~2-4 hours] of ~25 hours per onboarding case) multiplied by percentage of total\nonboarding costs attributable to FTEs (~57%) then multiplied by the estimated total industry spend on client onboarding ($40 billion per\nyear). FTE productivity was based on “voice of customer” and expert interviews and includes both the estimated reduction and FTE hours\nper onboarding case. Percentage of total client onboarding costs attributable to FTEs based on the average cost of FTEs in the client\nonboarding function at 10 tier-1 banks (McKinsey Cost Per Trade Survey) divided by total client onboarding cost (European Association of\nCorporate Treasurers). Total industry client onboarding spend based on a Thomson Reuters report: KYC Compliance: The Rising Challenge\nfor Financial Institutions.\n**Source: McKinsey Cost per Trade Survey, Thomson Reuters \"KYC Compliance: The Rising Challenge for Financial Institutions\" report, GLEIS\n2.0 voice of customer and expert interviews. McKinsey conducted a voice of the customer exercise involving interviews of over 70 stake-\nholders, including market participants across more than five sectors, current LEI registrants and users, Local Operating Units, regulators\nand potential Global LEI System partners.\n","contentLength":6112,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:33:19.156Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-report_a-new-future-for-legal-entity-identification_final.pdf","content":"B ~—\n\\§‘\n- A New Future for Legal\nA Entity Identification\nFinancial services businesses are investing\nvaluable time and resource on client\nidenfifigafion){‘_gt@ardized approach\n- the way forward? | \\”fi‘/\\’\\\n<\\ VA\n\\\\ / \\\\\nO\\ A\n- / X\nD\n= 3\nw | [ (1=\n\\ \\ / NE\n< ] |\n\\ /\n/\n/\n- ,,//)g\\\n)| Fl .\n","contentLength":286,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:33:50.962Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-report_a-new-future-for-legal-entity-identification_final.pdf","content":"Contents\n\n© Executive Summary 3\n© Onboarding Inefficiencies 5\n© Identification Issues are Business Issues 8\n© Improving Identification 10\n© Better Knowledge, Better Business 12\n© Contact 13\n","contentLength":190,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:33:50.962Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-report_a-new-future-for-legal-entity-identification_final.pdf","content":"11| 13 A New Future for Legal Entity Identification\nWhat LEI means for identification\nIdentifying legal entities at a global level has long been a comple,\nmultifaceted undertaking, so could LEls be just the tonic?\nThe Global LEI Index is the only global online source that provides\nopen, standardized and high quality legal entity reference data. Each\nLEl contains information about an entity’s ownership structure and thus\nanswers the questions of ‘who is who’ and ‘who owns whom’ among\nmarket participants.\nLEl codes offer businesses a standardized, one-stop approach to\nidentifying legal entities, which has the potential to take the complexity\nout of business transactions. With LEls, key reference information is\nconnected by a 20-digit alphanumeric code, enabling quick, consistent,\naccurate identification of the legal entities taking part in financial\ntransactions, and making time-consuming, inconsistent identification\nprocesses a thing of the past. The problems associated with using\nmultiple identifiers, outlined earlier in this report, along with the concern\nthat introducing digital technologies won’t necessarily make life easier,\nare both taken care of.\nThe rollout of LEls could also increase the stability of international\nfinancial markets and support higher quality and accuracy of financial\ndata overall — but businesses could reap individual benefits too. Like\nslicker onboarding of new legal entities, reduced inconsistency and\nreduced risk of business-loss, as well as more efficient use of valuable\n(and often senior) resource. Like being able to make smarter, more\ninformed and reliable decisions about who to do business with, based on\nup-to-date, transparent and accurate data.\nIt's estimated that the use of LEls in capital markets could lead to a 3.5%\nreduction in the overall capital markets operations costs. For the global\ninvestment banking industry alone, this could result in over $150 million\nin annual savings'. But that’s just a fraction of the potential wider savings,\nbecause any process that requires identification or verification of legal\nentities has the chance of being made more efficient and reliable through\nthe use of LEls. Not least because access to the LEIl data pool is, and\nalways will be, free of charge for all.\n1 McKinsey & Company and GLEIF White Paper: The Legal Entity Identifier:\nThe Value of the Unique Counterparty ID.\n","contentLength":2384,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:33:50.962Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-report_a-new-future-for-legal-entity-identification_final.pdf","content":"12 | 13 A New Future for Legal Entity Identification\nBetter Knowledge,\nBetter Business\n. ________________________________________________________________________________________________________|]\nThe findings in this report speak volumes about the need for an\naccurate and transparent source for legal entity identification. Too many\nbusinesses, especially in the financial services industry, are losing vast\namounts of time and money each time they make a business transaction\nas a result of a range of inefficient processes — and it’s that inefficiency\nthat means they run the risk of losing the business anyway. Not to\nmention encountering compliance and security issues because of\npoor identification.\nAdoption of LEls promises to deliver real business capabilities, benefits\nand quantifiable value for those businesses that make the switch?\nNot only will it reduce operational friction, but it also makes information\nmore accessible and reliable. This opportunity to cut costs and get\nmore efficient and accurate in their operations, all whilst gaining deeper\ninsights into the global marketplace, should appeal to all businesses.\nBut then so should the fact that a global standard for legal entity\nidentification, with open access to transparent and high quality reference\ndata for all, would be a force for good in the financial industry as a whole.\nWant to learn\nmore about the\nLEI? Visit us online\nwww.gleif.org\n2 See also, for example: Basel Committee on Banking Supervision: Guidelines —\nSound Management of Risks Related to Money Laundering and Financing of Terrorism;\nthe Wolfsberg Group: Correspondent Banking Due Diligence Questionnaire.\n","contentLength":1653,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:33:50.962Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-report_a-new-future-for-legal-entity-identification_final.pdf","content":"Contact\nFor more information, please contact:\nL\nStephan Wolf =\nChief Executive Officer\nstephan.wolf@gleif.org . %\nMeral Ruesing 745\nHead of Communications ~\nmeral.ruesing@gleif.org -\nGlobal Legal Entity Identifier Foundation, St. Alban-Vorstadt 5, 4052 Basel, Switzerland\nwww.gleif.org\nD ® @\no\nR\n\\ / \\\nN\nA\n\\\n\\S\n. \\\na8 N\n[ ] \\\\\nN\\\n/ : //\n& 9 9 * \" \\ 1\ne ol A A\n‘ / | ¢ <\nB \\\\ \\ // .\n- 0 S NEK /=X\nQ3 GLOBAL\n‘ LE| e\nMay 2018 \\ ’ SR\nCopyright © Global Legal Entity Identifier Foundation (GLEIF)\n","contentLength":492,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:33:50.962Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-report_a-new-future-for-legal-entity-identification_final.pdf","content":"3|13 A New Future for Legal Entity Identification\nExecutive Summary\nIt was the financial crisis of 2008 that laid bare the need for a universal\nsystem of identifying legal entities, and despite the subsequent\ndevelopment of the global Legal Entity Identifier (LEI), the process\ncontinues to be notoriously complex for many businesses, especially in a\nglobal marketplace. To investigate this issue, and to reveal the extent of\nthat complexity, the Global Legal Entity Identifier Foundation (GLEIF) has\nworked with the London-based research agency Loudhouse to gather the\ndata contained in this report.\nKey findings include:\nm Businesses use an average of 4 identifiers\nm Onboarding takes an average of 6—7 weeks\nm 57% agree that reliability of reference data is a challenge\nm 55% agree that the resourcing of onboarding is a challenge\nm 55% agree lengthy processes mean risk of business loss\nm 61% agree that digital technology will further complicate\n\nthe process\n\nThe need for greater adoption of a publicly available, global directory\nof legal entities is clear. Financial services businesses are investing\nsignificant amounts of time, money and resource into the basic task of\nidentifying legal entities as they onboard new client organizations. It\nalso has to be kept in mind that entity verification processes do not stop\nwith the conclusion of the onboarding process. The client data must\nbe maintained up-to-date throughout the business relationship, which\nincludes regularly verifying business card information and changes to the\nownership structure.\nAnd as long as businesses are not using a standardized, widespread\napproach, it will continue to be a long and laborious process, liable to\ntaking experts away from servicing and sales, and demanding too much\nfocus on administration.\nAdoption of the LEI would deliver quantifiable value for these businesses.\nThe days of gathering information from multiple sources just to establish\nbasic entity and ownership data, that’s often hard to trace and link,\nwould be over. Transactional and operational friction would be reduced\nand important information would be more accessible and traceable.\nCollectively, that reduces time and improves reliability.\n","contentLength":2208,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:33:50.962Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-report_a-new-future-for-legal-entity-identification_final.pdf","content":"4|13 A-NewlFuture for iegal Entity-ldentification\nThe Global LEI Index is the only global online source that provides\nopen, standardized and high quality legal entity reference data. Each\nLEl contains information about an entity’s ownership structure and thus\nanswers the questions of ‘who is who’ and ‘who owns whom’ among\nmarket participants.\nIn the pages that follow, we detail the inefficiencies of today’s onboarding\nprocesses, looking at how they can be a drain on time and resource\nfor financial services businesses. We go on to explain how the issues\nsurrounding the inefficient identification of legal entities can have real\nbusiness consequences. Finally, our report explores the impact of rising\ndigital technologies and the potential capabilities and benefits afforded\nby adopting a standardized method for identifying legal entities.\nReplacing disjointed information with a globally accepted approach takes\nthe complexity out of business transactions and delivers real results. Time\nsavings, greater transparency and more streamlined working processes\nare all up for grabs for the businesses that introduce the use of LEls.\nThis report is a collaborative effort between GLEIF and the London-\nbased research agency Loudhouse. The research presented within it was\nconducted among 102 senior salespeople in the banking sector, with a\nregional split as follows: 35 US, 34 UK and 33 German businesses. The\norganizations surveyed ranged evenly from having under 50 employees to\nover 1,000 employees. The detailed results are available for download on\nthe GLEIF website.\n","contentLength":1577,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:33:50.962Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-report_a-new-future-for-legal-entity-identification_final.pdf","content":"5|13 A New Future for Legal Entity Identification\nOnboarding Inefficiencies\n. ________________________________________________________________________________________________________|]\nIt will come as little surprise to businesses in the financial services sector\nthat, in the majority of cases, the process used for the onboarding of\nnew legal entities is convoluted and inefficient. In this first section of our\nreport, our respondents — all senior salespeople in the banking sector —\nreveal the true extent of the issue as they uncover what’s really going on\neach time a new legal entity is onboarded for a business transaction.\nThe proliferation of identifiers\nPerhaps the key finding in our research, from which all other lines can be\ndrawn, is the simple fact that financial institutions are using an average\nof four identifiers to accurately identify and crosscheck new legal entities\nthroughout the client relationship. And approximately one-third of\nrespondents reveal that they’re actually using a combination of five or\nmore identifiers. As Fig. 1 makes abundantly clear, there’s to date no\nstandard identifier for the industry — no single identifier that has gained\nglobal acceptance, as a substantial proportion of organizations continue\nto use a wide range of different identifiers.\nFig. 1 ISO BIC — International Organization for _ 45%\no Standardization Business Identifier Code 0\nIdentifiers\nInsurance Corporation\nGlobal LEI System — Legal Entity Identifier _\nRSSD ID — Replication Server System Database _ 35%\n(assigned by the Federal Reserve Bank) 0\nCUSIP — Committee on Uniform Security\nIdentification Procedures _\nSEC CIK — Securities and Exchange\nCommission, Central Index Key _\nOther vendor IDs -\n|\n","contentLength":1721,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:33:50.962Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-report_a-new-future-for-legal-entity-identification_final.pdf","content":"613 A New Future for Legal Entity Identification\nWith such a multitude in use, it’s little wonder that over half (54%) of\nrespondents agree that the use of different identifiers for the same\nlegal entity leads to inconsistency of information. But that’s not the only\nproblem with the proliferation of identifiers. There’s also the logistical\nfact that it makes onboarding a hugely burdensome, time-consuming\nprocess for sales teams.\nAs we see in Fig. 2, it takes an average of six to seven weeks to onboard\na new legal entity, with six in ten senior salespeople spending more than\n1.5 days per week on tasks related to onboarding. It’s worth noting, too,\nthat an average of 25% of the onboarding process involves manual tasks,\noften being undertaken by senior members of the team.\nThe use of multiple identifiers in new business onboarding and\nmaintaining the accuracy of the data later on is undoubtedly a time-\nconsuming burden. Moreover, there seems to be a lack of resounding\nconsensus among surveyed businesses over what it is that’s taking up\nthe most time — 18% say it's compliance with Know Your Customer\n(KYC) regulations; 16% say it’s documentation management; 15% say it's\nidentification of the legal entity; and so the list goes on, doing little to\ndeny the inconsistent nature of the process as it is today.\nAlmost half (49%) agree Fig. 2 o\nmiddle- and back-office activities\nrelated to onboarding are a\nmajor burden. A similar number\n(48%) agree the exact cost of _\nonboarding is extremely difficult I;ir::ttgr;;:i(z):;i: ?Vszveks) 6 6 7\nto quantify.\n= - - -\ndays a week doing\nonboarding-related activities\n","contentLength":1621,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:33:50.962Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-report_a-new-future-for-legal-entity-identification_final.pdf","content":"7|13 A New Future for Legal Entity Identification\nThe pitfalls of onboarding\nThere is greater consensus, on the other hand, around the kind of\nchallenges businesses are facing when it comes to the quality of the\nidentifiers they're using. We see in Fig. 3 that the same themes crop up\nagain and again. Mainly concerning the reliability and accuracy of the\ninformation being gleaned from the diverse range of identifiers used\neach time, as detailed earlier in Fig. 1, along with an array of logistical\nchallenges relating to the drain of onboarding on time and resource.\nTop 5\n\nResources needed\n\ndifferent sources 0\n\nTime needed to complete onboarding _\n\nprocess for client organizations\n\nDifficulties reconciling client information\n\nfrom multiple internal and external sources _\n\nAccurate identification of legal entities _\n\nLack of process automation _\n\nFalse positives with Anti Money\nThe need for transparency\nLegal entity identification is complex indeed — but multiple identifiers and\nhighly convoluted processes don’t just mean inconsistent information and\na drain on resource. They also mean a distinct lack of transparency, which\ndoesn’t bode well when it comes to meeting compliance regulations\nin financial transactions. This has a knock-on effect for both individual\nbusinesses and the financial services industry.\n","contentLength":1326,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:33:50.962Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-report_a-new-future-for-legal-entity-identification_final.pdf","content":"8|13 A New Future for Legal Entity Identification\nFor businesses, muddied waters make it difficult to evaluate risks\nproperly. Onboarding and transacting decisions can’t be made with\nconfidence, visibility or control. Most financial businesses turn to KYC\nproviders to aid the onboarding process, but even then, transparency\nremains an issue. As many as 46% of respondents acknowledge that it’s\na non-transparent way of identifying and reporting corporate structure\n— along with the 47% who say the information is usually out-of-date (or\n59% for those using 4+ identifiers) and the 46% who admit the service\nitself is expensive.\nIn finance, a lack of transparency means being more prone to fraud and\nmarket abuse. Suffice to say, transparency is better for everyone.\nIdentification Issues are\nBusiness Issues\n. __________________________________________________________________________________________________________________________|\nUsing multiple identifiers eats up time and hinders transparency — that\nmuch is clear. But there’s an even bigger business issue at stake when it\ncomes to onboarding new legal entities. Because the reality is that client\norganizations aren’t always sympathetic to the demands placed on finan-\ncial services businesses by compliance regulations. With exactly half of\nour respondents agreeing that it's becoming more and more difficult to\ncomply with KYC regulations, Fig. 4 details exactly why:\nTop 3 complexity of the onboarding process\nClient concerns about security around o\nchallenges\n\nLack of client understanding o\n\nKYC regulatory requirements\n\nLack of regulatory understanding _\n\nTime needed to update.cllent organizations _\n\non new regulatory requirements\n\nNeed to pass regulatory requests o\n\non to client organizations _\n\nLack of resource _\n","contentLength":1784,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:33:50.962Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-report_a-new-future-for-legal-entity-identification_final.pdf","content":"9|13 A New Future for Legal Entity Identification\nThe risk of business loss is real\n55% agree that prospects might turn to competitors if\ntheir onboarding process takes too long —and they’re\nright to be concerned.\nAs we see from the estimations in Fig. 5, lost business is thought to be\na very real consequence of the current identification process, either\nthrough inability to glean adequate information or simply lack of patience\non the part of the new legal entity. The irony being, of course, that the\nlegal entity might not find the process to be any quicker if and when they\ndo take their business elsewhere — after all, our research shows that the\nmajority of financial institutions are all using 4+ identifiers to onboard\nnew entities, and are therefore liable to the same inefficiencies.\nFig. 5\ns Proportion of business estimated\nto be lost\nTransaction is rejected because not enough\n14% information is known about the legal identity\nof the counterpart\n15(y Legal entity leaves because onboarding\no process is too difficult/takes too long\n","contentLength":1048,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:33:50.962Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-report_a-new-future-for-legal-entity-identification_final.pdf","content":"10 | 13 A New Future for Legal Entity Identification\nImproving Identification\n. ________________________________________________________________________________________________________|]\nOne thing’s for sure: a robust, simplified, improved identification\nprocess is long overdue, particularly as 52% of our respondents think\nthat onboarding time is only going to rise thanks to a combination\nof increased fraud, tighter regulations and growth in today’s\nbusiness landscape.\nThe rise of digital technology\nBusinesses need a system that keeps them on the right side of both\nregulators and clients, while making them more efficient overall. And\nthey’re aware that new technologies are increasingly likely to play a part\nin that. Fig. 6 highlights the predicted rise of technologies, but there’s a\ncaveat to go along with that: 61% of our respondents believe that the\ngrowth of digital solutions will actually make identity verification more\ndifficult, simply because it’ll mean a rise in the number of legal entities\ntransacted with.\nFig. 6\nDigital\nSignatures\n51%\nGoing forward,\nlegal entity\nonboarding will\nincorporate KYC Utilities\nDigital Based on\nCertificates Blockchain\n46% Technology\n50%\n","contentLength":1191,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:33:50.962Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-findings_challenges-onboarding-client-organizations-in-banking-sector_v1.0-final.pdf","content":"m Lo\n\nOy LE| .\n.\nKnow Your Customer (KYC):\nThe Challenges Faced by the\nBanking Sector When Onboarding\nNew Client Organizations\nResearch Findings\nAuthor: GLEIF\nMay 2018\n","contentLength":168,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:34:58.186Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-findings_challenges-onboarding-client-organizations-in-banking-sector_v1.0-final.pdf","content":"]\nContent S, El\n1. Research background 3\n\n2. Key takeaways 7\n\n3. Entity Identifiers 9\n\n4. Onboarding issues 13\n\n5. Assessing the business impact 18\n\n6. So, will things get better 21\n\n/. Summary 28\n\n8. Appendix 30\n\n9. Better Knowledge, Better Business 44\n","contentLength":254,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:34:58.186Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-findings_challenges-onboarding-client-organizations-in-banking-sector_v1.0-final.pdf","content":"No single identifier has gained ‘@,\\ LE|\nglobal acceptance\nThere is no single identifier which acts as a standard for the industry.\nHowever several are used by a substantial proportion of organisations.\nIdentifiers used\nISO BIC — International Organization for Standardization Business e 45%\nIdentifier Code\nFDIC Certificate ID — Federal Deposit Insurance Corporation I 44%\nGlobal LEI System — Legal Entity Identifier INEEEG——— 43%\nRSSD ID — Replication Server System Database (assigned by the o\n|\nAverage of Federal Reserve Bank) 35%\n4 CUSIP — Committee on Uniform Security Identification o\n! o I 34%\nidentifiers Procedures\nused Internal IDs NG 33%\nThomson Reuters—Perm ID NI 31%\nSEC CIK — Securities and Exchange Commission, Central Index Key IS 31%\nOther vendor IDs NN 15%\nDUNSID I 12%\nother 1 1%\nBase: Total (102) Q3 On average, how many different identifiers does your organization use to identify each client organization\nyou do business with? Q2 Which of the following identifiers does your organization use to identify clients\n(i.e. legal entities) you do business with? Please select all that apply\n\n© 2018 GLEIF and/or its affiliates. All rights reserved. | Author: GLEIF | Know-Your-Customer | GLEIF restricted 2018-05-09 11| 48\n","contentLength":1240,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:34:58.186Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-findings_challenges-onboarding-client-organizations-in-banking-sector_v1.0-final.pdf","content":"- 0000000000000000]\nThe proliferation of identifiers often ‘3, F|\nthrows up inconsistencies\nFinancial institutions use multiple identifiers for cross-checking. But this creates\nconfusion because the same ID may be associated with multiple entities (49%),\nand different IDs can relate to the same entity (47%).\nAssociated reference data is not up to\ndate (e.g. name, address, corporate 58% Issues\nstructure) With\nreference\nReference data from different sources is o data\ninconsistent 46%\nThe same ID is used for different legal o\nentities 49%\nMultiple\nidentifiers\nMore than one identifier of the same 47%\ntype refers to the same legal entity\nAccess to the reference data associated\nwith the identifier is expensive 42%\nBase: Total (102) Q4 Which, if any, of the following issues does your organization face with the identifiers currently used? Please\nselect all that apply. Q20 To what extent do you agree or disagree with each of the following statements?\n© 2018 GLEIF and/or its affiliates. All rights reserved. | Author: GLEIF | Know-Your-Customer | GLEIF restricted 2018-05-09 12 | 48\n","contentLength":1088,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:34:58.186Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-findings_challenges-onboarding-client-organizations-in-banking-sector_v1.0-final.pdf","content":"3, El\ne\nOnboarding Issues\n© 2018 GLEIF and/or its affiliates. All rights reserved. | Author: GLEIF | Know-Your-Customer | GLEIF restricted 2018-05-09 13 | 48\n","contentLength":158,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:34:58.186Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-findings_challenges-onboarding-client-organizations-in-banking-sector_v1.0-final.pdf","content":"- 0000000000000000]\nOnboarding is a burdensome and ‘3, F|\ntime-consuming process\nNew clients typically take 6 weeks to onboard — more if 4+ identifiers are used.\nA guarter of the process involves manual tasks and 6 in 10 senior salespeople\nspend more than 1.5 days of their week onboarding.\nNumber of\nidentifiers used\nTime to onboard a new -\nclient organization (weeks)\nSpend more than 1.5\ndays a week doing 57% 53% 61%\nonboarding-related activities\nBase: Total (102) Q5 In a typical week, what proportion of your time is spent doing activities related to the onboarding of new\nclient organizations?; Q6 On average, how long does it take for your organization to onboard a new client\norganization?; Q9 What proportion of your company’s process for the onboarding of new client organizations\ninvolves manual tasks?; Q20 To what extent do you agree or disagree with each of the following statements?\n© 2018 GLEIF and/or its affiliates. All rights reserved. | Author: GLEIF | Know-Your-Customer | GLEIF restricted 2018-05-09 14 | 48\n","contentLength":1030,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:34:58.186Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-findings_challenges-onboarding-client-organizations-in-banking-sector_v1.0-final.pdf","content":"There is little consensus as to what is taking the most ‘@,\\ LE|\ntime, pointing to a lack of consistency in process\nod Qg\ns ot\ng0 [\n\"EE gu EEEE EEEE\n820 ooy o\ni (1111 T\n0-250 250+\nemployees employees\nStage of onboarding that takes the longest\nGOl e Wt K oW YU O e (Y e — 187 #1 #2\nregulation\nDocumentation management NG 6% #1\nIdentification of legal entity [INIIIIIENEGEGEGNGEGNENNNNEEE 15%\nValidation of customer information [INIIIIIEINEENEGNGGNGNGNNNNNNNNEEE 14%\nCollection of customer information NN 13% #2\nValidation of customer relationship to legal entity NI 1%\nRisk rating NG 7%\nAnti Money Laundering checks [ 3% Single answer only permitted.\nBase: Total (102) Q10 Which stage / aspect of the onboarding process for new client organizations takes the longest?\nPlease select one.\n© 2018 GLEIF and/or its affiliates. All rights reserved. | Author: GLEIF | Know-Your-Customer | GLEIF restricted 2018-05-09 15 | 48\n","contentLength":918,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:34:58.186Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-findings_challenges-onboarding-client-organizations-in-banking-sector_v1.0-final.pdf","content":"But in general, reliability of information and lack ‘3, F|\nof resources are a significant challenge for many\nSmaller businesses struggle in particular to reconcile data from multiple\nsources (55%).\nTop 5 challenges of onboarding\nReliability of information NG 57% Company size\nResources needed (e.g. time, people, I 550 m\nmoney) 55%\nContradictory information from different I 52%\nTime needed to complete onboarding I 50%\nprocess for client organisations\nDifficulti«_es re_conciling client information I 48%\nfrom multiple internal and external sources\n0, 0,\nLack of process automation [N 39%\nFalse positives with Anti Money Laundering I 36%\nBase: Total (102) Q1 Thinking about onboarding new client organizations, what would you say are the top challenges your\norganization faces? Please select up to 5.\n© 2018 GLEIF and/or its affiliates. All rights reserved. | Author: GLEIF | Know-Your-Customer | GLEIF restricted 2018-05-09 16 | 48\n","contentLength":934,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:34:58.186Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-findings_challenges-onboarding-client-organizations-in-banking-sector_v1.0-final.pdf","content":"- _____00000_000000___]\nKYC providers have not yet shown their ‘3, F|\nvalue in the marketplace\nMost use KYC providers, however many complain about out-of-date reference\ndata (47%) and the cost of these solutions (46%).\nAverage number of Reference data is not always il ey e\n- » 479 » h ing 4+\nKYC providers used 3 up to date % t ;S:nl:ffir;grs\nNon-transparent means of identifying 46%\nand reporting corporate structure >\nLimited Coverage\nBase: Total (102) Q14 How many KYC service providers does your organization use to aid KYC processes?\nQ15 What would you say are the main drawbacks of using KYC service providers? Please select\nall that apply.\n© 2018 GLEIF and/or its affiliates. All rights reserved. | Author: GLEIF | Know-Your-Customer | GLEIF restricted 2018-05-09 17 | 48\n","contentLength":780,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:34:58.186Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-findings_challenges-onboarding-client-organizations-in-banking-sector_v1.0-final.pdf","content":"3, El\ne e\nAssessing the Business Impact\n© 2018 GLEIF and/or its affiliates. All rights reserved. | Author: GLEIF | Know-Your-Customer | GLEIF restricted 2018-05-09 18 | 48\n","contentLength":172,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:34:58.186Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-findings_challenges-onboarding-client-organizations-in-banking-sector_v1.0-final.pdf","content":"Clients are not always sympathetic to the ‘3, F|\n\ndemands compliance places on institutions\n\n2 in 5 senior salespeople say that the risk of losing business due to the length\n\nand complexity of the onboarding process is a top challenge. Clients are\n\nparticularly concerned about the amount of information they need to share with\nthird-parties.\nRisk of losing business due to length/complexity\ni I 39%\nof the onboarding process\nClient concerns about security around who is\n- ) I 38%\nviewing their documents\nContinuous changes in KYC regulation NN 37%\nLack of client understanding of regulatory I 36% 50%\nrequirements ° agree\nTime needed to comply with KYC regulatory I 8% ’ _\nrequirements ° It's becoming more and\n) more difficult to comply\nLack of regulatory understanding [N 27% with KYC regulation\nTime needed to update client organizations on\n) I 26%\nnew regulatory requirements\nNeed to pass regulatory requests on to client I 04\norganizations °\nLack of resource NI 14%\n\nBase: Total (102) Q13 Still thinking about compliance with Know Your Customer (KYC) regulation, what are the top\nchallenges for your organization? Please select up to 3.; Q20 To what extent do you agree or disagree with\neach of the following statements?\n\n© 2018 GLEIF and/or its affiliates. All rights reserved. | Author: GLEIF | Know-Your-Customer | GLEIF restricted 2018-05-09 19 | 48\n","contentLength":1360,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:34:58.186Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-findings_challenges-onboarding-client-organizations-in-banking-sector_v1.0-final.pdf","content":"- _____00000_000000___]\nLong onboarding processes can lead ‘3, F|\nto loss of business\nAround 15% of business is at risk as a result of the client losing patience with\nthe process.\nAnd 14% of business is lost because the client identity cannot be verified.\nProportion of business estimated to be lost:\nTransaction is rejected because not\n14% enough information is known about\nthe legal identity of the counterpart\no Legal entity leaves because\nfi 15% onboarding process is too\n? difficult / takes too long\nBase: Total (102) Q16 What proportion of your organization’s business doesn’t go ahead due to each of the following\nreasons? Q20 To what extent do you agree or disagree with each of the following statements?\n© 2018 GLEIF and/or its affiliates. All rights reserved. | Author: GLEIF | Know-Your-Customer | GLEIF restricted 2018-05-09 20 | 48\n","contentLength":844,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:34:58.186Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-findings_challenges-onboarding-client-organizations-in-banking-sector_v1.0-final.pdf","content":"3, El\nResearch Background\n© 2018 GLEIF and/or its affiliates. All rights reserved. | Author: GLEIF | Know-Your-Customer | GLEIF restricted 2018-05-09 3|48\n","contentLength":155,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:34:58.186Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-findings_challenges-onboarding-client-organizations-in-banking-sector_v1.0-final.pdf","content":"3, El\nill thi ?\nSo, will things get better:\n© 2018 GLEIF and/or its affiliates. All rights reserved. | Author: GLEIF | Know-Your-Customer | GLEIF restricted 2018-05-09 21| 48\n","contentLength":175,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:34:58.186Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-findings_challenges-onboarding-client-organizations-in-banking-sector_v1.0-final.pdf","content":"]\n52% believe the time to onboard will SLE\nincrease over the next 12 months\n599 Key Drivers of Change\nIncrease = |ncreased Fraud\n= Tighter regulations\n» Business growth\n29%\nStay the = Budget Limitations\nS * Process Limitations\nQ8. Please give a reason for your answer.\n© 2018 GLEIF and/or its affilates. Allrights reserved. | Author: GLEIF | Know-Your-Customer | GLEIF restricted 2018.05-09 22| 48\n","contentLength":398,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:34:58.186Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-findings_challenges-onboarding-client-organizations-in-banking-sector_v1.0-final.pdf","content":"> \\\n\nY 9y LE\n“Day by day, the fraud and risk “With more regulation and more\nfactors are growing. So, to avoid scams, it will take a little longer\nthem at all cost there has to be to complete all the procedures\n\nIncreased Fraud : P ey\nbetter technologies and steps for client onboarding.\nto undergo before taking clients\nonboard.”\n“We are expanding our “We are about to change our\nbusiness aggressively.” manpower and, while new\nBusiness Growth employees adju.st and gain speed\nwe expect the time [to onboard]\nto increase.”\nBase: Total (102) Q7. How do you expect the time to onboard new client organizations to change over the next 12 months?\nQ8. Please give a reason for your answer.\n© 2018 GLEIF and/or its affiliates. All rights reserved. | Author: GLEIF | Know-Your-Customer | GLEIF restricted 2018-05-09 23 | 48\n","contentLength":817,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:34:58.186Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-findings_challenges-onboarding-client-organizations-in-banking-sector_v1.0-final.pdf","content":". VN\nDocumentation management represents @, LEI\nmost scope for improvement\nIdentification of legal identity also has the potential to be made more efficient\naccording to 2 in 5 senior salespeople in the banking sector.\n\n. Sand | ol\nDocumentation management [INNNENEGEGEEE 42% 2o0| 0 oot | ong\n000/ Oag onoo | 0oog\nooo E o000\nIdentification of legal entity NN 37% L L1\n0-250 250+\nCollection of customer information NN 34% employees employees\nValidation of customer information [N 32% >\nValidation of customer relationship to I 31%\nlegal entity\nCompliance with Know \\(our Customer I 30% )\n(KYC) regulation\nAnti Money Laundering checks [N 23%\nBase: Total (102) Q11 And which stages / aspects of the onboarding process for new client organizations have the biggest\nscope to be improved in terms of efficiency? Please select up to three.\n© 2018 GLEIF and/or its affiliates. All rights reserved. | Author: GLEIF | Know-Your-Customer | GLEIF restricted 2018-05-09 24 | 48\n","contentLength":965,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:34:58.186Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-findings_challenges-onboarding-client-organizations-in-banking-sector_v1.0-final.pdf","content":"L\nNew technologies are expected to become ‘3, F|\npart of the onboarding process\nThe majority of financial institutions expect new technologies such as digital\nsignatures and blockchain to be integrated in the onboarding process of new\nclient organizations.\nT T\n\nKYC Utilities Based on Se% 66%\n\nBlockchain Technology ’ 0\n© 2018 GLEIF and/or its affiliates. All rights reserved. | Author: GLEIF | Know-Your-Customer | GLEIF restricted 2018-05-09 25| 48\n","contentLength":451,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:34:58.186Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-findings_challenges-onboarding-client-organizations-in-banking-sector_v1.0-final.pdf","content":"R\nL\nDigital\nSignatures\n51%\nGoing forward,\nlegal entity\nonboarding will\nincorporate... KYC Utilities\nDigital Based on\nCertificates Blockchain\n46% Technology\n50%\n© 2018 GLEIF and/or its affiliates. All rights reserved. | Author: GLEIF | Know-Your-Customer | GLEIF restricted 2018-05-09 26 | 48\n","contentLength":292,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:34:58.186Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-findings_challenges-onboarding-client-organizations-in-banking-sector_v1.0-final.pdf","content":"The KYC burden is an ongoing one ‘@,\\ LE|\nOnly two thirds of financial institutions believe they hold accurate client\ninformation. Less than a third of clients can be relied on to report material\nchanges to their legal entity, so the burden remains with the institution to\nconduct regular reviews.\nBelieve the information\nthey hold on client\norganizations is accurate\nBelieve it’s easier to Review information held\nmonitor for material on client organizations at\nchanges after Only least every 12 months\nonboarding is completed\nof clients promptly\nreport material changes\nto their legal entity\nBase: Total (102) Q17 How would you rate the accuracy of the information your company holds on client organizations it\nonboarded in the past?; Q18 What proportion of your client base do you believe promptly reports any material\nchanges about them as a legal entity?; Q19 And how frequently does your organization review the information\nyou hold about the structure of your clients’ legal entity?; Q20 To what extent do you agree or disagree with\nthe following statements?\n© 2018 GLEIF and/or its affiliates. All rights reserved. | Author: GLEIF | Know-Your-Customer | GLEIF restricted 2018-05-09 27 | 48\n","contentLength":1198,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:34:58.186Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-findings_challenges-onboarding-client-organizations-in-banking-sector_v1.0-final.pdf","content":"3, El\n© 2018 GLEIF and/or its affiliates. All rights reserved. | Author: GLEIF | Know-Your-Customer | GLEIF restricted 2018-05-09 28 | 48\n","contentLength":138,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:34:58.186Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-findings_challenges-onboarding-client-organizations-in-banking-sector_v1.0-final.pdf","content":"7\n¢ 9y LE\nInstitutions are facing an increasing burden\nas a result of the need to comply with KYC\n1\n1\n1\n1\nLack of reliable and consistent identifiers\nis creating more work and less certainty\n1\n1\n1\nThere is clearly an opportunity to align on\none identifier to generate efficiencies\n© 2018 GLEIF and/or its affiliates. All rights reserved. | Author: GLEIF | Know-Your-Customer | GLEIF restricted 2018-05-09 29 | 48\n","contentLength":413,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:34:58.186Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-findings_challenges-onboarding-client-organizations-in-banking-sector_v1.0-final.pdf","content":"3, El\nAppendix\n© 2018 GLEIF and/or its affiliates. All rights reserved. | Author: GLEIF | Know-Your-Customer | GLEIF restricted 2018-05-09 30 | 48\n","contentLength":147,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:34:58.186Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-findings_challenges-onboarding-client-organizations-in-banking-sector_v1.0-final.pdf","content":"]\nResearch Overview ‘3, F|\nThis research explores the challenges that the banking sector faces when it\ncomes to onboarding new client organizations, with a view to investigating, in\nparticular, the implications of Know-Your-Customer (KYC) regulation. The\nresearch was conducted among 102 senior salespeople in the banking sector.\n\nNumber of employees E\n\n® 50 - 99 employees\n\n® 250 - 499 employees\n\n® 1,000+ employees\n\nol | a2\n\n© 2018 GLEIF and/or its affiliates. All rights reserved. | Author: GLEIF | Know-Your-Customer | GLEIF restricted 2018-05-09 4|48\n","contentLength":556,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:34:58.186Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-findings_challenges-onboarding-client-organizations-in-banking-sector_v1.0-final.pdf","content":"Top 5 challenges of onboarding 3, |\n\nnew client organizations\n\nContradiCtory information from different sources\n\nTl-me needef:l to- complete onboarding process for 50% 29% 519% 37% 63%\n\nclient organizations\n\nRellablllty of information\n\nResources needed (e'g' time’ people’ money)\n\nAccurate identification of Iegal entities\n\nlefl(iultn?s reconciling client information from 28% 55% 20% 5% 51%\n\nmultiple internal and external sources\n\nFalse pOSitives with Ant Money Laundering alerts\n\nBase: Total (102) Q1. Thinking about onboarding new client organizations, what would you say are the top challenges your\norganization faces? Please select up to 5.\n\n© 2018 GLEIF and/or its affiliates. All rights reserved. | Author: GLEIF | Know-Your-Customer | GLEIF restricted 2018-05-09 31|48\n","contentLength":778,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:34:58.186Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-findings_challenges-onboarding-client-organizations-in-banking-sector_v1.0-final.pdf","content":"Onboarding time 9| F|\nS\nProportion of time spent doing onboarding-related activities in a typical week\n28%\n25%\n22%\n14%\n4%\n3% 3%\n] -\n[ |\n0-5% 6-10% 11-20% 21-30% 31-50% 51-75% 76-100% Don’t\nknow\nBase: Total (102) Q5 In a typical week, what proportion of your time is spent doing activities related to the onboarding of new\nclient organizations?\n© 2018 GLEIF and/or its affiliates. All rights reserved. | Author: GLEIF | Know-Your-Customer | GLEIF restricted 2018-05-09 32| 48\n","contentLength":475,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:34:58.186Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-findings_challenges-onboarding-client-organizations-in-banking-sector_v1.0-final.pdf","content":"]\nOnboarding time SLE\nAverage time it takes to onboard a new client\n\n© 2018 GLEIF and/or its affiliates. All rights reserved. | Author: GLEIF | Know-Your-Customer | GLEIF restricted 2018-05-09 33| 48\n","contentLength":200,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:34:58.186Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-findings_challenges-onboarding-client-organizations-in-banking-sector_v1.0-final.pdf","content":"Proportion of onboarding process ‘3, F|\nthat involves manual tasks\n25% 24%\nI I I I\n0-5% 6-10% 11-20% 21-30% 31-50% 51-75% 76-100%\nBase: Total (102) Q9 What proportion of your company’s process for the onboarding of new client organizations involves\nmanual tasks?\n© 2018 GLEIF and/or its affiliates. All rights reserved. | Author: GLEIF | Know-Your-Customer | GLEIF restricted 2018-05-09 34| 48\n","contentLength":394,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:34:58.186Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-findings_challenges-onboarding-client-organizations-in-banking-sector_v1.0-final.pdf","content":"Identifiers and KYC providers used ‘@,\\ LE|\nNumber of identifiers used\n4\n20% 4+\nl 50%\n6,10%\n1-3\n50%\n1\n8% 7,3%\n8+,2%\nBase: Total (102) Q3 On average, how many different identifiers does your organization use to identify each client organization\nyou do business with?\n© 2018 GLEIF and/or its affiliates. All rights reserved. | Author: GLEIF | Know-Your-Customer | GLEIF restricted 2018-05-09 35| 48\n","contentLength":397,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:34:58.186Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-findings_challenges-onboarding-client-organizations-in-banking-sector_v1.0-final.pdf","content":"Identifiers and KYC providers used ‘@,\\ LE|\nNumber of KYC providers used\n3\n38%\nNone, 1% —\n—\n\n6+, 1%\nBase: Total (102) Q14 How many KYC service providers does your organization use to aid KYC processes?\n© 2018 GLEIF and/or its affiliates. All rights reserved. | Author: GLEIF | Know-Your-Customer | GLEIF restricted 2018-05-09 36 | 48\n","contentLength":334,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:34:58.187Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-findings_challenges-onboarding-client-organizations-in-banking-sector_v1.0-final.pdf","content":"Accuracy of client information ‘3, F|\nAccuracy of information held about client organizations\n11% 55% 30% 4%\n\"5 - Extremelv accurate m4 m3 H2 1 - Not at all accurate\nBase: Total (102) Q17 How would you rate the accuracy of the information your company holds on client\norganizations it onboarded in the past?\n© 2018 GLEIF and/or its affiliates. All rights reserved. | Author: GLEIF | Know-Your-Customer | GLEIF restricted 2018-05-09 37| 48\n","contentLength":439,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:34:58.187Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-findings_challenges-onboarding-client-organizations-in-banking-sector_v1.0-final.pdf","content":"Accuracy of client information ‘3, F|\nProportion of client base that promptly reports material changes\n31%\n28%\n17%\n12%\n8%\n2% I 2%\n0-5% 6-10% 11-20% 21-30% 31-50% 51-75% 76-100%\nBase: Total (102) Q18 What proportion of your client base do you believe promptly reports any material changes about them as\na legal entity (e.g. changes in identity information, including who owns or controls them)?\n© 2018 GLEIF and/or its affiliates. All rights reserved. | Author: GLEIF | Know-Your-Customer | GLEIF restricted 2018-05-09 38 | 48\n","contentLength":527,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:34:58.187Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-findings_challenges-onboarding-client-organizations-in-banking-sector_v1.0-final.pdf","content":"Impact of compliance with KYC regulation ‘3, F|\nImpact on monetary\nresources needed to 33% 32% 17% 15% 2\ncomplete onboarding\nImpact on time needed to\nP , 24% 37% 23% 14% 8\ncomplete onboarding\nM 5 - Critical Impact 4 3 m2 M 1- Minimal Impact\nBase: Total (102) Q12 What is the impact of ensuring compliance with Know Your Customer (KYC) regulation on the time and\nmonetary resources needed to complete the onboarding process for new client organizations?; Q20 To what\nextent do you agree or disagree with each of the following statements?\n© 2018 GLEIF and/or its affiliates. All rights reserved. | Author: GLEIF | Know-Your-Customer | GLEIF restricted 2018-05-09 39 | 48\n","contentLength":669,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:34:58.187Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-findings_challenges-onboarding-client-organizations-in-banking-sector_v1.0-final.pdf","content":"Proportion of business lost due to ‘3, F|\nonboarding and ID verification issues\nLegal entity Ieav.es.because onboarding process is too 19% 329% 20% 18% 8o B\ndifficult / takes too long\nTransaction is rejected because not enough information _\n. . 209 319 269 16% 4% \"%\nis known about the legal entity of the counterpart 7 4 o & K\nTransaction is not completed bec.ause the legal entity 28% 28% 249% 1a% A4 2\ncannot be onboarded quickly enough\nM 0-5% H6-10% 111-20% H21-30% 131-50% B 51%+\nBase: Total (102) Q16 What proportion of your organization’s business doesn’t go ahead due to each of the\nfollowing reasons?\n© 2018 GLEIF and/or its affiliates. All rights reserved. | Author: GLEIF | Know-Your-Customer | GLEIF restricted 2018-05-09 40 | 48\n","contentLength":742,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:34:58.187Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-findings_challenges-onboarding-client-organizations-in-banking-sector_v1.0-final.pdf","content":"Roles Oy LEI\nJob title\nSales Lead,\n7% \\\nHead of Sales,\n17%\nSales Director,\n44%\nVP of Sales,\n32%\n\nBase: Total (102) S4 Could you please confirm your job title?\n© 2018 GLEIF and/or its affiliates. All rights reserved. | Author: GLEIF | Know-Your-Customer | GLEIF restricted 2018-05-09 5|48\n","contentLength":288,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:34:58.187Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-findings_challenges-onboarding-client-organizations-in-banking-sector_v1.0-final.pdf","content":"> \\\n\nY 9y LE\n“Day by day, the fraud and risk “With more regulation and more\nfactors are growing. So, to avoid scams, it will take a little longer\nthem at all cost there has to be to complete all the procedures\n\nIncreased Fraud : P ey\nbetter technologies and steps for client onboarding.\nto undergo before taking clients\nonboard.”\n“We are expanding our “We are about to change our\nbusiness aggressively.” manpower and, while new\nBusiness Growth employees adju.st and gain speed\nwe expect the time [to onboard]\nto increase.”\nBase: Total (102) Q7. How do you expect the time to onboard new client organizations to change over the next 12 months?\nQ8. Please give a reason for your answer.\n© 2018 GLEIF and/or its affiliates. All rights reserved. | Author: GLEIF | Know-Your-Customer | GLEIF restricted 2018-05-09 41 | 48\n","contentLength":817,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:34:58.187Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-findings_challenges-onboarding-client-organizations-in-banking-sector_v1.0-final.pdf","content":"78\n¢ 9y LE\n“As our organisation is facing crisis “Currently our budget is flat so\nfilled year, we have limited budget to we can't change.”\nBudget spend and access to some of the\n.. . clients data is expensive.”\nLimitations\nBase: Total (102) Q7. How do you expect the time to onboard new client organizations to change over the next 12 months?\nQ8. Please give a reason for your answer.\n© 2018 GLEIF and/or its affiliates. All rights reserved. | Author: GLEIF | Know-Your-Customer | GLEIF restricted 2018-05-09 42 | 48\n","contentLength":517,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:34:58.187Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-findings_challenges-onboarding-client-organizations-in-banking-sector_v1.0-final.pdf","content":"3, F\nS\n15%\nExpect the time to onboard\nnew clients to decrease\n“My organization is taking over\nNew SyStems some latest technologies to\nspeed up the collection of\nN ew rocess information and significantly\nreducing the risk of fraud.”\nBusiness decision\nSpeed up collection\nStreamline\nBetter work force\no Better strategies\nstreamlined our\nprocesses.”\nBase: Total (102) Q7. How do you expect the time to onboard new client organizations to change over the next 12 months?\nQ8. Please give a reason for your answer.\n© 2018 GLEIF and/or its affiliates. All rights reserved. | Author: GLEIF | Know-Your-Customer | GLEIF restricted 2018-05-09 43 | 48\n","contentLength":641,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:34:58.187Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-findings_challenges-onboarding-client-organizations-in-banking-sector_v1.0-final.pdf","content":"e\ney\n)y LEI\nBetter Knowledge, Better Business\nSolution proposed by GLEIF to the issues identified with the research\n© 2018 GLEIF and/or its affiliates. All rights reserved. | Author: GLEIF | Know-Your-Customer | GLEIF restricted 2018-05-09 44 | 48\n","contentLength":248,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:34:58.187Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-findings_challenges-onboarding-client-organizations-in-banking-sector_v1.0-final.pdf","content":"e\nBetter Knowledge, Better Business ‘@‘ LE|\nThe findings in this report speak volumes about the need for an\naccurate and transparent source for legal entity identification.\nToo many businesses, especially in Not to mention encountering\nthe financial services industry, are compliance and security issues |\nlosing vast amounts of time and because of poor identification. 3\nmoney each time they make a o)\nbusiness transaction as a result of a &2 /‘\\\n'\nrange of inefficient processes — and (b N4\nit’s that inefficiency that means they 5 3’ a N\n) ) : -3 T\nrun the risk of losing the business . El ) N ,?1\nanyway. 1 5 : X *6 A ‘\n© o8 d b B 0 4§\n\\ - 1 P8 L ‘\n. O o B N\\ :\n© 2018 GLEIF and/or its affiliates. All rights reserved. | Author: GLEIF’l Know—Your—Custome8| GLEIQ%Stricte Q S & 2@8—05—09\\0 45 | 48 0 ~\nANrs . > Qi\n","contentLength":817,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:34:58.187Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-findings_challenges-onboarding-client-organizations-in-banking-sector_v1.0-final.pdf","content":"e\nBetter Knowledge, Better Business S, LE|\nAdoption of LEls promises to deliver real business capabilities,\nbenefits and quantifiable value for those businesses that make\nthe switch.\nNot only will it reduce operational But then so should the fact that a\nfriction, but it also makes global standard for legal entity\ninformation more accessible and identification, with open access to\nreliable. This opportunity to cut costs transparent and high quality\ngnd ggt Mmore e_ff|C|ent anql accu_ra_te reference data for all, would be a\nin their operations, all whilst gaining ; ; din the fi .\ndeeper insights into the global _orce SRECE\nmarketplace, should appeal to all industry as a whole.\nbusinesses. a4 3 j ,\nA of JV%\n\\ S 1 JgP K\nQ i &\n© 2018 GLEIF and/or its affiliates. All rights reserved. | Author: GLEIF | Know-Your-Customer | GLEIF restricted 1 ! g 201' 5-09 . 4& 48 '\nA3 BB » &\n","contentLength":881,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:34:58.187Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-findings_challenges-onboarding-client-organizations-in-banking-sector_v1.0-final.pdf","content":"T\nWe enable smarter, less costly and more reliable ‘@,\\ L E|\ndecisions about who to do business with\nFor more information and regular updates on GLEIF\nactivities and LEI developments, visit the GLEIF website\nwhich is available in 14 languages at www.gleif.org\nFollow us on:\nYou\n\n\" Tube\n\n© 2018 GLEIF and/or its affiliates. All rights reserved. | Author: GLEIF | Know-Your-Customer | GLEIF restricted 2018-05-09 47 | 48\n","contentLength":419,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:34:58.187Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-findings_challenges-onboarding-client-organizations-in-banking-sector_v1.0-final.pdf","content":"- _____00000_000000___]\no o o m\nLimitations d, LEI\nThis presentation contains confidential and proprietary information and/or trade\nsecrets of the Global Legal Entity Identifier Foundation (GLEIF) and/or its\naffiliates, and is not to be published, reproduced, copied, or disclosed without\nthe express written consent of Global Legal Entity Identifier Foundation.\nGlobal Legal Entity Identifier Foundation, the Global Legal Entity Identifier\nFoundation logo are service marks of Global Legal Entity Identifier Foundation.\nISO and the ISO logo are service marks of International Organization for\nStandardization. Other products and services and company names mentioned\nhere in are the property of and may be the service mark or trademark of their\nrespective owners.\n© 2018 GLEIF and/or its affiliates. All rights reserved. | Author: GLEIF | Know-Your-Customer | GLEIF restricted 2018-05-09 48| 48\n","contentLength":895,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:34:58.187Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-findings_challenges-onboarding-client-organizations-in-banking-sector_v1.0-final.pdf","content":"Responsibilities 9| F|\nS\nResponsibility for buying and selling...\nInvestment Products 61%\nShares 51%\nBonds 49%\nDerivatives (e.g. options,\n(8. op 44%\nfutures)\nBase: Total (102) S2 For which of the following do you have responsibility within your organization?\n© 2018 GLEIF and/or its affiliates. All rights reserved. | Author: GLEIF | Know-Your-Customer | GLEIF restricted 2018-05-09 6|48\n","contentLength":388,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:34:58.187Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-findings_challenges-onboarding-client-organizations-in-banking-sector_v1.0-final.pdf","content":"3, El\n© 2018 GLEIF and/or its affiliates. All rights reserved. | Author: GLEIF | Know-Your-Customer | GLEIF restricted 2018-05-09 7|48\n","contentLength":135,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:34:58.187Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-findings_challenges-onboarding-client-organizations-in-banking-sector_v1.0-final.pdf","content":"]\nThe onboarding process is far from slick ‘@,\\ LE|\nThere is no one stop shop\nfor identifiers\nIdentifiers are often\ninconsistent\nOnboarding therefore creates\n\na significant burden\n\n© 2018 GLEIF and/or its affiliates. All rights reserved. | Author: GLEIF | Know-Your-Customer | GLEIF restricted 2018-05-09 8|48\n","contentLength":310,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:34:58.187Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-findings_challenges-onboarding-client-organizations-in-banking-sector_v1.0-final.pdf","content":"3, El\ne e e\nEntity Identifiers\n© 2018 GLEIF and/or its affiliates. All rights reserved. | Author: GLEIF | Know-Your-Customer | GLEIF restricted 2018-05-09 9|48\n","contentLength":160,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:34:58.188Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-findings_challenges-onboarding-client-organizations-in-banking-sector_v1.0-final.pdf","content":"e\nFinancial institutions use, on average, ‘@,\\ LE|\nfour identifiers to help identify client organizations\nIn order to accurately identify client organizations with the most up-to-date data,\nfinancial institutions tend to use a variety of different identifiers for cross-checks.\nOn average they use 4 different identifiers internally, but about a third say they\nuse 5 or more identifiers.\n:\n20% 50%\nAverage of\nD :\n‘ identifiers used\n6,10%\n1-3\n1\no\n8+,2%\n\nBase: Total (102) Q3 On average, how many different identifiers does your organization use to identify\n© 2018 GLEIF and/or its affiliates. All rights reserved. | Author: GLEIF | Know-Your-Customer | GLEIF restricted 2018-05-09 10 | 48\n","contentLength":688,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:34:58.188Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-the-pitfalls-of-onboarding/gleif-infographic_the-future-of-legal-entity-identification_final.pdf","content":"””\"\n. e\nGLEIF fi:\nST Al 0N\n° ZaiN= \"\"i‘Wi ',:‘ % .\nEnabling global identity A‘igfl%‘g%gfifl%‘%m .\nProtecting digital trust . lgi“mi‘fib\\i’g'f\"r“é’:‘i» Py\nNSV A,\nAPPSO\nThe Fut f Legal U RSt\n€ rFuture ot Legda Y AL\nA i\nEntitv Id i : AN S\nntity Identification \\\\e,}‘%%‘\n) ‘\\ \\4}, A —\nWhy a standardized approach ‘\\§!}§§%” .\nis the way forward. \\A‘@}}%‘gl -\n® \\ wfl‘\\w —\nOnboarding, on time\nTo onboard new clients, financial services firms must spend significant\namounts of time, money and resources on the correct identification\nof the legal entity they want to engage with. <>\n|\n(B\nMe @\nk \\ .\n\\ /[\n\\ \\ ®\nL\nAVERAGE TIME IT TAKES ,y /\n— TO ONBOARD A NEW “»‘ ‘\nweeks LEGAL ENTITY QQ\nTop challenges \\\\\\\nof onboarding... -\n\\\n—_— e |\nRELIABILITY RESOURCES CONTRADICTORY ‘\nOF INFORMATION NEEDED INFORMATION FROM\nDIFFERENT SOURCES\n000 Ny\n000\n00 I \\\n5 7 % 5 5 % 5 2 %\n(0 (0 (0\nAGREE AGREE AGREE\n()5\n- 1N \" -\ns,\nN ZRS\nAVERAGE NUMBER . .\nOF IDENTIFIERS\nBUSINESSES USE ' '\nType of identifier used:\nISO BIC FDICID GLOBAL LEI RSSD ID\n454 Lb4y L34 35«4\nThe current process is long and complex.\nUsing multiple identifiers can cause:\n—_— O\n— OO I\n—_— OO0\n— (XX X J\nINCONSISTENT DRAIN ON LACK OF\nINFORMATION RESOURCES TRANSPARENCY\nThe risk\n@ oooooooooo.‘\n(o)\nOF BUSINESSES BELIEVE PROSPECTS \\\nMIGHT TURN TO COMPETITORS IF THEIR ‘\nONBOARDING PROCESS TAKES TOO LONG\nA simple, robust identification is needed - especially when:\nBUSINESSES BELIEVE ONBOARDING TIME IS\nONLY GOING TO RISE DUE TO INCREASED FRAUD,\n@ 1 in ; REGULATION AND BUSINESS GROWTH\n070000\n00 00 O\\ OF BUSINESSES EXPECT DIGITAL TECHNOLOGY\n@ 61 o TO FURTHER COMPLICATE THE ONBOARDING *\nY00 00O / PROCESS\n100 0 o BN ————\n®\np{\nLEls are the way forward :\nThe Global LEIl Index is the only global online source that 2\"\"~ /,\nprovides open, standardized and high quality legal entity ’fym\nreference data. 4»\"@\nWith the use of a Legal Entity |dentifier, key reference data \\fl\\\\g\nis connected using a 20-digit alphanumeric code and is free (A\nfor all to use. i “\n&K\nREDUCTION IN COSTS ‘\\‘\\\nTHE ESTIMATED SAVINGS LEls \\\\}\nO/ COULD BRING TO CAPITAL \\/\no /0 MARKETS OPERATIONAL COSTS o\nWho is who? Who owns whom?\n...quickly, easily and accurately.\n[ [\nGet In touch with GLEIF\nto find out more\n","contentLength":2219,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:35:16.170Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/gleifs-digital-strategy-for-the-lei/gleif-idc-research-creating-agile-resilient-global-trade-with-the-lei-and-vlei/2023-03-23_driving-business-with-trust-the-sustaining-role-of-secure-and-reliable-identities_final_public.pdf","content":"| DERMECHNONOG WSRO RUKGHTE SUSTAINING ROLE OF SECURE AND RELIABLE IDENTITIES\nFhe Sustaini Rol fsS\nd Reliable Identiti\nMarch 2023\nSponsored by\nAuthor:\nGLEIF Marco Becker\nConsulting Manager\nIDC Central Europe\n[}\n@\nko)\nY o vy\n,w'\\\\';‘“\\\\\\Qf RN& f’.:i?“.‘.\\ \\\\\\\\Q\"\\ : e\n7 A SR (e R\n7 e A\"N{\"f&f‘“ ’}\\ -‘: : ?;snf‘i}z\n7 A2\\ TR,\n/ . L4 R ol P - =% S W \"f.“?}\"n,‘f S\\\n- R i SO VBRI, s G, 3\nLS : RERRRRER S R RRRRRERA Ll R ) b,\n4 R SR ALLLLLLEEY S (LOLs XE RRRRRLLE, Wfi“\\, SRR Sasiic \\\nP SR OODDRRTS S UG & 23 RSk R\nS 2 f:::?.:::.-\" N N\nZEERS X% .,:‘ SOOI 3 ORI SRR ¥ R s Y\nR ) X ORCR Sy s R R S e g 2 N L\nG / R .n.r-.o----- *afi'@ e SRR i\nAy T %r P AN\nin;: i*:‘\nBHEHI G 3 S5 | e BE L Bl =\nN \\iiiiii L o g /2 S/\nAR e r siogeviiiie Sesieaeiiiiiig\nI e &/\ni \\- \\* \\k“?,o’ s “\no N sk QRN L\n\\ / .é‘ \":\"2’-‘“-‘_’-‘_‘.‘_‘.'_‘.'_‘.'\".'\".\"'.'_'.'.'.'.'.\"'. :‘:,:{x “:‘:. ©\nN\\ DNl 7 i S, fis\n\\fa s BN '5555353532'31\"’..1‘:'-;.-'55553:'Et'i55:‘E:'E1'2fEfE:'E:'EfEt'E:\":fE:'5:'3:'32'5:'5:'5:5: fiis\nR e iR i\ne N (.\ns P IREE\nNN e\nYy YN RXNNARN L]\nN (L ’\nP00, ut\n\\: ; /.\n","contentLength":1049,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:36:20.844Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/gleifs-digital-strategy-for-the-lei/gleif-idc-research-creating-agile-resilient-global-trade-with-the-lei-and-vlei/2023-03-23_driving-business-with-trust-the-sustaining-role-of-secure-and-reliable-identities_final_public.pdf","content":"DRIVING BUSINESS WITH TRUST: THE SUSTAINING ROLE OF SECURE AND RELIABLE IDENTITIES\nIntroduction\nIn a digital and globalized world, checking the trustworthiness of a business counterpart can be difficult. While\nlegal entity identity — or more precisely the lack of transparency into the identities and ownership structures\nof legal entities — became a major issue for financial markets with the financial crisis in 2008, the same issue\napplies to global trade and supply chains. During the pandemic, fraudulent transactions increased, making\ntrust between business counterparts increasingly important and highlighting the need for verifiable company\ndata, especially in cross-border trade.\nCurrently, there are several challenges based on the lack of identifiability, and this list is not exclusive:\no Missing trust between legal entities that prohibits business interaction and trade finance\no Various, mostly non-standardized and -digitized national and international identification schemes\no Adherence to numerous regulations, such as know your customer (KYC), antifraud, and AML (anti-money\nlaundering)\no Cost and efficiency of thorough identity verification and risk management\no Limited flexibility, agility, and resilience to tackle accelerating disruptions\nThis IDC Technology Spotlight shows the importance of trust as an enabler for global trade, how identities for\nlegal entities and their representatives can enable and maintain trust, and how secure identities can be used to\nmitigate risk, raise efficiency, and foster resilience. It introduces the Legal Entity Identifier (LEI) (ISO-17442) for\nB2B identity and verification and shows how application of the LEI and vLEI, the digital, cryptographic version\nof the LEI code, can contribute to cross-border legal entity identification and to more efficient, secure, and\ninnovative supply chain management.\n. p - e s -\n‘ T 2 el e . T oy\nT e A s g & —\n¢ T & ' Ty s Y ) S .\nBl AS Le \" | - - - 4 — X ; \\‘ 5 / AR 3. .l\nN SRR TN, el\n@ < (0] . .\n: THEEEEER , - R\n: . S W e . ¥ \",_.'% h ‘ ~ ; 1\\ V 4\"‘; - R T T : -\nAN SRREER. E: § - NEE e —\nJ — } CLT Tt . Tl LE i : ¥\nv \" \"U—'y_ T4 s ‘ L ] ;fiflf.h' A\nek E 40k f vl —\n: k i e = ‘::‘::\" -\ne i , =IDC\n","contentLength":2201,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:36:20.844Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/gleifs-digital-strategy-for-the-lei/gleif-idc-research-creating-agile-resilient-global-trade-with-the-lei-and-vlei/2023-03-23_driving-business-with-trust-the-sustaining-role-of-secure-and-reliable-identities_final_public.pdf","content":"DRIVING BUSINESS WITH TRUST: THE SUSTAINING ROLE OF SECURE AND RELIABLE IDENTITIES\nDespite the value of having identities and identifiability, there are also challenges:\n@) Validity: Companies must check if an identifier is valid, if the counterpart really is the owner or\naffiliate of the identified entity, and if they are eligible to use the identifier.\nFeasibility: Checking identities but also providing and proving identity, legal capacity, and\n\nU’E | Uf\\ compliance with relevant laws is a lot of work. This is especially challenging for SMEs that don't\nhave the resources to maintain the many identities required by different business partners or\nbusiness transactions.\n\n3\n\n_,_'[9 Time and effort: There are multiple identification schemes — national, international, or\n\nN sectoral — stored in different silos, often neither digitized nor internationally standardized or\ninteroperable. The number of identities and the increasing cost of managing them make supply\nchains less efficient and agile.\n\né@; “Golden source” data: Relevant identity information needs to be continuously maintained (name,\naddress, operating status, etc.) and changes immediately communicated, in some cases even in\nreal time (if compliance is threatened, for example).\n\nTo make legal entity identities not only useful for transparency, resilience, and security, but also faster and\nmore versatile to increase business agility, efficiency, and collaboration, digitization of corporate identity will\nbecome increasingly foundational. Digital legal entity identity will be critical for a wide range of international\ntrade transactions and processes such as contract creation, data exchange, e-documents, ESG compliance, and\nknow-your-customer processes, while individually minimizing risk.\nIn summary, digital identity can improve individual supply chain risk, agility, and resilience, but also contribute\nto global society by fostering market integrity, financial stability, and a more inclusive trade system. To make\nidentities globally effective, IDC proposes three core requirements for broad adoption:\nGlobal value chains require a global approach: This requires globally unique identifiers to\nbridge local identity silos and enable efficient orchestration of worldwide trade processes.\nAgile and efficient identity checks require digitization: Standardized, interoperable, and\n( 4 technology-agnostic digital identity management solutions are needed to make processes efficient\n— and to eliminate duplicative verification workloads on similar occasions.\nro Holistic inclusion requires easy accessibility: This applies regardless of company size and\nL 4 . . . .\n@ jurisdiction to encompass the global trade network.\nIDC assumes that\n® could make up\nOro?,O of trade finance if trade\necosystems become\no*’o y\nO\nIDC FutureScape: Worldwide Corporate Banking 2023 Predictions, October 2022\n) =IDC\n","contentLength":2877,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:36:20.844Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/gleifs-digital-strategy-for-the-lei/gleif-idc-research-creating-agile-resilient-global-trade-with-the-lei-and-vlei/2023-03-23_driving-business-with-trust-the-sustaining-role-of-secure-and-reliable-identities_final_public.pdf","content":"DRIVING BUSINESS WITH TRUST: THE SUSTAINING ROLE OF SECURE AND RELIABLE IDENTITIES\nEnsuring Identities and Authentication of\nPeople in Organizational Roles with the\nGlobal LEI System and vLEI\nThe LEl is an internationally recognized standard for identification of legal entities. The LEl is a 20-digit code\nbased on ISO 17442-1:2020. As an ISO standard, it enables unique, global identification of entities, and it is\npersistent, meaning the entity remains tagged by the LEI even when it ceases operations. All LEls are part of a\nglobal register, the LEI Index, which anyone can access free of charge and at all hours. The LEI index enables\nanyone to access the LEI and the associated reference data including links to local business registration or\nother selected international identifiers such as the S&P Global Company ID, BIC, or ISIN. The LEI offers data\nabout “who is who\" and “who owns whom.”\n\nLEl record =) Entity creation date\n\ntransparency =) Last data validation date\n\nenables users to =) Last update of LE|\n\nCheCk mformatlon -) Entity operating status\n\nfor all issued LE|S’ =) Next scheduled revalidation date\n\nsuch as: S e\n\n=) LElissuer\n=p Corroboration level\n\nSource: IDC, based on information provided by GLEIF, 2023\nOrganizations can easily apply for an LEI by self-registering at one of the 39 accredited LEl issuers worldwide,\nserving 226 jurisdictions. The LEl issuers check the submitted data with local authorities and issue the LEI\nfor a small fee. An annual renewal requirement ensures high quality of data. Organizations can become a\nRegistration or Validation Agent, which expands the LEI issuer network. They can help their clients obtain LEIs\nand thereby streamline their LEl issuance.\nThe organization operating the LEI Index, the Global Legal Entity Identifier Foundation (GLEIF), is a\nsupranational non-profit organization based in Switzerland and founded by the Financial Stability Board (FSB),\ndriven by the leaders of the G20 after the financial crisis in 2008. GLEIF is overseen by the Regulatory Oversight\nCommittee (ROC) of more than 65 financial market regulators and public authorities as well as 19 observers\nfrom more than 50 countries.\n© IDC 2023 12 éIDC\n","contentLength":2198,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:36:20.844Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/gleifs-digital-strategy-for-the-lei/gleif-idc-research-creating-agile-resilient-global-trade-with-the-lei-and-vlei/2023-03-23_driving-business-with-trust-the-sustaining-role-of-secure-and-reliable-identities_final_public.pdf","content":"DRIVING BUSINESS WITH TRUST: THE SUSTAINING ROLE OF SECURE AND RELIABLE IDENTITIES\nFigure 6: Global LEI System and GLEIF Governance Framework\nStrong governance in place for LEl, the Global LElI System, and GLEIF\nThe LEI, the Global LEI System, and GLEIF are based on a strong global governance framework to protect the\npublic interest, while promoting an open, flexible, and adaptable operational model:\nComposed of public authorities Ensures the operational integrity\nfrom around the world of the Global LEI System\nReoulat Global\ncguiatory Legal Entity\nCOvers!igtht Identifier\norTnglc - Foundation\n(ROO) (GLEIF)\nAccredited\nLocal Issuers\nIssue LEls to legal entities\nSource: IDC, based on information provided by GLEIF, 2023\nIn December 2022 GLEIF launched the verifiable LEI (vLEl) to support automation of identity validation\nprocesses and add authentication and verification layers for organizational roles. This means the vLEI can also\ninclude person and role identity for representatives, either based on official organizational roles listed in ISO\n5009 or on their own creations, for example, based on local organization types or relationship structure. With\nthat, it becomes a digital credential, cryptographically bound to its owner.\nThe VLEI is based on open ACDC Credential (IETF draft) and Decentralized Identifier (W3C foundation) standards\nand is therefore interoperable. VLEIs are cryptographically bound to each other, building a trust chain with\nGLEIF the root of trust. Using the KERI network protocol, the VvLEI is robust and quantum safe. KERI also gives\norganizations full control over the VLEIs, their identity data usage, and the transportation to the network of\ntheir own choice, enabling it to be operated on blockchain, distributed ledger technology (DLT), on premises,\nor in clouds. From an IT perspective, very little investment is required and the technological complexity for set\nup is low. A standard server is sufficient to operate the KERI protocol and to manage the self-issued vLEls. Local\nsoftware on every device is needed to log in and authenticate access to the vLEls.\n3 =IDC\n","contentLength":2114,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:36:20.844Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/gleifs-digital-strategy-for-the-lei/gleif-idc-research-creating-agile-resilient-global-trade-with-the-lei-and-vlei/2023-03-23_driving-business-with-trust-the-sustaining-role-of-secure-and-reliable-identities_final_public.pdf","content":"DRIVING BUSINESS WITH TRUST: THE SUSTAINING ROLE OF SECURE AND RELIABLE IDENTITIES\n° L L L\nUse Case: Using LEI and VLEI in Supply Chain\nM Enh C li\nanagement to Enhance Compliance,\no L L\nEfficiency, and Innovation\nLooking at the benefits of legal entity identities in supply chains, the handling of dangerous goods illustrates\nhow VLEIs can contribute to compliance, efficiency, and innovation. This can also be translated to other goods,\nsuch as fakes (e.g., designer apparel) or those that fall under supply chain regulations (e.g., conflict minerals or\nprotected resources such as rainforest wood).\nFigure 7: Use Case: LEI and VLEIl in Supply Chain Management for Compliance, Efficiency, and\nInnovation\nEach participant in the workflow\nhas a VLEI containing ...\no Company LEI\n% « Official role of representatives\n%\\qzn « Functional role\n... that clearly identifies it and its\nrespective legal entity and enables it to\nperform actions that its official/functional\nL i role allows.\nSender TRACKING AND REPORTING Logistics Provider\n(Legal Entity #1) IN A CENTRAL SYSTEM: (Legal Entity #2)\nVLEI shows VLEI shows that logistics provider VLEI shows that DASG\nthat sender is is eligible to process shipping of has the authority to\neligible to ship ° dangerous goods and allows the check and decide if\ndangerous items LI.|J (9 reprentative to sign shipping contracts the dangerous items\nand allows sender - and their shipment\nrepresentative to precautions adhere to\nhandle logistics safety standards\nand contracts Dangerous Goods\nSafety Advisor (DASG)\n(Legal Entity #2)\nAlways up-to-date transport\ndocuments on digital device\nEER FER L\nJ L_. o\nChief Risk Officer Vehicle Driver 1st Receiver 2nd Receiver\n(Legal Entity #2) (Legal Entity #2) (Legal Entity #3) (Legal Entity #4)\nvLEl enables CRO to access VLEI proves that the legal entitiy VLEI shows that the receiving entities are eligible\nrelevant data for safety and risk and the vehicle driver have the to receive the dangerous good and allows the\ndocumentation and to sign off required licenses to transport representatives to sign the receiving\nmandatory reporting dangerous goods\nSource: IDC, based on information provided by GLEIF\n© IDC 2023 14 _EIDC\n","contentLength":2202,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:36:20.844Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/gleifs-digital-strategy-for-the-lei/gleif-idc-research-creating-agile-resilient-global-trade-with-the-lei-and-vlei/2023-03-23_driving-business-with-trust-the-sustaining-role-of-secure-and-reliable-identities_final_public.pdf","content":"DRIVING BUSINESS WITH TRUST: THE SUSTAINING ROLE OF SECURE AND RELIABLE IDENTITIES\nFigure 7 shows one supply chain link in a supply chain that could have dozens of links worldwide. Four\ncompanies, the sender, the logistics provider, and the two receivers have entity LEIs for the trade documents.\nThe logistics provider has issued different role vLEIs for the officials in charge, the dangerous-goods safety\nadvisor (DSGA), the risk prevention officer, and the vehicle drivers. With this, the individual VLEI representatives\ncan perform actions that their role allows for, such as signing off the trade documents or even only parts of\ndocuments for which they are responsible, transporting the dangerous goods, checking the dangerous goods\nfor proper handling, and submitting regulatory filings. Embedding the vLEI in all processes enables easier and\nfaster identity and trade verification up to real-time speed, enhances the security and efficiency of operations,\nand helps reporting; it is also traceable compliant.\nIt also enables process innovation. This can be done by reinventing a process, such as making the automated,\ndigital processing of all documents in a central platform accessible by eligible participants with defined roles,\nexpressed digitally via the vLEIL Or it can be done by implementing a new technology, for example, to ensure\nthat suppliers really are who they claim to be or do what they claim to be doing. IDC expects that by 2024,\n15% of supply chain transactions will use blockchain for the provenance of ethical and sustainable practices.\nIt can also be done by inventing a completely new way of doing things, such as setting up a circular economy\nwith a large partner ecosystem based on strong reporting, holistic supply chain control capabilities, and using\nidentities for the goods itself in the future.\n- ) 2\n‘O’f,’}? : =\n\" /‘?fi\"‘m@% -\n' | 4 —— - o\n!' h‘ -\ne A\ne ’ = T N .\n« s ) A P>\ne $4>Aw 1 ] VI_‘ 'A\"—\"i'l,’ - \\‘ i B ’ -‘; ‘ k- - ¥ V4 X\n= ’éé M 5 ¥ : ‘ il ! & <5 \\ | ,1“ .\n\\ \" N LT T, T ORI A\n. e W -~\ni B :,“-\\ \\ / ~‘§“ /\nN S O S\\\n. /Aam e 2P e 1(' 1) T T < ) G\n] O Lfi' fif\\ i !:E,Z ' ’ g \\fi i > I.—- T v I B\nel A R = g T\n: T = _ Y T p ‘# '\ns =IDC\n","contentLength":2236,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:36:20.844Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/gleifs-digital-strategy-for-the-lei/gleif-idc-research-creating-agile-resilient-global-trade-with-the-lei-and-vlei/2023-03-23_driving-business-with-trust-the-sustaining-role-of-secure-and-reliable-identities_final_public.pdf","content":"DRIVING BUSINESS WITH TRUST: THE SUSTAINING ROLE OF SECURE AND RELIABLE IDENTITIES\n\nConclusion\n\nEvery piece of software or system that provides visibility, transparency, or security adds a piece to the puzzle\n\nof building trust and mitigating risk in global supply chains. Secure and reliable identities are a prerequisite\n\nfor trust, and trust is a foundation for secure, resilient, and prosperous trade — especially cross-border.\nEstablishing a universal way to digitally verify legal entities and their key individuals can contribute to global\nsociety by fostering market integrity, financial stability, and a more inclusive worldwide trade system.\n\nThat makes the Global LEI System and the LEI important pieces of the puzzle. A key aspect is that the Global LEl\nSystem was established by the regulatory community as a public good and the system operations are managed\nby a foundation that is non-profit and based on an open governance framework, meaning the system is reliable\nand has no vendor lock-in risk. The digital vLEI can enable more efficient and agile business operations and\n\ncan improve customer experience while ensuring security and compliance. In the emerging sustainability\ncompliance area, the VLEI can support supply chain due diligence and sustainability reporting.\n\nIDC believes interconnectivity, ease of access, and a critical mass of participants are key success factors for\ndigital identity and trade digitalization. To reach critical mass, IDC believes large enterprises and organizations,\nregulators and policy makers, financial institutions, and vendors and service providers should be the driving\nforce here. They must work together to particularly enable small businesses worldwide, standardize methods\nand solutions, and promote the sharing and exchange of data.\n\n© IDC 2023 16 éIDC\n","contentLength":1817,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:36:20.844Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/gleifs-digital-strategy-for-the-lei/gleif-idc-research-creating-agile-resilient-global-trade-with-the-lei-and-vlei/2023-03-23_driving-business-with-trust-the-sustaining-role-of-secure-and-reliable-identities_final_public.pdf","content":"DRIVING BUSINESS WITH TRUST: THE SUSTAINING ROLE OF SECURE AND RELIABLE IDENTITIES\nResources\ne IDC European Identity and Digital Trust Forecast, 2022-2026 (IDC #EUR148752522, June 2022)\ne |IDCEuUropean IT Security Survey, May 2022\ne IDCEurope Sustainable Strategies and Technologies Maturity Survey, January 2022\no IDCFuture Enterprise Resilience and Spending Survey, Wave 5, June 2022\no IDC Future Enterprise Resilience and Spending Survey, Wave 7, August 2022\no IDCFuture Enterprise Resilience and Spending Survey, Wave 12, January 2022\no IDC FutureScape: Worldwide Corporate Banking 2023 Predictions (IDC #US49830222, October 2022)\no IDCFutureScape: Worldwide Blockchain 2021 Predictions (IDC #US45927420, October 2020)\ne IDC Security Identity Survey, September 2021\ne IDCSustainability in Germany 2022 — Greening of and by IT, March 2022\no IDCWorldwide Identity and Access Management Forecast, 2022-2026 (IDC #US48670522, July 2022)\ne The OLAF Report 2021, European Anti-Fraud Office, European Commission, Publications Office of the\nEuropean Union, 2022\n17 =IDC\n","contentLength":1066,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:36:20.844Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/gleifs-digital-strategy-for-the-lei/gleif-idc-research-creating-agile-resilient-global-trade-with-the-lei-and-vlei/2023-03-23_driving-business-with-trust-the-sustaining-role-of-secure-and-reliable-identities_final_public.pdf","content":"Marco Becker, Consulting Manager, IDC Central Europe\n\"l ) Marco Becker has been a senior consultant at IDC since 2019. He mainly prepares\n\" v studies and implements customer projects, for which he is in contact with both provider\ni and user companies. His focus is on (l)loT technology, cloud, cybersecurity, sustainability,\nand network technologies.\nIDCis the world's leading provider of market information, consultancy services, and events in the information technology and\ntelecommunications field. IDC analyzes and forecasts technological and industry-related trends and potential, enabling clients to plan\nbusiness strategies and IT purchasing. Drawing on its network of more than 1,300 analysts in 110 or so countries with global, regional, and\nlocal experience, IDC offers clients comprehensive research on the IT, TC, and consumer markets. Managers and IT professionals have been\nplacing their trust in IDC for decision making for more than 50 years.\nFor more information, please visit www.idc.com and www.idc.de.\nExternal publication of IDC information and data, including all IDC data and statements used for advertising purposes, press releases, or\nother publications, requires prior written approval from the appropriate IDC vice president, country manager, or managing director. A draft\nof the text for publication should accompany any such request. IDC reserves the right to deny approval of external publication for any\nreason.\nFor more information, please contact:\nLynn-Kristin Thorenz, Associate Vice President, Research and Consulting, IDC - eMail: Ithorenz@idc.com\n© IDC, 2023. Reproduction of this document without written permission is strictly prohibited.\nIDC Central Europe GmbH T: +49 69 90502-0 —\n—\n\nHanauer Landstr. 182 D F:+49 69 90502-100 — I ‘\nD-60314 Frankfurt a.M. E: info_ce@idc.com -\n© IDC 2023 18 _ ID :\n","contentLength":1838,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:36:20.844Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/gleifs-digital-strategy-for-the-lei/gleif-idc-research-creating-agile-resilient-global-trade-with-the-lei-and-vlei/2023-03-23_driving-business-with-trust-the-sustaining-role-of-secure-and-reliable-identities_final_public.pdf","content":"DRIVING BUSINESS WITH TRUST: THE SUSTAINING ROLE OF SECURE AND RELIABLE IDENTITIES\n\nTable of Contents\n\nDigital Trust: The Foundation of a Digital-Enabled World 4\n\nReliable Identity Becomes the Heart of Physical and Digital Interactions 6\n\n\"ldentity and Digital Trust\" — A Hot Growth Market 7\n\nIdentities Are Vital for Agile and Resilient Worldwide Trade 9\n\nEnsuring Identities and Authentication of People in Organizational Roles with Global LEI System and VLE| 12\n\nUse Case: Using LEI and vLEIl in Supply Chain Management to Enhance Compliance, Efficiency, and 14\n\nInnovation\n\nConclusion 16\n\nResources 17\n. =IDC\n","contentLength":613,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:36:20.844Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/gleifs-digital-strategy-for-the-lei/gleif-idc-research-creating-agile-resilient-global-trade-with-the-lei-and-vlei/2023-03-23_driving-business-with-trust-the-sustaining-role-of-secure-and-reliable-identities_final_public.pdf","content":"DRIVING BUSINESS WITH TRUST: THE SUSTAINING ROLE OF SECURE AND RELIABLE IDENTITIES\nL L L L L\n[ J\nDigital Trust: The Foundation of a Digital-\nThe world is fast becoming “digital first.” IDC believes that by 2024, 80% of the people around the world will\nhave access to the web and that spending on goods and services on the internet will reach more than $10.5\ntrillion — a huge amount given that overall consumer household spending reached $53 trillion in 2021,\naccording to the World Bank. Not only are enterprises striving to create new digital-first business models to\ndrive revenues and growth, but governments are also digitizing their economies and services.\nAll this comes with advantages for economies, trade, and consumer experience. It also comes with challenges,\nespecially in terms of risk. According to IDC research, mitigating risk that threatens digital trust is often the most\nchallenging aspect for digitally mature companies in running their digital business. And that's a huge problem\nbecause trust already is a key business asset in a global, digital context. Household customers are increasingly\nopting to only interact with trustworthy and purpose-driven organizations; this is increasingly the case for\nbusiness-to-business interactions too. More than 90% of European organizations say trust is relevant, important,\nor a competitive advantage. About 74% of organizations already have formal trust programs of varying maturity\nin place, some for now primarily focused on security and privacy while others already encompass customer\nexperience, reputation, sustainability, and diversity. 79% of organizations worldwide say trust programs —\ninvestments in security, privacy, and compliance to improve risk posture — will be a priority in 2023.\nFor\nof organizations, trust of digitally mature companies\nprograms will be an say\ninvestment priority in 2023. For 37/%, a is a major\ninvestment. challenge when running a digital business.\nSource: IDC Future Enterprise Resilience and Spending Survey, Wave 5, June 2022 Source: IDC Future Enterprise and Resilience Survey, Wave 7, 2022\nFigure 1: IDC Trust Framework\n&\nOéQ ;*C @f‘\\\\ e\noy C O & . ‘\nNy > o £ : : Strategic\nel © W & Ethics and Social <\nyc o Responsibility %\nERY o <,\n=2 ho] g ] : Z,\no - 3 Compliance e\nLl © =\nEl = Obligatory O‘\\/\\\n-\n2\nD\nFoundational\nSource: IDC, 2022\ne i y =IDC\n","contentLength":2353,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:36:20.844Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/gleifs-digital-strategy-for-the-lei/gleif-idc-research-creating-agile-resilient-global-trade-with-the-lei-and-vlei/2023-03-23_driving-business-with-trust-the-sustaining-role-of-secure-and-reliable-identities_final_public.pdf","content":"DRIVING BUSINESS WITH TRUST: THE SUSTAINING ROLE OF SECURE AND RELIABLE IDENTITIES\nIDC's Trust Framework (see Figure 1) illustrates potential trust outcomes and how trust is\nsystematically achieved by combining three interrelated layers of trust:\nRisk: Risk management is a prerequisite for every company. Only proper risk management enables\neconomically successful business operations by maintaining continuity.\nSecurity and compliance: A loss of sensitive data or any significant downtime of services\ncan quickly erode trust. To protect their economies, countries increasingly demand obligatory\n@ cybersecurity measures. This also applies to compliance with existing regulation. This layer may\nalso include privacy for those jurisdictions that have corresponding regulations in place.\nEthics and social responsibility: Long seen as a “nice to have,” ESG is still largely voluntary but\n/Qz\\ is becoming increasingly regulated and a key decision factor for customers and investors. Every\n@& measure that exceeds obligatory responsibilities conveys dedication and trust. When pursuing\n) their sustainability initiatives, 31% of European organizations see increasing brand value and trust\nas a key driver.\nCompanies that adhere to the above are perceived to be trustworthy by consumers, business partners,\nand governments, enabling accelerated commerce, better collaboration in business ecosystems, and easier\ninteraction with authorities. As Figure 2 shows, these can translate into benefits such as better visibility and\ntransparency of processes, improved loyalty and enhanced reputation, stronger partner relationships, and\noverall operational efficiency.\nAt the same time, in a digital-first world that is becoming more complex and faster every day, holistic end-to-\nend trust must be underpinned by technology, with the ability to prove identity a key technology pillar.\nFigure 2: Necessary Elements and Technologies to Achieve End-to-End Trust\nMEASURE, LEARN, AND IMPROVE\nELEMENTS OUTCOMES BENEFITS\n« Risk o Difcmiel « Visibility and transparency\n« Compliance governance « Customer loyalty\n» Privacy « Ecosystem . Brand reputation\n« Security management « Enhanced partner relationships\n« Ethics + Trust-enabled . Operational efficiency\n« Sustainability COMMErCE « Security and privacy by design\nMEASURE, LEARN, AND IMPROVE\nTECHNOLOGY UNDERPINNING TRUST\n: fi : Dat : Threat\naq g - 8 ata g rea\n@ Connectivity [\\@ e ety management management\nSource: IDC, 2022\n5 =IDC\n","contentLength":2468,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:36:20.844Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/gleifs-digital-strategy-for-the-lei/gleif-idc-research-creating-agile-resilient-global-trade-with-the-lei-and-vlei/2023-03-23_driving-business-with-trust-the-sustaining-role-of-secure-and-reliable-identities_final_public.pdf","content":"DRIVING BUSINESS WITH TRUST: THE SUSTAINING ROLE OF SECURE AND RELIABLE IDENTITIES\nL L\nReliable Identity Becomes the Heart of\nL L L L\nPhysical and Digital Interactions\n|dentities shape our lives. Think of how many IDs the average person already has to make sure they are eligible\nfor activities, purchases, or legal actions: driver's license, club membership, ecommerce platform login, email\naddresses, to name a few. The same applies to businesses: identities shape them and are an important way\nto reduce risk and enable business transactions — even more so in a globalized digital world. This is also why\nlegal entity identity and being identifiable anytime and anywhere becomes key for businesses.\nTable 1: Identity Relationship Types and Their Core Goals\nRELATIONSHIP TYPES CORE IDENTIFICATION GOALS\nB2E (business to employee) Identifying employees and authenticating their access to company\nresources\nB2C (business to consumer) Identifying customers for creditworthiness to lower risk and deliver\ncustomized customer experiences\nB2G&R (business to government/regulator) Identifying their business to governments and regulators worldwide,\ne.g., for tax or compliance\nB2B (business to business) Identifying business partners and suppliers, their compliance with\nimportant regulation, and their reliability\nBusiness identity is very complex. Public or regulatory authorities sometimes provide identities to businesses,\noften ending up with dozens of identity schemes for just one country. Businesses create identities to represent\nthemselves to customers or to manage online tools for customer or supplier relations. But it's not enough\njust to have identities. Identity crime and fraud has soared, with digitization and globalization sometimes\nJ y 8 8\ncausing huge financial damage and destroying trust. So, it's even more important to have secure and reliable\nidentities and ways to bridge across identity schemes. At the end of 2021, about 50% of companies interviewed\nby IDC worldwide said identity security is a source of operational savings, a linchpin for overall security, or a\ntechnology they wanted to spend more on. At the same time, 20% said identity security is a “necessary evil,” or\na “resource and time sink” forced on them by requirements and compliance, showing that identity security and\nmanagement can be difficult, especially when manual. The remaining 30% said it's a trade-off — useful as long\nas it's constrained and well managed. Too little identity security puts businesses in danger, but too much may\nprohibit any business at all.\nGlobal trade financing offers a good example. On one hand, fraud is a reason why global banks often decline\ntrade finance and loan requests especially for SMEs in emerging markets, as these pose more risk, harming\nglobal trade and inclusion. On the other hand, the number of regulatory hurdles (e.g., for AML/CFT/KYC due\ndiligence), associated costs, and lack of international standardization for corporate identities to eventually\nreduce risk make interactions less profitable, resulting in less business (or even none at all). Reliable and secure\nidentities are vital for physical and digital business interactions, but the way they are provided, managed, and\nverified needs to evolve to become easier, more secure, and more efficient.\nFor about\nof organizations,\n, Or a technology they want to spend more on.\nSource: IDC Security Identity Survey, September 2021\ne i : =IDC\n","contentLength":3437,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:36:20.844Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/gleifs-digital-strategy-for-the-lei/gleif-idc-research-creating-agile-resilient-global-trade-with-the-lei-and-vlei/2023-03-23_driving-business-with-trust-the-sustaining-role-of-secure-and-reliable-identities_final_public.pdf","content":"DRIVING BUSINESS WITH TRUST: THE SUSTAINING ROLE OF SECURE AND RELIABLE IDENTITIES\nIdentity and Digital Trust — A Hot Growth\nMarket\nIdentity and digital trust (IDT) is a technology market with big growth ahead of it. IDC forecasts double-digit\ngrowth worldwide and for all global regions in the coming years.\nFigure 3: Identity and Digital Trust Software Spending, 2022-2026\n. Worldwide consisting of: . APJ . EMEA . Americas CAGR = five-year average\nCAGR\n17%\n$31.7B\nCAGR\n$19.6B\n20%\n$17.2B\n$9.7B\nCAGR\n$7.5B\n14%\n$4.8B\nCAGR\n$4.7B\n$2.7B 15%\n2022 2026\nSource: Worldwide ICT Spending Guide Enterprise and SMB by Industry, January 2023\nThe IDT market will remain hot for the foreseeable future due to the soaring demand in B2C and B2B identity\nmanagement. Most companies focus their spending on employee identity management, but consumer identity\nmanagement is catching up. IDC believes there is not enough awareness of B2B identity management in terms\nof legal entity identities, though there are lots of potential benefits, such as digitization of manual and paper-\nbased business processes and fraud reduction and prevention. IDC believes that when these benefits are more\nwidely recognized or when fraud damages become too painful, the market will gain significant traction.\n7 =IDC\n","contentLength":1280,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:36:20.844Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/gleifs-digital-strategy-for-the-lei/gleif-idc-research-creating-agile-resilient-global-trade-with-the-lei-and-vlei/2023-03-23_driving-business-with-trust-the-sustaining-role-of-secure-and-reliable-identities_final_public.pdf","content":"DRIVING BUSINESS WITH TRUST: THE SUSTAINING ROLE OF SECURE AND RELIABLE IDENTITIES\nAt the same time, current technological developments are driving investment:\nA zero-trust approach (“never trust, always verify”) is set to become the default for\ncybersecurity. Instead of trusting known devices, users, or internal networks by default, a zero-\ntrust approach always requests strong identity verification. It's also important for supply chains\nand partner ecosystems, as it helps to secure data movement, accelerate information exchange,\nand improve business interactions. For 79% of European organizations zero trust is therefore a\ntop priority, with a defined strategy or at least incorporated in developments and initiatives where\npossible.\nInteroperability and standardization are needed to foster national and international\nuse of identities and credentials and mitigate silos. An important goal is to make solutions lean and\neasily accessible to be attractive for all organizations, especially SMEs and companies in developing\ncountries, which account for a large part of the global economy and trade. International\ninstitutions and foundations such as the ICC Digital Standards Initiative are taking the first steps to\nCreate open standards that can be globally utilized.\nDecentralized public key infrastructures enable verification of digital identities\nand credentials without the need to exchange personal data. Decentralized identities (DIDs) and\nremote identity verification are the foundation of self-sovereign identities (SSIs) that enable users\nto control which exchange of (personal) data is needed to perform a task that requires identity\ninformation.\nfi 115 e ‘\n{ / Remember\n. \"r - o, 106N :\n7 A 0 6\n'} ‘i ” | m‘@w{\ne > — By /‘« }l\ne i ; =IDC\n","contentLength":1759,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:36:20.844Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/gleifs-digital-strategy-for-the-lei/gleif-idc-research-creating-agile-resilient-global-trade-with-the-lei-and-vlei/2023-03-23_driving-business-with-trust-the-sustaining-role-of-secure-and-reliable-identities_final_public.pdf","content":"DRIVING BUSINESS WITH TRUST: THE SUSTAINING ROLE OF SECURE AND RELIABLE IDENTITIES\nL L L L L L\n\nIdentities Are Vital for Agile and Resilient\nWorldwide Trade\nLet's go back to 2008. The world slid into a financial crisis, but underlying this was a crisis of identity and trust.\nA lack of trust among banks and between banks and businesses led to a slump in lending and to a harsh\neconomic slowdown. There was another crisis in 2020, in the shape of COVID-19. The pandemic had a major\nimpact on business and trade, and identity again played a huge role. COVID restrictions led to risk mitigation by\nfinancial institutions to stop loans and letters of credit to SMEs that had no trusted identity and were therefore\nautomatically less credible. The result was a larger than ever trade finance gap that has created new risks for\nglobal supply chains, threatened the very existence of SMEs around the world, and decelerated global trade,\nespecially by impacting developing countries’ economies and their purchasing power. Another problem with\nCOVID was the enormous new wave of fraud. In 2027 alone, the European Anti-Fraud Office (OLAF) identified\nmore than 1,250 suspicious traders selling medical products on ecommerce platforms. OLAF seized 100 million\nCOVID-related products — the tip of a giant trade fraud iceberg.\nAll these problems are caused by mismanagement of risk. According to IDC, 26% of European companies\nsay low business recognition of supplier risk is a severe barrier for effective supplier cyber-risk management\nin their organization. For an additional 47%, it's a moderate barrier. This is intensified by other supply chain\nchallenges such as a lack of supply chain visibility and agility, a lack of collaboration with external suppliers and\ncustomers, and a lack of digital competencies, limiting new business models.\nFigure 4: Current Gaps in Supply Chains That Are Likely to Be the Most Problematic in the\nFuture If Not Addressed\nLack of supply chain visibility and agility to see necessary changes in time to react to them effectively\nB 42%\nInability to get products to market fast enough\nD 36%\nRobust data analytics and insight intelligence\nD 36%\nLack of sufficient collaboration with external suppliers and/or customers\nD 34%\nLack of digital competencies limits the ability to transition the supply chain to new business models\nD 33%\nSource: IDC Supply Chain Survey, March 2022\nDue to the current economic uncertainty, businesses and supply chains must be more agile and resilient than\never before. To improve supply chain risk mitigation and resilience, companies are prioritizing measures such\nas supply chain agility, supply chain visibility, and global supplier diversification. They are also including supply\nchain partners in risk mitigation.\n\n0 =IDC\n","contentLength":2778,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:36:20.844Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-solutions/gleifs-digital-strategy-for-the-lei/gleif-idc-research-creating-agile-resilient-global-trade-with-the-lei-and-vlei/2023-03-23_driving-business-with-trust-the-sustaining-role-of-secure-and-reliable-identities_final_public.pdf","content":"DRIVING BUSINESS WITH TRUST: THE SUSTAINING ROLE OF SECURE AND RELIABLE IDENTITIES\nFigure 5: Top 3 Measures Worldwide to Mitigate Supply Chain Risk\n@\n.@. @\n@ O\nL - —-0-0-0-\nO\nImprove supply Improve supply Diversify supply\n\nchain agility chain visibility globally\nSource: IDC Supply Chain Survey, March 2022\nTo implement these measures, organizations need to:\no Know all current suppliers in the supply chain, direct and indirect\ne Maintain continuously monitor all supply chain participants and changes in their legal status quo, such as\n\nbankruptcy, changes in ownership, and compliance violations\n\ne Secure exchange of relevant information for coordination and collaboration\no Be able to add new suppliers worldwide as fast as possible\nSecure and reliable identities of legal entities and their representatives are at the core of all of these and are\na prerequisite for agile, resilient trade. They enable reliable identification of all suppliers in supply chains, can\nsupport zero trust in physical and digital trade, and can accelerate supplier onboarding without compromising\nsecurity.\nAnother burden for supply chains and trade is the rapid development of ESG legislation worldwide. Germany's\nSupply Chain Act (LKSG), for example, came into effect in January 2023, forcing companies to ensure ESG-\nrelated liabilities such as human rights and ecological protective measures in accordance with various UN social\ndevelopment goals in their supply chains. 64% of German organizations say supply chains are important or\ncritical to implement ESG initiatives. Similar legislation exists or is planned in other countries, such as the U.S,,\nCanada, Brazil, France, the UK., and Australia. The EU has an advanced draft for a supply chain law with severe\nliabilities that could come into effect in 2025. 37% of worldwide organizations think that improving sustainability\nacross the supply chain has a significant impact on organizations' sustainability goals. Again, identity plays a\nvital role because companies need to identify all their suppliers and related entities to check sustainability\ncompliance.\n© IDC 2023 10 éIDC\n","contentLength":2123,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:36:20.844Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/global-lei-index/lei-statistics/2022-07-19_lei_statistics_dashboard-dictionary_v1.1.pdf","content":"O:GLEIF> rotatun ol st\nLE| Statistics Dashboard\nData Dictionary\n","contentLength":64,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:36:38.845Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/global-lei-index/lei-statistics/2022-07-19_lei_statistics_dashboard-dictionary_v1.1.pdf","content":"About this Document\nThis document defines formulas and pseudo code for metrics in the Global LEI System Statistics\ndashboard.\nChange History\nThis section records the history of all changes to this document.\n2022-07-19 1.1 Updating the CDF version GLEIF\n2020-12-01 1.0 First version of the data dictionary GLEIF\npublished to LEI Statistics website\na. Terms\nJurisdiction The jurisdiction of legal The field in CDF 3.1 which\nformation and registration of | refers to Legallurisdiction\nthe entity\nLEl issuer An organization authorized to | The field in CDF 3.1 which\nissue LEls to legal entities, It refers to ManagingLOU\nincludes only Accredited LOUs\nLEl issuer’s name The short name of the LEI Refers to internal reference\nissuer data\nLEI Statistics Dashboard Data Dictionary Page 2 of 9\n@ Public Version 1.1\n2022-07-19_LEI_Statistics_Dashboard_Dictionary_v1.1 2022-07-19\n","contentLength":870,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:36:38.846Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/global-lei-index/lei-statistics/2022-07-19_lei_statistics_dashboard-dictionary_v1.1.pdf","content":"Region Geographical region that is\ndefined by UNSD\n(https://unstats.un.org/unsd/\nmethodology/m49/)\nb1. Definitions for level 1 report metrics\nTerm Total LEI\nDescription The total number of LEls issued from the LEI File.\nPseudo Code IF LEl is not unique THEN KEEP LElI WITH RegistrationStatus = ISSUED\nTHEN\nCOUNT(UNIQUE(LEI)) WHERE RegistrationStatus IN [“ISSUED”,\n“LAPSED”, “PENDING_TRANSFER\"”, “PENDING_ARCHIVAL”,\n“RETIRED”] IF LEI IN (LEI file) AND initialRegistrationDate > 2012-01-\n01\nTerm Active LEI\nDescription The number of LEIs for active legal entities from the LEI File.\nPseudo Code COUNT(LEI) WHERE RegistrationStatus IN [“ISSUED”, “LAPSED”,\n“PENDING_TRANSFER”, “PENDING_ARCHIVAL”] and\nEntity.Status = “ACTIVE” IF LEI IN (Total LEl file)\nTerm Monthly LEI Growth Rate\nDescription Percentage of Newly Registered LEls in the last month.\nFormula Number of Newly Registered LEIs in the last month\nNumber of Active LEI in the month before last\nPseudo Code for the IF LEI' IN current day file AND LEI NOT IN (current day — 1 day) file\nnumber of Newly\nLEI Statistics Dashboard Data Dictionary Page 3 of 9\n@ Public Version 1.1\n2022-07-19_LEI_Statistics_Dashboard_Dictionary_v1.1 2022-07-19\n","contentLength":1192,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:36:38.846Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/global-lei-index/lei-statistics/2022-07-19_lei_statistics_dashboard-dictionary_v1.1.pdf","content":"Registered LEls in the THEN COUNT(LEI) between month start date and month end date\nlast month\nPseudo Code for the IF day equals “month before last end date”\nnumber of Active LEIs )\nin the month before THEN COUNT(Active LEI)\nlast\nTerm LEI Renewal Rate\nDescription The percentage of the LEls which renewed in the last one year\namong the LEIs which had at least one renewal event to date.\nFormula Number of Active LEIs renewed in the last one year\nNumber of Active LEIs having at least one renewal event to date\nNumber of Active LEIs | IF (NextRenewalDate) BETWEEN (“last quarter end date”) AND\nrenewed in the last one | (\"last quarter end date\" + 1 year) AND (InitialRegistration.Date)\nyear < \"last quarter end date\" — 1 year) AND and LEI IN (Active and\nverified LEI file)\nTHEN COUNT (LEI)\nPseudo Code for Total | IF (InitialRegistration.Date) < \"last quarter end date\" — 1 year)\nActive LEls having at and LEI IN (Active LEI file)\nleast 1 renewal event\nTHEN COUNT (LEI)\nTerm Concentration Score by jurisdiction (competition amongst LEI\nissuers)\nDescription The degree of competition between LEl issuers in a jurisdiction.\nThe concept of calculation is the Herfindahl-Hirschman Index\n(HHI) where a score of more than 50 refers to a less competitive\nmarket. Here jurisdictions having more than 1000 LEls in the\nqguarter before last are considered.\nLEI Statistics Dashboard Data Dictionary Page 4 of 9\n@ Public Version 1.1\n2022-07-19_LEI_Statistics_Dashboard_Dictionary_v1.1 2022-07-19\n","contentLength":1481,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:36:38.846Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/global-lei-index/lei-statistics/2022-07-19_lei_statistics_dashboard-dictionary_v1.1.pdf","content":"Formula\nSj = Zk=1...n Mjk 2\nWhere,\nSj= concentration score of jurisdiction j\nn = number of LEl issuer in a given jurisdiction\nMik = market share of an LEl issuer k in the jusrisdiction j\nExample There are three LEl issuers in UK and the corresponding market\nshares are 70%, 27% and 3%. Hence, the concentration score of\nUK=0.72+0.272 + 0.032 = 0.56 or 56%\nTerm Concentration Score by LEl issuers\nDescription The degree of market concentration by an LEl issuer. The\nconcept of calculation is the Herfindahl-Hirschman Index (HHI)\nwhere a score of more than 50 refers to LEl issuers\nconcentrating more in one jurisdiction. Here LEl issuers having\nmore than 1000 LEls in the month before last are considered.\nFormula\nSj = Zk=1...n Mjk 2\nWhere,\nSj= concentration score of LEl issuer j\nn = number of jurisdictions operated by the LEl issuer\nMi = jurisdictional share of an LEl issuer j in the jurisdiction k\nExample There are three jurisdictions one LEl issuer operates in, and the\ncorresponding jurisdictional shares are 70%, 27% and 3%.\nHence, the concentration score of the LEl issuer =0.72 + 0.272 +\n0.032=0.56 or 56%\nLEI Statistics Dashboard Data Dictionary Page 5 of 9\n@ Public Version 1.1\n2022-07-19_LEI_Statistics_Dashboard_Dictionary_v1.1 2022-07-19\n","contentLength":1253,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:36:38.846Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/global-lei-index/lei-statistics/2022-07-19_lei_statistics_dashboard-dictionary_v1.1.pdf","content":"Term Percentage of Fully Corroborated LEls\nDescription Ratio of Fully Corroborated LEls to Active LEls\nFormula Number of Active LEIs that are Fully Corroborated\nNumber of Active LEIs\nPseudo Code for Active | IF ValidationSources = \"FULLY_CORROBORATED\" and LEl in\nLEls that are fully (Active LEI file)\ncorroborated\nTHEN COUNT (LEI)\nb 2. Definitions for level 2 report metrics\nDescription Legal entites reported ultimate parents having an LEI\nPseudo Code IF LEl in (relationship record file) AND EndNodelDType = “LEI”\nAND RelationshipType = “IS_ULTIMATELY_CONSOLIDATED_BY”\nAND\nrelationship.status = ACTIVE AND relationship.registration.status\nIN (PUBLISHED, LAPSED, PENDING TARNSFER, PENDING\nARCHIVAL)\nTHEN COUNT(UNIQUE(LEI))\nDescription Legal entites reported direct parents having an LEI\nPseudo Code IF LEl in (relationship record file) AND EndNodelDType = “LEI”\nAND RelationshipType = “IS_DIRECTLY_CONSOLIDATED_BY”\nAND\nrelationship.status = ACTIVE AND relationship.registration.status\nIN (PUBLISHED, LAPSED, PENDING TARNSFER, PENDING\nARCHIVAL)\nTHEN COUNT(UNIQUE(LEI))\nLEI Statistics Dashboard Data Dictionary Page 6 of 9\n@ Public Version 1.1\n2022-07-19_LEI_Statistics_Dashboard_Dictionary_v1.1 2022-07-19\n","contentLength":1206,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:36:38.846Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/global-lei-index/lei-statistics/2022-07-19_lei_statistics_dashboard-dictionary_v1.1.pdf","content":"Description Legal entities reported having no ultimate parent according to the\ndefinition used\nPseudo Code | IF (ExceptionCategory from reporting exceptions file) =\n\"ULTIMATE_ACCOUNTING_CONSOLIDATION_PARENT\"\nAND IF child LEl is not unique AND different exception reason for the\nsame LEI THEN DELETE LEI\nAND (ExceptionReason from exception reason file) =\n[\"NATURAL_PERSONS\",\"NON_CONSOLIDATING\",\"NO_KNOWN_PERSON\"]\nTHEN COUNT (UNIQUE(LEI))\nDescription Legal entities reported having no direct parent according to the\ndefinition used\nPseudo Code | IF (ExceptionCategory from reporting exceptions file) =\n\"DIRECT_ACCOUNTING_CONSOLIDATION_PARENT\"\nAND IF child LEl is not unique AND different exception reason for the\nsame LEI THEN DELETE LEI\nAND (ExceptionReason from exception reason file) =\n[\"NATURAL_PERSONS\",\"NON_CONSOLIDATING\",\"NO_KNOWN_PERSON\"]\nTHEN COUNT (UNIQUE(LEI))\nDescription Legal entities reported ultimate parents who do not have an LEI\nPseudo Code IF (ExceptionCategory from exception file) =\n\"ULTIMATE_ACCOUNTING_CONSOLIDATION_PARENT\"\nAND IF child LEl is not unique AND different exception reason for\nthe same LEI THEN DELETE LEI\nAND (ExceptionReason from exception reason file) = \"NO_LEI\"\nTHEN COUNT (UNIQUE(LEI))\nLEI Statistics Dashboard Data Dictionary Page 7 of 9\n@ Public Version 1.1\n2022-07-19_LEI_Statistics_Dashboard_Dictionary_v1.1 2022-07-19\n","contentLength":1363,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:36:38.846Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/global-lei-index/lei-statistics/2022-07-19_lei_statistics_dashboard-dictionary_v1.1.pdf","content":"Description Legal entities reported direct parents who do not have an LEI\n\nPseudo Code IF (ExceptionCategory from exception file) =\n\"DIRECT_ACCOUNTING_CONSOLIDATION_PARENT\"\n\nAND IF child LEl is not unique AND different exception reason\nfor the same LEI THEN DELETE LEI\n\nAND (ExceptionReason from exception reason file) = \"NO_LEI\"\nTHEN COUNT (UNIQUE(LEI))\n\nDescription Legal entities’ ultimate parent relationship information is non-\npublic and therefore creates obstacles to releasing this\ninformation\n\nPseudo Code IF (ExceptionCategory from exception file) =\n\"ULTIMATE_ACCOUNTING_CONSOLIDATION_PARENT\"\n\nAND IF child LEl is not unique AND different exception reason\nfor the same LEI THEN DELETE LEI\n\nAND (ExceptionReason from exception reason file) =\n“NON_PUBLIC”\n\nTHEN COUNT (UNIQUE(LEI))\n\nDescription Legal entities’ direct parent relationship information is non-\npublic and therefore creates obstacles to releasing this\ninformation\n\nPseudo Code IF (ExceptionCategory from exception file) =\n\"DIRECT_ACCOUNTING_CONSOLIDATION_PARENT\"\n\nAND IF child LEl is not unique AND different exception reason\nfor the same LEI THEN DELETE LEI\nAND (ExceptionReason from exception reason file) =\n“NON_PUBLIC”\nLEI Statistics Dashboard Data Dictionary Page 8 of 9\n@ Public Version 1.1\n2022-07-19_LEI_Statistics_Dashboard_Dictionary_v1.1 2022-07-19\n","contentLength":1331,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:36:38.846Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/global-lei-index/lei-statistics/2022-07-19_lei_statistics_dashboard-dictionary_v1.1.pdf","content":"THEN COUNT (UNIQUE(LEI))\nb 3. Definitions of metrics for new ROC policies implementation\nTerm Government entities\nDescription The number of LEIs that is identified as government entities\nPseudo Code IF EntityCategory = \"RESIDENT_GOVERNMENT_ENTITY\" and LEl in\n(Active LEI file)\nTHEN COUNT (LEI)\nTerm International organizations\nDescription The number of LEIs that is identified as international organizations\nPseudo Code IF EntityCategory = \"INTERNATIONAL_ORGANIZATION\" and LEl in\n(Active LEI file)\nTHEN COUNT (LEI)\nDescription Legal entities reported fund relationship\nPseudo Code IF LEl in (relationship record file) AND EndNodelDType = “LEI”\nAND RelationshipType IS IN [“IS_FUND-MANAGED_BY”,\n“IS_SUBFUND_OF”, “IS_FEEDER_TO”]\nAND\nrelationship.status = ACTIVE AND relationship.registration.status\nIN (PUBLISHED, LAPSED, PENDING TARNSFER, PENDING\nARCHIVAL)\nTHEN COUNT(UNIQUE(LEI))\nLEI Statistics Dashboard Data Dictionary Page 9 of 9\n@ Public Version 1.1\n2022-07-19_LEI_Statistics_Dashboard_Dictionary_v1.1 2022-07-19\n","contentLength":1017,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:36:38.846Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/global-lei-index/download-global-lei-system-business-reports/2022-07-19_background_information_on_global_lei_system_report_v1.2.pdf","content":"OGLEIF ) ik g\n\nBackground Information on Global LEI\nSystem Business Report\n\nPublic\n\nVersion 1.2\n\n2022-07-19\n","contentLength":108,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:36:58.424Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/global-lei-index/download-global-lei-system-business-reports/2022-07-19_background_information_on_global_lei_system_report_v1.2.pdf","content":"Contents\nSN 143 o Yo 11 o1 T o Y\n2. State of play of LEl issuance and LEI growth potential ............................ 4\n3. Competition in the Global LEI System........cccceeuireecernireecrenceenceenccrencenneees 4\n4. LElIrenewal rates.....cccccciiieueiiiiienniiiiieniiiiieeiniieeiieeieeisisss D\n5. Level 1 reference data corroboration ........cccceeerreeeciiiineciininniiinneeiineeenes 5\n6. Statistics on the reporting of parent information by legal entities .......... 6\n7. Statistics on the new ROC policies implementation........cccceeeeeeeceenieeneees 7\nO Background Information on Global LE| System Business Report Page 2 of 7\n@ Public Version 1.2\n2022-07-19_Background_information_on_global_lei_system_report_v1.2.docx 2022-07-19\n","contentLength":738,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:36:58.424Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/global-lei-index/download-global-lei-system-business-reports/2022-07-19_background_information_on_global_lei_system_report_v1.2.pdf","content":"About this Document\nThis document describes concepts unique to the Global LEI System referenced with data included in\nthe quarterly Global LEI System Business Reports.\nChange History\nThis section records the history of all changes to this document.\n2022-07-19 1.2 ROC policies update GLEIF\nWhere changes are made for clarity and reading ease only and no change is made to the meaning or\nintention of this document, the version number will be increased by 0.1.\nWhere significant changes are made to this document, the version number will be incremented by\n1.0.\nBackground Information on Global LEI System Business Report Page 3 of 7\nGLEIF' Public Version 1.2\n2022-07-19_Background_information_on_global_lei_system_report_v1.2.docx 2022-07-19\n","contentLength":741,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:36:58.424Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/global-lei-index/download-global-lei-system-business-reports/2022-07-19_background_information_on_global_lei_system_report_v1.2.pdf","content":"1.Introduction\nThe Global Legal Entity Identifier Foundation (GLEIF) publishes quarterly reports, which highlight key\ndevelopments relevant to the adoption of the Legal Entity Identifier (LEI). Specifically, the reports\nassess annual growth and renewal expectations, evaluate the level of competition between LEI\nissuing organizations operating in the Global LEI System and analyse LEI renewal rates and reference\ndata corroboration. In addition, the reports deliver statistics on direct and ultimate parent\ninformation provided by legal entities. After the implementation of the new ROC policies, the reports\nalso provide summary statistics on new entity categories and fund relationship.\nThe quarterly reports refer to concepts and definitions unique to the Global LEI System. To facilitate\nan easy understanding of the reports, this document summarizes relevant concepts. Detailed\ninformation on the concepts summarized here are available on the GLEIF website.\n2.State of play of LEl issuance and LEI growth\npotential\nGLEIF, in partnership with the Regulatory Oversight Committee and the LEl issuing organizations, is\non a journey to increase the rate of LEl adoption so that in the future, the Global LEI Index will\ncapture an increasing number of entities engaging in financial transactions globally, providing a 360-\ndegree view.\nThe Global LEI Index contains historical and up-to-date LEI records including related reference data in\none authoritative source. The reference data provides information on a legal entity identifiable with\nan LEl. The Global LEI Index is the only global online source that offers open, standardized, and high-\nquality legal entity reference data.\nThe quarterly Global LEI System Business Reports detail:\n1. Total number of LEls issued globally and recent issuance trends.\n2. Countries with the most LEls and high rates of new LEl issuance.\n3. Important activity by LEl issuers.\n4. Overall LEI growth expectation for the year.\n5. Statistics on direct and ultimate parent information.\n6. Statistics on the new ROC policies implementation.\n3.Competition in the Global LEI System\nBackground Information on Global LEI System Business Report Page 4 of 7\n@ Public Version 1.2\n2022-07-19_Background_information_on_global_lei_system_report_v1.2.docx 2022-07-19\n","contentLength":2288,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:36:58.424Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/global-lei-index/download-global-lei-system-business-reports/2022-07-19_background_information_on_global_lei_system_report_v1.2.pdf","content":"LEl issuing organizations — also referred to as Local Operating Units (LOUs) — supply registration,\nrenewal and other services, and act as the primary interface for legal entities wishing to obtain an\nLEI. A legal entity is not limited to using an LEl issuer headquartered in its own country; instead, it can\nuse the registration services of any LOU that is accredited and qualified to validate LEI registrations\nwithin its authorized jurisdiction. The Global LEI System is designed to encourage competition\nbetween LEl issuers to the benefit of legal entities seeking to obtain an LEI. The fees charged for the\nissuance and maintenance of an LEl are entirely a matter for the LEI issuing organizations and must\nbe cost-based.\n\nThe quarterly Global LEI System Business Reports detail:\n\n1. Least competitive markets with more than 1,000 LEIs based on the number of LEl issuers\nproviding services in this country.\n\n2. Most competitive markets with more than 1,000 LEIs based on the number of LEl issuers\nproviding services in this country.\n\n3. Alegal entity is free to change the LEl issuer responsible for managing its LE|, i.e. to transfer\nits LEl and related reference data from the former LEl issuer (transfer out) to the chosen\nissuer (transfer in). Starting with the second report published in July 2017, we show the LEI\nissuers that have the most transfer activity.\n\n4.LEl renewal rates\n\nRenewal means that the reference data connected to an LEl is re-validated annually by the managing\nLEl issuer against a third party source. Legal entities that have obtained an LEI are obliged to renew it\nregularly. This is a key feature that distinguishes the LEI from other identifiers for the following\nreasons: Firstly, the principle of renewal is essential to ensure that the information available on a\nlegal entity with an LEl is accurate and up to date. No other global and open entity identification\nsystem has committed to a comparable strict regime of regular data verification. Secondly, the users\nof the data are aware of whether the information related to a specific LEl has been re-validated\nrecently or not. The Global LEI System is unique in providing absolute transparency on the timeframe\nwhen data has last been verified. If a legal entity fails to renew and re-certify its LEI registration by\nthe ‘Next Renewal Date’ stated with its LEI reference data, then the registration status of this LEI will\nbe set from ‘issued’ to ‘lapsed’.\n\nThe quarterly Global LEI System Business Reports detail:\n\n1. Total number of LEIs duly renewed versus the total number of LEIs that are supposed to\nrenew globally.\n\n2. Countries with more than 1,000 LEIs featuring the highest renewal rates.\n\n3. Countries with the highest rates of non-renewed LEls.\n\n5.Level 1 reference data corroboration\nBackground Information on Global LEI System Business Report Page 5 of 7\n@ Public Version 1.2\n2022-07-19_Background_information_on_global_lei_system_report_v1.2.docx 2022-07-19\n","contentLength":2962,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:36:58.424Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/global-lei-index/download-global-lei-system-business-reports/2022-07-19_background_information_on_global_lei_system_report_v1.2.pdf","content":"The business card information available with the LEI reference data, e.g. the official name of a legal\nentity and its registered address, is referred to as ‘Level 1’ data. It provides the answer to the\nquestion of ‘who is who'. The LEI-Common Data File (CDF) format defines how LEl issuing\norganizations report their LElI and Level 1 reference data. The CDF format specifies the field\n‘ValidationSources’. If the value included with this field in the publicly available LEI data record states\n‘Fully Corroborated LEI’, this means: Based on the validation procedures in use by the LEl issuer\nresponsible for managing this LEI record, there is sufficient information contained in authoritative\npublic sources to corroborate the information that the legal entity has provided for the record.\nThe quarterly Global LEI System Business Reports detail:\ne Percentage of total LEls issued that are fully corroborated by the LEl issuer.\n6.Statistics on the reporting of parent\ninformation by legal entities\nThe business card information available with the LEI reference data, e.g. the official name of a legal\nentity and its registered address, is referred to as ‘Level 1’ data. It provides the answer to the\nquestion of ‘who is who'. In May 2017, the process of enhancing the LEI data pool, by including ‘Level\n2’ data to answer the question of ‘who owns whom’, began. This data allows the identification of the\ndirect and ultimate parents of a legal entity and vice versa, in order that the entities owned by\nindividual companies can be researched.\nThe quarterly Global LEI System Business Reports detail:\n\n1. Records related to direct and ultimate parents that have an LEI: If the direct and / or\nultimate parent of an LEI registrant has obtained an LEI, the following applies: The child legal\nentity will be obliged to provide the LEI, respectively, of its direct and ultimate parent to the\nLEl issuing organization. The ‘Relationship Record Common Data File format’ applies to\nrelationship records for LEI registrants whose direct and ultimate parents have obtained an\nLEIL. The quarterly Global LEI System Business Reports identify the percentage of reported\nrelationship records where parents have an LEI. In addition, the reports state the number of\nchild entities associated with a parent entity that has an LEIl. The reports also indicate the\npercentage of fully corroborated relationship records. This means the relationship data\nprovided by the child entity has been validated against an explicit relationship statement\nfound in key sources (e.g. consolidated financial statements).\n\n2. Records related to direct and ultimate parents that do not have an LEl: when the parent\ndoes not consent to obtain an LEIl or to authorize its “child entity” to obtain an LEl on its\nbehalf. The quarterly Global LEI System Business Reports identify the percentage of reported\nrelationship records where parents do not have an LEI.\n\n3. Records related to legal entities that do not have a direct or ultimate parent: The quarterly\nGlobal LEI System Business Reports identify the percentage of LEl registrants that do not\nhave a direct or ultimate parent according to the definition used for Level 2 data collection.\nThis will include for instance (i) the entity is controlled by natural person(s) without any\nintermediate legal entity meeting the definition of parent in the Global LEI System; (ii) the\n\nBackground Information on Global LEI System Business Report Page 6 of 7\n@ Public Version 1.2\n2022-07-19_Background_information_on_global_lei_system_report_v1.2.docx 2022-07-19\n","contentLength":3566,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:36:58.424Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/global-lei-index/download-global-lei-system-business-reports/2022-07-19_background_information_on_global_lei_system_report_v1.2.pdf","content":"entity is controlled by legal entities not subject to preparing consolidated financial\nstatements (given the definition of parents in the Global LEI System); (iii) there is no known\nperson controlling the entity (e.g., diversified shareholding).\n\n4. Records related to legal entities whose relationship information is non-public and\ntherefore creates obstacles to releasing this information: Whenever the relationship\ninformation is non-public and therefore creates obstacles to releasing this information. An\nentity is not required to provide non-public relationship information in order to register or\nrenew an LEI.\n\n7.Statistics on the new ROC policies\nimplementation\n\nThe new ROC policies identify resident government entities and international organizations as\n\nspecific entity categories.\n\nThe quarterly Global LEI System Business Reports detail:\n\n1. Number of government entities by quarter.\n\n2. Top 5jurisdictions reporting government entities.\n\n3. Number of international organizations by quarter.\n\n4. Top 5 jurisdictions reporting international organizations.\n\nThe new ROC policies also report fund relationship for fund entities. The quarterly Global LEI System\nBusiness Reports detail:\n\n1. Number of entities reporting fund relationship.\n\n2. Top 5jurisdictions of legal entities reporting fund relationship.\n\n3. Validation status of fund relationship reporting.\n\n4. Detailed fund relationship reporting categories.\n\nBackground Information on Global LEI System Business Report Page 7 of 7\n@ Public Version 1.2\n2022-07-19_Background_information_on_global_lei_system_report_v1.2.docx 2022-07-19\n","contentLength":1604,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:36:58.424Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/global-lei-index/download-global-lei-system-business-reports/2022-07-19_business-report-dictionary_v1.5.pdf","content":"O:GLEIF> Protecting digtal rust\nGlobal LEI System Business\nReporting Data Dictionary\n","contentLength":85,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:37:20.697Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/global-lei-index/download-global-lei-system-business-reports/2022-07-19_business-report-dictionary_v1.5.pdf","content":"About this Document\nThis document defines formulas and pseudo codes for reporting on Global LEI System Business\nReport.\nChange History\nThis section records the history of all changes to this document.\n2022-07-19 1.5 Updated level 2 reporting definitions GLEIF\nand new metrics regarding ROC\npolicies implementation.\n2019-10-28 14 Fifth version of the data dictionary GLEIF\nwith updated definitions of New\nIssuance, Lapsed LEls, Transfers in,\nand Transfers out.\n2019-01-10 1.3 Fourth version of the data dictionary | GLEIF\nwith updated definitions\n2018-05-18 1.2 Third version of the data dictionary GLEIF\nwith updated definitions\n2017-11-14 1.1 Second version of the data dictionary | GLEIF\ncontaining the level 2 reporting\ndefinitions for the first time\n2017-04-12 1.0 First version of the data dictionary GLEIF\npublished to GLEIF website\nGlobal LEI System Business Reporting Data Dictionary Page 2 of 11\n@ Public Version 1.5\n2022-07-19_business-report-dictionary_v1.5.docx 2022-07-19\n","contentLength":985,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:37:20.697Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/global-lei-index/download-global-lei-system-business-reports/2022-07-19_business-report-dictionary_v1.5.pdf","content":"Pseudo Code IF LEl in (relationship record file) AND EndNodelDType = “LEI”\n\nAND RelationshipType IS IN [“IS_FUND-MANAGED_BY”,\n“IS_ SUBFUND_OF”, “IS_FEEDER_TQ”]\nAND\nrelationship.status = ACTIVE AND relationship.registration.status\nIN (PUBLISHED, LAPSED, PENDING TARNSFER, PENDING\nARCHIVAL)\nTHEN COUNT(UNIQUE(LELI))\n\nGlobal LEI System Business Reporting Data Dictionary Page 11 of 11\n\n@ Public Version 1.5\n2022-07-19_business-report-dictionary_v1.5.docx 2022-07-19\n","contentLength":463,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:37:20.697Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/global-lei-index/download-global-lei-system-business-reports/2022-07-19_business-report-dictionary_v1.5.pdf","content":"a. Terms\nCountry The jurisdiction of legal The field in CDF 3.1 which\nformation and registration of | refers to Legallurisdiction\nthe entity\nLEl issuer An organization authorized to | The field in CDF 3.1 which\nissue LEIs to legal entities. It refers to ManagingLOU.\nincludes only Accredited LOUs\nLEl issuer’s name The short name of the LEI Refers to internal reference\nissuer data\nb1. Definitions for level 1 report metrics\nTerm Total LEI\nDescription The total number of LEls issued from the LEI File.\nPseudo Code IF LEl is not unique THEN KEEP LElI WITH RegistrationStatus = ISSUED\nTHEN\nCOUNT(UNIQUE(LEI)) WHERE RegistrationStatus IN [“ISSUED”,\n“LAPSED”, “PENDING_TRANSFER”, “PENDING_ARCHIVAL”,\n“RETIRED”] IF LEI IN (LEI file) AND initialRegistrationDate > 2012-01-\n01\nTerm Active LEI\nDescription The number of LEIs for active legal entities from the LEI File.\nPseudo Code COUNT(LEI) WHERE RegistrationStatus IN [“ISSUED”, “LAPSED”,\n“PENDING_TRANSFER”, “PENDING_ARCHIVAL”] and\nEntity.Status = “ACTIVE” IF LEI IN (Total LEI file)\nGlobal LEI System Business Reporting Data Dictionary Page 3 of 11\n@ Public Version 1.5\n2022-07-19_business-report-dictionary_v1.5.docx 2022-07-19\n","contentLength":1177,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:37:20.697Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/global-lei-index/download-global-lei-system-business-reports/2022-07-19_business-report-dictionary_v1.5.pdf","content":"Term Active and verified LEI\nDescription The number of LEIs for active legal entities which are newly\nissued or, duly renewing the contract as of the File Date.\nPseudo Code COUNT(LEI) WHERE RegistrationStatus IN [“ISSUED”,\n“PENDING_TRANSFER”, “PENDING_ARCHIVAL”] and IF LEI IN\n(Active LEI file)\nTerm Quarterly LEI Growth Rate\nDescription Percentage of Newly Registered LEls in the last quarter.\nFormula Number of Newly Registered LEIs in the last quarter\nNumber of Active LEI in the quarter before last\nPseudo Code for the IF LEI IN current day file AND LEI NOT IN (current day — 1 day)\nnumber of Newly file\nRegistered LEls in the\nlast quarter THEN COUNT(LEI) between quarter start date and quarter end\ndate\nTerm LEI Renewal Rate\nDescription The percentage of the LEls which renewed in the last one year\namong the LEIs which had at least one renewal event to date.\nFormula Number of Active LEIs renewed in the last one year\nNumber of Active LEIs having at least one renewal event to date\nNumber of Active LEIs | IF (NextRenewalDate) BETWEEN (“last quarter end date”) AND\nrenewed in the last one | (\"|ast quarter end date\" + 1 year) AND (InitialRegistration.Date)\nyear < \"last quarter end date\" — 1 year) AND and LEI IN (Active and\nverified LEI file)\nTHEN COUNT (LEI)\nGlobal LEI System Business Reporting Data Dictionary Page 4 of 11\n@ Public Version 1.5\n2022-07-19_business-report-dictionary_v1.5.docx 2022-07-19\n","contentLength":1413,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:37:20.697Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/global-lei-index/download-global-lei-system-business-reports/2022-07-19_business-report-dictionary_v1.5.pdf","content":"Pseudo Code for Total | IF (InitialRegistration.Date) < \"last quarter end date\" — 1 year)\nActive LEIs having at and LEI IN (Active LEI file)\nleast 1 renewal event\nTHEN COUNT (LEI)\nTerm LEI Non-Renewal Rate\nDescription The percentage of the LEls which did not renew (Lapsed) in the\nlast one year among the LEIs which had at least one renewal\nevent to date.\nFormula Number of Active LEIs did not renew in the last one year\nNumber of Active LEIs having at least one renewal event to date\nPseudo Code for IF (NextRenewalDate) < “last quarter end date” and LEI IN\nLapsed LEls (Active file) OR (NextRenewalDate) > “last quarter end date”\nand LEI RegistrationStatus = “LAPSED”\nTHEN COUNT (LEI)\nTerm Concentration Score (competition amongst LEl issuers)\nDescription The degree of competition between LEl issuers in a jurisdiction.\nThe concept of calculation is the Herfindahl-Hirschman Index\n(HHI) where a score of more than 50 refers to a less competitive\nmarket. Here jurisdictions having more than 1000 LEls in the\nqguarter before last are considered.\nFormula\nSj = Zk=1...n Mjk 2\nWhere,\nSj= concentration score of jurisdiction j\nn = number of LEl issuer in a given jurisdiction\nGlobal LEI System Business Reporting Data Dictionary Page 5 of 11\n@ Public Version 1.5\n2022-07-19_business-report-dictionary_v1.5.docx 2022-07-19\n","contentLength":1319,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:37:20.697Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/global-lei-index/download-global-lei-system-business-reports/2022-07-19_business-report-dictionary_v1.5.pdf","content":"Mik = market share of an LEl issuer k in the jusrisdiction j\nExample There are three LEl issuers in UK and the corresponding market\nshares are 70%, 27% and 3%. Hence, the concentration score of\nUK=0.72+0.27?+0.032=0.56 or 56%\nTerm Percentage of Fully Corroborated LEls\nDescription Ratio of Fully Corroborated LEls to Active LEls\nFormula Number of Active LEIs that are Fully Corroborated\nNumber of Active LEIs\nPseudo Code for Active | IF ValidationSources = \"FULLY_CORROBORATED\" and LEl in\nLEls that are fully (Active LEI file)\ncorroborated\nTHEN COUNT (LEI)\nDescription Transfers out of LEI\nPseudo Code IF ManagingLOU.LEI (in Active LEl file of the current day file) #\nManagingLOU.LEI (in Active LEI file of the (current day — 1 day)\nfile)\nTHEN COUNT (LEI) per ManagingLOU (in Active LEI file of the\nquarter before last) between quarter start date and quarter end\ndate\nDescription Transfers in of LEI\nPseudo Code IF ManagingLOU.LEI (in Active LEl file of the current day file) #\nManagingLOU.LEI (in Active LEI file of the (current day — 1 day)\nfile)\nGlobal LEI System Business Reporting Data Dictionary Page 6 of 11\n@ Public Version 1.5\n2022-07-19_business-report-dictionary_v1.5.docx 2022-07-19\n","contentLength":1195,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:37:20.697Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/global-lei-index/download-global-lei-system-business-reports/2022-07-19_business-report-dictionary_v1.5.pdf","content":"THEN COUNT (LEI) per ManagingLOU (in Active LEI file of last\nquarter) between quarter start date and quarter end date\nb 2. Definitions for level 2 report metrics\nDescription Legal entities reported level 2 data\nPseudo Code OUTER JOIN (LEls from relationship record file and LEls from\nreporting exceptions file)\nTHEN COUNT(UNIQUE(LEI)) WHERE COUNT(relationshipType or\nExceptionType per LEI)>1\nWHERE (relationshipType) IS NOT IN\n[“IS_INTERNATIONAL_BRANCH_OF”, “IS_FUND-MANAGED_BY”,\n“IS_SUBFUND_OF”, “IS_FEEDER_TO”]\nAND\nrelationship.status = ACTIVE AND relationship.registration.status\nIN (PUBLISHED, LAPSED, PENDING TARNSFER, PENDING\nARCHIVAL)\nDescription Legal entites reported ultimate parents having an LEI\nPseudo Code IF LEl in (relationship record file) AND EndNodelDType = “LEI”\nAND RelationshipType = “IS_ULTIMATELY_CONSOLIDATED_BY”\nAND\nrelationship.status = ACTIVE AND relationship.registration.status\nIN (PUBLISHED, LAPSED, PENDING TARNSFER, PENDING\nARCHIVAL)\nTHEN COUNT(UNIQUE(LEI))\nDescription Legal entites reported direct parents having an LEI\nGlobal LEI System Business Reporting Data Dictionary Page 7 of 11\n@ Public Version 1.5\n2022-07-19_business-report-dictionary_v1.5.docx 2022-07-19\n","contentLength":1201,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:37:20.697Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/global-lei-index/download-global-lei-system-business-reports/2022-07-19_business-report-dictionary_v1.5.pdf","content":"Pseudo Code IF LEl in (relationship record file) AND EndNodelDType = “LEI”\nAND RelationshipType = “IS_DIRECTLY_CONSOLIDATED_BY”\nAND\nrelationship.status = ACTIVE AND relationship.registration.status\nIN (PUBLISHED, LAPSED, PENDING TARNSFER, PENDING\nARCHIVAL)\nTHEN COUNT(UNIQUE(LEI))\nDescription Legal entities reported having no ultimate parent according to the\ndefinition used\nPseudo Code | IF (ExceptionCategory from reporting exceptions file) =\n\"ULTIMATE_ACCOUNTING_CONSOLIDATION_PARENT\"\nAND IF child LEl is not unique AND different exception reason for the\nsame LEI THEN DELETE LEI\nAND (ExceptionReason from exception reason file) =\n[\"NATURAL_PERSONS\",\"NON_CONSOLIDATING\",\"NO_KNOWN_PERSON\"]\nTHEN COUNT (UNIQUE(LEI))\nDescription Legal entities reported having no direct parent according to the\ndefinition used\nPseudo Code | IF (ExceptionCategory from reporting exceptions file) =\n\"DIRECT_ACCOUNTING_CONSOLIDATION_PARENT\"\nAND IF child LEl is not unique AND different exception reason for the\nsame LEI THEN DELETE LEI\nAND (ExceptionReason from exception reason file) =\n[\"NATURAL_PERSONS\",\"NON_CONSOLIDATING\",\"NO_KNOWN_PERSON\"]\nTHEN COUNT (UNIQUE(LEI))\nGlobal LEI System Business Reporting Data Dictionary Page 8 of 11\n@ Public Version 1.5\n2022-07-19_business-report-dictionary_v1.5.docx 2022-07-19\n","contentLength":1297,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:37:20.698Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/global-lei-index/download-global-lei-system-business-reports/2022-07-19_business-report-dictionary_v1.5.pdf","content":"Description Legal entities reported ultimate parents who do not have an LEI\nPseudo Code IF (ExceptionCategory from exception file) =\n\"ULTIMATE_ACCOUNTING_CONSOLIDATION_PARENT\"\nAND IF child LEl is not unique AND different exception reason for\nthe same LEI THEN DELETE LEI\nAND (ExceptionReason from exception reason file) = \"NO_LEI\"\nTHEN COUNT (UNIQUE(LEI))\n\nDescription Legal entities reported direct parents who do not have an LEI\n\nPseudo Code IF (ExceptionCategory from exception file) =\n\"DIRECT_ACCOUNTING_CONSOLIDATION_PARENT\"\n\nAND IF child LEl is not unique AND different exception reason\nfor the same LEI THEN DELETE LEI\n\nAND (ExceptionReason from exception reason file) = \"NO_LEI\"\nTHEN COUNT (UNIQUE(LEI))\n\nDescription Legal entities’ ultimate parent relationship information is non-\npublic and therefore creates obstacles to releasing this\ninformation\n\nPseudo Code IF (ExceptionCategory from exception file) =\n\"ULTIMATE_ACCOUNTING_CONSOLIDATION_PARENT\"\n\nAND IF child LEl is not unique AND different exception reason\nfor the same LEI THEN DELETE LEI\nAND (ExceptionReason from exception reason file) =\n“NON_PUBLIC”\nTHEN COUNT (UNIQUE(LEI))\nGlobal LEI System Business Reporting Data Dictionary Page 9 of 11\n@ Public Version 1.5\n2022-07-19_business-report-dictionary_v1.5.docx 2022-07-19\n","contentLength":1291,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:37:20.698Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/global-lei-index/download-global-lei-system-business-reports/2022-07-19_business-report-dictionary_v1.5.pdf","content":"Description Legal entities’ direct parent relationship information is non-\npublic and therefore creates obstacles to releasing this\ninformation\n\nPseudo Code IF (ExceptionCategory from exception file) =\n\"DIRECT_ACCOUNTING_CONSOLIDATION_PARENT\"\n\nAND IF child LEl is not unique AND different exception reason\nfor the same LEI THEN DELETE LEI\nAND (ExceptionReason from exception reason file) =\n“NON_PUBLIC”\nTHEN COUNT (UNIQUE(LEI))\n\nb 3. Definitions of metrics for new ROC policies implementation\n\nTerm Government entities\n\nDescription The number of LEIs that is identified as government entities\n\nPseudo Code IF EntityCategory = \"RESIDENT_GOVERNMENT_ENTITY\" and LEl in\n\n(Active LEI file)\nTHEN COUNT (LEI)\n\nTerm International organizations\n\nDescription The number of LEIs that is identified as international organizations\n\nPseudo Code IF EntityCategory = \"INTERNATIONAL_ORGANIZATION\" and LEl in\n\n(Active LEI file)\nTHEN COUNT (LEI)\nDescription Legal entities reported fund relationship\nGlobal LEI System Business Reporting Data Dictionary Page 10 of 11\n@ Public Version 1.5\n2022-07-19_business-report-dictionary_v1.5.docx 2022-07-19\n","contentLength":1128,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:37:20.698Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/global-lei-index/download-global-lei-system-business-reports/download-global-lei-system-business-report-q2-2023/2023-07-18-quarterly_business_report.pdf","content":"Global LEI System\nBusiness Report\nQ2 2023\n","contentLength":42,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:37:57.760Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/global-lei-index/download-global-lei-system-business-reports/download-global-lei-system-business-report-q2-2023/2023-07-18-quarterly_business_report.pdf","content":"Global LEI System Business Report | Summary | Q2 2023 | page 02 @\nGLEIF\nLEl issuance and LEI growth potential: State of play In the second quarter of 2023, the overall renewal rate was 59.4%, which Statistics on the reporting of parent information by legal entities\nis slightly higher than the previous quarter (59.1%). At the end of the\nAt the end of the second quarter of 2023, the total LEl population was quarter, 61.7% of all LEls were in good standing (previous quarter: 61.7%). In the second quarter of 2023, approximately 2.26 million LEI registrants\napproximately 2.31 million. Around 63,000 LEls were issued during this The renewal rate in the EU increased to 63.9% (previous quarter 63.1%). (previous quarter: 2.19 million), representing 98% of the total LEI\nquarter, compared to over 63,000 in the previous quarter. This represents In non-EU jurisdictions, it fell slightly to 51.8% (previous quarter: 52%). In population, reported information on direct and ultimate parents. 99.9%\na quarterly growth rate of 2.8% (previous quarter: 2.9%). the reporting period, Hungary (94.2%) demonstrated the highest renewal of those LEI registrants who obtained a newly issued LEI or renewed an\nrates. Other jurisdictions in the top five for renewal rates are Japan existing LEl in this quarter reported parent information.\nIn the second quarter, Saudi Arabia had the highest quarterly LEl growth (91.3%), Finland (86.7%), Liechtenstein (82.1%) and India (80.3%).\nrate at the jurisdiction level (12.1%), followed by India (8.3%), Sweden The five jurisdictions with the highest non-renewal rates include Saudi In the reporting period, the percentage of legal entities reporting a\n(7.8%), Tiirkiye (5.4%) and Iceland (5.1%). In Saudi Arabia, India and Arabia (77.6%), China (76.5%), Belize (71.4%), the Russian Federation direct parent with an LEl was 5%. 3% of legal entities reported a direct\nTurkiye, growth was primarily driven by regulatory requirements and (66.6%) and Thailand (64.8%). parent that does not have an LEI. 87% of legal entities reported no\ninitiatives. In Sweden, the growth was due to a change in practice by direct parent according to the definition used. 5% of legal entities’\nFinansinspektionen — the Swedish Financial Supervisory Authority (FSA) — LEl transfers among LEI Issuers relationship information is non-public and therefore creates obstacles\nregarding LEl obligation under the European Union’s revised Market in to releasing this information. The pattern is almost identical for ultimate\nFinancial Instruments Directive (MiFID Il), particularly within the insurance In the second quarter of 2023, KELER Central Depository Ltd. (KELER) parent reporting. In the previous quarter, reporting trends are also very\nindustry. terminated its operation. LEls managed by KELER were transferred to GS1 similar.\nAISBL in this quarter.\nCompetition in the Global LEI System Updates of Common Data File formats\nLevel 1 reference data corroboration\nThis report identifies the least and most competitive markets among those In March 2022, the Common Data File (CDF) formats were updated\nwith over 1,000 LEls, based on the number of LEIl issuers providing services The business card information available with the LEI reference data, such based on the Regulatory Oversight Committee (ROC) policies:\nin the jurisdiction (the most competitive markets are those with the most as the official name of a legal entity and its registered address, is referred e Legal Entity Events (formerly referred to as “Corporate Actions\") and\nLEl issuers per jurisdiction with similar market share). In the second to as ‘Level 1’ data. It defines ‘who is who’. The Level 1 data is considered Data History in the Global LEl System,\nquarter of 2023, China, the Netherlands, Slovenia, Poland and Turkiye fully corroborated if, based on the validation procedures in use by the LEI e Policy on Fund Relationships and Guidelines for the registration of\nwere the five least competitive markets, in descending order. The five issuer, there is sufficient information contained in authoritative public Investment Funds in the Global LEI System,\nmost competitive, also in descending order, were Malta, Portugal, sources to corroborate the information provided by the legal entity for o LE| Eligibility for General Government Entities Guidance Document.\nBulgaria, Norway and Marshall Islands. There is no significant overall the record. If this is not the case, or the legal entity is not required to file Following these updates, GLEIF has compiled a transition period report\nchange compared to the previous quarter. with a local register’ (e.g. fund or trust), the business card information on these new legal entity categories and the fund relationships reported\navailable with an LEIl record is classified as ‘entity-supplied only’. this quarter.\nLEl renewal rates\nIn the second quarter of 2023, the percentage of fully corroborated Level At the end of the second quarter of 2023, over 5,100 legal entities were\nThe annual renewal process ensures that both legal entities and LEI issuing 1 reference data within the entire LEI population increased slightly to identified as government entities (previous quarter: 5,000), and 32 legal\norganizations review and re-validate legal entity reference data at least 84.8% (previous quarter: 84.6%). entities were reported as international organizations (previous quarter:\nonce per year. The Global LEI System is unique in providing absolute 30). More than 123,000 legal entities reported their fund relationship\ntransparency regarding when entity data was last verified. structures (previous quarter: 107,000). Among those, 66.4% were funds\nmanaged by a main management entity, 33% were sub-funds to\numbrella funds, and 0.6% were feeder funds. Feeder funds are those\nthat are exclusively, or almost exclusively, invested in a single other\nfund or several other funds that have identical investment strategies.\nL Registration requirements vary based on jurisdiction. Please see the GLEIF Registration Authorities list for further detail:\nwww.gleif.org/en/about-lei/code-lists/gleif-registration-authorities-list © 2023 GLEIF and/or its affiliates. All rights reserved. | Release date 2023-07-18 | Version 1.0 | Public\n","contentLength":6246,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:37:57.760Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/global-lei-index/download-global-lei-system-business-reports/download-global-lei-system-business-report-q2-2023/2023-07-18-quarterly_business_report.pdf","content":"Global LEI System Business Report | | Page 11\nL\nCDF Update Transition Period: Level 2 Fund Relationship\nL ]\nTop 5 Jurisdictions of the Legal Entities for\nlegal entities reported Level 2 Fund Relationship Reporting | Fig.-1\nlevel 2 Fund Relationship\n21,27\ndata by the end of Q2 3 19,624\n2023\nI 9'2I” 7,693 7,376\nUnited States Luxembourg France Japan Ireland\nValidation status of the fund relationship | Fig.-2 Level 2 Fund Relationship Categories | Fig.-3\n12.9% 1.9% | 9f1 (:.6?)\n0 i S reeder 1o\nEntity Supplied Only Partially Corroborated\n54,984 (33.0%)\nIs Subfund Of\n110,736 (66.4%)\n85.2% Is Fund Managed By\nFully Corroborated\nDISCLAIMER: All figures of this Global LEI System Business Report are derived from the Global Legal Entity Identifier Foundation (GLEIF)‘s LEI-Common Data File (CDF) format version 3.1, Relationship Record (RR) CDF format version 2.1 and Reporting Exceptions format version 2.1 excluding LEIs with registration\nstatuses DUPLICATE, ANNULLED and RETIRED. While every care has been taken in the compilation of this information, GLEIF will not be held responsible for any loss, damage or inconvenience caused because of inaccuracy or error within the Global LEI System Business Report. The text and graphic content of the\nGlobal LEI System Business Report may be used, printed and distributed ONLY with the copyright information displayed (© Copyright Global Legal Entity Identifier Foundation (GLEIF)).\n© 2023 GLEIF and/or its affiliates. All rights reserved. | Release date 2023-07-18 | Version 1.0 | Public\n","contentLength":1534,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:37:57.760Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/global-lei-index/download-global-lei-system-business-reports/download-global-lei-system-business-report-q2-2023/2023-07-18-quarterly_business_report.pdf","content":"Global LEI System Business Report | 02 2023 | page 03 ©\n. ____________________________________________________________________________________________________________________]\nLevel 1 Data Report\nQ2 2023\n1\nActive LEIs\nTotal Number Of Active LEIls by Jurisdictions | Fig. 1\nPaag) ¥7 (L\nK 61 . o\n& 22 & Mg\n»\n’,‘- : 846 1,524 =\n' 374 4 k\n; 18,930 2 N\nb s 86,6 9 = L \"y\n) 254 [ '-\ni \\/ ‘& 1 : 193 205\nad ; 51 3 40 »\n= = 3\n3,298 1 c\n: 4,492 o ' T t 1\n5\n34,698 233%223 Sl 4 ,086 .\n447 14 27 4 6 3 1,572 .\niR 6\nA 820 97 2 50 7 1 6 2,304 3\n4\n6 17 1 184 96841 977 2\n1,727 6 14\n1 1\n445 1026 745\n9 71\n11 3,160\n. 1,266 185 66 65 108 282\nNon-Locale Countries\n721 510 ) .\nCountry ’,\nEuropean Union 4 3 g los\nOther Jurisdictions' 17\nUnited Nations 11\n© 2023 GLEIF and/or its affiliates. All rights reserved. | Release date 2023-07-18 | Version 1.0 | Public\n1. Other Jurisdictions refers to international organizations that do not have a legal jurisdiction.\n","contentLength":942,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:37:57.760Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/global-lei-index/download-global-lei-system-business-reports/download-global-lei-system-business-report-q2-2023/2023-07-18-quarterly_business_report.pdf","content":"Global LEI System Business Report | 02 2023 | page 04 ©\n|\nActive LEIs\nTotal LEI Trend-Top 5 Jurisdictions | Fig.-2 Top LEI Trend-Top 5 LEl Issuers | Fig.-3\n300K\n500K\n- - O °©\n260K G\\e\\e_§e\n240K 400K\n220K\n200K\n300K\n180K @——_W\n160K (9/@/@/@\n200K\no e\n120K (3_—_6—_ — e — _e\n100K 100K\nQ3-2022 Q4-2022 Q1-2023 Q2-2023 Q3-2022 Q4-2022 Q1-2023 Q2-2023\n[ united States ¥ Business Entity Data B.V.\n[l united Kingdom [ ubisecure\n. Germany . London Stock Exchange\n[ italy B Bloomberg\n. Spain . WM Datenservice\n© 2023 GLEIF and/or its affiliates. All rights reserved. | Release date 2023-07-18 | Version 1.0 | Public\n","contentLength":605,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:37:57.760Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/global-lei-index/download-global-lei-system-business-reports/download-global-lei-system-business-report-q2-2023/2023-07-18-quarterly_business_report.pdf","content":"Global LEI System Business Report | 02 2023 | page 05 ©\n|\nGrowth in Total Number of Active LEIs\nNew LEl Issuance | Fig.-4 LEI Forecast | Fig.-5\nTotal LEIs Actual Active LEIs\nNewly Issued LEIs Forecasted Active LEls\n2500K\n2000K Q1-2023 Q2-2023 Q3-2023 Q4-2023\n1500K\n1000K\n2)247,000 [ 2,307,485 JN2;302;000 2,361,000 2,425,000\n500K\n0K\nQ3-2022 Q4-2022 Q1-2023 Q2-2023\nQuarterly LEI Growth - Top 5 Jurisdictions | Fig.-6' Quarterly LEI Growth - Top 5 LEl Issuers | Fig.-7\n12.1% 14.3%\n12.2%\n11.0%\n0,\n8.3% 7.8%\n7.7%\n5.4% 5.1% l 6.6%\nSaudi Arabia (3) India (128) Sweden (88) Tiirkiye (7) Iceland (4) Unilei (7) NasdaqLEl (1) SACB /Moarif (3) Ubisecure (225) LEIL (58)\nTotal issuance in thousands at most recent quarter-end date in parenthesis Total issuance in thousands at most recent quarter-end date in parenthesis\n1. Analysis includes only those jurisdictions with at least 1,000 LEls in total at the previous quarter-end date. © 2023 GLEIF and/or its affiliates. All rights reserved. | Release date 2023-07-18 | Version 1.0 | Public\n","contentLength":1031,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:37:57.761Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/global-lei-index/download-global-lei-system-business-reports/download-global-lei-system-business-report-q2-2023/2023-07-18-quarterly_business_report.pdf","content":"Global LEI System Business Report | 02 2023 | Page 06 ©\nL] I R N ————E——E S ———\nLEI Renewal activity LElI Renewal - Top 5 Jurisdictions | Fig.-9\n94.2% 91.3%\nio - 86.7%\nLEI Renewal | Fig.-8 82.1% 80.3%\n2500K\n2000K\nTotal Active LEls\n1500K\n1000K Active and Verified LEls\nHungary (18) Japan (11) Finland (43) Liechtenstein (12) India (128)\n500K B —————————————————\noK Total issuance in thousands at most recent quarter-end date in parenthesis\nQ3-2022 Q4-2022 Q1-2023 Q2-2023 L\nReference Data Corroboration by LEl issuers\nLEI non-Renewal (Lapsed LEIls) - Top 5 Jurisdictions | Fig.-10' Percentage of Fully Corroborated LEls | Fig.-11\n77.6%\n76.5% 71.4% 83.8% 84.3% 84.6% 84.8%\nI I I 66.6% 64.8%\nSaudi Arabia (3) China (106) Belize (1) Russian Federation (2) Thailand (2)\nQ3-2022 Q4-2022 Q1-2023 Q2-2023\nTotal issuance in thousands at most recent quarter-end date in parenthesis\n1. Analysis includes only those jurisdictions with at least 1,000 LEls in total at the previous quarter-end date. © 2023 GLEIF and/or its affiliates. All rights reserved. | Release date 2023-07-18 | Version 1.0 | Public\n","contentLength":1092,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:37:57.761Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/global-lei-index/download-global-lei-system-business-reports/download-global-lei-system-business-report-q2-2023/2023-07-18-quarterly_business_report.pdf","content":"Global LEI System Business Report | 02 2023 | page 07 ©\n|\nCompetition amongst LEl issuers\nLeast Competitive (Most Concentrated) Markets | Fig.-12\" Most Competitive (Least Concentrated) Markets | Fig.-13'\n19.7%\n18.8%\n97.9% 16.8% 17.3% 18.0%\nI ] ] j j I I I I\n\nChina (106) Netherlands (129) Slovenia (4) Poland (31) Tiirkiye (7) Malta (5) Portugal (12) Bulgaria (4) Norway (48) Marshall Islands (2)\nTotal issuance in thousands at most recent quarter-end date in parenthesis Total issuance in thousands at most recent quarter-end date in parenthesis\nTransfer out of LEls —Top 5 LEI Issuers | Fig.-14 Transfer in of LEIs — Top 5 LEl Issuers | Fig.-15\n\n7,162 7,320\n6,044\n3,589\n1,912\n4 1,669\n-1’296 - - l - - -1’299\nKELER (0) Business Entity Data Ubisecure (225) EQS (123) Bloomberg (181) GS1 AISBL (46) Ubisecure (225) Bloomberg (181) EQS (123) Unilei (7)\nB.V. (413)\n\nTotal issuance in thousands at most recent quarter-end date in parenthesis Total issuance in thousands at most recent quarter-end date in parenthesis\n\n1. Analysis includes only those jurisdictions with at least 1,000 LEls in total at the previous quarter-end date. . - . . .\n\nThe higher the percentage the more concentrated LEI management is with a single LEl issuer. © 2023 GLEIF and/or its affiliates. All rights reserved. | Release date 2023-07-18 | Version 1.0 | Public\n","contentLength":1337,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:37:57.761Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/global-lei-index/download-global-lei-system-business-reports/download-global-lei-system-business-report-q2-2023/2023-07-18-quarterly_business_report.pdf","content":"Global LEI System Business Report | | Page 08\n\nL _________________________________________________________________________________________________________________________}\n\nLevel 2 parent reporting\n\nTop 5 Jurisdictions of the Legal Entities for\nlegal entities reported Direct and Ultimate Parent Reporting | Fig.-1\nIn May 2017, the process of enhancing the LEI direct and ultimate\n. . : 225,769\ndata pool, by including ‘Level 2’ data to Pa;e“:;\":;;';g by the 12 3ce 170,200\n. end o ) y\n\nanswer the question of ‘who owns whomn’, 167,083 150,594\n\nbegan. The graphic below provides\n\ninformation on direct and ultimate parent\n\ndata collected through June 2023\".\n\nUnited States United Kingdom Germany Italy Spain\nEach legal entity reports information on its Each legal entity reports information on its\nof legal entities . of legal entities of legal entities of legal entities of legal entities of legal entities of legal entities\n. of legal entities q . . d ulti i N X .\n\nreported direct parents ted direct ¢ reported having no relationship reported ultimate reported ultimate reported having no relationship\n\nhaving an LEI* EEPOIEECicecHbanen s direct parent information is parents having an LEI* parents who do not ultimate parent information is\n\n(See next page for who do not have an LEI according to the non-public and (See next page for have an LEI according to the non-public and\nadditional details.) definition used therefore creates additional details.) definition used therefore creates\n\nobstacles to releasing obstacles to releasing\nthis information this information\n\n1 Referenced to level 2 relationship record CDF Golden Copy file dated 01 July 2023.\n2 99.9% legal entities reported direct parent.\n3 99.9% legal entities reported ultimate parent.\n\n4 The definitions of ultimate and direct parent are based on percentage share of accounting consolidation as per LEl Regulatory Oversight Committee . . . . i\nprescription. Related link https://www.gleif.org/en/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format © 2023 GLEIF and/or its affiliates. All rights reserved. | Release date 2023-07-18 | Version 1.0 | Public\n","contentLength":2168,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:37:57.761Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/global-lei-index/download-global-lei-system-business-reports/download-global-lei-system-business-report-q2-2023/2023-07-18-quarterly_business_report.pdf","content":"Global LEI System Business Report | | Page 09 ;\nLevel 2 parent reporting\nIdentification of the direct and ultimate parents of a legal entity with an LEl allows users to research entities\nowned by individual companies. It provides a better understanding of the entity from which a company or\nindividual is buying goods or services or in which it is investing. The following charts provide additional\ninformation on relationships where the direct or ultimate parents are identified by an LELI.\nAdditional Information on Direct Parents Having an LEI Additional Information on Ultimate Parents Having an LEI\nNumber of Direct Parents | Fig.-3 Number of Ultimate Parents | Fig.-5\n35K 24K\n30K 21K\n18K\n25K\n\\_ L\n20K\n12K\n15K\n9K\nN\n10K & >\nS‘ 6K o) T\n= 2 R e\n(99}\n5K 5 3 . = 3K ~ 8\n- © al o\n0K = 0K\nI I I I I I I I I I\n1 2 3 4 5 5 plus 1 2 3 4 5 5 plus\n© 2023 GLEIF and/or its affiliates. All rights reserved. | Release date 2023-07-18 | Version 1.0 | Public\n","contentLength":947,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:37:57.761Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/global-lei-index/download-global-lei-system-business-reports/download-global-lei-system-business-report-q2-2023/2023-07-18-quarterly_business_report.pdf","content":"Global LEI System Business Report | 02 2023 | page 10 O\n|\nNew policies implementation transition period report: new entity categories\nThe new Common Data Format identifies resident government entities and international\norganizations as specific entity categories. The following figures show the evolvement of the government\nentities and international organizations in the Global LEI System.\nNo. of government entities | Fig.-1 Top 5 jurisdictions reporting government entities | Fig.-2\n5,054 5,159 1,055\n4,637 4,852\n751 709\n382\nI I . .\n2022 -Q3 2022 - Q4 2023 -Q1 2023 - Q2 Poland (30) United States (277) Italy (170) Czech Republic (23) United Kingdom\n(179)\nTotal issuance in thousands at most recent quarter-end date in parenthesis\nNo. of international organizations | Fig.-3 Top 5 jurisdictions reporting international organizations | Fig.-4\n32 17\n30\n27\n11\n19 .\n. 4\nXX United Nations European Union\n2022 -Q3 2022 -Q4 2023 -Q1 2023 -Q2\nTotal issuance in thousands at most recent quarter-end date in parenthesis\n\n1. XX refers to international organizations that do not have a legal jurisdiction. © 2023 GLEIF and/or its affiliates. All rights reserved. | Release date 2023-07-18 | Version 1.0 | Public\n","contentLength":1204,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:37:57.761Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-concatenated-file/about-the-concatenated-file/2017-02-05_gleif-concatenated-file_v2-4_final.pdf","content":"@’ rotattng ol st\n\nGLEIF Concatenated Files\nSpecification and User\nManual\n\nFinal\n","contentLength":81,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:38:21.905Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-concatenated-file/about-the-concatenated-file/2017-02-05_gleif-concatenated-file_v2-4_final.pdf","content":"Table of Contents\n\n1 About the GLEIF Concatenated Files.........ccccevuvueeeiiiiiirirnrnniciicinnennenennnn. 4\n1.1 What are the GLEIF Concatenated Files? ......ccccovuiiieiriiiiiieeeeeciiieeeeesseeeeeee e 4\n1.2 Who creates the GLEIF Concatenated Files?........ccccceevvvviieeeeeiiiiieeeeneniieeeeeene 4\n1.3 Whatisincluded in the Concatenated Files? .........ccccceevvivieeeeiviiiieeeennsiieeeeeeen 4\n1.4 What is the technical format of the GLEIF Concatenated Files?.........ccccecceeeeeeeen. 5\n1.5 Whatif an LEl Issuer’s source file is not technically valid? ........c.cccccceviviieeeiinnnen. 5\n1.6 How are the GLEIF Concatenated Files created? .......ccoecvvveiviiiciiieeeiiiiiiieee s 5\n1.7 How up-to-date are the GLEIF Concatenated Files? ........ccccccvveivieeeiiiiiiieeniinnnnnn. 6\n1.8 Does GLEIF validate the LEI Issuers’ original source files? ........cccccceevevivieeeeiinnccnnn 7\n1.9 What future developments are planned?........ccccveeeviiiiiieeeniciciiieeeecsiieeee e essiinns 7\n1.10 Why are GLEIF Concatenated Files produced before 8th June 2015 different? .... 7\n\n2 How do | download the GLEIF Concatenated Files and the original source\nL1 =T -\n2.1 Manual dOWNIOAd ......ouiiiiiiiiiiieee e e &\n2.2 Automated dOWNIoad .......cocuiiiiiiiiiiiieie e e D\n2.2.1 File pUBblCation .....cccvieii it e e snene D\n2.2.2 File retrieVal URLS ... ...cieicccieie e cciieee ettt cctie e eevie e snae e e s ssnae e s snan e e s snanaaesnnnens O\n\n2.2.3 How can | parse the GLEIF Concatenated Files and the LEl Issuers’ original source\n] LTy ST PRPSRPRSR: 0|\n2.3 How can |l interpret the GLEIF Concatenated Files data once downloaded?....... 10\n3 Where can I find further information?.......ccccccoirrreiiiiirnciiinineccinnnnenennn 11\n3.1 Technical SUPPOIt....cc..uiiiiiei ettt e e e s rareeee s s sansesesessssneneeesss L1\no 00 0 O I Y T T WY o ] =TSSP i\n3.1.2 Whom should I contact for further questions? ........ccccceeeevevvieeccceeesve e 11\nG GLEIF Concatenated Files Specification and User Manual Page 2 of 11\n@ Public Version 2.4\n2017-02-05_gleif-concatenated-file_v2-4_final.docx 2017-05-04\n","contentLength":2095,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:38:21.905Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-concatenated-file/about-the-concatenated-file/2017-02-05_gleif-concatenated-file_v2-4_final.pdf","content":"3 Where can | find further information?\n3.1 Technical support\n3.1.1 LElIssuer files\nIf you have any questions regarding the original source files, please contact the respective LEI Issuer\nvia its website.\nContact details for all LEI Issuers can be found on the Original Sources page at www gleif.org.\n3.1.2 Whom should I contact for further questions?\nIf you have any questions regarding the GLEIF Concatenated Files downloaded from the GLEIF\nWebsite, please contact GLEIF directly at: info@gleif.org.\nGLEIF Concatenated Files Specification and User Manual Page 11 of 11\n@ Public Version 2.4\n2017-02-05_gleif-concatenated-file_v2-4_final.docx 2017-05-04\n","contentLength":654,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:38:21.905Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-concatenated-file/about-the-concatenated-file/2017-02-05_gleif-concatenated-file_v2-4_final.pdf","content":"- 2.4\n- Head of Development and Operations (GLEIF IT)\nAbout this Document\nThis document:\n¢ Describes the GLEIF Concatenated Files.\n¢ Explains how to download and use the Files.\nChange History\nThis section records the history of all changes to this document.\n2017-05-04 2.4 Level 2 updates GLEIF\n2016-01-27 2.0 Completed first Web version GLEIF\n2016-01-20 1.0 First draft pre-publication GLEIF\nWhere changes are made for clarity and reading ease only and no change is made to the meaning or\nintention of this document, the version number will be increased by 0.1.\nWhere significant changes are made to this document, the version number will be incremented by\n1.0.\nGLEIF Concatenated Files Specification and User Manual Page 3 of 11\n@ Public Version 2.4\n2017-02-05_gleif-concatenated-file_v2-4_final.docx 2017-05-04\n","contentLength":814,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:38:21.905Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-concatenated-file/about-the-concatenated-file/2017-02-05_gleif-concatenated-file_v2-4_final.pdf","content":"1 About the GLEIF Concatenated Files\nLEI Issuers — also referred to as Local Operating Units (LOUs) — supply\nregistration, renewal and other services, and act as the primary interface for\nLegal Entities wishing to obtain an LEI.\nThey assign LEls to, and collect information on, Legal Entities, and publish this\ninformation daily in original source files, both at their public websites and to\nGLEIF, for production of the centralized Global LEI Index.\nThe primary access point to the Global LEI Index is the complete set of GLEIF\nConcatenated Files.\n1.1 What are the GLEIF Concatenated Files?\nThe Global Legal Entity Identifier Foundation (GLEIF) publishes daily updated Concatenated Files. As\ntheir name indicates, they consist of a concatenation of all LEls and related data in the original source\nfiles published by all LEI Issuers worldwide, provided in central files, without changes to the source\ndata.\nGLEIF offers the unique Concatenated File service free of charge to any interested user, but please\ntake note of the LEI Data Terms of Use at www.gleif.org. The GLEIF Concatenated Files are available\non the GLEIF Download webpage.\n1.2 Who creates the GLEIF Concatenated Files?\nGLEIF creates the daily Concatenated Files in collaboration with all organizations that issue LEls (LOUs\n— Local Operating Units).\nEarlier versions of LEI-CDF Concatenated Files were published in cooperation with c-lei.org, a project\nsupported by GS1. For more information about c-lei.org, please visit www.c-lei.org.\n1.3 What is included in the Concatenated Files?\nGLEIF Concatenated Files’ content includes:\no All current Legal Entity Identifiers (LEIs) globally;\no Allrelated LEI Reference Data (LE-RD), including:\n¢ ldentification data for each Legal Entity itself;\no Relationships to other Legal Entities (where applicable);\no Reasons for lack of relationship reporting (where applicable).\nGLEIF Concatenated Files Specification and User Manual Page 4 of 11\n@ Public Version 2.4\n2017-02-05_gleif-concatenated-file_v2-4_final.docx 2017-05-04\n","contentLength":2031,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:38:21.905Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-concatenated-file/about-the-concatenated-file/2017-02-05_gleif-concatenated-file_v2-4_final.pdf","content":"1.4 What is the technical format of the GLEIF Concatenated Files?\nAll GLEIF Concatenated Files are provided as an XML data file within a ZIP compressed file.\nEach type of information is provided by the LEI Issuer according to its own Common Data File (CDF)\nformat, an XML Schema and content specification, and made available in its own Concatenated File:\nLEI-CDF Legal Entity identification (LEI code, Legal Entity information)\nRR-CDF Relationships between Legal Entities\nRepEx Reporting Exceptions (reasons for non-reporting)\nPlease see the GLEIF Common Data File Formats page for general and technical details of each CDF\nformat:\n1.5 What if an LEl Issuer’s source file is not technically valid?\nPlease note that for technical reasons, each type of GLEIF Concatenated File is compliant with the\nlatest version of the relevant Common Data File format.\nThis means that original source files which were not compliant with the Common Data File format on\na given day are excluded from the GLEIF Concatenated Files and, if available, an earlier compliant\nversion of the source file is used in the GLEIF Concatenated File of that day.\nDetails on the status of each source file are available via the “Show Details” link provided with each\nGLEIF Concatenated File on the GLEIF Download webpage.\n1.6 How are the GLEIF Concatenated Files created?\nDaily, the LEl Issuers’ original source files are concatenated by GLEIF. This process:\n1. 1. Removes the individual file headers.\n2. 2. Concatenates all currently available records.\n3. 3. Adds a central GLEIF file header.\nThe following diagram below illustrates this process.\nPlease note the process is the same for all file types.\nGLEIF Concatenated Files Specification and User Manual Page 5 of 11\n@ Public Version 2.4\n2017-02-05_gleif-concatenated-file_v2-4_final.docx 2017-05-04\n","contentLength":1821,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:38:21.905Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-concatenated-file/about-the-concatenated-file/2017-02-05_gleif-concatenated-file_v2-4_final.pdf","content":"Concatenated File\nIndividual File Headers\nIndividual File Header are replaced with Central File Header\na Central File Header\nR\nIndividual File Headers\nIndividual File Header are replaced with\na Central File Header\nR\nIndividual File Headers\nIndividual File Header are replaced with\na Central File Header\nRecord R\nEach GLEIF Concatenated File provides details on the LEI Issuers' original source files.\nFor more information on the structure of the LEI Data Records please see the Common Data File\nformat specification available at www.gleif org.\n1.7 How up-to-date are the GLEIF Concatenated Files?\nGLEIF makes all of the latest Concatenated Files available daily from 12:00 UTC+O.\nThe Original Sources page provides a listing of all contributing LEI Issuers as well as information on\nthe availability and schema validation status of the LEl Issuers’ data.\nPlease note: only technically valid (XML schema valid) source files are used in the Concatenated Files.\nThis accounts for any older LEI Issuer records: these are the records from the most recent valid XML\nfile provided by the respective LEl Issuer, and are used as fallbacks, should a valid file be temporarily\nunavailable.\nThe details link associated with each GLEIF Concatenated File listed on the Download page identifies\nthe LEI Issuers' original source files included in that specific GLEIF Concatenated File download.\nGLEIF Concatenated Files Specification and User Manual Page 6 of 11\nGLEIF) Public Version 2.4\n2017-02-05_gleif-concatenated-file_v2-4_final.docx 2017-05-04\n","contentLength":1535,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:38:21.905Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-concatenated-file/about-the-concatenated-file/2017-02-05_gleif-concatenated-file_v2-4_final.pdf","content":"1.8 Does GLEIF validate the LEI Issuers’ original source files?\nThe content of the original LEI Issuer source files is not validated by GLEIF. They are only checked\ntechnically to verify compliance with the XML Schema of the Common Data File format.\nTo view the detailed list of source files contained in each GLEIF Concatenated File, follow the \"Show\nDetails\" link available with the individual GLEIF Concatenated Files posted on the GLEIF website's\nDownload page.\nThis list indicates, among other things, if a source file included in a Concatenated File published prior\nto 8th June 2015 is not fully compliant with the relevant Common Data File format.\nContent issues should be communicated to the managing LEI Issuer associated with the data in\nquestion.\n1.9 What future developments are planned?\nGLEIF continually enhances the scope of its service to include data quality assurance, user search\ncapability, and other file access options.\nPlease see the GLEIF website for announcements of all new developments.\n1.10 Why are GLEIF Concatenated Files produced before 8th June\n2015 different?\nEarlier versions of LEI-CDF Concatenated Files are published in cooperation with c-lei.org, a project\nsupported by GS1.\nFor more information about c-lei.org, please visit c-lei.org.\nURLs of LEI-CDF Concatenated Files posted prior to 8th June 2015 are in the following format:\nhttps://www.gleif.org/lei-files//clei/-clei-file.zip\nThe LEI-CDF Concatenated Files published prior to 8th June 2015 are well-formed XML files.\nHowever, due to the fact that several of the original source files received from LEI Issuers prior to 8th\nJune 2015 were not yet fully compliant with the relevant CDF XML schema, neither are the GLEIF\nConcatenated Files posted before that date.\nGLEIF Concatenated Files Specification and User Manual Page 7 of 11\n@ Public Version 2.4\n2017-02-05_gleif-concatenated-file_v2-4_final.docx 2017-05-04\n","contentLength":1930,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:38:21.905Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-concatenated-file/about-the-concatenated-file/2017-02-05_gleif-concatenated-file_v2-4_final.pdf","content":"2 How do | download the GLEIF Concatenated\nFiles and the original source files?\nPlease note that the Concatenated Files are provided as XML, which needs\nspecialized tools for display and analysis.\nTo download a set of current LEI Records in Excel or CSV format, suitable for\nuse in spreadsheet applications, please use the LEI Search tool.\n2.1 Manual download\nTo download the GLEIF Concatenated Files manually:\n1. Go to the Concatenated Files Download page and select the desired CDF format.\n2. Click either\n1. the most recent GLEIF Concatenated File (highlighted at the top of the page) or\n2. any of the previous GLEIF Concatenated Files.\n3. If you would like information on the original source files, click the details link and you will be\nredirected to a page containing these files.\n4. Then click the download link to obtain the file you have chosen.\nPlease note that GLEIF offers all files as ZIP files.\nOnce downloaded, you can unzip the files with the tool of your choice (depending on your operating\nsystem this may happen automatically) and access the XML file in the Common Data File format.\nThe GLEIF Concatenated Files use XML formats which cannot be directly opened with e.g. Excel or\nAccess. Often a specialized tool is needed. GLEIF does not provide tool or application support;\ninstead we recommend consulting your IT team for any complex tasks.\nThe GLEIF Concatenated Files use XML formats which cannot be directly\nopened with e.g. Excel or Access. Often a specialized tool is needed. GLEIF does\nnot provide tool or application support; instead we recommend consulting your\nIT team for any complex tasks.\nGLEIF Concatenated Files Specification and User Manual Page 8 of 11\n@ Public Version 2.4\n2017-02-05_gleif-concatenated-file_v2-4_final.docx 2017-05-04\n","contentLength":1773,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:38:21.905Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-concatenated-file/about-the-concatenated-file/2017-02-05_gleif-concatenated-file_v2-4_final.pdf","content":"2.2 Automated download\nTo download the GLEIF Concatenated Files automatically, you can use a computer program to\nrequest the files, e.g. cURL, etc.\n2.2.1 File publication\nGLEIF’s daily Concatenated File is available from 12:00 UTC+00 (UTC-Z) at the Download page.\nPlease ensure that your download process executes at or shortly after 12:00 UTC-Z to be certain of a\nreliable process and up-to-date LEls.\n2.2.2 File retrieval URLs\nThe date in the URLs for the GLEIF Concatenated Files refers to the date of the concatenation.\n2.2.2.1 LEI-CDF V2, RR-CDF and Reporting Exception Files\nThe URLs for LEI-CDF V2, RR-CDF and Reporting Exception Files follow this pattern.\nhttps://leidata.gleif.org/api/v1/concatenated-files/{filetype}/{date}/zip\nWhere the parameters in {brackets} (do not include the brackets in the URL!) are as follows:\no date is the day’s calendar date in YYYYMMDD format.\no filetype is one of the following:\no lei2 — LEI-CDF V2 format.\ne rr— Relationship Record (RR) CDF format.\n* repex— Reporting Exception format.\n‘ Example:_https://leidata.gleif.org/api/vl/concatenated-files/lei2/20170501/zip\n2.2.2.2 LEI-CDF V1 Files\nAs of 8th June 2015, URLs of LEI-CDF V1 Files are in the following format:\nhttps://www.gleif.org/lei-files//GLEIF/-\nGLEIFconcatenated-file.zip\nBefore 8th June 2015, URLs of Concatenated Files are in the following format:\nhttps://www.gleif.org/lei-files//clei/-clei-file.zip\nGLEIF Concatenated Files Specification and User Manual Page 9 of 11\n@ Public Version 2.4\n2017-02-05_gleif-concatenated-file_v2-4_final.docx 2017-05-04\n","contentLength":1600,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:38:21.905Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-concatenated-file/about-the-concatenated-file/2017-02-05_gleif-concatenated-file_v2-4_final.pdf","content":"2.2.3 How can | parse the GLEIF Concatenated Files and the LEI Issuers’ original source\nfiles?\nAll files provided since 8th June 2015 are valid XML files complying with the relevant Common Data\nFile (CDF) format.\nAny XML parser can be used to incorporate the content into a given environment.\nPlease note that the GLEIF Concatenated Files are not a database and so there is no documentation\ndetailing tables, relationships between tables or database validation rules.\nThe GLEIF Concatenated File and the CDF formats are also not intended as database design guidance,\nthough they could be used to inform such a process. GLEIF does not provide tool support; instead we\nrecommend consulting your IT team for any complex tasks.\n2.3 How can | interpret the GLEIF Concatenated Files data once\ndownloaded?\nTo understand the definitions of the codes in LEI data fields, please see the detailed technical\nspecifications (human readable documentation) for the LEIl Common Data File formats.\nSoftware applications may require the XML Schema Definition (XSD) file to process the Concatenated\nFiles. The latest versions of the technical specifications and XSDs for all CDF formats can be found\nwww.gleif.org.\nLEI Issuers are also required to create and update CDF files according to the State Transition and\nValidation Rules (ST/VR) for the relevant CDF format. These data management rules are provided by\nGLEIF in addition to the CDF XML Schemas, and LEI Issuers must follow them in order to achieve high\ndata quality scores, but they are not automatically enforced.\nPlease find the ST/VR at the GLEIF Common Data File Formats pages on www.gleif.org.\nGLEIF Concatenated Files Specification and User Manual Page 10 of 11\n@ Public Version 2.4\n2017-02-05_gleif-concatenated-file_v2-4_final.docx 2017-05-04\n","contentLength":1791,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:38:21.905Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-golden-copy/2022-02-23_gleif-golden-copy-and-delta-files_v2.2-final.pdf","content":"@> Protecting dottal rust\n\nGLEIF Golden Copy and\nDelta Files Specification\nand User Manual\n\nFinal\n","contentLength":98,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:38:56.880Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-golden-copy/2022-02-23_gleif-golden-copy-and-delta-files_v2.2-final.pdf","content":"Table of Contents\n1 About the GLEIF Golden Copy FileS....cccceteuerencrencrnnceenrennceeenceenceenncenneens 4\n1.1 What s the responsibility of LEl Issuers and GLEIF in publishing Golden Copy\nFIlES? ittt aae e s s snnteeeessnnsnneeessnssnnenees Db\n1.2 Whatisincluded in the Golden Copy Files?.....ccocviiiiiriiiiieeeeiiiiieeeeessieveeee e 4\n1.3 What if one or more LEI Issuers upload the same LEI more than once, or a\ndisallowed combination of relationship reporting?.........ccccccceevivivieeeiiivcinn 5\n1.4 How up-to-date are the GLEIF Golden Copy Files? ......ccccvvveevivccivieeeeiiiiiieeeeensinns 7\n1.5 How can | download updates to GLEIF Golden Copy Files (Delta Files)? ............... 7\n1.6 Whatis the format of the GLEIF Golden Copy Files? .......ccccceevveivieeeiiiiiieiine i 8\n1.0.0 File COMPIESSION . .uiiiiiictiiiieiiiiit e ettt te e ee e ee e s saeeee e s saeee s asssaeeaeessanraeeassannreeaessnreeees O\n1.1.2 Data content StandardS.......ocuueeeiiiiiiieiiiniiie e O\n00 G T o1 L= (o ' = TSP\n1.7 Whatif an LEl Issuer’s source file is not technically valid? ........ccccccceeviviiiiiiinnnn. 9\n1.8 How are the GLEIF Golden Copy Files created? .......cccceevvvveeeeiiivineeeeinnnivneeennnen 10\n1.1.4 LElIssuer —file Upload.......cccceeciieiiieceeeeeciie ettt seesscteeeceeeseseesseeesneesssnseeeeneeens 10\n1.1.5 GLEIF — Golden Copy production.......cccccoeueeieirsiirieesisiiieeessiieeeesceeeeesseeessssenenns 10\n1.9 Does GLEIF validate the LEI Issuers’ original source files? ........ccccccvivvvvvneeennnn. 10\n1.10 What extra information is added by GLEIF?.........cccceeevvriiiiieeeeeiiniieeeeeessiieeeeeeenn 10\n1.11 What future developments are planned?.........cccveeeviviniiieeenivciiieeeecninieeee s 11\n2 Howdo | download the GLEIF Golden Copy Files and Delta Files?..........12\n2.1 Manual doWNnIoad ........coeiiiiiiiiiiiiieiie e e s saareee s e s snneeeeeees 12\n2.2 Automated dOWNIoad .......ccccueiieiiiiiiiieeie e ssriieeeesnees 13\n2.2.1 File PUBICAtION wiiiiiiiieee ittt tte e erete e estae e s srae e e s sneeaeesnee 13\n2.2.2 File retrieval URLs — Full and Delta FileS.......ccccceeeevieeeiiiiieieeccieee e cciieeeee 13\n3 How can linterpret the GLEIF Golden Copy Files data once downloaded?\n3.1 Data element (“attribute”) definitions........ccccevveeeiiciee e ens 15\n3.2 Technical validation and database import........ccccoeeveeieiiiiiieee i esiiieeenns 15\n3.3 Data management MUIES......cccvveeie it strie e sriie e e s sssiireee s e s s saibeaeeesssiseeaeeeses 1D\n4 Where can | find further information?......cc.cccovvevviiiiireiiiirieciiinieeennnnn. 16\n4.1 GeNneral QUESTIONS ...ccviiiiieeie ittt ssrae e e s essibeee s e s s saiinae s e s s sseaaeeessnnssseees 1O\n4.2 TechniCal SUPPOIt....cciiiiciiiieieciiiieeee e seeie e essrre e e s sssiieee s e s s saiinae e e s s sseaaeeessnnssseees 1O\n7 A I8 T =Y o 1 TP UOUPPT: | -\n4.2.2 Whom should | contact for further questions? ..........ccceecvvevciieeice s 16\nGLEIF Golden Copy and Delta Files Specification and User Page 2 of 16\nManual\n@ Public Version 2.2\nG 2022-02-23_gleif-golden-copy-and-delta-files_v2.2-final.docx 2022-02-24\n","contentLength":3113,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:38:56.880Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-golden-copy/2022-02-23_gleif-golden-copy-and-delta-files_v2.2-final.pdf","content":"The additional data will assist in data visualization and automatic / statistical comparisons for data\n\nquality checking.\n\n1.11 What future developments are planned?\n\nGLEIF continually enhances the scope of its service to include data quality assurance, user search\n\ncapability, and other file access options.\n\nPlease see the GLEIF website for announcements of all new developments.\nGLEIF Golden Copy and Delta Files Specification and User Page 11 of 16\nManual\n\n@ Public Version 2.2\n\n2022-02-23_gleif-golden-copy-and-delta-files_v2.2-final.docx 2022-02-24\n","contentLength":556,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:38:56.880Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-golden-copy/2022-02-23_gleif-golden-copy-and-delta-files_v2.2-final.pdf","content":"2 How do | download the GLEIF Golden Copy\nFiles and Delta Files?\n\n2.1 Manual download\n\nTo download the GLEIF Golden Copy Files and Delta Files manually:\n\n1. Goto the Golden Copy Files and Delta Files Download page and select the desired\nCommon Data File format (LEI-CDF for LEI Records, RR-CDF for Relationship Records,\nReporting Exceptions Format for Reporting Exceptions).\n\n2. Click either\n1. the most recent GLEIF Golden Copy File (highlighted at the top of the page) or\n2. any of the previous GLEIF Golden Copy Files.\n\nPlease note: It is possible that the download of the Golden Copy Files can\ntake a bit longer than expected due to a large number of parallel\ndownload requests being processed. It is advised to perform the\ndownload with a random interval of 1 - 120 minutes from the proposed\ntime (02:00 UTC, 10:00 UTC, 18:00 UTC) to avoid heavy traffic and to\nsupport load balancing.\n\nDelta files can also be manually downloaded. They always provide the most recent version of the\n\nrecords they contain (i.e. as of the current Golden Copy). However, to define which records are\n\nincluded they must be specified in terms of:\n\n¢ File type — the content and format of the Golden Copies the Delta File will be based on:\n\no Levell\no LEI-CDFV3.1\no Level2\no RR-CDF V2.1\no Reporting Exceptions V2.1\no Delta type — the time period since the previous update (e.g., the previous Delta File you\ndownloaded, or the original full Golden Copy File used to create your local copy):\n\n¢ Intra-day (since previous Golden Copy; eight hours earlier);\n\no Day (since three Golden Copies ago; 24 hours earlier);\n\n* Week (seven days ago);\n\n¢ One month (31 days ago).\nGLEIF Golden Copy and Delta Files Specification and User Page 12 of 16\nManual\n\n@ Public Version 2.2\n\n2022-02-23_gleif-golden-copy-and-delta-files_v2.2-final.docx 2022-02-24\n","contentLength":1822,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:38:56.880Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-golden-copy/2022-02-23_gleif-golden-copy-and-delta-files_v2.2-final.pdf","content":"2.2 Automated download\nTo download the GLEIF Golden Copy Files and Delta Files automatically, you can use a computer\nprogram to request the files, e.g., cURL, etc.\n2.2.1 File Publication\nTo download the GLEIF Golden Copy Files and Delta Files automatically, please ensure that your\ndownload process executes at or shortly after 02:00 UTC, 10:00 UTC, 18:00 UTC to be certain of a\nreliable process and up-to-date LEls.\n2.2.2 File retrieval URLs — Full and Delta Files\nA list of published files including specific download URLs can be obtained via the following URL:\nhttps://goldencopy.gleif.org/api/v2/golden-copies/publishes\nThe Golden Copy APl is available through two domains, goldencopy.gleif.org and leidata-\npreview.gleif.org (legacy). The URLs may differ, but the behaviour does not change.\nThe above URL returns a paginated listing for Golden Copy files of all CDF types (lei2, rr, repex) and\ndisplays both the Full Files as well as the Delta Files (Intra-day, Day, Week, One Month). Each file type\nand the corresponding Full File or Delta File are available in formats CSV, JSON, XML.\nPlease note: The ‘lei2’ keyword used in the APl URLs and JSON response\nattributes is used regardless of the LEI CDF version for legacy purpose\nto ensure backwards compatibility.\nThe ‘cdf_version’ field included in the API response indicates the exact CDF version the user can\nexpect.\nFollowing endpoints can be appended to above URL for additional or more specific functionality:\no /latest: always returns an updated list of the ‘latest’ published golden copy files for all CDF\nformats.\nExample: https://goldencopy.gleif.org/api/v2/golden-copies/publishes/latest\nThe ‘/latest’ endpoint provides Full File and Delta Files in formats CSV, JSON, XML.\no [filetype}: the ‘filetype’ endpoint will only return the CDF type specified\nExample: https://goldencopy.gleif.org/api/v2/golden-copies/publishes/lei2\no The filetypes available are as follows:\no lei2 (LEI-CDF);\ne rr (RR-CDF);\no repex (Reporting Exceptions);\nGLEIF Golden Copy and Delta Files Specification and User Page 13 of 16\nManual\n@ Public Version 2.2\n2022-02-23_gleif-golden-copy-and-delta-files_v2.2-final.docx 2022-02-24\n","contentLength":2170,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:38:56.880Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-golden-copy/2022-02-23_gleif-golden-copy-and-delta-files_v2.2-final.pdf","content":"o [{filetype}/latest: always returns the ‘latest’ published files based on the CDF type specified\nExample: https://goldencopy.gleif.org/api/v2/golden-copies/publishes/lei2/latest\n\no [ffiletype}/latest.{format}: will provide a prompt to download/save the latest file of the\nspecified CDF type in the desired for ‘format’\n\nExample: https://goldencopy.gleif.org/api/v2/golden-copies/publishes/lei2/latest.csv\no The formats available are as follows:\n° Csv\no xml\n° json\n\no [ffiletype}/{publish date}: the 'publish date' endpoint allows for the file dates to be explicit, for\nexample, https://goldencopy.gleif.org/api/v2/golden-copies/publishes/lei2/20200613-0000. In\naddition, the 'publish date' endpoint also supports direct download by format (xml, json, csv), for\nexample, https://goldencopy.gleif.org/api/v2/golden-copies/publishes/lei2/20200613-0000.csv\n\no The 'publish date' is the day's calendar date in YYYYMMDD format.\no The 'publish date' must also include the Golden Copy publishing time as per the example\nprovided.\no There are three timeframes available are as follows:\n* 0000;\n* 0800;\n* 1600;\n\no [ffiletype}/{publish date}.{format}?delta={deltaType}: Delta files can also be downloaded with\nthe 'deltatype’ endpoint. The endpoint will provide a prompt to download/save the specified\nDelta file in the specified format. The xml/csv/json export endpoint also supports delta file\ndownloads by providing a ‘delta’ query parameter with an appropriate delta type.\n\nPlease note: The {publish date} could be replaced with value ‘/atest’; and\nthis will download the latest Golden Copy files.\nExample: https://goldencopy.gleif.org/api/v2/golden-copies/publishes/lei2/20200421-\n0800.csv?delta=IntraDay\no Delta types to be included in URL as follows:\ne IntraDay\no LastDay\no LastWeek\ne LastMonth\nPlease note: \"LastDay, LastWeek, LastMonth” delta files are only retained\nfor a period of 31 days. “IntraDay” are however retained for a longer\nduration in accordance with the filetypes “lei2, rr, repex”.\nGLEIF Golden Copy and Delta Files Specification and User Page 14 of 16\nManual\n@ Public Version 2.2\n2022-02-23_gleif-golden-copy-and-delta-files_v2.2-final.docx 2022-02-24\n","contentLength":2169,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:38:56.880Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-golden-copy/2022-02-23_gleif-golden-copy-and-delta-files_v2.2-final.pdf","content":"3 How can | interpret the GLEIF Golden Copy\nFiles data once downloaded?\n3.1 Data element (“attribute”) definitions\nTo understand the definitions of the standardized codes in LEI data fields, please see the detailed\ntechnical specifications (human readable documentation) for the LEl Common Data File formats.\n3.2 Technical validation and database import\nSoftware applications may require the XML Schema Definition (XSD) file to process the\nConcatenated Files. The latest versions of the technical specifications and XSDs for all CDF formats\ncan be found www.gleif.org.\nPlease note: It the GLEIF Golden Copy Files are not a database and so\nthere is no documentation detailing tables, relationships between tables\nor database validation rules. The GLEIF Golden Copy File and the CDF\nformats are also not intended as database design guidance, though they\ncould be used to inform such a process. GLEIF does not provide tool\nsupport; instead, we recommend consulting your IT team for any complex\ntasks.\nThe JSON and CSV versions of the Golden Copy Files are based directly on the XML versions each file\ntype as described above.\nTherefore, although they cannot be directly validated using an XML schema, their data content will\nconform to the requirements of the corresponding CDF format schema XML, e.g. in terms of code\nstructures, enumerated values, character set and string length of free text fields, etc.\n3.3 Data management rules\nLEI Issuers are also required to create and update CDF files according to the State Transition and\nValidation Rules (ST/VR) for the relevant CDF format.\nThese data management rules are provided by GLEIF in addition to the CDF XML Schemas, and LEI\nIssuers must follow them in order to achieve high data quality scores, but they are not necessarily all\nautomatically enforced by GLEIF.\nPlease find the State Transition/Validation Rules at the GLEIF Common Data File Formats pages on\nwww.gleif.org.\nGLEIF Golden Copy and Delta Files Specification and User Page 15 of 16\nManual\n@ Public Version 2.2\n2022-02-23_gleif-golden-copy-and-delta-files_v2.2-final.docx 2022-02-24\n","contentLength":2098,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:38:56.881Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-golden-copy/2022-02-23_gleif-golden-copy-and-delta-files_v2.2-final.pdf","content":"4 Where can | find further information?\n\n4.1 General questions\n\nPlease address any queries which are not specifically technical in nature to:\n\ninfo@gleif.org\n\n4.2 Technical support\n\n4.2.1 LEl Issuer files\n\nIf you have any questions regarding the original source files, please contact the respective LEI Issuer\n\nvia its website.\n\nContact details for all LEI Issuers can be found on the Original Sources page at www.gleif.org.\n\n4.2.2 Whom should I contact for further questions?\n\nIf you have any questions regarding the GLEIF Golden Copy Files downloaded from the GLEIF\n\nWebsite, please contact GLEIF directly at: info@gleif.org.\nGLEIF Golden Copy and Delta Files Specification and User Page 16 of 16\nManual\n\n@ Public Version 2.2\n\n2022-02-23_gleif-golden-copy-and-delta-files_v2.2-final.docx 2022-02-24\n","contentLength":801,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:38:56.881Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-golden-copy/2022-02-23_gleif-golden-copy-and-delta-files_v2.2-final.pdf","content":"- 2.2\n- Head of IT Development and Operations (GLEIF IT)\nAbout this Document\nThis document:\no Describes the GLEIF Golden Copy and Delta Files.\no Explains how to download and use the Files.\nChange History\nThis section records the history of all changes to this document.\n2022-02-24 2.2 Updated the File retrieval URL’s section GLEIF\n2020-08-11 2.1 Enhanced URLs amended (Aliases) GLEIF\n2020-07-10 2.0 Second published version GLEIF\n2018-02-08 1.0 First published version GLEIF\nWhere changes are made for clarity and reading ease only and no change is made to the meaning or\nintention of this document, the version number will be increased by 0.1.\nWhere significant changes are made to this document, the version number will be incremented by\n1.0.\nGLEIF Golden Copy and Delta Files Specification and User Page 3 of 16\nManual\n@ Public Version 2.2\n2022-02-23_gleif-golden-copy-and-delta-files_v2.2-final.docx 2022-02-24\n","contentLength":916,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:38:56.881Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-golden-copy/2022-02-23_gleif-golden-copy-and-delta-files_v2.2-final.pdf","content":"1 About the GLEIF Golden Copy Files\nThe Golden Copy LEI record file (Level 1 data) contains each LEI code exactly\nonce. The Golden Copy relationships and relationship reporting exceptions\n(Level 2) files contain only allowed combinations of reporting items, and only\ncurrent Level 2 reporting information, i.e., relationship records with\nRegistrationStatus = PUBLISHED, or LAPSED.\nGLEIF offers Golden Copy Files free of charge to any interested user, but please\ntake note of the LEI Data Terms of Use at www.gleif.org.\n1.1 What is the responsibility of LEl Issuers and GLEIF in publishing\nGolden Copy Files?\nLEl Issuers — also referred to as Local Operating Units (LOUs):\no supply registration, renewal, and other services, and\ne act as the primary interface for Legal Entities wishing to obtain an LEL.\nThey assign LEls to, and collect information on, Legal Entities, and publish this information daily in\noriginal source files, both at their public websites and via direct upload to GLEIF’s systems, for\nproduction of the centralized Global LEI Index.\nGLEIF\n* maintains an archive of all uploaded LEI Issuer files (GLEIF Concatenated Files) for audit purposes.\no checks these files for basic standards compliance (Common Data File formats);\no produces data quality feedback that is passed on to the LEl Issuers, and\no compiles Golden Copy Files containing the latest version of each LEI record (Level 1 data)\nreceived from any LEI Issuer, and their associated relationship records and reporting exceptions\n(Level 2 data).\n1.2 What is included in the Golden Copy Files?\n¢ GLEIF Golden Copy Files’ content includes:\no All Legal Entity Identifiers (LEIs) globally;\no Allrelated LEI Reference Data (LE-RD), including:\no Level 1:\n¢ ldentification data for each Legal Entity itself;\nGLEIF Golden Copy and Delta Files Specification and User Page 4 of 16\nManual\n@ Public Version 2.2\n2022-02-23_gleif-golden-copy-and-delta-files_v2.2-final.docx 2022-02-24\n","contentLength":1950,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:38:56.881Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-golden-copy/2022-02-23_gleif-golden-copy-and-delta-files_v2.2-final.pdf","content":"o Level 2:\no Relationships to other Legal Entities (where applicable);\n* Reasons for lack of relationship reporting (“reporting exceptions”; where\napplicable)\nPlease note: Only technically valid (XML schema valid) LEl issuer source files\nare used in the Golden Copy Files.\nDelta Files, based on the Golden Copy Files, contain a sub-set of the most recent Golden Copy\ndefined as only the new or changed records since a previous Golden Copy specified by the user.\n1.3 What if one or more LEIl Issuers upload the same LEI more than\nonce, or a disallowed combination of relationship reporting?\nAttempts to upload duplicate LEls are rejected by GLEIF’s database (although they are kept on record\nfor audit). Duplication is prevented according to the following business rules:\no For LEI (legal entity data) records:\no Anew LEl record is created in the Golden Copy when GLEIF receives an LEI record\ncontaining a new unique LEI code (i.e. one not previously uploaded to GLEIF).\no Existing records are updated only if:\ne achanged version of the LEI data record is uploaded with the same LEI code (in\nthe data field) as in the database, and\no the current LEl Issuer of the LEI, according to the database, is the LEI Issuer\nwhose LEl is found in the field of the uploaded record, and\no the uploader of the file (whose LEI code is found in the field, is\nthe same as the current LEI Issuer of the LEl, and\no thereis no other, contradictory (i.e., different) record in the same LEI Issuer file\nwith the same LEI code.\no Exception: the current LEI Issuer explicitly marks the LEIl record as ready for\ntransfer (lei:RegistrationStatus = “PENDING_ARCHIVAL\") so that the new LEI\nIssuer may update the record with a different, appropriate post-transfer status,\nand become the record’s new “owner”.\nPlease note: In the case of an LEl transfer, no additional LEl record is\ncreated. The same single record is simply updated and assigned to a new\n“owner” who is allowed to update it.\nGLEIF Golden Copy and Delta Files Specification and User Page 5 of 16\nManual\n@ Public Version 2.2\n2022-02-23_gleif-golden-copy-and-delta-files_v2.2-final.docx 2022-02-24\n","contentLength":2177,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:38:56.881Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-golden-copy/2022-02-23_gleif-golden-copy-and-delta-files_v2.2-final.pdf","content":"o For relationship records:\n* A new relationship record is created in the Golden Copy only when\no GLEIF receives a new, unique relationship record (“unique” as below),\ne = “PUBLISHED”, or “LAPSED” and\no the LEl of the “child” entity already exists in the database.\nPlease note: The RegistrationStatus of the relationship record is “LAPSED”,\nwhen the Child LEIl is not renewed within the date specified in the\nNextRenewalDate field in the Registration details section of the relationship\nrecord.\no Relationship Records are updated by new versions only when\no they are considered unique and matched against uploaded records based on the\ncombination of their:\no (the LEI of the “child” entity),\no \no the LEl of the “child” entity already exists in the database.\nFor reporting exceptions:\nA new Reporting Exception is created in the Golden Copy when GLEIF receives a new, unique\nReporting Exception (“unique” as below).\ne Acurrent relationship record of a given relationship type always replaces an existing Reporting\nException of the same type for a given “child” LEL.\no Reporting Exceptions are considered unique based on the combination of their:\no (i.e. LEI code of the “child” entity),\no (type of relationship).\nPlease note:\nThe rules for creating, updating and removing Level 2 information from the\nGolden Copy Files (not from the Concatenated Files) mean that non-current\n(historical, and also erroneous) relationships and / or reporting exceptions\nmay not be found in a given Golden Copy File, even though they are in the\nConcatenated Files (i.e. audit trail) of the same day.\nLEI records, however, are never deleted from the Golden Copy.\nGLEIF Golden Copy and Delta Files Specification and User Page 6 of 16\nManual\n@ Public Version 2.2\n2022-02-23_gleif-golden-copy-and-delta-files_v2.2-final.docx 2022-02-24\n","contentLength":1913,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:38:56.881Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-golden-copy/2022-02-23_gleif-golden-copy-and-delta-files_v2.2-final.pdf","content":"1.4 How up-to-date are the GLEIF Golden Copy Files?\n\nGLEIF makes all of the latest Golden Copy Files available three times daily at 8 hour intervals by:\n\na) 02:00 UTC+0\n\nb) 10:00 UTC+0\n\nc) 18:00 UTC+0\n\nThis publication schedule is intended to provide a realistic level of timeliness for all major global\n\nbusiness time zones, given the likely time needed for updates to LEIl data and changes to legal\n\nentities themselves and the relationships between them.\n\nLEI Issuers can upload their files at any time of day and are required to upload at least one full file of\n\neach type (i.e., all LEl Records, relationship record, and reporting exceptions they manage) per day.\n\nDepending on specific LEl Issuers’ upload schedules, there may therefore be a delay of up to 24 hours\n\nbefore a change made, or a new LEl issued is reflected in the latest Golden Copy File.\n\nAll GLEIF Golden Copy Files are provided with ZIP compression for reduced disk space and download\n\nbandwidth consumption.\n\n1.5 How can | download updates to GLEIF Golden Copy Files (Delta\n\nFiles)?\n\nIn addition to Golden Copy Files, which always contain the most recent version of all LEI records,\n\nGLEIF makes Delta Files available.\n\nDelta Files contain only the most recent version of those LEI records which have been changed or\n\nnewly uploaded to GLEIF (for the first time ever) since the delta start time and date.\n\nTechnical details of how to obtain Delta Files can be found below. As noted below, Delta Files are\n\ncreated as the difference between full Golden Copy Files. They are made available in three pre-\n\ndefined time increments per day as above.\n\nThe delta start can be specified as:\n\n¢ one Golden Copy publication (intra-day),\n\ne one day (three publications),\n\ne one week (7 days) or\n\n¢ one month (31 days) before the present Golden Copy File.\n\nDelta Files are typically used to update a local copy of the Global LEI Index, after first creating the\n\nlocal copy from a complete Golden Copy File.\nGLEIF Golden Copy and Delta Files Specification and User Page 7 of 16\nManual\n\n@ Public Version 2.2\n\n2022-02-23_gleif-golden-copy-and-delta-files_v2.2-final.docx 2022-02-24\n","contentLength":2142,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:38:56.881Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-golden-copy/2022-02-23_gleif-golden-copy-and-delta-files_v2.2-final.pdf","content":"Please note:\nRelationship records with any status other than “PUBLISHED” or “LAPSED” are\nremoved from the Golden Copy.\nDelta Files that reflect this change contain the record to be deleted with an\nadded deletion flag in the Extension field.\n1.6 What is the format of the GLEIF Golden Copy Files?\nGolden Copy Files are provided in a range of technical formats to meet various user requirements.\n1.6.1 File compression\nAll GLEIF Golden Copy Files are provided with ZIP compression for reduced disk space and download\nbandwidth consumption.\nPlease note: When working with such very large files, downloading, opening\nand manipulating the file may be interrupted sometimes due to e.g. lack of\nsufficient memory. For large numbers of records this could be impractical and a\nspecialized tool e.g., a dedicated XML, JSON or CSV editor or parser, is needed.\n1.6.2 Data content standards\nEach type of information is provided by the LEI Issuer according to its own Common Data File (CDF)\nformat, an XML Schema and content specification:\nLEI-CDF Legal Entity identification (LEl code, Legal Entity information)\nRR-CDF Relationships between Legal Entities (LEI to LEI relationships)\nRepEx Reporting Exceptions (reasons for relationship non-reporting)\nPlease see the GLEIF Common Data File Formats page for general and technical details of each CDF\nformat.\nGLEIF Golden Copy and Delta Files Specification and User Page 8 of 16\nManual\n@ Public Version 2.2\n2022-02-23_gleif-golden-copy-and-delta-files_v2.2-final.docx 2022-02-24\n","contentLength":1513,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:38:56.881Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-golden-copy/2022-02-23_gleif-golden-copy-and-delta-files_v2.2-final.pdf","content":"1.6.3 File formats\nFiles complying to each of the above data content standards can be offered in the following common\nfile formats:\nXML XML files in UTF-8 (Unicode) encoding, valid against the\ncorresponding Common Data File format XML schema.\nJSON JSON files in a format corresponding to the nested XML tag structure\nof the corresponding Common Data File format XML schema.\ncsv CSV files in a tabular format that limits some repeatable fields found\nin the XML and JSON data formats to a useful number of instances.\nPlease note:\nXML, JSON and CSV files are plain text files, whose content is formatted in an\nefficient, machine-readable way. They are extremely large files, not intended\nto be opened in typical text editors or productivity applications and used\nmanually.\nGLEIF Golden Copy Files in JSON and XML formats cannot be directly opened\nwith e.g., Excel or Access. Normally a specialized tool is needed. Any XML or\nJSON parser can be used to incorporate the content into a given environment.\nIt is typically imported directly into a database or parsed and analyzed using\nbespoke software.\nGLEIF does not provide tool or application support; instead, we recommend\nconsulting your IT team for any complex tasks.\n1.7 What if an LEl Issuer’s source file is not technically valid?\nEach type of LEl Issuer source file must be compliant with the latest version of the relevant Common\nData File format.\nThis means that LEI Issuer source files which were not compliant with the Common Data File format\nat upload are excluded from creating or updating records in the GLEIF Golden Copy Files. Data from\nan earlier compliant version of the entire source file, if available, is used in the Golden Copy File in\nthis case.\nGLEIF Golden Copy and Delta Files Specification and User Page 9 of 16\nManual\n@ Public Version 2.2\n2022-02-23_gleif-golden-copy-and-delta-files_v2.2-final.docx 2022-02-24\n","contentLength":1885,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:38:56.881Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-golden-copy/2022-02-23_gleif-golden-copy-and-delta-files_v2.2-final.pdf","content":"1.8 How are the GLEIF Golden Copy Files created?\n\n1.8.1 LEl Issuer - file upload\n\nThe LEI Issuers upload their original source files to GLEIF. Each LOU must upload at least once per day\n\n(counted from 00:00:00 UTC-0) and may provide up to 10 successful intraday updates total per day.\n\n1.8.2 GLEIF - Golden Copy production\n\nThree times daily, GLEIF updates the central LEI database and produces a set of Golden Copy Files:\n\n1. Individual LEl Issuer source file headers are stored for reference but not included in the\nGolden Copy Files.\n\n2. New LEl records are created if the LEI has never existed in the LEI database before.\n\n3. New, current relationship and reporting exception records are created per existing LEI.\n\n4. Duplicate LEI records (and historical relationship / reporting exception records, and\nthose for unknown LEls) are excluded from the database, but always stored separately\nfor audit purposes.\n\n5. Existing LEl, relationship and reporting exception records are updated if changes are\ndetected since the last update.\n\n6. Geocoding information is added to all LEl records.\n\n7. Golden Copy Files are produced by concatenating all current records of a single file type\n(LEI, relationship, or reporting exception), and adding a GLEIF file header to each of the\nthree XML files.\n\n8. Golden Copy Files in JSON and CSV formats are produced from each of the three XML\nfiles.\n\n9. The Golden Copy files are made available through the GLEIF.org website.\n\n1.9 Does GLEIF validate the LEl Issuers’ original source files?\n\nThe content of the original LEIl Issuer source files is not validated by GLEIF. They are only checked\n\ntechnically to verify compliance with the XML Schema of the respective Common Data File format.\n\nContent issues should be communicated to the managing LEI Issuer associated with the data in\n\nquestion.\n\n1.10 What extra information is added by GLEIF?\n\nNo data is changed by GLEIF, but a number of enhancements are included in the Golden Copy files.\n\nGLEIF adds geocoded versions of addresses found in the LEI data to each LEI record, using the\n\n data element foreseen for this purpose. These additional versions do not\n\nreplace or change the original LEl data provided by the LEl Issuer.\n\nThe geocoded addresses add:\n\n¢ Normalized address fields which offer a more consistent format across all data records.\n\n* Longitude / latitude coordinates for automatic processing of the address location.\n\nGLEIF Golden Copy and Delta Files Specification and User Page 10 of 16\nManual\n\n@ Public Version 2.2\n2022-02-23_gleif-golden-copy-and-delta-files_v2.2-final.docx 2022-02-24\n","contentLength":2610,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:38:56.881Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/download-bic-to-lei-relationship-files/2023-03-23_bic-to-lei-factsheet_v1.3-final.pdf","content":"]\nBIC to LEl mapping table\nFactsheet\no\n","contentLength":39,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:39:09.317Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/download-bic-to-lei-relationship-files/2023-03-23_bic-to-lei-factsheet_v1.3-final.pdf","content":"Z 1NN\n\n(L 1 \\\\\n\nSWIFT @\n\n\\A\\_L_//\n\nAN\n\n1. Introduction\nSWIFT is a global member-owned cooperative and the world’s leading provider of secure financial\nmessaging services. SWIFT is committed to providing actionable global ID and reference data services\nand products, like the business identifier code (BIC), to global market participants, including regulators\nand the financial services industry to uniquely identify, classify and describe entities and financial\ninstruments.\nSWIFT is the registration authority for the ISO 9362 (BIC) standard appointed by ISO. In this role, SWIFT\nreceives BIC registration requests, assigns a BIC, and publishes the related BIC Data Record as defined in\nand in accordance with the requirements set out in ISO 9362.\nThe BIC is an international standard for identification of institutions within the financial services\nindustry. BICs are used in automated processing. They identify a financial institution or a non-financial\ninstitution.\nThe Global Legal Entity Identifier Foundation (GLEIF) is a not-for-profit organization created to support\nthe implementation and use of the Legal Entity Identifier (LEI). GLEIF manages a network of partners,\nthe Local Operating Units, to provide trusted services and open, reliable data for unique legal entity\nidentification worldwide.\nThe Legal Entity Identifier (LEI) is a 20-digit, alpha-numeric code based on the ISO 17442 standard\ndeveloped by ISO. It connects to key reference information that enables clear and unique identification\nof legal entities participating in financial transactions.\nIn this context, GLEIF and SWIFT are publishing a BIC-to-LEl mapping reference file, which will be\nupdated on a monthly basis and made publically available.\nThe file is built upon a mapping process established by SWIFT and certified by GLEIF. The purpose of this\nfactsheet is to describe the reference data involved, the analysis applied to map the BICs to the LEls, and\nthe ongoing update process.\n2. Reference Data\nThe SWIFT BIC Directory is the source for the BIC and BIC reference data. Additional information on this\ndata source including field definitions can be found here.\nThe GLEIF Concatenated File is the source for the LEIs and the legal entity reference data. Additional\ninformation on the GLEIF Concatenated Files and the Common Data File formats can be found here.\nThe BIC-to-LEI mapping table does not include historical BIC/LEI pairs, stand-alone unmapped BICs and\nLEls, nor the listing of daily or monthly changes. These can be obtained here.\nThe following table describes the critical fields considered for mapping.\nPublic Use\nAuthor: GLEIF and SWIFT | Version: Final 1.3 | 2023-03-23 Page 2 of 4\n","contentLength":2686,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:39:09.317Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/download-bic-to-lei-relationship-files/2023-03-23_bic-to-lei-factsheet_v1.3-final.pdf","content":"]\n)\n@\n&\n\nTable 1 - Critical Fields Considered for Mapping\n=5 1 S il\nComments\nLegal Type LE (legal entity) or FB Registration Status LEls with Registration\n(foreign branch) and Status of ANNULLED or\n# INACTIVE status. DUPLICATE are excluded\nInstitution The institution name Legal Name The LEI reference data\nName is not always the Other Entity Names or includes the legal name as\nlegal name; it can Transliterated Other well as other names and a\nalso refer to business Entity Names transliterated name given\nor operational the legal name includes\nnames. non-latin characters. If\nOnly latin characters available, “other entity\nare permitted in this names” in English will be\nfield. used.\ne, |\ncode of the country Other Address Country\n3. Analysis\nIn October 2017, there were around 120,000 BIC codes in the BIC Directory, 35,000 of which qualify as\n\"legal entities\" and 6,400 as foreign branches. Hence, approximately 41,000 BICs initially qualify for\nmapping as these legal entity types also qualify for LEI registration. All other BIC codes have been\nassigned to entities such as bank branches trading desks, departments, or test and development\nsystems or represent SWIFT network addresses and, therefore, no mapping to LEl is applicable.\nAs of October 2017, around 560,000 active LEls have been issued.\nAfter automated review by SWIFT, reconciling differences between the critical fields considered for\nmapping (see Table 1) requires manual review. A sampling demonstrates the following:\n¢ The BIC is not always accompanied with the legal name of the entity; often commercial names\nor even historical names (names before a merger) are kept on purpose so as not to disrupt the\npayment flow after mergers and acquisitions. In order to map such BICs correctly to the LEls, the\nlinking process requires a manual analysis of the entity’s history. Transliteration standards differ\nbetween SWIFT and the Global LEI System. The inclusion of special characters in legal names and\naddresses requires manual review by SWIFT.\n4. On-going update process\nThis section describes what changes (events) to the underlying datasets trigger update to the mapping\ndiscussed in the section above.\nPublic Use\nAuthor: GLEIF and SWIFT | Version: Final 1.3 | 2023-03-23 Page 3 of 4\n","contentLength":2258,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:39:09.317Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/download-bic-to-lei-relationship-files/2023-03-23_bic-to-lei-factsheet_v1.3-final.pdf","content":"Z 1NN\n(T 1Y\\\nSWIFT @\n1L/\nAN\nTable 2: The change to an LEI or BIC (event) and the consequent update to the BIC/LEI pair\n[Bvent |Update\nA new BIC or LEl is issued. The BIC or LEl is considered for mapping.\nIn a BIC/LEI pair the BIC became inactive. The BIC/LEI pair is removed.\n. If a Successor LEl is present, the BIC is re-\nIn a BIC/LEI pair the LEI became ANNULLED or . B ”\nmatched with the “Successor LEI”. The\nDUPLICATE. . .\nprevious BIC/LEI pair is removed.\nIf a Successor LEl is present, the BIC is\nmatched with the “Successor LEI”. The\nprevious BIC/LEI pair is preserved for 2 years\nand will be removed after.\nIn a BIC/LEI pair the LEI became RETIRED or If a Successor LEl is not present, the BIC is not\nMERGED. mapped to another LEl and the BIC/LEI pair is\npreserved for 2 years.\nIf in a BIC/LEI pair the BIC merges to another\nBIC, then SWIFT investigates the impact to\nthe pair.\nIn a BIC/LEI pair any of the BIC or LEI data The BIC/LEI pair is reviewed to determine if\nfields considered as equivalent mapping (see | the match is still applicable, and is removed if\nTable 1) change. not applicable anymore.\nUsers of the BIC-to-LEl mapping reference file may challenge individual BIC/LEI pairs via GLEIF's data\nchallenge facility available on gleif.org in 2018. The GLEIF data challenge facility will provide any user of\na BIC-to-LEl mapping reference file with the opportunity to substantiate doubts regarding individual\nBIC/LEI pairs. Challenging several BIC/LEI pairs requires entering one challenge per record. Further\ndetails will be made available on the GLEIF website in 2018. General questions on the BIC-to-LEl\nmapping table can be sent to GLEIF at info@gleif.org.\n5. File Specifications\nThe file is published in comma-separated format (csv) contained in a zip file. It contains all BIC-LEI pairs,\ni.e.is a “full” file. No “delta” file is made available. The file does not contain BICs that do not have\ncorresponding LEls nor LEls without corresponding BICs.\nThe file contains the following data:\nPublic Use\nAuthor: GLEIF and SWIFT | Version: Final 1.3 | 2023-03-23 Page 4 of 4\n","contentLength":2094,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:39:09.317Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/download-bic-to-lei-relationship-files/2017-12-21_annex-2_bic-to-lei-mapping-table-license-agreement_final.pdf","content":"ANNEX II\nLicense Agreement for the provision and use of the BIC/LEI Mapping Table\n(“BIC/LEI Mapping Table License Agreement”)\n\nStatement of Purpose\nSW.LF.T. SCRL (\"SWIFT\") has developed a mapping table between BICs and LEIs (hereafter\nreferred to as the \"Mapping Table\").\nThe Mapping Table includes BICs supplied by SWIFT as the designated ISO Registration\nAuthority (\"RA\") for the ISO 9362 Standard and LEIs supplied by the Global Legal Entity\nIdentifier Foundation (\"GLEIF\").\nThe Mapping Table is available on the website of GLEIF and updated monthly. For the latest\nBIC information and updates, always refer to www.swift.com/bic.\n1. Copyright and Related Rights. The Mapping Table made available hereunder may be\nprotected by copyright and related or neighboring rights (\"Copyright and Related Rights\").\nCopyright and Related Rights include, but are not limited to, the following:\n\ni. the right to reproduce, adapt, distribute, perform, display, communicate, and translate a\nwork;\n\nii. moral rights retained by the original author(s) and/or performer(s);\n\niii. publicity and privacy rights pertaining to a person's image or likeness depicted in a work;\n\niv. rights protecting against unfair competition in regards to a work, subject to the limitations\nin paragraph 3(a), below;\n\nv. rights protecting the extraction, dissemination, use and reuse of data in a work;\n\nvi. database rights (such as those arising under Directive 96/9/EC of the European\nParliament and of the Council of 11 March 1996 on the legal protection of databases, and\nunder any national implementation thereof, including any amended or successor version\nof such directive); and\n\nvii. other similar, equivalent or corresponding rights throughout the world based on\napplicable law or treaty, and any national implementations thereof.\n\n2. License: To the greatest extent permitted by, but not in contravention of applicable law,\nSWIFT and, for the LEIs included in the Mapping Table, GLEIF (individually and/or\ncollectively referred to as \"Affirmer\") hereby grant each member of the public at large a non-\nexclusive, transferable, sub-licensable and royalty-free license to use the Mapping Table (i) in all\nterritories worldwide, (ii) for the maximum duration provided by applicable law or treaty\n(including future time extensions), (iil) in any current or future medium and for any number of\ncopies, and (iv) for any purpose whatsoever, including without limitation commercial,\nadvertising or promotional purposes provided always that any copy of the Mapping Table, in\nwhole or in part, includes the following notice:\n","contentLength":2588,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:39:17.866Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/download-bic-to-lei-relationship-files/2017-12-21_annex-2_bic-to-lei-mapping-table-license-agreement_final.pdf","content":"\"SWIFT © and database rights [insert date (i.e. month and year) of the Mapping Table version|.\nAll rights reserved.\n\nThis Mapping Table has been developed by SWIFT. Any use of the Mapping Table, in whole or\nin part, is subject to the BIC/LEI Mapping Table License Agreement as published with the\nMapping Table available on GLEIF’s website.\n\nThe Mapping Table is updated monthly. For the latest BIC information and updates, always\nrefer to www.swift.com/bic .\"\n\nNo other rights are granted in respect of the Mapping Table except those provided under this\nBIC/LEI Mapping Table License Agreement.\n\n3. Limitations and Disclaimers.\n\na. No trademark or patent rights held by Affirmer are waived, abandoned, surrendered,\nlicensed or otherwise affected by this BIC/LEI Mapping Table License Agreement.\n\nb. Affirmer offers the Mapping Table as-is and makes no representations or warranties of\nany kind concerning the Mapping Table, express, implied, statutory or otherwise,\nincluding without limitation warranties of title, merchantability, fitness for a particular\npurpose, non-infringement, compatibility with any particular platforms or operating\nsystems or the absence of latent or other defects, accuracy, completeness or the present or\nabsence of errors, whether or not discoverable, all to the greatest extent permissible under\napplicable law.\n\nc. Affirmer disclaims responsibility for clearing rights of other persons that may apply to\nthe Mapping Table or any use thereof, including without limitation any person's\nCopyright and Related Rights in the Mapping Table. Further, Affirmer disclaims\nresponsibility for obtaining any necessary consents, permissions or other rights required\nfor any use of the Mapping Table.\n","contentLength":1719,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:39:17.866Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/download-bic-to-lei-relationship-files/2018-03-01_csv_import_guide_v1.1.pdf","content":": > Enabling global identity\nGLEI F Protecting digital trust\nCSV | t Guid\nFINAL V1.1 2018-03-01\nThis short guide demonstrates how to prepare and open a CSV data file using a spreadsheet\napplication such as Excel.\nIt does not cover all possible ways to open files. It is intended to draw attention to problems\nthat can be avoided when working with data files in this format.\nPublic\nVersion 1.1\n2018-03-01\n","contentLength":404,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:39:34.126Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/download-bic-to-lei-relationship-files/2018-03-01_csv_import_guide_v1.1.pdf","content":"Please note:\nGLEIF does not provide tool support, so we are not able to give detailed advice on your organization’s\nparticular systems or workflows. The examples here are for illustration and you may need to adapt\nto your local operating system and / or application. We recommend consulting your IT team for any\ncomplex tasks.\n1 Download file\nFirst download the file from the GLEIF.org website.\nRight-click on the file and select “Save As...” to save the file locally (please do not open it yet).\nThe data file has the filename extension “.csv”.\nDo not double click the data file immediately.\n2 Open Excel\nOnce the data file has been downloaded, do not directly open it.\ne Instead, find your spreadsheet application (e.g. Excel) and open it.\ne Create a new (blank) workbook:\n[ X X ] Microsoft Excel\nC g, N Total a List —\n> : B\nE Take a - o=\ntour . B\n@ Blank Workbook Welcome to Excel Make a List Total a list Track My Task\n[ 0]\n. Budget —_— et ‘ = — p— - \\\n2 0 =k wlly Hule\n- o Dol . [ = -\nCSV Import Guide Page 2 of 7\n@ Public Version 1.1\n2018-03-01_CSV_Import_Guide_V1.1 2018-03-01\n","contentLength":1084,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:39:34.126Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/download-bic-to-lei-relationship-files/2018-03-01_csv_import_guide_v1.1.pdf","content":"With some versions of Excel you may need to do this from a menu, such as:\n@ Excel File Edit View Insert Format Tools Data Window Help\n3 Set up import\nOnce a new workbook is open, select this option from the File menu:\nA dialog will now begin, guiding you through the steps of importing a file.\nYou need to repeat the steps in sections 2 until the end, for each file you wish to use.\nCSV Import Guide Page 3 of 7\n@ Public Version 1.1\n2018-03-01_CSV_Import_Guide_V1.1 2018-03-01\n","contentLength":477,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:39:34.127Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/download-bic-to-lei-relationship-files/2018-03-01_csv_import_guide_v1.1.pdf","content":"4 Import dialog\n4.1 Select file type\n1. Select CSV.\n2. Click Import.\nImport\nSelect the type of file vou want to import:\not— t\nFileMaker Pro database\nFiles created with FileMaker Pro, like .fp5 or .fp7.\nHTML file ‘\nHyper-text markup files from your computer.\nText file\nText files, which import best when separated by tabs or spa :s.\nCancel | SRULCESS\n4.2 Select data (file) formats\nThe next step may be different, depending on the operating system, application, and even the\nversion of Excel.\nIf the application sets any of the following values correctly, please do not change them:\ne The data must be recognized as Delimited.\ne The import must start at row: 1.\ne The most important setting may not yet be detected:\nUnicode (UTF — 8)\nPlease see the next page for an example.\nMake sure that all settings that offer Unicode and / or UTF — 8 are set to this value only.\nCSV Import Guide Page 4 of 7\n@ Public Version 1.1\n2018-03-01_CSV_Import_Guide_V1.1 2018-03-01\n","contentLength":960,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:39:34.127Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/download-bic-to-lei-relationship-files/2018-03-01_csv_import_guide_v1.1.pdf","content":"Do not click Finish. Instead always click Next until the final step is complete.\nText Import Wizard - Step 1 of 3\nIf this is correct, choose Next, or choose the Data Type that best describes your data.\n_ Fixed width - Fields are aligned in columns with spaces between each field.\nUi?-8\nPreview of selected data:\nPreview of file /Users/minum /31520170630-gleif-concatenated-file-lei2.csv.\n1 |LET,Legal Name,Other Entity Names,Transliterated Other Entity Names,legal Address First Address Line,L¢\n2 |\"@37998BEFHAR09220120\" , \"SHIFT, a.s.\",\"\",\"SHIFT, AS\",\"Moyzesova 932/6\",\"\",\"\",\"\" \" \"\" \"\" \"Bratislava-Stq\n3 |\"@97900BEFHORR200321 7\" , \"Centrdlny depozitér cennych papierov SR, a.s.”,\"\",\"CENTRALNY DEPOZITAR CENNYCH\n4|\"@97908BEGK@200A2331L\" , \"DLHOPIS, o.c.p., a.s.\",\"\",\"DLHOPIS, OCP, AS\",\"Trnavské cesta 1@@\",\"\",\"\" \"\" \"\",\nS |\"@97903BEFSA000008472\" , \"VBRN s.r.0.\",\"\" ,\"VBRW SRO\",\"Hlavna ulica 1@9/62\",\"\",\"\",\"\",\"\",\"\" \"\" \"Hrochot™,\"\n6 |\"@37998BEFSA000092563\" , \"Prvé stavebnd sporitelda, a. s.\",\"\",\"PRVA STAVEBNA SPORITELNA, A S\",\"Bajkalskd\n7 |\"@37900BECX0000000644 \" ,\"IPT Investment a.s. investicny fond s premenlivym zdkladnym imanim\" \"\" \"JPT I\n8 |\"@37908BEH0RR20008743\" . \"LETICIA INVESTMENT, a. s.\".\"\", \"LETICIA INVESTMENT, A S\".\"Prvosienkowvd 5\".\"\". \"\"\nCancel -| Finish\n4.3 Set delimiters and qualifiers\nThe CSV file contains two types of special formatting characters that tell your application where to\nsplit the text into columns and rows:\ne The delimiters are commas (,).\ne The qualifiers are double quotation marks (“).\nCSV Import Guide Page 5 of 7\n@ Public Version 1.1\n2018-03-01_CSV_Import_Guide_V1.1 2018-03-01\n","contentLength":1621,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:39:34.127Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/download-bic-to-lei-relationship-files/2018-03-01_csv_import_guide_v1.1.pdf","content":"Text Import Wizard - Step 2 of 3\nThis screen lets you set the delimiters your data contains.\nDelimiters\nTab Treat consecutive delimiters as one\nSemicolon Textqualifier |\nSpace\nOther:\nPreview of selected data:\nLEI Legal Name ther Entity\n7900BEFHAB20000128 [SHIFT, a.s.\n7900BEFHO000008217 |Centrdlny depozitdr cennych papierov SR, a.s.\n7900BEGKOA20003311 |DLHOPIS, o.c.p., a.s.\n7900BE F 50000000472 s.r.o.\n7900BE FS0000008569 |Prva stavebnd sporitelfa, a. s.\n7900BECX0000000644 |JPT Investment a.s. investicny fond s premenlivym zdkladnym imanim\n7998BEHQOAB2220743 LETICIA INVESTMENT, a. s.\nCancel < Back Finish\nIf your application detects these automatically please do not change the values; simply click Next.\nIf any additional values (e.g. “Tab”) are selected, please de-select them.\nOnly Comma (,) for Delimiters and double quotation marks (“) for Text qualifier are correct.\n4.4 Set data (content) format\nThe final step is to set data content formats that are used by Excel to display and in some cases,\nprocess, the data.\nThis is essential for files containing LEls.\ne Set the LEl column to Text as shown in the next screenshot.\ne The “General” type can cause problems with some long sequences of numbers.\nCSV Import Guide Page 6 of 7\n@ Public Version 1.1\n2018-03-01_CSV_Import_Guide_V1.1 2018-03-01\n","contentLength":1304,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:39:34.127Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/download-bic-to-lei-relationship-files/2018-03-01_csv_import_guide_v1.1.pdf","content":"Text Import Wizard - Step 3 of 3\nThis screen lets you select each column and set the Data Format.\nColumn data format\nGeneral\no Text\nDate: MDY [ &\nDo not import column (Skip)\nAdvanced...\nPreview of selected data:\nJLEI Legal Name Other Entity Namg\n)97900BEFHO000000120 |1t NN\nnepennidgy v vraidl(Centralny depozitar cennych papierov SR, a.s.\nneree 38y ey IDLHOPIS, o.c.p., a.s.\nP97900BEF50000000472 |1 ISR\nnepge gL LS S MPrva stavebna sporitelha, a. s.\nnepenn e s R IPT Investment a.s. investiény fond s premenlivym zakladnym imanim\nY AR o Y EY LETICIA INVESTMENT, a. s.\nCancel < Back\n\n[}\n\nOnly click Finish when all of the steps have been checked.\n\nPlease note:\n\ne When working with very large files, downloading, opening and manipulating the file may\nbe interrupted sometimes due to e.g. lack of sufficient memory.\n\ne For large files this could be impractical and a specialized tool e.g. a dedicated CSV editor\nor parser, is needed.\n\ne For detailed technical assistance using your application, please consult the official\napplication documentation. For example, detailed information on importing CSV files to\nMicrosoft Excel can be found at:\n\nhttps://support.office.com/en-us/article/Import-or-export-text-txt-or-csv-files-5250ac4c-663c-47ce-\n\n937b-339e391393ba\nCSV Import Guide Page 7 of 7\n@ Public Version 1.1\n2018-03-01_CSV_Import_Guide_V1.1 2018-03-01\n","contentLength":1356,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:39:34.127Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/download-isin-to-lei-relationship-files/2018-03-01_csv_import_guide_v1.1.pdf","content":": > Enabling global identity\nGLEI F Protecting digital trust\nCSV | t Guid\nFINAL V1.1 2018-03-01\nThis short guide demonstrates how to prepare and open a CSV data file using a spreadsheet\napplication such as Excel.\nIt does not cover all possible ways to open files. It is intended to draw attention to problems\nthat can be avoided when working with data files in this format.\nPublic\nVersion 1.1\n2018-03-01\n","contentLength":404,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:39:50.408Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/download-isin-to-lei-relationship-files/2018-03-01_csv_import_guide_v1.1.pdf","content":"Please note:\nGLEIF does not provide tool support, so we are not able to give detailed advice on your organization’s\nparticular systems or workflows. The examples here are for illustration and you may need to adapt\nto your local operating system and / or application. We recommend consulting your IT team for any\ncomplex tasks.\n1 Download file\nFirst download the file from the GLEIF.org website.\nRight-click on the file and select “Save As...” to save the file locally (please do not open it yet).\nThe data file has the filename extension “.csv”.\nDo not double click the data file immediately.\n2 Open Excel\nOnce the data file has been downloaded, do not directly open it.\ne Instead, find your spreadsheet application (e.g. Excel) and open it.\ne Create a new (blank) workbook:\n[ X X ] Microsoft Excel\nC g, N Total a List —\n> : B\nE Take a - o=\ntour . B\n@ Blank Workbook Welcome to Excel Make a List Total a list Track My Task\n[ 0]\n. Budget —_— et ‘ = — p— - \\\n2 0 =k wlly Hule\n- o Dol . [ = -\nCSV Import Guide Page 2 of 7\n@ Public Version 1.1\n2018-03-01_CSV_Import_Guide_V1.1 2018-03-01\n","contentLength":1084,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:39:50.408Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/download-isin-to-lei-relationship-files/2018-03-01_csv_import_guide_v1.1.pdf","content":"With some versions of Excel you may need to do this from a menu, such as:\n@ Excel File Edit View Insert Format Tools Data Window Help\n3 Set up import\nOnce a new workbook is open, select this option from the File menu:\nA dialog will now begin, guiding you through the steps of importing a file.\nYou need to repeat the steps in sections 2 until the end, for each file you wish to use.\nCSV Import Guide Page 3 of 7\n@ Public Version 1.1\n2018-03-01_CSV_Import_Guide_V1.1 2018-03-01\n","contentLength":477,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:39:50.408Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/download-isin-to-lei-relationship-files/2018-03-01_csv_import_guide_v1.1.pdf","content":"4 Import dialog\n4.1 Select file type\n1. Select CSV.\n2. Click Import.\nImport\nSelect the type of file vou want to import:\not— t\nFileMaker Pro database\nFiles created with FileMaker Pro, like .fp5 or .fp7.\nHTML file ‘\nHyper-text markup files from your computer.\nText file\nText files, which import best when separated by tabs or spa :s.\nCancel | SRULCESS\n4.2 Select data (file) formats\nThe next step may be different, depending on the operating system, application, and even the\nversion of Excel.\nIf the application sets any of the following values correctly, please do not change them:\ne The data must be recognized as Delimited.\ne The import must start at row: 1.\ne The most important setting may not yet be detected:\nUnicode (UTF — 8)\nPlease see the next page for an example.\nMake sure that all settings that offer Unicode and / or UTF — 8 are set to this value only.\nCSV Import Guide Page 4 of 7\n@ Public Version 1.1\n2018-03-01_CSV_Import_Guide_V1.1 2018-03-01\n","contentLength":960,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:39:50.408Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/download-isin-to-lei-relationship-files/2018-03-01_csv_import_guide_v1.1.pdf","content":"Do not click Finish. Instead always click Next until the final step is complete.\nText Import Wizard - Step 1 of 3\nIf this is correct, choose Next, or choose the Data Type that best describes your data.\n_ Fixed width - Fields are aligned in columns with spaces between each field.\nUi?-8\nPreview of selected data:\nPreview of file /Users/minum /31520170630-gleif-concatenated-file-lei2.csv.\n1 |LET,Legal Name,Other Entity Names,Transliterated Other Entity Names,legal Address First Address Line,L¢\n2 |\"@37998BEFHAR09220120\" , \"SHIFT, a.s.\",\"\",\"SHIFT, AS\",\"Moyzesova 932/6\",\"\",\"\",\"\" \" \"\" \"\" \"Bratislava-Stq\n3 |\"@97900BEFHORR200321 7\" , \"Centrdlny depozitér cennych papierov SR, a.s.”,\"\",\"CENTRALNY DEPOZITAR CENNYCH\n4|\"@97908BEGK@200A2331L\" , \"DLHOPIS, o.c.p., a.s.\",\"\",\"DLHOPIS, OCP, AS\",\"Trnavské cesta 1@@\",\"\",\"\" \"\" \"\",\nS |\"@97903BEFSA000008472\" , \"VBRN s.r.0.\",\"\" ,\"VBRW SRO\",\"Hlavna ulica 1@9/62\",\"\",\"\",\"\",\"\",\"\" \"\" \"Hrochot™,\"\n6 |\"@37998BEFSA000092563\" , \"Prvé stavebnd sporitelda, a. s.\",\"\",\"PRVA STAVEBNA SPORITELNA, A S\",\"Bajkalskd\n7 |\"@37900BECX0000000644 \" ,\"IPT Investment a.s. investicny fond s premenlivym zdkladnym imanim\" \"\" \"JPT I\n8 |\"@37908BEH0RR20008743\" . \"LETICIA INVESTMENT, a. s.\".\"\", \"LETICIA INVESTMENT, A S\".\"Prvosienkowvd 5\".\"\". \"\"\nCancel -| Finish\n4.3 Set delimiters and qualifiers\nThe CSV file contains two types of special formatting characters that tell your application where to\nsplit the text into columns and rows:\ne The delimiters are commas (,).\ne The qualifiers are double quotation marks (“).\nCSV Import Guide Page 5 of 7\n@ Public Version 1.1\n2018-03-01_CSV_Import_Guide_V1.1 2018-03-01\n","contentLength":1621,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:39:50.408Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/download-isin-to-lei-relationship-files/2018-03-01_csv_import_guide_v1.1.pdf","content":"Text Import Wizard - Step 2 of 3\nThis screen lets you set the delimiters your data contains.\nDelimiters\nTab Treat consecutive delimiters as one\nSemicolon Textqualifier |\nSpace\nOther:\nPreview of selected data:\nLEI Legal Name ther Entity\n7900BEFHAB20000128 [SHIFT, a.s.\n7900BEFHO000008217 |Centrdlny depozitdr cennych papierov SR, a.s.\n7900BEGKOA20003311 |DLHOPIS, o.c.p., a.s.\n7900BE F 50000000472 s.r.o.\n7900BE FS0000008569 |Prva stavebnd sporitelfa, a. s.\n7900BECX0000000644 |JPT Investment a.s. investicny fond s premenlivym zdkladnym imanim\n7998BEHQOAB2220743 LETICIA INVESTMENT, a. s.\nCancel < Back Finish\nIf your application detects these automatically please do not change the values; simply click Next.\nIf any additional values (e.g. “Tab”) are selected, please de-select them.\nOnly Comma (,) for Delimiters and double quotation marks (“) for Text qualifier are correct.\n4.4 Set data (content) format\nThe final step is to set data content formats that are used by Excel to display and in some cases,\nprocess, the data.\nThis is essential for files containing LEls.\ne Set the LEl column to Text as shown in the next screenshot.\ne The “General” type can cause problems with some long sequences of numbers.\nCSV Import Guide Page 6 of 7\n@ Public Version 1.1\n2018-03-01_CSV_Import_Guide_V1.1 2018-03-01\n","contentLength":1304,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:39:50.408Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/download-isin-to-lei-relationship-files/2018-03-01_csv_import_guide_v1.1.pdf","content":"Text Import Wizard - Step 3 of 3\nThis screen lets you select each column and set the Data Format.\nColumn data format\nGeneral\no Text\nDate: MDY [ &\nDo not import column (Skip)\nAdvanced...\nPreview of selected data:\nJLEI Legal Name Other Entity Namg\n)97900BEFHO000000120 |1t NN\nnepennidgy v vraidl(Centralny depozitar cennych papierov SR, a.s.\nneree 38y ey IDLHOPIS, o.c.p., a.s.\nP97900BEF50000000472 |1 ISR\nnepge gL LS S MPrva stavebna sporitelha, a. s.\nnepenn e s R IPT Investment a.s. investiény fond s premenlivym zakladnym imanim\nY AR o Y EY LETICIA INVESTMENT, a. s.\nCancel < Back\n\n[}\n\nOnly click Finish when all of the steps have been checked.\n\nPlease note:\n\ne When working with very large files, downloading, opening and manipulating the file may\nbe interrupted sometimes due to e.g. lack of sufficient memory.\n\ne For large files this could be impractical and a specialized tool e.g. a dedicated CSV editor\nor parser, is needed.\n\ne For detailed technical assistance using your application, please consult the official\napplication documentation. For example, detailed information on importing CSV files to\nMicrosoft Excel can be found at:\n\nhttps://support.office.com/en-us/article/Import-or-export-text-txt-or-csv-files-5250ac4c-663c-47ce-\n\n937b-339e391393ba\nCSV Import Guide Page 7 of 7\n@ Public Version 1.1\n2018-03-01_CSV_Import_Guide_V1.1 2018-03-01\n","contentLength":1356,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:39:50.408Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/download-isin-to-lei-relationship-files/2021-06-08_isin-to-lei_factsheet_v1.pdf","content":"I\n| / N N \\ @ coning gt\nISIN Issuer to LElI mapping\ntable\nFactsheet\nGLEIF and ANNA\n8/6/2021\n","contentLength":92,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:40:02.660Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/download-isin-to-lei-relationship-files/2021-06-08_isin-to-lei_factsheet_v1.pdf","content":"/ N N \\ @ P gk\n1. Introduction\n\nThe Association of National Numbering Agencies (ANNA) is a global industry association promoting,\nimplementing, and maintaining standards for financial and referential instruments. ANNA is committed\nto providing actionable global ID and reference data products and services to assist global market\nparticipants, including regulators and the financial services industry, to uniquely identify, classify and\ndescribe financial and referential instruments.\n\nThe membership of ANNA, National Numbering Agencies (NNAs), play a crucial role in the financial\nmarkets of their own nations, as well as global markets. Assigned and maintained by NNAs, the\nInternational Securities Identification Number (ISIN) ISO 6166, is the recognized global standard for\nunique identification of financial and referential instruments. Coverage includes, but is not limited to,\nequity, debt, derivatives, indices and digital assets.\n\nThe Global Legal Entity Identifier Foundation (GLEIF) is a not-for-profit organization created to support\nthe implementation and use of the Legal Entity Identifier (LEI). GLEIF manages a network of partners,\nthe Local Operating Units, to provide trusted services and open, reliable data for unique legal entity\nidentification worldwide.\n\nThe Legal Entity Identifier (LEl) is a 20-digit, alpha-numeric code based on the ISO 17442 standard\ndeveloped by ISO. It connects to key reference information that enables clear and unique identification\nof legal entities participating in financial transactions.\n\nIn this context, GLEIF and ANNA are publishing an ISIN-to-LEI mapping table, which will be updated on a\ndaily basis and made publicly available.\n\nThe file is built upon a mapping process established by ANNA and certified by GLEIF. The purpose of this\nfactsheet is to describe the reference data involved and the ongoing update process.\n\n2. Reference Data\n\nThe ANNA Service Bureau (ASB) is the consolidated source of global NNA data comprising the ISIN and\nassociated reference data. Additional information on ASB data including field definitions can be found\nhere.\n\nThe GLEIF Golden Copy File is the source for the LEls and the legal entity reference data. Additional\ninformation on the GLEIF Golden Copy Files and the Common Data File formats can be found here.\n\nThe ISIN-to-LEl mapping table only includes active ISINs where a LEI mapping is available from those\nNNAs who have joined the initiative. It does not contain ISINs that do not have corresponding LEls nor\nLEIs without corresponding ISINs. A full mapping table is produced on a daily basis i.e. is a “full” file, no\nlisting of daily or monthly changes are provided.\n\nDetails of the NNAs who have joined the initiative are available on ANNA’s website, ISIN to LEI Mapping\nInitiative.\n\nAdditional ISIN data can be obtained via the free ANNA ISIN Lookup Service.\n\nPublic Use\n\nAuthor: GLEIF and ANNA | Version: 1.0 | 2021-08-06 Page 2 of 4\n","contentLength":2941,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:40:02.660Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/download-isin-to-lei-relationship-files/2021-06-08_isin-to-lei_factsheet_v1.pdf","content":"]\n/ N N \\ @ Pretecing dgta st\nThe following table describes the critical fields considered for mapping.\nTable 1 - Critical Fields Considered for Mapping\nil = S il\nComments\n\nStatus ISINs # INACTIVE Registration Status LEls with Registration\n\nstatus Status of ANNULLED,\nDUPLICATE, MERGED or\nRETIRED are excluded\n\nIssuer Name | Entity name (full Legal Name The LEI reference data\nlegal name) including Other Entity Names or includes the legal name as\nOther Entity Names Transliterated Other well as other names and a\nor Transliterated Entity Names transliterated name given\nOther Entity names the legal name includes\nwhen legal name has non-latin characters. If\nnon-Latin characters available, “other entity\n\nnames” in English will be\nused.\n\nAddress Entity legal address, Legal Address The address of the entity as\nincluding country Other Address recorded in the registration\nand Other Addresses of the entity.\nor Transliterated An optional list of other\nOther Addresses addresses for the Legal\nwhen non-Latin Entity, excluding\ncharacters have been transliterations.\nused\n\nIssuer Legal Legal Form The legal form of the entity,\n\nForm taken from the ISO Entity\n\nLegal Form (ELF) code list\nmaintained by GLEIF\n3. On-going update process\nThis section describes what changes (events) to the underlying datasets trigger updates to the mapping\ndiscussed in the section above.\nPublic Use\nAuthor: GLEIF and ANNA | Version: 1.0 | 2021-08-06 Page 3 of 4\n","contentLength":1440,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:40:02.660Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/download-isin-to-lei-relationship-files/2021-06-08_isin-to-lei_factsheet_v1.pdf","content":"/ N N \\ @ rotectng digtal st\nTable 2: The change to an LEl or ISIN issuer (event) and the consequent update to the ISIN/LEI\npair\n[Bvet |Update\n\nA new ISIN is issued. The ISIN is considered for mapping.\n\nThe ISIN/LEI pair is removed from the\nAn ISIN becomes inactive in an ISIN/LEI pair. . / . P\n\nmapping file.\n\nIf a Successor LEl is present, the ISIN is re-\nThe LEI became ANNULLED, DUPLICATE, ) > P ;\n\n. . matched with the “Successor LEI”. The\n\nMERGED or RETIRED in an ISIN/LEI pair. . .\n\nprevious ISIN/LEI pair is removed.\nThe ISIN or LEI data fields considered as The ISIN/LEI pair is reviewed to determine if\nequivalent mapping (see Table 1) change in the match is still applicable, and is removed if\nan ISIN/LEI pair. no longer applicable.\n\nUsers of the ISIN-to-LEI mapping table may challenge individual ISIN/LEI pairs via info@gleif.org.\n\nGeneral questions on the ISIN-to-LEl mapping table can also be sent to GLEIF at info@gleif.org.\n\n4. File Specifications\n\nThe mapping table is published in comma-separated format (csv) on a daily basis. It contains all ISIN-LEI\npairs, i.e. is a “full” file. No “delta” file is made available. The file does not contain ISINs that do not have\ncorresponding LEls nor LEIs without corresponding ISINs.\n\nThe mapping table contains the following data:\n\n| FILDNAME [ FORMAT [ PRESENCE | DEScRPTION |\nPublic Use\n\nAuthor: GLEIF and ANNA | Version: 1.0 | 2021-08-06 Page 4 of 4\n","contentLength":1415,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:40:02.660Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/download-mic-to-lei-relationship-files/20220902_mic_to_lei_factsheet_v1.0.pdf","content":"]\nMIC to LEl mapping table\nFactsheet\no\n","contentLength":39,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:40:15.738Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/download-mic-to-lei-relationship-files/20220902_mic_to_lei_factsheet_v1.0.pdf","content":"Z 1NN\n\n(L 1 \\\\\n\nSWIFT @\n\n\\A\\_L_//\n\nAN\n\n1. Introduction\nSWIFT is a global member-owned cooperative and the world’s leading provider of secure financial\nmessaging services. SWIFT is committed to providing actionable global ID and reference data services\nand products, like the business identifier code (BIC) and the market identifier code (MIC), to global\nmarket participants, including regulators and the financial services industry to uniquely identify, classify\nand describe entities and financial instruments.\nSWIFT is the registration authority for the ISO 10383 (MIC) standard appointed by ISO. In this role,\nSWIFT receives MIC registration requests, assigns a MIC, and publishes the related MIC Data Record in\naccordance with the requirements set out in ISO 10383.\nThe MIC is an international standard for identification of exchanges, trading platforms, regulated or non-\nregulated markets and trade reporting facilities as sources of prices and related information in order to\nfacilitate automated processing.\nThe Global Legal Entity Identifier Foundation (GLEIF) is a not-for-profit organization created to support\nthe implementation and use of the Legal Entity Identifier (LEI). GLEIF manages a network of partners,\nthe Local Operating Units, to provide trusted services and open, reliable data for unique legal entity\nidentification worldwide.\nThe Legal Entity Identifier (LEI) is a 20-digit, alpha-numeric code based on the ISO 17442 standard\ndeveloped by ISO. It connects to key reference information that enables clear and unique identification\nof legal entities participating in financial transactions.\nIn this context, GLEIF and SWIFT are publishing a MIC-to-LEI mapping reference file, which will be\nupdated on a monthly basis and made publically available. Please note that whenever there is an update\nto the MIC file during the month, a new MIC-to-LEI mapping file is also published. Therefore, there could\nbe multiple publications within a month.\nThe file is built upon a mapping process established by SWIFT and certified by GLEIF. The purpose of this\nfactsheet is to describe the reference data involved, the analysis applied to map the MICs to the LEls,\nand the ongoing update process.\n2. Reference Data\nThe directory of MICs is the source for the MIC reference data. Additional information on this data\nsource including field definitions can be found here.\nThe GLEIF Golden Copy File is the source for the LEIs and the legal entity reference data. Additional\ninformation on the GLEIF Golden Copy Files and the Common Data File formats can be found here.\nPublic Use\nAuthor: GLEIF and SWIFT | Version: 0| 2022-09-02 Page 2 of 5\n","contentLength":2648,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:40:15.739Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/download-mic-to-lei-relationship-files/20220902_mic_to_lei_factsheet_v1.0.pdf","content":"Z 1NN\n(L 1 \\\\\nSWIFT @\n\\A\\_L_//\nAN\nThe following table describes the critical fields considered for mapping.\nTable 1 - Critical Fields Considered for Mapping\nMiIC Description & LEI Description & Comments\nComments\nFields considered for pre-conditions\nSTATUS MIC with STATUS Registration Status LEIs with Registration\nDELETED are Status of ANNULLED or\nexcluded DUPLICATE are excluded\nOPRT/SGMT | Only OPRT MICs are\nconsidered for the\nmapping\npublication\nFields considered as equivalents for mapping\nName The institution name | Legal Name The LEl reference data\nis not always the Other Entity Names or includes the legal name as\nlegal name; it can Transliterated Other well as other names and a\nalso refer to business | Entity Names transliterated name given\nor operational the legal name includes\nnames. non-latin characters. If\nOnly latin characters available, “other entity\nare permitted in this names” in English will be\nfield. used.\nISO Country | ISO 3166 alpha-2 Legal Address Country\nCode code of the country Other Address Country\n3. Analysis\nIn March 2021, there were around 2,500 MICs in the directory of MICs of which about 1,000 are\nqualified as segment MICs and the remaining 1,500 qualify as operating MICs and identifying the entity\noperating an exchange, market or trade reporting facility in a specific market or country.\nHence, approximately 1,500 MICs initially qualify for mapping as these legal entity types also qualify for\nLEI registration.\nAs of March 2021, around 1,800,000 active LEls have been issued.\nAfter automated review by SWIFT, reconciling differences between the critical fields considered for\nmapping (see Table 1) requires manual review. A sampling demonstrates the following:\n¢ The MIC is not always accompanied with the exact legal name of the entity; often commercial\nnames or even historical names are kept on purpose so as not to disrupt the market. To map\nsuch MICs correctly to the LEls, the linking process requires a manual analysis of the entity’s\nhistory. Transliteration standards differ between SWIFT and the Global LEI System. The inclusion\nof special characters in legal names and addresses requires manual review by SWIFT.\nPublic Use\nAuthor: GLEIF and SWIFT | Version: 0| 2022-09-02 Page 3 of 5\n","contentLength":2243,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:40:15.739Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/download-mic-to-lei-relationship-files/20220902_mic_to_lei_factsheet_v1.0.pdf","content":"Z 1NN\n(T 1Y\\\nSWIFT @\n1L/\nAN\n4. On-going update process\nThis section describes what changes (events) to the underlying datasets trigger update to the mapping\ndiscussed in the section above.\nTable 2: The change to an LEIl or MIC (event) and the consequent update to the MIC/LEI pair\nThe MIC applicant must submit the LEI of the\nA new MIC or LEl is issued. legal entity to register the new MIC. The MIC\nor LEl is considered for mapping.\nIn a MIC/LEI pair the MIC became inactive. The MIC/LEI pair is removed.\nIf a Successor LEl is present, the MIC is re-\nIn a MIC/LEI pair the LEl became ANNULLED\n/LEIp matched with the “Successor LEI”. The\nor DUPLICATE. . .\nprevious MIC/LEI pair is removed.\nIf a Successor LEl is present, the MIC is\nmatched with the “Successor LEI”. The\nprevious MIC/LEI pair is removed.\nIf a Successor LEl is not present, the MIC is\nIn a MIC/LEI pair the LEI became RETIRED not mapped to another LEIl and the MIC/LEI\npair is deleted.\nIf in a MIC/LEI pair the MIC merges to\nanother MIC, then SWIFT investigates the\nimpact to the pair.\nIn a MIC/LEI pair any of the MIC or LEI data The MIC/LEI pair is reviewed to determine if\nfields considered as equivalent mapping (see | the match is still applicable, and is removed if\nTable 1) change. not applicable anymore.\nUsers of the MIC-to-LEI mapping reference file may challenge individual MIC/LEI pairs via GLEIF’s data\nchallenge facility available on gleif.org. The GLEIF data challenge facility will provide any user of a MIC-\nto-LEI mapping reference file with the opportunity to substantiate doubts regarding individual MIC/LEI\npairs. Challenging several MIC/LEI pairs requires entering one challenge per record. General questions\non the MIC-to-LElI mapping table can be sent to GLEIF at info@gleif.org.\nPublic Use\nAuthor: GLEIF and SWIFT | Version: 0| 2022-09-02 Page 4 of 5\n","contentLength":1841,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:40:15.739Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/download-mic-to-lei-relationship-files/20220902_mic_to_lei_factsheet_v1.0.pdf","content":"Z 1NN\n(T 1Y\\\nSWIFT @\n1L/\nAN\n5. File Specifications\nThe full MIC file is published in different formats (excel, xml, csv, pdf).\nThe MIC-to-LEl file is published in comma-separated format (csv). It contains all MIC-LEI pairs, i.e. is a\n“full” file. No “delta” file is made available. The file does not contain MICs that do not have\ncorresponding LEls nor LEls without corresponding MICs.\nThe file contains the following data:\nPublic Use\nAuthor: GLEIF and SWIFT | Version: 0| 2022-09-02 Page 5 of 5\n","contentLength":496,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:40:15.739Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/download-mic-to-lei-relationship-files/2022-09-02_mic_to_lei_mapping_table_license_agreement_v1.0.pdf","content":"ANNEX 1\nLicense Agreement for the provision and use of the MIC/LEI Mapping\nTable\n(“MIC/LEI Mapping Table License Agreement”)\n\nStatement of Purpose\nSW.IF.T. SC (\"SWIFT\") has developed a mapping between MICs and LEIs in its MIC\ndirectory.\nGLEIF extracts the mapping from the MIC Directory developed by SWIFT and publishes it\non its dedicated webpage (hereafter referred to as the \"Mapping Table\").\nThe Mapping Table includes MICs supplied by SWIFT as the designated ISO Registration\nAuthority (\"RA\") for the ISO 10383 Standard and LEIs supplied by the Global Legal Entity\nIdentifier Foundation (\"GLEIF\").\nThe Mapping Table is available on the website of GLEIF and updated monthly. For the latest\nMIC information and updates, always refer to https://www.is020022.org/market-identifier-\ncodes.\n1. Copyright and Related Rights. The Mapping Table made available hereunder may be\nprotected by copyright and related or neighboring rights (\"Copyright and Related Rights\").\nCopyright and Related Rights include, but are not limited to, the following:\n\ni. the right to reproduce, adapt, distribute, perform, display, communicate, and translate\na work;\n\nii. moral rights retained by the original author(s) and/or performer(s);\n\niii. publicity and privacy rights pertaining to a person's image or likeness depicted in a\nwork;\n\niv. rights protecting against unfair competition in regards to a work, subject to the\nlimitations in paragraph 3(a), below;\n\nv. rights protecting the extraction, dissemination, use and reuse of data in a work;\n\nvi. database rights (such as those arising under Directive 96/9/EC of the European\nParliament and of the Council of 11 March 1996 on the legal protection of databases,\nand under any national implementation thereof, including any amended or successor\nversion of such directive); and\n\nvii. other similar, equivalent or corresponding rights throughout the world based on\napplicable law or treaty, and any national implementations thereof.\n\n2. License: To the greatest extent permitted by, but not in contravention of applicable law,\nSWIFT and, for the LEIs included in the Mapping Table, GLEIF (individually and/or\ncollectively referred to as \"Affirmer\") hereby grant each member of the public at large a non-\nexclusive, transferable, sub-licensable and royalty-free license to use the Mapping Table (i) in\nall territories worldwide, (i1) for the maximum duration provided by applicable law or treaty\n","contentLength":2423,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:40:24.310Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/download-mic-to-lei-relationship-files/2022-09-02_mic_to_lei_mapping_table_license_agreement_v1.0.pdf","content":"(including future time extensions), (iii) in any current or future medium and for any number\nof copies, and (iv) for any purpose whatsoever, including without limitation commercial,\nadvertising or promotional purposes provided always that any copy of the Mapping Table, in\nwhole or in part, includes the following notice:\n\n\"SWIFT © and database rights [insert date (i.e. month and year) of the Mapping Table\nversion]. All rights reserved.\n\nThis Mapping Table has been developed by SWIFT. Any use of the Mapping Table, in whole\nor in part, is subject to the MIC/LEI Mapping 1able License Agreement as published with the\nMapping Table available on GLEIF’s website.\n\nThe Mapping Table is updated monthly. For the latest MIC information and updates, always\nrefer to https://www.is020022.org/market-identifier-codes.\"\n\nNo other rights are granted in respect of the Mapping Table except those provided under this\nMIC/LEI Mapping Table License Agreement.\n\n3. Limitations and Disclaimers.\n\na. No trademark or patent rights held by Affirmer are waived, abandoned, surrendered,\nlicensed or otherwise affected by this MIC/LEI Mapping Table License Agreement.\n\nb. Affirmer offers the Mapping Table as-is and makes no representations or warranties\nof any kind concerning the Mapping Table, express, implied, statutory or otherwise,\nincluding without limitation warranties of title, merchantability, fitness for a particular\npurpose, non-infringement, compatibility with any particular platforms or operating\nsystems or the absence of latent or other defects, accuracy, completeness or the\npresent or absence of errors, whether or not discoverable, all to the greatest extent\npermissible under applicable law.\n\nc. Affirmer disclaims responsibility for clearing rights of other persons that may apply to\nthe Mapping Table or any use thereof, including without limitation any person's\nCopyright and Related Rights in the Mapping Table. Further, Affirmer disclaims\nresponsibility for obtaining any necessary consents, permissions or other rights\nrequired for any use of the Mapping Table.\n","contentLength":2072,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:40:24.310Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/download-mic-to-lei-relationship-files/2018-03-01_csv_import_guide_v1.1.pdf","content":": > Enabling global identity\nGLEI F Protecting digital trust\nCSV | t Guid\nFINAL V1.1 2018-03-01\nThis short guide demonstrates how to prepare and open a CSV data file using a spreadsheet\napplication such as Excel.\nIt does not cover all possible ways to open files. It is intended to draw attention to problems\nthat can be avoided when working with data files in this format.\nPublic\nVersion 1.1\n2018-03-01\n","contentLength":404,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:40:40.432Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/download-mic-to-lei-relationship-files/2018-03-01_csv_import_guide_v1.1.pdf","content":"Please note:\nGLEIF does not provide tool support, so we are not able to give detailed advice on your organization’s\nparticular systems or workflows. The examples here are for illustration and you may need to adapt\nto your local operating system and / or application. We recommend consulting your IT team for any\ncomplex tasks.\n1 Download file\nFirst download the file from the GLEIF.org website.\nRight-click on the file and select “Save As...” to save the file locally (please do not open it yet).\nThe data file has the filename extension “.csv”.\nDo not double click the data file immediately.\n2 Open Excel\nOnce the data file has been downloaded, do not directly open it.\ne Instead, find your spreadsheet application (e.g. Excel) and open it.\ne Create a new (blank) workbook:\n[ X X ] Microsoft Excel\nC g, N Total a List —\n> : B\nE Take a - o=\ntour . B\n@ Blank Workbook Welcome to Excel Make a List Total a list Track My Task\n[ 0]\n. Budget —_— et ‘ = — p— - \\\n2 0 =k wlly Hule\n- o Dol . [ = -\nCSV Import Guide Page 2 of 7\n@ Public Version 1.1\n2018-03-01_CSV_Import_Guide_V1.1 2018-03-01\n","contentLength":1084,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:40:40.432Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/download-mic-to-lei-relationship-files/2018-03-01_csv_import_guide_v1.1.pdf","content":"With some versions of Excel you may need to do this from a menu, such as:\n@ Excel File Edit View Insert Format Tools Data Window Help\n3 Set up import\nOnce a new workbook is open, select this option from the File menu:\nA dialog will now begin, guiding you through the steps of importing a file.\nYou need to repeat the steps in sections 2 until the end, for each file you wish to use.\nCSV Import Guide Page 3 of 7\n@ Public Version 1.1\n2018-03-01_CSV_Import_Guide_V1.1 2018-03-01\n","contentLength":477,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:40:40.432Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/download-mic-to-lei-relationship-files/2018-03-01_csv_import_guide_v1.1.pdf","content":"4 Import dialog\n4.1 Select file type\n1. Select CSV.\n2. Click Import.\nImport\nSelect the type of file vou want to import:\not— t\nFileMaker Pro database\nFiles created with FileMaker Pro, like .fp5 or .fp7.\nHTML file ‘\nHyper-text markup files from your computer.\nText file\nText files, which import best when separated by tabs or spa :s.\nCancel | SRULCESS\n4.2 Select data (file) formats\nThe next step may be different, depending on the operating system, application, and even the\nversion of Excel.\nIf the application sets any of the following values correctly, please do not change them:\ne The data must be recognized as Delimited.\ne The import must start at row: 1.\ne The most important setting may not yet be detected:\nUnicode (UTF — 8)\nPlease see the next page for an example.\nMake sure that all settings that offer Unicode and / or UTF — 8 are set to this value only.\nCSV Import Guide Page 4 of 7\n@ Public Version 1.1\n2018-03-01_CSV_Import_Guide_V1.1 2018-03-01\n","contentLength":960,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:40:40.432Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/download-mic-to-lei-relationship-files/2018-03-01_csv_import_guide_v1.1.pdf","content":"Do not click Finish. Instead always click Next until the final step is complete.\nText Import Wizard - Step 1 of 3\nIf this is correct, choose Next, or choose the Data Type that best describes your data.\n_ Fixed width - Fields are aligned in columns with spaces between each field.\nUi?-8\nPreview of selected data:\nPreview of file /Users/minum /31520170630-gleif-concatenated-file-lei2.csv.\n1 |LET,Legal Name,Other Entity Names,Transliterated Other Entity Names,legal Address First Address Line,L¢\n2 |\"@37998BEFHAR09220120\" , \"SHIFT, a.s.\",\"\",\"SHIFT, AS\",\"Moyzesova 932/6\",\"\",\"\",\"\" \" \"\" \"\" \"Bratislava-Stq\n3 |\"@97900BEFHORR200321 7\" , \"Centrdlny depozitér cennych papierov SR, a.s.”,\"\",\"CENTRALNY DEPOZITAR CENNYCH\n4|\"@97908BEGK@200A2331L\" , \"DLHOPIS, o.c.p., a.s.\",\"\",\"DLHOPIS, OCP, AS\",\"Trnavské cesta 1@@\",\"\",\"\" \"\" \"\",\nS |\"@97903BEFSA000008472\" , \"VBRN s.r.0.\",\"\" ,\"VBRW SRO\",\"Hlavna ulica 1@9/62\",\"\",\"\",\"\",\"\",\"\" \"\" \"Hrochot™,\"\n6 |\"@37998BEFSA000092563\" , \"Prvé stavebnd sporitelda, a. s.\",\"\",\"PRVA STAVEBNA SPORITELNA, A S\",\"Bajkalskd\n7 |\"@37900BECX0000000644 \" ,\"IPT Investment a.s. investicny fond s premenlivym zdkladnym imanim\" \"\" \"JPT I\n8 |\"@37908BEH0RR20008743\" . \"LETICIA INVESTMENT, a. s.\".\"\", \"LETICIA INVESTMENT, A S\".\"Prvosienkowvd 5\".\"\". \"\"\nCancel -| Finish\n4.3 Set delimiters and qualifiers\nThe CSV file contains two types of special formatting characters that tell your application where to\nsplit the text into columns and rows:\ne The delimiters are commas (,).\ne The qualifiers are double quotation marks (“).\nCSV Import Guide Page 5 of 7\n@ Public Version 1.1\n2018-03-01_CSV_Import_Guide_V1.1 2018-03-01\n","contentLength":1621,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:40:40.432Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/download-mic-to-lei-relationship-files/2018-03-01_csv_import_guide_v1.1.pdf","content":"Text Import Wizard - Step 2 of 3\nThis screen lets you set the delimiters your data contains.\nDelimiters\nTab Treat consecutive delimiters as one\nSemicolon Textqualifier |\nSpace\nOther:\nPreview of selected data:\nLEI Legal Name ther Entity\n7900BEFHAB20000128 [SHIFT, a.s.\n7900BEFHO000008217 |Centrdlny depozitdr cennych papierov SR, a.s.\n7900BEGKOA20003311 |DLHOPIS, o.c.p., a.s.\n7900BE F 50000000472 s.r.o.\n7900BE FS0000008569 |Prva stavebnd sporitelfa, a. s.\n7900BECX0000000644 |JPT Investment a.s. investicny fond s premenlivym zdkladnym imanim\n7998BEHQOAB2220743 LETICIA INVESTMENT, a. s.\nCancel < Back Finish\nIf your application detects these automatically please do not change the values; simply click Next.\nIf any additional values (e.g. “Tab”) are selected, please de-select them.\nOnly Comma (,) for Delimiters and double quotation marks (“) for Text qualifier are correct.\n4.4 Set data (content) format\nThe final step is to set data content formats that are used by Excel to display and in some cases,\nprocess, the data.\nThis is essential for files containing LEls.\ne Set the LEl column to Text as shown in the next screenshot.\ne The “General” type can cause problems with some long sequences of numbers.\nCSV Import Guide Page 6 of 7\n@ Public Version 1.1\n2018-03-01_CSV_Import_Guide_V1.1 2018-03-01\n","contentLength":1304,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:40:40.432Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/download-mic-to-lei-relationship-files/2018-03-01_csv_import_guide_v1.1.pdf","content":"Text Import Wizard - Step 3 of 3\nThis screen lets you select each column and set the Data Format.\nColumn data format\nGeneral\no Text\nDate: MDY [ &\nDo not import column (Skip)\nAdvanced...\nPreview of selected data:\nJLEI Legal Name Other Entity Namg\n)97900BEFHO000000120 |1t NN\nnepennidgy v vraidl(Centralny depozitar cennych papierov SR, a.s.\nneree 38y ey IDLHOPIS, o.c.p., a.s.\nP97900BEF50000000472 |1 ISR\nnepge gL LS S MPrva stavebna sporitelha, a. s.\nnepenn e s R IPT Investment a.s. investiény fond s premenlivym zakladnym imanim\nY AR o Y EY LETICIA INVESTMENT, a. s.\nCancel < Back\n\n[}\n\nOnly click Finish when all of the steps have been checked.\n\nPlease note:\n\ne When working with very large files, downloading, opening and manipulating the file may\nbe interrupted sometimes due to e.g. lack of sufficient memory.\n\ne For large files this could be impractical and a specialized tool e.g. a dedicated CSV editor\nor parser, is needed.\n\ne For detailed technical assistance using your application, please consult the official\napplication documentation. For example, detailed information on importing CSV files to\nMicrosoft Excel can be found at:\n\nhttps://support.office.com/en-us/article/Import-or-export-text-txt-or-csv-files-5250ac4c-663c-47ce-\n\n937b-339e391393ba\nCSV Import Guide Page 7 of 7\n@ Public Version 1.1\n2018-03-01_CSV_Import_Guide_V1.1 2018-03-01\n","contentLength":1356,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:40:40.432Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/s-p-global-company-id-to-lei-relationship/2022-10-10_s_p_global_company_id-to-lei_factsheet_v1.0.pdf","content":"]\nS&P Global OGLEIF ) ik prapnd\nMarket Intelligence\n\nS&P Global Company ID to\nLEl mapping table\nFactsheet\nGLEIF and S&P Global Market Intelligence\n10/10/2022\n","contentLength":158,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:40:52.390Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/s-p-global-company-id-to-lei-relationship/2022-10-10_s_p_global_company_id-to-lei_factsheet_v1.0.pdf","content":"S&p GIObal Enabling global identity\n\nMarket Intelligence GGLEIF’ Protecting digital trust\n1. Introduction\nS&P Global Market Intelligence is a division of S&P Global, which provides essential intelligence for\nindividuals, companies, and governments to make decisions with confidence. S&P Global Market\nIntelligence integrates financial and industry data, research and news into tools that help track\nperformance, generate alpha, identify investment ideas, understand competitive and industry dynamics,\nperform valuation, and assess credit risk. Investment professionals, government agencies, corporations\nand universities globally can gain the intelligence essential to making business and financial decisions\nwith conviction.\nThe S&P Global Company ID is the primary key in S&P Global Market Intelligence’s Cross Reference\nServices. It links the standardized and proprietary IDs for over 28 million entities, such as the Legal Entity\nIdentifier (LEI).\nThe Global Legal Entity Identifier Foundation (GLEIF) is a not-for-profit organization created to support\nthe implementation and use of the Legal Entity Identifier (LEI). GLEIF manages a network of partners,\nthe Local Operating Units, to provide trusted services and open, reliable data for unique legal entity\nidentification worldwide.\nThe Legal Entity Identifier (LEI) is a 20-digit, alpha-numeric code based on the ISO 17442 standard\ndeveloped by ISO. It connects to key reference information that enables clear and unique identification\nof legal entities participating in financial transactions.\nIn this context, GLEIF and S&P Global Market Intelligence are publishing the S&P Global Company ID-to-\nLElI mapping pairs via LEl search 2.0, which will be updated on a weekly basis.\nThe mapping is built upon a mapping process established by S&P Global Market Intelligence and\ncertified by GLEIF. The purpose of this factsheet is to describe the reference data involved and the\nongoing update process.\n2. Reference Data\nS&P Global Market Intelligence provides the cross reference services that comprises the S&P Global\nCompany ID, associated reference data and other identifiers that associated with the entity. Additional\ninformation the cross reference services can be found here.\nThe GLEIF Golden Copy File is the source for the LEIs and the legal entity reference data. Additional\ninformation on the GLEIF Golden Copy Files and the Common Data File formats can be found here.\nThe S&P Global Company ID-to-LEI mapping only includes active S&P Global Company IDs. It does not\ncontain S&P Global Company IDs that do not have corresponding LEIs nor LEIs without corresponding\nS&P Global Company IDs. The mapping is automatically showing with the LEI Search 2.0 results.\nThe following table describes the critical fields considered for mapping.\n\nTable 1 - Critical Fields Considered for Mapping\n\nPublic Use\nAuthor: GLEIF and S&P Global Market Intelligence | Version: 1.0 | 2022-10-10 Page 2 of 4\n","contentLength":2947,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:40:52.390Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/s-p-global-company-id-to-lei-relationship/2022-10-10_s_p_global_company_id-to-lei_factsheet_v1.0.pdf","content":"]\nS&P Global @ cbing oo centiy\nMarket Intelligence GLEIF | protectin oo\n\nCompamy> | conmems © | |1 |Ceeenseommen\n\nCompanyID | Comments\n\nPrimary Key primaryKey =1 Registration Status LEls with Registration Status\n\nare excluded\n\nCompany Entity name (full Legal Name The LEl reference data\n\nName legal name) including Other Entity Names or includes the legal name as\nOther Entity Names Transliterated Other well as other names and a\nor Transliterated Entity Names transliterated name given\nOther Entity names the legal name includes\nwhen legal name has non-latin characters. If\nnon-Latin characters available, “other entity\n\nnames” in English will be\nused.\n\nAddress Entity legal address, Legal Address The address of the entity as\nincluding country Other Address recorded in the registration\nand Other Addresses of the entity.\nor Transliterated An optional list of other\nOther Addresses addresses for the Legal\nwhen non-Latin Entity.\ncharacters have been\nused\n\n3. On-going update process\n\nThis section describes what changes (events) to the underlying datasets trigger updates to the mapping\ndiscussed in the section above.\n\nPublic Use\n\nAuthor: GLEIF and S&P Global Market Intelligence | Version: 1.0 | 2022-10-10 Page 3 of 4\n","contentLength":1223,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:40:52.390Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/s-p-global-company-id-to-lei-relationship/2022-10-10_s_p_global_company_id-to-lei_factsheet_v1.0.pdf","content":"S&p GIObal Enabling global identity\nMarket Intelligence GGLE'F’ Frtechng digtl st\nTable 2: The change to an LEI or S&P Global Company ID (event) and the consequent update to\nthe S&P Global Company ID/LEI pair\n[Event ~ |Update\nThe S&P Global C IDi id f\nmapping.\nAn S&P Global Company ID becomes inactive | It depends on the status of the associated LEI\nin an S&P Global Company ID/LEI pair. as described below.\nIf a Successor LEl is present, the S&P Global\nThe LEI became ANNULLED or DUPLICATE in Company ID is re-matched with the\nan S&P Global Company ID/LEI pair. “Successor LEI”. The previous S&P Global\nCompany ID /LEI pair is removed.\nIf a Successor LEl is present, the S&P Global\nThe LEI became RETIRED in an S&P Global Company ID is re-matched with the\n. Successor LEI”. If the Successor LEl is not\nCompany ID/LEI pair. .\npresent, the previous S&P Global Company ID\n/LEI pair retains.\nThe S&P Global Company ID or LEI data fields | The S&P Global Company ID /LEI pair is\nconsidered as equivalent mapping (see Table | reviewed to determine if the match is still\n1) change in an S&P Global Company ID /LEI applicable, and is removed if no longer\npair. applicable.\nUsers may challenge individual S&P Global Company ID/LEI pairs via info@gleif.org.\nGeneral questions on the S&P Global Company ID-to-LElI mapping can also be sent to GLEIF at\ninfo@gleif.org.\nPublic Use\nAuthor: GLEIF and S&P Global Market Intelligence | Version: 1.0 | 2022-10-10 Page 4 of 4\n","contentLength":1459,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:40:52.390Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/download-oc-to-lei-relationship-files/2018-03-01_csv_import_guide_v1.1.pdf","content":"@’ Protecting ol tust\n\nCSV Import Guide\nPublic ‘ \\\nVersion 1.1\n\n2018-03-01\n","contentLength":75,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:41:09.789Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/download-oc-to-lei-relationship-files/2018-03-01_csv_import_guide_v1.1.pdf","content":"About this Document\nThis short guide demonstrates how to prepare and open a CSV data file using a spreadsheet\napplication such as Excel.\nIt does not cover all possible ways to open files. It is intended to draw attention to problems\nthat can be avoided when working with data files in this format.\nPlease note:\nGLEIF does not provide tool support, so we are not able to give detailed advice on your organization’s\nparticular systems or workflows. The examples here are for illustration and you may need to adapt\nto your local operating system and / or application. We recommend consulting your IT team for any\ncomplex tasks.\n1 Download file\nFirst download the file from the GLEIF.org website.\nRight-click on the file and select “Save As...” to save the file locally (please do not open it yet).\nThe data file has the filename extension “.csv”.\nDo not double click the data file immediately.\n2 Open Excel\nOnce the data file has been downloaded, do not directly open it.\ne Instead, find your spreadsheet application (e.g. Excel) and open it.\ne Create a new (blank) workbook:\nCSV Import Guide Page 2 of 8\n@ Public Version 1.1\n2018-03-01_CSV_Import_Guide_V1.1 2018-03-01\n","contentLength":1167,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:41:09.789Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/download-oc-to-lei-relationship-files/2018-03-01_csv_import_guide_v1.1.pdf","content":"[ X N ] Microsoft Excel\n/ [NeWAWorkbook a\nR 5 S e Total a List o i :\n3 : ('): S =\n3\n. Take a = =\nN L o $302.00\no tour -\n@ Blank Workbook Welcome to Excel Make a List Total a list Track My Tasks\nRecent\n&\nBudget T — o F—J— =\nShared % of Income Spent Summary wm- = et ‘\n- [ D [ = 5 ==\nOpen =)= = = E =\nManage My Money Personal Budget Family Budget Credit Card Payoff Calculator Mortgage Loan Calculator\nCSV Import Guide Page 3 of 8\nGLEIF Public Version 1.1\n2018-03-01_CSV_Import_Guide_V1.1 2018-03-01\n","contentLength":499,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:41:09.789Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/download-oc-to-lei-relationship-files/2018-03-01_csv_import_guide_v1.1.pdf","content":"With some versions of Excel you may need to do this from a menu, such as:\n@ Excel File Edit View Insert Format Tools Data Window Help\n3 Set up import\nOnce a new workbook is open, select this option from the File menu:\nA dialog will now begin, guiding you through the steps of importing a file.\nYou need to repeat the steps in sections 2 until the end, for each file you wish to use.\nCSV Import Guide Page 4 of 8\n@ Public Version 1.1\n2018-03-01_CSV_Import_Guide_V1.1 2018-03-01\n","contentLength":477,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:41:09.789Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/download-oc-to-lei-relationship-files/2018-03-01_csv_import_guide_v1.1.pdf","content":"4 Import dialog\n4.1 Select file type\n1. Select CSV.\n2. Click Import.\nImport\nSelect the type of file vou want to import:\not— t\nFileMaker Pro database\nFiles created with FileMaker Pro, like .fp5 or .fp7.\nHTML file ‘\nHyper-text markup files from your computer.\nText file\nText files, which import best when separated by tabs or spa :s.\nCancel | SRULCESS\n4.2 Select data (file) formats\nThe next step may be different, depending on the operating system, application, and even the\nversion of Excel.\nIf the application sets any of the following values correctly, please do not change them:\ne The data must be recognized as Delimited.\ne The import must start at row: 1.\ne The most important setting may not yet be detected:\nUnicode (UTF — 8)\nPlease see the next page for an example.\nMake sure that all settings that offer Unicode and / or UTF — 8 are set to this value only.\nCSV Import Guide Page 5 of 8\n@ Public Version 1.1\n2018-03-01_CSV_Import_Guide_V1.1 2018-03-01\n","contentLength":960,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:41:09.789Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/download-oc-to-lei-relationship-files/2018-03-01_csv_import_guide_v1.1.pdf","content":"Do not click Finish. Instead always click Next until the final step is complete.\nText Import Wizard - Step 1 of 3\nIf this is correct, choose Next, or choose the Data Type that best describes your data.\n_ Fixed width - Fields are aligned in columns with spaces between each field.\nUi?-8\nPreview of selected data:\nPreview of file /Users/minum /31520170630-gleif-concatenated-file-lei2.csv.\n1 |LET,Legal Name,Other Entity Names,Transliterated Other Entity Names,legal Address First Address Line,L¢\n2 |\"@37998BEFHAR09220120\" , \"SHIFT, a.s.\",\"\",\"SHIFT, AS\",\"Moyzesova 932/6\",\"\",\"\",\"\" \" \"\" \"\" \"Bratislava-Stq\n3 |\"@97900BEFHORR200321 7\" , \"Centrdlny depozitér cennych papierov SR, a.s.”,\"\",\"CENTRALNY DEPOZITAR CENNYCH\n4|\"@97908BEGK@200A2331L\" , \"DLHOPIS, o.c.p., a.s.\",\"\",\"DLHOPIS, OCP, AS\",\"Trnavské cesta 1@@\",\"\",\"\" \"\" \"\",\nS |\"@97903BEFSA000008472\" , \"VBRN s.r.0.\",\"\" ,\"VBRW SRO\",\"Hlavna ulica 1@9/62\",\"\",\"\",\"\",\"\",\"\" \"\" \"Hrochot™,\"\n6 |\"@37998BEFSA000092563\" , \"Prvé stavebnd sporitelda, a. s.\",\"\",\"PRVA STAVEBNA SPORITELNA, A S\",\"Bajkalskd\n7 |\"@37900BECX0000000644 \" ,\"IPT Investment a.s. investicny fond s premenlivym zdkladnym imanim\" \"\" \"JPT I\n8 |\"@37908BEH0RR20008743\" . \"LETICIA INVESTMENT, a. s.\".\"\", \"LETICIA INVESTMENT, A S\".\"Prvosienkowvd 5\".\"\". \"\"\nCancel -| Finish\n4.3 Set delimiters and qualifiers\nThe CSV file contains two types of special formatting characters that tell your application where to\nsplit the text into columns and rows:\ne The delimiters are commas (,).\ne The qualifiers are double quotation marks (“).\nCSV Import Guide Page 6 of 8\n@ Public Version 1.1\n2018-03-01_CSV_Import_Guide_V1.1 2018-03-01\n","contentLength":1621,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:41:09.789Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/download-oc-to-lei-relationship-files/2018-03-01_csv_import_guide_v1.1.pdf","content":"Text Import Wizard - Step 2 of 3\nThis screen lets you set the delimiters your data contains.\nDelimiters\nTab Treat consecutive delimiters as one\nSemicolon Textqualifier |\nSpace\nOther:\nPreview of selected data:\nLEI Legal Name ther Entity\n7900BEFHAB20000128 [SHIFT, a.s.\n7900BEFHO000008217 |Centrdlny depozitdr cennych papierov SR, a.s.\n7900BEGKOA20003311 |DLHOPIS, o.c.p., a.s.\n7900BE F 50000000472 s.r.o.\n7900BE FS0000008569 |Prva stavebnd sporitelfa, a. s.\n7900BECX0000000644 |JPT Investment a.s. investicny fond s premenlivym zdkladnym imanim\n7998BEHQOAB2220743 LETICIA INVESTMENT, a. s.\nCancel < Back Finish\nIf your application detects these automatically please do not change the values; simply click Next.\nIf any additional values (e.g. “Tab”) are selected, please de-select them.\nOnly Comma (,) for Delimiters and double quotation marks (“) for Text qualifier are correct.\n4.4 Set data (content) format\nThe final step is to set data content formats that are used by Excel to display and in some cases,\nprocess, the data.\nThis is essential for files containing LEls.\ne Set the LEl column to Text as shown in the next screenshot.\ne The “General” type can cause problems with some long sequences of numbers.\nCSV Import Guide Page 7 of 8\n@ Public Version 1.1\n2018-03-01_CSV_Import_Guide_V1.1 2018-03-01\n","contentLength":1304,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:41:09.789Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/download-oc-to-lei-relationship-files/2018-03-01_csv_import_guide_v1.1.pdf","content":"Text Import Wizard - Step 3 of 3\nThis screen lets you select each column and set the Data Format.\nColumn data format\nGeneral\no Text\nDate: MDY [ &\nDo not import column (Skip)\nAdvanced...\nPreview of selected data:\nJLEI Legal Name Other Entity Namg\n)97900BEFHO000000120 |1t NN\nnepennidgy v vraidl(Centralny depozitar cennych papierov SR, a.s.\nneree 38y ey IDLHOPIS, o.c.p., a.s.\nP97900BEF50000000472 |1 ISR\nnepge gL LS S MPrva stavebna sporitelha, a. s.\nnepenn e s R IPT Investment a.s. investiény fond s premenlivym zakladnym imanim\nY AR o Y EY LETICIA INVESTMENT, a. s.\nCancel < Back\n\n[}\n\nOnly click Finish when all of the steps have been checked.\n\nPlease note:\n\ne When working with very large files, downloading, opening and manipulating the file may\nbe interrupted sometimes due to e.g. lack of sufficient memory.\n\ne For large files this could be impractical and a specialized tool e.g. a dedicated CSV editor\nor parser, is needed.\n\ne For detailed technical assistance using your application, please consult the official\napplication documentation. For example, detailed information on importing CSV files to\nMicrosoft Excel can be found at:\n\nhttps://support.office.com/en-us/article/Import-or-export-text-txt-or-csv-files-5250ac4c-663c-47ce-\n\n937b-339e391393ba\nCSV Import Guide Page 8 of 8\n@ Public Version 1.1\n2018-03-01_CSV_Import_Guide_V1.1 2018-03-01\n","contentLength":1356,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:41:09.789Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/download-oc-to-lei-relationship-files/2023-06-29_opencorporatesid-to-lei-factsheet_v1.1-final.pdf","content":"- 0]\nopencorporates @\nOpenCorporates |ID to LE|\nmapping table\nFactsheet\n","contentLength":72,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:41:25.417Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/download-oc-to-lei-relationship-files/2023-06-29_opencorporatesid-to-lei-factsheet_v1.1-final.pdf","content":"opencorporates OQ\n1. Introduction\n\nOpenCorporates is the world’s foundational source for legal entity data and is on a mission to bring\nabout genuine corporate transparency, and has been instrumental in opening access to corporate\nregistries across Europe and North America, as well as being the largest open database of companies in\nthe world, containing over 220 million companies and 300 million officers from 145 jurisdictions (as at\nearly 2023). Its data is fully provenanced to official sources, unified according to a global schema, up-to-\ndate and available at scale.\n\nThe Global Legal Entity Identifier Foundation (GLEIF) is a not-for-profit organization created to support\nthe implementation and use of the Legal Entity Identifier (LEI). GLEIF manages a network of partners,\nthe LEI Issuing Organizations, to provide trusted services and open, reliable data for unique legal entity\nidentification worldwide.\n\nThe Legal Entity Identifier (LEI) is a 20-digit, alpha-numeric code based on the ISO 17442 standard\ndeveloped by ISO. It connects to key reference information that enables clear and unique identification\nof legal entities participating in financial transactions.\n\nBoth datasets enable smarter, less costly and more reliable decisions about who to do business with. By\nproviding a link between these two datasets, users gain access to a richer pool of information with\nwhich to make decisions and, in turn, cut costs, simplify and accelerate operations. In taking this step\nforward by publishing a publicly available OpenCorporates ID-to-LEI mapping reference file - individuals\nand organizations will be able to map LEIs to information compiled by OpenCorporates from local\ncorporate registrations globally.\n\nThe mapping file is built upon a mapping process established in cooperation between GLEIF and\nOpenCorporates leveraging on OpenCorporates API. This file will be updated initially on a bi-weekly\nbasis. The purpose of this factsheet is to describe the reference data involved, the analysis applied to\nmap LEls to OpenCorporates IDs, and the ongoing update process.\n\n2. Reference Data\n\nThe OpenCorporates dataset is the source for the OpenCorporates ID and associated company data\nsourced from official company registers. Additional information on this data source including field\ndefinitions can be found here.\n\nThe GLEIF Concatenated File is the source for the LEIs and the legal entity reference data. Additional\ninformation on the GLEIF Concatenated Files and the Common Data File formats can be found here.\nThe OpenCorporates ID-to-LEI mapping table does not include historical OpenCorporates ID/LEI pairs,\nstand-alone unmapped OpenCorporates IDs and LEls, nor the listing of daily or monthly changes.\n\nThe following table describes the critical fields considered for mapping. Some additional pre-processing\nsteps are in place considering specific local differences. Should you require further information please\nreach out to info@gleif.org.\n\nPublic Use\n\nAuthor: GLEIF and OpenCorporates | Version: 1.1 | 2023-06-29 Page 2 of 6\n","contentLength":3058,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:41:25.417Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/download-oc-to-lei-relationship-files/2023-06-29_opencorporatesid-to-lei-factsheet_v1.1-final.pdf","content":"-]\nopencorporates OQ\nTable 1 - Critical Fields Considered for Mapping\ni =< | S el\nComments\nRegistration Status LEls with Registration\nStatus of ANNULLED or\nDUPLICATE are excluded\nEntityCategory LEls with EntityCategory\nFUND are excluded\nRegistrationAuthorityld LEls which use reserved\nRegistration Authority\ncodes RA888888 and\nRA999999 (GLEIF\nRegistration Authorit\ncode list)\nI o =l\nidentifier\nalidationAuthorityEntitylD\nCompany Identifier given by the | |RegistrationAuthorityEntityID |All available entity IDs of an\nNumber Company register to LEI Record are used to\nhe entity. Together alidationAuthorityEntitylD |establish a mapping pair. All\nwith the Jurisdiction white spaces are removed\nCode OtherValidationAuthorityEnti jand jurisdiction-specific\nhis forms a composite | tylD pre-processing of entity IDs\nprimary key for a legal is applied where necessary\nentity\nurisdiction Code for the Legallurisidiction he Legallurisdiction\nCode jurisdiction (lowercase, element is transformed to\nunderscore match the lowercase,\nersion of ISO 3166-2 underscore\ncode). List of version of the ISO 3166-2\njurisdiction code\ncodes are available\nat\nhttps://api.opencorpor\nates.com/jurisdictions\n3. Analysis\nIn April 2023, there were around 220 million companies in the OpenCorporates dataset with over 2.3\nmillion LEIs having been issued.\nOf these 2.3 million, about 1.2 million have been automatically reconciled with a strict criterion applied\nwith respect to registered jurisdiction, local company number.\nThere are two main reasons why an LEI will not have an applicable OpenCorporates ID:\nPublic Use\nAuthor: GLEIF and OpenCorporates | Version: 1.1 | 2023-06-29 Page 3 of 6\n","contentLength":1666,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:41:25.417Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/download-oc-to-lei-relationship-files/2023-06-29_opencorporatesid-to-lei-factsheet_v1.1-final.pdf","content":"opencorporates @)\n1. The LElis associated with legal form other than a company legal entity (e.g. mutual fund or\ngovernment bond)\n2. OpenCorporates does not yet include the register in the jurisdiction where the entity is\nregistered.\nThe technical approach to the mapping process will be subject to continuous review to improve the\nquality of the matching process.\n4. On-going update process\nThis section describes what changes (events) to the underlying datasets trigger update to the mapping\ndiscussed in the section above.\nGenerally, an existing mapping pair is only updated if one of the following LEI data elements is changed:\n® RegistrationAuthorityEntityld (RAEID)\ne ValidationAuthorityEntityld (VAEID),\ne OtherValidationAuthorityEntityld (OVAIED)\nUnmapped records will also be revisited on an adhoc basis based on updates to OpenCorporates\ncoverage or on renewal if an OpenCorporates ID has not previously been mapped.\nPublic Use\nAuthor: GLEIF and OpenCorporates | Version: 1.1 | 2023-06-29 Page 4 of 6\n","contentLength":1011,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:41:25.417Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/download-oc-to-lei-relationship-files/2023-06-29_opencorporatesid-to-lei-factsheet_v1.1-final.pdf","content":"-]\nopencorporates @)\nTable 2: The change to an LEI (event) and the consequent update to the OpenCorporates/LEIl pair\non the mapping file.\n[Evet |update\nIn an OpenCorporates ID/LEI pair the LEI The mapping is removed from the mapping\nANNULLED or DUPLICATE, the RAID or VAID file.\nchanges to RA999999/RA888888, or\nEntityCategory changes to FUND.\nIn an OpenCorporates ID/LEI pair the LEI became | The mapping is not removed from the\nIn an OpenCorporates ID/LEI pair any of the If RAEID, VAEID or OVAEID of an LEI Record\nOpenCorporates ID or LEI data fields considered changes, the LEl is sent to through the\nas equivalent mapping (see Table 1) change. mapping process irrespective whether\npreviously a mapping existed. If the updated\nset of entity IDs for an existing mapping\ncannot be matched with OpernCorporates\nanymore, the mapping pair is removed.\nIf any of the OpenCorporates data fields is\nupdated, the existing mappings are not\nupdated. The only trigger to update existing\nmappings is currently by updating one of the\nentity ID elements in the LEl data\nIf an LEI that was not mapped in the past is The LEl is sent through the mapping process\nrenewed. again.\nUsers of the OpenCorporates ID-to-LEI mapping reference file may ask general questions or challenge\nindividual OpenCorporates ID/LEI pairs by emailing info@gleif.org.\nPublic Use\nAuthor: GLEIF and OpenCorporates | Version: 1.1 | 2023-06-29 Page 5 of 6\n","contentLength":1415,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:41:25.417Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/download-oc-to-lei-relationship-files/2023-06-29_opencorporatesid-to-lei-factsheet_v1.1-final.pdf","content":"opencorporates @)\n5. File Specifications\nThe file is published in comma-separated format (csv) contained in a zip file. It contains all identified\nOpenCorporates ID-LEI pairs, i.e. is a “full” file. No “delta” file is made available. The file does not\ncontain OpenCorporates IDs that do not have corresponding LEIs nor LEIs without corresponding\nOpenCorporates IDs.\nThe file contains the following data:\nOpenCorporates ID 136 alphanumberic IAlways present he OpenCorporates ID of the entity.\njurisdiction_code “/” company number\n\n6. Resources\nThe OpenCorporates ID-to-LEI mapping full file can be downloaded via https://www.gleif.org/en/lei-\ndata/lei-mapping/download-oc-to-lei-relationship-files\nThe GLEIF API can be accessed via https://api.gleif.org/\nFor every OpenCorporates ID-LEI pair, on the website, the LEI can be seen under the section titled\n“Additional Identifiers” using the following URL where YY is the jurisdiction code (YY_YY in case of\nsubdivisions e.g. US_DE for Delaware), and XXXXXXX represents an arbitrary company number:\nwww.opencorporates.com/companies/YY/XXXXXXX\nFor users of the OpenCorporates API, the relevant call structure (before appending your API token) is:\nhttp://api.opencorporates.com/v0.4/companies/YY/XXXXXXX\nThe API call will return the LEI within the “identifiers” section.\nIf you receive OpenCorporates bulk data, please refer to your technical documents with respect to\n“Additional Identifiers”.\nUsing GLEIF as an example the relevant URLs would be:\n\ne https://opencorporates.com/companies/ch/1190521\n\ne https://api.opencorporates.com/v0.4/companies/ch/1190521\nFor details on how to access the OpenCorporates data at-scale through API or Bulk data, please refer to:\nhttps://opencorporates.com/info/our-data/.\nPublic Use\nAuthor: GLEIF and OpenCorporates | Version: 1.1 | 2023-06-29 Page 6 of 6\n","contentLength":1836,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:41:25.417Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/gleif-certification-process/2021-09-02_lei_mapping_cooperation_agreement_v1.pdf","content":"OGLEIF, Protacting digtal trust\nCooperation Agreement\nabout LEI Mapping\n","contentLength":72,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:41:52.316Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/gleif-certification-process/2021-09-02_lei_mapping_cooperation_agreement_v1.pdf","content":"COOPERATION AGREEMENT\nABOUT LEI MAPPING\nbetween\nGLOBAL LEGAL ENTITY IDENTIFIER FOUNDATION,\nSt. Alban-Vorstadt 5, CH-4052 Basel, Switzerland\nas GLEIF\nand\nCOMPANY\nAddress\nas\nCOMPANY\ntogether \"the Parties\"\nCooperation Agreement about LEI Mapping Page 2 of 12\n@ GLEIF and Mapping Partner Restricted Version 1.0\n2021-09-02_LEI_Mapping_Cooperation_Agreement_v1 2021-09-02\n","contentLength":366,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:41:52.316Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/gleif-certification-process/2021-09-02_lei_mapping_cooperation_agreement_v1.pdf","content":"10. Intellectual property\nAll intellectual property rights with respect to the work and results will be provided under a\nCreative Commons license (CC0)* for present and future usage (right of use). The right of use\ncontains in particular the right for full or partial copying, sharing, processing and publishing of\nwork and results.\n11. Severability\nThe invalidity of individual parts of this Cooperation Agreement shall have no impact on the\nvalidity of the Cooperation Agreement as a whole. The Parties agree that if any provision or part\nof a provision of this Cooperation Agreement shall, for whatever reason, be deemed invalid,\ninoperative or otherwise not enforceable, the Cooperation Agreement as a whole shall remain\nvalid and the invalid or inoperative provision or part of a provision shall be considered replaced\nby the provision which the Parties would have agreed on in good faith if they had been aware of\nthe invalidity of the respective provision.\n12. Assignment\nA Party is not entitled to transfer this Cooperation Agreement or any rights or obligations under\nthis Engagement Letter to any third party without the other Party's prior written consent.\n13. No Agency\nThe relationship between COMPANY and GLEIF does not constitute a joint venture or partnership\nin the meaning of Art. 530 et seq. of the Swiss Code of Obligations or any similar form of\ncooperation under any other applicable laws. Each party it is free to enter into relationships with\nothers.\n14. Written Form, Entire Engagement Letter\nThis Cooperation Agreement, including this clause, may only be amended, waived, rescinded or\nterminated in writing.\nThis Cooperation Agreement contains the entire understanding of the Parties with respect to the\nsubject matter hereof and substitutes and merges any previous Cooperation Agreement, be it\nwritten or oral, among the Parties hereto concerning the subject matter hereof.\n1 Creative Commons is a nonprofit organization that enables the sharing and use of creativity and\nknowledge through free legal tools.\nCooperation Agreement about LEI Mapping Page 11 of 12\n@ GLEIF and Mapping Partner Restricted Version 1.0\n2021-09-02_LEl_Mapping_Cooperation_Agreement_v1 2021-09-02\n","contentLength":2199,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:41:52.316Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/gleif-certification-process/2021-09-02_lei_mapping_cooperation_agreement_v1.pdf","content":"15. Contact Persons, Address, Phone, Website, Mail\nThe primary contact persons of either Party, as well as specialized contact persons (such as\ntechnical staff) are listed in Appendix 2.\nBoth Parties undertake to keep Appendix 2 up to date.\n16. Force Majeure\nIn the event of force majeure, such as floods, tsunamis, earthquakes, fires, storms such as\nhurricanes or typhoons, war, strikes, riots, volcanic eruptions, or any other similar extraordinary\nsituation, event or circumstance beyond the control of either Party, the obligations of the Parties\nare suspended to the extent force majeure prevents their reasonable performance, and no\ndamage claims shall arise for that reason.\nOnce the force majeure ceases, the Parties shall seek in good faith to resume orderly business.\nIf the force majeure persists for more than three months, the Parties shall convene to find an\nacceptable intermediate Engagement Letter.\n17. Jurisdiction\nThis Cooperation Agreement is governed by the Laws and Courts of Switzerland.\n18. Signatures\n, __Month 2022 Basel, __ Month 2022\nCOMPANY GLEIF\nmade in two originals, one for each Party\nCooperation Agreement about LEI Mapping Page 12 of 12\n@ GLEIF and Mapping Partner Restricted Version 1.0\n2021-09-02_LEI_Mapping_Cooperation_Agreement_v1 2021-09-02\n","contentLength":1283,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:41:52.316Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/gleif-certification-process/2021-09-02_lei_mapping_cooperation_agreement_v1.pdf","content":"Content\n1. INItIAl POSITION .viiiieie it sraae e e s sssasneeeessssannnnnees D\n2. ODBJECHIVES. ettt e s s s saaneae s s ssnnnneeessnnenns B\n3. SEBIVICES ittt e e ettt s s e e e e e e e eeeeesaeaenbesesasnnnn e eesanananeeeees O\n4, Place and Time of Collaboration .........cccccveviiiiiiiee i esiiieee e D\n5. NON-CoMPEtition ClaUSE ....ccciiviiiiiieiiiciiie e ssaareeeees D\n6. CoNFIdENtiality...ceiiiiiiiiiee e e e D\n7. {610 1] - PO TP PP TP PPUPPOPPPPPRPRNt L 0\n8. Settlement of DISPULES ....ccevvviiiiiiiiiiiiieie e sieeee s sveeeeessssssneeeeens 10\n9. Termand Termination .....c.cccvveeeiiiiniiiiee e eiiieeeessssiieee s ssssireeeesssseseeessssssseesesns 10\na. ordinary diSmissal .......ceeiiiiiiiiee i esee e s seeeee s e s ssneeeeesennes 10\nb. extraordinary dismissal.......cccccovviiiiiiiiiiiiiieie e esiieeee s siineeeeeeennes. 10\n10. Intellectual ProPerty .ooooccueeiii it ee e seee e e sraeeee s sssanbeeesesssenes 11\n11, SeVErabiliTy..uuuiiie e srae e e e sssrraeeeesssneees 11\n12, ASSIBNMENT...cci ittt e e e e ettt s s s e e e e e eeeeeeesneesesesnsnsnnnnsnsesansanens L1\n13, NO ABENCY cooeiiiiiiteeitit e e e e ee e e te ettt et ss s e s eeeeeeeeseseeesesesnsnsnnnnsnsessesanens L1\n14. Written Form, Entire Engagement Letter ......cccoeveiieiiiiiirniiiiceeeeeeeeeen, 11\n15. Contact Persons, Address, Phone, Website, Mail .......c.cooovvveeeeiiiiiiiiiiniieiiiiiineennn 12\n16. FOICE M UM ..coeiiiiitiiee ettt ettt s s e e e e e eeeeeeesaeesesesnsnsnnnnsnsnsansanees 12\n17, JUFISAICTION wetviiiie ittt e e s sireae e s s snaeeeesnnsssseeaesnsssnes 12\n18, SIBNATUIES ettt s s s e s e e s eeeeeeeseeesesesnsnsnnnnsnsesansanens 12\nO Cooperation Agreement about LEI Mapping Page 3 of 12\n@ GLEIF and Mapping Partner Restricted Version 1.0\n2021-09-02_LEI_Mapping_Cooperation_Agreement_v1 2021-09-02\n","contentLength":1806,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:41:52.316Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/gleif-certification-process/2021-09-02_lei_mapping_cooperation_agreement_v1.pdf","content":"1. Initial Position\nCOMPANY serves a wide variety of professional markets and industries across the globe.\nCOMPANY provides professionals with the intelligence, technology and human expertise in the\nareas of financial and risk, legal, tax and accounting, intellectual property, science and media\nmarkets.\nThe Global Legal Entity Identifier Foundation (GLEIF) is a not-for-profit organization created to\nsupport the implementation and use of the Legal Entity Identifier (LEl). GLEIF manages a network\nof partners, i.e. the LEl issuing organizations, to provide trusted services and open, reliable data\nfor unique legal entity identification worldwide.\nCOMPANY approached GLEIF to propose the establishment of a closer relationship to enhance\nthe overall coverage and quality of LEI data, coming from the each Local Operating Unit (LOU)\nand published on GLEIF’s website.\nThe Parties believe cross-referencing to alternative IDs like COMPANY’s Identifier “COMPANY-ID”\nwill help their mutual constituents map and acquire LEls with more precision.\n2. Objectives\nCOMPANY and GLEIF wish to engage in a joint project to establish a process for cross-referencing\nLEIs to the “COMPANY-ID”. For this purpose COMPANY will make its “COMPANY-ID” completely\navailable to GLEIF and the financial market without costs, restrictions or commercial\nconsiderations.\nThe cornerstone of the partnership would be a quality control feedback loop and a verification\nprocess that would certify the accuracy of mapping between COMPANY entity data and the LEI\nrecords published through the GLEIF.\nThe certification process is described on the GLEIF website.\nThe Parties have negotiated, and agreed on, the Conceptual Model.\nFor the avoidance of doubt, GLEIF shall be obliged to grant the Mapping Certificate to COMPANY\nif and when all components of the Conceptual Model, and the review of the Certification\nDocumentation (Internal Control Checklist) have been completed in due time and all criteria for\nsuccessful Certification are met.\n3. Services\nTo achieve the objectives described in section 2, the Parties provide the following agreed\nservices.\nCooperation Agreement about LEI Mapping Page 4 of 12\n@ GLEIF and Mapping Partner Restricted Version 1.0\n2021-09-02_LEI_Mapping_Cooperation_Agreement_v1 2021-09-02\n","contentLength":2284,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:41:52.316Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/gleif-certification-process/2021-09-02_lei_mapping_cooperation_agreement_v1.pdf","content":"3.1 GLEIF Services - Service Descriptions\nThe following services are performed by GLEIF. For all of them, the attended service operating\ntime will be during GLEIF’s Business Days between 09.00 — 17.00 UTC+1.\n3.1.1 Certification of mapping COMPANY ID to LEI\nName Certification of Mapping COMPANY ID to LEI\nTag line Accuracy and confirmation of mapping COMPANY ID to LEI process.\nDescription COMPANY documents the nature and extent of the mapping process(es)\nin a Technical Implementation Note (operational protocols). Supporting\ndocumentation (e.g. narratives, diagrams, exhibits describing the process\nand procedures) must be provided as additional information.\nGLEIF checks the relevant sample data from COMPANY with its\nmapping algorithms for accuracy, and checks whether the relevant\nsample data meets the accuracy criteria.\nProvided the information on samples from COMPANY is sufficient for\nmatching, GLEIF ensures the mismatches in the following areas have been\nchecked:\na) Entity name\nb) Entity short name\nc) Entity legal form\nd) Status (entity is active/inactive)\ne) Address\nf) Country\ng) Branch entities (branch or headquarters?)\nh) Duplicates\ni) Missing data.\nIf the matching meets the data quality criteria, COMPANY receives a\ncertificate.\nEssential Tasks = Define and maintain data quality checks\n= Check of accuracy mapping between COMPANY data and\n= GLEIF's LEl records\n= Record and deliver result\n= Re-validate (if applicable) with COMPANY\n= |ssue mapping certificate\nAccess Group(s) COMPANY\nCOMPANY Tasks = Provide relevant sample data for mapping algorithm(s)\n= Provide supporting documentation for data mapping algorithm(s)\n= Re-validate data if applicable\nCooperation Agreement about LEI Mapping Page 5 of 12\n@ GLEIF and Mapping Partner Restricted Version 1.0\n2021-09-02_LEI_Mapping_Cooperation_Agreement_v1 2021-09-02\n","contentLength":1840,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:41:52.316Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/gleif-certification-process/2021-09-02_lei_mapping_cooperation_agreement_v1.pdf","content":"3.1.2 Annual re-certification of COMPANY ID to LEI\nName Re-certification of Mapping COMPANY ID to LEI\nTag line Re-certification of the accuracy and confirmation of relevant data sample\nmatching process.\nDescription Annually COMPANY updates GLEIF’'s understanding of the current status\nof the mapping process that were verified as part of the initial\nCertification.\nSignificant changes should be advised within 30 days from the date they\noccurred. For areas where significant changes have occurred, COMPANY\ndocuments the nature and extent of the changes and how they affected\nthe mapping processing. Supporting documentation must be provided as\nadditional information regarding the change(s).\nGLEIF and COMPANY review the information and assess the overall impact\nof any changes noted in the mapping process. GLEIF and COMPANY\ndetermine if the changed mapping process still meets the required\nstandard and decides as to whether any remediation action is required.\nGLEIF may check the relevant sample data from COMPANY with its\nmapping algorithms for data quality, whether the relevant sample data\nmeets the data quality criteria.\nProvided the information on samples from COMPANY is sufficient for\nmatching, GLEIF ensures the mismatches in the following areas have been\nchecked:\na) Entity name\nb) Entity short name\nc) Entity legal form\nd) Status (entity is active/inactive)\ne) Address\nf) Country\ng) Branch entities (branch or headquarters?)\nh) Duplicates\ni) Missing data.\nIf the matching meets the data quality criteria, the certification is\nconfirmed.\nCooperation Agreement about LEI Mapping Page 6 of 12\n@ GLEIF and Mapping Partner Restricted Version 1.0\n2021-09-02_LEI_Mapping_Cooperation_Agreement_v1 2021-09-02\n","contentLength":1714,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:41:52.316Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/gleif-certification-process/2021-09-02_lei_mapping_cooperation_agreement_v1.pdf","content":"Essential Tasks = Check data quality of mapping between COMPANY data and\nGLEIF’s LEI records\n= Record and deliver result of re-validation\n= Re-validate (if applicable) with COMPANY\n= Confirm re-certification\nAccess Group(s) COMPANY\nCOMPANY Tasks ® Provide updated relevant sample data for its mapping algorithm\nnoting any changes\n= Provide supporting documentation for any algorithm changes\nnoted\nUpdate Frequency Annual at the anniversary of certification\n3.1.3 Publication of the COMPANY ID to LEI relationship links\nName Publication of the COMPANY ID to LEI Relationship Links\nTag line GLEIF publishes the relationship links between the COMPANY ID and the\nLEI.\nDescription Publication of the relationship links between the COMPANY ID and LEI\non gleif.org.\nVia an interface the upload of the master relationship link file to GLEIF\ntakes place. Data is represented in a specific format (e.g. codes,\ntimestamps). Details will be clarified in the Technical Implementation\nNote (operational protocols).\nThe uploaded file received from COMPANY ID will not be modified by\nGLEIF.\nEssential Tasks = Publish timely accurate file of LEI to COMPANY ID relationship\nlinks\n= Provide upload interface\n= Process quality checks\n= Send reports to COMPANY\nAccess Group(s) = COMPANY\n= Public\nCOMPANY Tasks » Deliver the mapping daily/weekly/monthly in the agreed format\non time\n= Remediate any reported errors\nCooperation Agreement about LEI Mapping Page 7 of 12\n@ GLEIF and Mapping Partner Restricted Version 1.0\n2021-09-02_LEI_Mapping_Cooperation_Agreement_v1 2021-09-02\n","contentLength":1561,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:41:52.316Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/gleif-certification-process/2021-09-02_lei_mapping_cooperation_agreement_v1.pdf","content":"3.2 COMPANY services\nThe services of COMPANY are all related to mapping of LEls (and the Company ID Issuer if\napplicable) and transmission of the Company ID to LEI Relationship data to GLEIF. In order to\nfacilitate the certification performed by GLEIF, the relationship data produced by COMPANY\nshould be uploaded to GLEIF in line with the services set out in this chapter. Technical details are\nspecified in the Technical Implementation Note (operational protocols).\n3.2.1 Delivery COMPANY ID to LEI relationship links\nName Deliver COMPANY ID to LEI Relationship Links\nTag line A cross reference of LEls to COMPANY which could be a one to one\nrelationship or a one to many relationships.\nDescription COMPANY provides a daily/weekly/monthly master file with relationships\nlinks of COMPANY ID to LEls with the attributes\n= LEl code\n= COMPANY ID\nCOMPANY does not provide any COMPANY ID related reference data.\nEssential Tasks = Apply mapping algorithms according to COMPANY operational\nprotocol to provide COMPANY ID to LEI relationships\n= Check for mismatches before delivering the file to GLEIF\n= Deliver relationship links in the agreed format\n* |nclude any changes based on reported errors from GLEIF\n= Process Incidents immediately\nAccess Group(s) GLEIF\n3.2.2 Manage challenges provided through gleif.org\nName Manage Challenges provided through gleif.org\nTag line COMPANY responds to LEI to COMPANY ID challenges received from\nGLEIF.\nDescription Description COMPANY will review and respond to LEI to COMPANY ID\nchallenges transmitted to it by GLEIF.\nThese challenges may be transmitted to COMPANY by GLEIF on behalf\nof a third party or on behalf of GLEIF. COMPANY investigates the\ncontent of the challenge and verifies if justified.\nCooperation Agreement about LEI Mapping Page 8 of 12\n@ GLEIF and Mapping Partner Restricted Version 1.0\n2021-09-02_LEI_Mapping_Cooperation_Agreement_v1 2021-09-02\n","contentLength":1900,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:41:52.316Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/gleif-certification-process/2021-09-02_lei_mapping_cooperation_agreement_v1.pdf","content":"COMPANY ensures the pertaining data is adjusted given the challenge is\njustified and uploads the adjusted record to GLEIF.\nEssential Tasks = Review and respond to all challenges transmitted by GLEIF\n= Research the content of the challenge and verify the challenge\nis valid and justified.\n= Upload to GLEIF the updated data collected\nAccess Group(s) Public\n4. Place and Time of Collaboration\nTeamwork can be provided via videoconference, conference call or in person. The Parties agree\nin detail by mutual consent about time and place of performance.\n5. Non-Competition Clause\nEach Party agrees not to directly or indirectly compete with the business of the other Party.\nEach Party acknowledges that the other Party may, in reliance of this Cooperation Agreement,\nprovide the Party access to confidential data and good will. Each Party agrees to retain said\ninformation according to section 6 as confidential and not to use said information on its own\nbehalf or disclose same to any third party. Each Party also agrees to take reasonable security\nmeasures to prevent accidental disclosure.\n6. Confidentiality\nInformation may be transferred between the Parties to the extent necessary to fulfil the purpose\nof this Cooperation Agreement. Such information may be, without limitation, in the form of\nbusiness and/or financial records, specifications, software programs, samples, models,\nphotographs, diagrams, drawings, correspondence and/or other documents or may be disclosed\norally or in writing, by demonstration or presentation or otherwise.\nAll such information so disclosed and explicitly marked as “confidential” is hereinafter referred to\nas “Confidential Information”.\nThe Parties will undertake to keep confidential any Information received from the other Party\nand will make no use of such Information, either directly or indirectly,\ne unless such Information is general public knowledge or becomes general public\nknowledge through no fault of any Party, or\ne unless such Information was in the receiving Party’s possession prior to Party’s receipt\nthereof as proven by written records, or\nCooperation Agreement about LEI Mapping Page 9 of 12\n@ GLEIF and Mapping Partner Restricted Version 1.0\n2021-09-02_LEI_Mapping_Cooperation_Agreement_v1 2021-09-02\n","contentLength":2261,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:41:52.316Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/gleif-certification-process/2021-09-02_lei_mapping_cooperation_agreement_v1.pdf","content":"e unless such Information has been received by the Party from any third party under no\nobligation of confidentiality, or\ne unless such Information was not marked as “confidential” from the other Party, or\ne the party is obliged by the regulator, oversight committee or by law.\n7. Costs\nEach Party shall bear its own costs.\n8. Settlement of Disputes\nBoth Parties agree that any disputes, controversies or claims arising out of, or in relation to, this\nAgreement, including (explicitly without limitation) the validity, invalidity, breach, or termination\nthereof, should be solved whenever possible amicably and out-of-court.\nIf disputes arise in connection with the contractual services, the contracting parties will make\nreasonable efforts to reach an out-of-court settlement.\nDisputes will first be discussed by the respective contact persons of both contracting parties.\nIf the contact persons do not reach a joint solution within 5 working days, each Party’s contact\nperson can escalate the disputes to the Party’s respective management.\n9. Term and Termination\nThis Cooperation Agreement will be effective the later of the dates of signing shown on the last\npage of this Agreement.\na. ordinary dismissal\nIt can be terminated by GLEIF or COMPANY at the end of any calendar year, giving twelve\nmonths’ previous notice, but not earlier than 24 months after the effective date.\nb. extraordinary dismissal\nEither Party may terminate this Cooperation Agreement in the event the other Party has\nmaterially breached or defaulted in the performance of any of its obligations hereunder, and\nsuch default has continued for thirty (30) days after written notice thereof was provided to the\nbreaching Party by the non breaching Party. Any termination shall become effective at the end of\nsuch thirty (30) day period unless the breaching Party has cured any such breach or default prior\nto the expiration of such period.\nCooperation Agreement about LEI Mapping Page 10 of 12\n@ GLEIF and Mapping Partner Restricted Version 1.0\n2021-09-02_LEI_Mapping_Cooperation_Agreement_v1 2021-09-02\n","contentLength":2075,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:41:52.316Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/gleif-certification-process/2018-04-03_nda_gleif_template_v1.1.pdf","content":"Mutual Non-Disclosure Agreement\n\nTHIS AGREEMENT (the Agreement) is entered into on [Day, Month and Year] (the Effective Date)\n\nby and between:\n\n1. Global Legal Entity Identifier Foundation “GLEIF”\nSt. Alban-Vorstadt 5, 4052 Basel, Switzerland\n\nand\n\n2. [Insert official name of the potential partner or participant], having its registered office or\nbased in _hereinafter referred to as .\n\nand\n\n3. [Insert official name of the potential partner or participant], having its registered office or\nbased in _hereinafter referred to as .\n\nIndividually referred to as a Party or collectively as the Parties.\n\nWHEREAS, the Parties discuss the possibility of establishing or pursuing a business relationship; and,\n\nWHEREAS, the Parties anticipate that during their discussions or negotiations, either Party may\n\ndisclose (the Disclosing Party) to the other Party or Parties (the Receiving Party) certain Confidential\n\nInformation (as defined below) for the limited purpose of enabling the Parties to evaluate the\n\nfeasibility of such business relationship.\n\nNow therefore, in consideration of the mutual covenants and undertakings contained herein, and\n\nintending to be legally bound, the Parties agree as follows:\n\n1 Confidential Information\n\n1.1 For the purposes of this Agreement, Confidential Information means any data or information\n\nthat is proprietary to or possessed by a Party and not generally known to the public or that has\nnot yet been revealed, whether in tangible or intangible form, whenever and however\ndisclosed, including, but not limited to:\n\ni) any scientific or technical information, invention, design, process, procedure, formula,\nimprovement, technology or method,;\n\nii) any concepts, samples, reports, data, know-how, works-in-progress, designs, drawings,\nphotographs, development tools, specifications, software programs, source code, object code,\nflow charts, and databases;\n\nMutual Non-Disclosure Agreement Page 1 of 5\n@ Public Version 1.1\n2018-04-03_NDA_GLEIF_template_v1.1 2018-04-03\n","contentLength":2007,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:42:08.061Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/gleif-certification-process/2018-04-03_nda_gleif_template_v1.1.pdf","content":"iii) any marketing strategies, plans, financial information, or projections, operations, sales estimates,\nbusiness plans and performance results relating to the Party's past, present or future business\nactivities, or those of its affiliates, subsidiaries and affiliated companies;\n\niv) trade secrets; plans for products or services, and customer or supplier lists;\n\nv) any other information that should reasonably be recognized as Confidential Information by the\nParties.\n\n1.2 The Parties agree hereby that Confidential Information needs not to be novel, unique,\npatentable, copyrightable or constitutes a trade secret in order to be designated Confidential\nInformation and therefore protected.\n\n1.3 Confidential Information shall be identified either by marking it, in the case of written\nmaterials, or, in the case of information that is disclosed orally or written materials that are\nnot marked, by notifying the other Party of the confidential nature of the information. Such\nnotification shall be done orally, by e-mail or written correspondence, or via other appropriate\nmeans of communication.\n\n1.4 The Parties hereby acknowledge that the Confidential Information proprietary to each Party\nhas been developed and obtained through great efforts and shall be regarded and kept as\nConfidential Information.\n\n1.5 Notwithstanding the aforementioned, Confidential Information shall exclude information that:\n\ni) isalready in the public domain at the time of disclosure by the Disclosing Party to the\nReceiving Party or thereafter enters the public domain without any breach of the terms\nof this Agreement;\n\nii) was already known by the Receiving Party before the moment of disclosure (under\nevidence of reasonable proof or written record of such disclosure);\n\niii) is subsequently communicated to the Receiving Party without any obligation of\nconfidence from a third party who is in lawful possession thereof and under no\nobligation of confidence to the Disclosing Party;\n\niv) becomes publicly available by other means than a breach of the confidentiality\nobligations by the Receiving Party (not through fault or failure to act by the Receiving\nParty);\n\nv) is or has been developed independently by employees, consultants or agents of the\nReceiving Party (proved by reasonable means) without violation of the terms of this\nAgreement or reference or access to any Confidential Information pertaining to the\nParties.\n\n2 Purpose of the Disclosure of Confidential Information\n\nThe Parties will enter into discussions or negotiations in contemplation or pursuit of a potential\n\nbusiness relationship (the Purpose).\n\nMutual Non-Disclosure Agreement Page 2 of 5\nGLEIF Public Version 1.1\n@ 2018-04-03_NDA_GLEIF_template_v1.1 2018-04-03\n","contentLength":2730,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:42:08.062Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/gleif-certification-process/2018-04-03_nda_gleif_template_v1.1.pdf","content":"3 Undertakings of the Parties\n\n3.1 Inthe context of discussions, preparations or negotiations, the Disclosing Party may disclose\nConfidential Information to the Receiving Party. The Receiving Party agrees to use the\nConfidential Information solely in connection with purposes contemplated between the\nParties in this Agreement and not to use it for any other purpose or without the prior written\nconsent of the Disclosing Party.\n\n3.2 The Receiving Party will not disclose and will keep confidential the information received,\nexcept to its employees, representatives or agents who need to have access to the\nConfidential Information for the purpose of carrying out their duties in connection with the\npermitted purpose specified in clause 2. The Receiving Party will inform them about the\nconfidential quality of the information provided and will ensure that their agreement is\nobtained to keep it confidential on the same terms as set forth in this Agreement. Hence the\nReceiving Party will be responsible for ensuring that the obligations of confidentiality and non-\nuse contained herein will be strictly observed and will assume full liability for the acts or\nomissions made for its personnel representatives or agents.\n\n3.3 The Receiving Party will use the Confidential Information exclusively for the permitted purpose\nstated in clause 2 and not use the information for its own purposes or benefit.\n\n3.4 The Receiving Party will not disclose any Confidential Information received to any third parties,\nexcept as otherwise provided for herein.\n\n3.5 The Parties shall treat all Confidential Information with the same degree of care as it accords\nto its own Confidential Information.\n\n3.6 All Confidential Information disclosed under this Agreement shall be and remain the property\nof the Disclosing Party and nothing contained in this Agreement shall be construed as granting\nor conferring any rights to such Confidential Information on the other Party. Principally,\nnothing in this Agreement shall be deemed to grant to the Receiving Party a license expressly\nor by implication under any patent, copyright or other intellectual property right. The\nReceiving Party hereby acknowledges and confirms that all existing and future intellectual\nproperty rights related to the Confidential Information are exclusive titles of the Disclosing\nParty. For the sake of clarity based in reciprocity and good faith of the Parties, the Receiving\nParty will not apply for or obtain any intellectual property protection in respect of the\nConfidential Information received. Likewise, any modifications and improvements thereof by\nthe Receiving Party shall be the sole property of the Disclosing Party.\n\n3.7 The Receiving Party shall promptly return or destroy all copies (in whatever form reproduced\nor stored), including all notes and derivatives of the Confidential Information disclosed under\nthis Agreement, upon the earlier of\n\ni) the completion or termination of the dealings contemplated in this Agreement;\nii) or the termination of this Agreement;\niii) or at the time the Disclosing Party may request it to the Receiving Party.\nMutual Non-Disclosure Agreement Page 3 of 5\n@ Public Version 1.1\nO 2018-04-03_NDA_GLEIF_template_v1.1 2018-04-03\n","contentLength":3234,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:42:08.062Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/gleif-certification-process/2018-04-03_nda_gleif_template_v1.1.pdf","content":"3.8 Notwithstanding the foregoing, the Receiving Party may retain such of its documents as\nrequired to comply with mandatory law, provided that such Confidential Information or copies\nthereof shall be subject to an indefinite confidentiality obligation.\n\n3.9 Inthe event that the Receiving Party is asked to communicate the Confidential Information to\nany judicial, administrative, regulatory authority or similar or obliged to reveal such\ninformation by mandatory law, it shall notify promptly the Disclosing Party of the terms of\nsuch disclosure and will collaborate to the extent practicable with the Disclosing Party in order\nto comply with the order and preserve the confidentiality of the Confidential Information.\n\n3.10 The Parties agree that the Disclosing Party will suffer irreparable damage if its Confidential\nInformation is made public, released to a third party, or otherwise disclosed in breach of this\nAgreement and that the Disclosing Party shall be entitled to obtain injunctive relief against a\nthreatened breach or continuation of any such breach and, in the event of such a breach, an\naward of actual and exemplary damages from any court of competent jurisdiction.\n\n3.11 The Receiving Party shall immediately notify the Disclosing Party upon becoming aware of any\nbreach of confidence by anybody to whom it has disclosed the Confidential Information and\ngive all necessary assistance in connection with any steps which the Disclosing Party may wish\nto take prevent, stop or obtain compensation for such a breach or threatened breach.\n\n3.12 The Confidential Information subject to this Agreement is made available \"as such\" and no\nwarranties of any kind are granted or implied with respect to the quality of such information\nincluding, but not limited to, its applicability for any purpose, non-infringement of third party\nrights, accuracy, completeness or correctness.\n\n3.13 Neither Party is under any obligation under this Agreement to disclose any Confidential\nInformation it chooses not to disclose. Further, neither Party shall have any liability to the\nother Party resulting from any use of the Confidential Information except with respect to\ndisclosure of such Confidential Information in violation of this Agreement.\n\n3.14 Nothing in this Agreement shall be construed to constitute an agency, partnership, joint\nventure, or other similar relationship between the Parties.\n\n4 Duration and Termination\n\nThis Agreement shall remain in effect for a period of two (2) years from the Effective Date unless\n\notherwise terminated by either Party giving notice to the other of its desire to terminate this\n\nAgreement. The requirement to protect Confidential Information disclosed under this Agreement\n\nshall survive termination of this Agreement.\n\n5 Applicable Law and Jurisdiction\n\nThis Agreement shall be construed and interpreted by the laws of Switzerland. The civil court of Basel\n\nshall have jurisdiction.\n\nMutual Non-Disclosure Agreement Page 4 of 5\n@ Public Version 1.1\n2018-04-03_NDA_GLEIF_template_v1.1 2018-04-03\n","contentLength":3043,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:42:08.062Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/gleif-certification-process/2018-04-03_nda_gleif_template_v1.1.pdf","content":"6 Validity\nIf any provisions of this Agreement are invalid or unenforceable, the validity of the remaining\nprovisions shall not be affected. The Parties shall replace the invalid or unenforceable provision by a\nvalid and enforceable provision that will meet the purpose of the invalid or unenforceable provision\nas closely as possible.\n7 Subsequent Agreements\nAncillary agreements, amendments or additions hereto have to be made in writing.\n8 Communications\nAny notices or communications required between the Parties shall be delivered by hand, email, or\nmailed by registered mail to the address of the other Party as indicated above. Any subsequent\nmodification of a Party's address should be reasonably communicated in advance to the effect of this\nAgreement.\n9 Competition\nThe receipt of Confidential Information pursuant to this Agreement will not prevent or in any way\nlimit either Party from developing, making or marketing products or services that are or may be\ncompetitive with the products or services of the other; or providing products or services to others\nwho compete with the other Party; as long as those results have not become from a breach of this\nAgreement.\nIN WITNESS WHEREOF, the Parties hereto have caused this Mutual Non-Disclosure Agreement to be\nexecuted as of the Effective Date stated above.\nGLEIF I\nBy: Stephan Wolf Sven Schumacher By:\nFunction: CEO General Counsel Function(s):\nBy:\nFunction(s):\nMutual Non-Disclosure Agreement Page 5 of 5\n@ Public Version 1.1\n2018-04-03_NDA_GLEIF_template_v1.1 2018-04-03\n","contentLength":1536,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:42:08.062Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/gleif-certification-process/2021-09-10-appendix-2-contact-details.pdf","content":"GGLEIF’ rotactng digtor st\nContact Details\nAppendix 2\n\nGLEIF \\\nRevision Version 2.0 ‘\n\n2021-09-10\n","contentLength":98,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:42:14.426Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/gleif-certification-process/2021-09-10-appendix-2-contact-details.pdf","content":"Contact Details of the Parties\nto be completed by GLEIF and the Mapping Partner at time of signature of the Cooperation\nAgreement, and to be kept accurate and up-to-date throughout the duration of the\nCooperation Agreement\n\nBasic contact details\n\nLegal domicile:\n\nGlobal Legal Entity Foundation (GLEIF)\n\nSt. Alban-Vorstadt 5\n\nCH-4052 Basel (Switzerland)\n\nCommerce-Register ID: CHE-200.595.965\n\nFrankfurt Office:\n\nBleichstrasse 59\n\nDE-60313 Frankfurt/Main (Germany)\n\nPhone (Switchboard):\n\nBasel: +41 61 5087045\n\nFrankfurt: +49 69 9074999-0\n\nGeneral E-Mail Address:\n\ninfo@gleif.org\n\nAuthorized Signatory / Signatories\n\nStephan Wolf\n\nCEO (joint signature at two)\n\nMail: stephan.wolf@gleif.org\n\nPhone (direct line): +49 69 9074999-11\n\nClare Rowley\n\nHead of Business (joint signature at two)\n\nMail: clare.rowley@gleif.org\n\nPhone (direct line): +49 69 9074999-24\nGLEIS - Global LEI System LEI Mapping Cooperation Agreement Page 2 of 3\n\nGLEIF Appendix 2 — Master Copy Version 2.1\n\n2021-09-10-Appendix-2-Contact-Details 10 September 2021\n","contentLength":1030,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:42:14.426Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/gleif-certification-process/2021-09-10-appendix-2-contact-details.pdf","content":"Xiaodi Wang\nMail: xiaodi.wang@gleif.org\nPhone: +49 151 17120525\nGLEIS - Global LEI System LEI Mapping Cooperation Agreement Page 3 of 3\n@ Appendix 2 — Master Copy Version 2.1\nC 2021-09-10-Appendix-2-Contact-Details 10 September 2021\n","contentLength":233,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:42:14.427Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/gleif-certification-process/2020-02-13_internal-controls-checklist_v2.0-final.pdf","content":"@ Protecting digital rust\n° °\nCertification\n°\nof LEl Mapping\nInternal Controls Checklist\nGLEIF\nACCREDITED\n","contentLength":106,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:42:31.187Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/gleif-certification-process/2020-02-13_internal-controls-checklist_v2.0-final.pdf","content":"Contents 2\nAContactDetails ........coiiiiiiiiii ittt iiiieetneeenes. 3\nBENtity Structure. ........... ittt iiiiiitnnnrnnnnnannanaaa. lt\nC Financial Data, Audits and General Governance.. . . .. ............5\nD Records Management. .. ...........c ittt 6\nE Software Development . .......... ittt nrennnnnnnnaasld\nF Operations Assessment ... ..........ci ittt ireneeneeneennennan. .8\nChecklist Instructions\n\n» Please complete Sections A, B and C after completion\n\n« of the Non-Disclosure Agreement when requested\n\n* by Business Operations.\n\n* Please ensure that supporting documentation is provided\n\n* wherever noted.\n\n» Please focus your responses ONLY on the systems, tools,\n\n* applications, practices and procedures which directly\n\n* relate to the development and production environment\n\n« for the mapping application(s).\n\n» Please be as specific and limited as possible.\n\n» You will be asked to complete Sections D-F of the Checklist\n\n» after signing the Cooperation Agreement.\n\nGLEIF 2020/02\n","contentLength":993,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:42:31.188Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/gleif-certification-process/2020-02-13_internal-controls-checklist_v2.0-final.pdf","content":"General Information for Certification of Mapping Documentation Submission 3\n> Required Documentation to be Submitted with Checklist Responses\nA Contact Details\nLegal Name of Mapping Partner VAT No. if applicable\nLEI (20 Alphanumeric Characters)\nSubmission Date (YYYY-MM-DD)\nURL of Mapping Partner\nParent/Grandparent/Owner/Governing Organization if applicable\nChecklist A-C attached\nLEI of Parent/Grandparent/Governing Organization if applicable Checklist D-F attached\nInternal Project Manager Authorized Representative\nName Name\nTitle Title\nEmail Email\nPhone Phone\nKey Contact Operations Key Contact Finance\nName Name\nTitle Title\nEmail Email\nPhone Phone\nAre you including any Yes If Yes, please list the following:\nthird-party assurance Type of report Date of report\nreports as part of this No yp P P\napplication? To be obtained\nReport expiry date Service provider\nCertificate attached? Yes No\nIn submitting this document, | confirm that, to the best of my knowledge, my organization is in\ncompliance with or is able to become compliant with the requirements of GLEIF reflected in the\nCooperation Agreement as of the date of this document unless otherwise noted.\nAuthorizing Representative Signature*\nE-Signature Date (YYYY-MM-DD)\nName\nTitle\nEmail\nPhone\n*Please note: the Authorized Representative may sign this form physically or electronically.\nGLEIF 2020|02\n","contentLength":1361,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:42:31.188Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/gleif-certification-process/2020-02-13_internal-controls-checklist_v2.0-final.pdf","content":"General Information for Certification of Mapping Documentation Submission L\nRequired Documentation to be Submitted with Checklist Responses\nB Entity Structure\nLegal Name of Mapping Partner\nPlease provide your most recent Annual Report/Financial Statements\n\nStatement of Beneficial Ownership\n\nPlease list all Entities which have >20 % LEI# %\n\nownership stake in your organization\n\nGLEIF 2020|02\n","contentLength":394,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:42:31.188Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/gleif-certification-process/2020-02-13_internal-controls-checklist_v2.0-final.pdf","content":"General Information for Certification of Mapping Documentation Submission 5\n> Required Documentation to be Submitted with Checklist Responses\nC Financial Data, Audits and General Governance\nLegal Name of Mapping Partner\nFinancial Data, Audits and General Governance\nType of Document Xrefto Docs Provided Yes No N/A Additional Documentation Requested\nPlease cite document Please check one\nand page #\n1. General Questions - Going Concern\n11 Do youhave a formal budget for this project? > Please provide budgets and explain financial assumptions,\nvolume estimations, operating budget, expenses, etc.\n1.2 Do you fully expect your organization to fund > Please briefly explain your long-range\nthis activity for the foreseeable future? business objectives.\n2. General Questions - Specific Mapping Service Operations\n21 Are you currently involved with any litigation matters > Provide a summary of all relevant litigation, arbitration,\nwhich could effect your mapping services? claims and proceedings.\n2.2 reyou subject to regulatory compliance requirements > Please list all relevant governmental regulatory agencies\nwhich could affect your mapping services? and the applicable regulations with respect of LEI activities.\nGLEIF 202002\n","contentLength":1229,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:42:31.188Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/gleif-certification-process/2020-02-13_internal-controls-checklist_v2.0-final.pdf","content":"General Information for Certification of Mapping Documentation Submission 6\n> Required Documentation to be Submitted with Checklist Responses\nD Records Management\nLegal Name of Mapping Partner\nRecords Management\nType of Document Xrefto Docs Provided Yes No N/A Please provide a brief narrative\nPlease cite document Please check one\nand page #\n1. Isaparticular function responsible for all aspects of\nrecord retention as per your established internal\npolicies?\nWhat s your testing process and periodicity?\n2. Isperiodic training provided to all relevant personnel\n(including employees, contractors and temporary\nstaff) to make them aware of your Records\nManagement procedures?\n3. Do youmaintain the following:\n31 Allsoftware including program logic and algorithms\nand supporting systems/software and utilities?\n3.2 Doyou know where all items in 3.1 are physically\nlocated and who and how secure custody is\nmaintained?\n3.3 Do you utilize test, demo or guest accounts\nand/or data?\n4. Do youensure access to relevant records is restricted\nto only those employees who are appropriately\nauthorized and need access to perform their duties?\n5. Do you ensure control proceduresrelating to the\nphysical and environmental protection of relevant\nrecords, including archived dataisin place and\nfunctioning properly?\n6. Do youensurerelevant records are only destroyed\nin compliance with your procedures and any\ncontractual, local or legal requirements?\nGLEIF 202002\n","contentLength":1452,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:42:31.188Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/gleif-certification-process/2020-02-13_internal-controls-checklist_v2.0-final.pdf","content":"General Information for Certification of Mapping Documentation Submission 7\n> Required Documentation to be Submitted with Checklist Responses\nE Software Development\nLegal Name of Mapping Partner\nSoftware Development\nType of Document Xrefto Docs Provided Yes No N/A Please provide a brief narrative\nPlease cite document Please check one\nand page #\n1. Do youhave a document which describes the\nsoftware development tools and environment in\nplace for the mapping application and supporting\napplications as applicable?\n2. Do youhave aformal process for developing and\napproving new software? And software changes?\n3. Do youhave aformal process in place for identifying,\ntracking and correcting software errors / bugs?\n4. Do youhave standard IT service management\nprocesses in place? This would include a patching\nprocess and upgrade/update policies and\nprocedures.\nGLEIF 202002\n","contentLength":874,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:42:31.188Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/gleif-certification-process/2020-02-13_internal-controls-checklist_v2.0-final.pdf","content":"General Information for Certification of Mapping Documentation Submission 8\n> Required Documentation to be Submitted with Checklist Responses\nF Operations Assessment\nLegal Name of Mapping Partner\nType of Document Xrefto Docs Provided Yes No N/A Additional Documentation Requested\nPlease cite document Please check one\nand page #\n1. Doyouhaveinplace procedures to review\npossible matches given:\na. therelevantreference data associated with the LEI > Please provide supporting documentation,\nor your record changes (for example, address or legal such as policies or procedure manual sections.\nname, etc.)?\nb. theregistration status of the LEI changes to merged, > Please provide supporting documentation,\nretired, annulled or duplicate? such as policies or procedure manual sections.\nc. youridentifier record changes to an equivalent > Please provide supporting documentation,\nstatus of merged, retired, annulled or duplicate (as such as policies or procedure manual sections.\napplicable)?\nd. Do you check for such events frequently? Please > Please provide supporting documentation,\nspecify your frequency. such as policies or procedure manual sections.\nGLEIF 202002\n","contentLength":1166,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:42:31.188Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/lei-mapping/gleif-certification-process/2020-02-13_internal-controls-checklist_v2.0-final.pdf","content":": > Enabling global identity\nG L E I F Protecting digital trust\nGlobal Legal Entity Identifier Foundation (GLEIF)\nSt. Alban-Vorstadt 5, PO Box\n4002 Basel\nSwitzerland\ngleif.org\nChairman of the Board: Gerard Hartsink\nChief Executive Officer: Stephan Wolf\nLEI of GLEIF: 506700GE1G29325QX363\n© 2020 All rights reserved\n","contentLength":315,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:42:31.188Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/proactive-management/2021-11-10_checkforduplicatedictionary_v1.2-final.pdf","content":"OGLEIF, Protecting dioital rust\nGLEIF Check for Duplicates\nDictionary\n","contentLength":70,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:42:54.387Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/proactive-management/2021-11-10_checkforduplicatedictionary_v1.2-final.pdf","content":"Table of Contents\n1. Purpose of the Check for Duplicates .......cccceeeeireeceenierencrenceeerenceenceenees D\n2. Check for Duplicates workflow and methodology........ccccccevvueeerenneeenne... 6\n2.1 Pre-PrOCESSING. . et eeeeeeeeee e e e ettt s s s e e e e e eseeeeeeeeebesnsnsnnnsnsassssesaseeeeeeeessesnens O\nFollowing preparation activities are performed: ..........cccceeeceeeviiiiccie st esie e, B\n2.2 Core algorithm ..o srare e e s e snaaeeeesenns T\n2.3 POST-PrOCESSING ..ttt e e e e e eeeeeee e e e e e e e e eeeeeeeenennens D\nGLEIF Check for Duplicates Page 2 of 11\n@ Public Version 1.2 final\n2021-11-10_CheckForDuplicateDictionary_v1.2_Final.docx 2021-11-10\n","contentLength":666,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:42:54.387Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/proactive-management/2021-11-10_checkforduplicatedictionary_v1.2-final.pdf","content":"3. Record deduplication: As potential duplicates are identified in several steps, the same record\ncould match on different criteria in the core algorithm (e.g.: Registration Authority comparison\nand fuzzy string matching) and be returned to LEI Issuers multiple times. In order to reduce the\neffort of the LEI Issuers, Record deduplication is then applied and only one instance of the record\nis returned as potential duplicate.\n\nGLEIF Check for Duplicates Page 11 of 11\n@ Public Version 1.2 final\nO 2021-11-10_CheckForDuplicateDictionary_v1.2_Final.docx 2021-11-10\n","contentLength":565,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:42:54.387Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/proactive-management/2021-11-10_checkforduplicatedictionary_v1.2-final.pdf","content":"_ Head of Data Quality Management and Data Science\nAbout this Document\nThis document contains a short description of GLEIF’s Check for Duplicates facility providing more\ntransparency to the users. This document does not replace the Implementation Note for Check for\nDuplicates or its Appendix.\nChapter 1 is about the purpose of the Check for Duplicates facility. Chapter 2 describes the current\n(as of the date of distribution of this document) approach for duplicates detection. The algorithm\nand parametrization may change in the future due to continuous improvement.\nChange History\nThis section records the history of all changes to this document.\n2021-11-10 1.2 Update layout and wording GLEIF\n2019-09-26 1.1 Clarifications GLEIF\n2016-10-06 1.0 Final version GLEIF\nGLEIF Check for Duplicates Page 3 of 11\n@ Public Version 1.2 final\n2021-11-10_CheckForDuplicateDictionary_v1.2_Final.docx 2021-11-10\n","contentLength":902,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:42:54.387Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/proactive-management/2021-11-10_checkforduplicatedictionary_v1.2-final.pdf","content":"Glossary\n\nCosine similarity A vector similarity metric that treats each sequence as a vector, and\ncalculates their cosine as the similarity score.\n\nExclusivity violation A violation of this type appears when any particular Legal Entity has\nsufficiently similar Reference Data against the threshold.\n\nExtended Exact Match String matching technique using the normalized strings and\nperforming exact match between those. For funds, this method is\nalso used for partial prefix/suffix matching.\n\nLEI Database The Global LEI Repository and other LEI Records that have been\nsubmitted to the Check for Duplicates facility.\n\nLE-RD Legal entity’s reference data.\n\nLevenshtein distance A metric for distinguishing differences between two strings. This\ndistance is the number of single character edits needed to turn one\nstring into the other. These edits consider insertions, deletions or\nsubstitutions.\n\nMonge-Elkan (Cosine) A string similarity metric that uses tokens (i.e. words) combined with\n\ndistance internal distance. In this case, the internal distance metric is Cosine.\n\nn-gram Splits of any particular words in strings of length n.\n\npunct: Posix Character Class containing a defined set of punctuation\ncharacters.\n\nUniqueness violation A violation of this type appears when an LEI code appears more than\nonce.\n\nGLEIF Check for Duplicates Page 4 of 11\n@ Public Version 1.2 final\n2021-11-10_CheckForDuplicateDictionary_v1.2_Final.docx 2021-11-10\n","contentLength":1444,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:42:54.387Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/proactive-management/2021-11-10_checkforduplicatedictionary_v1.2-final.pdf","content":"1. Purpose of the Check for Duplicates\nIn order to support the LEl issuing organizations, GLEIF provides the appropriate and mandatory\nprocesses and a technical interface for LEI Issuer to check the LEI and LE-RD data for duplicate\nentries. LEls are to be checked one at a time prior to their publication using an automated web\nservice APl (“Endpoint”) provided by GLEIF.\nAdditional to LEI Issuers’ own systems checking against duplicates, LEl issuing organizations are\nrequested to use GLEIF’'s Check for Duplicates facility to check all LEI Records independent of their\nRegistration Status prior to publication. To further prevent duplicated entries, new records are\ncompared to all records in the Global LEI Repository as well as to not yet issued LEI Records\nsubmitted to the Check for Duplicates facility by other LEl Issuers. This ensures that even if two\norganizations have been approached by the same legal entity, the LEI Issuers will notice the parallel\nprocess and will coordinate further with their client and the involved LEl Issuer, in order to prevent\nthe introduction of duplicates in the system.\nGLEIF Check for Duplicates Page 5 of 11\nGLEIF Public Version 1.2 final\n@ 2021-11-10_CheckForDuplicateDictionary_v1.2_Final.docx 2021-11-10\n","contentLength":1252,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:42:54.387Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/proactive-management/2021-11-10_checkforduplicatedictionary_v1.2-final.pdf","content":"2. Check for Duplicates workflow and methodology\nThe general workflow of Check for Duplicates consists of three main steps:\nPre-processing Core algorithm Post-processing\ne Normalization of * Uniqueness check e Legal jurisdiction\nused fields and e Registration handling\ntokens Authority e Funds handling\ne Indexing comparison e Record\ne Scoping e Extended Exact deduplication\nstring matching\ne Fuzzy string\nmatching\nThe pre-processing contains a series of preparation activities on the data fields for the actual\ncomparison, e.g., identified legal form terms in names are standardized and all strings are handled\ncase-insensitive. This step also includes some technicalities like Indexing and Scoping, needed for the\ncore algorithm and duplicates identification. Indexing and Scoping are technical details of the\nunderlying database system and will not be further described in this document.\nThe core functionality of Check for Duplicates for string matching is based on three similarity\nalgorithms: Levenshtein, Cosine and Monge-Elkan (combined with Cosine). Similarity is calculated for\nall combinations of LegalName, OtherEntityNames and TransliteratedNames.\nIn order to prune the suspected duplicates and keep the false positives at a minimum, additional\nmeasures are taken along the complete process, but especially in the Post-processing section of the\nworkflow.\n2.1 Pre-processing\nThe submitted LEI Record is always checked against the Global LEI Repository created from the latest\nGLEIF concatenation file. Only LEls with EntityStatus ACTIVE and RegistrationStatus different from\nDUPLICATE and ANNULLED are considered for the further processing. Afterwards Indexing and\nScoping is taking place.\nFollowing preparation activities are performed:\n¢ Ignore a leading or trailing “the”\n¢ Handle equally “&\"” and “and”\no lIgnore multiple consecutive spaces\n¢ Handle equally different spellings of the same legal form (e.g.: “Société anonyme”, “SA” or\n”S.A.”)\no lIgnore punctuation characters as defined in :punct: (Extended Exact Match and Registration\nAuthority comparison only)\nGLEIF Check for Duplicates Page 6 of 11\n@ Public Version 1.2 final\n2021-11-10_CheckForDuplicateDictionary_v1.2_Final.docx 2021-11-10\n","contentLength":2213,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:42:54.387Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/proactive-management/2021-11-10_checkforduplicatedictionary_v1.2-final.pdf","content":"Different steps in the core algorithm consider different normalization steps from the above describe\nlist. In general, Check for Duplicates is also setup in a way to operate case-insensitive and (tokens)\norder insensitive.\n2.2 Core algorithm\nStep 1: Uniqueness check\nFirst, a uniqueness check is performed and records with identical LEls to the submitted LEI Record are\nreturned as Uniqueness violations in the response with \"duplicate_type\": \"UNIQUENESS\". Regardless\nof the result of this check, the next steps are also performed for all records.\nStep 2: Registration Authority comparison\nAn exact match on the RegistrationAuthoritylD (RAID) and normalized RegistrationAuthorityEntitylD\n(RAEID) will be directly (i.e.: without additional comparison of the names) suggested as a potential\nduplicate in the response with “duplicate_type”: EXCLUSIVITY. Likewise, an exact match on the\n(Other)ValidationAuthoritylD ((O)VAID) and normalized (Other)ValidationAuthorityEntitylD\n((O)VAEID) will also result in a potential duplicate. Reserved codes for RegistrationAuthoritylD and\nValidationAuthoritylD (RA888888 and RA999999) are excluded as well as missing RAEID and VAEID\ncodes.\nExample 1: Registration Authority comparison\nLEI sent to the facility LEls in the Database Potential Duplicates\nRAID: RA123456 LEI A: RAID: RA123456 LEI A\nRAEID: AB-123.456.789 RAEID: AB123456789\nLEI B: RAID: RA654321\nRAEID: AB-123.456.789\nNote: LEI Issuers should avoid publishing “n/a” (or similar) as RAEID for registries that do not provide\nan entity ID as this would count as exact match and potentially return a large number of duplicate\nrecords. The usage of placeholder values like “n/a” is monitored via GLEIF’s Data Quality Checks.\nStep 3: Extended Exact string matching\nIn general, names used for comparison are taken from the fields LegalName, OtherEntityName and\nTransliteratedOtherEntityName with all possible combinations.\nThe first part in the name matching algorithm is using Extended Exact matching. If the names match,\nthe records are presented as potential duplicates to the user.\nGLEIF Check for Duplicates Page 7 of 11\n@ Public Version 1.2 final\n2021-11-10_CheckForDuplicateDictionary_v1.2_Final.docx 2021-11-10\n","contentLength":2208,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:42:54.387Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/proactive-management/2021-11-10_checkforduplicatedictionary_v1.2-final.pdf","content":"Example 2: Extended Exact matching\nLEI sent to the facility LEls in the Database Potential Duplicates\nLegalName: LEI A: LegalName: LEIA\nYES Bank Inc. yes-bank, Inc\nLEI B: LegalName:\nThe Bank LTD\n\nStep 4: Fuzzy string matching\n\nIf the names do not match in Step 3, three fuzzy string-matching algorithms are performed after\n\napplying the following pre-processing on each original name:\n\no Pre-processing steps as described above\n\n¢ Remove weak tokens and store them in separate weak token lists for each string\n\nAfter this, two strings (i.e.: name of the submitted record and name in the LEI Database) are\n\ncompared:\n\n1. Levenshtein — This is the simplest similarity algorithm, which checks two strings for insertions,\nsubstitutions and/or deletions of single characters that lead the source string to match the target\nstring:\n\na. The number of edits (insertions, substitutions, deletions) to match the source and target\nstring is the Levenshtein Distance.\n\nb. This distance (d) is divided by the length of the longer string to compare (source or\ntarget).\n\nc. 1-—disthe Levenshtein similarity. Results closer to 1 suggest a high similarity between a\npair of strings.\n\n2. Cosine — The cosine similarity calculates the cosine of the angle between two vectors, where\neach vector represents one of the strings. The result is a number between 0 and 1, where\nnumbers closer to 1 represent closer similarity between the strings provided.\n\n3. Monge-Elkan (Cosine) — This algorithm combines the benefits of sequence-based and set-based\nmethods and hence is less depended on the order of phrases in the strings.\n\nIf any of the three algorithms return a score above a defined threshold, the weak token lists are\n\ncompared (see example 4 below). The pair is considered to be a suspected duplicate, if at least one\n\ntoken appears in both lists (empty token lists match with all tokens). Each matching record will be\nreturned as Exclusivity violation in the response with \"duplicate_type\": \"EXCLUSIVITY\".\nGLEIF Check for Duplicates Page 8 of 11\n@ Public Version 1.2 final\n2021-11-10_CheckForDuplicateDictionary_v1.2_Final.docx 2021-11-10\n","contentLength":2123,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:42:54.387Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/proactive-management/2021-11-10_checkforduplicatedictionary_v1.2-final.pdf","content":"Example 3: Fuzzy name match including standardized Legal Forms in names\nLEI sent to the facility LEls in the Database Potential Duplicates\nLegalName: LEI A: LegalName: LEI A and LEI D\nLiability Company\nLEI B: LegalName:\nOther Project, LLC\nLEI C: LegalName:\nFlux Project GmbH\nLEI D: Legal Name:\nFlex Project\nWeak tokens are words that are identified as less important for distinguishing entities than the main\npart of the legal name. Typically, those tokens appear in many names, have a considerable number of\ncharacters and therefore increase the similarity score to levels which reach the required threshold of\na fuzzy algorithm. These string elements include standardized legal forms and typical terms with high\nfrequency (e.g., bank, investment). In cases where the string match is identified only on weak tokens,\nthe match is considered as a false positive and not presented to the user.\nExample 4: Weak token match only\nLEI sent to the facility LEls in the Database Potential Duplicates\nLegalName: LEI A: LegalName: \nAB Handelsbolag XY Handelsbolag\nLEI B: LegalName:\nOther Handelsbolag\n2.3 Post-processing\nPost-processing is performed on all records found in the Registration Authority comparison and\nname matching steps in order to remove false positives from the list of potential duplicates returned\nto LEl Issuers. The post-processing consists of three steps: Legal Jurisdiction comparison, extended\nfund analysis and record deduplication.\n1. Legal Jurisdiction comparison: For potential duplicates identified by the name matching\nalgorithms, it is checked if they have the same Legal Jurisdiction. If the Legal Jurisdiction differs,\nGLEIF Check for Duplicates Page 9 of 11\n@ Public Version 1.2 final\n2021-11-10_CheckForDuplicateDictionary_v1.2_Final.docx 2021-11-10\n","contentLength":1782,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:42:54.387Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/proactive-management/2021-11-10_checkforduplicatedictionary_v1.2-final.pdf","content":"the record is not presented as a potential duplicate. Only the country-part of the Legal\nJurisdiction field is compared (e.g.: if one record has Legal Jurisdiction “US-DE” and the other\n“US-NY”, both jurisdictions are considered to be the same). If a record does not provide a Legal\nJurisdiction, it will not be filtered out based on Legal Jurisdiction.\nExample 5: Post processing based on legal jurisdiction\nLEI sent to the facility LEls in the Database Potential Duplicates\nLegalName: LEI A: LegalName: LEIB\nPower Steels Private Limited Power Steels Private\nLegal Jurisdiction: Limited\nUs Legal Jurisdiction:\nIN\nLEI B: LegalName:\nPower Steels Private\nLimited\nLegal Jurisdiction:\nUS-NY\n2. Extended fund analysis: If one of the records has EntityCategory “FUND”, Extended Exact Prefix-\nSuffix match is performed to avoid multiple false hits for fund series that vary only on a number.\nExample 6: Post processing for FUNDS\nLEI sent to the facility LEls in the Database Potential Duplicates\nLegalName: LEI A: LegalName: LEI B and LEI C\nEntityCategory: EntityCategory:\n FUND\nLEI B: LegalName:\nInvestment Fund 3\nEntityCategory:\n\nLEI C: LegalName:\nUmbrella Fund -\nInvestment Fund 5\nEntityCategory:\nFUND\nGLEIF Check for Duplicates Page 10 of 11\n@ Public Version 1.2 final\n2021-11-10_CheckForDuplicateDictionary_v1.2_Final.docx 2021-11-10\n","contentLength":1344,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:42:54.387Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"@’ Protect dletto) st\n\nState Transition and\nValidation Rules for\nCommon Data File formats\n","contentLength":90,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.674Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Table of Contents\nY Yo 101 R 4 o TR 0 T YL U] 44 =T 4 Y\nAN | 1o o 1V T ' o TP | ||\n1.1 Terms and Definitions......ccccceeeviiiiiieie it csiieeee s sneee e s s sneeeeessnnnene 10\n1.2 Terminology and Typographical Conventions .........ccccecevveeeeivinineeeeinnnieeneeensiennn 12\n2 Lifecycle and General CoNCePtS.....cccerrueerenirrnecrenrrennceenceenncrnncesnecseneseneeee 14\n2.1 LEIRecord Set Reference Data ......ccccceeeeeiiiieeeeiiiiiicie s csssieeee s ssineeee s sssvvveeeesnnnenn 14\n2.1.1 Legal Entity data (Level 1 data — ‘“Who is WhO') ....cccovevvivicccieeeceecee e, 14\n2.1.2 Legal Entity relationship information (Level 2 data — “Who owns whom’)............ 14\n2.2 Corroboration of LEI Record Set .......ccccvivviiiiiiiiiiiiiieeee e ssieie e s ssiineeeeennn 21\n2.2.1 LEIREGISTIatioN ..ccceeiieeiiiiieie ettt e re e e e e e s s erneeneneeeaneanenes 21\n2.2.2 Validation c...uueeii et ee s srae e s snaees 22\n2.2.3 Application of GLEIF Registration Authorities List ........cccccccevevvieeccciesceeiiieeennn. 25\n2.3 LIf@ CYCIE coeeeee e s e sraae e e s s snnneaeeennn 27\n2.3.1 Registration Status COES .....ccuieiiiiiiiiei ittt ssrreee s seraees 28\n2.3.2 Changes in Registration Status due to Legal Entity Events .......c.cccveeviecviieeeriennen. 30\n2.3.3 Changes in Registration Status when a registration error is resolved.................... 31\n2.4 Registration Status Codes for Transient PUrpOSES......cccccevvvveeeeeriniinieensesiiinieeeennnn 31\n2.5 RENEWAI ciiiiciiiieiee e e s e ae e e snareeesenes 32\n2.6 1SO 3166 Conformance of Address and Jurisdiction Fields.............ccccceeeinnnennnnn. 32\n2.7 AdAress REPOITING ..uuviiiiiiiiiiiieee ettt eee s re e e sraae e ee s s sssaeeee s essaasaaaeesesens 33\n2.8 Entity Legal FOrm RePOItiNg ....cccvvcuuiiiiiiiiiiiieiieciiiiece s esssieeee s sveeeee s ssssvveeeeannnens 34\n2.9 Language, translation and transliteration ..........ccccceceeeiiivi s 35\n3 General State Transition and Validation Rules...........cccccccceeerrreennnnnnne.... 36\n3.1 Header Section (applicable to all files) .....cccceevveeeiieeiiiiieeceecee e 37\n3.2 CONTENT DAt e e e e e s DO\nR I O [ g 7= {1 o -1 (o] TP P TR PUPPPUPPPPPPRPPPOPOPRRRRRC 1o\nK I 1 L= @o | 1= | SO PSP PPPRUPPPPURPRPRPPNC 1 |\n3.5 Delta Start..cccccciiiee e sraeeee s sssnnneesesnsssnnnaeeen e 40\n3.6 ReCOrd COUNL .uviiiieiiiiiiiie sttt esie e e siieeee s s s snnneeessnsnnneesssssssnnnneeen s 40\n3.7 Extension (applicable to multiple Header Sections and data sections) ................41\n3.8 LEIRECOIT ettt s s sttte s sarre e e s ssvive e ae s s s sasbnaesesssnnnanesessnnnnnnenessnes B2\n3.9 LEI Code (context: LEI-CDF)......ccccieieiiiieeiiiiieciiieeessiieessevee e sieeeessvnessssnneessnnneee s 42\n3.10 Legal NAME c.iiiiiie ittt ee s ee s e s sra e e eesssvaneeessssasnnnnessssnnsneeeess B3\n3.11 Other ENntity NAmMES c.uuuiiiiiiiiiieiee ettt svrae e s sssvnneee s s s sainnae e s s snnneeee s 43\nG State Transition and Validation Rules for Common Data File formats Page 2 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":3087,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.674Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Common Data Files Format | The mandatory requirements for the structure and content of Legal\n\n(CDF) Entity Reference Data.\n\nELF code / ELF code list Abbreviation for the ISO 20275: Entity Legal Forms (ELF) code and\ncode list.\n\nExclusivity Violation Registration error where a Legal Entity has more than one LEI.\n\nGeneral Government Consists of institutional units that, in addition to fulfilling their\n\nSector political responsibilities and their role of economic regulation,\nproduce services (and possibly goods) for individual or collective\nconsumption mainly on a non-market basis and redistribute income\nand wealth.\n\nInstitutional Unit An institutional unit is an economic entity that is capable, in its own\nright, of owning assets, incurring liabilities and engaging in economic\nactivities and in transactions with other entities.\n\nInternational Organizations | Non-resident units created by international agreements or other\narrangements for the provision of non-market services or financial\nintermediation at the international level.\n\nLegal Entity Legal person or structure that is organized under the laws of any\njurisdiction (as defined in ISO 17442).\n\nLEl issuer, LOU An entity issuing and managing LEI Records; also referred to as\nManagingLOU, Managing LOU or just LOU (Local Operating Unit).\n\nLEI Record An XML data record in LEI-CDF format detailing one LEl record as\nreported by a Legal Entity to its LOU, and by the LOU to GLEIF.\n\nLEI Record Set An XML data record in CDF format describing one Legal Entity,\nincluding its related relationship information.\n\nRA code / RA list Abbreviation for the GLEIF Registration Authorities (RA) code and\nlist.\n\nReference Data The entity description and registration information recorded in the\nLEI Record Set.\n\nRelationship Record (RR) An XML data record in RR-CDF format detailing one relationship type\nbetween two Legal Entities, as reported by a Legal Entity to its LOU,\nand by the LOU to GLEIF.\n\nState Transition and Validation Rules for Common Data File formats Page 11 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2135,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.674Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"¢ The StartNode of a fund relationship SHALL be a fund entity, categorized by using the correct\nEntityCategory value FUND.\no If the RelationshipType is:\ne IS _SUBFUND_OF, then the EndNode of the relationship SHALL be a fund entity, categorized\nby using the correct EntityCategory value FUND (see\no Figure 8, relationship LEI A -> LEI D).\ne IS_FUND-MANAGED_BY, then the EndNode of the relationship SHALL be:\no afund entity, categorized by using the correct EntityCategory value FUND (see\no Figure 8, relationship LEI F -> LEI F).\ne aregular entity, categorized by using the correct EntityCategory value GENERAL (see\no Figure 8, relationship LEI A -> LEI G).\n* asole proprietor entity, categorized by using the correct EntityCategory value\nSOLE_PROPRIETOR.\ne IS _FEEDER_TO, then the EndNode of the relationship SHALL be a fund entity, categorized by\nusing the correct EntityCategory value FUND (see\no Figure 8, relationship LEI A -> LEI E).\n¢ For fund entities, if the requirement for financial consolidation requirement persists, direct and\nultimate parent entities SHALL be reported (see\no Figure 8, relationships LEI D -> LEI B and LEI C); In general for fund entities apply the same rules\nas described in chapter 2.1.2.\n¢ Fund entities MAY provide exact one Relationship Record of a type IS_SUBFUND_OF and\nIS_FEEDER_TO.\n¢ Reported ACTIVE fund relationships SHALL at least provide one RelationshipPeriod with\nPeriodeType RELATIONSHIP_PERIOD with a StartDate but no EndDate. Additional\nRelationshipPeriods MAY be included, if applicable (see 3.51).\n¢ Independent of what role in a relationship a fund entity plays (e.g., sub-fund, umbrella fund), the\nLegalName of the entity SHALL be its standalone LegalName and SHALL NOT include\nconcatenation of any related entities; in cases where an ‘Umbrella Structure’ relationship is\npresent, GLEIF will represent the names of the both the fund and the umbrella entities on LEI\nSearch as has been specified in the LEI-ROC policy.\n4.4 Issue New LEI - Fund in formation\nIn some jurisdictions or financial markets, fund entities require an LEl in order to register the fund or\nset up clearing accounts, before they become active from a legal perspective. In such cases, LEI\nState Transition and Validation Rules for Common Data File formats Page 101 of 170\nGLEIF Public Version 2.7.1 Final\n2022-04-01_State-Transition-Validation-Rules_v2.6_final.docx 2023-03-07\n","contentLength":2400,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.674Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"issuers SHALL follow these guidelines for setting up and maintaining the LEI Record for a not yet\n\nactive FUND:\n\ne The LEl issuer SHALL take due diligence to verify that the fund meets or will shortly meet the\nrequirements for entering the process requiring the LEI.\n\no The LEl issuer SHALL create and validate an LEI Record for the fund, as described above, including\nall relevant relationships and based on the available information and with the following special\nrules:\n\no EntityStatus SHALL be temporary set to NULL.\no EntityCreationDate SHALL NOT be populated.\no If afund relationship is introduced:\no RelationshipStatus SHALL be temporary set to NULL.\no RegistrationStatus of the relationship record SHALL be PUBLISHED.\ne StartDate of the RelationshipPeriod with PeriodType RELATIONSHIP_PERIOD SHALL NOT be\npopulated.\n\no During the setup of the fund, the LEl issuer SHALL work with the Legal Entity to keep the LEI\nRecord up to date with any Reference Data changes (e.g., a change in the name of the fund) and\nupdates the LEI Record Set accordingly. The LEl issuer SHALL be especially alert to the situation\nwhen the fund becomes a legally active entity, or the fund registration process is cancelled or\nwithdrawn.\n\n¢ If the fund becomes legally active, the LEl issuer SHALL update the LEI Record:\n\no EntityStatus SHALL be ACTIVE.\n\no EntityCreationDate SHALL be the date the legal status was achieved.\n\no If applicable, StartDate of the RelationshipPeriod with PeriodType RELATIONSHIP_PERIOD\nSHALL be the date the date the legal status was achieved.\n\no If the fund registration process is cancelled or withdrawn, the LEl issuer SHALL update the LEI\nRecord:\n\no RegistrationStatus of the LEI Record Set SHALL be ANNULLED.\n\no LElissuers SHALL monitor LEI Records for funds in formation closely and SHALL NOT keep them\nfor much longer in an uncertain state as it usually takes to register a fund in that jurisdiction.\n\nState Transition and Validation Rules for Common Data File formats Page 102 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2109,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.674Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o After the official registration of the fund entity is completed, the LEI Record Set SHALL be\nupdated accordingly.\n\n4.5 Issue New LEI - Sole proprietor\n\nWhen a new LEl is requested for a Sole Proprietor, in addition to or differing from section 4.1, the LEI\n\nissuer:\n\no SHALL ensure that the Legal Entity is registered in a Registration Authority\n\no SHALL validate and publish at least the following:\n\no RegistrationAuthorityID different from 'RA999999' and RegistrationAuthorityEntity|D SHALL\nbe included.\n\no EntityCategory SHALL be SOLE_PROPRIETOR.\n\no EntitySubCategory SHALL NOT be provided.\n\no LegalForm SHALL be a legal form applicable to Sole Proprietors in that jurisdiction.\n\no ValidationSources SHALL NOT be ENTITY_SUPPLIED_ONLY.\n\n4.6 Issue New LElI — Government entity\n\nWhen a new LEl is requested for a Government Entity as defined in chapters 3.22 and 3.23, in\naddition to or differing from section 4.1, the LEl issuer:\n\no SHALL validate and publish at least the following:\n\n+ EntityCategory SHALL be RESIDENT_GOVERNMENT_ENTITY.\n\no EntitySubCategory SHALL be CENTRAL GOVERNMENT, STATE GOVERNMENT, LOCAL\nGOVERNMENT or SOCIAL SECURITY, as applicable. If none of these sub-categories applies,\nEntitySubCategory SHALL NOT be provided.\n\n¢ If the Government Entity is registered in a registry or other authoritative source listed in the\nRA Code list in that country or jurisdiction, RegistrationAuthority SHALL be included\nrespectively and ValidationSources SHALL NOT be ENTITY_SUPPLIED_ONLY (unless the\nreserved code RA888888 is used to identify the authoritative source).\n\no If the Government Entity is not registered, but referred to in laws, regulations or decrees\nmade public by competent authorities, these public legal documents SHALL be used for\nvalidation and ValidationSources SHALL be either FULLY_CORROBORATED or\nPARTIALLY_CORROBORATED, depending on the extend of data elements validated against\nthat source. In this case RegistrationAuthoritylD RA999999 and ValidationAuthoritylD\nRA777777 SHALL be used and the document reference SHALL be added in the field\nOtherValidationAuthorityID.\n\nState Transition and Validation Rules for Common Data File formats Page 103 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2293,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.675Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o LegalAddress SHALL be the address recorded in the register or other authoritative source, if\nthe Government Entity is registered, or the official seat of the Government Entity as defined\nin their jurisdiction.\n\no HeadquartersAddress SHALL be the address of the Government Entity or the address of the\nauthorized entity managing the LEI registration on behalf of the Government Entity. The\naddress MAY be the same as LegalAddress. If another entity manages the registration,\nHeadquartersAddress SHALL include a ‘care-of’ part including the name of the entity\nmanaging the LEl registration.\n\no If the Government Entity has a dedicated legal form in the local jurisdiction according to the\nELF Code list, EntityLegalForm SHALL be included. If not, the appropriate reserved code (8888\nor 9999) SHALL be used together with a fitting descriptive term in the OtherLegalEntityForm\nfield.\n\n* If the Government Entity is declaring a direct and/or ultimate parent, the accounting\nstandard SHALL be GOVERNMENT_ACCOUNTING_STANDARD and the parent entity SHALL be\ncategorized as RESIDENT_GOVERNMENT_ENTITY as well. If no direct and/or ultimate parent\nis declared, a Reporting Exception with ExceptionReason NO_KNOWN_PERSON SHALL be\nincluded.\n\no If the Government Entity has a direct and/or ultimate parent that does not have an LEl, a\nReporting Exception with ExceptionReason NO_LEI SHALL be included.\n\nIf an LEI has been issued to a Government Entity prior to the implementation of LEI-CDF 3.1, the LEI\nissuer SHALL adapt the record in accordance with above rules during the next renewal at the latest.\nNote: Legal entities related to the European Union or related bodies SHALL NOT be categorized as\nGENERAL or RESIDENT_GOVERNMENT_ENTITY but rather as INTERNATIONAL_ORGANIZATION.\n4.7 Issue New LEI — International organization\n\nWhen a new LEl is requested for an International Organization as defined in chapter 3.22, which is\nnot organized in the specific legal form of a jurisdiction, in addition to or differing from section 4.1,\nthe LEl issuer:\n\no SHALL validate and publish at least the following:\n\no EntityCategory SHALL be INTERNATIONAL ORGANIZATION.\n\no EntitySubCategory SHALL NOT be provided.\n\n¢ HeadquartersAddress SHALL be the main base of operations or, in case most employees work\nin distributed field operations, the location of a secretariat or similar administrative central\nfunction.\n\n¢ The concept of LegalAddress as defined in the GLEIS does not apply to International\nOrganizations. LegalAddress SHALL be the same as HeadquartersAddress.\n\nState Transition and Validation Rules for Common Data File formats Page 104 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2731,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.675Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o If the RA Code list includes an authoritative source for International Organizations that can\nbe used to validate the data, that RA Code SHALL be included as RegistrationAuthority and\nValidationAuthority. In case the entity is not registered in any public registry, RA999999\nSHALL be used for RegistrationAuthoritylD. If there are also no Public Legal Documents\navailable that can be used to validate the data, RA999999 SHALL also be used as\nValidationAuthoritylD.\n\no ValidationAuthoritylD SHALL be RA777777 in case there is no information available in any\nregular registration authority and Public Legal Documents are used instead.\n\no AsInternational Organizations are established by treaties or other specific multinational\nagreements governed by international law, the concept of legal jurisdiction does not apply as\nfor other entities established under a national law. Legallurisdiction SHALL be the one of the\nfollowing:\n\no UN, if the entity is the United Nations, one of their specialized agencies or other\naffiliated organizations.\n\no EU, if the entity is established by a treaty signed by all members of the European Union\nand no other countries.\n\no XX, in all other cases.\n\no LegalForm SHALL be 9999, the reserved code for jurisdictions not on the ELF code list.\nOtherlLegalForm SHALL include the name of the treaty establishing the entity. If a series of\ntreaties or updates of treaties were signed to form or change the International Organization,\nonly the latest one establishing it in its current form SHALL be included.\n\no If the International Organization is declaring a direct and/or ultimate parent the parent entity\nSHALL be categorized as INTERNATIONAL_ORGANIZATION as well. If no direct and/or\nultimate parent is declared, a Reporting Exception with ExceptionReason\nNO_KNOWN_PERSON SHALL be included.\n\nIf an LEI has been issued to an International Organization prior to the implementation of LEI-CDF 3.1,\nthe LEl issuer SHALL adapt the record in accordance with above rules during the next renewal at the\nlatest.\n4.8 LEI Record Renewal\nIf a Legal Entity renews its LEI Record (see 2.5 Renewal above), the LEl issuer:\no SHALL validate that the Legal Entity is operational.\no SHALL validate the LEI Reference Data including all updates provided by the Legal Entity.\nState Transition and Validation Rules for Common Data File formats Page 105 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2470,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.675Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o SHALL validate that all reported ACTIVE relationships are still current and update the dates in\nperiods with PeriodType ACCOUNTING_PERIOD and DOCUMENT _FILING_PERIOD accordingly, if\npresent; if one or more relationships are no longer current, the Use Case 4.13.22 applies.\n\ne For a Fund entity, SHALL validate that all reported ACTIVE fund relationships (RelationshipType\nIS_ FUND-MANAGED_BY, IS SUBFUND_OF and IS_FEEDER_TO) are still current and update the\ndates in periods with PeriodType ACCOUNTING_PERIOD and DOCUMENT_FILING_PERIOD\naccordingly, if present; if one or more relationships are no longer current, the Use Case 4.13.22\napplies.\n\no SHALL check, if a parent without LEI (Exception reason NO_LEl) can be replaced by an LEI\nrelationship (see Use Case 4.9).\n\no SHALL check with the Legal Entity, if a reported exception due to legal obstacles still applies and\nreplace with a new Relationship Record if it is no longer valid.\n\ne SHALL set a new NextRenewalDate not more than 12 months after the current NextRenewalDate\nor the date of last Validation of the record, whichever is later; this applies to the Entity Data as\nwell as all ACTIVE Relationship Records.\n\ne For a Branch entity, SHALL ensure that the LEI Record of the (head office) Legal Entity has\nRegistrationStatus ISSUED; the Branch LElI Record SHALL NOT be renewed, if the\nRegistrationStatus of its head office LAPSED.\n\n4.9 LEI Record update — Parent Legal Entity without an LEIl requests\n\nan LEI\n\nThis Use Case applies where a parent without an LEI requests an LEI. As soon as the child Legal Entity\n\nis aware of this information, it needs to inform its LEIl issuer. The LEl issuer of the child entity:\n\no SHALL create the applicable Relationship Records(s) according to Use Cases 4.1.1.\n\no SHALL remove the NO_LEI Reporting exception record(s) from publication.\n\n4.10 LEI Record update — Relationship Record changes to Reporting\n\nException\n\nThis Use Case applies where the child Legal Entity reports a Reporting Exception after initially\n\ndeclaring a relationship. The LEl issuer:\n\ne SHALL annul the Relationship Record in case it was entered erroneously in the system.\n\no SHALL retire the Relationship Record in case the relationship for instance expired.\n\nState Transition and Validation Rules for Common Data File formats Page 106 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2418,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.675Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o In either case, the LOU SHALL continue publishing the ANNULLED/RETIRED Relationship\nRecord(s).\n\no SHALL create a new Reporting Exception and publish it.\n\n4.11 Lack of renewal — Legal Entity\n\nIf a Legal Entity does not renew its LElI Record (see Use Case 4.8), with reaching the\n\nNextRenewalDate, the LEl issuer:\n\no SHALL check with the registration and/or Validation Authority for the given Legal Entity (if\navailable), whether the entity is still active. If the Legal Entity stopped operations, then the rules\nfor retiring an LEIl apply here, or if applicable, the details of a corresponding Legal Entity Event.\n\nThe fact that an International Branch’s LEI Record is LAPSED SHALL NOT allow for the issuance of a\n\nsecond LEI Record for a Branch in the same host jurisdiction.\n\n4.12 Lack of renewal — Related Legal Entity including head offices,\n\nfund managers, umbrella and master funds\n\nIf the LEl Record of a related Legal Entity (the EndNode of an active relationship) is not renewed, all\n\nactive accounting consolidating, Fund Management Entities, Umbrella Structures and Master-Feeder\n\nRelationship Records having this entity’s LEl as EndNodelD SHALL NOT be updated, if the lack of\n\nrenewal of the parent Legal Entity is the only change.\n\nIf the parent Legal Entity is the head office of a Branch entity, the LEl issuer of the Branch SHALL set\n\nthe Branch’s LEI Record, including the Relationship Records, to LAPSED (see section 4.6). This SHALL\n\nbe ensured by the Branch LEI Record having the same NextRenewalDate as the head office LElI\n\nRecord, whether or not both records are managed by the same or by different LEIl issuers and\n\nregardless of any renewal request submitted by the Branch entity but not by the head office.\n\n4.13 Update of LEI Reference Data due to Legal Entity Events\n\nThe Reference Data of an LEI Record may change due to Legal Entity Events. The LEl issuer is\n\nresponsible to verify changed Reference Data. If the LEl issuer is ultimately unable to verify the\n\nchanged Reference Data, the Validation Sources SHALL change to PARTIALLY CORROBORATED or\n\nENTITY_SUPPLIED_ONLY.\n\nWhenever an element of the Reference Data is updated, the respective LastUpdateDate (LEI Record\n\nor Relationship Records) SHALL be updated with the current date and time as well.\n\nIf LEI Reference Data is updated to just correct an error or add missing data to an element associated\n\nwith Legal Entity Events (e.g., LegalName, LegalAddress, EntityLegalForm), but the Legal Entity itself\n\ndid not change, no Legal Entity Event SHALL be recorded together with the reference data update.\n\nState Transition and Validation Rules for Common Data File formats Page 107 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2774,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.675Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Legal Entity Events can occur as\n\n¢ Single Standalone events (e.g., an address change)\n\n¢ Sequence of Standalone events (e.g., a change in legal name after a merger or demerger)\n\n¢ Standalone Events that occur simultaneously (e.g., a change in legal name in the course of an\nabsorption)\n\ne Grouped events that happen at the same time (e.g., a change in legal form that also changes the\nlegal name)\n\ne Grouped events in a logical succession (e.g., reverse take-over).\n\n4.13.1 Legal Entity Event — Event timeline and status\n\nSome events MAY be able to be confirmed officially before the event becomes legally effective. For\n\nother events, becoming legally effective will be the only binding confirmation for the event. There\n\nMAY be cases where a Legal Entity Event has been confirmed officially but later will be withdrawn or\n\ncancelled before becoming legally effective.\n\nTo capture different timelines and statuses, each Legal Entity Event has an attribute defining the\n\nstatus of the event (see section 3.29):\n\no @event_status SHALL be IN_PROGRESS, if the Legal Entity Event is confirmed by an official\nsource (which could be the Legal Entity itself) but has not become legally effective yet. Not all\nevents MAY be able to be confirmed and recorded in the Global LEI System before the\nLegalEntityEventEffectiveDate.\n\no LegalEntityEventEffectiveDate SHALL be a future date (if the effective date is known) or\nSHALL be omitted (if the date is unknown).\n\no All provided AffectedFields SHALL include the values of the LEI Reference Data as expected to\nchange as a result of a completed Legal Entity Event.\n\n¢ The values provided in the attribute @field_xpath of the AffectedFields element SHALL be as\nlisted in section 3.36.\n\no @event_status SHALL be COMPLETED, if the Legal Entity Event is confirmed and legally effective.\no LegalEntityEventEffectiveDate SHALL be present and earlier or equal to\n\nLegalEntityEventRecordedDate.\n\n@event_status SHALL be WITHDRAWN_CANCELLED, if an event has been reported with\n\n@event_status IN_PROGRESS but has been determined to not be completed due to withdrawal or\n\ncancellation. This status SHALL be used only when it is confirmed that the event will not happen —a\n\ndelay past an expected effective date SHALL NOT result in a cancellation. Figure 9 gives further\n\ndetails on the application of event timelines.\nState Transition and Validation Rules for Common Data File formats Page 108 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2529,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.675Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"@event_status WITHDRAWN_CANCELLED SHALL also be used to cancel events that have been\npublished in the LEI Record by mistake. In this case the event with @event_status\nWITHDRAWN_CANCELLED SHALL have the exact same reference data as the erroneously introduced\nevent with @event_status COMPLETED with the exception of the LegalEntityEventRecordedDate.\nLegalEntityEvent:\no @entity_status:\nWITHDRAWN_CANCELLED\no LegalEntityEventRecordedDate:\ne 2020-06-01T00:00:00+02:00\n@event_status: IN_PROGRESS\n@event_status: WITHDRAWN_CANCELLED\nLegalEntityEvent:\no @entity_status: IN_PROGRESS\nLegalEntityEventEffectiveDate:\n: & y @event_status: COMPLETED\no 2020-11-20T00:00:00+02:00\no LegalEntityEventRecordedDate: LegalEntityEvent:\no 2020-04-20T00:00:00+02:00\no @entity_status: COMPLETED\n¢ LegalEntityEventEffectiveDate: 2020-11-\nAffectedFields: 20T00:00:00+02:00\no Expected attribute values that will o LegalEntityEventRecordedDate: 2020-\nbe effective on November 20, 2020. 12-05T00:00:00+02:00\nFigure 9: Application of event timeline and event status\n4.13.2 Legal Entity Event — Legal Name changes\nThis Use Case only applies where the legal name changes and the Legal Entity remains an operating\nentity. This event applies to all entity categories. For cases where the LegalName changed due to a\nchange of LegalForm, see Use Case 4.13.5.\nThe LEl issuer:\ne SHALL update LegalName accordingly, as recorded by an official Registration Authority.\no SHALL create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be omitted.\nState Transition and Validation Rules for Common Data File formats Page 109 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1797,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.675Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be CHANGE_LEGAL NAME.\no LegalEntityEventEffectiveDate SHALL be the date the change in LegalName becomes effective\nin the Legal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no If @event_statusis IN_PROGRESS, the LEl issuer SHALL provide information regarding the\nAffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide lei:LegalName\ne SHALL provide lei:OtherEntityNames\no MAY provide lei:TransliteratedOtherEntityNames\no MAY provide lei:SuccessorEntity\ne SHALL include a new OtherEntityName with OtherEntityNameType PREVIOUS_LEGAL_NAME.\no SHALL update OtherEntityName with OtherEntityNameType\nALTERNATIVE_LANGUAGE_LEGAL_NAME, if necessary.\no SHALL update TransliteratedOtherEntityNames, if necessary.\nIf the change of the Legal Entity name is due to the formation of a new Legal Entity, then a new LEI\nSHALL be issued for the new Legal Entity (see sections 4.1 and 4.3) and the SuccessorEntity /\nSuccessorlLEl field of the old LEI Record SHALL be updated with the new LEI (see sections 4.13.22).\nState Transition and Validation Rules for Common Data File formats Page 110 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1355,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.675Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Reporting Exception An XML data record in REPEX-CDF format detailing the reported\nRecord (Repex) exception for not reporting a relationship type in a relationship\nrecord, as reported by a Legal Entity to its LOU, and by the LOU to\nGLEIF.\nSystem of National The System of National Accounts (SNA) is the internationally agreed\nAccounts (SNA) standard set of recommendations on how to compile measures of\neconomic activity. The SNA defines resident Government Entities as\nnon-market producers, part of the central, state or local\ngovernment, social security funds or non-profit institutions (NPI)\ncontrolled by government units.\n(https://unstats.un.org/unsd/nationalaccount/sna.asp)\nSubsidiary A Legal Entity controlled by a holding company.\nTransition Rule A rule stipulating what LOUs, GLEIF and Legal Entities must do when\nan LEI Record Set changes from one allowed state to another.\nUse Case A specific operation scenario which applies one or more Business\nRules.\nValidation Ensures complete, reasonable, sensible data within acceptable\nboundaries by checking the data that is being entered.\nVerification Entered data matches exactly the Validation source.\n1.2 Terminology and Typographical Conventions\nWithin this document, the terms, as will be SHALL and MAY, are to be interpreted as specified in\nAnnex G of the ISO/IEC Directives, Part 2, 2001, 4th edition:\nSHALL (NOT) Requirement\nMAY Permission / Possibility\nWhen used in this way, these terms will always be shown in ALL CAPS; when these words appear in\nordinary typeface, they are intended to have their ordinary English meaning. All sections of this\nState Transition and Validation Rules for Common Data File formats Page 12 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1793,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.675Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"O LegalName changes O\n—>\nLEI A LEI A\nPre Event Post Event\nLEI A LEIA\nEntity: Entity:\no LegalName: ,Former LegalName“ o LegalName: ,New LegalName“\no OtherEntityName: “Former LegalName”\nRegistration: o OtherEntityNameType:\no lei:RegistrationStatus: ISSUED PREVIOUS_LEGAL_NAME\no LastUpdateDate: 2019-07-01T11:13:00+01:00\nRegistration:\no RegistrationStatus: ISSUED\no LastUpdateDate:\no 2020-04-16T17:43:00+02:00\nLegalEntityEvent:\no @group_type: STANDALONE\no @event_status: COMPLETED\no LegalEntityEventType: CHANGE_LEGAL_NAME\no LegalEntityEventEffectiveDate:\ne 2020-04-13T00:00:00.000Z\no LegalEntityEventRecordedDate:\ne 2020-04-16T00:00:00.000Z\no ValidationDocuments:\nSUPPORTING_DOCUMENTS\no ValidationReference:\nhttp://pub_registry.gov/new_entity_docs.pdf\nExample 1: The Legal Entity “Former LegalName” with an LEI A changed its name to “New LegalName” with effective\ndate April 13, 2020. The LEl issuer updated the record and published it in the Global LEI System on April 16, 2020. The\nchange of the name can be validated in the business registry where the Legal Entity is registered.\nState Transition and Validation Rules for Common Data File formats Page 111 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1269,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.675Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.13.3 Legal Entity Event — Business or trading name changes\nThis Use Case only applies where a business or trading name changes, the LegalName does not\nchange and the Legal Entity remains an operating entity. This event applies to all entity categories\nexcept for Government entities.\nThe LEl issuer:\no SHALL update OtherEntityName with OtherEntityNameType TRADING_OR_OPERATING_NAME\naccordingly.\no SHALL create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be CHANGE_OTHER_NAMES.\no LegalEntityEventEffectiveDate SHALL be the date the change in OtherEntityName becomes\neffective in the Legal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no If @event_statusis IN_PROGRESS, the LEl issuer SHALL provide information regarding the\nAffectedFields: For @field_xpath the LEl issuer usually\ne SHALL provide lei:OtherEntityNames\no MAY provide lei:TransliteratedOtherEntityNames\no MAY provide lei:SuccessorEntity\nIf the change of the Legal Entity’s business or trading name is due to the formation of a new Legal\nEntity, then a new LEI SHALL be issued for the new Legal Entity (see Use Cases 4.1 and 4.3) and the\nSuccessorEntity / SuccessorLEl field of the old LEI Record SHALL be updated with the new LEI (see\nUse Case 4.13.22).\nState Transition and Validation Rules for Common Data File formats Page 112 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1685,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.675Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"O Business or trading name changes O\nN — S\nLEI A LEI A\nPre Event Post Event\nLEI A LEI A\nEntity: Entity:\no LegalName: “Good company name” o LegalName: “Good company name”\no OtherEntityName: “GoodCo”\nRegistration: o OtherEntityNameType:\no lei:RegistrationStatus: LAPSED TRADING_OR_OPERATING_NAME\no LastUpdateDate: 2019-07-01T11:13:00+01:00\no NextRenewalDate: 2020-01- Registration:\n01T00:00:00+01:00 o lei:RegistrationStatus: ISSUED\no LastUpdateDate: 2020-01-23T10:42:00+02:00\no NextRenewalDate: 2021-01-\n01T00:00:00+01:00\nLegalEntityEvent:\no @group_type: STANDALONE\no @event_status: COMPLETED\no LegalEntityEventType:\nCHANGE_OTHER_NAMES\no LegalEntityEventEffectiveDate:\ne 2020-01-15T00:00:00.000Z\no LegalEntityEventRecordedDate:\ne 2020-01-23T00:00:00.000Z\no ValidationDocuments: CONTRACTS\no ValidationReference: Notarized documents\nExample 2: The Legal Entity ,,Good company name“ uses “GoodCo” as a new trading name as of January 15, 2020. The\nLegal Entity Event was recorded in the Global LEI System on January 23, 2020 in the course of renewal, after initially the\nLEI lapsed.\nState Transition and Validation Rules for Common Data File formats Page 113 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1266,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.675Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.13.4 Legal Entity Event — Address information changes\nThis Use Case only applies where the LegalAddress or HeadquartersAddress changes and the Legal\nEntity remains an operating entity. This event applies to all entity categories.\nThe LEl issuer:\no SHALL update LegalAddress and/or HeadquartersAddress accordingly.\no SHALL create a new LegalEntityEvent for each address changed with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be CHANGE_LEGAL_ADDRESS or CHANGE_HQ_ADDRESS,\nrespectively.\no LegalEntityEventEffectiveDate SHALL be the date the change in address becomes effective in\nthe Legal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no If @event_statusis IN_PROGRESS, the LEl issuer SHALL provide information regarding the\nAffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide lei:LegalAddress/* and/or lei:HeadquartersAddress/*\no MAY provide lei:OtherAddresses/*\n* MAY provide lei:TransliteratedOtherAddresses/*\no MAY provide lei:SuccessorEntity\ne Forall above mentioned address containers (LegalAddress, HeadquartersAddress,\nOtherAddresses and TransliteratedOtherAddresses) the concrete data elements SHALL be\nprovided.\no SHALL update OtherAddresses with type ALTERNATIVE_LANGUAGE_LEGAL_ADDRESS and/or\nALTERNATIVE_LANGUAGE_HEADQUARTERS_ADDRESS, if necessary.\no SHALL update TransliteratedOtherAddresses, if necessary.\no SHALL check, if also the Registration Information changed (see Use Case 4.15).\nIf the change of the legal address is due to the formation of a new Legal Entity, then a new LEI SHALL\nbe issued (see Use Cases 4.1 and 4.3) and the SuccessorEntity / SuccessorLEl field of the old LEI\nrecord SHALL be updated with the new LEI (see Use Case 4.13.22). Example 3 provides a specific use\ncase for changing address information.\nState Transition and Validation Rules for Common Data File formats Page 114 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2199,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.675Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"O Address information changes O\n———>\nLEI A LEI A\nIn-progress Event Post Event\nLEI A LEI A\nEntity: Entity:\no FirstAddressLine: “Streetname former legal o FirstAddressLine: “Streetname new legal\naddress 1” address 5”\no AddressNumber: 1 o AddressNumber: 5\nRegistration: Registration:\no RegistrationStatus: ISSUED o RegistrationStatus: ISSUED\no LastUpdateDate: 2019-07-01T11:13:00+01:00 o LastUpdateDate: 2020-01-23T710:42:00+02:00\nLegalEntityEvent: LegalEntityEvent:\no @group_type: STANDALONE o @group_type: STANDALONE\no @event_status: IN_PROGRESS o @event_status: IN_PROGRESS\no LegalEntityEventType: o LegalEntityEventType:\nCHANGE_LEGAL_ADDRESS CHANGE_LEGAL_ADDRESS\no LegalEntityEventEffectiveDate: o LegalEntityEventEffectiveDate:\ne 2020-01-15T00:00:00.000Z e 2020-01-15T00:00:00.000Z\no LegalEntityEventRecordedDate: o LegalEntityEventRecordedDate:\ne 2019-07-07T00:00:00+01:00 e 2019-07-07T00:00:00+01:00\no ValidationDocuments: ¢ ValidationDocuments:\nSUPPORTING_DOCUMENTS SUPPORTING_DOCUMENTS\no ValidationReference: o ValidationReference:\nhttp://pub_registry.gov/new_entity_docs.pdf http://pub_registry.gov/new_entity_docs.pdf\nAffectedFields: LegalEntityEvent:\no Entity/LegalAddress/FirstAddressLine: o @group_type: STANDALONE\no @event_status: COMPLETED\no LegalEntityEventType:\nCHANGE_LEGAL_ADDRESS\no LegalEntityEventEffectiveDate:\nExample 3: The Legal Entity makes available the information about a change in the legal address that will become\neffective on January 15, 2020. In the example only the street and address number change. The change of the legal\naddress was recorded in the Global LEI System on July 7, 2019 as in-progress event. The completion of the Legal Entity\nEvent was validated in the local registry and recorded in the Global LEI System on January 23, 2020.\nState Transition and Validation Rules for Common Data File formats Page 115 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1973,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.675Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.13.5 Legal Entity Event — Legal form changes\nA change of the legal form potentially has different degrees of impact on the Legal Entity. The\nfollowing three Use Cases describe the most common variants. They apply to all entity categories.\nFor cases where an ELF code is supplied for the first time, see section 2.8 instead.\nThe first Use Case (Example 4) applies when only the legal form changes and the Legal Entity remains\nan operating entity. An example could be that the legal forms used in the Legal Entity’s jurisdiction\nare transformed into other legal forms while preserving the legal status of the Legal Entities.\nIn this case, the LEl issuer:\ne SHALL update LegalForm accordingly, following the general rules for Entity Legal Form Reporting\n(see section 2.8).\no SHALL create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be CHANGE_LEGAL_FORM.\no LegalEntityEventEffectiveDate SHALL be the date the change in the legal form becomes\neffective in the Legal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no If @event_statusis IN_PROGRESS, the LEl issuer SHALL provide information regarding the\nAffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide lei:EntityLegalFormCode and lei:OtherLegalForm, if necessary\no MAY provide lei:Legallurisdiction\no MAY provide lei:SuccessorEntity\no SHALL check, if also Registration Information has changed (see Use Case 4.15).\nState Transition and Validation Rules for Common Data File formats Page 116 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1848,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.675Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"O LegalForm changes O\n———’\nLEI A LEI A\nIn-progress Event Post Event\nLEI A LEI A\n\nEntity: Entity:\n\no EntityLegalFormCode: 059 o EntitylegalFormCode: Y1Q4\n\nRegistration: Registration\n\no RegistrationStatus: ISSUED o RegistrationStatus: ISSUED\n\no LlastUpdateDate: 2019-07-01711:13:00+01:00 o LastUpdateDate: 2020-01-23T710:42:00+02:00\n\nLegalEntityEvent: LegalEntityEvent:\n\no @group_type: STANDALONE o @group_type: STANDALONE\n\no @event_status: IN_PROGRESS o @event_status: IN_PROGRESS\n\no LegalEntityEventType: o LegalEntityEventType:\n\nCHANGE_LEGAL_FORM CHANGE_LEGAL_FORM\n\no LegalEntityEventEffectiveDate: o LegalEntityEventEffectiveDate:\n\ne 2020-01-15T00:00:00.000Z e 2020-01-15T00:00:00.000Z\n\no LegalEntityEventRecordedDate: o LegalEntityEventRecordedDate:\n\ne 2019-07-01T00:00:00+01:00 e 2019-07-01T00:00:00+01:00\n\no ValidationDocuments: ¢ ValidationDocuments:\nSUPPORTING_DOCUMENTS SUPPORTING_DOCUMENTS\n\no ValidationReference: o ValidationReference:\nhttp://registry.gov/evidence.pdf http://registry.gov/evidence.pdf\n\nAffectedFields: AffectedFields:\n\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:E o /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:E\nntity/lei:LegalForm/lei:EntityLegalFormCode: ntity/lei:LegalForm/lei:EntityLegalFormCode:\nY1Q4 Y1Q4\n\nLegalEntityEvent:\no @group_type: STANDALONE\no @event_status: COMPLETED\no LegalEntityEventType:\nCHANGE_LEGAL_FORM\no LegalEntityEventEffectiveDate:\ne 2020-01-15T00:00:00.000Z\no LegalEntityEventRecordedDate:\ne 2020-01-23T00:00:00.000Z\n¢ ValidationDocuments:\nSUPPORTING_DOCUMENTS\no ValidationReference:\nhttp://registry.gov/evidence.pdf\nExample 4: The Legal Entity changes its legal form from ELF O59C to ELF Y1Q4 with effective date January 15, 2020. The\nLEl issuer has published this change on July 1, 2019 prior to the effective date. The completion of the Legal Entity Event\nwas recorded in the Global LEI System on January 23, 2020.\nState Transition and Validation Rules for Common Data File formats Page 117 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2074,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.675Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"The second Use Case (Example 5) applies when also the legal name changes due to the legal form\nchange and the Legal Entity remains an operating entity.\nIn this case, the LEl issuer:\no SHALL update LegalForm accordingly, following the general rules for Entity Legal Form Reporting\n(see section 2.8).\no SHALL create a new LegalEntityEvent for the legal form change with:\no @group_type SHALL be CHANGE_LEGAL_FORM_AND_NAME.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be a unique identifier (e.g., a hash value calculated from the combination\nof the LEl, EventType and EffectiveDate).\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be CHANGE_LEGAL_FORM.\no LegalEntityEventEffectiveDate SHALL be the date the change in the legal form becomes\neffective in the Legal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no If @event_status is IN_PROGRESS, the LEl issuer SHALL provide information regarding the\nAffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide lei:EntityLegalFormCode and lei:OtherLegalForm, if necessary\no MAY provide lei:Legallurisdiction\no MAY provide lei:SuccessorEntity\no SHALL create a new LegalEntityEvent for the legal name change with (see Use Case 4.13.2):\no @group_type SHALL be CHANGE_LEGAL FORM_AND_NAME.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be the same unique identifier used for the previous event.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be CHANGE_LEGAL NAME.\no LegalEntityEventEffectiveDate SHALL be the date the change in the legal form becomes\neffective in the Legal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\nState Transition and Validation Rules for Common Data File formats Page 118 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2070,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.675Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o If @event_statusis IN_PROGRESS, the LEl issuer SHALL provide information regarding the\n\nAffectedFields: For @field_xpath the LEl issuer usually\n\no SHALL provide lei:LegalName\n\ne SHALL provide lei:OtherEntityNames\n\no MAY provide lei:TransliteratedOtherEntityNames\n\no MAY provide lei:SuccessorEntity\n\no SHALL check, if also Registration Information has changed (see section 4.15).\nState Transition and Validation Rules for Common Data File formats Page 119 of 170\n@ Public Version 2.7.1 Final\n\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":566,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.675Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"LegalForm and LegalName change\n-\nPre Event Post Event\nLEI A LEI A\nEntity: Entity:\no EntityLegalFormCode: FGVH o EntityLegalFormCode: O85W\no LegalName: “Company Name Inc” o LegalName: “Company Name LLC”\nRegistration: Registration:\no lei:RegistrationStatus: ISSUED o lei:RegistrationStatus: ISSUED\no lastUpdateDate: 2019-07-01711:13:00+01:00 o LastUpdateDate: 2020-01-23T10:42:00+02:00\nLegalEntityEvent:\no @group_type:\nCHANGE_LEGAL_FORM_AND_NAME\no @group_id: dfecd444f23463443a98n12a\no @event_status: COMPLETED\no LegalEntityEventType:\nCHANGE_LEGAL_FORM\no LegalEntityEventEffectiveDate:\ne 2020-01-15T00:00:00.000Z\no LegalEntityEventRecordedDate:\ne 2020-01-23T00:00:00.000Z\no ValidationDocuments:\nSUPPORTING_DOCUMENTS\ne ValidationReference:\nhttp://pub_registry.gov/new_entity_docs.pdf\nLegalEntityEvent:\no @group_type:\nCHANGE_LEGAL_FORM_AND_NAME\no @group_id: dfecd444f23463443a98n12a\no @event_status: COMPLETED\no LegalEntityEventType:\nCHANGE_LEGAL_NAME\no ValidationDocuments:\nSUPPORTING_DOCUMENTS\no LegalEntityEventEffectiveDate:\ne 2020-01-15T00:00:00.000Z\no LegalEntityEventRecordedDate:\ne 2020-01-23T00:00:00.000Z\no ValidationDocuments:\nSUPPORTING_DOCUMENTS\ne ValidationReference:\nhttp://pub_registry.gov/new_entity_docs.pdf\nExample 5: The Legal Entity changes its legal form from ELF FGVH to ELF O85W with effective date January 15, 2020 and\nadditionally changes its legal name. The completion of the Legal Entity Event was recorded in the Global LEI System on\nJanuary 23, 2020.\nState Transition and Validation Rules for Common Data File formats Page 120 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1667,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.675Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"document, with the exception of the Introduction, are normative, except where explicitly noted as\nnon-normative. The following typographical conventions are used throughout the document:\no ALL CAPS type is used for the special terms enumerated above and when in the text is referred to\na data field value from an enumerated list.\no CamelCase type is used to refer to the data elements as declared in the CDF XML Schema\nDefinition (xsd).\nState Transition and Validation Rules for Common Data File formats Page 13 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":620,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.675Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"The third Use Case (Example 6) applies when the legal form change creates a new Legal Entity while\nthe previous Legal Entity ceases to exist.\n\nIn this case, the LEl issuer:\n\no SHALL retire the LEI Record Set of the previous Legal Entity:\n\no Set RegistrationStatus to RETIRED.\n\no Set RegistrationStatus of all current Relationship Records to RETIRED with RelationshipStatus\nINACTIVE; set EndDate of RelationshipPeriod with PeriodType RELATIONSHIP_PERIOD as\nLegalEntityEventEffectiveDate of the event (see below).\n\no Setthe new Legal Entity (see below) as SuccessorEntity.\n\ne Create a new LegalEntityEvent for the LEI Record Set of the previous Legal Entity with:\n\no @group_type SHALL be COMPLEX_CHANGE_LEGAL_FORM.\n\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\n\no @group_id SHALL be omitted.\n\no @group_sequence_no SHALL be omitted.\n\no LegalEntityEventType SHALL be CHANGE_LEGAL_FORM.\n\no LegalEntityEventEffectiveDate SHALL be date the change in the legal form becomes effective\nin the Legal Jurisdiction of the Legal Entity.\n\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\n\no If @event_statusis IN_PROGRESS, the LEl issuer SHALL provide information regarding the\nAffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide lei:EntityLegalFormCode and lei:OtherLegalForm, if necessary\no MAY provide lei:Legallurisdiction\no MAY provide lei:LegalName\no MAY provide lei:OtherEntityNames\no MAY provide lei:TransliteratedOtherEntityNames\no MAY provide lei:SuccessorEntity\n\no If @event_status is COMPLETED and there is at least one SuccessorEntity entry added to the LEI\n\nRecord Set, the LEl issuer SHALL provide information regarding the AffectedFields: For\n\n@field_xpath the LEl issuer usually\n\no SHALL provide lei:SuccessorEntity\n\no Issue a new LEI Record (see Use Cases 4.1 and 4.3), including all appropriate relationships.\nState Transition and Validation Rules for Common Data File formats Page 121 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2099,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.675Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o For the newly issued LEI Record, create a new LegalEntityEvent with:\no @group_type SHALL be COMPLEX_CHANGE_LEGAL_FORM.\no @event_status SHALL be COMPLETED.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be CHANGE_LEGAL_FORM.\no LegalEntityEventEffectiveDate SHALL be the date when the change in the legal form becomes\neffective in the Legal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no AffectedFields SHALL be omitted.\nState Transition and Validation Rules for Common Data File formats Page 122 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":749,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.675Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"LegalForm changes and LEI A retires\n_————’\nPost Event Post Event\nLEIA LEI B (Create new LEI Record Set)\nEntity: Entity:\no EntityLegalFormCode: FGVH o EntityLegalFormCode: O85W\no LegalName: Company inc o LegalName: Company LLC\no SuccessorlLEl: B o EntityCreationDate:\ne 2020-01-15T00:00:00.000Z\nRegistration:\no lei:RegistrationStatus: RETIRED Registration:\no lei:LastUpdateDate: o lei:RegistrationStatus: ISSUED\no 2020-01-23T10:42:00+02:00 o lei:LastUpdateDate:\no 2020-01-23T10:42:00+02:00\nRelationship:\no rr:RegistrationStatus: RETIRED LegalEntityEvent:\no rr:RelationshipStatus: INACTIVE o @group_type:\no rr:LastUpdateDate: COMPLEX_CHANGE_LEGAL_FORM\no 2020-01-23T10:42:00+02:00 e @event_status: COMPLETED\no LegalEntityEventType:\nLegalEntityEvent: CHANGE_LEGAL_FORM\n° (@group_type: o LegalEntityEventEffectiveDate:\nCOMPLEX_CHANGE_LEGAL_FORM e 2020-01-15T00:00:00.000Z\no @event_status: COMPLETED o LegalEntityEventRecordedDate:\no LegalEntityEventType: e 2020-01-23T00:00:00.000Z\nCHANGE_LEGAL_FORM ¢ ValidationDocuments:\no LegalEntityEventEffectiveDate: SUPPORTING_DOCUMENTS\ne 2020-01-15T00:00:00.000Z o ValidationReference:\no LegalEntityEventRecordedDate: http://pub_registry.gov/new_entity_docs.pdf\no 2020-01-23T00:00:00+01:00\no ValidationDocuments:\nSUPPORTING_DOCUMENTS\no ValidationReference:\nhttp://pub_registry.gov/new_entity docs.pdf\nAffectedFields:\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:E\nntity/lei:SuccessorEntity/lei:SuccessorLEl:\nLEI B\nExample 6: Legal Entity LEI A changes its legal form from ELF O59C to ELF NSNT with effective date January 15, 2020. As a\nconsequence, LEI A retires, and an LEI Record Set for LEI B is created. The completion of the Legal Entity Event was\nrecorded in the Global LEI System on January 23, 2020.\nState Transition and Validation Rules for Common Data File formats Page 123 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1938,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.675Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"A legal form change could result in one of the three above described scenarios. The LEl issuer SHALL\nassess and evaluate the documents at hand and decide which of the three scenarios apply in the\nparticular case.\n4.13.6 Legal Entity Event — Acquisition\nLegal Entity A (general Legal Entity or Fund, but not Branch, Government Entity or International\nOrganization), either independent/stand-alone or Subsidiary/sub-fund/compartment, is acquired by\nanother Legal Entity B but remains a separate/segregated Legal Entity.\nThe LEl issuer managing the record of entity A SHALL:\no Retire any current Relationship Records and/or stop publishing Reporting Exception Records for\nA.\no Create new relationships/exceptions with parent Legal Entity B (including Fund relationships, if\napplicable).\no Create a new LegalEntityEvent (single, combined or group, as applicable) with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be MERGERS_AND_ACQUISITIONS.\no LegalEntityEventEffectiveDate SHALL be the date the acquisition becomes effective in the\nLegal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no If @event_statusis IN_PROGRESS, the LEl issuer SHALL provide information regarding the\nAffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide rr:EndNode/rr:NodelD\no SHALL provide rr:EndNode/rr:NodeType\no SHALL provide rr:RelationshipType\n* MAY provide repex:ExceptionCategory\no MAY provide repex:ExceptionReason\nState Transition and Validation Rules for Common Data File formats Page 124 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1849,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.675Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"O Acquired by O\n- >\nLEIA LEIB\nPost Event\nLEI A\nRelationship:\no rr:RegistrationStatus: RETIRED\no rr:LastUpdateDate: 2020-04-16T17:43:00.000Z\no Create new RelationshipRecords, if applicable\no Stop publishing ReportingExceptions, if applicable\nLegalEntityEvent:\no @group_type: STANDALONE\no @event_status: COMPLETED\no LegalEntityEventType: MERGERS_AND_ACQUISITIONS\no LegalEntityEventEffectiveDate: 2020-03-02T00:00:00.000Z\no LegalEntityEventRecordedDate: 2020-04-16T00:00:00.000Z\no ValidationDocuments: SUPPORTING_DOCUMENTS\no ValidationReference: http://registry.gov/evidence.pdf\nExample 7: The Legal Entity with LEI A is acquired by Legal Entity with LEI B with effective date on March 2, 2020 and\nrecorded in the Global LEI System on April 16, 2020.\n4.13.7 Legal Entity Event — Absorption\nLegal Entity A (general Legal Entity or Fund, but not Branch, Government Entity or International\nOrganization), either independent/stand-alone or Subsidiary/sub-fund/compartment, is acquired by\nanother Legal Entity B (may or may not be in a parent relationship with A). All assets/shares of Legal\nEntity A are absorbed by Legal Entity B and A ceases to exist as an active Legal Entity.\nNote: The addition of Absorption to the list of Legal Entity Events covered by the policy is under\nreview with the LEI-ROC.\nThe LEl issuer managing the record of Legal Entity A SHALL:\no Retire LEI Record Set of absorbed Legal Entity A:\no Set RegistrationStatus RETIRED.\ne Set current relationships to RETIRED, if applicable.\no Set Legal Entity B as SuccessorEntity.\nState Transition and Validation Rules for Common Data File formats Page 125 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1726,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.675Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be ABSORPTION.\no LegalEntityEventEffectiveDate SHALL be the date the Absorption becomes effective in the\nLegal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no If @event_status is IN_PROGRESS or COMPLETED, the LEl issuer SHALL provide information\nregarding the AffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide lei:SuccessorEntity\nThe LEl issuer managing the record of entity B SHALL:\no Record the absorption of Legal Entity A by creating a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be ABSORPTION.\no LegalEntityEventEffectiveDate SHALL be the date the Absorption becomes effective in the\nLegal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\n© AffectedFields SHALL be omitted.\nNote: LEI Records for A and B MAY be managed by different LEl issuers. Nevertheless, there SHALL be\nconsistency for the LegalEntityEventEffectiveDate and ValidationReference of the event; Recorded\nDate MAY be different.\nState Transition and Validation Rules for Common Data File formats Page 126 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1645,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.676Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"O Absorbed by O\nR\nLEI A LEIB\nPost Event Post Event\nLEI A LEI B\nEntity: LegalEntityEvent:\no SuccessorEntity: LEI B o @group_type: STANDALONE\no @event_status: COMPLETED\nRegistration: o LegalEntityEventType: ABSORPTION\no RegistrationStatus: RETIRED o LegalEntityEventEffectiveDate:\no LastUpdateDate: 2020-01-23T10:42:00+02:00 e 2020-01-20T00:00:00.000Z\no LegalEntityEventRecordedDate:\nRelationship: e 2020-01-23T00:00:00.000Z\no Stop publishing ReportingExceptions » ValidationDocuments:\nSUPPORTING_DOCUMENTS\nRelationship Registraion: « ValidationReference:\no RegistrationStatus: RETIRED http://registry.gov/evidence.pdf\no LastUpdateDate: 2020-01-23T10:42:00+02:00\nLegalEntityEvent:\no @group_type: STANDALONE\no @event_status: COMPLETED\no LegalEntityEventType: ABSORPTION\no LegalEntityEventEffectiveDate:\ne 2020-01-20T00:00:00.000Z\no LegalEntityEventRecordedDate:\ne 2020-01-23T00:00:00.000Z\no ValidationDocuments:\nSUPPORTING_DOCUMENTS\no ValidationReference:\nhttp://registry.gov/evidence.pdf\nAffectedFields:\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:E\nntity/lei:SuccessorEntity/lei:SuccessorLEl:\nLEI B\nExample 8: The Legal Entity with LEI A is absorbed by a Legal Entity with an LEI B with effective date January 20, 2020 and\nboth records have been updated on the same date January 23, 2020.\nState Transition and Validation Rules for Common Data File formats Page 127 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1480,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.676Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.13.8 Legal Entity Event — Merger\nA common example how a Merger is processed and its outcome:\nLegal Entity A (not a Branch) and Legal Entity B (not a Branch either and usually of a similar category\nas A) combine their shares/assets and together form a new Legal Entity C (general Legal Entity or\nFund, but not Branch). A and B cease to exist as Legal Entities after the Merger.\nThe LEl issuer(s) managing the LEI Record Sets of entities A and B SHALL:\no Retire records of entity A and entity B once @event_status is COMPLETED:\no Set RegistrationStatus RETIRED.\no Set EntityStatus INACTIVE.\ne Set current relationships to RETIRED, if applicable.\no Set Legal Entity C as SuccessorEntity.\no Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be MERGERS_AND_ACQUISITIONS.\no LegalEntityEventEffectiveDate SHALL be the date the Merger becomes effective in the Legal\nJurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no If @event_status is IN_PROGRESS or COMPLETED, the LEl issuer SHALL provide information\nregarding the AffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide lei:SuccessorEntity\nThe LEl issuer creating the new LEI Record for Legal Entity C SHALL:\n¢ Issue a new LEI Record (see Use Case Issue new LEI), including all appropriate relationships.\no Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be omitted.\nG State Transition and Validation Rules for Common Data File formats Page 128 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1912,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.676Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be MERGERS_AND_ACQUISITIONS.\no LegalEntityEventEffectiveDate SHALL be the date the Merger becomes effective in the Legal\nJurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no AffectedFields SHALL be omitted.\nLEIB\nMerge O\nLEIC\nLEI A\nPre Event Post Event\nState Transition and Validation Rules for Common Data File formats Page 129 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":590,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.676Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Pre & Post Event Post Event\nLEI A; LEIB LEI C (Create new LEI Record Set)\nEntity: Entity:\no EntityStatus: INACTIVE (Post Event) o LegalName: “New Firm LLC”\no SuccessorEntity: LEI C (Post Event) o EntityStatus: ACTIVE\no CreationDate:\nRegistration LE| A: 2020-04-19T00:00:00+02:00\no RegistrationStatus: RETIRED (Post Event)\no LastUpdateDate (Post Event): Registration:\no LEI A: 2020-04-20T13:43:25+02:00 o RegistrationStatus: ISSUED\no LEIB: 2020-05-20T13:43:25+02:00 ¢ InitialRegistrationDate:\n2020-04-20T00:00:00+02:00\nRelationship (Post Event):\n« Stop publishing ReportingExceptions LegalEntityEvent:\no @group_type: STANDALONE\nRelationship Registration (Post Event): o @event_status: COMPLETED\no RegistrationStatus: RETIRED o LegalEntityEventType:\nMERGERS_AND_ACQUISITIONS\nLegalEntityEvent (Pre & Post Event): o LegalEntityEventEffectiveDate:\no @group_type: STANDALONE o 2020-04-19T00:00:00+02:00\no @entity_status: IN_PROGRESS o LegalEntityEventRecordedDate:\no LegalEntityEventType: MERGERS_AND_ACQUISITIONS o 2020-04-20T00:00:00+02:00\no LegalEntityEventEffectiveDate: o ValidationDocuments: CONTRACTS\ne 2020-04-19T00:00:00+02:00 o ValidationReference: Notarized documents\no LegalEntityEventRecordedDate:\no LEI A: 2020-03-11T00:00:00+02:00\ne LEIB: 2020-03-13T00:00:00+02:00\no ValidationDocuments: SUPPORTING_DOCUMENTS\no ValidationReference: http://registry.gov/evidence.pdf .\nExample 9: LEI A and LEI B merge into LEI C (new Legal\n. Entity). LEI A and LEI B cease to exist on April 19, 2020.\nAffectedFields: The LEl issuer of LEI A was made aware of the\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei: incoming merger on 11 March 2020, while the LEI\nSuccessorEntity/lei:SuccessorLEl: LEI C issuer of LEI B was made aware of the incoming\nmerger on 13 March 2020. Both LOUs were given the\nLegalEntityEvent (Post Event): information that the legal name of LEI C will be “New\n« @group_type: STANDALONE Firn:l LLC” and that the merger will be complete.d on 19\n« @entity_status: COMPLETED April 2020. The recorded dates.of the Legal Entity\n- Events MAY vary between the involved records, as\no LegalEntityEventType: MERGERS_AND_ACQUISITIONS these may be managed by different LEI issuers.\no LegalEntityEventEffectiveDate:\no 2020-04-19T00:00:00+02:00\no LegalEntityEventRecordedDate:\ne LEI A: 2020-04-20T00:00:00+02:00\ne LEI B: 2020-05-20T00:00:00+02:00\no ValidationDocuments: SUPPORTING_DOCUMENTS\no ValidationReference: http://registry.gov/evidence.pdf\nAffectedFields:\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:\nSuccessorEntity/lei:SuccessorLEl: LEI C\nState Transition and Validation Rules for Common Data File formats Page 130 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2768,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.676Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"2 Lifecycle and General Concepts\n\n2.1 LEI Record Set Reference Data\n\nThe LEI Record Set consists of a set of one LEI record and its corresponding Relationship Records (RR),\n\nand Reporting Exception Records (Repex) that give the full Level 1 and Level 2 Reference Data for\n\nthat LEL.\n\nLEI records, Relationship Records and Reporting Exception Records each consist of a pre-defined set\n\nof mandatory and optional data elements. The following types of elements are used within the LEI\n\nRecord Set:\n\no Fixed list of allowed values (enumerations): only values defined in the respective xsd file are\nallowed. Example element: RegistrationStatus.\n\no Codes from a code list: only values from the current version of the referenced code list are\nallowed. Example element: LegalFormCode.\n\no Fixed format: only values with a specific format pattern are allowed. Example element: LEI.\n\no Free text: any content allowed. The xsd MAY have some restrictions defined (length, character\nset, no leading/trailing spaces). The content of a free text element SHALL NOT be “N/A” or similar\nplaceholder. Example element: LegalName.\n\n2.1.1 Legal Entity data (Level 1 data — ‘Who is who’)\n\nThe Legal Entity Identifier (LEl) connects to key Reference Data that provides the information on a\n\nLegal Entity identifiable with an LEI. The ISO 17442 standard developed by the International\n\nOrganization for Standardization defines a set of attributes that comprises the most essential\n\nelements of identification. The standard specifies the minimum Reference Data, which must be\n\nsupplied for each LEIl and further requirements for the LEI code and provided Reference Data. For the\ncomplete scope and content of the standard, please refer to the International Organization for\n\nStandardization®.\n\nWith the inclusion of Legal Entity Events and the related update of the Common Data File format to\n\nversion 3.1, the Legal Entity data will be enriched with Legal Entity Event information that impacts\n\nthe Legal Entity and changes their reference data.\n\n2.1.2 Legal Entity relationship information (Level 2 data — ‘Who owns whom’)\n\nLegal Entity relationship information describe the relationship between two Legal Entities. All\n\nrelationships have a specific type describing the kind of the relationship and two end points defining\n\nL https://www.iso.org/standard/75998.html\n\nState Transition and Validation Rules for Common Data File formats Page 14 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2526,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.676Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.13.9 Legal Entity Event — Transformation of a Subsidiary to an International Branch\nLegal Entity A (a general Legal Entity) in country X, a Subsidiary of parent Legal Entity B in country Y,\nis absorbed by Legal Entity B and turned into an International Branch. All shares/assets and liabilities\nof Legal Entity A are absorbed by Legal Entity B. This Legal Entity Event can only be recorded if Legal\nEntity A fulfills all the requirements for International Branches within the Global LEI System (see\nsection 4.2); otherwise, a different Legal Entity Event could apply. In case Legal Entity A is in the\nhome jurisdiction of Legal Entity B and it has been transformed to a Branch entity, the LEI of Legal\nEntity A SHALL be set to RETIRED since an International Branch LEI cannot be assigned in the home\njurisdiction. In that scenario the Legal Entity Event of type ABSORPTION MAY apply.\nFor the transformation of a subsidiary to an international branch, the LEl issuer managing the LEI\nRecord Set of Legal Entity A SHALL:\ne Update LEI Record Set of Legal Entity A to Branch:\no Set current relationships with Legal Entity B to RETIRED.\no Create a new relationship with Legal Entity B with RelationshipType\nIS_INTERNATIONAL BRANCH_OF; StartDate of the RelationshipPeriod with PeriodType\nRELATIONSHIP_PERIOD SHALL be the LegalEntityEventEffectiveDate of the Legal Entity Event\n(see below).\no Set EntityCategory to BRANCH.\ne Set the LegalForm and the ELF code to the LegalForm and the ELF code of the (head office)\nLegal Entity B.\no Set the Legal Jurisdiction to the Legal Jurisdiction of the (head office) Legal Entity B.\no Setthe RegistrationStatus (lei and rr) to either ISSUED or LAPSED, depending on the\nRegistrationStatus of the (head office) Legal Entity B.\no Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be TRANSFORMATION_SUBSIDIARY_TO_BRANCH\no LegalEntityEventEffectiveDate SHALL be the date the transformation becomes effective\nin the Legal Jurisdiction of the Legal Entity\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the\nGlobal LEI System.\nState Transition and Validation Rules for Common Data File formats Page 131 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2465,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.676Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o If @event_status is IN_PROGRESS, the LEl issuer SHALL provide information regarding\nthe AffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide rr:EndNode/rr:NodelD\no SHALL provide rr:EndNode/rr:NodeType\no SHALL provide rr:RelationshipType\no SHALL provide lei:EntityCategory\ne SHALL provide lei:SuccessorEntity, if applicable\no If @event_status is COMPLETED, the LEl issuer SHALL provide information regarding the\nAffectedFields: For @field_xpath the LEl issuer usually\ne SHALL provide lei:SuccessorEntity, if applicable\nState Transition and Validation Rules for Common Data File formats Page 132 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":723,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.679Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Switzerland O Transformed into O Belgium\nLET A International branch of LEI B\nPost Event Post Event\nLEI B\nLEI A\nEntity:\nEntity: o EntityLegalformCode: N5NT\ne EntityCategory: BRANCH o Legallurisdiction: BE\no EntityLegalformCode: N5NT\no Legallurisdiction: BE Registration:\no RegistrationStatus: ISSUED\nRegistration:\no RegistrationStatus: ISSUED Relationship Registration:\no RegistrationStatus: PUBLISHED\nRelationship: © LastUpdateDate:\no RegistrationStatus of previous relationships with LEI s 2020-04-20T13:43:25+02:00\nB: RETIRED\no Create new RelationshipRecord with LEI B with\nRelationship/RelationshipType\nIS INTERNATIONAL BRANCH OF Example 10: The Legal Entity with LEI A,\n* RelationshipPeriodStartDate: r:::\\csi;cnlrisez ?rl:tb:adr:ai:\\‘{c::nl-aili:;\\:l branch\n° 2020-04-18T00:00:00+02:00 of Legal Entity B with effective date April\n18, 2020. Both records have been\nRelationship Registration: updated on the same date April 20, 2020.\no RegistrationStatus: PUBLISHED\no LastUpdateDate: 2020-04-20T13:43:25+02:00\nLegalEntityEvent:\no @group_type: STANDALONE\no @entity_status: COMPLETED\no LegalEntityEventType:\nTRANSFORMATION_SUBSIDIARY_TO_BRANCH\no LegalEntityEventEffectiveDate:\no 2020-04-18T00:00:00+02:00\no LegalEntityEventRecordedDate:\no 2020-04-20T00:00:00+02:00\no ValidationDocuments: CONTRACTS\no ValidationReference: Notarized documents\nIf applicable, LegalEntityEvent:\no @group_type: STANDALONE\no @entity_status: COMPLETED\no LegalEntityEventType: CHANGE_LEGAL_FORM\no LegalEntityEventEffectiveDate:\no 2020-04-18T00:00:00+02:00\no LegalEntityEventRecordedDate:\no 2020-04-20T00:00:00+02:00\no ValidationDocuments: CONTRACTS\no ValidationReference: Notarized documents\nState Transition and Validation Rules for Common Data File formats Page 133 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1860,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.680Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.13.10 Legal Entity Event — Acquisition of an International Branch\nA common example how Acquisition of an International Branch is processed and its outcome:\nInternational Branch A of (head office) Legal Entity B, is acquired by Legal Entity C and henceforth\noperates as Branch for (head office) Legal Entity C. The assets and liabilities related to the Branch are\nfully or partially transferred from Legal Entity B to Legal Entity C. Legal Entity B will have International\nBranch A deleted from the official registry (RA source). Legal Entity C will register a new International\nBranch D in the official registry. This Legal Entity Event can only be recorded if Legal Entity D fulfills all\nthe requirements for International Branches within the Global LEI System (see section 4.2).\nThe LEl issuer managing the LEI Record Set of International Branch A SHALL:\no Set the RegistrationStatus (lei and rr) to RETIRED\no Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be ACQUISITION_BRANCH.\no LegalEntityEventEffectiveDate SHALL be the date the acquisition of the Branch becomes\neffective in the Legal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no If @event_statusis IN_PROGRESS or COMPLETED, the LEl issuer SHALL provide information\nregarding the AffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide lei:SuccessorEntity\no Set the new International Branch (see below) as SuccessorEntity.\nThe LEl issuer managing the LEI Record Set of Branch entity D SHALL:\no Create a new LEI Record for a Branch, if the conditions for issuing an LEI Record for a Branch are\nmet (see Use Case 4.2).\no Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be COMPLETED.\no @group_id SHALL be omitted.\nState Transition and Validation Rules for Common Data File formats Page 134 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2206,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.680Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be ACQUISITION_BRANCH.\no LegalEntityEventEffectiveDate SHALL be the date the acquisition of the Branch becomes\neffective in the Legal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no AffectedFields SHALL be omitted.\no The EntityCreationDate SHALL be the LegalEntiyEventEffectiveDate of entity A’s event with\nLegalEntityEventType ACQUISITION_BRANCH.\n¢ The LegalEntityEventEffectiveDate SHALL be the date the Acquisition becomes effective in the\nLegal Jurisdiction of Branch entity A.\ne Set the LegalForm and the ELF code to the LegalForm and the ELF code of the (head office) Legal\nEntity C.\no Set the Legal Jurisdiction to the Legal Jurisdiction of the (head office) Legal Entity C.\n¢ Create a Relationship Record with the head office C and RelationshipType\nIS_INTERNATIONAL _BRANCH_OF; the StartDate of the RelationshipPeriod with PeriodType\nRELATIONSHIP_PERIOD SHALL be the EntityCreationDate.\no Legal Entity D can acquire an LEl only in case it is not in the home jurisdiction of Legal Entity C.\nState Transition and Validation Rules for Common Data File formats Page 135 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1341,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.680Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"LEI C\nEntity:\no EntityLegalFormCode: N5NT\no Legallurisdiction: BE\nO Transfers assets & liabilities O\n—>\nLEIB LEIC\nFormer INTERNATIONAL_BRANCH_OF\nIS_INTERNATIONAL_BRANCH_OF\nchd\\‘edw\nLEIA LEI D (Create new LEI Record Set)\nEntity: Entity:\ne SuccessorEntity: LEI D o EntitiyCreationDate:\ne 2020-04-19T00:00:00+02:00\nRegistration: o EntityLegalFormCode: N5NT\no RegistrationStatus: RETIRED o Legallurisidiction: BE\no LastUpdateDate: 2020-04-20T13:43:25+02:00\nRelationship:\nRelationship: ° RelationshipType:\no Stop publishing ReportingExceptions IS_INTERNATIONAL_BRANCH_OF\no RelationshipPeriodType:\nRelationship Registration: RELATIONSHIP_PERIOD\no RegistrationStatus: RETIRED * RelationshipPeriodStartDate:\ne 2020-04-19T00:00:00+02:00\nLegalEntityEvent: o LastUpdateDate: 2020-04-20T13:43:25+02:00\no @group_type: STANDALONE\no @entity_status: COMPLETED LegalEntityEvent:\no LegalEntityEventType: ACQUISITION_BRANCH o @group_type: STANDALONE\no LegalEntityEventEffectiveDate: o @entity_status: COMPLETED\n¢ 2020-04-19T00:00:00+02:00 o LegalEntityEventType: ACQUISITION_BRANCH\no LegalEntityEventRecordedDate: o LegalEntityEventEffectiveDate:\ne 2020-04-20T00:00:00+02:00 e 2020-04-19T00:00:00+02:00\ne ValidationDocuments: REGULATORY_FILING o LegalEntityEventRecordedDate:\ne 2020-04-20T00:00:00+02:00c\nAffectedFields: + ValidationDocuments: REGULATORY_FILING\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:E\nntity/lei:SuccessorEntity/lei:SuccessorLEl:\nLEID\nExample 11: The Legal Entity with LEI A, which is an International Branch of B, is acquired by Legal Entity with an LEI C\nwith effective date April 19, 2020. The Legal Entity with LEI A ceases to exist and a new Legal Entity with LEI D is issued as\ninternational Branch of Legal Entity with LEI C. The LElI Record Sets of LEI A and LEI D have been updated on the same\ndate April 20, 2020.\nState Transition and Validation Rules for Common Data File formats Page 136 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2022,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.680Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.13.11 Legal Entity Event — Break-up\nLegal Entity A (general Legal Entity or Government Entity) completely separates into two or more\nindependent Legal Entities B and C (plus D, E, ...). Entity A will cease to exist as an independent Legal\nEntity.\nA common example how Break-up is processed and its outcome if entity A ceases to exists:\nThe LEl issuer managing the LEl Record Set of entity A SHALL:\ne Retire the LEI Record Set of Legal Entity A:\no Set RegistrationStatus RETIRED.\ne Set current relationships to RETIRED, if applicable.\ne SHALL include SuccessorEntity for every newly created entity after the separation.\no Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be BREAKUP.\no LegalEntityEventEffectiveDate SHALL be the date the Break-up becomes effective in the Legal\nJurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no If @event_statusis IN_PROGRESS or COMPLETED, the LEl issuer SHALL provide information\nregarding the AffectedFields: For @field_xpath the LEl issuer usually\ne SHALL provide lei:SuccessorEntity for all independent Legal Entities created\nThe LEl issuer(s) managing the records of entities B, C, ... SHALL:\no Create new LEI Records for the new Legal Entity(ies) (see Use Case 4.1).\no Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be COMPLETED.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\nG State Transition and Validation Rules for Common Data File formats Page 137 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1852,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.680Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o LegalEntityEventType SHALL be BREAKUP.\no LegalEntityEventEffectiveDate SHALL be the date the Break-up becomes effective in the Legal\nJurisdiction of the new Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no AffectedFields SHALL be omitted.\nState Transition and Validation Rules for Common Data File formats Page 138 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":495,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.680Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"LEIB LEIC LEID(E, F,..)\nv\nBreak-up\nLEI A\nLEI A LEIB, C, (D, E,F,..)\nEntity: o Create new LEI Record Sets\no SuccessorEntity: LEI B\no SuccessorEntity: LEI C LegalEntityEvent:\nRegistration: o @group_type: STANDALONE\no RegistrationStatus: RETIRED o @event_status: COMPLETED\no LegalEntityEventType: BREAKUP\nRelationship: + LegalEntityEventEffectiveDate:\n© Stop publishing ReportingExceptions © 2020-04-12T00:00:00+02:00\no LegalEntityEventRecordedDate:\nRelationship Registration + 2020-04-20T00:00:00+02:00\n© RegistrationStatus: RETIRED + ValidationDocuments:\n_ SUPPORTING_DOCUMENTS\nLegalEntityEvent: » ValidationReference:\n© @group_type: STANDALONE http://registry.gov/evidence.pdf\no @event_status: COMPLETED\no LegalEntityEventType: BREAKUP\no LegalEntityEventEffectiveDate:\no 2020-04-12T00:00:00+02:00\no LegalEntityEventRecordedDate:\no 2020-04-20T00:00:00+02:00\no ValidationDocuments:\nSUPPORTING_DOCUMENTS\no ValidationReference:\nhttp://registry.gov/evidence.pdf\nAffectedFields:\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Ent\nity/lei:SuccessorEntity/lei:SuccessorLEl: LEI B\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Ent\nity/lei:SuccessorEntity/lei:SuccessorLEl: LEI C\nExample 12: The Legal Entity with LEI A is separated into LEI B and LEI C with effective date April 12, 2020. The Legal\nEntity with LEI A ceases to exist. Theoretically, it is possible that LEI A is split into additional Legal Entities (LEID, E, F, ...).\nThe LEI Record Sets of LEI A and LEI D have been updated on the same date April 20, 2020.\nState Transition and Validation Rules for Common Data File formats Page 139 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1712,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.680Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.13.12 Legal Entity Event — Demerger\n\nA part or division of Legal Entity A (general Legal Entity or Government Entity) is separated into a new\n\nseparate entity, Subsidiary Legal Entity B. Part of Legal Entity A’s shares/assets and liabilities are\n\ntransferred to B.\n\nThe LEl issuer managing the LEI Record Set of Legal Entity A SHALL:\n\no Create a new LegalEntityEvent with:\n\no @group_type SHALL be STANDALONE.\n\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\n\no @group_id SHALL be omitted.\n\no @group_sequence_no SHALL be omitted.\n\no LegalEntityEventType SHALL be DEMERGER.\n\no LegalEntityEventEffectiveDate SHALL be the date the Demerger becomes effective in the\nLegal Jurisdiction of the Legal Entity.\n\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\n\no If @event_statusis IN_PROGRESS or COMPLETED, the LEl issuer SHALL provide information\nregarding the AffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide lei:SuccessorEntity\n\no Set LEI B as SuccessorEntity.\n\nThe LEl issuer managing the LEI Record Set of entity B SHALL:\n\n¢ Create a new LEI Record Set for the new Legal Entity B (see Use Case 4.1).\n\n* Create accounting consolidation relationship(s) with Legal Entity A, as applicable; StartDate of\nthe RelationshipPeriod with PeriodType RELATIONSHIP_PERIOD SHALL be the effective date that\nthe Legal Entity event became effective in the Legal Jurisdiction of the new Legal Entity (see\nbelow).\n\no Create a new LegalEntityEvent with:\n\no @group_type SHALL be STANDALONE.\n\no @event_status SHALL be COMPLETED.\n\no @group_id SHALL be omitted.\n\no @group_sequence_no SHALL be omitted.\n\no LegalEntityEventType SHALL be DEMERGER.\nState Transition and Validation Rules for Common Data File formats Page 140 of 170\n\n@ Public Version 2.7.1 Final\n\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1910,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.680Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"the Legal Entities linked by the relationship. Currently, relationship information for accounting\nconsolidation parents, for branches and for funds are defined within the Global LEI System.\nAccounting consolidating parent relationship\nAccounting consolidating parent relationship information is based on existing accounting definitions\nimplemented in the International Financial Reporting Standard (IFRS) or the United States Generally\nAccepted Accounting Principles (US GAAP), but other accounting standards are also accepted.\nThe direct accounting consolidating parent of Legal Entity X would be defined as the lowest level\nLegal Entity that prepares consolidated financial statements that consolidate entity X, based on the\naccounting definition of consolidation applying to this parent.\nThe ultimate accounting consolidating parent of entity X would be the highest level Legal Entity\npreparing consolidated financial statements that consolidate entity X, based on the accounting\ndefinition of consolidation applying to this parent. The ultimate accounting consolidating parent\nSHALL NOT have accounting consolidating parent relationships of its own.\nAccording to the definitions of direct and ultimate parents, a Legal Entity cannot declare a\nconsolidation relationship for one parent and a non-consolidating exception for the other. If the\ndirect accounting consolidation parent is controlled, but not consolidated, by another entity, it is also\nconsidered to be the ultimate parent within the Global LEI System (see Figure 1). Likewise, if the child\nLegal Entity is controlled, but not consolidated, by an entity that itself is controlled by an entity\nconsolidating the child Legal Entity, the consolidating entity would be both direct and ultimate parent\n(see Figure 2, example b).\nBy the same definition, only entities with two non-consolidating exceptions can be viable candidates\nfor being declared as an ultimate parent of another entity. GLEIF created a set of data quality checks\nto ensure compliance with this requirement, assigning errors to both the LEl issuer of the child Legal\nEntity record and of the ultimate parent record when inconsistent parent relationships are detected.\nIt is expected that LEl issuers, as part of the Validation and Verification of Level 2 data, check if the\nultimate parent identified by an LEI has consistent parent information. LEl issuer SHALL use LEI\nSearch 2.0, Level 2 XML files (relationship and exception files) and/or Golden Copy files to identify\ninformation regarding the ultimate parent's relationships (if any).\nState Transition and Validation Rules for Common Data File formats Page 15 of 170\n@ Public Version 2.7.1 Final\nG 2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2755,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.684Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o LegalEntityEventEffectiveDate SHALL be the date the Demerger becomes effective in the\nLegal Jurisdiction of the new Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no AffectedFields SHALL be omitted.\nO Demerger O\n—>\nLEI A LEIB\nLEIA LEI B (Create new LEI Record Set)\nEntity: Entity:\no SuccessorEntity: LEI B o EntityCreationDate:\no 2020-04-12T00:00:00+02:00\nLegalEntityEvent:\no @group_type: STANDALONE Relationship:\no @event_status: COMPLETED o Create accounting consolidation\n+ LegalEntityEventType: DEMERGER relationship(s)\no LegalEntityEventEffectiveDate: o RelationshipPeriodStartDate:\no 2020-04-12T00:00:00+02:00 o 2020-04-12T00:00:00+02:00\n+ LegalEntityEventRecordedDate: © RelationshipPeriodType:\n+ 2020-04-20T00:00:00+02:00 RELATIONSHIP_PERIOD\n° ValidationDocuments: L LaStUpdateDate: 2020-04-20T13:43:25+02:00\nSUPPORTING_DOCUMENTS\n« ValidationReference: LegalEntityEvent:\nhttp://registry.gov/evidence.pdf © @group_type: STANDALONE\no @event_status: COMPLETED\nAffectedFields: o LegalEntityEventType: DEMERGER\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/I ¢ LegalEntityEventEffectiveDate:\nei:Entity/lei:SuccessorEntity/lei:Successor e 2020-04-12T00:00:00+02:00\nLEI: LEI B o LegalEntityEventRecordedDate:\no 2020-04-20T00:00:00+02:00\no ValidationDocuments:\nSUPPORTING_DOCUMENTS\no ValidationReference:\nhttp://registry.gov/evidence.pdf\nExample 13: The Legal Entity with LEI A is separated into LEI B with effective date April 12, 2020. The Legal Entity with LEI\nA continues to exist. The LEI Record Sets of LEI A and LEI D have been updated on the same date April 20, 2020.\nState Transition and Validation Rules for Common Data File formats Page 141 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1838,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.684Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.13.13 Legal Entity Event — Spin-off\nA part, division or Subsidiary of Legal Entity A (general Legal Entity) is separated into Legal Entity B,\nwhich could be a new or existing Legal Entity. In case of an existing Legal Entity B, Legal Entity B will\nno longer remain as a Subsidiary of Legal Entity A after completion of the Spin-off. Part of Legal Entity\nA’s shares/assets and liabilities are transferred to Legal Entity B; shareholders of Legal Entity A are\ncompensated for the asset value or loss by either receiving shares from Legal Entity B or via dividend.\nThe LEl issuer managing the LEI Record Set of Legal Entity A SHALL:\no Provide a SuccessorEntity.\no Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be SPINOFF.\no LegalEntityEventEffectiveDate SHALL be the date the Spin-off becomes effective in the Legal\nJurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no If @event_status is IN_PROGRESS or COMPLETED, the LEl issuer SHALL provide information\nregarding the AffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide lei:SuccessorEntity\nThe LEl issuer managing the LEI Record Set of Legal Entity B SHALL:\no Create a new LEI Record for the new Legal Entity B (see Use Case 4.1), if applicable.\no Retire any excisting relationships between Legal Entity B and Legal Entity A, if Legal Entity B\nalready exists,\no Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be COMPLETED, in case a new Legal Entity is created.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED, in case\nLegal Entity B already existed before the Spin-off.\no @group_id SHALL be omitted.\nState Transition and Validation Rules for Common Data File formats Page 142 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2110,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.684Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be SPINOFF.\no LegalEntityEventEffectiveDate SHALL be the date the Spin-off becomes effective in the\nLegalljurisdiction of the new Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no AffectedFields SHALL be omitted.\nO Spin-off O\n—>\nLEI A LEIB\nLEIA LEI B (existing entity, prev. subsidiary)\nEntity: Relationship:\no SuccessorEntity: LEI B o RelationshipStatus: RETIRED\no RelationshipPeriodEndDate:\nLegalEntityEvent: e 2020-04-18T00:00:00+02:00\n© @group_type: STANDALONE o RelationshipPeriodType:\no @event_status: COMPLETED RELATIONSHIP_PERIOD\n© LegalEntityEventType: SPINOFF o LastUpdateDate: 2020-04-20T13:43:25+02:00\no LegalEntityEventEffectiveDate:\no 2020-04-18T00:00:00+02:00 LegalEntityEvent:\no LegalEntityEventRecordedDate: o @group_type: STANDALONE\no 2020-04-20T00:00:00+02:00 o @event_status: COMPLETED\no ValidationDocuments: o LegalEntityEventType: SPINOFF\nSUPPORTING_DOCUMENTS o LegalEntityEventEffectiveDate:\no ValidationReference: e 2020-04-18T00:00:00+02:00\nhttp://registry.gov/evidence.pdf o LegalEntityEventRecordedDate:\no 2020-04-20T00:00:00+02:00\nAffectedFields: o ValidationDocuments:\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/| SUPPORTING_DOCUMENTS\nei:Entity/lei:SuccessorEntity/lei:Successor o ValidationReference:\nLEI: LEIB http://registry.gov/evidence.pdf\nExample 14: The Legal Entity with LEI A is separated into LEI B with effective date April 18, 2020. The Legal Entity with LEI\nA continues to exist. The former relationship record between LEI B and LEI A is set to RegistrationStatus RETIRED. The LEI\nRecord Sets of LEI A and LEI B have been updated on the same date April 20, 2020.\nState Transition and Validation Rules for Common Data File formats Page 143 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1934,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.684Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"O Spin-off O\n—>\nLEIA LEIB\nLEI A\nEntity: LEl B (new entity, prev. division of A)\ne SuccessorEntity: LEI B\nEntity:\nLegalEntityEvent: o EntityCreationDate:\n« @group_type: STANDALONE + 2020-04-18T00:00:00+02:00\no @event_status: COMPLETED\no LegalEntityEventType: SPINOFF LegalEntityEvent:\no LegalEntityEventEffectiveDate: © @group_type: STANDALONE\no 2020-04-18T00:00:00+02:00 ¢ @event_status: COMPLETED\no LegalEntityEventRecordedDate: o LegalEntityEventType: SPINOFF\ne 2020-04-20T00:00:00+02:00 o LegalEntityEventEffectiveDate:\no ValidationDocuments: e 2020-04-18T00:00:00+02:00\nSUPPORTING_DOCUMENTS o LegalEntityEventRecordedDate:\ne ValidationReference: e 2020-04-20T00:00:00+02:00\nhttp://registry.gov/evidence.pdf o ValidationDocuments:\nSUPPORTING_DOCUMENTS\nAffectedFields: o ValidationReference:\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/I http://registry.gov/evidence.pdf\nei:Entity/lei:SuccessorEntity/lei:Successor\nLEI: LEI B\nExample 15: The Legal Entity with LEI A is separated into LEI B with effective date April 18, 2020. The Legal Entity with LEI\nA continues to exist. The entity for LEI Record Set B has been created as a result of the Spin Off on April 20, 2020.\n4.13.14 Legal Entity Event — Transformation of an International Branch to a\nSubsidiary\nInternational Branch A of (head office) Legal Entity B, is separated from Legal Entity B and becomes a\nnew Legal Entity C, a Subsidiary of Legal Entity B; part of Legal Entity B’s shares/assets and liabilities\nare transferred to new Legal Entity C.\nThe LEl issuer managing the LEI Record of Legal Entity A SHALL:\ne Retire the LEI Record Set of Legal Entity A:\n\no Set RegistrationStatus to RETIRED.\n\no Set RegistrationStatus of all current Relationship Records to RETIRED with RelationshipStatus\nINACTIVE; set EndDate of RelationshipPeriod with PeriodType RELATIONSHIP_PERIOD as\nEffective Date of the LegalEntityEvent (see below).\n\no Set Legal Entity C as SuccessorEntity.\n\no Create a new LegalEntityEvent with:\nState Transition and Validation Rules for Common Data File formats Page 144 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2162,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.684Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o @group_type SHALL be STANDALONE.\n\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\n\no @group_id SHALL be omitted.\n\no @group_sequence_no SHALL be omitted.\n\n+ LegalEntityEventType SHALL be TRANSFORMATION_BRANCH_TO_SUBSIDIARY.\n\no LegalEntityEventEffectiveDate SHALL be the date the transformation becomes effective in\nthe Legal Jurisdiction of the Legal Entity.\n\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\n\no If @event_status is IN_PROGRESS, or COMPLETED, the LEl issuer SHALL provide information\nregarding the AffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide lei:SuccessorEntity\n\ne The LEl issuer managing the LEI Record of the new Legal Entity C SHALL:\n\no Create new LEI Records for the new Legal Entity(ies) (see section 4.1)\n\no Create a new accounting consolidation relationship(s) with Legal Entity B, as applicable;\nStartDate of the RelationshipPeriod with PeriodType RELATIONSHIP_PERIOD SHALL be the\nLegalEntityEventEffectiveDate that the Legal Entity event became effective in the Legal\nJurisdiction of the new Legal Entity (see below).\n\no Create a new LegalEntityEvent with:\n\no @group_type SHALL be STANDALONE.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no @event_Status SHALL be COMPLETED\n+ LegalEntityEventType SHALL be TRANSFORMATION_BRANCH_TO_SUBSIDIARY.\no LegalEntityEventEffectiveDate SHALL be the date the transformation becomes effective in\nthe Legal Jurisdiction of the new Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no AffectedFields SHALL be omitted.\nState Transition and Validation Rules for Common Data File formats Page 145 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1862,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.684Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"0\nFormer NTERNAW s\\mw&mwcomm DATED_BY\nSucceeded by\n—>\nS %\no LEIA LEI C (Create new LEI Record Set)\nEntity: Entity:\no SuccessorEntity: LEI C o EntityCreationDate:\ne 2020-04-17T00:00:00+02:00\nRegistration:\no RegistrationStatus: RETIRED Relationship:\no LastUpdateDate: 2020-04-20T13:43:25+02:00 o Create accounting consolidation\nrelationship(s)\nRelationship: o RelationshipPeriodStartDate:\no RelationshipPeriodEndDate: e 2020-04-17T00:00:00+02:00\ne 2020-04-17T00:00:00+02:00 o RelationshipPeriodType:\no RelationshipPeriodType: RELATIONSHIP_PERIOD\nRELATIONSHIP_PERIOD o LastUpdateDate: 2020-04-20T13:43:25+02:00\nRelationship Registration: LegalEntityEvent:\no RegistrationStatus: RETIRED o @group_type: STANDALONE\no @event_status: COMPLETED\nLegalEntityEvent: + LegalEntityEventType:\n° (@group_type: STANDALONE TRANSFORMATION_BRANCH_TO_SUBSIDIARY\n¢ @event_status: COMPLETED o LegalEntityEventEffectiveDate:\n¢ LegalEntityEventType: e 2020-04-17T00:00:00+02:00\nTRANSFORMATION_BRANCH_TO_SUBSIDIARY + LegalEntityEventRecordedDate:\no LegalEntityEventEffectiveDate: o 2020-04-20T00:00:00+02:00\n° 2020-04-17T00:00:00+02:00 o ValidationDocuments:\no LegalEntityEventRecordedDate: SUPPORTING_DOCUMENTS\no 2020-04-20T00:00:00+02:00 o ValidationReference:\n¢ ValidationDocuments: http://registry.gov/evidence.pdf\nSUPPORTING_DOCUMENTS\no ValidationReference:\nhttp://registry.gov/evidence.pdf\nAffectedFields:\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:E\nntity/lei:SuccessorEntity/lei:SuccessorLEl: LEI\nC\nExample 16: The Legal Entity with LEI A, which is an International Branch of LEI B, is transformed into a Subsidiary of LEI B\nwith effective date April 17, 2020. The Legal Entity with LEI B is now the direct and/or ultimate parent of LEI C. The Legal\nentity with LEI A ceases to exist and a new Legal Entity with LEI C is created as successor of LEI A. The LEI Record Sets of\nLEI A and LEI C have been updated on the same date April 20, 2020.\nState Transition and Validation Rules for Common Data File formats Page 146 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2120,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.684Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.13.15 Legal Entity Event — Bankruptcy\nLegal Entity A (general Legal Entity or Government Entity) declares Bankruptcy based on the laws of\nits jurisdiction. During the process, the Legal Entity could no longer be operational, and could still\nexist as Legal Entity. Once the process is completed, all or part of the Legal Entity could survive, and\nthe LEI remains ISSUED or the Legal Entity could become inactive and the LEIl is RETIRED. Bankruptcy\nevents are often followed by Liquidation, Insolvency or Dissolution events which will determine the\nfinal status of the Legal Entity and its LEI.\nWhile the Bankruptcy is in progress, the LEl issuer managing the LEI Record Set of Legal Entity A\nSHALL:\no Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status MAY be IN_PROGRESS.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be BANKRUPTCY.\no LegalEntityEventEffectiveDate SHALL be the date the Bankruptcy becomes effective in the\nLegal Jurisdiction of Legal Entity A.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no If @event_status is IN_PROGRESS or COMPLETED, the LEl issuer SHALL provide information\nregarding the AffectedFields: For @field_xpath the LEl issuer usually\no MAY provide lei:SuccessorEntity\no Keep the LEI Record Set of Legal Entity A as it is, but check if a change in legal name and/or in\nlegal form applies; create the respective Legal Entity Events, including all other LEI Record Set\nupdates, if necessary. Depending on the laws and regulations in the Legal Entity’s jurisdiction, the\nchange in legal form and/or legal name MAY already be effective, in which case the\n@event_status of these events SHALL be COMPLETED rather than IN_PROGRESS.\nOnce the Bankruptcy event is completed the LEl issuer managing the LEI Record Set of entity A\nSHALL:\no Create a new LegalEntityEvent with:\no @event_status SHALL be COMPLETED.\no LegalEntityEventEffectiveDate SHALL be the date the Bankruptcy becomes effective in the\nLegal Jurisdiction of Legal Entity A.\nState Transition and Validation Rules for Common Data File formats Page 147 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2291,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.684Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no AffectedFields SHALL be omitted.\nState Transition and Validation Rules for Common Data File formats Page 148 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":322,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.684Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Bankruptcy\n- O O o Oy >\nS S\nIn-progress Event Post Event\nLEI A LEI A\nLegalEntityEvent: Registration:\no @group_type: STANDALONE o RegistrationStatus: RETIRED\no @event_status: IN_PROGRESS\no LegalEntityEventType: BANKRUPTCY Relationship:\no LegalEntityEventEffectiveDate: o Create accounting consolidation relationship(s)\no 2020-09-08T00:00:00+02:00 o RelationshipPeriodEndDate:\no LegalEntityEventRecordedDate: e 2020-04-19T00:00:00+02:00\ne 2020-02-09T00:00:00+02:00 o RelationshipPeriodType: RELATIONSHIP_PERIOD\no ValidationDocuments: o LastUpdateDate:\nSUPPORTING_DOCUMENTS e 2020-04-20713:43:25+02:00\ne ValidationReference:\nhttp://registry.gov/evidence.pdf LegalEntityEvent:\no @group_type: STANDALONE\no @event_status: IN_PROGRESS\no LegalEntityEventType: BANKRUPTCY\nExample 17: The Legal Entity LEI A goes ¢ LegalEntityEventEffectiveDate:\nbankrupt. The process of Bankruptcy was e 2020-09-08T00:00:00+02:00\nscheduled to end on September 8, 2020 and o LegalEntityEventRecordedDate:\nwas recorded in the Global LEI System on s 2020-02-09T00:00:00+02:00\nFebruary 9, 2020. In this example, no « ValidationDocuments: SUPPORTING_DOCUMENTS\nrelevant information describing the Legal s -\nEntity is changed and therefore no ‘ Valldatlon'Reference: .\nAffectedFields are included. The Bankruptcy http://registry.gov/evidence.pdf\nwas completed on October 19, 2020 behind\nschedule. The completion of the Legal Entity LegalEntityEvent:\nEvent was recorded in the Global LEI System o @group_type: STANDALONE\non November 20, 2020. As a consequence of s @event_status: COMPLETED\nthe bankruptcy, the Legal Entity has ceased o LegalEntityEventType: BANKRUPTCY\nto exist due toa dissomtio.n even.t on o LegalEntityEventEffectiveDate:\nDecember 19, 2020. The dissolution was\nrecorded in the Global LEI System on ¢ 2020-10-19T00:00:00+02:00\nDecember 20, 2020. o LegalEntityEventRecordedDate:\ne 2020-11-20T00:00:00+02:00\nLegalEntityEvent:\no @group_type: STANDALONE\no @event_status: COMPLETED\no LegalEntityEventType: DISSOLUTION\no LegalEntityEventEffectiveDate:\ne 2020-12-19T00:00:00+02:00\no LegalEntityEventRecordedDate:\ne 2020-12-20T00:00:00+02:00\ne ValidationDocuments: SUPPORTING_DOCUMENTS\ne ValidationReference:\nhttp://registry.gov/evidence.pdf\nState Transition and Validation Rules for Common Data File formats Page 149 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2413,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.684Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.13.16 Legal Entity Event — Insolvency\n\nLegal Entity A (general Legal Entity or Government Entity) declares itself insolvent based on the laws\nof its jurisdiction. This Legal Entity Event is handled like a Bankruptcy, except for the different\nLegalEntityEventType recorded.\n\nIn contrast to Bankruptcy, the LEl issuer managing the LegalEntityEvent of Legal Entity A SHALL:\n\no Use INSOLVENCY as LegalEntityEventType.\n\n4.13.17 Legal Entity Event — Liquidation\n\nLegal Entity A (general Legal Entity or Government Entity) closes all business activities due to\nLiguidation. This Legal Entity Event always leads to the retirement of the LEl and the Legal Entity\nbecoming INACTIVE when the Legal Entity Event reached @event_status COMPLETED. Liquidation\ncan be the result of a Bankruptcy or of an Insolvency.\n\nThe LEl issuer managing the LEI Record Set of Legal Entity A SHALL:\n\no Retire the LEI Record Set of Legal Entity A, if @event_status is COMPLETED:\n\no Set RegistrationStatus to RETIRED.\n\no Set EntityStatus to INACTIVE.\n\no Set RegistrationStatus of all current Relationship Records to RETIRED with RelationshipStatus\nINACTIVE; set EndDate of RelationshipPeriod with PeriodType RELATIONSHIP_PERIOD as\nEffective Date of the LegalEntityEvent (see below).\n\no Create a new LegalEntityEvent with:\n\no @group_type SHALL be STANDALONE.\n\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\n\no @group_id SHALL be omitted.\n\no @group_sequence_no SHALL be omitted.\n\no LegalEntityEventType SHALL be LIQUIDATION.\n\no LegalEntityEventEffectiveDate SHALL be the date the LIQUIDATION becomes effective in the\nLegal Jurisdiction of Legal Entity A.\n\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\n\no If @event_statusis IN_PROGRESS or COMPLETED, the LEl issuer SHALL provide information\nregarding the AffectedFields: For @field_xpath the LEl issuer usually\no MAY provide lei:SuccessorEntity\n\nState Transition and Validation Rules for Common Data File formats Page 150 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2131,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.684Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Non-consolidating Non-consolidating\nException Exception\n%}T PARENT\\/ULTIMATE/PA\\RENT\n@\\?\nDIRECT PARENT\n@ EJ‘LTIMI/\\TE PARE;\\]T\n\\I: \\\"\\ ULTIMATE PARENT\nA ! ULTIMATE PARENT\nULTIMATE PARENT /\nDIRECT PARENT\nFigure 1: General view on one complete network chain and the representation of the Relationship Records to the\nultimate parent LEI.\nChild reporting (bottom-up) principle\nInitially only child entities may report level 2 data (the relationship information to their parent\nentities) to minimize difficulties arising from complex Business Rules dependent on the reporting\nentity and de-duplication. This also covers a parent entity instructing its child entity or entities to\nreport parent information, and also delegated reporting by a parent entity on behalf of any child\nentities.\nGiven this rule, reporting of child entities without an LEl is NOT possible under any circumstance.\nState Transition and Validation Rules for Common Data File formats Page 16 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1067,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.684Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.13.18 Legal Entity Event — Dissolution\nLegal Entity A (general Legal Entity of Government Entity) voluntarily closes all business activities.\nThis Legal Entity Event always leads to the retirement of the LElI and the Legal Entity becoming\nINACTIVE when the Legal Entity Event reached @event_status COMPLETED. This Legal Entity Event is\nhandled like Liquidation, except for the different Legal EntityEventType and the different expected\n@field_xpath.\nIn contrast to Liquidation, the LEl issuer managing the LEI Record Set of Legal Entity A SHALL create a\nnew LegalEntityEvent with:\no LegalEntityEventType SHALL be DISSOLUTION.\no If @event_status is IN_PROGRESS or COMPLETED, the LEl issuer SHALL provide information\nregarding the AffectedFields: For @field_xpath the LEl issuer usually\no MAY provide lei:SuccessorEntity\n4.13.19 Legal Entity Event — Voluntary Arrangement\nA company Voluntary Arrangement (CVA) allows a Legal Entity A (general Legal Entity or Government\nEntity) to negotiate with its creditors the settlement of any debts by paying only a portion of the\namounts owed or by some other arrangement to pay the debt. This Legal Entity Event does not lead\nto retirement of the LEL.\nThe LEl issuer managing the LEI Record Set of Legal Entity A SHALL:\no Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS.\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be VOLUNTARY_ARRANGEMENT\no @event_status SHALL be IN_PROGRESS.\no LegalEntityEventEffectiveDate SHALL be the date the CVA becomes effective in the Legal\nJurisdiction of Legal Entity A.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no AffectedFields SHALL be omitted.\nOnce the CVA is completed, the LEl issuer managing the LEI Record Set of entity A SHALL:\nState Transition and Validation Rules for Common Data File formats Page 151 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2068,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.685Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be COMPLETED\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be VOLUNTARY_ARRANGEMENT.\no LegalEntityEventEffectiveDate SHALL be the date the CVA becomes effective in the Legal\nJurisdiction of Legal Entity A.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no AffectedFields SHALL be omitted.\nState Transition and Validation Rules for Common Data File formats Page 152 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":675,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.685Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"O Voluntary Arrangement O\n_————’\nLEI A LEI A\nPre Event Post Event\nLEI A LEI A\nLegalEntityEvent: LegalEntityEvent:\no @group_type: STANDALONE o @group_type: STANDALONE\no @event_status: IN_PROGRESS o @event_status: IN_PROGRESS\no LegalEntityEventType: o LegalEntityEventType:\nVOLUNTARY_ARRANGEMENT_IN_PROGRESS VOLUNTARY_ARRANGEMENT_IN_PROGRESS\no LegalEntityEventEffectiveDate: [ ] o LegalEntityEventEffectiveDate: [ ]\no LegalEntityEventRecordedDate: o LegalEntityEventRecordedDate:\ne 2020-03-05T09:00:00+02:00 e 2020-03-05T09:00:00+02:00\no ValidationDocuments: CONTRACTS o ValidationDocuments: CONTRACTS\nLegalEntityEvent:\no @group_type: STANDALONE\no @event_status: COMPLETED\no LegalEntityEventType:\nVOLUNTARY_ARRANGEMENT\no LegalEntityEventEffectiveDate:\no 2020-04-19T00:00:00+02:00\no LegalEntityEventRecordedDate:\no 2020-04-20T09:00:00+02:00\no ValidationDocuments: CONTRACTS\nExample 18: Legal Entity LEI A engages in a company Voluntary Arrangement without any knowledge regarding the\nexpected effective date. The process of the Voluntary Arrangement was recorded in the Global LEI System on March 5,\n2020. The Voluntary Arrangement was completed on April 19, 2020. The completion of the Legal Entity Event was\nrecorded in the Global LEI System on April 20, 2020.\nState Transition and Validation Rules for Common Data File formats Page 153 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1452,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.685Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.13.20 Legal Entity Event — Reverse Takeover\nA Reverse Takeover describes the following scenario:\n1. Entity Bis acquired by entity A\n2. Entity Ais absorbed by B\n3. Entity B changes its LegalName to A\nThe result has a surviving entity with the original LegalName of entity A and the LEI of entity B. The\nLEI Record of entity A will be RETIRED and point to the LEI of entity B as SuccessorEntity.\nTo record this Legal Entity Event, the LEl issuer of entity A SHALL update the LEI Record as following:\no Set RegistrationStatus RETIRED.\no Set Legal Entity B as SuccessorEntity.\ne Set current relationships to RETIRED, if applicable.\no Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED, based on\nthe status of the event (see section 4.13.1).\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be MERGERS_AND_ACQUISITIONS.\n¢ LegalEntityEventEffectiveDate SHALL be the date the Reverse Takeover becomes effective in\nthe Legal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\n¢ ValidationDocument and the optional ValidationReference SHALL indicate the sources used\nfor validating the Legal Entity Event.\no If @event_statusis IN_PROGRESS or COMPLETED, the LEl issuer SHALL provide information\nregarding the AffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide lei:SuccessorEntity\nThe LEl issuer of entity B SHALL record the Reverse Takeover event as a group of three events, linked\ntogether and set in the correct sequence order:\n¢ Create a new LegalEntityEvent with:\no @group_type SHALL be REVERSE_TAKEOVER.\nState Transition and Validation Rules for Common Data File formats Page 154 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1935,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.685Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be a unique identifier (e.g., a hash value calculated from the combination\nof the LEl, EventType and EffectiveDate).\no @group_sequence_no SHALL be 1 (one).\no LegalEntityEventType SHALL be MERGERS_AND_ACQUISITIONS.\n¢ LegalEntityEventEffectiveDate SHALL be the date the Reverse Takeover becomes effective in\nthe Legal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\n¢ ValidationDocument and the optional ValidationReference SHALL indicate the sources used\nfor validating the Legal Entity Event.\no AffectedFields SHALL be omitted.\ne Create a new LegalEntityEvent with:\no @group_type SHALL be REVERSE_TAKEOVER.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be the same unique identifier used for the previous event.\no @group_sequence_no SHALL be 2 (two).\no LegalEntityEventType SHALL be ABSORPTION.\no LegalEntityEventEffectiveDate SHALL be the same date as for the previous event.\no LegalEntityEventRecordedDate SHALL be the same date as for the previous event.\n¢ ValidationDocument and the optional ValidationReference SHALL indicate the sources used\nfor validating the Legal Entity Event.\no AffectedFields SHALL be omitted.\no Create a new LegalEntityEvent with:\no @group_type SHALL be REVERSE_TAKEOVER.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED.\no @group_id SHALL be the same unique identifier used for the previous event.\no @group_sequence_no SHALL be 3 (three).\no LegalEntityEventType SHALL be CHANGE_LEGAL_NAME.\nG State Transition and Validation Rules for Common Data File formats Page 155 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1855,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.685Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o LegalEntityEventEffectiveDate SHALL be the same date as for the previous event.\no LegalEntityEventRecordedDate SHALL be the same date as for the previous event.\n¢ ValidationDocument and the optional ValidationReference SHALL indicate the sources used\nfor validating the Legal Entity Event.\no If @event_statusis IN_PROGRESS, the LEl issuer SHALL provide information regarding the\nAffectedFields: For @field_xpath the LEl issuer usually\no SHALL provide lei:LegalName\no MAY provide lei:OtherEntityNames\no MAY provide lei:TransliteratedOtherEntityNames\n¢ The LegalName of LEI B SHALL change to LegalName of LEI A.\nState Transition and Validation Rules for Common Data File formats Page 156 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":796,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.685Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"1 Acquired by\nA/Z/-\\bs;edby\\\n_—mmm\nS S\nLEI A LEI B\nEntity: Entity:\no “SuccessorEntity: LEI B” o LegalName: “Company B.V.“\no LegalName: Company B.V.\nLegalEntityEvent:\nRegistration: o @group_type: REVERSE_TAKEOVER\no RegistrationStatus: RETIRED o @event_status: COMPLETED\no @group_id: dfecd444f23463443a98n12a\nRelationship: o @group_sequence_no: 1\n* Remove ReportingExceptions o LegalEntityEventType:\no lastUpdateDate: 2020-04-20T13:43:25+02:00 MERGERS_AND_ACQUISITIONS\no LegalEntityEventEffectiveDate:\nRelationship Registration: © 2020-04-19T00:00:00+02:00\n* RegistrationStatus: RETIRED o LegalEntityEventRecordedDate:\no 2020-04-20T00:00:00+02:00\nLegalEntityEvent: « ValidationDocuments: ACCOUNTS_FILING\no @group_type: STANDALONE\no @event_status: COMPLETED LegalEntityEvent:\n© LegalEntityEventType: o @group_type: REVERSE_TAKEOVER\nMERGERS_AND_ACQUISITIONS s @event_status: COMPLETED\n© LegalEntityEventEffectiveDate: + @group_id: dfecd444f23463443a98n12a\n© 2020-04-19T00:00:00+02:00 « @group_sequence_no: 2\n© LegalEntityEventRecordedDate: + LegalEntityEventType: ABSORPTION\n¢ 2020-04-20T11:30:00+02:00 » LegalEntityEventEffectiveDate:\no ValidationDocuments: ACCOUNTS_FILING s 2020-04-19T00:00:00+02:00\no ValidationReference: Consolidated financial + LegalEntityEventRecordedDate:\nstatement o 2020-04-20T11:30:00+02:00\no ValidationDocuments: ACCOUNTS_FILING\nAffectedFields:\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:E LegalEntityEvent:\nntity/lei:SuccessorEntity/lei:SuccessorLEl: « @group_type: REVERSE_TAKEOVER\nLEI B + @event_status: COMPLETED\no @group_id: dfecd444f23463443a98n12a\no (@group_sequence_no: 3\no LegalEntityEventType: CHANGE_LEGAL_NAME\no LegalEntityEventEffectiveDate:\no 2020-04-19T00:00:00+02:00\no LegalEntityEventRecordedDate:\ne 2020-04-20T11:30:00+02:00\no ValidationDocuments: ACCOUNTS_FILING\nExample 19: Reverse Takeover\nState Transition and Validation Rules for Common Data File formats Page 157 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2050,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.685Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.13.21 Legal Entity Event — Transformation of an Umbrella Fund to a Stand-Alone\nFund\nWhen an umbrella fund A is converted into a stand-alone fund, all sub-funds/compartments of\numbrella fund A (fund entities with a IS_SUBFUND_OF relationship with umbrella fund A) are either\nmerged into umbrella fund A or need to be separated from umbrella fund A with a different Legal\nEntity Event recorded for the sub-fund(s). This Use Case assumes, that all (remaining) sub-funds are\nmerged into the umbrella fund prior to the conversion.\nThe LEl issuer managing the LEI Record Sets of any sub-fund of umbrella fund A SHALL:\ne Set the sub-fund relationship to RETIRED.\no Set the RegistrationStatus of each sub-fund to RETIRED.\no Set the umbrella fund as SuccessorEntity.\nThe LEl issuer managing the LEl Record Sets of umbrella fund entity A SHALL:\no Create a new LegalEntityEvent with:\no @group_type SHALL be STANDALONE.\no @event_status SHALL be IN_PROGRESS, WITHDRAWN_CANCELLED or COMPLETED, based on\nthe status of the event (see section 4.13.1).\no @group_id SHALL be omitted.\no @group_sequence_no SHALL be omitted.\no LegalEntityEventType SHALL be TRANSFORMATION_UMBRELLA_TO_STANDALONE.\no LegalEntityEventEffectiveDate SHALL be the date the transformation becomes effective in\nthe Legal Jurisdiction of the Legal Entity.\no LegalEntityEventRecordedDate SHALL be the date, when the event is recorded in the Global\nLEI System.\no If @event_statusis IN_PROGRESS or COMPLETED, the LEl issuer SHALL provide information\nregarding the AffectedFields: For @field_xpath the LEl issuer usually\no MAY provide lei:SuccessorEntity\n4.13.22 Legal Entity Event — Effects on parent and child relationships\nA Legal Entity Event applied to a Legal Entity can also affect all relationships where the entity is the\nEndNode (parent). Several cases have already been described above. In addition, there is need to\nlook at cases if the parent Legal Entity is RETIRED and hence no longer active or if a Legal Entity that\nwas an ultimate parent has been acquired and now has parent relationships.\nState Transition and Validation Rules for Common Data File formats Page 158 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2246,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.685Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"As soon as the LEl issuer of any child Legal Entity is aware of the retirement of the parent, the LEI\n\nissuer SHALL:\n\no Update all affected relationships to RETIRED.\n\no Create new Relationship Records or reporting exceptions, as applicable.\n\ne The LEl issuer of the child entity works with the child Legal Entity to record the new direct or\nultimate parent Legal Entity relationship.\n\nThe LEl issuer of the child Legal Entity can be informed about the change in the parent’s\n\nRegistrationStatus either\n\no by the child Legal Entity at the time of renewal,\n\n* viathe challenge process\n\ne orduring the course of normal business operations\n\nGiven the LEl issuer of the parent Legal Entity becomes aware of this change to the parent Legal\n\nEntity via the challenge process or during the course of normal business, the LEl issuer should notify\n\nthe LEl issuer of the child Legal Entity and request the LEl issuer of the child Legal Entity to provide\n\nupdated information on the direct or ultimate parent Legal Entity.\n\no If the child Legal Entity has active Relationship Records with rr:RegistrationStatus PUBLISHED or\n\nLAPSED reported, these are updated as follows:\n\no RelationshipStatus SHALL be INACTIVE.\n\no rr:RegistrationStatus SHALL be RETIRED.\n\no RelationshipPeriods with PeriodType RELATIONSHIP_PERIOD SHALL have EndDate populated\nwith the date the parent Legal Entity ceased to exist (same as the\nLegalEntityEventEffectiveDate that retired the parent Legal Entity).\n\no Relationship Records that are already RETIRED, DUPLICATE or ANNULLED are not updated.\n\no The LEl issuer of the child Legal Entity creates a new set of relationship data for the direct and/or\n\nultimate parent Legal Entity based on the updated information.\n\nFor an International Branch relationship, if the (head office) Legal Entity it belongs to merges or\n\nretires and is no longer active, the LEI Record Set of a Branch needs to be updated as well. Either the\n\n(head office) Legal Entity or the International Branch notifies their LEIl issuer at the time of renewal,\n\nthe LEl issuer is made aware via the challenge process, or the LEl issuer becomes aware of the (head\nState Transition and Validation Rules for Common Data File formats Page 159 of 170\n\n@ Public Version 2.7.1 Final\n\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2328,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.685Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"office) Legal Entity retiring during the course of normal business. The LEl issuer of the International\nBranch SHALL change the Branch entity’s LElI Record Set to the RegistrationStatus of RETIRED to have\nthe same status as the (head office) Legal Entity (see above Use Cases 4.8.1 or 4.8.2 respectively).\n4.13.23 Legal Entity Event — Erroneously introduced Legal Entity Event\nIf a Legal Entity Event has been falsely introduced to the LEI Repository, the LEl issuer SHALL:\ne Continue uploading the erroneously introduced Legal Entity Event\no Create an additional Legal Entity Event with:\no @event_status WITHDRAWN_CANCELLED\no LegalEntityEventRecordedDate representing the date the event was cancelled\no All remaining reference data shall be identical to the erroneously introduced legal entity\nevent\nState Transition and Validation Rules for Common Data File formats Page 160 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":986,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.685Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"With the exception of branches, all Legal Entities SHALL report relationship data for both direct and\nultimate accounting consolidating parent. Each relationship SHALL be reported by either a\nRelationship Record or a Reporting Exception Record. See Figure 1 for possible combinations.\nOnly one parent Legal Entity per child may be reported per unique relationship type with published\nregistration status. Direct and ultimate parent can be the same Legal Entity, still the child reports one\nrelationship of each type. The parent entity can be represented by:\ne an LEl for those parent Legal Entities with an LEI;\no an exception with exception reason NO_LEl in case the parent Legal Entity does not have an LEI.\nDIRECT PARENT\\/ULHMATE PARENT DIRECT Pw PARENT\na) b)\nDIRECT PARENTVULTIMATE PARENT DIRECT PARENT\\/ ULTIMATE PARENT\nc) .H d) ‘a\nState Transition and Validation Rules for Common Data File formats Page 17 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1020,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.685Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"O Remediation of an incorrectly reported event O\nIntroduction of incorrect event Resolved incorrect event\nLEI A LEI A\nRegistration: Registration:\no RegistrationStatus: RETIRED o RegistrationStatus: ISSUED\no LastUpdateDate: 2020-01-23T08:41:00+02:00 o LastUpdateDate: 2020-01-25T10:42:00+02:00\nLegalEntityEvent: LegalEntityEvent:\no @group_type: STANDALONE o @group_type: STANDALONE\no @event_status: COMPLETED o @event_status: COMPLETED\no LegalEntityEventType: DISSOLUTION o LegalEntityEventType: DISSOLUTION\no LegalEntityEventEffectiveDate: o LegalEntityEventEffectiveDate:\ne 2020-01-20T00:00:00.000Z e 2020-01-20T00:00:00.000Z\no LegalEntityEventRecordedDate: o LegalEntityEventRecordedDate:\no 2020-01-23T08:41:00+02:00 o 2020-01-23T08:41:00+02:00\no ValidationDocuments: o ValidationDocuments:\nSUPPORTING_DOCUMENTS SUPPORTING_DOCUMENTS\no ValidationReference: o ValidationReference:\nhttp://registry.gov/evidence.pdf http://registry.gov/evidence.pdf\nLegalEntityEvent:\no @group_type: STANDALONE\no @event_status: WITHDRAWN_CANCELLED\no LegalEntityEventType: DISSOLUTION\no LegalEntityEventEffectiveDate:\ne 2020-01-20T00:00:00.000Z\no LegalEntityEventRecordedDate:\ne 2020-01-25T10:42:00+02:00\no ValidationDocuments:\nSUPPORTING_DOCUMENTS\no ValidationReference:\nhttp://registry.gov/evidence.pdf\nExample 20: LEI A was erroneously set to RETIRED on 23 January 2020 and a Legal Entity Event with LegalEntityEventType\nDISSOLUTION was introduced. The LEl issuer acknowledged the incorrect Legal Entity Event on 25 January 2020 and\ncreated an additional Legal Entity Event with @event_status WITHDRAWN_CANCELLED to indicate that the previously\nrecorded Legal Entity Event was incorrect. The RegistrationStatus of the LEI Record returns to ISSUED.\nState Transition and Validation Rules for Common Data File formats Page 161 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1920,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.685Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.14 Update of LEI Reference Data other than due to Legal Entity\nEvents\nThe Reference Data of an LEI Record Set may change without the occurrence of specific Legal Entity\nEvents, for instance due to data updated by the Legal Entity or challenged data. The LEl issuer is\nresponsible to verify changed or challenged Reference Data. If the LEl issuer is ultimately unable to\nfully corroborate Reference Data updated or confirmed by the Legal Entity, the Validation Sources\nmust change to PARTIALLY CORROBORATED or ENTITY_SUPPLIED_ONLY.\nWhenever an element of the Reference Data is updated, the respective LastUpdateDate (LEI Record\nor Relationship Records) SHALL be updated with the current date and time as well.\n4.15 LEI Record update — Registration information changes\nThis Use Case only applies where the registration information changes, and the Legal Entity remains\nan operating entity. Usually, this would happen as part of a Legal Entity Event (e.g.: legal form\nchange), but the registration information change does not trigger a Legal Entity Event itself.\nThe LEl issuer:\no SHALL update lei:RegistrationAuthority accordingly, following the general rules for Registration\nAuthority Reporting (see section 2.2.3).\no SHALL check, if an update to lei:ValidationAuthority, lei:ValidationOtherAuthorities and/or\nlei:ValidationSources is required.\nThis also includes cases where a non-reserved Registration Authority code is supplied for the first\ntime (see section 2.2.3 for the Transition Rules after an RA list update).\n4.16 LEI Record update — Reporting Exception changes to\nRelationship Records\nThis Use Case applies where the child Legal Entity reports a parent Legal Entity after initial opt-out\nreporting.\nThe LEl issuer:\no SHALL create the applicable Relationship Record(s) according to Use Cases 4.1.1 and/or 4.1.2.\ne SHALL remove the superseded reporting exception record(s) from publication.\nIf the ExceptionReason was NO_LEI, Use Case 4.11 applies instead.\nState Transition and Validation Rules for Common Data File formats Page 162 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2153,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.686Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.17 LEI Record Set update — Entity or Relationship Data changes\n\nThis Use Case applies where any data element in the entity data or the Relationship data or a\n\nreporting exception changes that is not the result of one of the other Use Cases (usually, this is only\n\nnecessary to amend registration or validation errors).\n\nThe LEl issuer:\n\ne SHALL update the respective data element(s) accordingly.\n\ne SHALL not make any additional changes, except for updating LastUpdateDate.\n\n4.18 LEI Record Set update — Change of fund manager\n\nThis Use Case applies when the management of a fund entity changes from fund manager with LEI A\n\nto fund manager with LEI B and the fund entity itself is still active.\n\nThe LEl issuer:\n\ne SHALL set the rr:RegistrationStatus of the fund relationship record with EndNodelD LEI A to\nRETIRED. The EndDate of the RelationshipPeriod with PeriodType RELATIONSHIP_PERIOD SHALL\nbe the date of the change.\n\ne SHALL introduce a new fund relationship record with rr:RegistrationStatus PUBLISHED with\nEndNodelD LEI B. The StartDate of the RelationshipPeriod with PeriodType\nRELATIONSHIP_PERIOD SHALL be the date of the change.\n\n4.19 LEI Record Set update — Transfer\n\nA Legal Entity's LEI Record can be transferred from one LEl issuer to another. All Relationship Records\n\n(active and inactive) are also transferred. The following sections describe the updates to the LEI\n\nRecord Set only. For details on timelines and responsibility, refer to the Supporting Documentation\n\nfor Transfers.\n\nIn general, only LEI Record Sets representing operational Legal Entities can be transferred\n\n(RegistrationStatus ISSUED or LAPSED). In rare cases, LEI Record Sets representing inactive Legal\n\nEntities (RegistrationStatus RETIRED) and even invalid records (RegistrationStatus DUPLICATE or\n\nANNULLED) will transfer from one LEl issuer to another. In such cases the Receiving LOU should\n\nprovide an explanation to the Sending LOU (e.g.: the closure of one LEl issuer).\n\nA transfer is initiated after the request from the Legal Entity by the Receiving LOU. The Receiving LOU\n\ninforms the Sending LOU about the transfer request, providing evidence for the authorization of the\n\nrequestor. The Sending LOU confirms the transfer with their contact to the Legal Entity. If no\nresponse from the Legal Entity can be received within the timeframe defined in supporting transfer\nprotocol documentation, the Sending LOU SHALL accept the transfer request.\nState Transition and Validation Rules for Common Data File formats Page 163 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2632,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.686Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Sending LOU Perspective:\n\nWhen the Sending LOU receives the transfer request, the LEI Record Set is updated as follows:\n\no lei:RegistrationStatus SHALL be PENDING_TRANSFER.\n\no rr:RegistrationStatus SHALL be PENDING_TRANSFER for all Relationship Records.\n\nWhen the Sending LOU confirms the transfer request and verifies that the updated\n\nRegistrationStatus is displayed in the Golden Copy, the LEI Record Set is updated as follows:\n\no lei:RegistrationStatus SHALL be PENDING_ARCHIVAL that was PENDING_TRANSFER before.\n\no rr:RegistrationStatus SHALL be PENDING_ARCHIVAL for all Relationship Records that were\nPENDING_TRANSFER before.\n\nThe Sending LOU verifies in the Golden Copy Files, generated by GLEIF, that its own LEI Record Set is\n\ndisplayed as PENDING_ARCHIVAL. After the Receiving LOU’s LEI Record Set is published in the Golden\n\nCopy, the Sending LOU updates their LElI Record Set as follows:\n\no lei:RegistrationStatus SHALL be TRANSFERRED that was PENDING_ARCHIVAL before and\nremoved from files uploaded to GLEIF.\n\no rr:RegistrationStatus SHALL be TRANSFERRED for all Relationship Records that were\nPENDING_ARCHIVAL before and removed from files uploaded to GLEIF.\n\ne All remaining Relationship Records and all Reporting Exception Records are removed from files\nuploaded to GLEIF.\n\nReceiving LOU Perspective:\n\nThe Receiving LOU validates all LEI Reference Data during transfer and once the Sending LOU\n\npublishes the LEI Record with RegistrationStatus PENDING_ARCHIVAL, the Receiving LOU SHALL\n\npublish a complete set of entity and relationship data, including historical and/or internal\nrelationships:\n\no lei:RegistrationStatus SHALL be ISSUED, unless, in very rare cases, the LEI Record was RETIRED,\nDUPLICATE or ANNULLED prior to the transfer request, in which case, the original\nRegistrationStatus is retained; the Receiving LOU SHALL NOT publish the LElI Record with\nRegistrationStatus LAPSED after the transfer is completed, even if that was the recorded status\npublished by the Sending LOU. All LAPSED LEIs SHALL be renewed during transfer.\n\nState Transition and Validation Rules for Common Data File formats Page 164 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2241,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.686Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o rr:RegistrationStatus SHALL be PUBLISHED for all ACTIVE Relationship Records; INACTIVE\nRelationship Records that were ANNULLED by the Sending LOU are retained with the\nRegistrationStatus they had prior to the transfer; the Receiving LOU SHALL keep historical\nRelationship Records unchanged except for amending data quality issues (e.g.: due to missing\nRelationshipPeriods).\n\no InitialRegistrationDate for all LEI Record Sets SHALL NOT be updated but retained as it was\nbefore the transfer (adapting to a different time zone is accepted but not required).\n\nFigure 10 further clarifies the transfer protocol. Each row represents a time unit, e.g., one business\n\nday.\n\nState Transition and Validation Rules for Common Data File formats Page 165 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":852,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.686Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Receiving LOU Sending LOU\nInitiation of Transfer\nThe Legal Entity informs its new\nmanaging LOU (Receiving LOU)\nrequesting a transfer. The LOU O\ncontacts the current managing LOU [RSUET, LACRED]\n(Sending LOU) and triggers a LEIA\ntransfer.\nO\\ PENDING_\nLEIA TRANSFER\nThe Sending LOU sends confirmation of the\nLEI Transfer request back to the Receiving\nLOU. The Sending LOU notifies the Legal\nEntity that the transfer will occur after 3\nbusiness days, if no objection is received.\nThe Transfer Objection Form is attached to\nthe notification.\nO\\ PENDING_\nLEIA ARCHIVAL\nThe Sending LOU receives\nconfirmation from the Legal Entity or\nthe Legal Entity has not responded\nwithin 3 business days.\nLEIA\nO\\ PENDING _\nThe Receiving LOU validates the LEIA ARCHIVAL\nmost recent data of the LEI Record\nSet and publishes the record.\nThe Sending LOU stops publishing\nthe LEI Record Set after the LEI\nO— Record Set appears in the Golden\nLEIA Copy Files generated by GLEIF with\nManagingLOU = Receiving LOU.\nTransfer Completed\nFigure 10: Exemplary timeline of an LEI transfer\nState Transition and Validation Rules for Common Data File formats Page 166 of 170\nGLEIF) Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1243,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.686Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.20 Registration errors — Exclusivity Violation (duplication)\nIf a Legal Entity has more than one LEI, the Legal Entity SHALL choose which LEI Record Set survives.\nIf the contact point for both LEls is non-responsive, then the earliest LEI survives. The DUPLICATE\nstatus is assigned to the non-surviving registration (i.e. the LEI that should no longer be used).\no lei:RegistrationStatus SHALL be DUPLICATE\ne SuccessorLElI SHALL be the LEI of the surviving registration\no for Branch entities, the survivor SHALL be another Branch entity in the same host jurisdiction; if\nthe Branch entity was registered in the same jurisdiction as the head office, lei:RegistrationStatus\nSHALL be ANNULLED instead (see Use Case 4.17 Registration error — Eligibility violation)\no rr:RegistrationStatus SHALL be ANNULLED for all relationships\nIf a parent Legal Entity (i.e.: the entity represented by the EndNodelD of a Relationship Record) is a\nduplicate, the LEl issuer of the child Legal Entity adjusts all not ANNULLED Relationship Records with\nthis parent Legal Entity as EndNote as follows:\no rr:RegistrationStatus of existing Relationship Records SHALL be ANNULLED\n¢ new Relationship Records SHALL be created with the surviving parent Legal Entity’s LEIl as\nEndNodelD\n4.21 Registration error — Relationship Record or reporting exception\nis a duplicate\nA child LEI record SHALL have only a maximum of one relationship data set of each type at a time. If\nthere is more than one published at the same time, duplicate Relationship Records exist. There are\nthree ways, duplicate Relationship Records can be introduced:\n* More than one ACTIVE Relationship Record with the exact same StartNode, same\nRelationshipType but different EndNodes are published, or\n* More than one Relationship Record with the exact same StartNode, same RelationshipType,\nsame EndNode and same StartDate for PeriodType RELATIONSHIP_PERIOD is published.\ne One ACTIVE accounting consolidation parent relationship is published together with a\ncorresponding reporting exception for the same parent (direct/ultimate).\nState Transition and Validation Rules for Common Data File formats Page 167 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2256,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.686Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"For the first case, the LEl issuer SHALL determine which Relationship Record is correct currently; all\nother duplicate records need to be set either to INACTIVE, if they represent no longer current\nrelationships, or to ANNULLED, if they were created erroneously.\n\n4.22 Registration error — Eligibility violation (invalid LEl issuance)\n\nIf an LEI registration is identified as erroneous or invalid after it is issued, the LEl issuer SHALL set the\n\nrecord to an ANNULLED state but keep it as published records in the Global LEI System to support the\n\nhistorical record and to provide resolution to any external query of the LEI. If the record represented\n\na parent Legal Entity (i.e.: is the EndNode in a Relationship Records), the LEl issuer of the child Legal\n\nEntity SHALL update all affected relationships as if the parent were a duplicate (see section 4.20).\n\n4.23 Issue New LEI for an US company incorporated in one state but\n\noperating in another\n\nIn the US, the state where a company is incorporated may not necessarily be the state where the\n\ncompany has its main base of operations. When a Legal Entity incorporated in the US is requesting a\n\nnew LEI code, in addition to or differing from section 4.1, the LEl issuer:\n\nSHALL validate and publish at least the following:\n\no RegistrationAuthority SHALL be the register where the entity is incorporated.\n\no Legallurisdiction SHALL match with the state of incorporation.\n\no EntityLegalFormCode SHALL match with Legallurisdiction.\n\no LegalAddress SHALL be the address displayed in the RegistrationAuthority.\n\ne HeadquartersAddress SHALL be the main location of business operations.\n\no If the entity is registered with a business name or as a foreign company in the state where the\nheadquarters are located, this registration SHALL be included in the ValidationAuthority or in\nOtherValidationAuthorities.\n\n¢ ValidationSources SHALL be FULLY_CORROBORATED, if all relevant elements can be\ncorroborated via the provided ValidationAuthority and OtherValidationAuthorities; it SHALL be\nPARTIALLY_CORROBORATED if not all relevant elements can be corroborated.\n\nState Transition and Validation Rules for Common Data File formats Page 168 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2292,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.689Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.24 Issue New LEI - Financial institution in the US\n\nBanks, credit unions, and other financial institutions in the US can be chartered on a state level or on\n\na federal level and are subject to regulations and supervision from multiple governmental\n\nauthorities. When a new LEl is requested for financial institution in the US (e.g., National Banks and\n\nFederal Savings Associations, State Banks, Credit Unions, Bank Holding Companies, Edge Act\n\nCorporations), in addition to or differing from section 4.1, the LEl issuer:\n\no SHALL consult the FDIC’s “BankFind Suit”, the FFIEC’s NIC institution search, the OOC's list of\nfinancial institutions, or the NCUA’s “Research a Credit Union Tool” and determine if the LEI\napplicant is a National Bank, Federal Savings Association, Federal Credit Union, or a state-\nchartered institution.\n\nIf the LEl applicant is chartered on a federal level, following rules apply:\n\no Legallurisdiction SHALL be US.\n\no EntityLegalForm SHALL be an ELF code assigned on federal (US) level representing the respective\ntype of financial institution (e.g., “62VJ” for National Bank).\n\no The LEl issuer SHALL determine under which authority the entity is chartered and populate the\nrespective RA code as RegistrationAuthoritylD\n\no RegistrationAuthorityEntitylD SHALL be the local identifier representing the entity; it SHALL be\nthe ‘native’ identifier assigned by that authority (e.g., the OCC’s charter license number) as some\nalso provide identifiers assigned by other authorities (e.g., FDIC certificate number).\n\n¢ ValidationAuthoritylD SHALL be one of the authorities consulted to determine that the entity is\nfederally chartered (FDIC, OCC, FFIEC, or NCUA). Having a different authority than in\nRegistrationAuthoritylD MAY support the identification of potential duplicates.\nValidationAuthorityEntity|D SHALL be the ‘native’ entity identifier assigned by that authority.\n\no OtherValidationAuthorities MAY be included to refer to further authorities (e.g., local business\nregister) used for the corroboration of the reference data.\n\nIf the LEIl applicant is chartered on a state level, the following rules apply:\n\no Legallurisdiction SHALL be the state where the state-chartered institution is chartered.\n\no EntityLegalForm SHALL be the Legal Form code that best describes the nature of the financial\ninstitution using the relevant ELF codes for that state.\n\no The LEl issuer SHALL determine under which authority the entity is chartered and populate the\nrespective RA code as RegistrationAuthoritylD\n\no RegistrationAuthorityEntitylD SHALL be the local identifier representing the entity; it SHALL be\nthe ‘native’ identifier assigned by that authority.\n\nState Transition and Validation Rules for Common Data File formats Page 169 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2866,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.689Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"¢ ValidationAuthoritylD SHALL be one of the authorities consulted to determine that the entity is\nstate-chartered (FDIC, OCC, FFIEC, or NCUA). ValidationAuthorityEntitylD SHALL be the ‘native’\nentity identifier assigned by that authority.\ne OtherValidationAuthorities MAY be included to refer to further authorities (e.g., local business\nregister) used for the corroboration of the reference data.\nState Transition and Validation Rules for Common Data File formats Page 170 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":582,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.689Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Figure 2: Examples for level 2 declaration within an LEI Record Set - a) describes the expected Use Case of an LEI A\ndeclaring two different LEls as direct and ultimate parent; b) LEI A declares same LEI B as direct and ultimate parent by\nproviding two separated Relationship Records; c) LEI A declares an LEI B as direct parent and an exception (e.g., NO_LEI)\nfor its ultimate parent relationship; d) LEI A declares two exceptions.\nA child Legal Entity SHALL never have an accounting consolidation parent or branch relationship with\nitself; the LEI identifying the parent must be different from the LEI identifying the child entity.\nReporting accounting consolidating direct and ultimate parent is mandatory for all Legal Entities with\nthe exception of branches (see below). In cases where the Legal Entity has declined to provide the\nmandatory reporting of a specified type of relationship information (direct or ultimate parent), the\nreason is explicitly declared in relationship Reporting Exception Record. This information is reported\nat the time of LEl Issuance, LEI Renewal, or LEl Transfer, whichever happens first.\nExceptions are reported as provided by the Legal Entity. The LOU creates a reporting exception\ninstead of a Relationship Records. The LOU SHALL remove the exception record given:\no the child subsequently reports the respective direct or the ultimate parent.\n¢ the child entity subsequently ends (LEI RegistrationStatus of RETIRED, ANNULLED, or DUPLICATE).\no after a transfer to another LOU has been completed.\nException reason reporting\nIn the case that a Legal Entity is aware that it has a relationship of the relevant type but withholds\nthe details due to legal concerns, the Legal Entity SHALL provide an opt out reason NON_PUBLIC.\nReasons are recorded in a manner specified by the LEI-ROC and reported in the Reporting Exception\nRecords file. No relationship information SHALL be recorded by the LEl issuer. The opt out reason is\ncollected as part of the LEl Record of the reporting entity. As noted by the LEI-ROC, it would be the\nprerogative of any competent regulator requiring this information to determine whether the opt out\nwas justified.\nNon-consolidating exceptions have one of the following reasons: NATURAL_PERSONS,\nNON_CONSOLIDATING or NO_KNOWN_PERSON. This group of exceptions can only be assigned to\nboth parents or to neither of them and never in combination with an active relationship or another\nexception reason indicating that an unreported accounting consolidation relationship exists.\nNo parent according to the definition used\nIf the Legal Entity reports that it has no accounting consolidating parent relationships, this\ninformation is collected and reported in the Reporting Exception Records file.\nParent without LEI\nIn the case that one or both Relationship Records include a parent without an LEl, this information is\nalso reported in the Reporting Exception Records file for publication.\nState Transition and Validation Rules for Common Data File formats Page 18 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":3128,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.689Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Resolving parentage conflicts\n\nParentage conflicts describe situations where the reported relationship information for direct and\n\nultimate parent is not consistent with the definition of parent relationships based on accounting\n\nconsolidation or if the declared ultimate parent is not a viable candidate for being an ultimate\nparent.\n\nCommon reasons for inconsistent information:\n\no Declared ultimate parent has parents: the ultimate parent has public parent relationships.\n\no Declared ultimate parent has incorrect exceptions: the ultimate parent SHALL have exactly 2\nexceptions — one for its direct and one for its ultimate parent — with proper exception reasons\n(NATURAL_PERSONS, NON_CONSOLIDATING, NO_KNOWN_PERSON). Reporting Exception\nRecords with other reasons are inconsistent to being declared as an ultimate parent.\n\no Declared ultimate parent has at least one public Reporting Exception Record with reason NO_LEI.\n\no Declared ultimate parent is inactive, or LEl record is invalid: the RegistrationStatus of the\nultimate parent's LEl record is RETIRED, MERGED , DUPLICATE or ANNULLED.\n\no Declared ultimate parent is an International Branch: the ultimate parent can never be defined as\na BRANCH.\n\nIn case of inconsistent information, the LEl issuer SHALL confirm the relationship information of the\n\nLEI record managed by them (can be the child Legal Entity, the declared ultimate parent or both).\n\nThis also can involve contacting the involved Legal Entities but the most up to date consolidated\n\nfinancial statements remain the primary source for validating Level 2 data. If the current information\n\nis found to be incorrect, the LEl issuer SHALL update the relationship information accordingly. If the\ncurrent information is confirmed as correct, the LEl issuer SHALL approach the other LEl issuer(s)\ninvolved by raising a challenge and providing evidence of how the data should be corrected. At this\nstage, the LEl issuer MAY publish the record even if the parentage conflict has not been resolved.\n\nChallenges MAY be raised using GLEIF's Challenge Facility integrated in LEI Search on GLEIF website?.\n\nThe other LEl issuer then re-validates their record(s) and responds to the challenge accordingly. If the\n\nchallenge is not accepted, both LEl issuers need to discuss this matter further with all involved\n\nparties.\n\nBranch relationships\n\nBranches are part of the same legal person as their head office, and can be described as different\n\nestablishments, or locations, of the same corporate entity, whereas a Subsidiary is a legal person\n\ndistinct from its parent. However, International Branches may have independent requirements for\nregulatory reporting and are therefore eligible for their own LEls. A Branch relationship describes the\nrelationship between an International Branch and its head office. The Branch LEI MAY represent\n\n2 https://search.gleif.org/\n\nState Transition and Validation Rules for Common Data File formats Page 19 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":3061,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.689Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"multiple offices or locations of a Legal Entity in a host country jurisdiction. The Legal Entity SHALL\n\nprovide the address information and additional Reference Data of the Branch. A Branch SHALL NOT\n\ndeclare a direct or ultimate accounting consolidating parent relationship or report exceptions.\n\nFund relationships\n\nFor Fund entities the following three relationship types are available (see section 3.50):\n\n¢ Fund Management Entity: A Legal Entity that is considered as the main management entity of a\nfund when it is legally responsible for the constitution and operation of the fund. Such\nresponsibility will include the day-to-day management of a fund's investments and management\nof a fund’s risks, or the appointment of others for that purpose. In the latter case, the entity to\nwhich these functions may have been delegated is not considered to be a Fund Management\nEntity. The Fund Management Entity can be the fund itself, if the fund is self-managed. In this\ncase there MAY be a relationship for which StartNode and EndNode are populated with the LEI of\nthe fund.\n\no Umbrella Structures: An Umbrella Structure is a Legal Entity with one or more than one sub-\nfunds/compartments where each sub-fund/compartment has its own investment objectives,\nseparate investment policies and strategies, segregation of assets, separate investors and which\nhas segregated liability between sub-funds/compartments. U.S. Series Funds and Japanese “non-\ninvestment management funds” are to be identified as Umbrella Structures in the Global LEI\nSystem.\n\no Master-Feeder: A relationship, where a Feeder Fund is exclusively, or almost exclusively, invested\nin a single other fund (e.g., U.S, EU UCITS), or several funds that have identical investment\nstrategies (for the latter, provided this situation is qualified as a Master-Feeder Relationship\nunder the applicable laws and regulations, e.g., some alternative investment funds in the EU)\nreferred to as a Master Fund (or Master Funds). It is clarified that this covers only cases where\nthis relationship is organized in the legal documentation of the feeder fund and does not cover\nrelationships where a fund’s assets are invested in multiple other funds (fund of fund structure).\n\nThe collection of new fund relationships in the Global LEI System SHALL be mandatory:\n\na) If the relationship is mandated to be reported and publicly available in the relevant\njurisdiction AND if the LEl is mandatory for the related entity in the relevant jurisdiction\n\nb) For the relationship between an Umbrella Structure and a sub-fund or compartment or other\nsub-structure.\n\nIn all cases where a fund relationship is reported, StartNode and EndNode of the relationship SHALL\n\nbe LEI codes.\n\nState Transition and Validation Rules for Common Data File formats Page 20 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2906,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.690Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.12 Transliterated Other Entity Names.....cccccevvvviiieiiinniiiiiieeccciiiece e ssssiieeeeen 44\n3.13 Legal AQAIESS ...vvuieeeiiiieeeeereiiitte e srte e etrrr e e s e ssrire e ee s s s saibeaae e s s sananeeessnsnnneeaesenes 4D\n3.14 Headquarters AdAreSS ......ccuvuviieeiiiiiiiieeeesiiiieee e esssiieeeessssiiesesessssnnseesssssssnseeessnns 40\n3.15 Other AdAreSSES ..ceeivviieeee ittt eeesie e e e s esssireeee s sasieeae e s s snnaneeessnsnsnseeessnsn BT\n3.16 Transliterated Other Addresses.......cvviviviiiiiviiee e essiieee e seveeeessssnnneee e 47\n3.17 Registration AULNOIILY ..ccciiiiiiiiieiiiiciiiececie e ssnnneee e 48\n3.18 Registration AUthOrIty ID ...cccvveiiiiiiiiiieeie e e s ssnnneee e 49\n3.19 Other Registration AUthOrity ID.......cccceeeviiiiiiiee s ssieneee 0. 49\n3.20 Registration Authority Entity ID......cccccveiiiiiiiiiiie i ceciieeee s esiiieeeessssiiieeeeeen. D0\n3.21 Legal JUriSAICTiON ...cicciiieeie ettt s ee s eee e s s sraae e essssnnneeesenes DL\n3.22 ENTitY Cat@OrY ettt ettt e e e e e e e e eeereaesne e s D2\n3.23 ENtitySUDCAtEEOIY .uuiiiiiii ittt ettt ee s e ae e s s state e eessnaaeeeeenes DD\n3.24 Legal FOIM ciiiiiiiiee ettt ette e e rrae e e s e srabe e ae s s s sasbaaeeesssannanesessnnnsssenessnes DT\n3.25 ENtItY STAtUS .cuieiiiie ettt te e e s aaaeeeeenes DO\n3.26 Entity Creation Date ...ttt DO\n3.27 SUCCESSOr ENTItY oot e s e eeeeeeeeeeeesnen OO\n3.28 Legal ENtity EVENTS ..cccvveiiii ittt sttt e esiieeee s siiieeae e s s snaneeesssnnnneaesanns O\n3.29 Legal ENtity EVENT oottt ee s siie e s srane e e s ssnaaeee e enes O2\n3.30 Legal ENtity EVENT TYPE .ciiiiiiiiiiiieieeciiieeeecriiieee s es e ee e s srae e e e s sssnneeeessssssnnaeaen e O4\n3.31 Legal Entity Event Effective Date.......cccceevevivieee it ssiiaeee 0000, 06\n3.32 Legal Entity Event Recorded Date........ccccoeviiieeeiiiiiieeie s ensiieeie s sevieeesssinieee e 07\n3.33 Validation Documents (context: LEI-CDF).......ccccceevviieeeiiieeeceeeessiieesvee e siieeeennn 67\n3.34 Validation Reference (context: LEI-CDF)......ccccccveiiviieeiiiiieeecieee e e esiee e eeiieeennn. 68\n3.35 Affected FIEldS ..uuiiii ittt ssrreeee a0 D8\n3.36 Affected Field. ... e s s naeeee e enes 0O\n3.37 Initial Registration Date (context: LEI-CDF) ........cccovvveeeiviieeecieeeeesivieesceeeesiieenennn 71\n3.38 Last Update Date (context: LEI-CDF)......cccccveeeieeeriiieeeiiiieeeciieeessiiesessveeesveeeesnnnn 71\n3.39 Registration Status (context: LEI-CDF) ..c.covvveeiiieeiiiieecciee e sevieee s 72\n3.40 Next Renewal Date (context: LEI-CDF)....ccccuueeeieeeiiiieeciiiieeciieee e e esvee e svvveeeennnn 72\n3.41 Managing LOU (context: LEI-CDF)....ccccviiiiiiie e ccieeesstee s eeeee s svieeessvaee e 73\n3.42 Validation Sources (context: LEI-CDF)......ccccueveiiiieeciieeeciieeesiiee e eeeeeesieessssineeennn 73\n3.43 Validation AULNOIItY......ceiiiiiiiiiec e ee s seanneee e 1\n3.44 Validation AUthOFItY ID ....ccooveiiiieiiiciiiiecce e erae e ssvreeee s snvnnneeenn 1\n3.45 Other Validation AUthOrity ID.....ccooviiiiiiiiiiiiece et ssivveee e e 1D\n3.46 Validation Authority Entity ID.....ccooviiiiiiiiiiiiiece et seeve e sieaeee a0 10\n3.47 Other Validation AUthOIItIES.......coviviiiiiiiiiiiieee et ssiaaeee e 10\n348 STArt NOGE....eieiieie et srire e ee s s s saaieae s e s s sanaaeeessnnsnneaessnes 1T\nG State Transition and Validation Rules for Common Data File formats Page 3 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":3461,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.690Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"The reporting of the Umbrella Structure MAY be triggered by the umbrella entity as well as by its\ncompartments or sub-funds. However, the relationships are then technically recorded following the\nexisting approach of bottom-up declaration (see section 3.50).\nParent reporting for Government Entities\nGeneral Government Entities are related to each other in the sense that all of them belong to the\nGovernment sector. However, there is no “control” of one Government Entity over another in the\nmeaning attributed to “control” in the IFRS or US GAAP. The consolidation procedures may be quite\ndifferent among government entities and the standards used to identify parent relationships\nbetween general entities would not apply. Government entities that are controlled by another\nGovernment Entity SHALL declare parent relationships according to the usual Global LEI System rules\nbut are likely to use specific accounting standards — GOVERNMENT_ACCOUNTING_STANDARD.\nIn the cases that the parent is unknown, the existing relationship exception for\n“NO_KNOWN_PERSON“is to be used.\n2.2 Corroboration of LElI Record Set\n2.2.1 LEI Registration\ne The process by which Legal Entities are issued LEls and the corresponding Reference Data is\nadded and published in the Global LEI System after successful Validation.\no Asageneral rule, only active Legal Entities can request an LEI.\n° When the LEl is initially issued, the RegistrationStatus SHALL be ISSUED and EntityStatus SHALL\nbe ACTIVE.\n¢ Inrare cases, a regulatory framework may require that inactive entities that do not have an LEI\nneed to be identified with an LEI. Then the LEIl record MAY be issued initially with\nRegistrationStatus RETIRED and EntityStatus INACTIVE.\no If a Legal Entity has (a) parent(s) according to the definitions described above, (a) Relationship\nRecord(s) SHALL be published.\n¢ Only relationships that are active by the time of the registration SHALL be recorded.\nRelationships that ended prior to the initial registration SHALL be excluded.\n* When a Legal Entity cannot provide information on its direct and/or ultimate parents, a\nReporting Exception Record SHALL be published instead.\no The Reporting Exception Record includes the applicable reason for not providing (a) Relationship\nRecord(s). If the reason changes over time, the Reporting Exception Record SHALL be updated.\nState Transition and Validation Rules for Common Data File formats Page 21 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2534,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.690Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"2.2.2 Validation\n\nThe LEI Reference Data includes all elements of an LEI Record that describe the Legal Entity itself and\n\nall of its relationships. The LEI Registration details that describe the state of the LEI Record itself are\n\nnot part of the LEI Reference Data.\n\nThe Legal Entity is responsible to supply its Reference Data when a new LEl is requested. The LOU\n\nverifies the existence of the Legal Entity and the Reference Data based on reliable public sources,\n\nprimarily the sources as mentioned on the RA list. If the data is not available from public sources,\nthen the data MAY be provided by the Legal Entity. Available information from the authoritative\nsource used for Validation SHALL be entered in ValidationAuthority. If more than one authoritative\nsource was used, OtherValidationAuthorities SHALL be populated with information from additional\nsources.\n\ne The LElissuer is responsible for validating and verifying the Reference Data of the LEIl Record,\nusing public (RA) sources where available and relying on entity supplied documents, if no public\nsource can be consulted.\n\no The LEl issuer also is responsible to validate any changes and updates to LEI Records.\n\no The LEl issuer SHALL note the level of Validation in the Reference Data via the element\nValidationSources.\n\no If public sources from the RA list were used to validate the LEI Reference Data, ValidationSources\nSHALL be either FULLY_CORROBORATED, if all LEI Reference Data can be verified, or\nPARTIALLY_CORROBORATED, if only some of the LEI Reference Data can be verified.\n\no If public sources from the RA list were used to validate the LEI Reference Data and all data apart\nfrom the postal code and region can be verified using the public sources, the LEl issuer SHALL add\nthe postal code and region information and ValidationSources SHALL be FULLY_CORROBRATED,\nas the postal code and region are a derivative of the verified address.\n\no If the Validation relies on sources provided by the Legal Entity or other sources not included in\nthe RA list, ValidationSources SHALL be ENTITY_SUPPLIED_ONLY.\n\n* Insome jurisdiction, Government entities are not registered by any Registration Authority.\nHowever, the Government Entity is established by a public legislation or statute, that can be\nreferred to for corroboration. If such public legal document is the source used for corroboration,\nValidationSources SHALL be FULLY _CORROBORATED, if all data elements could be corroborated\nfrom the document, or PARTIALLY_CORROBORATED, if some data elements could be\ncorroborated. Using such documents for validation of unregistered Government entities SHALL\nbe the preferred validation process compared to relying only on entity supplied information.\n\no If ValidationSources is PENDING, the LEI Record SHALL NOT be published and is for the LEI\nissuer's internal use only.\n\no The same authoritative source SHALL NOT appear more than once in ValidationAuthority and/or\nOtherValidationAuthorities but one of the sources MAY be the same as RegistrationAuthority.\n\nState Transition and Validation Rules for Common Data File formats Page 22 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":3213,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.690Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o OtherValidationAuthorities SHALL NOT include RA999999 (see chapter 2.2.3) as\nValidationAuthorityID.\n\no OtherValidationAuthorities MAY contain additional information about an authorititative source\nand local identifiers, in order to enrich the LEI Record Set and support verification by a third\nparty, the public or just to enhance and enable a mapping exercise.\n\no If the Legal Entity has declared relationships, the LEl issuer is responsible to validate that the\nrelationship between the two Legal Entities exists.\n\no The LElissuer is responsible for validating that the LEl presented in an EndNode of a relationship\nindeed represents the Legal Entity declared in the documents used for validating the\nrelationship.\n\ne The LElissuer is not responsible for validating Reporting Exception reasons reported.\n\ne The LElissuer is not responsible for validating a Legal Entity’s statement that there is no parent\naccording to the accounting consolidating definition used but SHALL respond to any challenges to\nthat status.\n\no The LElissuer is not expected to validate the Reference Data associated with the LEI presented as\nEndNode unless the LEl issuer is also the LEl issuer of the EndNode’s LEI Record Set.\n\ne The LElissuer is responsible for ensuring that a relationship is made to an active entity. This\nmeans the parent LEI should not have a RegistrationStatus of DUPLICATE, RETIRED, MERGED , or\nANNULLED at the time of the initial Relationship Records issuance. Rare cases, where an LEl is\nissued initially to an inactive entity are exempted from this rule.\n\no The LEl issuer SHALL accept or deny a Relationship Record based on the result of its Validation.\n\no The LEl issuer SHALL revalidate the complete LEI Reference Data at each renewal. When LEI\nReference Data is updated (e.g.: by the Legal Entity or due to a challenge), the updated data\nSHALL also be validated.\n\nPrimary sources are required for the Validation of accounting consolidating parent relationships.\n\nThese include only the following documents:\n\n1. Consolidated financial statements are a key source to validate parent relationships. Such reports\nmay be prepared and submitted to the relevant authority quarterly or annually or attested to by\na third-party auditor and not submitted to an authority.\n\n2. Regulatory filings (i.e., reports to a securities regulator or a bank supervisor) are another\nimportant source. When validating using a regulatory filing, the filing name must be provided (as\nwell as the path if available). Best practice would be to include the Digital Object Identifier (DOI)\nof the document.\n\n3. Other types of allowable sources include other documents supporting the preparation of\nconsolidated financial statements, contracts, and other official documents.\n\nState Transition and Validation Rules for Common Data File formats Page 23 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2939,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.692Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Proprietary products containing secondary data derived from a variety of sources are not considered\nas valid sources for Validation of relationship data. Only an original source of the above-mentioned\nquality is acceptable. The level of corroboration depends on the sources used for Validation:\n\n¢ The ValidationSources of a Relationship Records is FULLY _CORROBORATED if\no (i) there are consolidated financial statements, other documents supporting the preparation\n\nof consolidated financial statements coming from or otherwise confirmed by the external\nauditor, or regulatory filings\n\ne AND (ii) these documents establish the consolidation relationship and mention the name of\nboth related entities.\n\no The ValidationSources of a Relationship Record is PARTIALLY_CORROBORATED, if\no (i) the definition of parent used in regulatory filings differs from the accounting consolidation\n\ndefinition, but filings assist in corroborating the information provided by the child Legal\nEntity that the conditions of consolidation are met. Only accounting consolidation\nrelationships are expected to be reported and the LEl issuer is not expected to conduct an\nanalysis of differences between the regulatory sources and the accounting standard.\nGenerally, the type of source, or the fact that the source does not refer to accounting\nstandards will inform the LEl issuer that this category should be used;\n\no OR (ii) Official documents such as regulatory filings or contracts make it likely that the\nconditions of accounting consolidation are met, or have ceased to be met, when\nconsolidated accounts reflecting the new situation have not been established yet.\n\n¢ The ValidationSources of a Relationship Records is ENTITY_SUPPLIED_ONLY if\ne (i) the conditions for FULLY_CORROBORATED or PARTIALLY_CORROBORATED would have\n\nbeen met, except that the documents used for Validation are usually not publicly available in\nthe legal jurisdiction(s) of the child and parent Legal Entities;\n\ne AND (ii) the child Legal Entity provided official documents for the purpose of validating the\nrelationship.\n\nFund entities can have fund relationships in addition to the above described accounting consolidating\n\nparent relationships. A fund prospectus would be a good source for validating the different Fund\n\nrelationships:\n\ne Providing prospectus certified by a regulatory authority from GLEIF RA list SHALL be set to\nFULLY_CORROBORATED and the corresponding RA code SHALL be documented in the Validation\nAuthority container.\n\ne Providing prospectus not vetted by any authority SHALL be reported as ENTITY_SUPPLIED _ONLY.\n\nState Transition and Validation Rules for Common Data File formats Page 24 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2779,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.692Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"The Validation Authority of a fund entity SHALL be the financial regulator registering the fund.\n\n2.2.3 Application of GLEIF Registration Authorities List\n\nLEl issuers SHALL ensure the cross reference to the local authoritative source is standardized and\n\nincluded in an LEI record. GLEIF maintains and publishes a list with Registration Authority (RA) Codes®\n\nthat SHALL be used to populate RegistrationAuthoritylD and ValidationAuthorityID. This list includes\nspecific and unique codes for all authoritative sources accepted by GLEIF as well as three reserved RA\ncodes (RA777777, RA888888 and RA999999).\n\nSpecific RA code (not RA777777, RA888888 or RA999999):\n\n» If a specific RA code is available, it SHALL be used in RegistrationAuthoritylD and/or\nValidationAuthorityID.\n\no If RegistrationAuthoritylID is populated with a specific RA code, OtherRegistrationAuthoritylD\nSHALL NOT be provided; the same applies to ValidationAuthorityID and\nOtherValidationAuthorityID.\n\n¢ If ValidationAuthorityID is populated with a specific RA code, ValidationSources SHALL NOT be\nENTITY_SUPPLIED_ONLY.\n\no If a specific code is removed from the RA list, the LEl issuer SHALL update all affected records,\nwith a correct new code within the specified implementation time. The new code SHALL NOT be\nRA888888 with the name of the just removed registration authority as OtherAuthorityID.\n\nReserved RA code RA777777:\n\no The RA code RA777777 is used for General Government Entities and International Organizations\nonly in case there is no information available in any regular registration authority and Public\nLegal Documents are used for validation instead.\n\no If ValidationAuthoritylID is populated with RA777777, OtherValidationAuthoritylD SHALL be\npopulated with the name of the source as free text or if available with the link to the documents\nused for validation.\n\no RegistrationAuthoritylD and OtherRegistrationAuthoritylD SHALL NOT be populated with\nRA777777.\n\no If ValidationAuthorityID is RA777777, the RegistrationAuthoritylD SHALL be RA888888 or\nRA999999 only (please consult Figure 3)\n\n3 https://www.gleif.org/en/about-lei/code-lists/gleif-registration-authorities-list#\n\nState Transition and Validation Rules for Common Data File formats Page 25 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2348,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.692Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o If ValidationAuthorityID is RA777777, ValidationSources SHALL shall be\nPARTIALLY_CORROBORATED or FULLY_CORROBORATED.\n\nReserved RA code RA888888:\n\no The RA code RA888888 is used as an interim code. This indicates that a Registration/Validation\nAuthority is not available on the RA list, but the addition of a relevant source, which could be\nused for the LEl in question, has been requested to GLEIF.\n\no This code SHALL be used only after a request to add a new RA source has been sent by email to\nralist@gleif.org with further description of the source.\n\no All requests for new RA codes (or modifications) are collected over time and processed in time\nfor the periodical publication of a new version of the RA list. The approximate date(s) for the\npublication of a new version are communicated well in advance.\n\n* In cases, where the suggested source has NOT been accepted as authoritative source, the LEI\nissuer needs to provide a new suggestion for a source in order to ensure proper corroboration\nwithin a month, if no other implementation time is defined. If no other source could be identified\nfor Validation and Verification of the Legal Entity and its Reference Data, the correspondent\nfields SHALL be changed to RA999999.\n\n* In cases, where the suggested source has been accepted as an authoritative source, the LEl issuer\nSHALL replace the reserved code with the new code and adjust the corroboration level\naccordingly within the time frame communicated for the implementation of the new version of\nthe RA list.\n\n¢ The reserved code RA888888 SHALL NOT be used for longer than a month after publication of\nthe new version of the RA list which includes the new valid RA code, unless a different\nimplementation time has been defined.\n\no If RegistrationAuthorityID is populated with RA888888, OtherRegistrationAuthoritylD SHALL be\npopulated with the name of the source as free text; the same applies to ValidationAuthoritylD\nand OtherValidationAuthorityID.\n\n¢ The name provided as free text SHALL be the same as used in the request sent to GLEIF to add\nthe source to the RA list.\n\no If RegistrationAuthorityID or ValidationAuthorityID is RA888888, ValidationSources SHALL only be\nset to the lowest corroboration level, namely ENTITY_SUPPLIED_ONLY.\n\nReserved RA code RA999999:\n\ne The RA code RA999999 refers to situations when no Registration Authority can be defined for a\nLegal Entity. The LEl issuers are obliged to use their full efforts and local expertise to ensure that\nthe applicant is an existing Legal Entity and is eligible to obtain an LEl and also document this\ninformation accordingly.\n\nState Transition and Validation Rules for Common Data File formats Page 26 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2789,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.692Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o If RA999999 is used as identifier for the source, the respective EntitylD SHALL NOT be populated.\nPlaceholders like “N/A”, “None”, etc. SHALL NOT be used.\n¢ If ValidationAuthorityID is RA999999, ValidationSources SHALL be ENTITY_SUPPLIED_ONLY.\ne RA999999 SHALL NOT be used in OtherValidationAuthorityID or for records with EntityCategory\nBRANCH.\nFigure 3 below shows the allowed combinations of reserved RA codes for RegistrationAuthoritylD\nand ValidationAuthority ID.\nValidationAuthoritylD\nSpecifc\nRA777777 RA888888 RA999999 ValidationAuthoritylD\nRegistrationAuthoritylD\nSpecific Not ok Not ok Not ok Ok\nRegistrationAuthoritylD ot okay ot okay ot okay ay\nFigure 3: Overview of allowed combinations of reserved and specific RA codes for RegistrationAuthoritylD and\nValidationAuthoritylD\n2.3 Life cycle\nFigure 4 highlights the existing general STVR in the registration status of an LEIl, from its creation in\nthe internal LEl issuer systems until reaching a so-called end state. In addition, the life cycle includes\nand describes the process of transferring an LElI Record Set from one LEl issuer to another.\nThe life cycle is divided into “Internal” states, that are managed by the LEl issuer but not shared with\nthe public, and “Published” states, that are included in the Global LEI Repository. For instance,\nPENDING_VALIDATION is Internal with respect to publication because LEI registrations are expected\nto be fully validated prior to the LEI being assigned, issued, and published. An expected part of the\nlife cycle of an LEl registration is the timely update and periodic Validation of its Reference Data. This\nperiodic Validation needs to be performed at least once a year. If a record is not validated again\nwithin this timeframe, the registration status code will be set to LAPSED, meaning the Validation is\noverdue.\nState Transition and Validation Rules for Common Data File formats Page 27 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2012,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.692Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"1\nPUBLISHED\n- /‘///J>77777\\7\\\nINTERNAL H\nREGISTRATION LIFE CYCLE\n: .\nSTART ISSUING PROCESS TRANSIENT\n\\/ |\n\\ END STATES |\nTRANsFERED]<—1\n\nFigure 4: High-level general representation of the life cycle of an LEI\n\n2.3.1 Registration Status Codes\n\nThe RegistrationStatus operational data element indicates the state that an LEI Record can have over\n\nits life cycle.\n\nThe defined status codes fall into four broad categories:\n\n1. Registration life cycle: These are codes applied in the normal life cycle of an LEl registration from\nsubmission through issuance through the termination of the registration when the entity\nbecomes inactive.\n\n2. Registration Errors: These are codes that are needed to correct errors that may occur in LEI\nregistration process.\n\n3. Transient conditions: These are codes that support certain transient conditions describing the\ntransfer of an LEl registration from one LEIl issuer to another.\n\n4. Deprecated statuses: Values that have been accepted in the past, and due to changes in\nunderlying standards, policies and/or rules, have be amended as invalid or no longer in use.\n\nEach RegistrationStatus code holds information regarding the publication of the LEI Record Set as\n\nshown in below table:\n\ne Published: The LEI Record Set is included in the public files published by the LEl issuer and GLEIF.\n\nState Transition and Validation Rules for Common Data File formats Page 28 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1509,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.692Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"¢ Transient: The LEI Record Set is included in the public file published by the LEl issuer, but only\nduring a record transfer from one LEl issuer to another. It may not be included in files published\nby GLEIF, if the same LEl is already published by another LEl issuer.\n\ne Archived: The LEI Record Set is not included in the public file published by the LEl issuer or by\nGLEIF but is retained by the LEl issuer as part of its archival records.\n\n¢ Internal: The LEI Record Set is not included in the public file published by the LEl issuer or by\nGLEIF but may be exchanged between LEI issuers and/or GLEIF as part of the Validation process\nprior to issuance.\n\no Deprecated: The RegistrationStatus has been deprecated and SHALL NOT be used anymore. LEI\nRecords with this RegistrationStatus MAY appear in historical LEI Record files but have been\nupdated to a different status in current data files.\n\nThe following table categorizes the RegistrationStatusEnum codes:\n\nPENDING_VALIDATION Registration life cycle Internal\n\nISSUED Registration life cycle Published\n\nPUBLISHED Registration life cycle Published\n\nDUPLICATE Registration Errors Published\n\nLAPSED Registration life cycle Published\n\nMERGED Deprecated Deprecated\n\nRETIRED Registration life cycle Published\n\nANNULLED Registration Errors Published\n\nCANCELLED Registration Errors Archived\n\nTRANSFERRED Transient condition Archived\n\nPENDING_TRANSFER Transient condition Transient\n\nPENDING_ARCHIVAL Transient condition Transient\n\nThe value MERGED in the RegistrationStatus field is deprecated with the LEI-CDF 3.1 being effective.\nState Transition and Validation Rules for Common Data File formats Page 29 of 170\n@ Public Version 2.7.1 Final\n\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1764,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.692Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"2.3.2 Changes in Registration Status due to Legal Entity Events\nWhile the RegistrationStatus has information about the LEI Record itself and not necessarily\ndescribes the state of the Legal Entity, some Legal Entity Events also trigger a transition in\nRegistrationStatus. Each of the following events documented with its exact effective date SHALL\nchange the RegistrationStatus of the LEI Record to RETIRED according to the existing rules:\no Liquidation (@event_status COMPLETED)\n¢ Insolvency (@event_status COMPLETED)\no Dissolution of a Legal Entity, including International Branches and Subsidiaries (@event_status\nCOMPLETED)\ne Mergers and Acquisitions (for the Legal Entity which ceases operation as a result of a merger)\nRETIRED is an end state of an LEl Record Set, and an update that assigns this RegistrationStatus code\nto the LEI Record Set is the last regular update that is made to that record. Therefore, the\nEntityStatus and the RelationshipStatus are set to INACTIVE once this end state has been reached. In\norder to satisfy the 1ISO 17442 persistence criteria of the LEI (i.e., the ability to properly interpret\nexisting and historical records and reports that refer to LEls in this state), these LEI Records are still\npart of the published LEI records. The LEI Record Set MAY still be updated to comply with the\nimplementation of new code lists or to amend data quality issues caused by the record. In such cases\nGLEIF needs to be informed about the data updates.\nThe following Legal Entity Events SHALL be documented together with the EffectiveDate of the event\nand SHALL remain in their current RegistrationStatus (expected to be either ISSUED or LAPSED):\n¢ Changeinlegal name (@group_type STANDALONE)\ne Change in trade or doing business name\no Change in legal address\no Change in headquarters address\n¢ Change of legal form\no Demergers and Spinoffs (for the entity that has been demerged or spin off)\ne Absorption\no Voluntary Arrangement\no Acquisition of an international branch (for the branch entity)\no Transformation of an international branch into a Subsidiary (for the entity that has been\ntransformed into a Subsidiary)\ne Transformation of a Subsidiary to an international branch (for the entity that has been\ntransformed into an international branch)\nState Transition and Validation Rules for Common Data File formats Page 30 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2459,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.692Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"349 ENA NOUE ettt ettt e e s s saabn e s e s s snaae e e e s snnnneeesenes 1O\n3.50 RelationShip TYPE cooiiiiiiiei et ae e sraae e s ssnaneeeeenes 1O\n3.51 Relationship PEriods .....ccciiiiiiiiiiiiiiiiiiieeee sttt srne e s sssnieeee s seinneeeeees S0\n3.52 Relationship StAtUS ...uvviiiiiiiiiie e 82\n3.53 Relationship QUAlIfIErS.......ooviuiieiiiiriiiee e ee e e 82\n3.54 Relationship QUaNLIfIErs ......c.uivviiiiiiiiiee e ieee e S\n3.55 |Initial Registration Date (context: RR-CDF).......ccccceeverivriieecicieee e 84\n3.56 Last Update Date (context: RR-CDF) .......ccccveeeiiieiiiiieecriiee e s e sieeee 0000 85\n3.57 Registration Status (context: RR-CDF) .....ccccceeeiieiiiiiieciiiee e 85\n3.58 Next Renewal Date (context: RR-CDF)....ccccveeeuiiieiiieeeiiiee e e seiieeee00. 80\n3.59 Managing LOU (context: RR-CDF) ......cccceeiiiieeiiieeeciies e sstve e e sive e 8 7\n3.60 Validation Sources (context: RR-CDF) .....ccccueeeiieiiiiiieeisiiee e esiie e siveee e 8 7\n3.61 Validation Documents (context: RR-CDF) .......cccceviviiieeiiiiee e s, 88\n3.62 Validation Reference (context: RR-CDF) .......ccccvveeiivieeeiiiiie e ssiee e siieeeen00n 89\n3.63 LEI (context: REPEX-CDF)..ccccciiiecieeeiiieeesitiie e ceeeeesiie e essvee s saee e e s savaesssnee s snnveeesnnee 89\n3.64 EXCePtion CateBOrY ....cooiiiiiiiiiiiiiceee ettt ee e OO\n3.65 EXCePtion REASON....ccoiiiiiiiiiiieeieitie e e e e e s e s e eeeesneenenesnens D0\n3.66 EXCEPLiON RETEIENCE ...uuiiiii ittt srae e ssaaaeee e enes D2\n3.67 Associated Entity — DEPRECATED .......cuvviviiiiiiiieeeeiiiieece s essiieeeeesssneneeesssnnneeeeenns 92\n3.68 Entity Expiration Date — DEPRECATED ......ccoocutiiiiiiiiiiieee s ciiiiieee s essiinneeee e ssnneeee . 93\n3.69 Entity Expiration Reason — DEPRECATED.........ccccvivmiiiiiiiiiieieeeeeeeeeeeeeeeeeeeieiiennnnn. 93\nL ¥ LY - 1 R |-\n4.1 Issue New LEI that is not branch, fund, sole proprietor, government entity or\n\ninternational Organization ........cccvueeeiiiinieeie e 9D\n4.1.1 Relationship with a parent Legal Entity with an LEl.........ccccovvviiiiviiiieiiiniieeeennn.. 96\n4.1.2 Relationship with a parent Legal Entity without an LEl .........cccccceeviviiiiiiinieennnn... 96\n4.1.3 No accounting consolidation parent relationship........cccoccevieviieeiiiiviiniiesieeen e 97\n\n4.1.4 Accounting consolidation parent relationship not reported due to legal obstacles\n(o] 2o 10 1 | TS TS USURORSSPRP < ¥\n4.2 Issue NeW LEI = Branch .......coooviuiiiiiiiiiiiiiee e cssiieie e svveeeee s ssvnneeesssssinnnne s 97\n4.3 Issue NeW LEI = FUNd .....oviiiiiiiiiiiecceciiieece e esieee e svane e e e s ssnnneee s snssannenees 99\n4.4 Issue New LEI —Fund in formation ........cccccevvviiiiiiinniiiienscciieeeesssiiieee e esnnnnnn. 101\n4.5 Issue New LEI —Sole proprietor.....ccccoccvveeeeiiiiieeeeiiisiieeeeesssieeeeeesscveneesssnsnnneees 103\n4.6 Issue New LElI —Government entity........cccceviimimiiiiiiiiiiin e eececccveeeeeeeeen... 103\n4.7 Issue New LEI —International organization .........ccccceeeviveeeiiiiiieeeeeinniiiee e 104\n4.8 LEIRecOrd RENEWAl ..cuvvviiiiiiiiiiiieieeciiiecce et essiieie e sieeeeessssnnseeessnssennnns 10D\n4.9 LEl Record update — Parent Legal Entity without an LEI requests an LEl............106\n4.10 LEI Record update — Relationship Record changes to Reporting Exception .......106\nG State Transition and Validation Rules for Common Data File formats Page 4 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":3466,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.692Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"¢ Umbrella fund changes its structure to a stand-alone fund (for the new stand-alone fund)\n\no Bankruptcy (@event_status IN_PROGRESS)\n\n¢ Liquidation (@event_status IN_PROGRESS)\n\no Insolvency (@event_status IN_PROGRESS)\n\no Dissolution of an entity, including international branches and subsidiaries (@event_status\nIN_PROGRESS)\n\no Break ups (for any part of the original Legal Entity that remains in operation and for any new\nLegal Entities that are formed as part of the terms of the breakup)\n\n2.3.3 Changes in Registration Status when a registration error is resolved\n\nThere are three registration status codes that apply to situations in which a registration assignment\n\nerror has been made: DUPLICATE, ANNULLED, and CANCELLED.\n\no The DUPLICATE code refers to the non-surviving record under an Exclusivity Violation.\n\no The ANNULLED code applied to any other type of assignment error detected after an LEI\nregistration has been publicly issued.\n\no The CANCELLED code refers to any type of assignment error detected before publication.\n\nThese error states are terminal: no further updates to Entity sections of registration records in these\n\nstates SHALL occur. Records in the DUPLICATE or ANNULLED states SHALL be retained as published\n\nrecords in the Global LEI System to support the historical record and to provide resolution to any\nexternal query of the LEI. The LEI Record Set MAY still be updated to comply with the\nimplementation of new code lists or to amend data quality issues caused by the record. In such cases\n\nGLEIF needs to be informed about the data updates. Records with the state CANCELLED SHALL be\n\nretained internally by an LEl issuer to support auditing.\n\n2.4 Registration Status Codes for Transient Purposes\n\nThree registration status codes exist to accommodate the transfer of the management of an LElI\n\nregistration from one LEl issuer to another: PENDING_TRANSFER, PENDING_ARCHIVAL,\n\nTRANSFERRED.\n\no PENDING_TRANSFER and PENDING_ARCHIVAL are used in the transitional period between the\nreceipt of a porting request by a Sending LOU and the final confirmation of the transfer.\n\no The TRANSFERRED code is used in the archival records of a Sending LOU after having successfully\ncompleted the transfer of that responsibility to another (Receiving) LOU. A record in this state is\nnot published but kept internally by the prior LOU for audit trail purposes.\n\nFor a short period of time a given record may appear more than once in a published concatenated\n\nfile. This case occurs at the end of the transfer process, when the Sending LOU publishes their file\n\nState Transition and Validation Rules for Common Data File formats Page 31 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2760,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.692Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"with RegistrationStatus PENDING_ARCHIVAL and the Receiving LOU publishes their file with the\nregistration status ISSUED. The time window for these transient states is limited by a transfer\nprotocol shared between GLEIF and the LEl issuers (see Use Case 4.19). On average, transfers SHALL\nbe completed within five to ten business days.\n2.5 Renewal\nRenewal is the process that triggers the periodic Validation of an LEI Record Set. Renewal is required\none year after the initial registration and every year thereafter. The Next Renewal Date in the\nrecord’s registration section indicates the date when the next renewal is due. If a record is not\nrenewed in due time, the LEl issuer shall validate that the entity is still operating. Given the entity is\nstill operating, the Registration Status SHALL be set to LAPSED and the Next Renewal Date SHALL NOT\nbe updated.\nThe renewal of an LEI Record is initiated by the Legal Entity. The LEIl issuer SHALL inform the Legal\nEntity at least six weeks prior to the next renewal date and remind the Legal Entity to renew the LEI\nRecord Set. Any changes to the LEI Reference Data SHALL be updated by the Legal Entity and\nvalidated by the LEl issuer. After this is completed, the Registration Status remains ISSUED and one\nyear is added to the Next Renewal Date. A LAPSED record MAY be renewed as well and return to an\nISSUED state at any point of time.\n2.6 1SO 3166 Conformance of Address and Jurisdiction Fields\nThe following LEI-CDF data fields must contain current, valid ISO 3166 country (or region, where\napplicable) codes taken from the ISO 3166 code lists. The XML schema for the LEI-CDF validates only\nthe format (pattern) of these fields, not the specific codes used.\no CountryCode in all addresses\no RegionCode in all addresses\no Legallurisdiction\nThe RegionCode SHALL be an ISO 3166-2 subdivision code assigned under the CountryCode.\nDepending on the jurisdiction, either a country code or a region code or either of both SHALL be used\nin Legallurisdiction. Details on this are defined in the GLEIF Accepted Legal Jurisdictions Code List*.\n4 GLEIF Accepted Legal Jurisdictions Code List: https://www.gleif.org/en/about-lei/code-lists/gleif-accepted-\nlegal-jurisdictions-code-list\nState Transition and Validation Rules for Common Data File formats Page 32 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2411,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.693Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"2.7 Address Reporting\n\nAn LEI Record SHALL have at least a LegalAddress (where the entity is legally registered) and a\n\nHeadquartersAddress (where the main center of control of the entity resides). LegalAddress and\n\nHeadquartersAddress MAY be the same. Both addresses MAY also be in different countries and/or in\n\ncountries different from Legallurisdiction. If the Legal Entity has only one address recorded in an\n\nofficial Registration Authority, LegalAddress and HeadquartersAddress SHALL be the same address,\nexcept for entities categorized as FUND or BRANCH which have special rules for\n\nHeadquartersAddress (see 3.13 and 3.14 below). If the registry has partial address information, for\n\ninstance a seat of the company recorded only with the city name and a second field with a complete\n\naddress, the latter SHALL be used for LegalAddress and HeadquartersAddress, even if the address is\nin a different city than the city of the seat. In case of doubts, the LEl issuer SHALL contact the\nauthoritative source for further clarification and validation of the data.\n\nIf the address recorded in the registry is not complete, the LEl issuer SHALL collect the missing\n\nelements from the Legal Entity and set ValidationSources to PARTIALLY_CORROBORATED, except\n\nwhen only postal code and/or region is added by the LOU. In this case, the record can be still\n\nFULLY_CORROBORATED (see chapter 2.2.2). In case the HeadquartersAddress could be validated in\n\nan autoritative source different from the primary one, this could be added in the container\n\nOtherValidationAutorities and the corroboration status MAY be set FULLY_CORROBORATED.\n\nAll addresses reported SHALL be complete and include the following mandatory elements:\n\no FirstAddressLine SHALL include the first line describing the address. Up to three additional lines\nMAY be included.\n\no City SHALL be the name of the city in local language and alphabet.\n\no PostalCode SHALL be the postal code in the format specified by the local postal service. For\ncountries that do not use postal codes in addresses, this optional element SHALL NOT be\nprovided.\n\no Region SHALL be the 1ISO 3166-2 region code of the address. For countries that do not have\nregion codes, this optional element SHALL NOT be provided.\n\ne Country SHALL be the ISO 3166-1 country code of the address.\n\nAddresses MAY include optional elements for additional relevant parts of an address to be recorded\n\nin a structured way:\n\n¢ MailRouting MAY contain explicit routing information or “care of” address.\n\no AddressNumber MAY contain the building number.\n\n¢ AddressNumberWithinBuilding MAY contain an internal location within a building, for example to\nidentify the floor, suite or an apartment.\n\nState Transition and Validation Rules for Common Data File formats Page 33 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2892,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.693Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"The information in these optional fields SHALL also be included in FirstAddressLine or\nAdditionalAddressLines. The content of the mandatory elements SHALL NOT be repeated in any\nother field (e.g., the postal code SHALL NOT be included in the designated City field).\n\n2.8 Entity Legal Form Reporting\n\nLEl issuers SHALL ensure that cross reference to the entity legal form is standardized and included in\n\nan LEl record. GLEIF maintains the ISO 20275 standard and publishes the Entity Legal Forms (ELF)\n\nCode List. Codes from that list SHALL be used to populate EntityLegalFormCode. This list includes\n\nspecific and unique codes for all legal forms identified per jurisdiction and two reserved ELF codes\n\n(8888 and 9999) that are valid across jurisdictions.\n\nSpecific ELF code (not 8888 or 9999):\n\no If a specific ELF code is available for an entity's legal form in the entity's legal jurisdiction, it\nSHALL be used in EntityLegalFormCode.\n\no If EntityLegalFormCode is populated with a specific ELF code, OtherLegalForm SHALL NOT be\nprovided.\n\no If a specific code is removed from the ELF code list, the LEl issuer SHALL update all affected\nrecords representing an ACTIVE Legal Entity with a correct new code. The new ELF code SHALL\nNOT be 8888 or 9999 with the name of the just removed legal form as OtherLegalForm.\n\nReserved ELF codes 8888 and 9999:\n\ne Reserved ELF code 8888 is to be used when a new ELF code (for a legal form not yet on the list) is\nrequested by an LEl issuer from GLEIF for a jurisdiction which is on the ELF code list.\n\no Reserved ELF code 9999 is to be used for LEIs from a jurisdiction which is not on the ELF code list\nyet.\n\n¢ The reserved code 8888 SHALL be used only after a request email to elf@gleif.org with further\ndescription of the legal form has been sent.\n\no All requests for new ELF codes (and modifications) are collected over time and processed in time\nfor the periodical publication of a new version of the ELF code list. The approximate date(s) for\nthe publication of a new version SHALL be published well in advance.\n\n¢ In cases, where the suggested legal form has NOT been accepted, based on the reason for the\nrejection, the LEl issuer SHALL select one of the following options:\n\no Use a different existing ELF code assigned to the Legal Entity’s legal form (if possible).\ne Propose another new legal form to be added to the ELF code list and update OtherLegalForm\naccordingly.\n¢ Send more convincing documentation for the proposed legal form.\nState Transition and Validation Rules for Common Data File formats Page 34 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2669,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.693Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o Annul the LEl, but only if the outcome of the discussion is that the proposed legal form is not\neligible for an LEI.\n\n¢ In cases, where the suggested legal form has been accepted, the LEl issuer SHALL update all\napplicable records with the new ELF code, including records that are RETIRED, MERGED not later\nthan one month after publication, unless another implementation time has been set.\n\no If EntityLegalFormCode is populated with 8888 or 9999, OtherLegalForm SHALL include the\ncorrect name of the entity's legal form where no ELF code exists. Therefore, OtherLegalForm\nSHALL NOT contain any ELF code or undescriptive text like “OTHER”, “N/A” or “None”. The name\nprovided as free text SHALL be the same as used in the request sent to GLEIF to add the source to\nthe RA list.\n\n2.9 Language, translation and transliteration\n\ne Where LEl record fields allow for an optional (as per LEI-CDF) language tag, this tag SHALL always\nbe provided. This SHALL be an IETF Language Code conforming to the latest RFC from IETF BCP\n47.\n\ne For transliterated names and addresses then the language code SHALL specify the language of\nthe name or address prior to transliteration.\n\no TransliteratedOtherEntityNames SHALL include a list of ASClI-transliterated (i.e. Latin- or\nRomanized) representations of names for the Legal Entity in all cases of non-romanized\nLegalName.\n\no If using TransliteratedAddressType, the transliterated elements that correspond to the\nmandatory and optional information provided in either the LegalAddress, HeadquartersAddress,\nor OtherAddress SHALL be required, given any of these elements are provided in a non-latin\nalphabet.\n\ne If alegal name or address is provided in an alternative language, both the primary field and the\nalternative SHALL have a language tag, and both SHALL NOT be the same.\n\nState Transition and Validation Rules for Common Data File formats Page 35 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1997,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.693Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3 General State Transition and Validation Rules\nThese rules SHALL apply to the general Use Case for issuing and managing an LE| for a Legal Entity as\nwell as publishing the LEI Record Set. An LEI Record Set with complete Reference Data is composed\nof data fields that are published in different XML files. Each XML file has its own name space and\nschema file. These are:\ne LEl Entity Data (Level 1):\n* Name space: lei\no .xsd file: https://www.gleif.org/content/2-about-lei/6-common-data-file-format/1-\nupcoming-versions/2021-03-04_lei-cdf-v3-1.xsd\no LEI Relationship Data (Level 2):\no Name space: rr\no .xsd file: https://www.gleif.org/content/2-about-lei/6-common-data-file-format/1-\nupcoming-versions/2021-03-04_rr-cdf-v2-1.xsd\no Reporting exception Data (Level 2):\n¢ Name space: repex\no .xsd file: https://www.gleif.org/content/2-about-lei/6-common-data-file-format/1-\nupcoming-versions/2021-07-20_reporting-exceptions-format-v2-1.xsd\nThe complete Xpath is shown in the field description for each field. The schema description in the\n.xsd file provides a more technical definition of each element, including format restrictions, allowed\nvalues, etc. In case there is a discrepancy between the required cardinality of a field in this document\nand the corresponding CDF file, the definition in this document SHALL prevail.\nState Transition and Validation Rules for Common Data File formats Page 36 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1507,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.693Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.1 Header Section (applicable to all files)\nlei:LEIHeader\nrr:Header\nrepex:Header\n_ Contains the file upload information for this file.\n/lei:LEIData/lei:LEIHeader\n/rr:RelationshipData/rr:Header\n/repex:ReportingExceptionData/repex:Header\nThe Header Section describes the context for the LEI Records contained in the main body of the file.\nThe Header Section includes information on the origin and timestamp of the data. The content of the\nHeader Section SHALL NOT be required to interpret the data content of any LEI Record; each LEI\nRecord is self-contained. The Header Section includes the following elements:\ne Content Date\ne Originator\no File Content\no Delta Start\ne Record Count\n° Extension\nState Transition and Validation Rules for Common Data File formats Page 37 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":878,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.693Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.2 Content Date\nlei:ContentDate\nrr:ContentDate\nrepex:ContentDate\n_ The date and time as of which the data contained in the file is valid.\n/lei:LEIData/lei:LEIHeader/lei:ContentDate\n/rr:RelationshipData/rr:Header/rr:ContentDate\n/repex:ReportingExceptionData/repex:Header/repex:ContentDate\nThe Content Date for each record defines the date and time as of which the data contained in the file\nis valid. The following rules apply:\no The ContentDate SHALL be equal to or later than the latest InitialRegistrationDate in the file.\no The ContentDate SHALL be equal to or later than the latest LastUpdateDate in the file.\no The ContentDate SHALL be later than the DeltaStart date for delta files.\n3.3 Originator\nlei:Originator\nrr:Originator\nrepex:Originator\n_ The LEI of the LEl issuer that created the content of this file.\n/lei:LEIData/lei:LEIHeader/lei:Originator\n/rr:RelationshipData/rr:Header/rr:Originator\n/repex:ReportingExceptionData/repex:Header/repex:Originator\nState Transition and Validation Rules for Common Data File formats Page 38 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1148,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.693Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"e The Originator SHALL be a valid LEI with correct check digits as specified in the 1ISO 17442\nstandard document.\no The Originator SHALL contain the LEI of the LEl issuer publishing the file.\no If FileContent is not GLEIF_FULL_PUBLISHED or GLEIF_DELTA_PUBLISHED, Originator SHALL be\npopulated.\n3.4 File Content\nlei:FileContent\nrr:FileContent\nrepex:Content\n_ A code describing the content of this file.\n/lei:LEIData/lei:LEIHeader/lei:FileContent\n/rr:RelationshipData/rr:Header/rr:FileContent\n/repex:ReportingExceptionData/repex:Header/repex:FileContent\n¢ The value LOU_FULL_PUBLISHED for FileContent SHALL be used to designate a file containing all\nup-to-date LEI Records published by an LEl issuer.\no If FileContent is LOU_FULL_PUBLISHED, then DeltaStart SHALL NOT be present.\n¢ The value LOU_DELTA_PUBLISHED for FileContent is used to designate a file containing only LEI\nRecords newly added or changed since an LOU’s last upload.\no If FileContent is LOU_DELTA_PUBLISHED, then DeltaStart SHALL be present.\no If FileContent is neither LOU_DELTA_PUBLISHED nor GLEIF_DELTA_PUBLISHED, DeltaStart SHALL\nNOT be present.\nState Transition and Validation Rules for Common Data File formats Page 39 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1298,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.693Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.5 Delta Start\nlei:DeltaStart\nrr:DeltaStart\nrepex:DeltaStart\nThe date and time of the baseline relative to which this file contains\nnew or changed records.\n/lei:LEIData/lei:LEIHeader/lei:DeltaStart\n/rr:RelationshipData/rr:Header/rr:DeltaStart\n/repex:ReportingExceptionData/repex:Header/repex:DeltaStart\nCurrently, delta files are not provided or accepted by GLEIF.\no If Header contains the DeltaStart element, then FileContent SHALL be LOU_DELTA_PUBLISHED or\nGLEIF_DELTA_PUBLISHED.\n3.6 Record Count\nlei:RecordCount\nrr:RecordCount\nrepex:RecordCount\n_ The number of records in this file.\n/lei:LEIData/lei:LEIHeader/lei:RecordCount\n/rr:RelationshipData/rr:Header/rr:RecordCount\n/repex:ReportingExceptionData/repex:Header/repex:RecordCount\ne The number of instances of lei:LEIRecord, rr:Relationship or repex:ReportingException contained\nin this file SHALL equal the value of RecordCount.\nState Transition and Validation Rules for Common Data File formats Page 40 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1069,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.693Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.11 Lack of renewal —Legal Entity......ccccoeeviviieeiiiiiiiiee i scvvieeeessivieeeessssennnn. 107\n4.12 Lack of renewal — Related Legal Entity including head offices, fund managers,\numbrella and master fuNdS.........cccveeeiiiiiieiiere e ineee e e 107\n4.13 Update of LEI Reference Data due to Legal Entity Events .........ccccceevvvveeeeine.. 107\n4.13.1Legal Entity Event — Event timeline and status..........cccecceevviviiieeeinisceeeecnsiieeenn. 108\n4.13.2Legal Entity Event — Legal Name changes ......cccccevvveeeeivvieeesicciiieeececsiieeeseesvveeen e, 109\n4.13.3Legal Entity Event — Business or trading name changes ........ccccccceeevieeeiiiiiieennnnn, 112\n4.13.4Legal Entity Event — Address information changes........ccccevveevcvecviecceeeninennnn. 114\n4.13.5Legal Entity Event — Legal form changes........cccccvvveeveeecieeevcie e ceeecvvieeeeeesveees 116\n4.13.6Legal Entity Event — ACQUISITION ....coivviiiiieiiiiiie e csiieee s seeeee s esseveeee e 124\n4.13.7Legal Entity Event — AbSOrption ......cccveeeiiiiiieii e ccsiieeeecccrvieesssssvieee s sssnveeeeeees 125\n4.13.8Legal Entity EVENt — IMEIEI ..ccveeieeieiieeie ettt cssriitee et eesssavie e asssvseee s ssssveneeanns 128\n4.13.9Legal Entity Event — Transformation of a Subsidiary to an International Branch 131\n4.13.10 Legal Entity Event — Acquisition of an International Branch.......................... 134\n4.13.11 Legal Entity Event — Break-up ....ccccccceeeviieeiieiiieee s cciieeeeceviieeessesiieee s sssnieeeeeens 137\n4.13.12 Legal Entity Event — DeMErger....cccuveiivviviieiiiiieeeeeisieeeesssiieeessssneeessssvenneanns 140\n4.13.13 Legal Entity Event — Spin-0ff ......cccccoeiiiiiiie et sie e 142\n4.13.14 Legal Entity Event — Transformation of an International Branch to a Subsidiary\n144\n4.13.15 Legal Entity Event —BankruptCy .....ccccevvvveericiviieenscisiieeesecivieessessvieeesessvveneeeens 147\n4.13.16 Legal Entity Event — INnSOIVENCY.....uveevivviiiiiiiiiiiie e criieeeesssieee e essiieeee e 150\n4.13.17 Legal Entity Event — Liquidation.......ccccceuveeiiiiviieeiiiniieiecssiieeecsssieeeeessieeeeenns 150\n4.13.18 Legal Entity Event — DisSOIULION ......cccccviiiiiiiiiieee s cciiieeecciiieeeseesiieee s eesiieeeeeees 151\n4.13.19 Legal Entity Event — Voluntary Arrangement.........ccccceeveeviveeriecsieeeseesveenneens 151\n4.13.20 Legal Entity Event — Reverse Tak@oVver ......cccoceeeeivvveeieenniieeeinssieeesensnenneenns 154\n4.13.21 Legal Entity Event — Transformation of an Umbrella Fund to a Stand-Alone\n4.13.22 Legal Entity Event — Effects on parent and child relationships...................... 158\n4.13.23 Legal Entity Event — Erroneously introduced Legal Entity Event ................... 160\n4.14 Update of LEI Reference Data other than due to Legal Entity Events ................ 162\n4.15 LEI Record update — Registration information changes..........cccccceeviiiieeni . 162\n4.16 LEI Record update — Reporting Exception changes to Relationship Records......162\n4.17 LEI Record Set update — Entity or Relationship Data changes..........ccccceeeeeeee.. 163\n4.18 LEI Record Set update — Change of fund manager ........ccccoevvvvveievviiiiieeee i 163\n4.19 LEI Record Set update — Transfer......occcvveeviiiiiieiee i csssieee s sieieee s sssineen. 163\n4.20 Registration errors — Exclusivity Violation (duplication)......c...cccccevvveeeieeeen... 167\n4.21 Registration error — Relationship Record or reporting exception is a duplicate 167\n4.22 Registration error — Eligibility violation (invalid LEl issuance) ............................ 168\n4.23 Issue New LEl for an US company incorporated in one state but operating in\nANOTNET oo s e e s s s sanaae e e s s snsssaeeeses LO8\nG State Transition and Validation Rules for Common Data File formats Page 5 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":3843,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.694Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o Iflei:LEIRecord, rr:Relationship or repex:ReportingException is empty, then RecordCount SHALL\nbe 0.\no RecordCount SHALL NOT be negative (less than 0).\n3.7 Extension (applicable to multiple Header Sections and data\nsections)\nlei:Extension\nrr:Extension\nrepex:Extension\nThis Extension element contains any additional elements required to\nextend the Header or data container element.\n~/lei:Extension\n~/rr:Extension\n~/repex:Extension\no Extension elements MAY be included in all Header Sections and several data section elements\n(see corresponding .xsd files for details).\no There are no restrictions on the contents of the Extension element. For this reason, it is\nrecommended to inform recipients which elements to expect here.\nState Transition and Validation Rules for Common Data File formats Page 41 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":909,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.694Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.8 LEI Record\nContains LEI Reference Data including details of the LEI's registration\nwith the ManagingLOU.\n_ /lei:LEIData/lei:LEIRecords/lei:LEIRecord\nThe LEI Record is a container holding all Level 1 Reference Data including Entity Data and details of\nthe LEI's Registration with the ManagingLOU.\no Optional Extension elements MAY be included.\n3.9 LEI Code (context: LEI-CDF)\nThe 1SO 17442 compatible identifier for the Legal Entity described in\nthe Entity section.\n_ /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:LEl\ne The LEI Code SHALL be ISO 17442 compliant.\ne An LElI Code SHALL be used only once (uniqueness).\n¢ Only one LEl per Legal Entity may be reported (exclusivity).\no The LEl issuer SHALL be responsible for checking for duplicate LEls (uniqueness and exclusivity)\nprior to issuing, updating, renewing and transferring an LEl and publishing the LEI Record Set.\nState Transition and Validation Rules for Common Data File formats Page 42 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1060,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.694Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.10 Legal Name\n\n_ The legal name of the Legal Entity.\n\n_ /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:LegalName\n\no LegalName SHALL be the legal name of the entity in a local language and character set commonly\nused in the registration authority or in other authoritative validation sources.\n\n¢ LegalName SHALL be the primary legal name in case of being in a jurisdiction with more than one\nlegal name (e.g., in different languages).\n\n3.11 Other Entity Names\n\n_ lei:OtherEntityNames\n\nAn optional list of other names (excluding transliterations) for the\nLegal Entity.\n\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity\n/lei:OtherEntityNames\n\nThe OtherEntityNames element is a container including one or more other names for the Legal Entity\n\ntogether with a specification of a name type.\n\no The Legal Entity MAY provide an official, registered name for the Legal Entity in another language\nor a translated version of the entity's legal name. However, as far the local registry provides a\ntranslated or transliterated version of the legal name, these SHALL be made available in the\nappropriate element as part of the LEI Record Set.\n\nState Transition and Validation Rules for Common Data File formats Page 43 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1330,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.694Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"¢ Avalue of type OtherEntityName in a file conforming to this standard SHALL include an optional\nlanguage code, permitting OtherEntityName to be repeated as many times as necessary to\nexpress the same name type in multiple languages.\n\n¢ The language code of an OtherEntityName with type ALTERNATIVE_LANGUAGE_LEGAL_NAME\nSHALL NOT be the same as the LegalName's language code.\n\no OtherEntityName with type PREVIOUS_LEGAL_NAME SHALL NOT be the same as the current\nLegalName.\n\no OtherEntityName with type TRADING_OR_OPERATING_NAME SHALL NOT be the same as the\ncurrent LegalName.\n\n3.12 Transliterated Other Entity Names\n\n_ lei:TransliteratedOtherEntityNames\n\nAn optional list of ASClI-transliterated (i.e. Latin- or Romanized)\nrepresentations of names for the Legal Entity.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity\n/lei:TransliteratedOtherEntityNames\n\nThe TransliteratedOtherEntityNames element is a container including one or more transliterated\n\nnames for the Legal Entity together with a specification of the transliteration procedure.\n\no If populated, the TransliteratedOtherEntityNames SHALL include a list of ASClI-transliterated (i.e.\nLatin- or Romanized) representations of names for the Legal Entity in all cases of non-romanized\nLegalName.\n\no The general rules for transliteration SHALL apply (see section 2.9).\n\nState Transition and Validation Rules for Common Data File formats Page 44 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1513,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.694Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.13 Legal Address\nThe address of the Legal Entity as recorded in the registration of the\nLegal Entity in its legal jurisdiction.\n\n_ /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:LegalAddress\n\nThe LegalAddress element is a container including mandatory and optional elements comprising the\n\nentity’s legal address.\n\no LegalAddress SHALL be the address of the entity as recorded in the registration of the entity.\n\ne For an International Branch, LegalAddress SHALL be the address of the entity in the host country.\n\ne Forafund entity, LegalAddress SHALL be a current address provided in the business registry in\nwhich the entity was formed (for funds that are incorporated) or by the financial regulatory\nauthority where the entity is registered (for all other cases). If no such address is provided, a\nregistered address from the fund’s constituting documents SHALL be recorded as LegalAddress. If\nsuch documents are also not available, the registered address of the fund managing entity\nresponsible for the legal affairs of the fund SHALL be recorded as LegalAddress. In this case, a\n“care of” address structure (MailRouting) SHALL be used to signal that the address is one of a\ndifferent entity. See the LEI ROC policy on Fund Relationships and Guidelines for the registration\nof Investment Funds in the Global LEI System?® for details.\n\no If the entity is not registered, LegalAddress SHALL be the address mentioned in any document\nused to validate the existence of the entity, or, in lack of, the entity's declared center of control\n(same as HeadquartersAddress).\n\no The general rules for reporting addresses SHALL apply (see section 2.7).\n\n5 https://www.leiroc.org/publications/gls/roc_20190520-1.pdf\n\nState Transition and Validation Rules for Common Data File formats Page 45 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1901,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.694Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.14 Headquarters Address\n\n_ lei:HeadquartersAddress\n\n_ The address of the headquarters of the Legal Entity.\n\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Entity/lei:HeadquartersAddress\n\nThe HeadquartersAddress element is a container including mandatory and optional elements\n\ncomprising the entity’s headquarters address.\n\n¢ HeadquartersAddress SHALL be the address of the main office or center of control of a company\nor organization.\n\n¢ HeadquartersAddress MAY be the same as the LegalAddress of the Legal Entity.\n\ne For an International Branch, HeadquartersAddress SHALL be the address of the head office.\n\no For afund entity, HeadquartersAddress SHALL be the registered address of the fund managing\nentity. A “care of” address structure (MailRouting) SHALL be used to signal that the address is\none of a different entity.\n\ne For a Government Entity, HeadquartersAddress SHALL be the address of the entity itself or the\naddress of the authorized entity managing the LEI registration on behalf of the Government\nEntity. The address MAY be the same as LegalAddress. If another entity manages the registration,\na “care of” address structure (MailRouting) SHALL be used including the name of the entity\nmanaging the LEI registration.\n\ne For an International Organization with distributed field operations and no discernable main office\nor center of control, HeadquartersAddress SHALL be the location of a secretariat or similar\nadministrative central function.\n\no The general rules for reporting addresses SHALL apply (see section 2.7).\n\nState Transition and Validation Rules for Common Data File formats Page 46 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1723,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.694Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.15 Other Addresses\nAn optional list of other addresses for the Legal Entity, excluding\ntransliterations.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Entity/lei:OtherAddresses\nThe OtherAddresses element is a container including one or more other addresses associated with\nthe Legal Entity, including a specification of the type of address.\n¢ The language code of another address with type ALTERNATIVE_LANGUAGE_LEGAL_ADDRESS\nSHALL NOT be the same as that of the Legal Entity's LegalAddress.\n¢ The language code of any other address of type\nALTERNATIVE_LANGUAGE_HEADQUARTERS ADDRESS SHALL NOT be the same as that of the\nLegal Entity's primary HeadquartersAddress.\no Addresses in alternative languages SHALL describe the same location but SHALL NOT be literally\nidentical across all fields included.\ne The general rules for reporting addresses SHALL apply (see section 2.7).\n3.16 Transliterated Other Addresses\n_ lei:TransliteratedOtherAddresses\n_ An optional list of transliterated addresses for the Legal Entity.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Entity/lei:TransliteratedOtherAddresses\nState Transition and Validation Rules for Common Data File formats Page 47 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1286,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.694Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"The TransliteratedOtherAddresses element is a container including one or more transliterations of\nthe Legal Entity’s addresses.\no The general rules for reporting addresses SHALL apply (see section 2.7).\no The general rules for transliteration SHALL apply (see section 2.9).\n3.17 Registration Authority\n_ lei:RegistrationAuthority\nInformation about the official authority in the Legal Entity's\njurisdiction of legal registration, for example a business registry, and\nthe corresponding identification of the Legal Entity by that official\nsource.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Entity/lei:RegistrationAuthority\nThe RegistrationAuthority element is a container including a mandatory RegistrationAuthoritylD and\nthe optional RegistrationAuthorityEntitylD and OtherRegistrationAuthoritylD. The Legal Entity is\nresponsible to supply its local Registration Authority and identifier. This is for mapping to the local\nRegistration Authority.\no The rules for using GLEIF Registration Authority codes SHALL apply (see section 2.2.3)\nState Transition and Validation Rules for Common Data File formats Page 48 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1220,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.694Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.18 Registration Authority ID\n_ lei:RegistrationAuthoritylD\nThe reference code of the Registration Authority, taken from the\nRegistration Authorities Code List maintained by GLEIF.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity\n/lei:RegistrationAuthority/lei:RegistrationAuthoritylD\no RegistrationAuthoritylD SHALL be populated with a valid code from the Registration Authorities\nlist.\no For Legal Entities that are not registered in a registry, RegistrationAuthoritylD SHALL be\nRA999999.\no For EntityCategory BRANCH RegistrationAuthoritylD SHALL NOT be populated with the value\nRA999999.\no The general rules for Registration and Validation SHALL apply (see section 2.2).\n3.19 Other Registration Authority ID\n_ lei:OtherRegistrationAuthoritylD\nA legacy / historical reference code of a Registration Authority which\nis not yet entered in the Registration Authorities Code List (RA list)\nmaintained by GLEIF, or the designation of an interim register until\nsuch time as an entry from RA list can be delivered.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity\n/lei:RegistrationAuthority/lei:OtherRegistrationAuthoritylD\no OtherRegistrationAuthoritylD MAY be present when RegistrationAuthoritylD is populated.\nState Transition and Validation Rules for Common Data File formats Page 49 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1400,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.695Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o If RegistrationAuthorityID is RA888888, OtherRegistrationAuthoritylD SHALL include the name of\nthe Registration Authority, as submitted in the request sent to GLEIF to add a new code to the RA\nlist (see section 2.2.3).\n3.20 Registration Authority Entity ID\n_ lei:RegistrationAuthorityEntitylD\nThe identifier of the Legal Entity at the indicated Registration\nAuthority. Typically, the identifier of the Legal Entity as maintained by\na business registry in the jurisdiction of legal registration, or if the\nLegal Entity is one that is not recorded in a business registry, the\nidentifier of the Legal Entity in the appropriate Registration Authority.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity\n/lei:RegistrationAuthority/lei:RegistrationAuthorityEntitylD\no If the Registration Authority provides an entity ID, RegistrationAuthorityEntitylD SHALL be\npopulated with the entity ID from the register. If the authoritative source does not provide an\nentity ID, RegistrationAuthorityEntitylD SHALL NOT be included. This applies also, if RA888888 is\nused.\no RegistrationAuthorityEntitylD SHALL be populated, if lei:ValidationSources is\nFULLY_CORROBORTATED or PARTIALLY_CORROBORATED, with following exceptions:\n¢ The Legal Entity category (EntityCategory) is marked as FUND.\no RegistrationAuthorityEntitylD SHALL NOT be populated, if RegistrationAuthorityID is RA999999\nor one of the RA Codes identifying sources known to not providing an entity ID.\nState Transition and Validation Rules for Common Data File formats Page 50 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1634,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.696Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.24 Issue New LEI — Financial institution inthe US ............ccoe il 169\nAbout this Document\nThis document describes Business Rules for the issuance, updating, management and publication of\nLEI Reference Data according to the Common Data File (CDF) formats LEI-CDF 3.1, RR-CDF 2.1 and\nRepex-CDF 2.1.\nChange History\nThis section records the history of all changes to this document.\n2023-03-07 2.7.1 Clarified use of legal form for international branches GLEIF\n(3.21)\n2023-02-09 2.7 Add use cases for corporations and financial GLEIF\ninstitutions in the US (4.23, 4.24)\nProvide additional clarification on existing rules and\nguidelines for branches, funds in formation, and legal\nentity events (3.24, 3.31, 3.40, 3.52, 3.58, 4.2, 4.3, 4.4,\n4.8,4.13.1).\nRemove references which elements have been\nadded/deprecated in the latest CDF transition.\n2022-04-01 2.6 Added chapter 4.13.23 on resolving incorrectly GLEIF\nreported Legal Entity Events\nProvide additional clarification on existing rules and\nguidelines (2.1.2, 2.3.2, 2.7, 3.20, 3.26, 3.27, 3.36, 3.46,\n3.60, 3.61, 4.6, 4.13.1, 4.13.5, 4.13.9, 4.13.17, 4.13.18\nState Transition and Validation Rules for Common Data File formats Page 6 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1297,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.696Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.21 Legal Jurisdiction\n_ lei:Legallurisdiction\nThe jurisdiction of legal formation of the Legal Entity; i.e. where the\nlegal form of the Legal Entity originates.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Entity/lei:Legallurisdiction\no Legallurisdiction SHALL be a country or subdivision code from the GLEIF Accepted Legal\nJurisdictions Code List (https://www.gleif.org/en/about-lei/code-lists/gleif-accepted-legal-\njurisdictions-code-list). As per July 2020, all LEls SHALL be compliant with this list.\no Legallurisdiction SHALL contain the country or region where the Legal Entity Form originates. As\nsuch, the content of Legallurisdiction is linked to the content of LegalForm.\ne A company with a legal form from country A which has its address(es) in country B SHALL have A\nas its Legallurisdiction.\n¢ An International Branch SHALL always have the LegalForm and Legallurisdiction of the Legal\nEntity to which it belongs.\no For an International Organization established by treaties or other specific multinational\nagreements governed by international laws, Legallurisdiction SHALL be one of the following:\no UN, if the entity is the United Nations, one of their specialized agencies or other affiliated\norganizations.\no EU, if the entity is established by a treaty signed by all members of the European Union and\nno other countries.\no XX, in all other cases.\nState Transition and Validation Rules for Common Data File formats Page 51 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1550,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.705Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.22 Entity Category\nIndicates (where applicable) the category of Legal Entity identified by\nthis LEI Record, as a more specific category within the broad\ndefinition given in ISO 17442. These categories are based on Use\nCases specified in LEI-ROC policies, found at\nhttp://www.leiroc.org/list/leiroc_gls/index.htm.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Entity/lei:EntityCategory\n\nEntityCategory contains the general category of certain types of Legal Entities that are subject to\n\nspecial rules within the Global LEI System.\n\no For Legal Entities that are funds, individuals acting in a business capacity or International\nBranches, the EntityCategories of FUND, SOLE_ PROPRIETOR or BRANCH SHALL be assigned,\nrespectively.\n\no For Legal Entities that are Government entities, the EntityCategory\nRESIDENT_GOVERNMENT_ENTITY SHALL be assigned with an appropriate sub-category, where\napplicable.\n\no For organizations established by international agreement that may not be (only) subject to the\nlaws or regulations of the country or countries in which they are located, the EntityCategory\nINTERNATIONAL_ORGANIZATION SHALL be assigned.\n\no For Legal Entities that are not funds, individuals acting in a business capacity, International\nBranches, Government entities or International Organizations, the EntityCategory of GENERAL\nSHALL be assigned .\n\nAn LEI Record SHALL be identified as BRANCH, if:\n\n¢ The Branch is an International Branch as defined, outside of the head office’s jurisdiction. For\npurposes of the LEI-ROC policy document, jurisdiction is synonymous with country and\nInternational Branch is defined as a non-incorporated establishment of a Legal Entity, when this\nestablishment is located in a separate jurisdiction from the jurisdiction in which the head office\nof the (same) Legal Entity is located, i.e., in a host jurisdiction outside of its home jurisdiction.\nUnder this definition, an establishment may consist of a single office or other business premises,\n\nState Transition and Validation Rules for Common Data File formats Page 52 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2164,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.705Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"or of several offices (i.e., a branch network) in different locations of the same host jurisdiction:\neven in the latter case, only one LElI would be issued per host jurisdiction, essentially amounting\nto, one country-one LEI. Unlike foreign subsidiaries of a parent entity, which are separately\nincorporated as separate Legal Entities or organized under the laws of the host jurisdictions, an\nInternational Branch, as defined here, is legally dependent on the (head office) Legal Entity it\nbelongs to and cannot exist without its (head office) Legal Entity;\n\ne The Branch is registered in a publicly accessible local business registry, local regulatory registry or\ntax registry, preferably an RA source;\n\no The Legal Entity the Branch belongs to already has an LEIl so that the LEI of the (head office) Legal\nEntity can always be associated with the LEI of the International Branch in the Global LEI System;\nand\n\no The Reference Data of the International Branch in the LEI system includes a Branch relationship\nlinking the Branch to its (head office) Legal Entity.\n\nAn LEI Record SHALL be identified as FUND, if:\n\n¢ Inline with the governance principles of the Global LEI System, the Legal Entity reports being an\ninvestment fund, defined as a collective investment scheme (or pooled investment) beneficially\nowned by multiple investors and managed on behalf of those investors by an asset manager or\nby the fund itself.\n\n¢ Investment funds or collective investment schemes MAY not always be registered, or MAY be\nsubject to varying degrees of regulation, and there is therefore no single legal or regulatory\ndefinition. Above definition of fund entities SHALL apply to funds incorporated as a company as\nwell as funds established by contract.\n\no The LElissuer SHALL verify that the report of the Legal Entity being a fund is correct. LEl issuers\nare not required to verify whether an entity not reporting itself as a fund is a fund, except\nminimum due diligence including:\n\no whether the name of the fund includes the mention that it is a fund or any equivalent in the\nrelevant language and legal framework;\n\no whether the legal form necessarily means that the entity is a FUND;\n\n* whether the registry used to establish the existence of the entity is specific to funds;\n\no if the LEl of the Legal Entity is the EndNodelD of an ACTIVE relationship with\nRelationshipType IS_FEEDER_TO.\n\nAn LEI Record SHALL be identified as SOLE_PROPRIETOR, if:\n\nState Transition and Validation Rules for Common Data File formats Page 53 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2628,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.705Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"¢ The entity is a type of enterprise that is owned and operated by one person or family\nbusiness (married couple, mothers, fathers, siblings, etc.) and in which there is no legal\ndistinction between the owner’s assets and liabilities and the business entity.\no The person or family business has unlimited personal responsibility for all losses and debts.\n¢ Inseveral countries it would be possible to identify a Sole Proprietor from the business registry\n(RA source); in such cases all Registration Authority information should be incorporated.\nAn LEI Record SHALL be identified as RESIDENT_GOVERNMENT _ENTITY, if:\n¢ The Legal Entity is a non-market producer, part of a central, state or local government, social\nsecurity funds or a non-profit institution (NPI) controlled by government units.\no The definition of Government Entities® in the Global LEl System is in line with the underlying ISO\n17442 standard and further guided by the System of National Accounts (SNA).\no Astate owned, but independent general Legal Entity or Fund not part of or controlled by the\ngovernment SHALL NOT be categorized as RESIDENT_GOVERNMENT_ENTITY but rather as\nGENERAL or FUND, respectively.\nAn LEI Record SHALL be identified as INTERNATIONAL_ORGANIZATION, if:\no The Legal Entity is a non-resident unit, created by international agreement or other\narrangements for the provision of non-market services or financial intermediation at the\ninternational level.\no The special characteristics of an “international organization” as this term is used in the SNA may\nbe summarized as follows:\n¢ The members of an international organization are either national states or other\ninternational organizations whose members are national states; they thus derive their\nauthority either directly from the national states that are their members or indirectly from\nthem through other international organizations.\n\n¢ They are entities established by formal political agreements between their members that\nhave the status of international treaties; their existence is recognized by law in their member\ncountries.\n\n* Because they are established by international agreement, they are accorded sovereign\nstatus; that is, international organizations are not subject to the laws or regulations of the\n\n8 https://www.leiroc.org/publications/gls/roc_20201229.pdf\n\nState Transition and Validation Rules for Common Data File formats Page 54 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2504,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.705Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"country, or countries, in which they are located; they are not treated as resident institutional\nunits of the countries in which they are located.\n¢ International organizations are created for various purposes including, among others, the\n\nfollowing types of activities:\n\ne The provision of non-market services of a collective nature for the benefit of their\nmembers.\n\n¢ Financial intermediation at an international level, that is, channeling funds between\nlenders and borrowers in different countries.\n\n3.23 EntitySubCategory\n\nIndicates and specifies further (where applicable) the sub-category\n(sub-sector) of Legal Entity identified by this LElI Record and already\ncategorized by the EntityCategory field.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Entity/lei:EntitySubCategory\n\nEntitySubCategory contains the sub-category/sub-sector of certain categories of Legal Entities that\n\nare subject to special rules within the Global LEI System.\n\no Legal Entities other than RESIDENT_GOVERNMENT_ENTITY (i.e., GENERAL, FUND, BRANCH,\nSOLE_PROPRIETOR, INTERNATIONAL ORGANIZATION) SHALL NOT declare any subsector or sub-\ncategory.\n\no Legal Entities that are classified as RESIDENT_GOVERNMENT_ENTITY in the EntityCategory field\nSHALL declare its Government subsector, if available and applicable.\n\nFigure 5 provides a schematic overview of the structure of a General Government and sets the\n\nbaseline for the subsector definitions.\n\nState Transition and Validation Rules for Common Data File formats Page 55 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1611,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.705Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"General Government\nCentral Administration\nState Government\nSocial Security\nFunds Local Government\nLocal Local Local Local Local Local\nGovernment Government Government Government Government Government\nAl A2 B1 B2 C1 C2\nLocal Local Local Local Local Local\nGovernment Government Government Government Government Government\nA3 A4 B3 B4 c3 c4\nPublic corporation 1 Public corporation 2 Public corporation 3 Public corporation n\no\n\nFigure 5: Scheme of a General Government\n\nAn LEI Record SHALL be identified as CENTRAL_GOVERNMENT, if:\n\n¢ The central government subsector consists of the institutional units plus non-profit institution\n(NPI) controlled by the central government institutions (paragraph 4.134 of the SNA). Paragraph\n4.135 of the SNA defines central administration as comprising all institutional units that extend\ntheir authority over the entire territory of the country.\n\nAn LEI Record SHALL be identified as STATE_GOVERNMENT, if:\n\no The state government subsector consists of the institutional units that exercise some\ngovernment functions at a level below that of the central government and above that of the\ngovernment institutional units existing at a local level. These are institutional units whose fiscal,\nlegislative and executive authority extends over individual states in which the country, as a\nwhole, may be divided. In some countries, especially small countries, individual states and state\ngovernments may not exist (paragraph 4.141 of the SNA). The state government usually has the\nfiscal authority to levy taxes on institutional units that are resident in or engage in economic\nactivities or transactions within its area of competence (paragraph 4.142 of the SNA).\n\nAn LEI Record SHALL be identified as LOCAL_GOVERNMENT, if:\n\n¢ The local government subsector consists of local governments that are separate institutional\nunits. The scope of their authority is generally much less than that of central government or state\ngovernments, and they may or may not, be entitled to levy taxes on institutional units resident in\n\nState Transition and Validation Rules for Common Data File formats Page 56 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2230,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.705Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"their areas (paragraph 4.145 of the SNA).\n\nAn LEI Record SHALL be identified as SOCIAL_SECURITY, if:\n\ne Social security schemes are social insurance schemes that cover the community as a whole or\nlarge sections of the community and are imposed and controlled by government units. The\nschemes cover a wide variety of programmes, providing benefits in cash or in kind for old age,\ninvalidity or death, survivors, sickness and maternity, work injury, unemployment, family\nallowance, health care, etc. (paragraph 4.124 of the SNA). They can operate at all levels of\nGovernment (paragraph 4.147 of the SNA). When social security schemes are separately\norganized from the other activities of government units and hold their assets and liabilities\nseparately from the latter and engage in financial transactions on their own account, they qualify\nas institutional units that are described as social security funds. However, institutional\narrangements in respect of social security schemes differ from country to country and in some\ncountries they may become so closely integrated with the other finances of government as to\nbring into question whether they should be treated as separate institutional units. (paragraph\n4.125 of the SNA).\n\nIf a Government Entity does not fit the definitions of one of these sub-categories, EntitySubCategory\n\nSHALL NOT be provided.\n\n3.24 Legal Form\n\n_ The legal form of the Legal Entity.\n\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:LegalForm\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:LegalForm\n\n/lei:EntityLegalFormCode\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:LegalForm\n/lei:OtherLegalForm\n\nThe legal form of the Legal Entity is represented by the LegalForm container. It consists of two\n\nelements: EntityLegalFormCode and OtherLegalForm.\n\no EntityLegalFormCode SHALL be taken from the ISO 20275 Entity Legal Form (ELF) Code list\nmaintained by GLEIF.\n\nState Transition and Validation Rules for Common Data File formats Page 57 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2108,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.705Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o If EntityCategory is not BRANCH, the ELF code SHALL have a legal jurisdiction matching the LEI’s\nLegallurisdiction.\no If EntityCategory is BRANCH, LegalForm SHALL be the legal form of the (head office) Legal Entity.\ne For an International Organization, LegalForm SHALL be 9999, the reserved code for jurisdictions\nnot on the ELF code list. OtherLegalForm SHALL include the name of the treaty establishing the\nentity. If a series of treaties or updates of treaties were signed to form the entity, only the latest\none establishing it in its current form SHALL be included.\no The general rules for Entity Legal Form Reporting SHALL apply (see section 2.8).\ne If one of the reserved ELF codes is used, OtherLegalForm SHALL be present.\no If any non-reserved ELF code is used, OtherLegalForm SHALL be omitted.\n3.25 Entity Status\nThe operational and/or legal registration status of the Legal Entity\n(may be ACTIVE, INACTIVE or NULL).\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Entity/lei:EntityStatus\nThe EntityStatus of an LEI Record SHALL indicate the status of the Legal Entity itself. It is linked to\nother data fields related to especially INACTIVE entities or records (e.g., SuccessorLEl,\nRegistationStatus).\no If EntityStatus is set to ACTIVE, the RegistrationStatus SHALL NOT be set to RETIRED.\no Accepted values for the field are:\no ACTIVE: As of the last report or update, the Legal Entity reported that it was legally registered\nand operating.\no INACTIVE: It has been determined that the Legal Entity that was assigned the LEl is no longer\nlegally registered and/or operating, as indicated by a recorded Legal Entity Event.\ne NULL: Providing an ACTIVE or INACTIVE status of the Legal Entity is not applicable .\nState Transition and Validation Rules for Common Data File formats Page 58 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1904,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.706Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o If EntityStatus is set to INACTIVE, the RegistrationStatus SHALL NOT be set to either ISSUED or\nLAPSED and SHALL NOT be PENDING_TRANSFER or PENDING_ARCHIVAL, except for very rare\ncases that require the transfer of an LEI Record representing an inactive Legal Entity.\n\n¢ The EntityStatus is set to NULL in following cases:\n\no The LEl reaches one of the end stages of its lifecycle representing an error — ANNULLED or\nDUPLICATE.\no The LElisissued for a FUND entity in a jurisdiction (e.g., Spain), where the existence of an LElI\nis a prerequisite to be able to register the entity itself (see section 4.3).\n3.26 Entity Creation Date\nThe date on which the Legal Entity was first established, as\nrepresented by ISO 8601 (as defined in ISO 17442).\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/\nlei:EntityCreationDate\n\no The date when the Legal Entity has been created, formed or incorporated SHALL be provided for\nall LEI Record Sets not yet reached an end stage of their lifecycle.\n\n¢ The information SHALL be extracted from the local registry (if applicable and the entity is a\nregistered entity) or from the legal documents provided by the entity (in case of entity supplied\ndata only). This information provides additional value to the LEI Record Set and will simplify the\nefforts with future mapping partners. It will also enable a high-automated process for mapping\nand potential duplicate identification.\n\n¢ The date provided SHALL be in ISO 8601 datetime format with a minimum value 0001-01-\n01T00:00:00.\n\n¢ If only the year and month of the creation are known and no information about the exact day of\nthe month is availble, the LEIl issuer SHALL use the first day of the respective month.\n\n¢ If the entity is a BRANCH, EntityCreationDate SHALL be the date of the creation of the Branch\nitself and not the date of the creation of the (head office) Legal Entity to which it belongs.\n\nState Transition and Validation Rules for Common Data File formats Page 59 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2080,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.706Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.27 Successor Entity\n\n_ One or more Legal Entities that continue or replace this LEI.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Entity/lei:SuccessorEntity\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Entity/lei:SuccessorEntity/lei:SuccessorLEl\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Entity/lei:SuccessorEntity/lei:SuccessorEntityName\n\nThe SuccessorEntity element is a container including one or more successor entities, identified by\n\neither an LEl or by legal name.\n\no The SuccessorEntity container SHALL be used to report the surviving or new LEI Record Set in\ncases of an Exclusivity Violation or when a Legal Entity Event occurred, requiring the provision of\none or more Successor Entity information.\n\no The SuccessorEntity SHALL be identified either by LEl or by LegalName.\n\no If RegistrationStatus is DUPLICATE, SuccessorLEI SHALL include the LEI of the surviving LEI\nRegistration and SuccessorEntityName SHALL NOT be included.\n\no If one of the following Legal Entity Events has been recorded in the LegalEntityEvents section, the\nSuccessorLElI SHALL be provided, in case the successor Legal Entity holds an LEI; and\nSuccessorEntityName SHALL be provided, in case the successor Legal Entity does not hold an LEI:\no DEMERGER\no SPINOFF\no ACQUISITION_BRANCH\no TRANSFORMATION_BRANCH_TO_SUBSIDIARY\no TRANSFORMATION_UMBRELLA_TO_STANDALONE\no BREAKUP\n+ MERGERS_AND_ACQUISITIONS\n\no If one of the following Legal Entity Events involves a successor entity, the SuccessorLElI SHALL be\nprovided, in case the successor Legal Entity holds an LEI; and SuccessorEntityName SHALL be\nprovided, in case the successor Legal Entity does not hold an LEI:\n\nState Transition and Validation Rules for Common Data File formats Page 60 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1838,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.706Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"2021-12-22 2.5 Added use case for change in fund management (4.18). | GLEIF\nProvide additional clarification on existing rules and\nguidelines (2,2,3, 2.8, 3.24, 3.29, 3.33, 3.36, 3.51, 3.61,\n4.2,4.4,4.7,4.13.1,4.13.3,4.13.4, 4.13.5, 4.13.8,\n4.13.9,4.13.13, 4.13.15, 4.13.16, 4.13.19, 4.21)\n\n2021-09-30 2.4 Provide additional clarification on existing rules and GLEIF\nguidelines (3.36, 3.51, 3.53 several use cases in chapter\n4)\n\nReflect changes due to Repex-CDF 1.2 (3.65, 4.14) and\ndeprecation of the Provisional Node Identifier (PNI)\n(2.1.2,2.2.2,3.49,4.1.2,4.8,4.9,4.13.22, 4.18, 4.20)\nIntroduction of RA777777 (2.2.3, 3.44, 3.45, 3.46, 4.6,\n4.7)\n\n2021-06-21 2.3 Provide additional clarification on existing rules and GLEIF\nguidelines (3.20, 3.23, 3.30, 3.46, 3.57, 4.18)\n\n2021-03-08 2.2 Introduced changes due to ROC policy on Government | GLEIF\nEntities and International Organizations (3.22, 3.23,\n3.53,4.6,4.7)\n\nProvide additional clarification on existing rules and\nguidelines\n\n2020-12-17 2.1 Highlight text elements and paragraphs with the CDF GLEIF\nformat version when these become effective\nProvide additional clarification on existing rules and\nguidelines (2.2, 2.3, 3.20, 3.26, 4.1, 4.11)\n\n2020-07-31 2.0 Updated general structure of the document GLEIF\nCombined STVR for Level 1 and Level 2\nUpdated general rules in chapter 2 to clarify existing\nrules and guidelines (2.2, 2.3, 2.7, 2.8, 2.9)\n\nIncluded per element description and rules for relevant\n\nXML elements in chapter 3.\n\nRevised existing and added new Use Cases in chapter 4.\n\nIntroduced changes due to LEI-ROC Fund Relationship\n\npolicy implementation (2.1.2, 3.50)\n\nIntroduced changes due to LEI-ROC Legal Entity Events\n\npolicy implementation (new elements 3.27-3.36)\n\nUpdated description and rules for EntityCategory (3.22)\n\nUpdated description and rules for EntityStatus (3.24)\nState Transition and Validation Rules for Common Data File formats Page 7 of 170\n\n@ Public Version 2.7.1 Final\n\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2036,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.706Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"+ CHANGE_LEGAL_NAME\n+ CHANGE_OTHER_NAMES\n¢ CHANGE_LEGAL_FORM\no BANCRUPTCY\n¢ LIQUIDATION\no If the SuccessorLEl is provided, the SuccessorEntityName SHALL NOT be present and vice versa.\no If the SuccessorLEl is provided, it SHALL NOT have the same LEI as the replaced entity’s LEI\nRecord.\n3.28 Legal Entity Events\n_ lei:LegalEntityEvents\nContainer for a finite number of events specified by the LEI ROC in\nthe life of a Legal Entity that would impact the Reference Data in the\nGlobal LEI System.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity\n/lei:LegalEntityEvents\n¢ The container Legal Entity Events SHALL be provided, when at least one of the Legal Entity Event\ntypes in scope occurred.\no The container SHALL contain at least one Legal Entity Event instance or one Legal Entity Event\nGroup instance.\nState Transition and Validation Rules for Common Data File formats Page 61 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":991,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.706Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.29 Legal Entity Event\n_ lei:LegalEntityEvents\nContainer for a finite number of events specified by the LEI ROC in\nthe life of a Legal Entity that would impact the Reference Data in the\nGlobal LEI System.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity\n/lei:LegalEntityEvents\ne Each Legal Entity Event container SHALL include two to four attributes, associated with event\nstatus and grouping of Legal Entity Events:\no @group_type: This mandatory attribute defines, whether or not this Legal Entity Event is\npart of a group of events. Allowed enumerations:\n\no STANDALONE: Single / standalone Legal Entity Event with no combination of multiple\nevents.\n\no CHANGE_LEGAL_FORM_AND_NAME: Legal Entity Event including change of the legal\nname triggered by change of the legal form.\n\no COMPLEX_CHANGE_LEGAL_FORM: Legal Entity Event including change of the Legal\nEntity status triggered by change of the legal form.\n\ne REVERSE_TAKEOVER: This event is part of a reverse takeover Legal Entity Event.\n\no @event_status: This mandatory attribute defines the status of the Legal Entity Event with\nregard to the event timeline. Allowed enumerations:\n\n* IN_PROGRESS: The Legal Entity Event activity and processing is in progress.\n\no WITHDRAWN_CANCELLED: The Legal Entity Event as announced will not occur.\n\no COMPLETED: The Legal Entity Event activity and processing have been completed as of\nthe LegalEntityEventEffectiveDate.\n\no @group_id: An identifier assigned to link events that are part of the same group of multiple\nor complex events:\n\ne SHALL be the exact same string for all events linked together.\n\ne SHALL be provided for events having a @group_type\nCHANGE_LEGAL_FORM_AND_NAME or REVERSE_TAKEOVER and SHALL NOT be\npopulated for events having a @group_type STANDALONE or\nCOMPLEX_CHANGE_LEGAL_FORM events.\n\nState Transition and Validation Rules for Common Data File formats Page 62 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1989,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.706Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"e @group_sequence_no: A number which indicates the sequence of each Legal Entity Event\nwithin a group of events.\ne SHALL NOT be populated for STANDALONE events.\ne SHALL be provided for event groups with a logical sequence of events, like a\nREVERSE_TAKEOVER event group.\ne SHALL NOT be populated, if the event sequence is not important as all events happen at\nthe exact same time, for example a change in legal name due to a change in legal form\n(event type CHANGE_LEGAL_FORM_AND_NAME).\n¢ The event that happened first SHALL have @group_sequence_no 1 (one), the next 2\n(two), etc. Each @group_sequence_no SHALL be used only once within a group.\n¢ Inorder to describe Legal Entity Events, each Legal Entity Event container SHALL contain the\nfollowing fields:\no LegalEntityEventType\no LegalEntityEventEffectiveDate\no LegalEntityEventRecordedDate\n* ValidationDocuments\n¢ ValidationReference (optional)\no AffectedFields\no LegalEntityEvent elements SHALL NOT be updated.\n¢ Anew LegalEntityEvent element SHALL be created, if an already existing LegalEntityEvent\nchanges its @event_status from IN_PROGRESS to COMPLETED or WITHDRAWN_CANCELLED.\no A LegalEntityEvent with @event_status IN_PROGRESS SHALL NOT be removed in case a\nfollow up event with @event_status COMPLETED or WITHDRAWN_CANCELLED is introduced.\ne A LegalEntityEvent MAY be updated, if only typing errors or similar minor inconsistencies are\nremediated.\nState Transition and Validation Rules for Common Data File formats Page 63 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1592,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.706Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.30 Legal Entity Event Type\n_ lei:LegalEntityEventType\n_ The type of Legal Entity Event.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/\nlei:LegalEntityEvents/lei:LegalEntityEvent/\nlei:LegalEntityEventType\no Legal Entity Event Type SHALL be always provided as part of the descriptive data of a Legal Entity\nEvent\n¢ The following types of Legal Entity Events SHALL be recorded in the Global LEI System as part of\nthe LEI Record Set. Data collection for high priority Legal Entity Events SHALL begin with the\n\nimplementation of LEI-CDF 3.1. Events with a medium or low priority SHALL be collected at a\n\nlater date but MAY also be included earlier.\n\ne High priority Legal Entity Events (to be implemented by 31 March 2022):\n\no CHANGE_LEGAL_NAME: Change in the legal name of the Legal Entity.\n\ne CHANGE_OTHER_NAMES: Change in the trade- or doing business name of the Legal Entity.\n\no CHANGE_LEGAL_ADDRESS: Change in the legal address of the Legal Entity.\n\no CHANGE_HQ_ADDRESS: Change in the Headquarters Address of the Legal Entity.\n\no CHANGE_LEGAL_FORM: Change in the legal form of the Legal Entity.\n\ne ACQUISITION_BRANCH: The acquiring Legal Entity purchases an International Branch entity.\n\no TRANSFORMATION_BRANCH_TO_SUBSIDIARY: The transfer of all of the assets and liabilities\nof a Legal Entity in relation to an International Branch to the new Subsidiary entity in\nexchange for the transfer of securities representing the capital of the Subsidiary entity\nreceiving the transfer.\n\no TRANSFORMATION_SUBSIDIARY_TO_BRANCH: The transfer of all of the assets and liabilities\nof a Subsidiary to an International Branch entity in exchange for the transfer of securities of\nthe Legal Entity to which the Branch belongs, representing the capital of the International\nBranch entity receiving the transfer.\n\no TRANSFORMATION_UMBRELLA_TO _STANDALONE: Change in legal form from a Fund Legal\nEntity structure with one or more than one sub-funds/compartments to a Fund Legal Entity\nstructure without sub-funds/compartments.\n\nState Transition and Validation Rules for Common Data File formats Page 64 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2204,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.706Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o DISSOLUTION: (i) A voluntary termination of operations, (ii) a general assignment for the\nbenefit of the Legal Entity’s creditors or (iii) any other liquidation, dissolution or winding up\nof the Legal Entity (excluding a Liquidity Event), whether voluntary or involuntary.\n\n¢ Medium priority Legal Entity Events (TBD):\n\n» BREAKUP: A break-up is a corporate action in which a single company splits into two or more\nindependent, separately run companies. Regulators also can mandate break-ups of\ncompanies for anti-trust reasons.\n\no MERGERS_AND_ACQUISITIONS: The consolidation of Legal Entities or assets through various\ntypes of financial transactions, including mergers, acquisitions, consolidations, tender offers,\npurchase of assets and management acquisitions.\n\no DEMERGER: Distribution of securities issued by another Legal Entity. The distributed\nsecurities may either be of a newly created or of an existing Legal Entity. For example, spin-\noff, demerger, unbundling, divestment.\n\no SPINOFF: A special case of demerger where the shareholders of the original entity are\ncompensated for the value loss of the original entity via shares of the new entity or via\ndividend.\n\no Low priority Legal Entity Events (TBD):\n\no BANKRUPTCY: Legal status of a Legal Entity unable to pay creditors. Bankruptcy usually\ninvolves a formal court ruling. Securities may become valueless.\n\n¢ LIQUIDATION: Distribution of cash, assets or both of a Legal Entity. Debt may be paid in order\nof priority based on preferred claims to assets specified by the security.\n\no VOLUNTARY_ARRANGEMENT: A procedure that allows a Legal Entity to settle debts by\npaying only a proportion of the amount that it owes to creditors or to come to some other\narrangement with its creditors over the payment of its debts.\n\no INSOLVENCY: The entry of a decree or order by a court or agency or supervisory authority\nhaving jurisdiction in the premises the appointment of a trustee-in-bankruptcy or similar\nofficial for such party in any insolvency, readjustment of debt, marshalling of assets and\nliabilities, or similar proceedings, or for the winding up or liquidation of their respective\naffairs.\n\no ABSORPTION: Absorption is a form of merger where there is a combination of two or more\ncompanies into an 'existing company'. In the case of absorption, only one company survives,\nand all others lose their identity. (The addition of Absorption to the list of Legal Entity Events\ncovered by the policy is under review with the LEI-ROC.)\n\no REVERSE_TAKEOVER: A reverse takeover is the acquisition of a larger, publicly traded\ncompany by a smaller private company. It involves complex series of events including\nacquisition, absorption and name change.\n\nState Transition and Validation Rules for Common Data File formats Page 65 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2896,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.707Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.31 Legal Entity Event Effective Date\n\n_ lei:LegalEntityEventEffectiveDate\n\n_ The date when the Legal Entity Event becomes legally effective.\n\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/\nlei:LegalEntityEvents/lei:LegalEntityEvent/lei:/\nlei:LegalEntityEventEffectiveDate\n\no LegalEntityEventEffectiveDate SHALL provide the date (not considering the time) when the Legal\nEntity Event becomes legally effective, if the date is known or in the past (event_status\nCOMPLETED).\n\no LegalEntityEventEffectiveDate MAY be omitted, if the date is not known (applies only, if the\nevent_status of the Legal Entity Event is IN_PROGRESS or WITHDRAWN_CANCELLED). If the date\nis known for not yet completed Legal Entity Events, LegalEntityEventEffectiveDate SHALL be\nprovided.\n\ne The format SHALL be according to the ISO 8601 standard. The time part of the content SHALL be\nalways '00:00:00' independent of the provided Time Zone.\n\no LegalEntityEventEffectiveDate SHALL be provided as part of the descriptive data of a Legal Entity\nEvent.\n\no LegalEntityEventEffectiveDate SHALL be limited to dates after 0001-01-01T00:00:00.\n\no LegalEntityEventEffectiveDate MAY be equal to LegalEntityEventRecordedDate if the actual\nLegalEntityEventEffectiveDate is not known.\n\nState Transition and Validation Rules for Common Data File formats Page 66 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1437,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.707Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.32 Legal Entity Event Recorded Date\n_ lei:LegalEntityEventRecordedDate\nThe date when the Legal Entity Event was recorded in the Global LEI\nSystem\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/\nlei:LegalEntityEvents/lei:Legal EntityEvent/\nlei:LegalEntityEventRecordedDate\no LegalEntityEventRecordedDate SHALL be always provided as part of the descriptive data of a\nLegal Entity Event.\no LegalEntityEventRecordedDate SHALL provide the date and timestamp when the Legal Entity\nEvent was recorded in the Global LEI System.\no Ifthe event_status is COMPLETED, LegalEntityEventRecordedDate SHALL be equal to, or after the\nLegalEntityEventEffectiveDate.\n3.33 Validation Documents (context: LEI-CDF)\n_ lei:ValidationDocuments\nType of source document(s) used for validating the\nLegal Entity Event.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/\nlei:LegalEntityEvents/lei:Legal EntityEvent/\nlei:ValidationDocuments\no The type of Validation documents used to corroborate the Legal Entity Event SHALL be provided.\ne Currently accepted type of documents to validate Legal Entity Events are:\no ACCOUNTS_FILING: A consolidated financial (accounting) statement, prepared and submitted\nto the relevant authority.\nState Transition and Validation Rules for Common Data File formats Page 67 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1394,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.707Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"¢ REGULATORY_FILING: A regulatory filing providing public information on Legal Entities\nand/or their relationships (e.g.: documents submitted to a (financial) regulator).\ne SUPPORTING_DOCUMENTS: Other documents supporting the validation of Legal Entities\nand/or their relationships (e.g.: business registers or other authoritative sources).\no CONTRACTS: Contract(s) attesting to the validity of Legal Entities and/or their relationships.\no OTHER_OFFICIAL_DOCUMENTS: Other official document(s) attesting to the validity of Legal\nEntities and/or their relationships (e.g.: notarized documents).\n3.34 Validation Reference (context: LEI-CDF)\n_ lei:ValidationReference\nA reference to a specific document or other source used as the basis\nof validation for this Legal Entity Event.\nlei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/\nlei:LegalEntityEvents/lei:Legal EntityEvent/\nlei:ValidationReference\no The content of ValidationReference SHALL contain a reference to a specific document or other\nsource used as the basis of Legal Entity Event Validation for this record.\n3.35 Affected Fields\nA list of LEI Record Set elements that are expected to be updated in\nthe LEI Record Set as a result of a Legal Entity Event.\nlei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/\nlei:LegalEntityEvents/lei:LegalEntityEvent/\nlei:AffectedFields\nAffectedFields is a container element including one or more AffectedField elements.\nState Transition and Validation Rules for Common Data File formats Page 68 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1597,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.707Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o This container SHALL include all relevant changes to the LEI Record Set due to the Legal Entity\nEvent.\n\no This container can only exist within a Legal Entity Event element.\n\n3.36 Affected Field\n\nA single element and its value that is expected to be updated in the\nLEl Record Set as a result of a Legal Entity Event.\nlei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/\nlei:LegalEntityEvents/lei:LegalEntityEvent/\nlei:AffectedFields/lei:AffectedField\n\nEach AffectedField refers to an LEI Record Set element that will be affected by the Legal Entity Event.\n\no AffectedField SHALL include an attribute (@field_xpath), referring to the full Xpath to a single\nelement that is expected to be updated in the LEI Record Set as a result of a Legal Entity Event.\n\no The value of AffectedField SHALL be the expected value of the data element due to Legal Entity\nEvent. Values for Legal Entity Events in progress (@event_status IN_PROGRESS) MAY not be\nalways available, but the LEl issuer SHALL report these elements if available.\n\no For events with @event_status COMPLETED, leading to the introduction of one or more\nSuccessorEntitiy entries, AffectedFields SHALL be provided, presenting the values of the recorded\nsuccessor entities.\n\no If no SuccessorEntity was introduced due to the Legal Entity Event with @event_status\nCOMPLETED or WITHDRAWN_CANCELLED, AffectedFields SHALL NOT be provided.\n\no Expected values for the attribute @field_xpath are:\n\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:LegalName\n\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:OtherEntityNames/lei:OtherEntityNam\ne\n\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:OtherEntityNames/lei:OtherEntityNam\ne@type\n\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:TransliteratedOtherEntityNames/lei:Tr\nansliteratedOtherEntityName\nState Transition and Validation Rules for Common Data File formats Page 69 of 170\n\n@ Public Version 2.7.1 Final\n\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2024,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.707Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:TransliteratedOtherEntityNames/lei:Tr\nansliteratedOtherEntityName@type\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:LegalAddress/*\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:HeadquartersAddress/*\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:OtherAddresses/*\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:TransliteratedOtherAddresses/*\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:Legallurisdiction\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:EntityCategory\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:LegalForm/lei:EntityLegalFormCode\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:LegalForm/lei:OtherLegalForm\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:SuccessorEntity/lei:SuccessorLEl\no /lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity/lei:SuccessorEntity/lei:SuccessorEntityNa\nme\no /rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord/rr:Relationship/rr:EndNo\nde/rr:NodelD\no /rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord/rr:Relationship/rr:EndNo\nde/rr:NodeType\no /rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord/rr:Relationship/rr:Relatio\nnshipType\no /[repex:ReportingExceptionData/repex:ReportingExceptions/repex:Exception/repex:Exceptio\nnCategory\no /[repex:ReportingExceptionData/repex:ReportingExceptions/repex:Exception/repex:Exceptio\nnReason\ne For all above mentioned address containers (LegalAddress, HeadquartersAddress,\nOtherAddresses and TransliteratedOtherAddresses) the concrete data elements SHALL be\nprovided.\nState Transition and Validation Rules for Common Data File formats Page 70 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1851,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.707Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Updated description and rules for SuccessorEntity\n(3.26)\nUpdate description and rules for RelationshipStatus\n(3.52)\nDeprecated AssociatedEntity (3.67),\nEntityExpirationDate (3.68) and EntityExpirationReason\n(3.69)\nClarification on branch entities (4.2)\n2018-01-26 1.2 2.2.5 — updated as ELF code list is now available GLEIF\n2.8 - 2\" bullet point updated from\nIf ValidationSources is ENTITY_SUPPLIED_ONLY then\nValidationAuthorityID and ValidationAuthorityEntitylD\nMUST NOT be populated to\nIf ValidationSources is ENTITY_SUPPLIED_ONLY then\nValidationAuthorityID is RA999999\n2.9 — last bullet point: added or RA999999 has been\nentered). In these cases, OtherRegistrationAuthoritylD\nmay provide information on the documents supplied\nby the Legal Entity for Validation.\n3.1 - LegalName: added in the local language and\ncharacter set.\n3.2 — LegalAddress: added This is the jurisdiction of\nlegal formation and registration of the branch entity.\n3.16 — added If the LEI-CDF record is also a head office\nthen the associated branch entities must all be in\nstatus ISSUED following the renewal of the head office\nLEI.\n2017-05-04 1.1 2.2: added included in Originator GLEIF\n2.4: updated\n2.6: replaced relationships with LEls\n2.9: updated\n2.11: removed PENDING\n3.8: added branches\n3.17: added branches\n2016-11-30 1.0 Final version GLEIF\nState Transition and Validation Rules for Common Data File formats Page 8 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1505,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.707Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.37 Initial Registration Date (context: LEI-CDF)\n\n_ lei:InitialRegistrationDate\nThe date of the first LEl assignment, being the date of publication of\nthe identifier and its supporting data record as represented in I1SO\n8601.\n\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Registration/lei:InitialRegistrationDate\n\n¢ InitialRegistrationDate SHALL be set with the date when the LEI Record transits from the internal,\n\nnot published status PENDING_VALIDATION to ISSUED.\n\ne Once set, InitialRegistrationDate SHALL NOT be updated. This applies also when the LEI Record\n\nSet is being transferred to a different LEI issuer.\n\no The InitialRegistrationDate SHALL NOT be later than LastUpdateDate or NextRenewalDate.\n\n3.38 Last Update Date (context: LEI-CDF)\n\n_ Date/time the LEI Record was most recently updated.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Registration/lei:LastUpdateDate\n\n* Any update to an LEl record SHALL be indicated by setting the LastUpdateDate to the date the\n\nupdate occurred.\n\no There SHALL be at least one other field in the record that changed when LastUpdateDate is\n\nupdated.\n\no There SHALL NOT be any update to any other field without also an update to LastUpdateDate.\n\no LastUpdateDate SHALL NOT be earlier than InitialRegistrationDate.\n\no lastUpdateDate SHALL NOT be a date in the future.\n\nState Transition and Validation Rules for Common Data File formats Page 71 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1503,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.708Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.39 Registration Status (context: LEI-CDF)\n_ lei:RegistrationStatus\nThe status of the Legal Entity's LEI registration with the\nManagingLOU.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Registration/lei:RegistrationStatus\n\nThe element RegistrationStatus describes the status of the LEI registration.\n\no If RegistrationStatus is ISSUED, then EntityStatus SHALL be ACTIVE and ValidationSources SHALL\nNOT be PENDING.\n\no If RegistrationStatus is ISSUED, then NextRenewalDate SHALL be greater than or equal to the\nContentDate of the XML file.\n\no If RegistrationStatus is LAPSED, then NextRenewalDate SHALL be earlier than ContentDate.\n\no If the RegistrationStatus is LAPSED, the LEI Reference Data MAY still be updated.\n\no If RegistrationStatus is DUPLICATE, then SuccessorEntity SHALL be populated.\n\no If RegistrationStatus is ANNULLED, then SuccessorEntity MAY be populated.\n\no If the RegistrationStatus is RETIRED, no further updates to Entity sections of registration records\nin these states SHALL occur. Exceptions are allowed for updated information about the correct\nstatus, mapping to new code lists or ensuring high data quality of the record.\n\no MERGED — DEPRECATED .\n\n3.40Next Renewal Date (context: LEI-CDF)\n\n_ lei:NextRenewalDate\n\nThe next date by which the LEI registration should be renewed and\nre-certified by the Legal Entity.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Registration/lei:NextRenewalDate\n\no NextRenewalDate SHALL be later than InitialRegistrationDate.\n\nState Transition and Validation Rules for Common Data File formats Page 72 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1669,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.708Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"* NextRenewalDate SHALL NOT be later than ContentDate plus one year and sixty days.\n3.41 Managing LOU (context: LEI-CDF)\nThe LEI of the LOU that is responsible for administering this LEI\nregistration.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Registration/lei:ManagingLOU\nManagingLOU identifies the LEl issuer currently managing the LEI Record.\n¢ ManagingLOU SHALL be populated with the LEI of the LEl issuer.\n¢ ManagingLOU SHALL be populated with the LEI of a GLEIF Accredited LEl issuer for all LElI Record\nSet files published. Exceptions are allowed only for Candidate LEl issuers during testing and\nonboarding.\n¢ ManagingLOU SHALL be identical to the Originator in the file header for all LEI Record Sets\nuploaded to GLEIF.\n3.42 Validation Sources (context: LEI-CDF)\n_ lei:ValidationSources\nThe level of Validation of the Reference Data provided by the\nregistrant.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Registration/lei:ValidationSources\nThe LEl issuer notes the level of Validation in the Reference Data via the element ValidationSources:\no If ValidationSources is either PARTIALLY_CORROBORATED or FULLY_CORROBORATED then a\nspecific ValidationAuthoritylD SHALL be populated and which SHALL be different from RA999999\nand RA888888. The ValidationAuthorityEntitylD SHALL be populated given the register is\navailable for publication.\nState Transition and Validation Rules for Common Data File formats Page 73 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1533,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.708Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o If ValidationSources is ENTITY_SUPPLIED_ONLY then ValidationAuthoritylD SHALL be either\nRA999999 or RA888888.\no If ValidationSources is set to PENDING, then the LEIl record SHALL NOT be published and is only\nfor internal LOU use.\no The general rules laid out in section 2.2 SHALL apply.\n3.43 Validation Authority\n_ lei:ValidationAuthority\nInformation about the (primary) official authority in the Legal Entity's\njurisdiction of legal registration, for example a business registry, and\nthe corresponding identification of the Legal Entity by that official\nsource used to validate the Legal Entity Reference Data.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Registration/lei:ValidationAuthority\ne The container ValidationAuthority SHALL be provided and the LEl issuer is responsible to supply\nthe related information according to the rules described in section 2.2.\n3.44 Validation Authority ID\n_ lei:ValidationAuthoritylD\nThe reference code of the Registration Authority, taken from the\nRegistration Authorities Code List (RA list) maintained by GLEIF.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Registration/lei:ValidationAuthority\n/lei:ValidationAuthorityID\n¢ ValidationAuthoritylD SHALL be populated with a valid code from the Registration Authorities list\n(see section 2.2).\no For LEI Records that are not validated against a registry, ValidationAuthoritylD SHALL be\nRA999999.\nState Transition and Validation Rules for Common Data File formats Page 74 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1572,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.708Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o For Government Entities and International Organizations, RA777777 SHALL be used in case there\nis no information available in any regular registration authority and Public Legal Documents are\nused instead for partially or fully corroborated records.\n\n3.45 Other Validation Authority ID\n\n_ lei:OtherValidationAuthoritylD\n\nA legacy / historical reference code of a Registration Authority which\nis not yet entered in the Registration Authorities Code List (RA list)\nmaintained by GLEIF, or the designation of an interim register until\nsuch time as an entry from RA list can be delivered.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Registration/lei:ValidationAuthority\n/lei:OtherValidationAuthoritylD\n\no OtherValidationAuthoritylID MAY be present when ValidationAuthoritylID is populated.\n\no If ValidationAuthorityID is RA888888, OtherValidationAuthoritylD SHALL include the name of the\nRegistration Authority, as submitted in the request sent to GLEIF to add a new code to the RA list\n(see section 2.2).\n\no If ValidationAuthorityID is RA777777, OtherValidationAuthoritylD SHALL include the name and\nreference and where possible the link to the documents used for corroboration.\n\nState Transition and Validation Rules for Common Data File formats Page 75 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1364,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.708Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.46 Validation Authority Entity ID\n\n_ lei:ValidationAuthorityEntitylD\nThe identifier of the entity at the indicated Registration Authority.\nTypically, the identifier of the Legal Entity as maintained by a\nbusiness registry in the jurisdiction of legal registration, or if the\nentity is one that is not recorded in a business registry (e.g., one of\nthe varieties of funds registered instead with financial regulators),\nthe identifier of the entity in the appropriate Registration Authority.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Registration/lei:ValidationAuthority\n/lei:ValidationAuthorityEntitylD\n\no If the Registration Authority used for Validation provides an entity ID,\n\nValidationAuthorityEntitylD SHALL be populated with the entity ID from the authoritative source.\n\no If the authoritative source does not provide an entity ID, ValidationAuthorityEntitylD SHALL NOT\n\nbe included.\n\no IfRA777777 or RA888888 is used, the ValidationAuthorityEntitylD MAY be provided depending\n\non the source.\n\n¢ ValidationAuthorityEntityID SHALL NOT be populated, if ValidationAuthoritylD is RA999999 or\n\none of the RA Codes identifying sources known to not providing an entity ID.\n\n3.47 Other Validation Authorities\n\n_ lei:OtherValidationAuthorities\nAn optional list of additional Registration Authorities used by the LEI\nissuer to validate the entity data.\n\n_ {0,1} with {1,n} lei:OtherValidationAuthority included\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Registration/lei:OtherValidationAuthorities\n\ne OtherValidationAuthorities is a container that MAY be included to provide information about\n\nadditional Validation Authorities used for Validation.\nState Transition and Validation Rules for Common Data File formats Page 76 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1838,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.708Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o All subsets in OtherValidationAuthorities MAY repeat the same source as ValidationAuthority in\ncase the source uses different local identifiers for the same legal entity.\no Every subset in OtherValidationAuthorities SHALL be unique within this registration.\no OtherValidationAuthorities SHALL NOT include any subset having ValidationAuthorityID as\nRA999999.\n3.48 Start Node\n_ An LEI for the Legal Entity at the start of a directional relationship.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Relationship/rr:StartNode\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Relationship/rr:StartNode/rr:NodelD\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Relationship/rr:StartNode/rr:NodeType\nThe StartNode identifies the entity which is, where applicable, the child or lower node of a\nhierarchical relationship.\no StartNode/NodelD SHALL be the LEI of the child entity in the relationship.\no StartNode/NodeType SHALL be LEI.\no StartNode/NodelD SHALL be different from EndNode/NodelD.\nState Transition and Validation Rules for Common Data File formats Page 77 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1234,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.709Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.49 End Node\nAn LEl or ISO 17442-compatible ID for the Legal Entity at the end of a\ndirectional relationship.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Relationship/rr:EndNode\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Relationship/rr:EndNode/rr:NodelD\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Relationship/rr:EndNode/rr:NodeType\nThe EndNode identifies the entity which is, where applicable, the parent or higher node of a\nhierarchical relationship.\n¢ EndNode/NodelD SHALL be the LEI of the direct or ultimate accounting consolidating parent\nentity in the relationship.\no EndNode/NodelD SHALL be different from the StartNode/NodelD.\n© EndNode/NodeType SHALL be LEI in case the EndNode/NodelD contains an LEI.\n3.50 Relationship Type\nA unique code designating the specific category of a directional\nrelationship between two Legal Entities.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Relationship/rr:RelationshipType\no RelationshipType SHALL specify relationship between the StartNode and the EndNode.\nCurrently, three use-cases for relationships exist in the Global LEI System:\n1. Accounting Consolidating Parent Relationship:\nState Transition and Validation Rules for Common Data File formats Page 78 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1421,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.709Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o For the direct accounting consolidating parent, RelationshipType SHALL be\nIS_DIRECTLY_CONSOLIDATED_BY\n\ne For the ultimate accounting consolidating parent, RelationshipType SHALL be\nIS_ULTIMATELY_CONSOLIDATED_BY\n\n2. International Branch Relationship:\n\n¢ The RelationshipType SHALL be IS_INTERNATIONAL_BRANCH_OF for a Branch entity when\nconnecting to its head office.\n\nBoth above-mentioned use-cases are mutually exclusive; if an active consolidating relationship is\npresent, there cannot be an active Branch Relationship and vice versa.\n3. Fund Relationships are (see Figure 6) :\n\n¢ RelationshipType SHALL be IS_FUND-MANAGED_BY, if the StartNode is a fund managed by a\nmain management entity in a Fund Management Entity relationship. The EndNode is legally\nresponsible for the constitution and operation of the fund.\n\no RelationshipType SHALL be IS SUBFUND_OF, if the StartNode is a sub-fund to an umbrella\nfund in an Umbrella Structure relationship. The EndNode is a Legal Entity with one or more\nthan one sub-funds/compartments where each sub-fund/compartment has its own\ninvestment objectives, separate investment policies and strategies, segregation of assets,\nseparate investors and which has segregated liability between sub-funds/compartments.\n\no RelationshipType SHALL be IS_FEEDER_TO, if the StartNode is a Feeder Fund, that is (almost)\nexclusively invested in a single other fund in a Master-Feeder Relationship. The EndNode is\nthe Master Fund that has identical investment strategies.\n\n4 \\\nISSUBFWbERTO\nIS_FUND-MANAGED_BY \\\n\\_{/\nFigure 6: Fund Relationship types\n\nState Transition and Validation Rules for Common Data File formats Page 79 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1759,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.709Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.51 Relationship Periods\nA collection of paired beginning and end dates relating to the\nrelationship itself, periods (e.g., accounting cycles) covered by\ndocuments demonstrating the relationship, or the filing date(s) of\nthose documents.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Relationship/rr:RelationshipPeriods\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Relationship/rr:RelationshipPeriods/rr:StartDate\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Relationship/rr:RelationshipPeriods/rr:EndDate\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Relationship/rr:RelationshipPeriods/rr:PeriodType\nRelationshipPeriods contain three elements:\no StartDate: Date the relationship begins\no EndDate: Date the relationship ends\no PeriodType: The kind of relationship period\n¢ The StartDate of a RelationshipPeriod SHALL NOT be later than the EndDate, if provided.\no The StartDate SHALL NOT be later than the Relationship Record’s LastUpdateDate.\no The StartDate SHALL NOT be earlier than the LEI Record’s EntityCreationDate.\no Relationship Records can have multiple RelationshipPeriods simultaneously, but only one at a\ntime for any given PeriodType.\no ARelationshipPeriod SHALL always include StartDate and PeriodType. EndDate is optional and\nSHALL NOT be provided if the period has no defined EndDate or the date is unknown.\no All Relationship Records SHALL include exactly one RelationshipPeriod with PeriodType\nRELATIONSHIP_PERIOD.\nState Transition and Validation Rules for Common Data File formats Page 80 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1716,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.709Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"All changes made during creation (for clarity and reading ease as well as significant changes),\nincrease the version number by 0.1.\nThe approved PID is considered to be the final version and gets version number 1.0.\nState Transition and Validation Rules for Common Data File formats Page 9 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":398,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.709Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o Relationships with RelationshipType IS_DIRECTLY_CONSOLIDATED_BY and\nIS_ULTIMATELY_CONSOLIDATED_BY SHALL include one RelationshipPeriod with PeriodType\nACCOUNTING_PERIOD.\n\no Relationships with RelationshipType IS_INTERNATIONAL_BRANCH_OF MAY include one\nRelationshipPeriod with PeriodType ACCOUNTING_PERIOD.\n\no Relationships with RelationshipType IS_FUND-MANAGED_BY, IS_SUBFUND_OF and\nIS FEEDER_TO SHALL NOT include any RelationshipPeriod with PeriodType\nACCOUNTING_PERIOD.\n\no Relationship Records MAY include one RelationshipPeriod with PeriodType\nDOCUMENT_FILING_PERIOD.\n\nRelationshipPeriod with PeriodType = RELATIONSHIP_PERIOD\n\nIndicates the duration of the relationship itself, regardless of when the relationship was first included\n\nin the Global LEI System. The StartDate would indicate the earliest date at which the relationship\n\nexisted. If that information is not available or exactly known, it SHALL be the earliest date where the\nvalidity of the relationship could be corroborated. Usually, this date will be earlier than the\n\nInitialRegistrationDate of the relationship. For ACTIVE relationships, EndDate SHALL NOT be included,\n\nwhile for INACTIVE relationships, EndDate SHALL be populated with the last date the relationship\n\nexisted. StartDate and, once provided, EndDate would not generally be updated, unless the originally\nrecorded date was incorrect.\n\nRelationshipPeriod with PeriodType = ACCOUNTING_PERIOD\n\nIndicates the time period reflected in the source document (generally distinct from the date of the\n\ndocument) and is intended to indicate the accounting period covered by the most recent Validation\n\ndocuments. The accounting period for relationships based on accounting consolidation SHALL be\nupdated with the latest accounting period during renewals.\n\nRelationshipPeriod with PeriodType = DOCUMENT_FILING_PERIOD\n\nIndicates the date of the document filing or publication. This only applies where the Validation\n\ndocuments are filed or publicly available. The StartDate SHALL be the date of document filing or\n\npublication.\n\nIf the Validation documents also indicate the period over which the filing applies, the EndDate SHALL\n\nbe the end date of this period. Although entities should be encouraged to provide the exact dates\n\nwhen known, start and end dates MAY be approximated by the date of the situation described in the\nfirst accounting statement showing consolidation or the end of consolidation, respectively. For\ninstance, what is sought here is not that the accounting statement used for Validation is for the year\n\n2019, but that the relationship was valid at least as of 31 December 2019.\n\nState Transition and Validation Rules for Common Data File formats Page 81 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2812,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.709Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.52 Relationship Status\n_ rr:RelationshipStatus\nThe status of the Legal Entities' relationship itself: ACTIVE, INACTIVE\nor NULL.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Relationship/rr:RelationshipStatus\no RelationshipStatus SHALL reflect the status of the relationship.\n¢ RelationshipStatus SHALL be ACTIVE if both Legal Entities are operational and the relationship\nbetween them is current and verified.\no RelationshipStatus SHALL be INACTIVE if one of the Legal Entities ceased to exist or the\nrelationship is no longer current.\no RelationshipStatus SHALL be NULL if the RegistrationStatus of the Relationship Record is\nDUPLICATE or ANNULLED .\no RelationshipStatus MAY be NULL in the exceptional case of a fund in formation (see chapter 4.4).\n3.53 Relationship Qualifiers\n_ rr:RelationshipQualifiers\nAny additional qualitative attributes that help to categorize\nthe relationship.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Relationship/rr:RelationshipQualifiers\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord/r\nr:Relationship/rr:RelationshipQualifiers/rr:RelationshipQualifier/rr:Q\nualifierDimension\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord/r\nr:Relationship/rr:RelationshipQualifiers/rr:RelationshipQualifier/rr:Q\nualifierCategory\nState Transition and Validation Rules for Common Data File formats Page 82 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1519,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.709Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"Definitions of accounting consolidation and other relationship types could vary by jurisdiction. The\nLegal Entity reports the accounting consolidation, which is verified by the LEl issuer. Available values\nare:\n\no rr:QualifierDimension:\n\ne ACCOUNTING_STANDARD: The accounting standard applied to determine the definition of\ne.g., ultimate or direct accounting consolidating parent for the relationship detailed in this\nRelationshipRecord. The relevant accounting standard is that applicable to the EndNode (the\n\"parent” entity).\n\ne rr:QualifierCategory:\n\no US_GAAP: United States-Generally Accepted Accounting Principles.\n\no IFRS: International Financial Reporting Standard (developed by the International Accounting\nStandards Board — IASB see http://www.ifrs.org)\n\no OTHER_ACCOUNTING_STANDARD: A financial reporting (accounting) standard not otherwise\nlisted in the latest version of the relationship data file format.\n\no GOVERNMENT_ACCOUNTING_STANDARD: Used for entities consolidated under the\nInternational Public Sector Accounting Standard (IPSAS 35) or National Government or\nFederal Government accounting standards specifically developed for Government entities in\ntheir state or local jurisdiction.\n\nThe declaration of the consolidating standards SHALL follow below rules and hierarchies:\n\n* International standards SHALL overrule local GAAPs.\n\no The GOVERNMENT_ACCOUNTING_STANDARD SHALL be used only when both StartNode and\nEndNode are categorized as RESIDENT_GOVERNMENT_ENTITY or\nINTERNATIONAL_ORGANIZATION, respectively.\n\no Entities categorized as RESIDENT_GOVERNMENT_ENTITY SHALL declare direct and ultimate\nparent only by GOVERNMENT_ACCOUNTING_STANDARD; none of the other accounting\nstandards SHALL be used.\n\nState Transition and Validation Rules for Common Data File formats Page 83 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1906,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.709Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.54 Relationship Quantifiers\n_ rr:RelationshipQuantifier\nAny additional quantitative attributes that help to categorize\nthe relationship.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Relationship/rr:RelationshipQuantifiers\n¢ The Quantifier Dimension allows adding quantitative attributes to a relationship, like the\npercentage of shares the parent holds, etc.\n3.55 Initial Registration Date (context: RR-CDF)\nThe date at which the relationship information was first collected by\nthe ManaginglLOU.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Registration/rr:InitialRegistrationDate\no InitialRegistrationDate SHALL be set when the Relationship Data Record transits from the\ninternal, not published status PENDING_VALIDATION to PUBLISHED, analog to the\nInitialRegistrationDate within the context of LEI Data.\no LEl Records for Level 1 and Level 2 Reference Data MAY have a different InitialRegistrationDate,\ndepending on when each record was entered into the Global LEI System.\no Likewise, different Relationship Records for the same child entity MAY have different\nInitialRegistrationDates.\ne Once set, InitialRegistrationDate SHALL NOT be updated. This applies also when the Relationship\nRecords is being transferred to a different LEl issuer.\n¢ The InitialRegistrationDate SHALL not be later than LastUpdateDate or NextRenewalDate.\nState Transition and Validation Rules for Common Data File formats Page 84 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1567,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.709Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.56 Last Update Date (context: RR-CDF)\n\nThe date at which the information was most recently updated by the\nManagingLOU.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Registration/rr:LastUpdateDate\n\n¢ Any update to a Relationship Record SHALL be indicated by setting the LastUpdateDate to the\ndate the update occurred.\n\no There SHALL be at least one other field in the record that changed when LastUpdateDate is\nupdated.\n\no There SHALL NOT be any update to any other field without also an update to LastUpdateDate.\n\no LlastUpdateDate SHALL NOT be earlier than InitialRegistrationDate.\n\no lastUpdateDate SHALL never be a date in the future.\n\n3.57 Registration Status (context: RR-CDF)\n\n_ rr:RegistrationStatus\n\nThe status of the Legal Entity's Relationship Record\n\nregistration with the ManagingLOU.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Registration/rr:RegistrationStatus\n\nThe element RegistrationStatus describes the status of the relationship registration.\n\no If RegistrationStatus is PENDING_VALIDATION, the record SHALL NOT be published in any files\nwith Content Type LOU_FULL_PUBLISHED, LOU_DELTA_PUBLISHED, GLEIF_FULL_PUBLISHED, or\nGLEIF_DELTA_PUBLISHED.\n\no If RegistrationStatus is PUBLISHED, then RelationshipStatus SHALL be ACTIVE, and\nValidationSources SHALL NOT be PENDING.\n\nState Transition and Validation Rules for Common Data File formats Page 85 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1525,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.709Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o If RegistrationStatus is PUBLISHED, then NextRenewalDate SHALL be greater than or equal to the\nContentDate.\no If RegistrationStatus is RETIRED, then RelationshipStatus SHALL be INACTIVE.\n¢ A RegistrationStatus of CANCELLED SHALL NOT be published.\no If RegistrationStatus is LAPSED, then NextRenewalDate SHALL be earlier than ContentDate.\n3.58 Next Renewal Date (context: RR-CDF)\nThe next date by which the relationship information SHALL be\nrenewed and re-certified by the Legal Entity.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Registration/rr:NextRenewalDate\no NextRenewalDate SHALL be later than InitialRegistrationDate.\n¢ The NextRenewalDate for relationships with RelationshipType IS_DIRECTLY_CONSOLIDATED_BY\nor IS_ULTIMATELY_CONSOLIDATED_BY SHALL be the same for the child LEl and the Relationship\nRecords.\nState Transition and Validation Rules for Common Data File formats Page 86 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1025,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.709Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.59 Managing LOU (context: RR-CDF)\nThe LEI of the LOU that is responsible for administering this\nRelationship Record.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Registration/rr:ManagingLOU\nManagingLOU identifies the LEl issuer currently managing the LEI Relationship Records.\n¢ ManagingLOU SHALL be populated with the LEI of the LEl issuer.\n¢ ManagingLOU SHALL be populated with the LEI of a GLEIF Accredited LEl issuer for all LElI Record\nfiles published. Exceptions are allowed only for Candidate LEl issuers during testing and\nonboarding.\n¢ ManagingLOU SHALL be identical to the Originator in the file header for all LElI Records uploaded\nto GLEIF.\n¢ ManagingLOU SHALL be identical to the ManagingLOU in the LEI Record for the child Legal Entity\nrepresented by the StartNode of the relationship.\n3.60 Validation Sources (context: RR-CDF)\n_ rr:ValidationSources\n_ Level of relationship Validation.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Registration/rr:ValidationSources\n¢ ValidationSources SHALL be FULLY_CORROBORATED, if an accounting consolidation relationship\ncan be validated using current and confirmed consolidated financial statements or other\naccepted documents. Fund relationships SHALL be FULLY_CORROBORATED, if the relationship\ncan be validated using regulatory filings to regulators or central banks as well as registers and\ndatabases kept by competent authorities. A fund prospectus vetted by such authority is also\naccepted, even if the source of the document is the fund manager and not the regulator.\nState Transition and Validation Rules for Common Data File formats Page 87 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1762,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.710Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o ValidationSources SHALL be PARTIALLY_CORROBORATED, if the accepted documents have\ndifferent definitions of accounting consolidation or if the documents make it likely that an\naccounting consolidation relationship exists but the confirmed financial statements do not\ninclude this situation, yet.\n\n¢ ValidationSources SHALL be ENTITY_SUPPLIED_ONLY, if the conditions for assigning\nFULLY_CORROBORATED or PARTIALLY _CORROBORATED are not met and the Validation relies\nsolely on unconfirmed documents provided by the Legal Entity. For fund relationships, this also\nincludes a prospectus not (yet) vetted by the authorities.\n\n3.61 Validation Documents (context: RR-CDF)\n\n_ rr:ValidationDocuments\n\nType of source document(s) used for validating the\n\nrelationship.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Registration/rr:ValidationDocuments\n\n¢ The type of Validation documents used to corroborate the relationship SHALL be provided.\n\nCurrently accepted type of documents to validate relationships are:\n\no ACCOUNTS_FILING: A consolidated financial (accounting) statement, prepared and submitted\nto the relevant authority.\n\no REGULATORY_FILING: A regulatory filing providing public information on Legal Entities\nand/or their relationships (e.g.: documents submitted to a (financial) regulator, including a\nfund prospectus made available on the regulator’s web site).\n\ne SUPPORTING_DOCUMENTS: Other documents supporting the validation of legal entities\nand/or their relationships (e.g.: business registers or other authoritative sources, such as\nofficial fund register or databases for regulated fund entities provided by the regulator).\n\no CONTRACTS: Contract(s) attesting to the validity of Legal Entities and/or their relationships.\n\no OTHER_OFFICIAL_DOCUMENTS: Other official document(s) attesting to the validity of Legal\nEntities and/or their relationships (e.g.: notarized documents or a fund prospectus provided\nby the fund manager).\n\ne If ValidationSources is ENTITY_SUPPLIED_ONLY the ValidationDocuments are none of the sources\nadmitted for FULLY_CORROBORATED and PARTIALLY_CORROBORATED.\n\nState Transition and Validation Rules for Common Data File formats Page 88 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2302,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.710Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o If ValidationDocuments is REGULATORY_FILING, the ValidationReference element SHALL be\npresent and contain, if available, the filing URL (including name and full path). The filing URL MAY\ncontain other standard identifiers e.g., DOI (Digital Object Identifier).\n\n3.62 Validation Reference (context: RR-CDF)\n\n_ rr:ValidationReference\n\nA reference to a specific document or other source used as the\nbasis of relationship Validation for this Relationship Record.\n/rr:RelationshipData/rr:RelationshipRecords/rr:RelationshipRecord\n/rr:Registration/rr:ValidationReference\n\no The content of ValidationReference SHALL contain a reference to a specific document or other\nsource used as the basis of relationship Validation for this record.\n\n3.63 LEI (context: Repex-CDF)\n\n_ The LEI for the Legal Entity which raised this exception.\n\n/repex:ReportingExceptionData/repex:ReportingExceptions\n/repex:Exception/repex:LEl\n\ne SHALL contain the LEI of the entity reporting the exception (i.e.: the child Legal Entity).\n\ne The EntityCategory in the record assigned to this LEI SHALL NOT be BRANCH.\n\n3.64 Exception Category\n\nState Transition and Validation Rules for Common Data File formats Page 89 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1290,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.710Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"A category of mandatory information reporting, beyond the\nminimum required for Legal Entity identification, which the Legal\nEntity declines, giving reasons and references where applicable.\n/repex:ReportingExceptionData/repex:ReportingExceptions\n/repex:Exception/repex:ExceptionCategory\n\nThe ExceptionCategory of a Reporting exception defines whether the exception applies to the\n\nreporting of the direct parent or the ultimate parent.\n\no Relationship Records and Reporting exceptions SHALL be mutually exclusive for the same parent\nreporting (direct vs. ultimate).\n\no If a Reporting exception having ExceptionCategory\nDIRECT_ACCOUNTING_CONSOLIDATING_PARENT is present, no active Relationship Records\nhaving RelationshipType IS_DIRECTLY_CONSOLIDATED_BY SHALL be present.\n\no If a Reporting exception having ExceptionCategory\nULTIMATE_ACCOUNTING_CONSOLIDATING_PARENT is present, no active Relationship Records\nhaving RelationshipType IS_ULTIMATELY_CONSOLIDATED_BY SHALL be present.\n\n3.65 Exception Reason\n\nA single reason provided by the Legal Entity for declining to\nprovide the mandatory report of a specified type of information\n(beyond the minimum Reference Data needed purely for\nidentification of the Legal Entity).\n/repex:ReportingExceptionData/repex:ReportingExceptions\n/repex:Exception/repex:ExceptionReason\n\nThe LEI-ROC has specified scenarios where the child Legal Entity may report it does not have a parent\n\naccording to the definition used or it may decline to provide parent information.\n\nThe LEl issuer MAY also report an exception given the parent does not have an LEI yet. Different\n\nexception reasons apply in each scenario:\n\nState Transition and Validation Rules for Common Data File formats Page 90 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1825,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.710Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"1 Introduction\n\nThe State Transition and Validation Rules (STVR) describe Business Rules and their technical\n\nimplementation for the issuance, updating, management and publication of LEI Reference Data\n\naccording to the Common Data File (CDF) formats.\n\n¢ Rules enforced by the XML schema are documented in the xsd files for LEI-CDF, RR-CDF and\nREPEX-CDF in their latest version.\n\n¢ Rules required in addition to the XML schema definition (also called Business Rules, data\nmanagement rules, STVR) are documented separately here.\n\nNOTE: These Business Rules are written by GLEIF to provide specific steps for the LEl issuers to follow\n\nin producing and quality assuring the LEI data they provide to GLEIF and publish in the Global LEI\n\nSystem.\n\nNOTE: Each CDF data field is presented here with:\n\n¢ Element name\n\no Description or rationale (source) per data element\n\ne Cardinality\n\no The Xpath identifying the unique data field in its CDF XML representation\n\no General rules\n\nNOTE: During implementation and transition periods between versions of the related CDF formats,\n\nthere might be certain descriptions, listing or explanations relevant only for a specific version of the\n\nCDF formats. These could relate to the upcoming version as well as to the retiring version. In order to\n\nmake these differences more visible to the reader, in this document such elements are highlighted\n\nwith the information about the related version. Some examples, but nor limited to these are (added\n\nin LEI-CDF x.x), (updated in RR-CDF x.x), (deprecated in LEI-CDF x.x).\n\n1.1 Terms and Definitions\n\nBranch/International A lead International Branch or International Branch network outside\n\nBranch of the headquarters’ jurisdiction.\n\nBusiness Rule GLEIF’s legal, organizational and technical rules for implementation\nof the LEI-ROC’s high-level policies for LEl data beyond the technical\nrules enforced by the relevant XML schema.\n\nState Transition and Validation Rules for Common Data File formats Page 10 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2093,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.710Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"e Child Legal Entity reports it does not have a parent according to the definition used:\no NATURAL_PERSONS: the child Legal Entity is controlled by (a) natural person(s).\n© NON_CONSOLIDATING: the child Legal Entity is not subject to reporting in consolidated\nfinancial statements.\no NO_KNOWN_PERSON: there is no known person controlling the child Legal Entity (e.g.,\ndiversified shareholding).\no Child Legal Entity reports it does have a parent according to the definition used but this parent\ndoes not yet have an LEI:\n+ NO_LEI\no Child Legal Entity has an accounting consolidation parent relationship but declines to provide\nparent information due to other obstacles:\no NON_PUBLIC for all of the below use cases:\n\ne Obstacles in the laws or regulations of a jurisdiction prevent the child Legal Entity from\nproviding or publishing this information.\n\ne The child Legal Entity reports that the consent of the parent was necessary under the\napplicable legal framework and the parent did not consent or could not be contacted.\n\n¢ Binding legal commitments such as the articles governing the child Legal Entity, or a\ncontract prevent the child Legal Entity from providing or publishing this information.\nThis is distinct from laws or regulations of a jurisdiction that prevent the child Legal\nEntity from providing or publishing information on its parent.\n\no The child Legal Entity has sought to consult the parent entity about the reporting of the\nparent information to the Global LEI System but could not confirm the absence of\ndetriment in a way that can appropriately prevent liability risks for the child Legal Entity\n(or those acting on its behalf) under the applicable legal framework. The disclosure of\nthis information would be detrimental to the child Legal Entity or the relevant parent.\n\no The disclosure of this information would be detrimental to the Legal Entity or the\nrelevant parent. This will include reasons generally accepted by public authorities in\nsimilar circumstances, based on a declaration by the entity.\n\no Restrictions:\n¢ In case a Government Entity (EntityCategory RESIDENT_GOVERNMENT_ENTITY) needs to\ndeclare a reporting exception other than NO_LEI, the reason for it SHALL only be\n\nNO_KNOWN_PERSON.\n\nState Transition and Validation Rules for Common Data File formats Page 91 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2413,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.710Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.66 Exception Reference\n_ repex:ExceptionReference\nReferences of the law, regulation or other element of the legal\nframework to support reason(s) provided by the Legal Entity for\ndeclining to provide information on its parents.\n/repex:ReportingExceptionData/repex:ReportingExceptions\n/repex:Exception/repex:ExceptionReference\no ExceptionReference SHALL include the references of the law, regulation or other element of the\nlegal framework supporting the reason provided by the child Legal Entity for declining to provide\ninformation on its parents.\n3.67 Associated Entity — DEPRECATED\n_ lei:AssociatedEntity\nAnother entity associated with this entity if needed to fully identify\nthis entity or to place it in an appropriate context.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity\n/lei:AssociatedEntity\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity\n/lei:AssociatedEntity@type\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity\n/lei:AssociatedEntity/lei:AssociatedLEl\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord/lei:Entity\n/lei:AssociatedEntity/lei:AssociatedEntityName\no The AssociatedEntity itself SHALL be used in instances in which the legal identity of a FUND\ncannot be described sufficiently well by its own LegalName alone.\n¢ The AssociatedEntity element SHALL be used to provide the LEl or name of another entity such as\nan umbrella fund, fund manager or other hierarchically relevant entity.\nThis field has been removed from the LEl Common Data Format to avoid redundancy, as the\ninformation will be consistently provided in the fund relationship related fields.\nState Transition and Validation Rules for Common Data File formats Page 92 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1767,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.711Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"3.68 Entity Expiration Date — DEPRECATED\n_ lei:EntityExpirationDate\nThe date that the Legal Entity ceased to operate, whether due to\ndissolution, merger or acquisition.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Entity/lei:EntityExpirationDate\nThe element EntityExpirationDate is only supplied if the Legal Entity has ceased to exist or no longer\noperates as a separate Legal Entity.\n¢ EntityExpirationDate SHALL contain the date the entity ceased to exist. If the exact date is not\nknown, the date the Managing LOU was made aware that the entity is no longer active SHALL be\nentered.\no If EntityExpirationDate is present, then EntityExpirationReason SHALL be present.\no If EntityExpirationDate is present, then EntityStatus SHALL be INACTIVE.\no If EntityExpirationDate is not present, then EntityExpirationReason SHALL NOT be present.\no EntityExpirationDate SHALL be provided only after the fact, meaning it SHALL NOT be later than\nContentDate in the header or LastUpdateDate of the record.\nThis field has been removed from the LEl Common Data Format to avoid redundancy, as the\ninformation will be consistently provided in the Legal Entity Events related fields.\n3.69 Entity Expiration Reason — DEPRECATED\n_ The reason that a Legal Entity ceased to exist and/or operate.\n/lei:LEIData/lei:LEIRecords/lei:LEIRecord\n/lei:Entity/lei:EntityExpirationReason\nThe element EntityExpirationReason is only supplied if the Legal Entity has ceased to exist or no\nlonger operates as a separate Legal Entity.\nState Transition and Validation Rules for Common Data File formats Page 93 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1683,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.711Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o EntityExpirationReason SHALL contain the reason why the entity is no longer active.\n\no If EntityExpirationReason is present, then EntityExpirationDate SHALL be present.\n\n« If EntityExpirationReason is present, then EntityStatus SHALL be INACTIVE.\n\no If EntityExpirationReason is not present, then EntityExpirationDate SHALL NOT be present.\n\nThis field has been removed from the LEl Common Data Format to avoid redundancy, as the\n\ninformation will be consistently provided in the Legal Entity Events related fields.\nState Transition and Validation Rules for Common Data File formats Page 94 of 170\n\n@ Public Version 2.7.1 Final\n\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":702,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.711Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4 Use Cases\nThe following Use Cases provide rules and guidelines for LEI registration and renewal, updates to the\nLEI Record Set due to Legal Entity Events, and the handling of registration errors.\n4.1 Issue New LEI that is not branch, fund, sole proprietor,\ngovernment entity or international organization\nWhen a Legal Entity is requesting a new LEI code, the LEl issuer:\no SHALL check that there is not already an LEI code assigned to the entity (avoiding Exclusivity\nViolations)\ne Assign a unique LEI code (avoiding uniqueness violations)\n¢ Validate and publish at least the following:\n¢ LegalName as stated in the Registration Authority or other official source\ne OtherEntityNames and TransliteratedNames, if applicable\no LegalForm and Legallurisdiction\no Complete LegalAddress and HeadquartersAddress\n¢ TransliteratedAddresses and OtherAddresses, if applicable\no EntityCategory SHALL be GENERAL\no EntitySubCategory SHALL NOT be provided\no EntityStatus SHALL be ACTIVE (specific exceptions for NULL and in very rare cases exceptions\nMAY be granted by GLEIF after reporting explicitly the exact Use Case to GLEIF for directly\nissuing LEls for INACTIVE Legal Entities)\no RegistrationAuthority SHALL be included\n¢ ValidationSources SHALL be included\n¢ ValidationAuthority SHALL be included\no InitialRegistrationDate SHALL be the date the record is initially published\no LastUpdateDate SHALL be equal to InitialRegistrationDate\n¢ NextRenewalDate SHALL NOT be more than one year after InitialRegistrationDate\n¢ ManagingLOU SHALL be the LEI of a GLEIF Accredited LEl issuer\nG State Transition and Validation Rules for Common Data File formats Page 95 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1757,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.711Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"¢ Two Relationship Records, one for the direct and one for the ultimate accounting\nconsolidating parent, SHALL be included, following the general rules for Legal Entity\nrelationship information (see 2.1.2) and the applicable Use Case(s) from chapters 4.1.1, 4.1.2,\n4.1.3 and 4.1.4. Different Use Cases can apply for the direct and ultimate parent.\n\no Relationship Records describing a Branch or fund relationship SHALL NOT be included.\n\n4.1.1 Relationship with a parent Legal Entity with an LEI\n\ne When an LEl is initially issued for a Legal Entity and the child Legal Entity has an accounting\nconsolidating direct and/or ultimate parent relationship, a Relationship Record SHALL be\npublished for each relationship.\n\n¢ Only relationships that are ACTIVE by the time of the registration shall be considered.\n\no The RegistrationStatus SHALL be PUBLISHED and the RelationshipStatus SHALL be ACTIVE.\n\no Relationships that ended prior to the initial registration SHALL NOT be included. Relationships\nthat ended after initial registration SHALL be updated as described in the Use Cases for Legal\nEntity Events (see section 4.13).\n\nWhen the child Legal Entity states having (a) parent(s) that is identified with an LEI, the LEl issuer:\n\n« Validates and publishes (a) Relationship Record(s) with at least the following:\n\no StartNode/NodelD SHALL be the same as the newly assigned LEI of the child Legal Entity.\n\no EndNode/NodelD SHALL be the LEI code already assigned to the parent Legal Entity and\npublished in the Global LEI Repository by the time this record is published.\n\no The RelationshipStatus SHALL be ACTIVE.\n\no RelationshipPeriod with PeriodType RELATIONSHIP_PERIOD SHALL be included with\nStartDate and no EndDate.\n\no RelationshipPeriod with PeriodType ACCOUNTING_PERIOD SHALL be included with StartDate\nand EndDate.\n\no RelationshipPeriod with PeriodType DOCUMENT_FILING_PERIOD MAY be included with\nStartDate and no EndDate.\n\n4.1.2 Relationship with a parent Legal Entity without an LEI\n\nIn the case a child Legal Entity reports an accounting consolidating parent relationship with a Legal\n\nEntity that does not have an LEI, the LEl issuer:\n\no SHALL publish a Reporting Exception Record with the appropriate ExceptionCategory and an\nExceptionReason NO_LEI.\n\no SHALL remove the existing relationship exception of type NO_LEI from the upload file, in case a\npublic relationship record to another LEl is introduced.\n\nState Transition and Validation Rules for Common Data File formats Page 96 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2600,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.711Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"e SHALL not be under an obligation to verify that the provided reason is valid but SHALL respond to\nany challenges of this state.\n4.1.3 No accounting consolidation parent relationship\nIf the Legal Entity reports not having (a) parent(s) according to the definition of accounting\nconsolidation, the LEl issuer:\no SHALL publish a Reporting Exception Record with the appropriate ExceptionCategory and an\nExceptionReason NON_CONSOLIDATION, NATURAL_PERSONS or NO_KNOWN_PERSON.\ne SHALL not be under an obligation to verify that the provided reason is valid but SHALL respond to\nany challenges of this state.\nTypically, LEIs that are pointed as ultimate parent entities exhibit these exception reasons.\n4.1.4 Accounting consolidation parent relationship not reported due to legal obstacles\n(opt-out)\nIf the child Legal Entity states any legal obstacles for providing parent relationship information that\nwould otherwise be included with a Relationship Record, the LEl issuer:\no SHALL publish a Reporting Exception Record with the appropriate ExceptionCategory and an\nExceptionReason NON_PUBLIC.\ne SHALL not be under an obligation to verify that the provided reason is valid but SHALL respond to\nany challenges of this state.\n4.2 Issue New LEI - Branch\nWhen a new LEl is requested for an International Branch, the LEl issuer:\ne SHALL ensure that the entity requesting the LEl is an International Branch of the (head office)\nLegal Entity, to which it belongs\no SHALL verify that the (head office) Legal Entity has an LEI with RegistrationStatus ISSUED.\ne SHALL ensure that the Branch is located in a different country as the (head office) Legal Entity.\no SHALL ensure that no other LEI has been issued to a Branch of the (head office) Legal Entity in the\nsame host country.\no SHALL validate that the Branch is registered in the local Registration Authority.\no SHALL validate and publish at least the following:\no LegalName as stated in the Registration Authority.\no LegalAddress SHALL be the address of the Branch in its host country.\no HeadquartersAddress SHALL be the legal address of the (head office) Legal Entity.\nState Transition and Validation Rules for Common Data File formats Page 97 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":2293,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.711Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"o EntityCategory SHALL be BRANCH.\no EntitySubCategory SHALL NOT be provided.\no LegalForm SHALL be the LegalForm of the (head office) Legal Entity.\no Legallurisdiction SHALL be the Legallurisdiction of the (head office) Legal Entity.\no ValidationSources SHALL NOT be ENTITY_SUPPLIED_ONLY.\no SHALL publish exactly one Relationship Record with:\ne StartNode SHALL be the new LEI of the Branch.\n¢ EndNode SHALL be the LEI of the (head office) Legal Entity.\no RelationshipType SHALL be IS_INTERNATIONAL_BRANCH_OF.\no RelationshipStatus SHALL be ACTIVE.\no RelationshipPeriod with PeriodType RELATIONSHIP_PERIOD SHALL be included with\nStartDate and no EndDate.\no RelationshipPeriods with other PeriodTypes MAY be included.\ne SHALL NOT publish Reporting Exception Records.\nFigure 7 describes the reporting of Branch entities implementing the concept International Branch\nfor a (head office) Legal Entity. This means that there is only one Branch-LEl issued per host country.\nHowever, this LEI represents all locations and/or offices within the jurisdiction. The (head office of\nthe) Legal Entity decides on and provides the correct Reference Data for all its International\nBranches.\nS\nSNTERNATONALBRANCTERNATONALBRANCHOF\n@ /\nLEIC LEIC LEIC LEIB LEIB LEIB\nLocation 1 Location2 Location 3 Location 1 Location2 Location 3\nFigure 7: Example for Branch relationships\nState Transition and Validation Rules for Common Data File formats Page 98 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1537,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.711Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"4.3 Issue New LEIl - Fund\n\nWhen a new LEI code is requested for a FUND, in addition to or differing from section 4.1 and section\n2.1.2, the LEl issuer:\n\no SHALL validate and publish at least the following:\n\no LegalAddress is the current address provided in the business registry in which the entity was\nformed (which would generally be the case for funds that are incorporated) or (in other\ncases) the address recorded in the primary Registration Authority of the fund.\n\n¢ HeadquartersAddress is the address of the fund manager.\n\no Legallurisdiction SHALL match the LegalForm of the entity, and MAY in some cases be\ndifferent from the jurisdiction of the LegalAddress.\n\no EntityCategory SHALL be FUND.\n\no EntitySubCategory SHALL NOT be provided.\n\no If the fund entity is in scope of the LEI ROC policy on fund relationships, then it SHALL report\nall mandatory fund relationships. See chapter 2.1.2.\n\n¢ The Validation Authority of a fund SHALL always be the financial regulator registering the\nfund where applicable.\n\no If the fund prospectus is not vetted by authorities, ValidationSources SHALL be\nENTITY_SUPPLIED_ONLY.\n\n¢ In cases where the fund entity is self-managed, the fund entity MAY report a relationship of\ntype IS_FUND-MANAGED_BY, in which the end node of the relationship points to the same\nfund entity (see\n\no Figure 8, LEI F). This is an indication that a fund is self-managed, to distinguish from the\nscenario when a fund has not opted out of reporting a relationship.\n\nFigure 8 provides an example of LEl network including fund relationships. For simplicity and clean\nrepresentation, not all required Relationship Records are provided for the second (LEI D, LEI E, LEI G)\nand third level (LEI H, LEI B, LEI C, LEI | LEI J).\nState Transition and Validation Rules for Common Data File formats Page 99 of 170\n@ Public Version 2.7.1 Final\n2023-02-09_State-Transition-Validation-Rules_v2.7_final.docx 2023-03-07\n","contentLength":1924,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.712Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} +{"siteName":"Gleif website","source":"Gleif website","author":"No author specified","creationDate":"No creation date specified","url":"https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf","content":"LEI H (NOT A FUND) LEI B (NOT A FUND) LEI C (NOT A FUND) LEI I (NOT A FUND) LEIJ (NOT A FUND)\nK IS_DIRECTLY_CONSOLIDATED_BY / IS_ULTIMATELY_T(\\:ONSOLIDATED_BY /\\\nIS_FUND-MANAGED_BY y’cONSOLIDATED_BY ycws%lomeo_gy\n? LEI G (NOT A FUND) LEID - FUND (UMBRELLA) LEI E - FUND (MASTER) T\nIS_DIRECTLY_CONSOLIDATED_BY /K IS_SUBFUND_OF / FEEDER_TO IS_ULTIMATELY_CONSOLIDATED_BY\nIS_ULTIMATELY_CONSOLIDATED_BY % | IS_FEEDER_TO ‘ IS_DIRECTLY_CONSOLIDATED_BY\n/__\\ /\n¥\\O/&F”\"”@:fl/®\nLEI A - FUND LEI F - FUND\nFigure 8: Example of network including fund entities and their relationships\nState Transition and Validation Rules for Common Data File formats Page 100 of 170\nGLEIF) Public Version 2.7.1 Final\n2022-04-01_State-Transition-Validation-Rules_v2.6_final.docx 2023-03-07\n","contentLength":759,"tag":"pdf","imgUrl":"","imgMeta":"","imgMetaLength":0,"imgWidth":0,"imgHeight":0,"timestamp":"2023-08-11T21:49:13.712Z","hierarchy.lvl0":"","hierarchy.lvl1":"","hierarchy.lvl2":"","hierarchy.lvl3":"","knowledgeLevel":"No level specified","type":"No type specified","pageTitle":"No title specified","firstHeadingBeforeElement":"","mediaType":"pdf"} diff --git a/search-index-typesense/config/config-search-index-entries-manual/handmade.json b/search-index-typesense/config/config-search-index-entries-manual/handmade.json new file mode 100644 index 0000000..10f21e2 --- /dev/null +++ b/search-index-typesense/config/config-search-index-entries-manual/handmade.json @@ -0,0 +1,158 @@ +[ + { + "siteName": "PDF-ed", + "source": "PDF-ed", + "author": "Drummond Reed", + "creationDate": "", + "url": "https://docs.google.com/presentation/d/1mO1EZa9BcjAjWEzw7DWi124uMfyNyDeM3HuajsGNoTo/", + "content": "ACDC for Muggles", + "contentLength": 0, + "tag": "p", + "imgUrl": "", + "imgMeta": "", + "imgMetaLength": 0, + "imgWidth": 0, + "imgHeight": 0, + "timestamp": "2023-07-27T00:00:00.000Z", + "hierarchy.lvl0": "", + "hierarchy.lvl1": "", + "hierarchy.lvl2": "", + "hierarchy.lvl3": "", + "knowledgeLevel": "", + "type": "", + "pageTitle": "ACDC for Muggles", + "firstHeadingBeforeElement": "", + "mediaType": "Google Docs", + "category": "Presentation" + }, + { + "siteName": "PDF-ed", + "source": "PDF-ed", + "author": "Robert Mitwicki", + "creationDate": "", + "url": "https://docs.google.com/presentation/d/1tF_OFGAKUz9RKCLTdwDYDu7hJuEbFz-LQ6PAih7HBK8/", + "content": "KERI: Facilitating secure data flows in an auditable supply chain", + "contentLength": 0, + "tag": "p", + "imgUrl": "", + "imgMeta": "", + "imgMetaLength": 0, + "imgWidth": 0, + "imgHeight": 0, + "timestamp": "2023-07-27T00:00:00.000Z", + "hierarchy.lvl0": "", + "hierarchy.lvl1": "", + "hierarchy.lvl2": "", + "hierarchy.lvl3": "", + "knowledgeLevel": "", + "type": "", + "pageTitle": "KERI: Facilitating secure data flows in an auditable supply chain", + "firstHeadingBeforeElement": "", + "mediaType": "Google Docs", + "category": "Presentation" + }, + { + "siteName": "PDF-ed", + "source": "PDF-ed", + "author": "Henk van Cann", + "creationDate": "", + "url": "https://docs.google.com/presentation/d/1gknUMIBGgU7aOLbrQKN1QtIKZKqkW7oY/", + "content": "You control, therefore you are, and you get to decide", + "contentLength": 0, + "tag": "p", + "imgUrl": "", + "imgMeta": "", + "imgMetaLength": 0, + "imgWidth": 0, + "imgHeight": 0, + "timestamp": "2023-07-27T00:00:00.000Z", + "hierarchy.lvl0": "", + "hierarchy.lvl1": "", + "hierarchy.lvl2": "", + "hierarchy.lvl3": "", + "knowledgeLevel": "", + "type": "", + "pageTitle": "You control, therefore you are, and you get to decide", + "firstHeadingBeforeElement": "", + "mediaType": "Google Docs", + "category": "Presentation" + }, + { + "siteName": "PDF-ed", + "source": "PDF-ed", + "author": "Daniel Hardman", + "creationDate": "", + "url": "https://docs.google.com/presentation/d/1wz1cqUDI8M9w1Q8-gvJ_8zCjefTOd68LmrGj2UCBgI0/", + "content": "DIDComm Mythconceptions", + "contentLength": 0, + "tag": "p", + "imgUrl": "", + "imgMeta": "", + "imgMetaLength": 0, + "imgWidth": 0, + "imgHeight": 0, + "timestamp": "2023-07-27T00:00:00.000Z", + "hierarchy.lvl0": "", + "hierarchy.lvl1": "", + "hierarchy.lvl2": "", + "hierarchy.lvl3": "", + "knowledgeLevel": "", + "type": "", + "pageTitle": "DIDComm Mythconceptions", + "firstHeadingBeforeElement": "", + "mediaType": "Google Docs", + "category": "Presentation" + }, + { + "siteName": "PDF-ed", + "source": "PDF-ed", + "author": "Ryan West", + "creationDate": "", + "url": "https://docs.google.com/presentation/d/1hknEsGJlP5blETmPOw91FZyaOPwer6wnmnIWMlVUHKc/", + "content": "Keridemlia: Discovery for KERI", + "contentLength": 0, + "tag": "p", + "imgUrl": "", + "imgMeta": "", + "imgMetaLength": 0, + "imgWidth": 0, + "imgHeight": 0, + "timestamp": "2023-07-27T00:00:00.000Z", + "hierarchy.lvl0": "", + "hierarchy.lvl1": "", + "hierarchy.lvl2": "", + "hierarchy.lvl3": "", + "knowledgeLevel": "", + "type": "", + "pageTitle": "Keridemlia: Discovery for KERI", + "firstHeadingBeforeElement": "", + "mediaType": "Google Docs", + "category": "Presentation" + }, + { + "siteName": "PDF-ed", + "source": "PDF-ed", + "author": "Drummond Reed and Samuel Smith", + "creationDate": "", + "url": "https://docs.google.com/presentation/d/12nX_IIPp5xw8qAxhZy-ae2aWYytYQmFBbB9K3PcVhqQ/", + "content": "CESR for First Year Wizards", + "contentLength": 0, + "tag": "p", + "imgUrl": "", + "imgMeta": "", + "imgMetaLength": 0, + "imgWidth": 0, + "imgHeight": 0, + "timestamp": "2023-07-27T00:00:00.000Z", + "hierarchy.lvl0": "", + "hierarchy.lvl1": "", + "hierarchy.lvl2": "", + "hierarchy.lvl3": "", + "knowledgeLevel": "", + "type": "", + "pageTitle": "CESR for First Year Wizards", + "firstHeadingBeforeElement": "", + "mediaType": "Google Docs", + "category": "Presentation" + } +] \ No newline at end of file diff --git a/search-index-typesense/config/config-sitemaps-exlude-urls/README.md b/search-index-typesense/config/config-sitemaps-exlude-urls/README.md new file mode 100644 index 0000000..6b5d211 --- /dev/null +++ b/search-index-typesense/config/config-sitemaps-exlude-urls/README.md @@ -0,0 +1,14 @@ +# Information + +Create an array with strings that should be ignored. + +Writing `newsroom` results in every URL that contains the string `newsroom` being ignored. + +``` +[ + "gleif.org/en/meta", + "gleif.org/en/contact", + "gleif.org/en/newsroom", + "gleif.org/en/lei-data/email-notifications-on-technical-updates" +] +``` diff --git a/search-index-typesense/config/config-sitemaps-exlude-urls/gleifExcludeUrls.json b/search-index-typesense/config/config-sitemaps-exlude-urls/gleifExcludeUrls.json new file mode 100644 index 0000000..9237a8b --- /dev/null +++ b/search-index-typesense/config/config-sitemaps-exlude-urls/gleifExcludeUrls.json @@ -0,0 +1,6 @@ +[ + "gleif.org/en/meta", + "gleif.org/en/contact", + "gleif.org/en/newsroom", + "gleif.org/en/lei-data/email-notifications-on-technical-updates" +] \ No newline at end of file diff --git a/search-index-typesense/config/config-sitemaps-exlude-urls/wotTermsExcludeUrls.json b/search-index-typesense/config/config-sitemaps-exlude-urls/wotTermsExcludeUrls.json new file mode 100644 index 0000000..c833668 --- /dev/null +++ b/search-index-typesense/config/config-sitemaps-exlude-urls/wotTermsExcludeUrls.json @@ -0,0 +1,25 @@ +[ + "weboftrust.github.io/WOT-terms/docs/overview/", + "weboftrust.github.io/WOT-terms/docs/category/how-we-did", + "weboftrust.github.io/WOT-terms/docs/how-we-did/chatbots", + "weboftrust.github.io/WOT-terms/docs/how-we-did/cheat-sheet-writing-page", + "weboftrust.github.io/WOT-terms/docs/how-we-did/check-and-accept-pr-production-edusite-locally", + "weboftrust.github.io/WOT-terms/docs/how-we-did/create-omnigraffle-infographic-and-convert-to-svg", + "weboftrust.github.io/WOT-terms/docs/how-we-did/create-search-index", + "weboftrust.github.io/WOT-terms/docs/how-we-did/create-terms-link-table", + "weboftrust.github.io/WOT-terms/docs/how-we-did/docusaurus-process", + "weboftrust.github.io/WOT-terms/docs/how-we-did/embed-github-hosted-image-in-github-wiki-page", + "weboftrust.github.io/WOT-terms/docs/how-we-did/file-system", + "weboftrust.github.io/WOT-terms/docs/how-we-did/fill-out-terms-toip-wiki", + "weboftrust.github.io/WOT-terms/docs/how-we-did/homepage-text-altering", + "weboftrust.github.io/WOT-terms/docs/how-we-did/install", + "weboftrust.github.io/WOT-terms/docs/how-we-did/intro", + "weboftrust.github.io/WOT-terms/docs/how-we-did/label-content-and-alert-changes", + "weboftrust.github.io/WOT-terms/docs/how-we-did/load-glossary-weboftrust-in-docusaurus", + "weboftrust.github.io/WOT-terms/docs/how-we-did/markdown-from-wot-wiki", + "weboftrust.github.io/WOT-terms/docs/how-we-did/pull-in-markdown-documents", + "weboftrust.github.io/WOT-terms/docs/how-we-did/source-and-destination-for-search", + "weboftrust.github.io/WOT-terms/docs/how-we-did/sync-agenda-to-production-via-local", + "weboftrust.github.io/WOT-terms/docs/how-we-did/typesense-search-install-config", + "weboftrust.github.io/WOT-terms/docs/how-we-did/why-terms-wot-manage-structure" +] \ No newline at end of file diff --git a/search-index-typesense/config/config-sitemaps-manual/README.md b/search-index-typesense/config/config-sitemaps-manual/README.md new file mode 100644 index 0000000..f0ea247 --- /dev/null +++ b/search-index-typesense/config/config-sitemaps-manual/README.md @@ -0,0 +1,7 @@ +# Information + +In this directory you can place handcrafted sitemaps. They will be copied to the sitemaps working dir and included as a source for the scraper bots. + +You are free to name the files. + +See slack-keri-archive.xml` as an example: this is a one time sitemap since this archive will not change anymmore. diff --git a/search-index-typesense/config/config-sitemaps-manual/sitemap-www.gleif.org-pdf.xml b/search-index-typesense/config/config-sitemaps-manual/sitemap-www.gleif.org-pdf.xml new file mode 100644 index 0000000..ca6871f --- /dev/null +++ b/search-index-typesense/config/config-sitemaps-manual/sitemap-www.gleif.org-pdf.xml @@ -0,0 +1,447 @@ + + + + https://www.gleif.org/about/gleif-services/service-reports/gleif-service-report-june-2023/2023-07-14_gleif_service_report_v1.0.pdf + + + https://www.gleif.org/about/gleif-services/iso-20000-certification/itms_707855.pdf + + + https://www.gleif.org/about/gleif-engagement/gleif-stakeholder-groups/gleif-vendor-relationship-group/2022-09-06_gleif-vendor-services-relationship-group-charter_v1.4.pdf + + + https://www.gleif.org/about/gleif-engagement/gleif-stakeholder-groups/gleif-gifi-relationship-group/2018-11-05_gleif_gifi-relationship-group-charter_v1.pdf + + + https://www.gleif.org/about/governance/regulatory-oversight-committee-roc/roc_20201001-1.pdf + + + https://www.gleif.org/about/governance/mou-between-gleif-and-roc/20150923-ROC-GLEIF-MOU-final-signed.pdf + + + https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf + + + https://www.gleif.org/about/governance/by-laws/gleif-by-laws-final-27-october-2016.pdf + + + https://www.gleif.org/about/governance/policies/2017-03-01_board-code-of-conduct_v1.0-final-approved.pdf + + + https://www.gleif.org/about/governance/policies/2023-02-03_conflict_of_interest_policy_1.1final.pdf + + + https://www.gleif.org/about/governance/policies/2020-02-05_bod_travelandexpense_policy_v2.0-final-approved.pdf + + + https://www.gleif.org/about/governance/policies/16-09-16_General_Accounting_FIN007_v.1_final.pdf + + + https://www.gleif.org/about/governance/policies/16-09-16_IA_Charter_v.1_final.pdf + + + https://www.gleif.org/about/governance/policies/2020-01-24_whistleblowingpolicy_v1.0-final-approved.pdf + + + https://www.gleif.org/about-lei/get-an-lei-find-lei-issuing-organizations/how_to_identify_your_new_lou_after_the_termination_of_business_entity_data_b_v.pdf + + + https://www.gleif.org/about-lei/get-an-lei-find-lei-issuing-organizations/registration-agents/2023_03_28_registration-agents-governance-framework_1.0.pdf + + + https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2020-06-01-ma-master-agreement-1.3-final.pdf + + + https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2017-09-01-ma-appendix-01-non-disclosure-agreement_final.pdf + + + https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2021-05-31-ma-appendix-02-accreditation-checklist_final.pdf + + + https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-6-30-ma-appendix-02-accreditation-manual.pdf + + + https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2018-02-08_ma-appendix-05-lou-contract-requirements.pdf + + + https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-03-31-ma-appendix-06-sla_2.1.pdf + + + https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2021-11-30_ma-appendix-07-payments_v1.4-final.pdf + + + https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2016-02-01-ma-appendix-08-ancillary-duties_final.pdf + + + https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2017-09-01-ma-appendix-09a-terms-of-use-gleif_final.pdf + + + https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-05-11_ma-appendix-10-accreditation-verification_1.4final.pdf + + + https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2016-02-01-ma-appendix-11-swiss-data-protection-act_final.pdf + + + https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2016-02-01-ma-appendix-13-individual-deviations-from-the-ma_final.pdf + + + https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2023-03-28-ma-appendix-14-third-party-services-v1.3.pdf + + + https://www.gleif.org/about-lei/common-data-file-format/2022-02-22_cdf_questions_and_answers_v2.4.pdf + + + https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf + + + https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf + + + https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf + + + https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2021-11-23_lei-cdf-3.1-and-rr-cdf-2.1-and-repex-cdf-2.1-samples-description_v1.2-final.pdf + + + https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2022-02-09_upcoming-cdf-xml-comprehensive-example-description_v1.0-final.pdf + + + https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2021-09-30_xslt-documentation_v1.1-final.pdf + + + https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2021-09-30_guiding_document_for_the_transition_period_v1.1-final.pdf + + + https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/gleif-data-consumers-quick-guide.pdf + + + https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf + + + https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf + + + https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_reporting-exceptions-format-v1-1.pdf + + + https://www.gleif.org/about-lei/code-lists/gleif-registration-authorities-list/2022-03-23_ra_list_v1.7.pdf + + + https://www.gleif.org/about-lei/code-lists/gleif-registration-authorities-list/2022-03-23_overview_changes_ra_list_v1.0_to_v1.7.pdf + + + https://www.gleif.org/about-lei/code-lists/iso-20275-entity-legal-forms-code-list/2021-10-21-elf-code-list-v1.4.1.pdf + + + https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf + + + https://www.gleif.org/about-lei/code-lists/gleif-accepted-legal-jurisdictions-code-list/gleif_acceptedjurisdictions_v1.4.pdf + + + https://www.gleif.org/vlei/introducing-the-verifiable-lei-vlei/2023-04-03_vlei-q-a-updated_v1.1_final.pdf + + + https://www.gleif.org/vlei/introducing-the-verifiable-lei-vlei/gleif-ebook-the-vlei-introducing-digital-i-d-for-organizations-everywhere/01-06-2023-gleif_introduction-to-the-vlei_redesign_v2.2.pdf + + + https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-primary-document_v1.0_final.pdf + + + https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-gleif-identifier-governance-framework_v1.0_final.pdf + + + https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-qualified-vlei-issuer-identifer-vlei-credential-governance-framewo.pdf + + + https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-legal-entity-vlei-credential-governance-framework_v1.0_final.pdf + + + https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-qualified-vlei-issuer-authorization-vlei-credential-framework_v1.pdf + + + https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-legal-entity-official-organizational-role-vlei-credential-govern.pdf + + + https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-legal-entity-engagement-context-role-vlei-credential-framework_v.pdf + + + https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-glossary_v1.1_final.pdf + + + https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-risk-assessment_v1.1_final.pdf + + + https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-trust-assurance-framework_v1.1_final.pdf + + + https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-governance-requirements_v1.0_final.pdf + + + https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-business-requirements_v1.0_final.pdf + + + https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-technical-requirements-part1-keri-infrastructure_v1.1_final.pdf + + + https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-technical-requirements-part2-vlei-credentials_v1.0_final.pdf + + + https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-technical-requirements-part_3-vlei-credential-schema-registry_v1.pdf + + + https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-vlei-ecosystem-information-trust-policies_v1.0_final.pdf + + + https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_vlei-issuer-qualification-agreement_v1.0_final.pdf + + + https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2023-04-03_appendix-1-non-disclosure-agreement_v1.1_final.pdf + + + https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2023-04-03_appendix-2-vlei-issuer-qualification-program-manual_v1.1_final.pdf + + + https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2023-04-03_appendix-3-vlei-issuer-qualification-program-checklist_v1.2_final.pdf + + + https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-4-vlei-issuer-contact-details_v1.0_final.pdf + + + https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-5-qualified-vlei-issuer-service-level-agreement_v1.2_final.pdf + + + https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-6-terms-of-use-qualified-vlei-issuer-trustmark_v1.0_final.pdf + + + https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-7-qualified-vlei-issuer-legal-entity-contract-terms_v1.0_final.pdf + + + https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-06-09_gleif_ceviant_kyc_onboarding_v1.0_approved_final.pdf + + + https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-06-28_moodys_kyc-onboarding_gleif_v1.0_approved_final.pdf + + + https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-07-04_japan-eseal_gleif_v1.0_approved-final.pdf + + + https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-06-01_gleif_bloomberg_sanctions_screening_v1.0_bloomberg_approved_final.pdf + + + https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-06-06_gleif_element-22_sanctions_screening_v1_approved_final.pdf + + + https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-06-5_gleif_lse_sanctions_screening_v1.0_approved_final.pdf + + + https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-06-08_moodys_sanctions_screening_gleif_v1.0_approved.pdf + + + https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-06-22_gleif_wmd_sanctions_screening_v1.0_final_approved.pdf + + + https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/p070722.pdf + + + https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/swift_global_adoption_of_the_lei_finaldraftv1.pdf + + + https://www.gleif.org/lei-solutions/validation-agents/gleif-ebook-introducing-the-lei-validation-agent/2020-09-29_gleif-ebook-lei-validation-agent-framework_v1.1-final.pdf + + + https://www.gleif.org/lei-solutions/validation-agents/gleif-ebook-introducing-the-lei-validation-agent/2020-09-29_gleif-announces-new-va-role-for-fis_v1.0-final-clean.pdf + + + https://www.gleif.org/lei-solutions/validation-agents/gleif-ebook-a-closer-look-at-the-validation-agent-trial-process/2021-03-03_gleif-validation-agent-trial-ebook_v1.0-approved-public.pdf + + + https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies_v1.2-final.pdf + + + https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/le-lei_la-cle-qui-deverrouillera-linclusion-financiere-dans-les-pays-en-developpement_v1.2-final.pdf + + + https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/2021-08-10-global-digital-business-identity-initiative-launches-to-boost-financial-inclusion-for-african-businesses_v.1.1-final.pdf + + + https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/2021-08-10-foerderung-finanzieller-inklusion-von-unternehmen-in-afrika-globale-initiative-zur-digitalen-identifizierung-von-unternehmen-gestartet_v.1.1-final.pdf + + + https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/2021-08-10-lancement-de-initiative-identite-numerique-mondiale-de-l-entreprise-en-soutien-a-l-inclusion-financiere-des-entreprises-africaines_v.1.1-final.pdf + + + https://www.gleif.org/lei-solutions/mckinsey-company-and-gleif-leis-and-client-lifecycle-management-in-banking-a-u-s-4-billion-beginning/2019-10-29_gleif-ebook-leis-and-client-lifecycle-management-in-banking-a-u.s-4-billion-v1.0-approved-public.pdf + + + https://www.gleif.org/lei-solutions/mckinsey-company-and-gleif-leis-and-client-lifecycle-management-in-banking-a-u-s-4-billion-beginning/gleif-infographic-leis-transforming-banks-client-lifecycle-management/2019-10-29_gleif-infographic-leis-transforming-banks-client-lifecycle-management_v1.0-approved-public.pdf + + + https://www.gleif.org/lei-solutions/mckinsey-company-and-gleif-creating-business-value-with-the-lei/legal-entity-identifier_mckinsey_gleif_2017_final.pdf + + + https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-report_a-new-future-for-legal-entity-identification_final.pdf + + + https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-findings_challenges-onboarding-client-organizations-in-banking-sector_v1.0-final.pdf + + + https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-the-pitfalls-of-onboarding/gleif-infographic_the-future-of-legal-entity-identification_final.pdf + + + https://www.gleif.org/lei-solutions/gleifs-digital-strategy-for-the-lei/gleif-idc-research-creating-agile-resilient-global-trade-with-the-lei-and-vlei/2023-03-23_driving-business-with-trust-the-sustaining-role-of-secure-and-reliable-identities_final_public.pdf + + + https://www.gleif.org/lei-data/global-lei-index/lei-statistics/2022-07-19_lei_statistics_dashboard-dictionary_v1.1.pdf + + + https://www.gleif.org/lei-data/global-lei-index/download-global-lei-system-business-reports/2022-07-19_background_information_on_global_lei_system_report_v1.2.pdf + + + https://www.gleif.org/lei-data/global-lei-index/download-global-lei-system-business-reports/2022-07-19_business-report-dictionary_v1.5.pdf + + + https://www.gleif.org/lei-data/global-lei-index/download-global-lei-system-business-reports/download-global-lei-system-business-report-q2-2023/2023-07-18-quarterly_business_report.pdf + + + https://www.gleif.org/lei-data/gleif-concatenated-file/about-the-concatenated-file/2017-02-05_gleif-concatenated-file_v2-4_final.pdf + + + https://www.gleif.org/lei-data/gleif-golden-copy/2022-02-23_gleif-golden-copy-and-delta-files_v2.2-final.pdf + + + https://www.gleif.org/lei-data/lei-mapping/download-bic-to-lei-relationship-files/2023-03-23_bic-to-lei-factsheet_v1.3-final.pdf + + + https://www.gleif.org/lei-data/lei-mapping/download-bic-to-lei-relationship-files/2017-12-21_annex-2_bic-to-lei-mapping-table-license-agreement_final.pdf + + + https://www.gleif.org/lei-data/lei-mapping/download-bic-to-lei-relationship-files/2018-03-01_csv_import_guide_v1.1.pdf + + + https://www.gleif.org/lei-data/lei-mapping/download-isin-to-lei-relationship-files/2018-03-01_csv_import_guide_v1.1.pdf + + + https://www.gleif.org/lei-data/lei-mapping/download-isin-to-lei-relationship-files/2021-06-08_isin-to-lei_factsheet_v1.pdf + + + https://www.gleif.org/lei-data/lei-mapping/download-mic-to-lei-relationship-files/20220902_mic_to_lei_factsheet_v1.0.pdf + + + https://www.gleif.org/lei-data/lei-mapping/download-mic-to-lei-relationship-files/2022-09-02_mic_to_lei_mapping_table_license_agreement_v1.0.pdf + + + https://www.gleif.org/lei-data/lei-mapping/download-mic-to-lei-relationship-files/2018-03-01_csv_import_guide_v1.1.pdf + + + https://www.gleif.org/lei-data/lei-mapping/s-p-global-company-id-to-lei-relationship/2022-10-10_s_p_global_company_id-to-lei_factsheet_v1.0.pdf + + + https://www.gleif.org/lei-data/lei-mapping/download-oc-to-lei-relationship-files/2018-03-01_csv_import_guide_v1.1.pdf + + + https://www.gleif.org/lei-data/lei-mapping/download-oc-to-lei-relationship-files/2023-06-29_opencorporatesid-to-lei-factsheet_v1.1-final.pdf + + + https://www.gleif.org/lei-data/lei-mapping/gleif-certification-process/2021-09-02_lei_mapping_cooperation_agreement_v1.pdf + + + https://www.gleif.org/lei-data/lei-mapping/gleif-certification-process/2018-04-03_nda_gleif_template_v1.1.pdf + + + https://www.gleif.org/lei-data/lei-mapping/gleif-certification-process/2021-09-10-appendix-2-contact-details.pdf + + + https://www.gleif.org/lei-data/lei-mapping/gleif-certification-process/2020-02-13_internal-controls-checklist_v2.0-final.pdf + + + https://www.gleif.org/lei-data/gleif-data-quality-management/proactive-management/2021-11-10_checkforduplicatedictionary_v1.2-final.pdf + + + https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf + + + https://www.gleif.org/lei-data/gleif-data-quality-management/data-quality-checks/2023-07-04_dqc_rulesetting_3.3_v1.3_final.pdf + + + https://www.gleif.org/lei-data/gleif-data-quality-management/data-quality-checks/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf + + + https://www.gleif.org/lei-data/gleif-data-quality-management/data-quality-checks/details/2023-07-04_dqc_rulesetting_3.3_v1.3_final.pdf + + + https://www.gleif.org/lei-data/gleif-data-quality-management/challenge-lei-data/2019-12-02_challenge_manual_v1.1-final.pdf + + + https://www.gleif.org/lei-data/gleif-data-quality-management/downloads/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf + + + https://www.gleif.org/lei-data/gleif-data-quality-management/downloads/2023-07-04_dqc_rulesetting_3.3_v1.3_final.pdf + + + https://www.gleif.org/lei-data/gleif-data-quality-management/downloads/2021-07-07_data_quality_report_dictionary_v3.0-final-public.pdf + + + https://www.gleif.org/lei-data/gleif-data-quality-management/downloads/2019-12-02_challenge_manual_v1.1-final.pdf + + + https://www.gleif.org/lei-data/gleif-data-quality-management/downloads/2021-11-10_checkforduplicatedictionary_v1.2-final.pdf + + + https://www.gleif.org/newsroom/events/past-gleif-events/gleif-2022-meet-the-market-event-tokyo-japan/gleif-meet-market-tokyo.pdf + + + https://www.gleif.org/newsroom/events/past-gleif-events/lei-forum-singapore-creating-business-value-with-the-lei-the-global-identity-behind-every-business/gleif-lei-forum-singapore-06.pdf + + + https://www.gleif.org/newsroom/events/past-gleif-events/gleif-2018-meet-the-market-event-paris-france/2018june_mtm-program_5-2.pdf + + + https://www.gleif.org/newsroom/events/past-gleif-events/gleif-2018-meet-the-market-event-riyadh-saudi-arabia/meet-market-agenda2017-final-2.pdf + + + https://www.gleif.org/newsroom/events/past-gleif-events/gleif-2016-meet-the-market-event-tokyo-japan/160902_gleif_meet_the_market_tokyo.pdf + + + https://www.gleif.org/newsroom/events/past-gleif-events/gleif-2015-meet-the-market-event-mexico/GLEIF_2015_MexicoCity_Agenda5.pdf + + + https://www.gleif.org/newsroom/events/past-gleif-events/gleif-2015-press-conference-frankfurt-am-main-germany/gleif-2015-ffm-press-conference-agenda.pdf + + + https://www.gleif.org/newsroom/events/past-gleif-events/gleif-mtm-event-london/gleif-2015-london-agenda.pdf + + + https://www.gleif.org/newsroom/press-releases/gleif-advances-digital-trust-and-identity-for-legal-entities-globally/2020-12-10_gleif-advances-digital-trust-and-identity-for-legal-entities-globally_v1.0-final-approved.pdf + + + https://www.gleif.org/newsroom/press-releases/gleif-advances-digital-trust-and-identity-for-legal-entities-globally/2020-12-10_supporting-quotes-from-the-vlei-ecosystem_v1.0-approved.pdf + + + https://www.gleif.org/newsroom/press-releases/gleif-unveils-issuance-and-infrastructure-models-for-verifiable-lei/2021-02-11_gleif-unveils-vlei-issuance-and-infrastructure-models_v.1.0-final.pdf + + + https://www.gleif.org/newsroom/press-releases/gleif-and-trust-over-ip-foundation-publish-ecosystem-governance-framework-for-digitally-verifiable-lei/2022-02-07_gleif-and-trust-over-ip-foundation-publish-ecosystem-governance-framework-for-digitally-verifiable-lei_v1.2-final.pdf + + + https://www.gleif.org/lei-data/global-lei-index/download-global-lei-system-business-reports/download-global-lei-system-business-report-q4-2022/2023-01-19-quarterly_business_report.pdf + + + https://www.gleif.org/newsroom/gleif-podcasts/gleif-webcast-connect-the-corporate-dots-globally-with-the-lei/2016-11-03_gleif-webinar-2016_slides-v1.0-final-approved.pdf + + + https://www.gleif.org/newsroom/gleif-podcasts/gleif-webcast-creating-business-value-with-the-lei/2017-11-16_gleif-webinar-2017_slides-version-1.1-final.pdf + + + https://www.gleif.org/newsroom/gleif-podcasts/gleif-webcast-advancing-digital-identity-with-the-lei/2018-12-05_gleif-webinar-2018_slides_v1.0-final-public.pdf + + + https://www.gleif.org/_documents/blog/20181205-gleif-webcast-2018-advancing-digital-identity-with-the-lei/2018-12-05_GLEIF-Webinar-2018_Slides_v1.0_Final_Public.pdf + + + https://www.gleif.org/_documents/blog/20181205-gleif-webcast-2018-advancing-digital-identity-with-the-lei/gleif-research-report_a-new-future-for-legal-entity-identification_final.pdf + + + https://www.gleif.org/_documents/blog/20181205-gleif-webcast-2018-advancing-digital-identity-with-the-lei/gleif-research-findings_challenges-onboarding-client-organizations-in-banking-sector_v1.0-final.pdf + + \ No newline at end of file diff --git a/search-index-typesense/config/config-sitemaps-manual/slack-keri-archive.xml b/search-index-typesense/config/config-sitemaps-manual/slack-keri-archive.xml new file mode 100644 index 0000000..87ce003 --- /dev/null +++ b/search-index-typesense/config/config-sitemaps-manual/slack-keri-archive.xml @@ -0,0 +1,69 @@ + + + + + https://weboftrust.github.io/WOT-terms/slack/html/ + + + https://weboftrust.github.io/WOT-terms/slack/html/general.html + + + https://weboftrust.github.io/WOT-terms/slack/html/keripy.html + + + https://weboftrust.github.io/WOT-terms/slack/html/edu.html + + + https://weboftrust.github.io/WOT-terms/slack/html/cesr-dev.html + + + https://weboftrust.github.io/WOT-terms/slack/html/signify-dev.html + + + https://weboftrust.github.io/WOT-terms/slack/html/keri-dev.html + + + https://weboftrust.github.io/WOT-terms/slack/html/signify.html + + + https://weboftrust.github.io/WOT-terms/slack/html/did-keri-dev.html + + + https://weboftrust.github.io/WOT-terms/slack/html/vlei.html + + + https://weboftrust.github.io/WOT-terms/slack/html/licencing.html + + + https://weboftrust.github.io/WOT-terms/slack/html/introductions.html + + + https://weboftrust.github.io/WOT-terms/slack/html/keriml.html + + + https://weboftrust.github.io/WOT-terms/slack/html/did-keri.html + + + https://weboftrust.github.io/WOT-terms/slack/html/iiw-nov-2022.html + + + https://weboftrust.github.io/WOT-terms/slack/html/keri-rs.html + + + https://weboftrust.github.io/WOT-terms/slack/html/governance.html + + + https://weboftrust.github.io/WOT-terms/slack/html/cesr.html + + + https://weboftrust.github.io/WOT-terms/slack/html/random.html + + + https://weboftrust.github.io/WOT-terms/slack/html/keri-cesr-licensing.html + + + https://weboftrust.github.io/WOT-terms/slack/html/keri-swift.html + + \ No newline at end of file diff --git a/search-index-typesense/config/configOverrides.json b/search-index-typesense/config/configOverrides.json new file mode 100644 index 0000000..6df7179 --- /dev/null +++ b/search-index-typesense/config/configOverrides.json @@ -0,0 +1,72 @@ +[ + { + "name": "Diger", + "query": "Diger", + "url": "https://github.com/WebOfTrust/keripy/blob/main/src/keri/core/coring.py", + "position": 1, + "match": "exact" + }, + { + "name": "keriForMuggels", + "query": "Keri for Muggles", + "url": "https://github.com/SmithSamuelM/Papers/blob/master/presentations/KERI_for_Muggles.pdf", + "position": 1, + "match": "exact" + }, + { + "name": "keri", + "query": "keri", + "url": "https://github.com/WebOfTrust/keri/blob/main/README.md", + "position": 1, + "match": "exact" + }, + { + "name": "acdcForMuggles", + "query": "ACDC for Muggles", + "url": "https://docs.google.com/presentation/d/1mO1EZa9BcjAjWEzw7DWi124uMfyNyDeM3HuajsGNoTo/", + "position": 1, + "match": "exact" + }, + { + "name": "supplyChain", + "query": "supply chain", + "url": "https://docs.google.com/presentation/d/1tF_OFGAKUz9RKCLTdwDYDu7hJuEbFz-LQ6PAih7HBK8/", + "position": 1, + "match": "exact" + }, + { + "name": "DIDCommMythconceptions", + "query": "errors", + "url": "https://docs.google.com/presentation/d/1wz1cqUDI8M9w1Q8-gvJ_8zCjefTOd68LmrGj2UCBgI0/", + "position": 1, + "match": "exact" + }, + { + "name": "EcosystemGovernanceFrameworkTechnicalRequirementsPart1KERIInfrastructurePrep", + "query": "governance", + "url": "https://docs.google.com/document/d/1fpHz6yWQKYu57MdRdY1uo4NkW-up5frJ/", + "position": 1, + "match": "exact" + }, + { + "name": "CESRforFirstYearWizards", + "query": "wizard", + "url": "https://docs.google.com/presentation/d/12nX_IIPp5xw8qAxhZy-ae2aWYytYQmFBbB9K3PcVhqQ/", + "position": 1, + "match": "exact" + }, + { + "name": "TEL", + "query": "tel", + "url": "https://github.com/WebOfTrust/keripy/blob/main/ref/tel.md", + "position": 1, + "match": "exact" + }, + { + "name": "Gleif", + "query": "gleif", + "url": "https://www.gleif.org/en/about/governance/board-of-directors", + "position": 1, + "match": "exact" + } +] \ No newline at end of file diff --git a/search-index-typesense/config/configScraperGenericSitemaps.mjs b/search-index-typesense/config/configScraperGenericSitemaps.mjs new file mode 100644 index 0000000..e92cdc6 --- /dev/null +++ b/search-index-typesense/config/configScraperGenericSitemaps.mjs @@ -0,0 +1,416 @@ +import createInput from '../modules/createInput.mjs'; +import scrape from '../modules/scrape.mjs'; +import extractMainContent from '../modules/extractMainContent.mjs'; +import getTextContent from '../modules/getTextContent.mjs'; +import logger from '../modules/logger.mjs'; + + +/** + * ESSIFlabs + * + * + */ + +const configESSIFlabs = { + sitemap: await createInput({ + sourceType: 'remoteXMLsitemap', + sourcePath: 'https://essif-lab.github.io/framework/sitemap.xml', + }), + siteName: 'eSSIF-Lab', + source: 'eSSIF-Lab', + category: 'Blogs', + author: '', + destinationFile: 'search-index-typesense/search-index-entries/eSSIF-Lab.jsonl', + domQueryForContent: 'article .markdown p, article .markdown h1, article .markdown h2, article .markdown h3, article .markdown h4, article .markdown h5, article .markdown h6, article .markdown li, article .markdown img, article .markdown pre, article .markdown code' +} + +async function customScrapeESSIFlabs(page, domQueryForContent, pageUrl) { + logger.setLogFile('success.log'); + logger.log('pageUrl: ' + pageUrl); + + const mainContent = await extractMainContent(page, domQueryForContent); + + // let pageTitle; + // pageTitle = await page.$eval('article header h1', (element) => { + // element.textContent.trim() + // }); + const pageTitle = await getTextContent(page, 'article h1'); + + // const hierarchyLevels = await page.$$eval('.breadcrumbs__link', (nodes) => + // nodes.map((node) => node.textContent.trim()) + // ); + + + let all = {}; + all.mainContent = mainContent; + all.pageTitle = pageTitle; + return all; +} + + + +/** + * Gleif + * + * + */ + +const configGleif = { + // // 1: Use a local created sitemap + // sitemap: await createInput({ + // sourceType: 'localXMLsitemap', + // sourcePath: 'search-index-typesense/sitemaps/sitemap-www.gleif.org.xml', + // }), + + // 2: Use html sitemap on website + sitemap: await createInput({ + sourceType: 'querySelector', + sourcePath: 'https://www.gleif.org/en/meta/sitemap', + queryString: '.content ul li a',// must be an a element + excludeURLs: 'search-index-typesense/config/config-sitemaps-exlude-urls/gleifExcludeUrls.json' + }), + siteName: 'Gleif website', + source: 'Gleif website', + category: 'Blogs', + author: '', + destinationFile: 'search-index-typesense/search-index-entries/gleif.jsonl', + domQueryForContent: 'article .content p, article .content h1, article .content h2, article .content h3, article .content h4, article .content h5, article .content h6, article .content li, article .content img, article .content pre, article .content code' +} + +async function customScrapeGleif(page, domQueryForContent, pageUrl) { + logger.setLogFile('success.log'); + logger.log('pageUrl: ' + pageUrl); + + const mainContent = await extractMainContent(page, domQueryForContent); + + const creationDate = await getTextContent(page, '.meta li'); + + // let pageTitle; + // pageTitle = await page.$eval('.content h1', (element) => { + // return element.textContent.trim() + // }); + + const pageTitle = await getTextContent(page, '.content h1'); + + + let all = {}; + all.mainContent = mainContent; + all.pageTitle = pageTitle; + all.creationDate = creationDate; + return all; +} + + + +// /** +// * gleifPDF +// * +// * +// */ + +// const configGleifPDF = { +// // 1: Use a local created sitemap +// sitemap: await createInput({ +// sourceType: 'localXMLsitemap', +// sourcePath: 'search-index-typesense/sitemaps/sitemap-www.gleif.org-pdf.xml', +// }), + +// // // 2: Use html sitemap on website +// // sitemap: await createInput({ +// // sourceType: 'querySelector', +// // sourcePath: 'https://www.gleif.org/en/meta/sitemap', +// // queryString: '.content ul li a',// must be an a element +// // excludeURLs: 'search-index-typesense/config/config-sitemaps-exlude-urls/gleifExcludeUrls.json' +// // }), +// siteName: 'Gleif website', +// source: 'Gleif website', +// category: 'Blogs', +// author: '', +// destinationFile: 'search-index-typesense/search-index-entries/gleifPDF.jsonl' +// } + +// async function customScrapeGleifPDF(page, domQueryForContent, pageUrl) { +// logger.setLogFile('success.log'); +// logger.log('pageUrl: ' + pageUrl); + +// const mainContent = await extractMainContent(page, domQueryForContent); + +// const creationDate = await getTextContent(page, '.meta li'); + +// // let pageTitle; +// // pageTitle = await page.$eval('.content h1', (element) => { +// // return element.textContent.trim() +// // }); + +// const pageTitle = await getTextContent(page, '.content h1'); + + +// let all = {}; +// all.mainContent = mainContent; +// all.pageTitle = pageTitle; +// all.creationDate = creationDate; +// return all; +// } + + + +/** + * ReadTheDocs Keripy + * + * + */ + +const configReadTheDocsKeripy = { + sitemap: await createInput({ + sourceType: 'localXMLsitemap', + sourcePath: 'search-index-typesense/sitemaps/sitemap-keripy.readthedocs.io.xml', + }), + siteName: 'Python Implementation of the KERI Core Libraries', + source: 'Python Implementation of the KERI Core Libraries', + category: 'Blogs', + author: 'Dr. Samuel Smith and contributors', + destinationFile: 'search-index-typesense/search-index-entries/readthedocs.keripy.io.jsonl', + domQueryForContent: '.document' +} + +async function customScrapeReadTheDocsKeripy(page, domQueryForContent, pageUrl) { + logger.setLogFile('success.log'); + logger.log('pageUrl: ' + pageUrl); + + const mainContent = await extractMainContent(page, domQueryForContent); + + const pageTitle = await getTextContent(page, 'section h1'); + + let all = {}; + all.mainContent = mainContent; + all.pageTitle = pageTitle; + return all; +} + + + +/** + * ReadTheDocs Keria + * + * + */ + +const configReadTheDocsKeria = { + sitemap: await createInput({ + sourceType: 'localXMLsitemap', + sourcePath: 'search-index-typesense/sitemaps/sitemap-keria.readthedocs.io.xml', + }), + siteName: 'Python Implementation of the KERI Core Libraries', + source: 'Python Implementation of the KERI Core Libraries', + category: 'Blogs', + author: 'Dr. Samuel Smith and contributors', + destinationFile: 'search-index-typesense/search-index-entries/readthedocs.keria.io.jsonl', + domQueryForContent: '.document' +} + +async function customScrapeReadTheDocsKeria(page, domQueryForContent, pageUrl) { + logger.setLogFile('success.log'); + logger.log('pageUrl: ' + pageUrl); + + const mainContent = await extractMainContent(page, domQueryForContent); + + const pageTitle = await getTextContent(page, 'section h1'); + + let all = {}; + all.mainContent = mainContent; + all.pageTitle = pageTitle; + return all; +} + + + +/** + * ReadTheDocs Signifypy + * + * + */ + +const configReadTheDocsSignifypy = { + sitemap: await createInput({ + sourceType: 'localXMLsitemap', + sourcePath: 'search-index-typesense/sitemaps/sitemap-signifypy.readthedocs.io.xml', + }), + siteName: 'Python Implementation of the KERI Core Libraries', + source: 'Python Implementation of the KERI Core Libraries', + category: 'Blogs', + author: 'Dr. Samuel Smith and contributors', + destinationFile: 'search-index-typesense/search-index-entries/readthedocs.signifypy.io.jsonl', + domQueryForContent: '.document' +} + +async function customScrapeReadTheDocsSignifypy(page, domQueryForContent, pageUrl) { + logger.setLogFile('success.log'); + logger.log('pageUrl: ' + pageUrl); + + const mainContent = await extractMainContent(page, domQueryForContent); + + const pageTitle = await getTextContent(page, 'section h1'); + + let all = {}; + all.mainContent = mainContent; + all.pageTitle = pageTitle; + return all; +} + + + +/** + * WOTterms + * + * + */ + +const configWOTterms = { + sitemap: await createInput({ + sourceType: 'remoteXMLsitemap', + sourcePath: 'https://weboftrust.github.io/WOT-terms/sitemap.xml', + excludeURLs: 'search-index-typesense/config/config-sitemaps-exlude-urls/wotTermsExcludeUrls.json' + }), + siteName: 'KERISSE (this site)', + source: 'KERISSE (this site)', + category: 'KERISSE (this site)', + author: 'Henk van Cann', + destinationFile: 'search-index-typesense/search-index-entries/WOT-terms.jsonl', + domQueryForContent: 'article .markdown p, article .markdown h1, article .markdown h2, article .markdown h3, article .markdown h4, article .markdown h5, article .markdown h6, article .markdown li, article .markdown img, article .markdown pre, article .markdown code' +} + +async function customScrapeWOTterms(page, domQueryForContent, pageUrl) { + logger.setLogFile('success.log'); + logger.log('pageUrl: ' + pageUrl); + + const mainContent = await extractMainContent(page, domQueryForContent); + + let type = await page.$eval('article', (element) => { + switch (element.getAttribute('data-type')) { + case 'G': + return 'General'; + case 'S': + return 'SSI'; + case 'K': + return 'KERI/ACDC specific'; + } + }); + + // Find the breadcrumbs element and all its child
  • elements + let hierarchyLevels = await page.$$eval('.breadcrumbs__link', (nodes) => + nodes.map((node) => node.textContent.trim()) + ); + + // Get the value of the data-level attribute from the article element + let knowledgeLevel = await page.$eval('article', (element) => { + return element.getAttribute('data-level'); + }); + + // let pageTitle = await page.$eval('article header h1', (element) => { + // return element.textContent.trim() + // }); + const pageTitle = await getTextContent(page, 'article h1:first-of-type'); + + + let all = {}; + all.mainContent = mainContent; + all.type = type; + all.hierarchyLevel0 = hierarchyLevels[0]; + all.hierarchyLevel1 = hierarchyLevels[1]; + all.hierarchyLevel2 = hierarchyLevels[2]; + all.hierarchyLevel3 = hierarchyLevels[3]; + all.knowledgeLevel = knowledgeLevel; + all.pageTitle = pageTitle; + return all; +} + + + +// /** +// * WOTgloss +// * +// * +// */ + +// const configWOTgloss = { +// sitemap: await createInput({ +// sourceType: 'querySelector', +// sourcePath: 'https://github.com/weboftrust/WOT-terms/wiki', +// queryString: '#wiki-pages-box a', +// }), +// siteName: 'WebofTrust glossary', +// source: 'WebofTrust glossary', +// category: 'Glossary', +// author: 'Henk van Cann', +// destinationFile: 'search-index-typesense/search-index-entries/wotgloss.jsonl', +// domQueryForContent: '.markdown-body p, .markdown-body h1, .markdown-body h2, .markdown-body h3, .markdown-body h4, .markdown-body h5, .markdown-body h6, .markdown-body li, .markdown-body img, .markdown-body pre, .markdown-body code' +// } + +// async function customScrapeWOTgloss(page, domQueryForContent, pageUrl) { +// logger.setLogFile('success.log'); +// logger.log('pageUrl: ' + pageUrl); + +// const mainContent = await extractMainContent(page, domQueryForContent); + +// // let pageTitle = await page.$eval('.repository-content h1', (element) => { +// // return element.textContent.trim() +// // }); +// const pageTitle = await getTextContent(page, '.repository-content h1'); + +// let all = {}; +// all.mainContent = mainContent; +// all.pageTitle = pageTitle; +// return all; +// } + + + +/** + * Slack Keri Archive + * + * + */ + +const configSlackKeriArchive = { + sitemap: await createInput({ + sourceType: 'localXMLsitemap', + sourcePath: 'search-index-typesense/sitemaps/slack-keri-archive.xml', + }), + siteName: 'Slack Keri Archive', + source: 'Slack Keri Archive', + category: 'Slack Keri Archive', + author: 'Slack Keri Members', + destinationFile: 'search-index-typesense/search-index-entries/slack-keri-archive.jsonl', + domQueryForContent: 'body' +} + +async function customScrapeSlackKeriArchive(page, domQueryForContent, pageUrl) { + logger.setLogFile('success.log'); + logger.log('pageUrl: ' + pageUrl); + + const mainContent = await extractMainContent(page, domQueryForContent); + + const pageTitle = await getTextContent(page, 'h1'); + + let all = {}; + all.mainContent = mainContent; + all.pageTitle = pageTitle; + return all; +} + + + + + + +export default async function () { + scrape(configESSIFlabs, customScrapeESSIFlabs); + scrape(configGleif, customScrapeGleif); + // scrape(configGleifPDF, customScrapeGleifPDF); + scrape(configReadTheDocsKeripy, customScrapeReadTheDocsKeripy); + scrape(configReadTheDocsKeria, customScrapeReadTheDocsKeria); + scrape(configReadTheDocsSignifypy, customScrapeReadTheDocsSignifypy); + scrape(configWOTterms, customScrapeWOTterms); + // scrape(configWOTgloss, customScrapeWOTgloss); + scrape(configSlackKeriArchive, customScrapeSlackKeriArchive); +}; \ No newline at end of file diff --git a/search-index-typesense/config/config_sitemaps_create.sh b/search-index-typesense/config/config_sitemaps_create.sh new file mode 100644 index 0000000..c7a2b41 --- /dev/null +++ b/search-index-typesense/config/config_sitemaps_create.sh @@ -0,0 +1,77 @@ +#!/bin/bash + + +# Author: Kor Dwarshuis +# Created: 2023 +# Updated: - +# Description: This script starts sitemap creator scripts. Not every URL that is scraped needs a sitemap via this route: sometimes a sitemap is already available, for example in the root of a website (sitemap.xml). Or via an HTLM sitemap available via a URL. + +# Import variables from .env file +source .env + + +######################################## +# General websites +######################################## + +# `sitemap-generator-cli` should be installed globally via `npm install -g sitemap-generator-cli` to run the `sitemap-generator` command. +sitemap-generator https://keria.readthedocs.io --verbose -f ./search-index-typesense/sitemaps/sitemap-keria.readthedocs.io.xml + +sitemap-generator https://keripy.readthedocs.io --verbose -f ./search-index-typesense/sitemaps/sitemap-keripy.readthedocs.io.xml + +sitemap-generator https://signifypy.readthedocs.io --verbose -f ./search-index-typesense/sitemaps/sitemap-signifypy.readthedocs.io.xml + + + + +######################################## +# Github repos - createSitemapGithub.mjs +######################################## + +# How to use: +# $ node ${SEARCH_INDEX_DIR}/createSitemapGithub.mjs + +# Github owner: Trust over IP +node ${SEARCH_INDEX_DIR}/createSitemapGithub.mjs trustoverip tswg-acdc-specification main Code +node ${SEARCH_INDEX_DIR}/createSitemapGithub.mjs trustoverip tswg-did-method-webs-specification main Code +node ${SEARCH_INDEX_DIR}/createSitemapGithub.mjs trustoverip tswg-cesr-specification main Code +node ${SEARCH_INDEX_DIR}/createSitemapGithub.mjs trustoverip tswg-cesr-proof-specification main Code +node ${SEARCH_INDEX_DIR}/createSitemapGithub.mjs trustoverip tswg-oobi-specification main Code +node ${SEARCH_INDEX_DIR}/createSitemapGithub.mjs trustoverip tswg-ipex-specification main Code +node ${SEARCH_INDEX_DIR}/createSitemapGithub.mjs trustoverip tswg-acdc-specification-archived main Code +node ${SEARCH_INDEX_DIR}/createSitemapGithub.mjs trustoverip acdc main Code +node ${SEARCH_INDEX_DIR}/createSitemapGithub.mjs trustoverip TSS0033-technology-stack-acdc main Code +node ${SEARCH_INDEX_DIR}/createSitemapGithub.mjs trustoverip tswg-keri-specification main Code +node ${SEARCH_INDEX_DIR}/createSitemapGithub.mjs trustoverip tswg-ptel-specification main Code +node ${SEARCH_INDEX_DIR}/createSitemapGithub.mjs trustoverip keri main Code + +# Github owner: Sam Smith +node ${SEARCH_INDEX_DIR}/createSitemapGithub.mjs SmithSamuelM Papers master Whitepapers + +# Github owner: WebOfTrust +node ${SEARCH_INDEX_DIR}/createSitemapGithub.mjs WebOfTrust cardano-backer main Code +node ${SEARCH_INDEX_DIR}/createSitemapGithub.mjs WebOfTrust cesride main Code +node ${SEARCH_INDEX_DIR}/createSitemapGithub.mjs WebOfTrust cesrpy main Code +node ${SEARCH_INDEX_DIR}/createSitemapGithub.mjs WebOfTrust gcp-ksm-shim main Code +node ${SEARCH_INDEX_DIR}/createSitemapGithub.mjs WebOfTrust ietf-did-keri main Code +node ${SEARCH_INDEX_DIR}/createSitemapGithub.mjs WebOfTrust kara main Code +node ${SEARCH_INDEX_DIR}/createSitemapGithub.mjs WebOfTrust kassh main Code +node ${SEARCH_INDEX_DIR}/createSitemapGithub.mjs WebOfTrust keep main Code +node ${SEARCH_INDEX_DIR}/createSitemapGithub.mjs WebOfTrust keri main Code +node ${SEARCH_INDEX_DIR}/createSitemapGithub.mjs WebOfTrust keri-swift main Code +node ${SEARCH_INDEX_DIR}/createSitemapGithub.mjs WebOfTrust keria main Code +node ${SEARCH_INDEX_DIR}/createSitemapGithub.mjs WebOfTrust keride main Code +node ${SEARCH_INDEX_DIR}/createSitemapGithub.mjs WebOfTrust keriox main Code +node ${SEARCH_INDEX_DIR}/createSitemapGithub.mjs WebOfTrust keripy main Code +node ${SEARCH_INDEX_DIR}/createSitemapGithub.mjs WebOfTrust parside main Code +node ${SEARCH_INDEX_DIR}/createSitemapGithub.mjs WebOfTrust saidide main Code +node ${SEARCH_INDEX_DIR}/createSitemapGithub.mjs WebOfTrust schema main Code +node ${SEARCH_INDEX_DIR}/createSitemapGithub.mjs WebOfTrust scir main Code +node ${SEARCH_INDEX_DIR}/createSitemapGithub.mjs WebOfTrust shkr main Code +node ${SEARCH_INDEX_DIR}/createSitemapGithub.mjs WebOfTrust signifi main Code +node ${SEARCH_INDEX_DIR}/createSitemapGithub.mjs WebOfTrust signifide main Code +node ${SEARCH_INDEX_DIR}/createSitemapGithub.mjs WebOfTrust signify-ts main Code +node ${SEARCH_INDEX_DIR}/createSitemapGithub.mjs WebOfTrust signifypy main Code +node ${SEARCH_INDEX_DIR}/createSitemapGithub.mjs WebOfTrust vlei dev Code +node ${SEARCH_INDEX_DIR}/createSitemapGithub.mjs WebOfTrust ward main Code + diff --git a/search-index-typesense/copy_manual_files.sh b/search-index-typesense/copy_manual_files.sh new file mode 100644 index 0000000..fe77fba --- /dev/null +++ b/search-index-typesense/copy_manual_files.sh @@ -0,0 +1,39 @@ +#!/bin/bash + +# Author: Kor Dwarshuis +# Created: 2023 +# Updated: - +# Description: Copy manually created files to the output directories of the automated scripts so they will be included in the final output directories + +# Import variables from .env file +source .env + + +############## COPY SCRAPED CONTENT (JSON) FROM HANDMADE DIR TO AUTOMATED DIR ############## +# Handmade content entries +search_index_entries_manual_dir="$(pwd)/${SEARCH_INDEX_DIR}/config/config-search-index-entries-manual" + +# Automated entries +search_index_entries_dir="$(pwd)/${SEARCH_INDEX_DIR}/search-index-entries" + +# Copy all .json files from the handmade directory to the output directory +for file in "$search_index_entries_manual_dir"/*.{json,jsonl}; do + if [[ -f "$file" ]]; then # this check ensures it's a file, in case no .json or .jsonl files are found + cp "$file" "$search_index_entries_dir" + fi +done + + + +############## COPY SITEMAP.XML FROM HANDMADE DIR TO AUTOMATED DIR ############## +# Handmade sitemaps +sitemaps_manual_dir="$(pwd)/${SEARCH_INDEX_DIR}/config/config-sitemaps-manual" + +# Automated entries +sitemaps_dir="$(pwd)/${SEARCH_INDEX_DIR}/sitemaps" + + +# Copy manually created sitemap files to the output directory +for file in "$sitemaps_manual_dir"/*.xml; do + cp "$file" "$sitemaps_dir" +done diff --git a/search-index-typesense/countLinesInJsonlFiles.mjs b/search-index-typesense/countLinesInJsonlFiles.mjs new file mode 100644 index 0000000..fde9c78 --- /dev/null +++ b/search-index-typesense/countLinesInJsonlFiles.mjs @@ -0,0 +1,61 @@ +/** + * Author: Kor Dwarshuis + * Date: 2023-09-14 + * Description: + * This Node.js script reads all .jsonl files in a specified directory, counts the + * number of lines in each file, and calculates the grand total of lines across all files. + * + * Input: Directory path containing .jsonl files (inputDir) + * Output: Writes the number of lines for each .jsonl file and a grand total to a file (outputFile) + * + * Usage: run the script from the root of the project + * + */ + +import fs from 'fs/promises'; +import path from 'path'; + +// Configurable input and output paths +const inputDir = './search-index-typesense/search-index-entries'; // Directory containing .jsonl files +const outputDir = './search-index-typesense/logs'; // Directory where the output file will be saved +const outputFilename = 'entry_counts.txt'; // Output filename + +// Initialize grand total of lines +let grandTotal = 0; + +// Initialize output string +let outputString = ''; + +// Function to count lines in a single file +const countLinesInFile = async (filePath) => { + const data = await fs.readFile(filePath, 'utf-8'); + const lines = data.split(/\r?\n/).length - 1; + return lines; +}; + +// Main function to orchestrate the whole process +const main = async () => { + try { + const files = await fs.readdir(inputDir); + const jsonlFiles = files.filter(file => path.extname(file) === '.jsonl'); + + for (const file of jsonlFiles) { + const filePath = path.join(inputDir, file); + const lineCount = await countLinesInFile(filePath); + + grandTotal += lineCount; + outputString += `The file ${file} has ${lineCount} lines.\n`; + } + + outputString += `The grand total of lines across all .jsonl files is ${grandTotal}.\n`; + + const outputPath = path.join(outputDir, outputFilename); + await fs.writeFile(outputPath, outputString); + + console.log(`Results written to ${outputPath}`); + } catch (err) { + console.error('An error occurred:', err); + } +}; + +main(); diff --git a/search-index-typesense/createHtmlFileWithAllImages.mjs b/search-index-typesense/createHtmlFileWithAllImages.mjs new file mode 100644 index 0000000..f324d9c --- /dev/null +++ b/search-index-typesense/createHtmlFileWithAllImages.mjs @@ -0,0 +1,56 @@ +/** + * Author: Kor Dwarshuis + * Date: 2024-03-12 + * Description: + * + */ + + +import { promises as fs } from 'fs'; + +// Function to generate Markdown file with img elements +async function generateMarkdown(inputFile, outputFile) { + try { + // Read the imgUrl array from the input JSON file + const jsonContent = await fs.readFile(inputFile, 'utf-8'); + const imgUrlArray = JSON.parse(jsonContent); + + // Sort the array based on the "count" property in descending order + imgUrlArray.sort((a, b) => b.count - a.count); + + // Create Markdown content with img elements and additional information + let markdownContent = '# All images found\n\n'; + markdownContent += `Total unique images found: ${imgUrlArray.length}\n\n`; + markdownContent += 'Images can hold anything: photo’s, diagrams, charts etc.\n\n'; + + imgUrlArray.forEach((imageInfo, index) => { + + let imageInfoMetaSizeInKB = (imageInfo && imageInfo.meta && imageInfo.meta.sizeInKB) ? imageInfo.meta.sizeInKB : 'N/A'; + let imageInfoMetaHash = (imageInfo && imageInfo.meta && imageInfo.meta.hash) ? imageInfo.meta.hash : 'N/A'; + + markdownContent += `## Image ${index + 1}\n`; + markdownContent += `![Image](${imageInfo.imgUrl})\n`; + + // No empty space allowed to the left of the pipe character due to markdown table formatting + markdownContent += ` +||| +|---|---| +|Count|${imageInfo.count}| +|Size (kB)|${imageInfoMetaSizeInKB}| +|SHA256|${imageInfoMetaHash}| +\n\n`; + }); + + // Write Markdown content to output file + await fs.writeFile(outputFile, markdownContent); + console.log('Markdown file generated successfully:', outputFile); + } catch (err) { + console.error('Error generating Markdown file:', err); + } +} + +// Example usage: +const inputFile = './static/json/all-images/all-images.json'; // Specify input JSON file containing image information +const outputFile = './docs/05_resources/all-images.md'; // Specify output Markdown file + +generateMarkdown(inputFile, outputFile); diff --git a/search-index-typesense/createSitemapGithub.mjs b/search-index-typesense/createSitemapGithub.mjs new file mode 100644 index 0000000..d876e0c --- /dev/null +++ b/search-index-typesense/createSitemapGithub.mjs @@ -0,0 +1,75 @@ +/* + Author: Kor Dwarshuis + Created: 2023-06-26 + Updated: - + Description: This script generates a sitemap for a GitHub repository. The sitemap includes all files in the repository. The sitemap is saved in a file named after the repository with the .xml extension. The script requires the repository owner, repository name, and the directory where the sitemap should be saved as arguments. The script uses the GitHub API to fetch the repository tree. + + It then filters the tree to include only the blob-type items (files) and constructs the corresponding URLs. The resulting URLs are used to generate the sitemap.xml file. + + Run it fromt the project-root using the following command: + node search-index-typesense/createSitemapGithub.mjs + + Example: + $ node search-index-typesense/createSitemapGithub.mjs WebOfTrust keripy main search-index-typesense/sitemaps + + Example writing to root of project file system: + $ node search-index-typesense/createSitemapGithub.js WebOfTrust keripy main . + + The script will generate the sitemap.xml file in the specified sitemap directory. +*/ + +import axios from 'axios'; +import fs from 'fs'; +import path from 'path'; +import logger from './modules/logger.mjs'; +import { config } from 'dotenv'; +config(); + +const args = process.argv.slice(2); +const repositoryOwner = args[0]; +const repositoryName = args[1]; +const branchName = args[2]; +const category = args[3]; +const githubSitemapDirectory = process.env.SEARCH_INDEX_DIR + '/sitemaps/github'; + +async function getRepositoryTree() { + try { + const response = await axios.get(`https://api.github.com/repos/${repositoryOwner}/${repositoryName}/git/trees/${branchName}?recursive=1`, { + headers: { 'Authorization': `${process.env.GITHUB_AUTH_TOKEN}` } + }) + ; + return response.data.tree; + } catch (error) { + logger.setLogFile('error.log'); + logger.log('Failed to fetch repository tree' + error); + return []; + } +} + +async function generateSitemap() { + const repositoryTree = await getRepositoryTree(); + + const fileUrls = repositoryTree + .filter((item) => item.type === 'blob') + .map((item) => `https://github.com/${repositoryOwner}/${repositoryName}/blob/${branchName}/${item.path}`); + + const sitemapXml = ` + + ${fileUrls.map((url) => `${url}`).join('\n')} + + `; + + // If githubSitemapDirectory does not exist, create it + if (!fs.existsSync(githubSitemapDirectory)) { + fs.mkdirSync(githubSitemapDirectory); + } + + const sitemapFilePath = path.join(githubSitemapDirectory, `sitemap.githubcom.${repositoryOwner}.${repositoryName}-${branchName}.${category}.xml`); + fs.writeFileSync(sitemapFilePath, sitemapXml); + + logger.setLogFile('success.log'); + logger.log(`${sitemapFilePath} sitemap generated successfully`); + +} + +generateSitemap(); diff --git a/search-index-typesense/extractData-test.mjs b/search-index-typesense/extractData-test.mjs new file mode 100644 index 0000000..987e4fa --- /dev/null +++ b/search-index-typesense/extractData-test.mjs @@ -0,0 +1,14 @@ +/* + Author: Kor Dwarshuis + Created: 2023-03-16 + Updated: - + Description: +*/ + +// import scraperGithub from './config/configScraperGithub.mjs'; +// import scraperGenericSingleUrls from './prepareScraperSingleUrlsFromWotTermsGoogleSheet.mjs'; +import scraperGenericSitemapTest from './config/configScraperGenericSitemapsTest.mjs'; + +// scraperGithub(); +// scraperGenericSingleUrls(); +scraperGenericSitemapTest(); \ No newline at end of file diff --git a/search-index-typesense/extractData.mjs b/search-index-typesense/extractData.mjs new file mode 100644 index 0000000..520534b --- /dev/null +++ b/search-index-typesense/extractData.mjs @@ -0,0 +1,14 @@ +/* + Author: Kor Dwarshuis + Created: 2023-03-16 + Updated: - + Description: +*/ + +import scraperGithub from './prepareScraperGithub.mjs'; +import scraperGenericSingleUrls from './prepareScraperSingleUrlsFromWotTermsGoogleSheet.mjs'; +import scraperGenericSitemap from './config/configScraperGenericSitemaps.mjs'; + +scraperGithub(); +scraperGenericSingleUrls(); +scraperGenericSitemap(); \ No newline at end of file diff --git a/search-index-typesense/extractDataPrio1.mjs b/search-index-typesense/extractDataPrio1.mjs new file mode 100644 index 0000000..09602ed --- /dev/null +++ b/search-index-typesense/extractDataPrio1.mjs @@ -0,0 +1,8 @@ +/* + Author: Kor Dwarshuis + Created: 2023-03-16 + Updated: - + Description: +*/ + +//TODO: \ No newline at end of file diff --git a/search-index-typesense/findAllImgs.mjs b/search-index-typesense/findAllImgs.mjs new file mode 100644 index 0000000..785b4ec --- /dev/null +++ b/search-index-typesense/findAllImgs.mjs @@ -0,0 +1,117 @@ +/** + * Author: Kor Dwarshuis + * Date: 2024-03-12 + * Description: + * + */ + +// const fs = require('fs'); +// const path = require('pat); + +import fs from 'fs'; +import path from 'path'; +import readline from 'readline'; +import { URL } from 'url'; +import { getImageMetaData } from './modules/getImageMetaData.mjs'; + +function processJSONLFiles(directory, outputFile) { + // Object to store unique imgUrl and their count, along with domain mismatch count + let imgUrlCount = {}; + let domainMismatchCount = {}; + + // Read files in the directory + fs.readdir(directory, (err, files) => { + if (err) { + console.error('Error reading directory:', err); + return; + } + + // Filter files ending with '.jsonl' + const jsonlFiles = files.filter(file => file.endsWith('.jsonl')); + + // Loop through each JSONL file + jsonlFiles.forEach(jsonlFile => { + const filePath = path.join(directory, jsonlFile); + + // Create readline interface + const rl = readline.createInterface({ + input: fs.createReadStream(filePath), + crlfDelay: Infinity + }); + + rl.on('line', (line) => { + try { + const jsonObj = JSON.parse(line); + if (jsonObj.imgUrl && jsonObj.imgUrl.trim() !== '') { + const imgUrl = jsonObj.imgUrl.trim(); + const url = jsonObj.url.trim(); + + // Increment count for existing imgUrl or initialize count to 1 + imgUrlCount[imgUrl] = (imgUrlCount[imgUrl] || 0) + 1; + + // Parse URLs to extract domains + const imgUrlDomain = (new URL(imgUrl)).hostname; + const urlDomain = (new URL(url)).hostname; + + // Increment domain mismatch count if domains are different + if (imgUrlDomain !== urlDomain) { + domainMismatchCount[imgUrl] = (domainMismatchCount[imgUrl] || 0) + 1; + } + } + } catch (err) { + console.error('Error parsing JSON:', err); + } + }); + + rl.on('close', () => { + (async () => { + try { + const imgUrlArray = await Promise.all(Object.keys(imgUrlCount).map(async imgUrl => { + try { + const info = await getImageMetaData(imgUrl); + console.log(info); // You can remove this line if you don't need to log the info + return { + imgUrl, + count: imgUrlCount[imgUrl], + domainMismatchCount: domainMismatchCount[imgUrl] || 0, + meta: info + }; + } catch (error) { + console.error(error); + return { + imgUrl, + count: imgUrlCount[imgUrl], + domainMismatchCount: domainMismatchCount[imgUrl] || 0, + meta: null + }; + } + })); + const jsonContent = JSON.stringify(imgUrlArray, null, 4); + fs.writeFile(outputFile, jsonContent, (err) => { + if (err) { + console.error('Error writing file:', err); + return; + } + console.log('Unique imgUrl values with count and domain mismatch count written to file:', outputFile); + }); + } catch (error) { + console.error(error); + } + })(); + + + }); + }); + }); +} + + + + + +// Example usage: +const directory = './search-index-typesense/search-index-entries'; // Specify directory +const outputFile = './static/json/all-images/all-images.json'; // Specify output file + +processJSONLFiles(directory, outputFile); + diff --git a/search-index-typesense/import.sh b/search-index-typesense/import.sh new file mode 100644 index 0000000..6686f9a --- /dev/null +++ b/search-index-typesense/import.sh @@ -0,0 +1,104 @@ +#!/bin/bash + +# Author: Kor Dwarshuis +# Created: 2023 +# Updated: - +# Description: This script imports JSONL files into a Typesense collection (typesense.org). +# Instructions: In order to run this script, you need to have a .env file in the root of the project with the following variables: +# TYPESENSE_ADMIN_API_KEY +# TYPESENSE_HOST +# TYPESENSE_COLLECTION_NAME +# External libraries: jq (https://stedolan.github.io/jq/) and curl (https://curl.se/) are required to run this script. + +# Logger generates a log file with a timestamp and from which file the message comes from. +source ./search-index-typesense/logger.sh + +source "$(pwd)/.env" +local_TYPESENSE_ADMIN_API_KEY="${TYPESENSE_ADMIN_API_KEY}" +local_TYPESENSE_HOST="${TYPESENSE_HOST}" +local_TYPESENSE_COLLECTION_NAME="${TYPESENSE_COLLECTION_NAME}" + + +# Use the `local_TYPESENSE_ADMIN_API_KEY`, `local_TYPESENSE_HOST`, and `local_TYPESENSE_COLLECTION_NAME` variables anywhere in the script as needed + +setLogFile "success.log" +log "local_TYPESENSE_COLLECTION_NAME:" +log $local_TYPESENSE_COLLECTION_NAME + + + +############## CONFIGURATION ############## +# URL of the endpoint to empty the collection +# explanation: the filter_by parameter is used to delete all documents that have a content field that is not empty +urlDelete="https://${local_TYPESENSE_HOST}.a1.typesense.net/collections/${local_TYPESENSE_COLLECTION_NAME}/documents?filter_by=content:!=''" + +# URL of the endpoint to import documents +urlImport="https://${local_TYPESENSE_HOST}.a1.typesense.net/collections/${local_TYPESENSE_COLLECTION_NAME}/documents/import?action=create" + +# Automated entries +input_dir="$(pwd)/search-index-typesense/search-index-entries" +output_dir="$(pwd)/search-index-typesense/search-index-entries" + +# log files +log_dir="$(pwd)/search-index-typesense/logs" + +############## CONVERT JSON TO JSONL ############## + +convert_json_to_jsonl() { + convert_input_dir="$1" + convert_output_dir="$2" + + # Create the output directory if it doesn't exist + mkdir -p "$convert_output_dir" + + # Loop through all .json files that should be converted to .jsonl + for file in "$convert_input_dir"/*.json; do + # Get the file name without extension + filename=$(basename "$file" .json) + # Convert the file to .jsonl format using jq + jq -c '.[]' "$file" > "$convert_output_dir/$filename.jsonl" + done +} + +convert_json_to_jsonl $input_dir $output_dir + + +############## IMPORT JSONL FILES ############## +# Iterate over each JSONL file in the directory + +setLogFile "success.log" +log "Start importing files: $file" + + +import_jsonl_files_to_search_index() { + import_output_dir="$1" + import_log_dir="$2" + + # Loop through all .jsonl files in the output directory + for file in "$import_output_dir"/*.jsonl; do + # Check if the file exists and is a regular file + if [[ -f "$file" ]]; then + setLogFile "success.log" + log "\n\nImporting file: $file" + + # Extract the filename without extension + filename=$(basename "$file" .jsonl) + + # Execute the cURL command to import the document + curl -H "X-TYPESENSE-API-KEY: ${local_TYPESENSE_ADMIN_API_KEY}" \ + -X POST \ + -T "$file" \ + --http1.1 \ + "$urlImport" >> "$import_log_dir/import-into-search-index.log" + + setLogFile "success.log" + log "\n\nImport completed for file: $file" + log "-------------------------" + + + fi + done +} + +# Start importing the files +import_jsonl_files_to_search_index $output_dir $log_dir \ No newline at end of file diff --git a/search-index-typesense/isLibraryInstalled.mjs b/search-index-typesense/isLibraryInstalled.mjs new file mode 100644 index 0000000..8b2aa0b --- /dev/null +++ b/search-index-typesense/isLibraryInstalled.mjs @@ -0,0 +1,83 @@ +/** + * @file This file checks if the required libraries are installed. + * If not, it logs an error message to the console and to a log file. + * The libraries that are checked are ImageMagick, jq, and curl. + * This script uses the child_process module to execute shell commands and the util module to promisify the exec function. + * The logger module is used to log messages to the console and to a log file. + * @author Kor Dwarshuis + * @version 1.0.0 + * @since 2024-05-21 + */ + +import { exec } from 'child_process'; +import util from 'util'; +import logger from './modules/logger.mjs'; + +const execPromisified = util.promisify(exec); + +async function isLibraryInstalled(libraryName, command = libraryName, expectedOutput = libraryName) { + console.log("Testing if " + libraryName + " is installed"); + try { + const { stdout } = await execPromisified(`${command} --version`); + return stdout.includes(expectedOutput); + } catch (error) { + return false; + } +} + +async function isNpmPackageInstalled(packageName) { + try { + const { stdout } = await execPromisified(`npm list -g ${packageName}`); + return !stdout.includes('empty'); + } catch (error) { + return false; + } +} + +const messages = { + error: ' is not installed', + success: ' is installed' +}; + +// Usage: +if (!await isLibraryInstalled('ImageMagick', 'convert', 'ImageMagick')) { + console.log('ImageMagick' + messages.error); + logger.setLogFile('error.log'); + logger.log('ImageMagick' + messages.error); + +} else { + console.log('ImageMagick' + messages.success); + logger.setLogFile('success.log'); + logger.log('ImageMagick' + messages.success); +} + +if (!await isLibraryInstalled('jq')) { + console.log('jq' + messages.error); + logger.setLogFile('error.log'); + logger.log('jq' + messages.error); + +} else { + console.log('jq' + messages.success); + logger.setLogFile('success.log'); + logger.log('jq' + messages.success); +} + +if (!await isLibraryInstalled('curl')) { + console.log('curl' + messages.error); + logger.setLogFile('error.log'); + logger.log('curl' + messages.error); +} else { + console.log('curl' + messages.success); + logger.setLogFile('success.log'); + logger.log('curl' + messages.success); +} + +if (!await isNpmPackageInstalled('sitemap-generator-cli')) { + console.log('sitemap-generator-cli' + messages.error); + logger.setLogFile('error.log'); + logger.log('sitemap-generator-cli' + messages.error); +} else { + console.log('sitemap-generator-cli' + messages.success); + logger.setLogFile('success.log'); + logger.log('sitemap-generator-cli' + messages.success); +} \ No newline at end of file diff --git a/search-index-typesense/logger.sh b/search-index-typesense/logger.sh new file mode 100644 index 0000000..08d40ad --- /dev/null +++ b/search-index-typesense/logger.sh @@ -0,0 +1,61 @@ +#!/bin/bash + +# Script Name: logger.sh +########################################################################### +# Author: Kor Dwarshuis +# Created: 2023-09-13 +# Updated: - +# Description: This script provides logging functionalities for Bash scripts. +# It defines two primary functions: `setLogFile` and `log`. +# - `setLogFile` allows users to set the filename for the log output. +# - `log` appends a log entry to the set log file, prefixed with a timestamp. +# +# Example Usage: +# To use these logging functions in another script, source this file at the +# top of your script: +# source /path/to/logger.sh +# +# Then, you can use the `setLogFile` and `log` functions as shown below: +# setLogFile "success.log" +# log "This code ran successfully!" +########################################################################### + + + + +# Define log directory and default log file +logsDir="search-index-typesense/logs" +currentLogFile="success.log" + +# Function to set the log file +setLogFile() { + currentLogFile="$1" +} + +# Function to log messages +log() { + local timestamp=$(date +"%H:%M:%S") # Get the current time without milliseconds + local logMessage="[$timestamp] $1" + + echo "$logMessage" # Output to console + + # Write to the currently set log file + echo "$logMessage" >> "${logsDir}/${currentLogFile}" + + # Check for write error + if [ $? -ne 0 ]; then + echo "Error writing to log file" + fi +} + +# # Example usage +# setLogFile "success.log" +# log "This code ran successfully!" + +# # Uncomment the following block to catch errors +# # if some_command; then +# # log "This code ran successfully!" +# # else +# # setLogFile "error.log" +# # log "An error occurred" +# # fi diff --git a/search-index-typesense/main.sh b/search-index-typesense/main.sh new file mode 100644 index 0000000..7e459c7 --- /dev/null +++ b/search-index-typesense/main.sh @@ -0,0 +1,183 @@ +#!/bin/bash + +source ".env" + +# Sets the variable SCRIPT_DIR to the directory where the script itself is located. +SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)" + + +# Function to handle the user's choice +function handle_choice() { + if [[ "$choice" == "1" ]]; then + echo " " + echo " " + echo " ************************************" + echo " The script will now start scraping all sites." + echo " ************************************" + echo " " + echo " " + show_progress + do_scrape_all + elif [[ "$choice" == "2" ]]; then + echo " " + echo " " + echo " ************************************" + echo " The script will now make a backup." + echo " ************************************" + echo " " + echo " " + show_progress + do_backup + elif [[ "$choice" == "3" ]]; then + read -n 1 -r -p " Are you sure you want to import into Typesense? (y/N) " confirm + echo # Empty line below the prompt + if [[ "$confirm" == [yY] ]]; then + echo " " + echo " " + echo " ************************************" + echo " The script will now import into Typesense." + echo " ************************************" + echo " " + echo " " + show_progress + do_import + else + echo "Import operation cancelled." + fi + elif [[ "$choice" == "4" ]]; then + read -n 1 -r -p " Are you sure you want to restore into Typesense? (y/N) " confirm + echo # Empty line below the prompt + if [[ "$confirm" == [yY] ]]; then + echo " " + echo " " + echo " ************************************" + echo " The script will now restore into Typesense." + echo " ************************************" + echo " " + echo " " + show_progress + do_restore + else + echo "Restore operation cancelled." + fi + else + clear + echo " " + echo " " + echo " ************************************" + echo " Goodbye! You chose to exit." + echo " ************************************" + echo " " + echo " " + fi +} + +# Function to display the introduction text +function display_intro() { + clear + echo " " + echo " " + echo " ************************************" + echo " " + echo " ╦╔═╔═╗╦═╗╦╔═╗╔═╗╔═╗ ┌─┐┬─┐┌─┐" + echo " ╠╩╗║╣ ╠╦╝║╚═╗╚═╗║╣ │ │├┬┘│ ┬" + echo " ╩ ╩╚═╝╩╚═╩╚═╝╚═╝╚═╝o└─┘┴└─└─┘ " + echo " " + echo " " + echo " Various scripts related to scraping and indexing in Typesense." + echo " " + echo " " + echo " Please choose one of the following options:" + echo " " + echo " [1] Scrape all sites (scrape + backup) *)" + echo " " + echo " [2] Backup" + echo " " + echo " [3] Import" + echo " " + echo " [4] Restore (import jsonl file into Typesense)" + echo " " + echo " [Q] Quit" + echo " " + echo " " + echo " *) The backup is always made after the scraping is finished" + echo " and is a copy of this latest scrape session." + echo " " + echo " " + +} + +# Function to prompt the user for input +function prompt_input() { + read -n 1 -r -p " Enter your choice (1/2/3/4/5/6/Q)? " choice + echo # Empty line below the prompt + echo # Empty line below the prompt +} + +function do_scrape_all() { + # Start scraping all sites. + source "$SCRIPT_DIR/scrape_start.sh" +} + +function do_scrape_prio_1() { + # Start scraping priority sites only. + source "$SCRIPT_DIR/scrape_prio_1_start.sh" +} + +function do_scrape_test() { + # Start scraping test. + source "$SCRIPT_DIR/scrape_start_test.sh" +} + +function do_backup() { + # Start backing up. + source "$SCRIPT_DIR/backup.sh" +} + +function do_import() { + ######################### + # IMPORTING INTO TYPESENSE CLOUD Open Source Search + ######################### + + # Make collection in Typesense empty. + source "$SCRIPT_DIR/make_collection_empty.sh" + setLogFile "success.log" + log "Making collection empty finished" + + # Import the data into Typesense. + source "$SCRIPT_DIR/import.sh" + setLogFile "success.log" + log "Importing data finished" + + # Import overrides into Typesense. + source "$SCRIPT_DIR/overrides.sh" + setLogFile "success.log" + log "Importing overrides finished" +} + +function do_restore() { + # Make collection in Typesense empty. + source "$SCRIPT_DIR/make_collection_empty.sh" + setLogFile "success.log" + log "Making collection empty finished" + + # Start backing up. + source "$SCRIPT_DIR/restore.sh" +} + +# Function to show the progress of the scraping process +function show_progress() { + for i in {1..5} + do + printf "." + sleep 0.2 + done +} + +# Main script starts here +display_intro +prompt_input +handle_choice + +# End of script + diff --git a/search-index-typesense/make_collection_empty.sh b/search-index-typesense/make_collection_empty.sh new file mode 100644 index 0000000..ba2252c --- /dev/null +++ b/search-index-typesense/make_collection_empty.sh @@ -0,0 +1,30 @@ +#!/bin/bash + +# Author: Kor Dwarshuis +# Created: 2023 +# Updated: - +# Description: This script empties a Typesense collection (typesense.org). + +# Logger generates a log file with a timestamp and from which file the message comes from. +source ./search-index-typesense/logger.sh + +source "$(pwd)/.env" +local_TYPESENSE_ADMIN_API_KEY="${TYPESENSE_ADMIN_API_KEY}" +local_TYPESENSE_HOST="${TYPESENSE_HOST}" +local_TYPESENSE_COLLECTION_NAME="${TYPESENSE_COLLECTION_NAME}" + +# Use the `local_TYPESENSE_ADMIN_API_KEY`, `local_TYPESENSE_HOST`, and `local_TYPESENSE_COLLECTION_NAME` variables anywhere in the script as needed + +setLogFile "success.log" +log "local_TYPESENSE_COLLECTION_NAME:" +log $local_TYPESENSE_COLLECTION_NAME + + +############## CONFIGURATION ############## +# URL of the endpoint to empty the collection +# explanation: the filter_by parameter is used to delete all documents that have a content field that is not empty +urlDelete="https://${local_TYPESENSE_HOST}.a1.typesense.net/collections/${local_TYPESENSE_COLLECTION_NAME}/documents?filter_by=content:!=''" + +############## MAKE COLLECTION EMPTY ############## +curl -H "X-TYPESENSE-API-KEY: ${local_TYPESENSE_ADMIN_API_KEY}" -X DELETE $urlDelete + diff --git a/search-index-typesense/modules/appendToFile.mjs b/search-index-typesense/modules/appendToFile.mjs new file mode 100644 index 0000000..1c92603 --- /dev/null +++ b/search-index-typesense/modules/appendToFile.mjs @@ -0,0 +1,29 @@ +/* + Author: Kor Dwarshuis + Created: 2023-08-11 + Updated: - + Description: Append the jsonl (not json) output to a file. +*/ + + +import fs from 'fs'; +import path from 'path'; +import logger from './logger.mjs'; + +export default function appendToFile(entries, outputPath) { + const resolvedPath = path.resolve(outputPath); + + // Writing a string to file (JSONL format) + const fileContent = entries; + + // Append the entries array to the file + logger.setLogFile('success.log'); + logger.log('Appending entries to file'); + + fs.appendFileSync(resolvedPath, fileContent); + + // For reporting purposes, though it might not be the actual number of total pages after append + logger.setLogFile('success.log'); + logger.log(`Appended ${entries.length} pages`); + logger.log(`Search index updated at ${outputPath}`); +} diff --git a/search-index-typesense/modules/createInput.mjs b/search-index-typesense/modules/createInput.mjs new file mode 100644 index 0000000..42997b7 --- /dev/null +++ b/search-index-typesense/modules/createInput.mjs @@ -0,0 +1,109 @@ +/* + Author: Kor Dwarshuis + Created: 2023-03-16 + Updated: - + Description: Create input for the scraper, from xml sitemaps or a list of URLs on a page to JavaScript objects. +*/ + +import puppeteer from 'puppeteer'; +import xml2js from 'xml2js'; +import fetch from 'node-fetch'; +import fs from 'fs'; +import path from 'path'; +import logger from './logger.mjs'; + +function removeUrlsFromSitemap(sitemap, excludeURLs) { + if (excludeURLs !== undefined) { + // Fetch the URLs to remove from the sitemap + const strUrlsToRemove = fs.readFileSync(excludeURLs, 'utf8'); + const objUrlsToRemove = JSON.parse(strUrlsToRemove); + + // Substring matching: if the URL contains any of the substrings in the objUrlsToRemove array, remove it from the sitemap + const updatedSitemap = sitemap.urlset.url.filter((url) => { + const loc = url.loc[0]; + return !objUrlsToRemove.some(substring => loc.includes(substring)); + }); + + sitemap.urlset.url = updatedSitemap; + } + // if condition is not met, do nothing and return the sitemap unchanged + return sitemap; +} + +export default async function createInput(input) { + // If there is a remote sitemap.xml file, fetch it and parse it + if (input.sourceType === 'remoteXMLsitemap') { + // Fetch and parse the sitemap.xml file + logger.setLogFile('success.log'); + logger.log('Fetching sitemap...'); + + const sitemapUrl = input.sourcePath; + const sitemapResponse = await fetch(sitemapUrl); + const sitemapXml = await sitemapResponse.text(); + const sitemap = await xml2js.parseStringPromise(sitemapXml, { explicitArray: true }); + + removeUrlsFromSitemap(sitemap, input.excludeURLs); + + if (sitemap.urlset && sitemap.urlset.url) { + logger.setLogFile('success.log'); + logger.log(`Found ${sitemap.urlset.url.length} URLs in sitemap`); + } else { + logger.setLogFile('error.log'); + logger.log(`${sitemapUrl}: No URLs found in sitemap`); + } + + return sitemap; + } + + // If there is a local sitemap.xml file, parse it + if (input.sourceType === 'localXMLsitemap') { + const sitemapXml = fs.readFileSync(path.resolve(input.sourcePath), 'utf-8'); + const sitemap = await xml2js.parseStringPromise(sitemapXml, { explicitArray: true }); + removeUrlsFromSitemap(sitemap, input.excludeURLs); + + if (sitemap.urlset && sitemap.urlset.url) { + logger.setLogFile('success.log'); + logger.log(`Found ${sitemap.urlset.url.length} URLs in sitemap`); + + } else { + logger.setLogFile('error.log'); + logger.log(`${input.sourcePath}: No URLs found in sitemap`); + } + + return sitemap; + } + + // If there is a list of URLs on a page, parse it + if (input.sourceType === 'querySelector') { + const browser = await puppeteer.launch(); + const page = await browser.newPage(); + + // Get all page URLs + await page.goto(input.sourcePath); + const urls = await page.$$eval(input.queryString, (links) => + links.map((link) => link.href) + ); + logger.setLogFile('success.log'); + logger.log('urls: ', urls); + + const sitemapXml = `${urls + .map((url) => `${url}`) + .join('\n ')}`; + + const sitemap = await xml2js.parseStringPromise(sitemapXml); + await browser.close(); + + removeUrlsFromSitemap(sitemap, input.excludeURLs); + + if (urls.length > 0) { + logger.setLogFile('success.log'); + logger.log(`Found ${sitemap.urlset.url.length} URLs in sitemap`); + } else { + logger.setLogFile('error.log'); + logger.log(`${input.sourcePath}: No URLs found in sitemap`); + } + + return sitemap; + } + +} diff --git a/search-index-typesense/modules/createOrEmptyFile.mjs b/search-index-typesense/modules/createOrEmptyFile.mjs new file mode 100644 index 0000000..340f92e --- /dev/null +++ b/search-index-typesense/modules/createOrEmptyFile.mjs @@ -0,0 +1,17 @@ +import fs from 'fs'; + +export function createOrEmptyFile(filePath) { + try { + // Check if file exists + if (fs.existsSync(filePath)) { + // If file exists, empty it + fs.writeFileSync(filePath, ''); + } else { + // If file does not exist, create it + fs.writeFileSync(filePath, ''); + } + console.log(`File ${filePath} created or emptied successfully.`); + } catch (err) { + console.error(err); + } +} diff --git a/search-index-typesense/modules/createOutput.mjs b/search-index-typesense/modules/createOutput.mjs new file mode 100644 index 0000000..ca64655 --- /dev/null +++ b/search-index-typesense/modules/createOutput.mjs @@ -0,0 +1,44 @@ +/* + Author: Kor Dwarshuis + Created: 2023-03-16 + Updated: - + Description: Create output, ready to be written to a file, and be imported into Typesense. +*/ + + +export default function createOutput(input) { + let strEntries = ''; + for (const element of input.mainContent) { + // if an entry is not passed, create a default entry + const entry = { + siteName: input.siteName || 'No site name specified', + source: input.source || 'No source specified', + author: input.author || 'No author specified', + creationDate: input.creationDate || 'No creation date specified', + url: input.pageUrl || 'No url specified', + content: element.content || '', + contentLength: element.contentLength || 0, + tag: element.tag || '', + imgUrl: element.imgUrl || '', + imgMeta: element.imgMeta || '', + imgMetaLength: element.imgMetaLength || 0, + imgWidth: element.imgWidth || 0, + imgHeight: element.imgHeight || 0, + timestamp: new Date().toISOString() || '', + 'hierarchy.lvl0': input.hierarchyLvl0 || '', + 'hierarchy.lvl1': input.hierarchyLvl1 || '', + 'hierarchy.lvl2': input.hierarchyLvl2 || '', + 'hierarchy.lvl3': input.hierarchyLvl3 || '', + knowledgeLevel: input.knowledgeLevel || 'No level specified', + type: input.type || 'No type specified', + pageTitle: input.pageTitle || 'No title specified', + firstHeadingBeforeElement: element.firstHeadingBeforeElement || '', + mediaType: input.mediaType || 'No file type specified', + category: input.category || 'No category type specified' + }; + + strEntries += JSON.stringify(entry) + '\n'; + + } + return strEntries; +} \ No newline at end of file diff --git a/search-index-typesense/modules/extractMainContent.mjs b/search-index-typesense/modules/extractMainContent.mjs new file mode 100644 index 0000000..95d7259 --- /dev/null +++ b/search-index-typesense/modules/extractMainContent.mjs @@ -0,0 +1,150 @@ +/* + Author: Kor Dwarshuis + Created: 2023-03-16 + Updated: - + Description: Extract the main content from a page, the paragraphs, list items, images and text around them. It loops through all elements that match the given selector and extracts the text content of the element and the first heading element preceding the element. It also extracts the text content of the image preceding the element and the text content of the elements preceding and following the image. It returns an array of objects with the following properties: + text + firstHeadingBeforeElement + imgUrl + imgMeta (text content of the elements preceding and following the image) + tag (the tag name of the element) +*/ + + +export default async function (page, domQueryForContent) { + const elements = await page.evaluate( + (domQueryForContent) => { + // Helper function to find the first heading element preceding the given element + function findPreviousHeadingElement(element) { + let previousElement = element.previousElementSibling; + while (previousElement) { + if (isHeadingElement(previousElement) && !isHeadingElement(element)) {// if the previous element is a heading element and the current element is not a heading element + return previousElement; + } + previousElement = previousElement.previousElementSibling; + } + return null; + } + + function getTextAroundImage(element, maxCharacters) { + // Check if the element is an image + if (element.tagName !== 'IMG') { + return ''; + } + + let text = ''; // Variable to store the extracted text + let remainingCharacters = maxCharacters; // Track the remaining characters to reach the maximum + + // Find the nearest previous sibling node that contains text + let prevSibling = element.previousElementSibling; + while (prevSibling && remainingCharacters > 0) { + const prevText = prevSibling.innerText.trim(); + const charsToAdd = Math.min(remainingCharacters, prevText.length); + text = prevText.slice(-charsToAdd) + ' ' + text; // Add the text to the beginning of the extracted text + remainingCharacters -= charsToAdd; + prevSibling = prevSibling.previousElementSibling; + } + + // Find the nearest next sibling node that contains text + let nextSibling = element.nextElementSibling; + while (nextSibling && remainingCharacters > 0) { + const nextText = nextSibling.innerText.trim(); + const charsToAdd = Math.min(remainingCharacters, nextText.length); + text += ' ' + nextText.slice(0, charsToAdd); // Add the text to the end of the extracted text + remainingCharacters -= charsToAdd; + nextSibling = nextSibling.nextElementSibling; + } + + // Traverse up the tree if the maximum characters limit is not reached + let parent = element.parentNode; + + while (parent && remainingCharacters > 0) { + let prevSib = parent.previousElementSibling; + let nextSib = parent.nextElementSibling; + while (remainingCharacters > 0) { + if (prevSib) { + const prevSibText = prevSib.innerText.trim(); + const prevCharsToAdd = Math.min(remainingCharacters, prevSibText.length); + text = prevSibText.slice(-prevCharsToAdd) + ' ' + text; // Add the text to the beginning of the extracted text + remainingCharacters -= prevCharsToAdd; + prevSib = prevSib.previousElementSibling; + } + + if (nextSib) { + const nextSibText = nextSib.innerText.trim(); + const nextCharsToAdd = Math.min(remainingCharacters, nextSibText.length); + text += ' ' + nextSibText.slice(-nextCharsToAdd); // Add the text to the end of the extracted text + remainingCharacters -= nextCharsToAdd; + nextSib = nextSib.nextElementSibling; + } + + if (!prevSib && !nextSib) { + break; + } + } + parent = parent.parentNode; + } + + return text.trim(); + } + + // Helper function to check if an element is a heading element (h1, h2, h3, etc.) + function isHeadingElement(element) { + const tagName = element.tagName.toLowerCase(); + return ( + tagName.startsWith("h") && tagName.length === 2 && !isNaN(tagName.charAt(1)) + ); + } + + function elementRouting(element) { + if (element.tagName.toLowerCase() === 'img') { + return { + imgUrl: element.src,//TODO: remove or use it + // imgMeta: element.alt + " " + element.title,//TODO: remove or use it + imgWidth: element.clientWidth, + imgHeight: element.clientHeight, + tag: element.tagName.toLowerCase() + }; + } else if (element.tagName.toLowerCase() === 'pre' || element.tagName.toLowerCase() === 'code') { + return { + textContent: element.innerText.trim(),// use innerText here + textContentLength: element.textContent.trim().length,// use textContentLength here + tag: element.tagName.toLowerCase() + }; + } else { + return { + textContent: element.textContent.trim(), + textContentLength: element.textContent.trim().length, + tag: element.tagName.toLowerCase() + } + } + } + + const elements = Array.from(document.querySelectorAll(domQueryForContent)); + return elements.map((el) => { + const headingElement = findPreviousHeadingElement(el); + + const textAroundImage = getTextAroundImage(el, 800); + const textAroundImageLength = getTextAroundImage(el, 800).length; + + return { + content: elementRouting(el).textContent, + contentLength: elementRouting(el).textContentLength, + tag: elementRouting(el).tag, + firstHeadingBeforeElement: headingElement + ? headingElement.textContent.trim() + : null, + imgUrl: elementRouting(el).imgUrl, + imgMeta: textAroundImage, + imgMetaLength: textAroundImageLength, + imgWidth: elementRouting(el).imgWidth, + imgHeight: elementRouting(el).imgHeight, + + }; + }); + }, + domQueryForContent + ); + + return elements; +} diff --git a/search-index-typesense/modules/general-pdf.mjs b/search-index-typesense/modules/general-pdf.mjs new file mode 100644 index 0000000..8525fa9 --- /dev/null +++ b/search-index-typesense/modules/general-pdf.mjs @@ -0,0 +1,203 @@ +/* + Author: Kor Dwarshuis + Created: 2023-08-12 + Updated: - + Description: Scrape PDF's using ImageMagick and Tesseract. +*/ + +import { promisify } from 'util'; +import fetch from 'node-fetch'; +import { promises as fs } from 'fs'; +import { convert as callbackConvert } from 'imagemagick'; +// import tesseract from 'node-tesseract-ocr'; +import Tesseract from 'tesseract.js'; +import path from 'path'; +import logger from './logger.mjs'; +import dotenv from 'dotenv'; + +// Config +const tempDirectoryPath = './' + process.env.SEARCH_INDEX_TEMP_DIR; + +async function resetDirectory(path) { + try { + // Check if directory exists + await fs.access(path); + + // If it exists, remove it + await fs.rmdir(path, { recursive: true }); + logger.setLogFile('success.log'); + logger.log('Directory removed'); + } catch (error) { + // If the error is not because the directory doesn't exist, throw it + if (error.code !== 'ENOENT') { + logger.setLogFile('error.log'); + logger.log('Error in resetDirectory: ' + err); + + throw error; + } + } + + // Create the directory + + await fs.mkdir(path); + logger.setLogFile('success.log'); + logger.log('Directory created'); +} +async function deleteDirectory(path) { + try { + // Check if directory exists + await fs.access(path); + + // If it exists, remove it + await fs.rmdir(path, { recursive: true }); + console.log('Directory removed'); + } catch (error) { + // If the error is not because the directory doesn't exist, throw it + if (error.code !== 'ENOENT') { + throw error; + } + logger.setLogFile('success.log'); + logger.log('Directory does not exist, no action needed'); + } +} + + +async function downloadPDF(url, destination) { + const response = await fetch(url); + const buffer = await response.buffer(); + await fs.writeFile(destination + "/downloaded.pdf", buffer); +} + +const convert = promisify(callbackConvert); + +async function convertPDFtoImage(directoryPath) { + try { + await convert([ + '-density', '300', + `${directoryPath}/downloaded.pdf`, + '-quality', '90', + `${directoryPath}/page.png` + ]); + logger.setLogFile('success.log'); + logger.log('PDF converted to images'); + + } catch (err) { + logger.setLogFile('error.log'); + logger.log('Error during conversion: ' + err); + } +} + + +// // Via Tesseract OCR (needs installation of Tesseract OCR) +// +// const config = { +// lang: "eng", +// oem: 1, +// psm: 3, +// } +// +// async function ocrAllImagesInDirectory(directory) { +// let mainContent = []; +// try { +// // 1. Read all files in the directory +// const files = await fs.readdir(directory); + +// // 2. Filter for PNG files +// const pngFiles = files.filter(file => path.extname(file).toLowerCase() === '.png'); + +// // 3. Loop through PNG files and process them +// const recognizedTexts = []; +// for (let file of pngFiles) { +// const imagePath = path.join(directory, file); +// const text = await tesseract.recognize(imagePath, config); +// mainContent.push({ +// content: text, +// contentLength: text.length, +// tag: "pdf" +// }); +// console.log(`Recognized text from ${file}:`, text); +// recognizedTexts.push(text); +// } + +// // 4. Return the recognized texts +// return recognizedTexts; + +// } catch (error) { +// console.error(error.message); +// return []; +// } +// } + +// Via Tesseract.js (installation via npm install tesseract.js) +async function ocrAllImagesInDirectory(directory) { + let mainContent = []; + + try { + // 1. Read all files in the directory + const files = await fs.readdir(directory); + + // 2. Filter for PNG files + const pngFiles = files.filter(file => path.extname(file).toLowerCase() === '.png'); + + // 3. Use Promise.all to wait for all the OCR operations to complete + const texts = await Promise.all(pngFiles.map(async file => { + const imagePath = path.join(directory, file); + + try { + // OCR the image using Tesseract.js + const { data: { text } } = await Tesseract.recognize( + imagePath, + 'eng', + { + logger: m => { + logger.setLogFile('success.log'); + logger.log(m); + } + } + ); + + return { + content: text, + contentLength: text.length, + tag: "pdf" + }; + } catch (err) { + console.error('Error:', err); + logger.setLogFile('error.log'); + logger.log('Error:' + err); + + return null; // return null for failed OCR operations + } + })); + + // 4. Filter out any null values and return the texts + mainContent = texts.filter(text => text !== null); + + } catch (error) { + console.error(error.message); + logger.setLogFile('error.log'); + logger.log(error.message); + } + + return mainContent; +} + + +export async function processPDF(url) { + try { + + await resetDirectory(tempDirectoryPath); + await downloadPDF(url, tempDirectoryPath); + await convertPDFtoImage(tempDirectoryPath); + const mainContent = await ocrAllImagesInDirectory(tempDirectoryPath); + let all = {}; + all.mainContent = mainContent; + deleteDirectory(tempDirectoryPath); + return all; + } catch (error) { + logger.setLogFile('error.log'); + logger.log('Error in processing: ' + err); + + throw error; + } +} diff --git a/search-index-typesense/modules/getImageMetaData.mjs b/search-index-typesense/modules/getImageMetaData.mjs new file mode 100644 index 0000000..9b4d1a8 --- /dev/null +++ b/search-index-typesense/modules/getImageMetaData.mjs @@ -0,0 +1,35 @@ +/* + Author: Kor Dwarshuis + Created: 2024-03-14 + Updated: - + Description: +*/ + +// imageInfo.js + +import fetch from 'node-fetch'; +import { createHash } from 'crypto'; + +// Function to get information about the image +export async function getImageMetaData(url) { + try { + // Fetch image + const response = await fetch(url); + const buffer = await response.buffer(); + + // Calculate hash + const hash = createHash('sha256').update(buffer).digest('hex'); + + // Get file size + const sizeInBytes = Buffer.byteLength(buffer); + const sizeInKB = sizeInBytes / 1024 || null; + + return { + sizeInKB, + hash + }; + } catch (error) { + console.error('Error:', error); + return null; + } +} diff --git a/search-index-typesense/modules/getTextContent.mjs b/search-index-typesense/modules/getTextContent.mjs new file mode 100644 index 0000000..2762cde --- /dev/null +++ b/search-index-typesense/modules/getTextContent.mjs @@ -0,0 +1,17 @@ +/* + Author: + Created: 2023-03-16 + Updated: - + Description: Get the text content of an element. +*/ + + +export default async function getTextContent(page, selector) { + const elements = await page.$$(selector); + + const output = await Promise.all(elements.map(async (t) => { + return await t.evaluate(x => x.textContent); + })) + return output[0]; + +} \ No newline at end of file diff --git a/search-index-typesense/modules/github-API.mjs b/search-index-typesense/modules/github-API.mjs new file mode 100644 index 0000000..b2a0fc0 --- /dev/null +++ b/search-index-typesense/modules/github-API.mjs @@ -0,0 +1,40 @@ +/* + Author: Kor Dwarshuis + Created: 2023-08-12 + Updated: - + Description: Get the content of a file from a GitHub repository via the GitHub API. + Example usage + + getFileContent('WebOfTrust', 'keripy', 'development', 'src/keri/app/connecting.py') + .then(content => { + console.log(content); + }) + .catch(error => { + console.error(`Failed to fetch file content: ${error.message}`); + }); +*/ + + +import fetch from 'node-fetch'; +import { config } from 'dotenv'; + +config(); + +const GITHUB_AUTH_TOKEN = process.env.GITHUB_AUTH_TOKEN; + +export async function getFileContent(owner, repo, branch, path) { + const url = `https://api.github.com/repos/${owner}/${repo}/contents/${path}?ref=${branch}`; + const headers = { + 'Authorization': `token ${GITHUB_AUTH_TOKEN}`, + 'Accept': 'application/vnd.github.v3.raw' + }; + + const response = await fetch(url, { headers }); + + if (response.status !== 200) { + throw new Error(`GitHub API responded with status: ${response.status}`); + } + + return await response.text(); +} + diff --git a/search-index-typesense/modules/github-pdf.mjs b/search-index-typesense/modules/github-pdf.mjs new file mode 100644 index 0000000..3f49604 --- /dev/null +++ b/search-index-typesense/modules/github-pdf.mjs @@ -0,0 +1,166 @@ +/* + Author: Kor Dwarshuis + Created: 2023-08 + Updated: - + Description: + This script performs PDF scraping from a given GitHub repository using Puppeteer and OCR (Optical Character Recognition) via Tesseract.js. + + Functions and Procedures: + + 1. `githubPDF(page, pageUrl)`: + - Main function that initiates the scraping process. + - Takes a puppeteer page object and the URL of the GitHub page where the PDF is located. + + 2. `extractRepoNameFromGithubURL(url)`: + - Extracts and returns the repository name from a GitHub URL. + + 3. `areMorePagesAvailable(page)`: + - Checks whether more PDF pages are available for scraping on the GitHub page. + + 4. `clickMorePagesButton(page)`: + - Clicks the "More pages" button on the GitHub page to load additional PDF pages. + + Flow of Execution: + + - The script navigates to the GitHub page containing the PDF. + - It waits for an iframe to load that contains the PDF. + - Clicks the "More Pages" button until all PDF pages are visible. + - Takes a screenshot of each PDF page (rendered in a canvas element). + - Performs OCR on each screenshot using Tesseract.js to convert images to text. + - Returns the OCR text and the repository name. + + Logging: + + - Any errors encountered are logged into 'error.log'. + - OCR progress and other information are logged into 'success.log'. +*/ + + +import Tesseract from 'tesseract.js'; +import { createWorker } from 'tesseract.js'; +import puppeteer from 'puppeteer'; +import logger from './logger.mjs'; + +export async function githubPDF(page, pageUrl) { + function extractRepoNameFromGithubURL(url) { + try { + const parsedUrl = new URL(url); + + // Validate that the URL is from GitHub + if (parsedUrl.hostname !== 'github.com') { + throw new Error('URL is not from github.com'); + } + + // Split the pathname into segments and return the second one + const segments = parsedUrl.pathname.split('/'); + return segments[2]; // This will be the repo name + + } catch (err) { + logger.setLogFile('error.log'); + logger.log(err.message); + + return null; // Invalid URL or not a GitHub URL + } + } + + + + // Wait for iframe to be loaded + await page.waitForSelector('iframe'); + + // Extract the 'src' attribute from the iframe + const iframeSrc = await page.$eval('iframe', frame => frame.src); + let mainContent = []; + + // Navigate to the iframe's source + await page.goto(iframeSrc, { + waitUntil: 'networkidle2' + }); + + // To get the whole pdf, we need to click the "More pages" button until all pages are loaded + // In Github if the loading class is added to the More Pages button means that there are no more pages to load + async function areMorePagesAvailable(page) { + const selector = '#js-click-for-more'; + const className = 'loading'; + return !(await page.$eval(selector, (el, className) => el.classList.contains(className), className)); + } + + + + + + + + // Repeatedly click the "More pages" button until all pages are loaded + let morePagesToLoad = await areMorePagesAvailable(page); + + // Function to check for the "More pages" button and click it + const clickMorePagesButton = async (page) => { + if (morePagesToLoad) { + // Wait for the "More pages" button to be visible + try { + await page.waitForSelector('#js-click-for-more', { visible: true, timeout: 60000 }); + } catch (err) { + logger.setLogFile('error.log'); + logger.log('Could not find #js-click-for-more: ' + err.message); + // Exit or continue based on your logic + } + + const button = await page.$('#js-click-for-more'); + if (button) { + await button.click(); + console.log("More pages button clicked"); + await page.waitForTimeout(1000); + morePagesToLoad = await areMorePagesAvailable(page); + } else { + console.log("'More pages' button not found"); + } + } + }; + + while (morePagesToLoad) { + await clickMorePagesButton(page); + } + + // Now that the whole pdf is loaded (into several canvasses), we can scrape the PDF + // Fetch all the canvas elements on the page + const canvases = await page.$$('canvas'); + + + for (const canvas of canvases) { + const canvasImage = await canvas.screenshot(); + + try { + // OCR the captured canvas image using Tesseract.js + const { data: { text } } = await Tesseract.recognize( + canvasImage, + 'eng', + { + logger: m => { + logger.setLogFile('success.log'); + logger.log(m); + } + } + ); + + mainContent.push({ + content: text, + contentLength: text.length, + tag: "pdf" + }); + + } catch (err) { + logger.setLogFile('error.log'); + logger.log('Error:' + err); + } + } + + + // // Tesseract via Worker part 3 - close the worker + // await worker.terminate(); + + let all = {}; + all.mainContent = mainContent; + all.pageTitle = extractRepoNameFromGithubURL(pageUrl); + return all; +} \ No newline at end of file diff --git a/search-index-typesense/modules/logger.mjs b/search-index-typesense/modules/logger.mjs new file mode 100644 index 0000000..88771d4 --- /dev/null +++ b/search-index-typesense/modules/logger.mjs @@ -0,0 +1,45 @@ +/* + Author: Kor Dwarshuis + Created: 2023-08-29 + Updated: Date + Description: This script is a replacement for console.log. It gives more info, like a time stamp and from where the log entry is created. This script uses the tracer module to log to the console and to a file. The log file is set to 'logs.txt' by default. To change the log file, use the setLogFile function. See the example below, in a try catch block, but you can use it everywhere you like. + + import logger from './logger.mjs'; + + try { + // Some code that might throw an error + logger.setLogFile('success.log'); + logger.log('This code ran successfully!'); + } catch (error) { + logger.setLogFile('error.log'); + logger.log(`An error occurred: ${error.message}`); + } +*/ + +import fs from 'fs'; +import tracer from 'tracer'; + +const logsDir = 'search-index-typesense/logs'; +let currentLogFile = 'success.log'; // default log file + +const logger = tracer.console({ + // format: "{{timestamp}} [{{file}}:{{line}}] <{{title}}> {{message}}", + format: "{{timestamp}} [{{file}}:{{line}}] {{message}}", + dateformat: "HH:MM:ss.L", + transport: function (data) { + console.log(data.output); // Output to console + + // Write logs to the currently set log file + fs.appendFile(logsDir + "/" + currentLogFile, data.output + '\n', err => { + if (err) { + console.error('Error writing to log file', err); + } + }); + } +}); + +logger.setLogFile = function (filename) { + currentLogFile = filename; +} + +export default logger; diff --git a/search-index-typesense/modules/scrape.mjs b/search-index-typesense/modules/scrape.mjs new file mode 100644 index 0000000..a926fbd --- /dev/null +++ b/search-index-typesense/modules/scrape.mjs @@ -0,0 +1,172 @@ +/* + Author: Kor Dwarshuis + Created: 2023-03-16 + Updated: - + Description: Scrape websites using puppeteer. +*/ + +import puppeteer from 'puppeteer'; +import createOutput from './createOutput.mjs'; +import appendToFile from './appendToFile.mjs'; +import fs from 'fs'; +import logger from './logger.mjs'; +import { githubPDF } from './github-pdf.mjs'; +import { processPDF as generalPDF } from './general-pdf.mjs'; +import { getFileContent as githubContent } from './github-API.mjs'; + +export default async function scrape(config, customScrape) { + const browser = await puppeteer.launch({ headless: "new" });// for production + // const browser = await puppeteer.launch({ headless: false });// for testing + const page = await browser.newPage(); + // Set a custom user agent header + await page.setUserAgent('KERISSE-Web-of-Trust-Scraper'); + let scraped = {}; + + function getFileExtension(url) { + try { + const parsedUrl = new URL(url); + + // Split the pathname into segments and get the last segment + const segments = parsedUrl.pathname.split('/'); + const lastSegment = segments[segments.length - 1]; + + // Use a regular expression to extract the file extension + const match = /\.([a-z0-9]+)$/i.exec(lastSegment); + if (match) { + return match[1]; // Return the file extension without the dot + } else { + return "Web page"; // No file extension found, so we'll assume it's a web page + } + + } catch (err) { + logger.setLogFile('error.log'); + logger.log(err.message); + + return null; // Invalid URL + } + } + + function extractGithubParts(url) { + // Check if the URL is a valid GitHub URL + const githubRegex = /^https:\/\/github\.com\/([^\/]+)\/([^\/]+)\/blob\/([^\/]+)\/(.+)$/; + const match = url.match(githubRegex); + + if (!match) { + logger.setLogFile('error.log'); + logger.log('Invalid GitHub URL'); + + throw new Error('Invalid GitHub URL'); + } + + return { + owner: match[1], + repo: match[2], + branch: match[3], + path: match[4] + }; + } + + if (config && config.sitemap && config.sitemap.urlset && Array.isArray(config.sitemap.urlset.url)) { + // Iterate over each URL in the sitemap and create an array of entries for each URL + // console.log('Indexing pages...'); + for (const url of config.sitemap.urlset.url) {// for production + // for (const url of config.sitemap.urlset.url.slice(150, 163)) {// for testing + const pageUrl = url.loc[0]; + const pageExtension = getFileExtension(pageUrl); + const parsedUrl = new URL(pageUrl); + logger.setLogFile('success.log'); + logger.log(`Indexing ${pageUrl}`); + + try { + // Navigate to the page URL and process the page content using the specified function + + // PDF: + if (pageUrl.toLowerCase().endsWith('.pdf')) { + // PDF + github.com + if (parsedUrl.hostname.includes('github.com')) { + await page.goto(pageUrl); + scraped = await githubPDF(page, pageUrl); + } + // PDF + not github.com + else { + scraped = await generalPDF(pageUrl); + } + + } + + // Not PDF: + else { + // Not PDF + github.com (not wiki) + if (parsedUrl.hostname.includes('github.com') && !parsedUrl.pathname.includes('/wiki/')) { + let mainContent = []; + const parts = extractGithubParts(url.loc[0]); + + const content = await githubContent(parts.owner, parts.repo, parts.branch, parts.path) + .then(content => { + return content; + }) + .catch(error => { + console.error(`Failed to fetch file content: ${error.message}`); + }); + + // return content; + mainContent.push({ + content: content, + contentLength: content.length, + tag: 'textarea', + }); + scraped.mainContent = mainContent; + scraped.pageTitle = parts.path; + } + + // Not PDF + not github.com + else { + await page.goto(pageUrl); + scraped = await customScrape(page, config.domQueryForContent, pageUrl);//TODO: find out if pageUrl is needed + } + } + + /* + -if an entry is not passed, createOutput({…}) creates a default entry. + -everything that is assigned via scraped, like scraped,knowledgeLevel, can be added via customScrape. But mediaType for example cannot be assigned via the custom Scraper but get its data via a local var. + */ + + let strOutput = createOutput({ + siteName: config.siteName, + source: config.source, + author: config.author, + category: config.category, + pageUrl: pageUrl, + mainContent: scraped.mainContent, + hierarchyLvl0: scraped.hierarchyLevel0, + hierarchyLvl1: scraped.hierarchyLevel1, + hierarchyLvl2: scraped.hierarchyLevel2, + hierarchyLvl3: scraped.hierarchyLevel3, + knowledgeLevel: scraped.knowledgeLevel, + type: scraped.type, + creationDate: scraped.creationDate, + pageTitle: scraped.pageTitle, + firstHeadingBeforeElements: scraped.firstHeadingBeforeElements, + mediaType: pageExtension + }); + + + appendToFile(strOutput, config.destinationFile); + // Log the page URL to a log file and to a markdown file + fs.appendFileSync('search-index-typesense/logs/scraped.log', `Scraped: ${pageUrl}\n`); + fs.appendFileSync(process.env.INDEX_OVERVIEW_FILE, `${pageUrl}\n\n`); + + } catch (err) { + logger.setLogFile('error.log'); + logger.log(`Error processing page ${pageUrl}: ${err}`); + } + } + } else { + logger.setLogFile('error.log'); + logger.log('config.sitemap.urlset.url is not defined or not an array'); + } + + // await new Promise(resolve => setTimeout(resolve, 1000000000)); // For testing: Delay the script termination + + await browser.close(); +} diff --git a/search-index-typesense/modules/writeToFile.mjs b/search-index-typesense/modules/writeToFile.mjs new file mode 100644 index 0000000..f36384c --- /dev/null +++ b/search-index-typesense/modules/writeToFile.mjs @@ -0,0 +1,21 @@ +/* + Author: Kor Dwarshuis + Created: 2023-03-16 + Updated: 2023-08-11 + Description: Write the json output to a file. +*/ + +import fs from 'fs'; +import path from 'path'; + +export default function writeToFile(entries, outputPath) { + const resolvedOutputPath = path.resolve(outputPath); + + // Write the entries array to the file + console.log(`Writing search index to file...`); + const fileContent = JSON.stringify(entries); + fs.writeFileSync(resolvedOutputPath, fileContent); + + console.log(`Indexed ${entries.length} pages`); + console.log(`Search index written to ${resolvedOutputPath}`); +} diff --git a/search-index-typesense/overrides.sh b/search-index-typesense/overrides.sh new file mode 100644 index 0000000..e7c3a14 --- /dev/null +++ b/search-index-typesense/overrides.sh @@ -0,0 +1,168 @@ +#!/bin/bash + +# Author: Kor Dwarshuis +# Created: 2023 +# Updated: - +# Description: This Bash script automates the management of "overrides" for a specific collection in a Typesense server. +# Overrides in Typesense allow manual curation of search ranking results. This script assists in updating and managing such overrides. + +# STEP 1: Convert URLs to IDs +# Purpose: This step converts URLs present in the input JSON to their corresponding document IDs in the Typesense collection. +# Input: A JSON file containing URLs +# Output: A JSON file containing corresponding document IDs + +# Sample Input: +# [ +# { +# "name": "foo", +# "query": "bar", +# "url": "https://example.com/some/path/", +# "position": 1, +# "match": "exact" +# }, +# ... +# ] + +# Sample Output: +# [ +# { +# "name": "foo", +# "query": "bar", +# "id": "7347", +# "position": 1, +# "match": "exact" +# }, +# ... +# ] + +# STEP 2: Apply Overrides +# Purpose: This step first clears all existing overrides from the Typesense server and then uploads new ones from the prepared JSON. +# The overrides JSON includes fields such as: +# - name: Name of the override. +# - query: Query to which the override applies. +# - id: Document ID to be promoted. +# - position: Desired position in search results. +# - match: Match type for the query (either "exact" or "contains"). + +# Note: This script deletes all existing overrides at its start. This operation is irreversible. Always ensure the intent before executing. + +# External Dependencies: +# - jq: Lightweight and flexible command-line JSON processor. + +# Logger generates a log file with a timestamp and from which file the message comes from. +source ./search-index-typesense/logger.sh + +### CONFIGURATION +source "$(pwd)/.env" +local_TYPESENSE_ADMIN_API_KEY="${TYPESENSE_ADMIN_API_KEY}" +local_TYPESENSE_HOST="${TYPESENSE_HOST}" +local_TYPESENSE_COLLECTION_NAME="${TYPESENSE_COLLECTION_NAME}" +input_file_path="search-index-typesense/config/configOverrides.json" +output_file_path="search-index-typesense/overrides/overridesID.json" + +### STEP 1: Convert URLs to IDs +temp_file=$(mktemp) +jq -c '.[]' "$input_file_path" | while read -r object; do + # Extract the URL from the object + url=$(echo "$object" | jq -r '.url') + + # Perform the request and store the response in a variable, Contains the url + # response=$(curl -s -H "X-TYPESENSE-API-KEY: ${local_TYPESENSE_ADMIN_API_KEY}" \ + # "https://${local_TYPESENSE_HOST}.a1.typesense.net/collections/${local_TYPESENSE_COLLECTION_NAME}/documents/search?q=${url}&query_by=url") + + + # Perform the request and store the response in a variable, Exact match on the url + response=$(curl -s -H "X-TYPESENSE-API-KEY: ${local_TYPESENSE_ADMIN_API_KEY}" \ + "https://${local_TYPESENSE_HOST}.a1.typesense.net/collections/${local_TYPESENSE_COLLECTION_NAME}/documents/search?q=${url}&query_by=url&filter_by=url:=:${url}") + + + + + # SANITIZE RESPONSE + # This is trial and error and only working for the current response. + + # Replace backslash-escaped double quotes with single quotes + sanitized_string=$(echo "$response" | sed 's/\\"/'\''/g') + + # Sanitize the JSON response by removing all backslashes. + # Reason is this output: "content":"1 ) } \ .@ccoun;mg ;@eclger2) 4p ’7:3) ? /4) 420Rotated public keys", + sanitized_response=$(echo "$sanitized_string" | sed 's/\\//g') + + # Sanitize the JSON response by removing control characters + sanitized_response=$(echo "$sanitized_response" | tr -d '\000-\031') + + # Check if the sanitized response contains any error messages + if echo "$sanitized_response" | jq -e '.error' > /dev/null; then + error_message=$(echo "$sanitized_response" | jq -r '.error') + setLogFile "error.log" + log "Error in response: $error_message" + + exit 1 + fi + + # Extract the "id" entry from the sanitized response using jq + id=$(echo "$sanitized_response" | jq -r '.hits[0].document.id') + + # Check if the ID is null and handle this case accordingly + if [ "$id" = "null" ]; then + setLogFile "error.log" + log "No ID found for the URL $url" + + else + # Remove the "url" entry and add the "id" entry in the object + new_object=$(echo "$object" | jq --arg id "$id" 'del(.url) | .id = $id') + + # Write the new object to the temporary file + echo "$new_object" >> "$temp_file" + fi +done + +# Convert the temporary file to a JSON array and write it to the output file +jq -s '.' "$temp_file" > "$output_file_path" + +# Remove the temporary file +rm "$temp_file" + +### STEP 2: Clear Existing Overrides +OVERRIDES=$(curl -H "X-TYPESENSE-API-KEY: ${local_TYPESENSE_ADMIN_API_KEY}" "https://${local_TYPESENSE_HOST}.a1.typesense.net/collections/${local_TYPESENSE_COLLECTION_NAME}/overrides") +OVERRIDE_NAMES=$(echo $OVERRIDES | jq -r '.overrides[] | .id') +for OVERRIDE_NAME in $OVERRIDE_NAMES; do + curl "https://${local_TYPESENSE_HOST}.a1.typesense.net/collections/${local_TYPESENSE_COLLECTION_NAME}/overrides/$OVERRIDE_NAME" -X DELETE \ + -H "X-TYPESENSE-API-KEY: ${local_TYPESENSE_ADMIN_API_KEY}" +done + +### Import New Overrides +process_json_data() { + local JSON_DATA=$1 + local LENGTH=$(echo "$JSON_DATA" | jq '. | length') + + for ((i=0; i<$LENGTH; i++)); do + # Extract the name, query, id, position, and match from each object + local NAME=$(echo "$JSON_DATA" | jq -r --argjson index $i '.[$index] | .name') + local QUERY=$(echo "$JSON_DATA" | jq -r --argjson index $i '.[$index] | .query') + local ID=$(echo "$JSON_DATA" | jq -r --argjson index $i '.[$index] | .id') + local POSITION=$(echo "$JSON_DATA" | jq -r --argjson index $i '.[$index] | .position') + local MATCH=$(echo "$JSON_DATA" | jq -r --argjson index $i '.[$index] | .match') + + # Insert variables into the curl command + curl "https://${local_TYPESENSE_HOST}.a1.typesense.net/collections/${local_TYPESENSE_COLLECTION_NAME}/overrides/$NAME" -X PUT \ + -H "Content-Type: application/json" \ + -H "X-TYPESENSE-API-KEY: ${local_TYPESENSE_ADMIN_API_KEY}" -d '{ + "rule": { + "query": "'"$QUERY"'", + "match": "'"$MATCH"'" + }, + "includes": [ + { + "id": "'"$ID"'", + "position": '"$POSITION"' + } + ] + }' + done +} +JSON_DATA1=$(<"search-index-typesense/overrides/overridesID.json") +process_json_data "$JSON_DATA1" + +# # Cleanup if desired +# rm search-index-typesense/overrides/overridesID.json diff --git a/search-index-typesense/overrides/sortAdjustment.js b/search-index-typesense/overrides/sortAdjustment.js new file mode 100644 index 0000000..6fa2b47 --- /dev/null +++ b/search-index-typesense/overrides/sortAdjustment.js @@ -0,0 +1,8 @@ +export const queriesWithSortAdjustment = [ + // example: + { + queryString: "keri", + sortAdjustment: 1, + urlSubstring: "https://github.com/WebOfTrust/keripy/" + } +]; \ No newline at end of file diff --git a/search-index-typesense/prepareScraperGithub.mjs b/search-index-typesense/prepareScraperGithub.mjs new file mode 100644 index 0000000..b9b1974 --- /dev/null +++ b/search-index-typesense/prepareScraperGithub.mjs @@ -0,0 +1,46 @@ +import createInput from './modules/createInput.mjs'; +import scrape from './modules/scrape.mjs'; +import { config as dotenvConfig } from 'dotenv'; +import { promises as fs } from 'fs'; +import path from 'path'; + +dotenvConfig(); + +const sitemapDir = path.join(process.env.SEARCH_INDEX_DIR, '/sitemaps/github'); + + +// Function to create configuration +const createConfig = async (filename) => { + const parts = filename.split('.'); + const repositoryOwner = parts[2]; + const repositoryName = parts[3]; + // const branchName = parts[4]; + const category = parts[4]; + + return { + sitemap: await createInput({ + sourceType: 'localXMLsitemap', + sourcePath: `${sitemapDir}/${filename}`, + }), + siteName: `${repositoryOwner} / ${repositoryName}`, + source: `${repositoryOwner} / ${repositoryName}`, + category: category, + author: `${repositoryOwner}`, + destinationFile: `${process.env.SEARCH_INDEX_DIR}/search-index-entries/${repositoryOwner}-${repositoryName}.jsonl` + // branch: branchName + }; +} + +export default async function () { + try { + const files = await fs.readdir(sitemapDir); + for (const filename of files) { + if (filename.endsWith('.xml')) { // Filter XML files + const config = await createConfig(filename); + await scrape(config); + } + } + } catch (err) { + console.error(`Error reading sitemap directory: ${err.message}`); + } +}; diff --git a/search-index-typesense/prepareScraperSingleUrlsFromWotTermsGoogleSheet.mjs b/search-index-typesense/prepareScraperSingleUrlsFromWotTermsGoogleSheet.mjs new file mode 100644 index 0000000..b57f9d7 --- /dev/null +++ b/search-index-typesense/prepareScraperSingleUrlsFromWotTermsGoogleSheet.mjs @@ -0,0 +1,124 @@ +/** + * @file This module exports a function that scrapes data from a list of websites and saves it to a JSONL file. + * @module scraper-generic + */ + +import fs from 'fs'; +import path from 'path'; +import scrape from './modules/scrape.mjs'; +import extractMainContent from './modules/extractMainContent.mjs'; +import { config as configDotEnv } from 'dotenv'; +configDotEnv(); + +/** + * The directory where the JSON file containing the list of websites to scrape is located. + * @type {string} + */ +const inputDirJSON = process.env.SEARCH_INDEX_DIR + "/singleUrlsFromWotTermsGoogleSheet"; + +/** + * The name of the JSON file containing the list of websites to scrape. + * @type {string} + */ +const inputFileNameJSON = "singleUrlsFromWotTermsGoogleSheet.json"; + +/** + * The full path of the JSON file containing the list of websites to scrape. + * @type {string} + */ +const filePathJSON = path.join(inputDirJSON, inputFileNameJSON); + +/** + * The contents of the JSON file containing the list of websites to scrape. + * @type {string} + */ +const data = fs.readFileSync(filePathJSON, 'utf-8'); + +/** + * The parsed JSON object containing the list of websites to scrape. + * @type {Object} + */ +const dataObj = JSON.parse(data); + +/** + * The column names of the list of websites to scrape. + * @type {Array} + */ +const entriesIndex = dataObj.values[0]; + +/** + * The entries of the list of websites to scrape. + * @type {Array>} + */ +const entries = dataObj.values.slice(1); // removes the first item in the array + +/** + * Returns the position of a value in the entriesIndex array. + * @param {string} value - The value to search for in the entriesIndex array. + * @returns {number} - The position of the value in the entriesIndex array, or -1 if not found. + */ +function positionInArray(value) { + for (let i = 0; i < entriesIndex.length; i++) { + if (entriesIndex[i] === value) return i; + } + return -1; +} + +/** + * Scrapes data from all websites in the list and saves it to a JSONL file. + * @async + */ +async function scrapeAll() { + for (let i = 1; i < entries.length; i++) { + const urlPosition = positionInArray('url'); + + const sitemap = { + "urlset": { + "url": [{ "loc": [entries[i][urlPosition]] }] + } + } + + const config = { + sitemap: sitemap, + siteName: entries[i][positionInArray('siteName')], + source: entries[i][positionInArray('source')], + category: entries[i][positionInArray('category')], + author: entries[i][positionInArray('author')], + destinationFile: process.env.SEARCH_INDEX_DIR + '/search-index-entries/site-' + i + '-' + entries[i][positionInArray('pageTitle')].replace(/\s+/g, '-') + '.jsonl', + domQueryForContent: entries[i][positionInArray('querySelector')] + } + + // Pass additional parameters to customScrape + const type = entries[i][positionInArray('type')]; + const pageTitle = entries[i][positionInArray('pageTitle')]; + + scrape(config, (page, domQueryForContent, pageUrl) => { + return customScrape(page, domQueryForContent, pageUrl, type, pageTitle); + }); + } +} + +/** + * Custom scraping function that extracts the main content of a webpage. + * @async + * @param {Object} page - The webpage to scrape. + * @param {string} domQueryForContent - The DOM query selector for the main content of the webpage. + * @param {string} pageUrl - The URL of the webpage. + * @returns {Object} - An object containing the main content, type, and page title of the webpage. + */ +async function customScrape(page, domQueryForContent, pageUrl, type, pageTitle) { + const mainContent = await extractMainContent(page, domQueryForContent); + let all = {}; + all.mainContent = mainContent; + all.type = type; + all.pageTitle = pageTitle; + return all; +} + +/** + * Exports a function that scrapes data from a list of websites and saves it to a JSONL file. + * @async + */ +export default async function () { + scrapeAll(); +}; \ No newline at end of file diff --git a/search-index-typesense/prepare_file_system.sh b/search-index-typesense/prepare_file_system.sh new file mode 100644 index 0000000..c40b926 --- /dev/null +++ b/search-index-typesense/prepare_file_system.sh @@ -0,0 +1,50 @@ +#!/bin/bash + + +# Author: Kor Dwarshuis +# Created: 2023 +# Updated: 2023-08-13 +# Description: This script prepares the file system for the search-index-typesense project. It creates the necessary directories and files. It also removes the old files and directories. This script is meant to be run before the other scripts. + + + +# Import variables from .env file +source .env + +# Set the directory path +dir_path="search-index-typesense" + + +### LOG FILES remove dir and recreate ### +# Check if a directory named "log" exists inside the path +if [ -d "${dir_path}/logs" ]; then + # If the directory exists, delete it and everything inside + rm -rf "${dir_path}/logs" +fi +# Create a new directory named "logs" +mkdir "${dir_path}/logs" + +# Create files with the specified names +touch "${dir_path}/logs/error.log" "${dir_path}/logs/import-into-search-index.log" "${dir_path}/logs/scraped.log" "${dir_path}/logs/success.log" + + +### SEARCH-INDEX-ENTRIES remove dir and recreate ### +if [ -d "${dir_path}/search-index-entries" ]; then + rm -rf "${dir_path}/search-index-entries" +fi +mkdir "${dir_path}/search-index-entries" + + +### SITEMAPS remove dir and recreate ### +if [ -d "${dir_path}/sitemaps" ]; then + rm -rf "${dir_path}/sitemaps" +fi +mkdir "${dir_path}/sitemaps" + + + +### INDEXED-IN-KERISSE.MD ### +# Remove and recreate the index file where all the indexed websites are listed +rm -rf "$INDEX_OVERVIEW_FILE" +touch "$INDEX_OVERVIEW_FILE" + diff --git a/search-index-typesense/removeURLsFromSitemap.mjs b/search-index-typesense/removeURLsFromSitemap.mjs new file mode 100644 index 0000000..a579a90 --- /dev/null +++ b/search-index-typesense/removeURLsFromSitemap.mjs @@ -0,0 +1,215 @@ +/** + * Author: Kor Dwarshuis + * Created: 2023 + * Updated: - + * + * Description: This JavaScript code is designed to remove unwanted URLs + * from sitemap.xml files. It uses the Node.js fs module to interact with + * the file system, the path module to handle file paths, xml2js to parse + * XML data, and a custom logger module for logging. + * + * The script defines several arrays to specify the types of URLs to remove: + * + * - unwantedExtensions: URLs with these file extensions will be removed. + * - unwantedHiddenFiles: URLs of these hidden files will be removed. + * - unwantedFileNames: URLs of these specific files will be removed. + * - unwantedPatterns: URLs matching these regex patterns will be removed. + * + * The removeFilesFromSitemap function is the main function of the script. + * It takes a directory and the arrays of unwanted URLs as arguments. + * It first finds all XML files in the given directory and its subdirectories. + * For each XML file, it reads the file, parses the XML data, and filters out + * unwanted URLs based on the given criteria. It then writes the filtered + * data back to the XML file. + * + * The script logs every URL it removes to a success.log file using the + * logger module. If the script encounters any errors, it logs them to an + * error.log file. + * + * Finally, the script calls removeFilesFromSitemap with the sitemapDir + * directory and the arrays of unwanted URLs. It logs a success message + * if the function completes successfully, or an error message if it + * encounters an error. + */ + + +import fs from 'fs'; +import path from 'path'; +import xml2js from 'xml2js'; +import logger from './modules/logger.mjs'; + +// Sitemap directory +const sitemapDir = 'search-index-typesense/sitemaps'; + +// Array of extensions to filter out +const unwantedExtensions = [ + '.jpg', + '.jpeg', + '.png', + '.gif', + '.bmp', + '.webm', + '.mp4', + '.mov', + '.avi', + '.zip', + '.gitignore', + '.gitattributes', + '.gitmodules', + '.gitkeep', + '.DS_Store', + '.git', + '.editorconfig', + '.eslintrc', + '.eslintignore', + '.flowconfig', + '.gitpod.yml', + '.prettierrc', + '.prettierignore', + '.stylelintrc', + '.stylelintignore', + '.travis.yml', + '.vscode', + '.vscodeignore', + '.history', + '.idea', + '.docusaurus', + '.icns', + '.otf', + '.ttf' +]; + +// Add an array for unwanted hidden files +const unwantedHiddenFiles = [ + '.gitignore', + '.gitattributes', + '.gitmodules', + '.gitkeep', + '.DS_Store', + '.coveragerc' + // ... [Any other hidden files you want to exclude] +]; + + +// Array of specific file names to filter out, examples: 'README.md', 'README' +// README.md will remove all files named README.md but not README +//TODO: test if README will remove all files named README and README.md +const unwantedFileNames = [ + 'LICENSE', + 'README.md', + 'node_modules', + 'package.json', + 'package-lock.json', + '__pycache__', + 'pycache', + '__init__.py', + 'init.py', + 'README.md', + 'setup.py', + 'requirements.txt', + 'publish.sh', + 'make.bat', + 'Makefile', + 'swagger.yaml', + 'swagger.json', + 'contents.xcworkspacedata', + 'build', + 'project.pbxproj', + 'yarn.lock', + 'target', + 'Cargo.toml', + 'conf.py', + 'index.rst' +]; + +// Regex pattern to filter out hidden files and certain filenames +// const unwantedPatterns = [/^\./, /\.env\..*/]; +const unwantedPatterns = [/\.env\..*/]; + +async function removeFilesFromSitemap(dir, extensions, fileNames, hiddenFiles, patterns) { + function findXmlFiles(dir, xmlFiles = []) { + const files = fs.readdirSync(dir); + + for (const file of files) { + const fullPath = path.join(dir, file); + if (fs.statSync(fullPath).isDirectory()) { + findXmlFiles(fullPath, xmlFiles); + } else if (file.endsWith('.xml')) { + xmlFiles.push(fullPath); + } + } + return xmlFiles; + } + + const xmlFiles = findXmlFiles(dir); + + for (const file of xmlFiles) { + const xmlData = fs.readFileSync(file); + const parser = new xml2js.Parser(); + const data = await parser.parseStringPromise(xmlData); + const urls = data.urlset.url; + + if (urls && urls.length > 0) { + // Filter out URLs with certain extensions or filenames + const filteredUrls = urls.filter(url => { + let urlString = url.loc[0]; + const parsedUrl = new URL(urlString); + const parsedPath = path.parse(parsedUrl.pathname); + + // Filter out unwanted extensions + if (extensions.includes(parsedPath.ext)) { + logger.setLogFile('success.log'); + logger.log('Url removed from sitemap: ', parsedUrl.href); + + return false; + } + + // Filter out unwanted hidden files + if (hiddenFiles.includes(parsedPath.base)) { + logger.setLogFile('success.log'); + logger.log('Hidden file URL removed from sitemap: ', parsedUrl.href); + + return false; + } + + // Filter out unwanted filenames + if (fileNames.includes(parsedPath.base)) { + logger.setLogFile('success.log'); + logger.log('Url removed from sitemap: ', parsedUrl.href); + + return false; + } + + // Filter out unwanted patterns + for (let pattern of patterns) { + if (pattern.test(parsedPath.base)) { + logger.setLogFile('success.log'); + logger.log('Url removed from sitemap: ', parsedUrl.href); + + return false; + } + } + + // If URL passes all the filters, include it in the result + return true; + }); + data.urlset.url = filteredUrls; + + const builder = new xml2js.Builder(); + const newXml = builder.buildObject(data); + + fs.writeFileSync(file, newXml); + } + } +} + +removeFilesFromSitemap(sitemapDir, unwantedExtensions, unwantedFileNames, unwantedHiddenFiles, unwantedPatterns) + .then(() => { + logger.setLogFile('success.log'); + logger.log('Removed urls from sitemaps successfully'); + + }) + .catch(err => { + logger.setLogFile('error.log'); + logger.log('Error while removing urls from sitemaps:' + err); + }); diff --git a/search-index-typesense/renameFilesToLowerCase.mjs b/search-index-typesense/renameFilesToLowerCase.mjs new file mode 100644 index 0000000..9f14029 --- /dev/null +++ b/search-index-typesense/renameFilesToLowerCase.mjs @@ -0,0 +1,47 @@ +/* + Author: Kor Dwarshuis + Created: 2023 + Updated: - + Description: This script renames all files in a directory to lowercase. It requires the directory path as an argument. The script uses the Node.js fs module to read the directory and rename the files. +*/ + +import fs from 'fs'; +import path from 'path'; +import logger from './modules/logger.mjs'; + +function renameFilesToLowerCase(directoryPath) { + fs.readdir(directoryPath, (err, files) => { + if (err) { + logger.setLogFile('error.log'); + logger.log(`Error reading directory: ${err}`); + + return; + } + + files.forEach((file) => { + const oldFilePath = path.join(directoryPath, file); + const newFilePath = path.join(directoryPath, file.toLowerCase()); + + fs.rename(oldFilePath, newFilePath, (renameErr) => { + if (renameErr) { + logger.setLogFile('error.log'); + logger.log(`Error renaming file to lower case: ${renameErr}`); + } else { + logger.setLogFile('success.log'); + logger.log(`${file} has been renamed to lower case`); + } + }); + }); + }); +} + +// Usage: Provide the directory path as an argument when running the script +const directoryPath = process.argv[2]; + +if (!directoryPath) { + logger.setLogFile('success.log'); + logger.log('Please provide the directory path as an argument.'); + +} else { + renameFilesToLowerCase(directoryPath); +} diff --git a/search-index-typesense/restore.sh b/search-index-typesense/restore.sh new file mode 100644 index 0000000..a29cd1f --- /dev/null +++ b/search-index-typesense/restore.sh @@ -0,0 +1,50 @@ +#!/bin/bash + +# Author: Kor Dwarshuis +# Created: 2023 +# Updated: - +# Description: This script imports a JSONL file into a Typesense collection (typesense.org). + +# Import variables from .env file +source .env + +# Logger generates a log file with a timestamp and from which file the message comes from. +source ./${SEARCH_INDEX_DIR}/logger.sh + +local_TYPESENSE_ADMIN_API_KEY="${TYPESENSE_ADMIN_API_KEY}" +local_TYPESENSE_HOST="${TYPESENSE_HOST}" +local_TYPESENSE_COLLECTION_NAME="${TYPESENSE_COLLECTION_NAME}" + + +# Use the `local_TYPESENSE_ADMIN_API_KEY`, `local_TYPESENSE_HOST`, and `local_TYPESENSE_COLLECTION_NAME` variables anywhere in the script as needed + +setLogFile "success.log" +log "local_TYPESENSE_COLLECTION_NAME:" +log $local_TYPESENSE_COLLECTION_NAME + + + +############## CONFIGURATION ############## +# URL of the endpoint to import documents +urlImport="https://${local_TYPESENSE_HOST}.a1.typesense.net/collections/${local_TYPESENSE_COLLECTION_NAME}/documents/import?action=create" + +# log files +log_dir="$(pwd)/${SEARCH_INDEX_DIR}/logs" + + +############## IMPORT JSONL FILE ############## + +setLogFile "success.log" +log "Start importing files: $file" + + +# Execute the cURL command to import the document +curl -H "X-TYPESENSE-API-KEY: ${local_TYPESENSE_ADMIN_API_KEY}" \ + -X POST \ + -T "$(pwd)/${SEARCH_INDEX_DIR}/search-index-restore/restore.jsonl" \ + --http1.1 \ + "$urlImport" >> "$log_dir/import-into-search-index.log" + +setLogFile "success.log" +log "\n\nImport completed for file: $file" +log "-------------------------" diff --git a/search-index-typesense/scrape_start.sh b/search-index-typesense/scrape_start.sh new file mode 100644 index 0000000..c844586 --- /dev/null +++ b/search-index-typesense/scrape_start.sh @@ -0,0 +1,112 @@ +# Import variables from .env file +source .env + + +# Logger generates a log file with a timestamp and from which file the message comes from. +source ./${SEARCH_INDEX_DIR}/logger.sh + + +######################### +# TEST IF REQUIRED LIBRARIES ARE INSTALLED +######################### +setLogFile "success.log" +log "Start testing libraries is finished" +node "$SCRIPT_DIR/isLibraryInstalled.mjs" +log "Testing libraries is finished (check outcome in success.log and error.log)" + + + +######################### +# INITIALIZING +######################### + +# Get the directory where the main.sh script is located +SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)" + + + +######################### +# PREPARING +######################### + +# Prepare file system. Remove old files and directories and create new ones. +setLogFile "success.log" +log "Start preparing file system" +source "$SCRIPT_DIR/prepare_file_system.sh" +log "Preparing file system finished" + +# Copy handmade stuff: entries for direct import into Typesense, manual files, sitemaps. +setLogFile "success.log" +log "Start copying manual files" +source "$SCRIPT_DIR/copy_manual_files.sh" +log "Copying manual files finished" + +# Create sitemaps via sitemap-generator. +setLogFile "success.log" +log "Start creating sitemaps" +source "$SCRIPT_DIR/config/config_sitemaps_create.sh" +log "Creating sitemaps finished" + +# Remove unwanted urls from the sitemaps (new sitemaps generated or not) +setLogFile "success.log" +log "Start removing unwanted urls from sitemaps" +node "$SCRIPT_DIR/removeURLsFromSitemap.mjs" +log "Removing unwanted urls from sitemaps finished" + + +# Filenames to lowercase. +setLogFile "success.log" +log "Start renaming files to lowercase" +node "${SCRIPT_DIR}/renameFilesToLowerCase.mjs" ${SEARCH_INDEX_DIR}/sitemaps +log "Renaming files to lowercase finished" + +# Fetch external content from Google Sheets. +setLogFile "success.log" +log "Start fetching external content" +node fetchExternalContent/fetchSingleUrlsFromWotTermsGoogleSheet/fetchSingleUrlsFromWotTermsGoogleSheet.js +log "Fetching external content finished" + +######################### +# START SCRAPING +######################### + +# Scrape the websites. +setLogFile "success.log" +log "Start extracting data" +node "$SCRIPT_DIR/extractData.mjs" +log "Extracting data finished" + +# Split the content.jsonl file into multiple files so the size is optimal for Typesense. +setLogFile "success.log" +log "Start splitting content" +node "$SCRIPT_DIR/splitContentJSONL.mjs" +log "Splitting content finished" + +# Count the total number of lines in all .jsonl files and write it to log dir. +setLogFile "success.log" +log "Start counting number of lines" +node "$SCRIPT_DIR/countLinesInJsonlFiles.mjs" +log "Counting number of lines finished" + +setLogFile "success.log" +log "Start collecting urls and writing to index file" +node "$SCRIPT_DIR/collectScrapedUrls.mjs" "${SEARCH_INDEX_DIR}/${SEARCH_INDEX_ENTRIES_DIR}" "${INDEX_OVERVIEW_FILE}" +log "Collecting urls and writing to index file finished" + +# Sort and style the index file. +setLogFile "success.log" +log "Start sorting and styling index file" +node "$SCRIPT_DIR/sortAndStyleScrapedIndex.mjs" "$INDEX_OVERVIEW_FILE" +log "Sorting and styling index file finished" + + + +######################### +# BACKING UP +######################### + +# Backup output (scrape results, handmade stuff, sitemaps, logs, webpage overview, typesense export). +setLogFile "success.log" +log "Start creating backup" +source "$SCRIPT_DIR/backup.sh" +log "Creating backup finished" \ No newline at end of file diff --git a/search-index-typesense/sortAndStyleScrapedIndex.mjs b/search-index-typesense/sortAndStyleScrapedIndex.mjs new file mode 100644 index 0000000..39324a8 --- /dev/null +++ b/search-index-typesense/sortAndStyleScrapedIndex.mjs @@ -0,0 +1,95 @@ +/** + * Sorts the lines in a file alphabetically and wraps them in HTML list elements. + * The first line of the file is preserved as a header. + * Usage: node sortFile.js + * Example: + * $ node search-index-typesense/sortAndStyleScrapedIndex.mjs docs/overview/indexed-in-KERISSE.md + * + */ + +import fs from 'fs'; +import logger from './modules/logger.mjs'; +import { format } from 'date-fns'; + +const urlRegex = /(https?:\/\/[^\s]+)/g; + +function sortLinesInFile(fileName) { + // Read the file + fs.readFile(fileName, 'utf8', (err, data) => { + if (err) { + logger.setLogFile('error.log'); + logger.log('Error reading the file:' + err); + + return; + } + + // Check if the content already contains
      or
    • + if (data.includes('
        ') || data.includes('
      • ')) { + logger.setLogFile('error.log'); + logger.log('The content already contains HTML list elements, skipping processing.'); + + return; + } + + // Split the data into lines + const lines = data.split('\n'); + + // Remove empty lines + const nonEmptyLines = lines.filter(line => line.trim() !== ''); + + // Count the entries + const pagesCount = nonEmptyLines.length; + + // Sort the non-empty lines alphabetically + const sortedLines = nonEmptyLines.sort(); + + // Wrap and convert URL lines to clickable links + const wrappedLines = sortedLines.map(line => { + const isURL = line.match(urlRegex); + if (isURL) { + const url = isURL[0]; + const wrappedURL = `${url}`; + return `
      • ${wrappedURL}
        • `; + } + return `
      • ${line}
        • `; + }); + + // Join the wrapped lines into a single string + const wrappedContent = wrappedLines.join('\n'); + + // Wrap the content in
          and
        + const finalContent = `
          \n${wrappedContent}\n
        `; + + // Get the current time + const currentTime = format(new Date(), 'dd MMMM yyyy HH:mm:ss'); + + // Add a header + const header = '# Indexed in KERISSE'; + + // Final string to write to the file + const contentWithHeader = `${header}\n

        Indexed at ${currentTime}

        \n

        Number of indexed pages: ${pagesCount}

        \n${finalContent}`; + + // Write the final content back to the file + fs.writeFile(fileName, contentWithHeader, 'utf8', (err) => { + if (err) { + logger.setLogFile('error.log'); + logger.log('Error writing to the file:' + err); + + return; + } + logger.setLogFile('success.log'); + logger.log('File sorted and wrapped in HTML successfully!'); + }); + }); +} + +// Usage: node sortFile.js +const fileName = process.argv[2]; +if (!fileName) { + logger.setLogFile('error.log'); + logger.log('Please provide a file name as an argument.'); + + process.exit(1); +} + +sortLinesInFile(fileName); diff --git a/search-index-typesense/splitContentJSONL.mjs b/search-index-typesense/splitContentJSONL.mjs new file mode 100644 index 0000000..110a2b0 --- /dev/null +++ b/search-index-typesense/splitContentJSONL.mjs @@ -0,0 +1,121 @@ +import fs from 'fs'; +import path from 'path'; +import readline from 'readline'; +import logger from './modules/logger.mjs'; + +const directoryPath = './search-index-typesense/search-index-entries/'; // The path to the directory containing the .jsonl files +// Set it to your desired path +const chunkSize = 2500; // Adjust this value to change the chunk size + + +// Get all files from the directory +fs.readdir(directoryPath, (err, files) => { + if (err) { + logger.setLogFile('error.log'); + logger.log('Error reading the directory:', err); + return; + } + + // Filter .jsonl files and process each + files.filter(file => path.extname(file) === '.jsonl').forEach(processFile); +}); + +function processFile(file) { + const originalFilePath = path.join(directoryPath, file); + const renamedOriginalFilePath = originalFilePath + '.not-split'; + const tempFilePath = originalFilePath + '.temp'; + + const readStream = fs.createReadStream(originalFilePath); + const writeStream = fs.createWriteStream(tempFilePath); + + const rl = readline.createInterface({ + input: readStream, + output: writeStream + }); + + rl.on('line', (line) => { + const obj = JSON.parse(line); + const contents = splitContent(obj.content); + contents.forEach(content => { + const newObj = { ...obj, content }; + writeStream.write(JSON.stringify(newObj) + '\n'); + }); + }); + + rl.on('close', () => { + // Rename the original file by adding ".not-split" at the end + fs.rename(originalFilePath, renamedOriginalFilePath, (err) => { + if (err) { + logger.setLogFile('error.log'); + logger.log(`Error renaming ${file} to ${renamedOriginalFilePath}:`, err); + return; + } + // Rename the temp file back to the original name + fs.rename(tempFilePath, originalFilePath, (err) => { + if (err) { + logger.setLogFile('error.log'); + logger.log(`Error renaming temporary file ${tempFilePath} to ${file}:`, err); + + return; + } + logger.setLogFile('success.log'); + logger.log(`Done processing ${file}. Original renamed to ${file}.not-split`); + + }); + }); + }); +} + + + +// Version 1: Splitting by number of characters +// // This function splits the content into chunks of the configured size, but also tries to avoid splitting in the middle of a word +// function splitContent(content) { +// // Splitting the content into chunks of the configured size +// return content.match(new RegExp(`.{1,${chunkSize}}`, 'g')) || []; +// } + +// Version 2: Splitting by number of lines +// This function splits the content into chunks of the configured size +function splitContent(content) { + const chunks = []; + if (content === "") { + chunks.push(""); // Add an empty string to preserve the entry + } else { + for (let i = 0; i < content.length; i += chunkSize) { + chunks.push(content.slice(i, i + chunkSize)); + } + } + return chunks; +} + +// Version 3: Splitting into chunks of configurable size, but also trying to avoid splitting in the middle of a line +// // This function splits the content into chunks of the configured size, but also tries to avoid splitting in the middle of a line +// function splitContent(content) { +// const lines = content.split('\n'); +// const chunks = []; + +// let currentChunk = ''; + +// lines.forEach(line => { +// // If adding the next line exceeds the chunk size or if it's a significant break in content (e.g., a comment or new function) +// if (currentChunk.length + line.length + 1 > chunkSize || line.trim().startsWith('#') || line.trim().startsWith('def ')) { +// if (currentChunk) { +// chunks.push(currentChunk); +// } +// currentChunk = line; +// } else { +// // If there's already content in the current chunk, add a newline before adding the next line +// if (currentChunk) { +// currentChunk += '\n'; +// } +// currentChunk += line; +// } +// }); + +// if (currentChunk) { +// chunks.push(currentChunk); +// } + +// return chunks; +// } diff --git a/src/custom.css b/src/custom.css new file mode 100644 index 0000000..dacdc92 --- /dev/null +++ b/src/custom.css @@ -0,0 +1,903 @@ +/* + * Levels + */ +.show-level-buttons-info img { + max-width: 2em; + margin-right: 0.5em; + float: left; +} + +/* clear float */ +.show-level-buttons-info:after { + content: ''; + display: table; + clear: both; +} + +/* + * Video + */ + +/* TODO: better settings for width and height */ +.youtube-video { + display: block; + border: 1px solid pink; + margin: 0 auto 1em; + /* width: 300px; */ + /* width: 300px; */ + /* height: 200px; */ +} + +video { + width: 100%; +} + +video[poster] { + object-fit: cover; +} + +.video-inline { + background: #eef9fd; + border: 3px solid #b2beea; + border-radius: 7px; + width: 10em; + float: right; + margin: 0 1em 1em; + padding: 0.5em; +} + +.subtitlecontainer { + font-size: 1.5em; +} + +.video-test { + border: 1px solid #222; + margin: 1em 0 2em; +} + +/* + * Cross Links + */ +.cross-link { + color: rgb(212, 109, 136); +} + +/* + * External Links + * https://christianoliff.com/blog/styling-external-links-with-an-icon-in-css/ + */ + +article a[href^="http"]::after, +article a[href^="https://"]::after { + content: ''; + width: 18px; + height: 18px; + margin-left: 4px; + background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' width='16' height='16' fill='currentColor' viewBox='0 0 16 16'%3E%3Cpath fill-rule='evenodd' d='M8.636 3.5a.5.5 0 0 0-.5-.5H1.5A1.5 1.5 0 0 0 0 4.5v10A1.5 1.5 0 0 0 1.5 16h10a1.5 1.5 0 0 0 1.5-1.5V7.864a.5.5 0 0 0-1 0V14.5a.5.5 0 0 1-.5.5h-10a.5.5 0 0 1-.5-.5v-10a.5.5 0 0 1 .5-.5h6.636a.5.5 0 0 0 .5-.5z'/%3E%3Cpath fill-rule='evenodd' d='M16 .5a.5.5 0 0 0-.5-.5h-5a.5.5 0 0 0 0 1h3.793L6.146 9.146a.5.5 0 1 0 .708.708L15 1.707V5.5a.5.5 0 0 0 1 0v-5z'/%3E%3C/svg%3E"); + background-position: center; + background-repeat: no-repeat; + background-size: contain; + display: inline-block; +} + +/* + * Tables + */ +table th { + writing-mode: vertical-lr; +} + +table td, +table th { + vertical-align: top; +} + + +/* + * Tippy + */ +.tippy-box { + padding: 1em; +} + +.definition-button { + background: rgb(155, 204, 242); + border-radius: 50%; + font-size: 1.2em; + padding: 0.1em 0.25em 0.15em; + /* Adjust vertical and horizontal padding separately */ + + margin-left: 0.3em; + line-height: 0.8; + /* Keep this to control the height */ + border: none !important; + vertical-align: middle; + cursor: pointer; + + /* Inline-flex for vertical and horizontal alignment */ + display: inline-flex; + align-items: center; + justify-content: center; +} + + + +[aria-describedby='tippy-1'].definition-button { + transform: rotate(45deg); + /* CSS styles */ +} + + +/* + * BEGIN HTML5 Boilerplate + * https://github.com/h5bp/html5-boilerplate + */ + +/* + * Hide visually and from screen readers + */ + +.hidden, +[hidden] { + display: none !important; +} + +/* + * Hide only visually, but have it available for screen readers: + * https://snook.ca/archives/html_and_css/hiding-content-for-accessibility + * + * 1. For long content, line feeds are not interpreted as spaces and small width + * causes content to wrap 1 word per line: + * https://medium.com/@jessebeach/beware-smushed-off-screen-accessible-text-5952a4c2cbfe + */ + +.sr-only { + border: 0; + clip: rect(0, 0, 0, 0); + height: 1px; + margin: -1px; + overflow: hidden; + padding: 0; + position: absolute; + white-space: nowrap; + width: 1px; +} + +/* + * Extends the .sr-only class to allow the element + * to be focusable when navigated to via the keyboard: + * https://www.drupal.org/node/897638 + */ + +.sr-only.focusable:active, +.sr-only.focusable:focus { + clip: auto; + height: auto; + margin: 0; + overflow: visible; + position: static; + white-space: inherit; + width: auto; +} + +/* + * Hide visually and from screen readers, but maintain layout + */ + +.invisible { + visibility: hidden; +} + +/* + * END HTML5 Boilerplate + */ + +/* + * TYPESENSE INSTANTSEARCH +*/ + +:root { + --docusaurus-instantsearch-modal-bg: #222222bd; + --docusaurus-instantsearch-bg: #feffff; + --docusaurus-instantsearch-bg-hover: #f8fafb; +} + +/* For readability concerns, you should choose a lighter palette in dark mode. */ +[data-theme='dark'] { + --docusaurus-instantsearch-modal-bg: #22222259; + --docusaurus-instantsearch-bg: #222; + --docusaurus-instantsearch-bg-hover: #393838; +} + +.search-heading { + background-image: url("/img/stamp.png"); + background-position: left top; + background-repeat: no-repeat; + background-color: transparent; + background-size: contain; + /* background-size: clamp(30px, 4%, 160px) auto; */ + /* background-origin: content-box; */ + padding: 0 1em 0 2em; +} + +#search a { + display: block; + text-decoration: none; +} + +/* Fix: on iOS you cannot scroll horizontally in a pre tag in search results */ +#search pre { + overflow-x: scroll; + width: 100%; + position: relative; +} + +#search pre { + overflow-x: scroll; +} + +/* This forces the scrollbar to always be visible in WebKit browsers */ +#search pre::-webkit-scrollbar { + -webkit-appearance: none; + width: 11px; +} + +#search pre::-webkit-scrollbar-thumb { + border-radius: 8px; + border: 2px solid white; + /* should match the background of the container */ + background-color: rgba(0, 0, 0, .5); +} + +#search pre::-webkit-scrollbar-track { + background-color: #e5e5e5; +} + + +/* The icon at the top right, which starts the search modal */ +#search-start { + cursor: pointer; + padding: 0.5em; + line-height: normal; + width: 3em; + text-align: right; + font-size: 1.5em; + border: none; + background: none; +} + +#search-close { + position: absolute; + top: 0; + right: 0; + cursor: pointer; + padding: 0.5em; + font-size: 2em; + z-index: 1042; +} + +/* .docs-doc-page #search-box .ais-SearchBox .ais-SearchBox-input { */ +#search-box .ais-SearchBox .ais-SearchBox-input { + margin: 0 auto; + padding: 0.1em 0.5em; + font-size: 1.5em; + + /* Style copied from the card properties, via web inspector */ + border-color: rgba(var(--bs-secondary-rgb), var(--bs-border-opacity)) !important; + max-width: 100%; +} + +.column-refinement-filters { + background: #337dbe0c; +} + +#clear-refinements .ais-ClearRefinements-button { + margin: 0 !important; + /* To override the classes that are assigned to typesense buttons, defined in typesenseInstantSearch.js */ +} + +#current-refinements-list { + font-size: 0.7em !important; +} + +#current-refinements-list .ais-CurrentRefinements-label, +#current-refinements-list .ais-CurrentRefinements-category { + display: block; +} + +#current-refinements-list .ais-CurrentRefinements-label { + font-weight: bold; + margin-top: 1em; +} + + +.ais-Hits-list { + list-style-type: none; + padding-left: 0; +} + +.ais-Pagination-list li { + display: inline-block; + margin: 0.5em; + + font-size: 1.2em; +} + +.ais-Pagination-list li a { + text-decoration: none; + padding: 0.5em; +} + +.ais-Hits--empty { + background: transparent url('/img/travolta.gif') center center no-repeat; + min-height: 400px; +} + +.ais-Pagination-item--selected .ais-Pagination-link { + border: 1px solid var(--ifm-color-primary); + border-radius: 7px; +} + +.card { + transition: background 0.3s ease-in-out; + /* max-height: 20em; */ + overflow: scroll; + -webkit-overflow-scrolling: touch; +} + +/* .card:hover { + transition: background 0.3s ease-in-out; + background: var(--docusaurus-instantsearch-bg-hover); +} */ + + + +/* html structure refinement list +
      • +
        + +
        +
        • +*/ +.ais-RefinementList-count { + /* color: var(--ifm-color-primary) !important; */ + color: #111; + background-color: #80b5ff76; + border-radius: 10px; + padding: 2px 5px; + position: relative; + top: -0.6em; + left: 0.5em; + font-size: 0.5em; +} + +/* If an item wraps to a new line, the new line should not go under the checkbox. Solution: use text-indent */ +.ais-RefinementList-item { + margin-left: 2.8em; +} + +.ais-RefinementList-item div { + text-indent: -1.3em; +} + +/* .ais-RefinementList-item input { + margin-bottom: 2em; + display: inline-block; +} */ + + +.contextual-info { + font-size: 0.9em; +} + +/* #filters-section .row { + min-height: 15em; + border: 1px solid #cccccc56; + border-radius: 7px; + overflow: scroll; +} */ + +.card-header.gleif { + background-image: url("/img/logo-gleif.svg"); +} + +.card-header.essif-lab { + background-image: url("/img/logo-essif-lab.png"); +} + +.card-header.kerisse { + background-image: url("/img/stamp.png"); +} + +.card-header.gleif, +.card-header.essif-lab, +.card-header.kerisse { + background-position: right bottom; + background-repeat: no-repeat; + background-color: transparent; + background-size: contain; + background-origin: content-box; +} + +.search-results-img { + max-width: 100%; + margin: 0 auto; + display: block; +} + +#search mark { + /* background-color: transparent; */ + color: #000; + position: relative; +} + +#search mark { + position: relative; + border: 3px solid #337dbe8c; +} + +/* Underlining search hits */ +#search mark::after { + content: ""; + display: block; + height: 0.8em; + /* Adjust the height */ + width: 100%; + position: absolute; + bottom: -0.3em; + left: 0; + background-size: cover; + background-repeat: repeat-x; +} + +/* + * END TYPESENSE INSTANTSEARCH + */ + + +/* +Scroll Shadows + +https://css-tricks.com/books/greatest-css-tricks/scroll-shadows/ +*/ +.scroll-shadows { + overflow: auto; + + background: + /* Shadow Cover TOP */ + linear-gradient(white 30%, + rgba(255, 255, 255, 0)) center top, + + /* Shadow Cover BOTTOM */ + linear-gradient(rgba(255, 255, 255, 0), + white 70%) center bottom, + + /* Shadow TOP */ + radial-gradient(farthest-side at 50% 0, + rgba(0, 0, 0, 0.2), + rgba(0, 0, 0, 0)) center top, + + /* Shadow BOTTOM */ + radial-gradient(farthest-side at 50% 100%, + rgba(0, 0, 0, 0.2), + rgba(0, 0, 0, 0)) center bottom; + + background-repeat: no-repeat; + background-size: 100% 40px, 100% 40px, 100% 14px, 100% 14px; + background-attachment: local, local, scroll, scroll; +} + + +/* + ToIP Glossary +*/ + +#glossary_content dt { + margin-top: 1.4em; + font-size: 125%; + font-family: Verdana, sans-serif; +} + +#glossary_content dt, +#glossary_content dt a { + color: #a3c74e; +} + +#glossary_content dt.letter { + text-align: center; + font-weight: bold; + color: #999; + border-bottom: solid 1px #ddd; + margin-left: 25%; + margin-right: 25%; + margin-top: 2.2em; + color: #666; +} + +#glossary_content dd { + margin-left: 2em; +} + +#glossary_content dt>span.tag { + float: right; + background-color: #eee; + border: 1px solid #ccc; + padding: 2px 4px; + margin-right: 4px; + font-size: 60%; + font-family: Verdana; + color: #666; +} + +#glossary_content dd>p:first-child { + margin-top: 0.2em; +} + +#glossary_content a { + color: #3061a8; + text-decoration: none; +} + +#glossary_content a:hover { + border-bottom: solid 1px #3061a8; +} + +#glossary_content a:active { + background-color: #eee; +} + +#glossary_content a:visited { + color: #6161a8; +} + +#glossary_content p.meta { + font-size: 80%; + color: #bbb; + text-align: right; + margin-top: -0.9em; +} + +#glossary_content ._slf { + float: left; + padding-right: 4px; + padding-top: 4px; + margin-left: -20px; + cursor: pointer; + width: 16px; + height: 16px; + display: none; +} + +#glossary_content dt:not(.letter):hover>._slf { + display: inline; +} + +#glossary_content ._xl { + padding-right: 4px; + display: none; + cursor: pointer; + width: 16px; + height: 16px; +} + +#glossary_content dt:not(.letter):hover>._xl { + display: inline; +} + +/* + END ToIP Glossary +*/ + + + +/* img.floatleft { + float: left !important; + margin-right: 1em !important; + margin-bottom: 1em !important; + width: 200px !important; +} */ + +img.floatleft { + float: left; + margin-right: 1em; + margin-bottom: 1em; + width: 200px; +} + + + +/* #docusaurus_skipToContent_fallback > div > main > div > div > div > div > article > div.theme-doc-markdown.markdown > img { + float: left !important; + margin-right: 1em !important; + margin-bottom: 1em !important; + width: 200px !important; +} */ + + + +/* + SVG +*/ +svg a { + fill: blue; + /* stroke: blue; */ + /* stroke-width: 0.4; */ + /* stroke-linecap: round; */ + text-decoration: underline !important; +} + +/* Animate SVG arrows */ +@keyframes drawSvgArrows { + to { + stroke-dashoffset: 0; + } +} + +/* path { */ +/* path[stroke-dasharray] { */ +path[marker-end] { + stroke-dasharray: 10; + stroke-dashoffset: 40; + /* animation: drawSvgArrows 3.5s linear forwards; */ + animation: drawSvgArrows 3.5s linear infinite; +} + +/* + END SVG +*/ + + +/* + Images +*/ + +/* Default settings for images */ +article .markdown img, +/* images in search results also need a shadow */ +#hits .card-body img { + width: 100%; + + /* Since images often contain text, it is important to show where the image ends */ + box-shadow: + 0px 0px 3.9px rgba(0, 0, 0, 0.039), + 0px 0px 9.4px rgba(0, 0, 0, 0.057), + 0px 0px 17.8px rgba(0, 0, 0, 0.07), + 0px 0px 31.7px rgba(0, 0, 0, 0.083), + 0px 0px 59.3px rgba(0, 0, 0, 0.101), + 0px 0px 142px rgba(0, 0, 0, 0.14); + margin-bottom: 2em; +} + +/* Default settings, no media queries */ +article .markdown .inline-thumb-start, +#hits img.inline-thumb-start, +article .markdown .inline-thumb-end, +#hits img.inline-thumb-end, +article .markdown .inline-small-start, +#hits img.inline-small-start, +article .markdown .inline-small-end, +#hits img.inline-small-end, +article .markdown .inline-medium-start, +#hits img.inline-medium-start, +article .markdown .inline-medium-end, +#hits img.inline-medium-end { + width: 100%; +} + +/* Small devices (landscape phones, 576px and up) */ +@media (min-width: 576px) { + + article .markdown .inline-thumb-start, + #hits img.inline-thumb-start { + float: left; + width: 5em; + max-width: 15%; + margin: 0 1em 1em 0; + } + + article .markdown .inline-thumb-end, + #hits img.inline-thumb-end { + float: right; + width: 5em; + max-width: 15%; + margin: 0 0 1em 1em; + } + + article .markdown .inline-small-start, + #hits img.inline-small-start { + float: left; + width: 15em; + max-width: 25%; + margin: 0 1em 1em 0; + } + + article .markdown .inline-small-end, + #hits img.inline-small-end { + float: right; + width: 15em; + max-width: 25%; + margin: 0 0 1em 1em; + } + + article .markdown .inline-medium-start, + #hits img.inline-medium-start { + float: left; + width: 25em; + max-width: 50%; + margin: 0 1em 1em 0; + } + + article .markdown .inline-medium-end, + #hits img.inline-medium-end { + float: right; + width: 25em; + max-width: 50%; + margin: 0 0 1em 1em; + } +} + +/* Full page images */ +.markdown img { + cursor: pointer; +} + +.image-container-full-page img { + margin: auto; + object-fit: contain; +} + +.image-container-full-page { + z-index: 1041; + background: white; + position: fixed; + top: 0; + left: 0; + width: 100vw; + height: 100vh; + overflow: scroll; +} + +.image-container-full-page::after { + content: '×'; + /* Unicode character for multiplication sign, resembles a cross */ + position: absolute; + top: 10px; + right: 10px; + font-size: 48px; + cursor: pointer; + /* Makes it obvious the element is clickable */ +} + +/* End full page images */ + +/* + End Images +*/ + +/* + Various +*/ +.ais-SearchBox-loadingIndicator { + display: none; +} + +/* + End Various +*/ + + +/* + Horizontal scrollable navbar in search results +*/ +.scrollable-navbar { + overflow-x: auto !important; + width: 100% !important; +} + +.nowrap { + white-space: nowrap !important; + display: inline-block !important; +} + +.nav-item { + display: inline-block !important; + padding: 10px 5px !important; + text-decoration: none !important; +} + +/* + End Horizontal scrollable navbar in search results +*/ + + +/* + Glossary Menu +*/ +.glossary-menu { + background: #ecf1f4; +} + +.greyed-out { + color: #aaa; + pointer-events: none; +} + +/* + End Glossary Menu +*/ + +/* + All Glossareis Combined +*/ +.glossaries-combined h2 { + color: #a3c74e; + font-weight: 700; + font-size: 1.2em; + font-family: Verdana, sans-serif; +} + +/* + End all Glossareis Combined +*/ + + + +@keyframes outlineAnimation { + 0% { + outline: 2px solid transparent; + } + + 50% { + outline: 2px solid blue; + /* Change color as needed */ + } + + 100% { + outline: 2px solid transparent; + } +} + +.animate-outline { + animation: outlineAnimation 1s ease-in-out; +} + +/* + Bookmarklets +*/ +.bookmarklet { + animation: outlineAnimation 1s ease-in-out infinite; + outline: 3px dashed #222; +} + +/* + End Bookmarklets +*/ + + +/* + Auto-generated index links, for example on github issues page +*/ +.generated-index-links { + width: 100%; + /* box-sizing: border-box; */ +} + +/* Medium devices (tablets, 768px and up) The navbar toggle appears at this breakpoint */ +@media (min-width: 768px) { + .generated-index-links { + /* width: calc(100% / 4 - 1em); */ + width: calc(100%/3); + } +} + +/* + End Auto-generated index links +*/ \ No newline at end of file diff --git a/src/typesenseInstantSearch.js b/src/typesenseInstantSearch.js new file mode 100644 index 0000000..6a90845 --- /dev/null +++ b/src/typesenseInstantSearch.js @@ -0,0 +1,559 @@ +/** + * @file This file instantiates the Typesense InstantSearch.js adapter and the InstantSearch.js search client. + * @author Kor Dwarshuis + * @version 1.0.0 + * @since 2023-05-19 + */ + +import instantsearch from 'instantsearch.js/es'; + +// to be used in the future +// import { queriesWithSortAdjustment } from '/search-index-typesense/overrides/sortAdjustment.js'; + +import { + searchBox, + hits, + pagination, + // infiniteHits, + configure, + // stats, + // analytics, + refinementList, + clearRefinements, + // menu, + sortBy, + currentRefinements, +} from 'instantsearch.js/es/widgets'; + +import TypesenseInstantSearchAdapter from 'typesense-instantsearch-adapter'; +// import { SearchClient as TypesenseSearchClient } from 'typesense'; // To get the total number of docs + +// import { connectSearchBox } from 'instantsearch.js/es/connectors' +import { connectRefinementList } from 'instantsearch.js/es/connectors'; + +// This is a custom widget that displays the refinement list for the "tag" attribute, but only for items that have the label "img". This is a replacement for the standard refinementList widget. The standard refinementList widget does not allow you to show a message when there are no items available. This custom widget does. +const refinementListImageToggle = connectRefinementList((renderOptions, isFirstRender) => { + const { items, widgetParams } = renderOptions; + + const container = document.querySelector("#tag-refinement-list"); + + if (items.length === 0) { + // Display "No results" if there are no items + container.innerHTML = '
        No images available
        '; + } else { + // Otherwise, build and display the refinement list + const list = items.map(item => { + return ``; + }).join(''); + + container.innerHTML = `
        ${list}
        `; + } +}); + +const typeSenseInstantSearch = () => { + // "Try searching for:" + function handleSearchTermClick(event) { + const searchBox = document.querySelector('.ais-SearchBox-input'); + search.helper.clearRefinements(); + searchBox.value = event.currentTarget.textContent; + search.helper.setQuery(searchBox.value).search(); + } + + document.querySelectorAll('.clickable-search-term').forEach((el) => { + el.addEventListener('click', handleSearchTermClick); + }); + + // to be used in the future + // function applyCustomSorting(items) { + // console.log('items: ', items); + // const currentQuery = search.helper.state.query; + + // const matchingQueryObj = queriesWithSortAdjustment.find( + // (obj) => obj.queryString === currentQuery + // ); + + // if (matchingQueryObj) { + // const sortAdjustment = matchingQueryObj.sortAdjustment; + // const urlSubstring = matchingQueryObj.urlSubstring; + + // return items.map((item) => { + // item.sort_order = item.url && item.url.includes(urlSubstring) ? sortAdjustment : 0; + // return item; + // }).sort((a, b) => b.sort_order - a.sort_order); + // } + + // return items; + // } + + + + + + const typesenseInstantsearchAdapter = new TypesenseInstantSearchAdapter({ + server: { + apiKey: 'qy6mC9ZakKZ3C8GUD5T3iDrelDgpp5Zc', // Be sure to use an API key that only allows searches, in production + nodes: [ + { + host: '9ktso7i1b8034azqp-1.a1.typesense.net', + port: '443', + protocol: 'https', + }, + ], + }, + // The following parameters are directly passed to Typesense's search API endpoint. + // So you can pass any parameters supported by the search endpoint below. + // queryBy is required. + // filterBy is managed and overridden by InstantSearch.js. To set it, you want to use one of the filter widgets like refinementList or use the `configure` widget. + additionalSearchParameters: { + // query_by: 'title,authors', + // query_by: 'imgMeta, content, firstHeadingBeforeElement, pageTitle, siteName, source, url', + query_by: 'content, firstHeadingBeforeElement, pageTitle, siteName, source, url', + // weights: '10000,1,1,1,1,1,1', + // filter_by: 'tag:=[p]', + // filter_by: 'tag:[a]', + // filter_by: 'contentLength:>50', + // sort_by: 'contentLength:asc',//asc or desc + + // sort_by: 'imgMetaLength:asc, contentLength:asc',//asc or desc + sort_by: 'imgWidth:desc,contentLength:desc,imgUrl(missing_values: last):desc',//asc or desc + // sort_by: 'imgWidth:desc,imgUrl(missing_values: last):desc',//asc or desc + group_by: 'url', + group_limit: 1 + }, + }); + const searchClient = typesenseInstantsearchAdapter.searchClient; + + const search = instantsearch({ + searchClient, + indexName: 'Wot-terms',// production + // indexName: 'Wot-terms-test',// testing + routing: true, + // searchFunction(helper) { + // if (helper.state.query === '') { + // document + // .querySelector('.search-modal-backdrop') + // .classList.add('hidden'); + // document.querySelector('#search').classList.add('hidden'); + // } else { + // document + // .querySelector('.search-modal-backdrop') + // .classList.remove('hidden'); + // document.querySelector('#search').classList.remove('hidden'); + // } + // helper.search(); + // }, + }); + + search.addWidgets([ + searchBox({ + container: '#search-box', + showSubmit: false, + showReset: false, + showLoadingIndicator: true, + placeholder: 'Enter Search…', + autofocus: true, + cssClasses: { + input: 'form-control', + }, + // queryHook(query, search) { + // const modifiedQuery = queryWithoutStopWords(query); + // if (modifiedQuery.trim() !== '') { + // search(modifiedQuery); + // } + // }, + }), + + configure({ + hitsPerPage: 10, + }), + hits({ + container: '#hits', + + // to be used in the future + // transformItems(items) { + // let sortedItems = applyCustomSorting(items); + // return sortedItems; + // }, + templates: { + item(item) { + function makeCodeStringShorter(string) { + /* + Sometimes code blocks are very long and they take up a lot of space in the search results. + + This function takes a string as input and returns a modified version of the string. + It finds the first occurrence of the tag and the tag in the input string. + Then, it extracts a substring that includes 100 characters before the first and 100 characters after the first . + The extracted substring is wrapped in an HTML element with the class "highlighted". + If either the tag or the tag is not found, the function returns the original string unchanged. + */ + + // Find the index of the first occurrence of and in the string + let firstMarkerTagIndex = string.indexOf(''); + let lastMarkerTagIndex = string.indexOf(''); + + // Check if either < marker > or is not found in the string + if (firstMarkerTagIndex === -1 || lastMarkerTagIndex === -1) { + return string; // Return the original string if the tags are not found + } + + // Calculate the start and end indices for the substring + let start = Math.max(0, firstMarkerTagIndex - 300); // Start xxx characters before the first or at the beginning of the string + let end = Math.min(string.length, lastMarkerTagIndex + 300); // End xxx characters after the first or at the end of the string + + // Extract the substring containing 100 characters before the first and 100 characters after the first + let firstMarkerTagWith100CharactersBeforeAndAfterIt = string.substring(start, end); + + // Add a span with the "highlighted" class around the extracted substring + firstMarkerTagWith100CharactersBeforeAndAfterIt = `${firstMarkerTagWith100CharactersBeforeAndAfterIt}`; + + return firstMarkerTagWith100CharactersBeforeAndAfterIt; // Return the modified string + } + + + // External links should open in a new tab + let openInNewTab = ''; + if (item.url.indexOf('weboftrust.github.io/WOT-terms') === -1) { + openInNewTab = 'target="_blank" rel="noopener"'; + } + + // "Postprocess" the content. Especially code samples can be very long and take up a lot of space in the search results. This function makes the code samples shorter. TODO: check if other content types need to be shortened as well. + let postProcessedCode = ''; + + // If the tag is pre or textarea, wrap the content in a 
         tag, first let's do the opening tag
+          let postProcessedOpeningTag = '';
+          if (item.tag === 'pre' || item.tag === 'textarea') {
+            postProcessedOpeningTag = '
        ';
+            postProcessedCode = makeCodeStringShorter(item._highlightResult.content.value);
+          } else { // Otherwise, wrap the content in a 
         tag
+            postProcessedOpeningTag = '
        '
+            postProcessedCode = item._highlightResult.content.value;
+          }
+
+          // If the tag is pre or textarea, wrap the content in a 
         tag, now let's do the closing tag
+          let postProcessedClosingTag = '';
+          if (item.tag === 'pre' || item.tag === 'textarea') {
+            postProcessedClosingTag = '
        ';
+          } else { // Otherwise, wrap the content in a 
         tag
+            postProcessedClosingTag = '
        '
+          }
+          // END "Postprocess" the content
+
+          // Only if curated is true, show a sticky label
+          let itemCurated = item.curated === true ? `` : '';
+
+          // Only if siteName is not empty, show it
+          let itemSiteNameTemplateString = item.siteName !== '' ? `${item._highlightResult.siteName.value}` : '';
+
+          // Only if title is not empty, show it
+          // mb-4
+          let itemTitleTemplateString = item.pageTitle !== '' ? `
        ${item._highlightResult.pageTitle.value}
        ` : '';
+
+          // Only if author is not empty, show it
+          let itemAuthorTemplateString = item.author !== '' ? `• ${item._highlightResult.author.value}` : '';
+
+
+          // Add class to img based on imgWidth (img that are under 301 are assumed to be logos etc, above 301 are assumed to be explanations, flowcharts, etc)
+          let imgClass = '';
+          item.imgWidth < 301 ? imgClass = "inline-thumb-start" : imgClass = "";
+
+          // Only if imgUrl is not empty, show it
+          let itemImgUrlTemplateString = item.imgUrl !== '' ? `` : '';
+
+          // Only if imgMeta is not empty, show it
+          let itemImgMetaTemplateString = item.imgMeta !== '' ? `
        ${item._highlightResult.imgMeta.value}
        ` : '';
+
+          // Only if creationDate is not empty, show it
+          let itemCreationDateTemplateString = item.creationDate !== '' ? `• ${item.creationDate}` : '';
+
+          // Only if knowledgeLevel is not empty, show it
+          let itemKnowledgeLevelTemplateString = item.knowledgeLevel !== '' ? `• Level: ${item.knowledgeLevel}` : '';
+
+          // Only if type is not empty, show it
+          let itemTypeTemplateString = item.type !== '' ? `• ${item.type}` : '';
+
+          // Only if hierarchy.lvl1 is not empty, show it
+          let itemHierarchyLvl1TemplateString = item['hierarchy.lvl1'] !== '' ? `• ${item['hierarchy.lvl1']}` : '';
+
+          // Only if firstHeadingBeforeElement is not empty, show it
+          let itemFirstHeadingBeforeElementTemplateString = item.firstHeadingBeforeElement !== '' ? `
        ${item.firstHeadingBeforeElement}
        ` : '';
+
+          let siteBrandingClass = '';
+          if (item.siteName === "Gleif website") {
+            siteBrandingClass = "gleif";
+          }
+          if (item.siteName === "eSSIF-Lab") {
+            siteBrandingClass = "essif-lab";
+          }
+          if (item.siteName === "KERISSE (this site)") {
+            siteBrandingClass = "kerisse";
+          }
+          return `
+            
        
+              
        
+                ${itemCurated}
         Found on: ${itemSiteNameTemplateString}
        
+              
        
+              
        
+                
        
+                  ${item._highlightResult.url.value}
+                  ${itemAuthorTemplateString}
+                  ${itemCreationDateTemplateString}
+                  ${itemKnowledgeLevelTemplateString}
+                  ${itemTypeTemplateString}
+                  ${itemHierarchyLvl1TemplateString}
+                
        
+                
        
+                ${itemTitleTemplateString}
+                ${itemFirstHeadingBeforeElementTemplateString}
+
+                ${postProcessedOpeningTag}
+                  ${postProcessedCode}
+                ${postProcessedClosingTag}
+
+                ${itemImgUrlTemplateString}
+                ${itemImgMetaTemplateString}
+              
        
+              
        
+                back to top
+                to URL
+                
+              
        
+            
        
+      `;
+        },
+      },
+    }),
+
+    pagination({
+      container: '#pagination',
+    }),
+    clearRefinements({
+      container: '#clear-refinements',
+      templates: {
+        resetLabel: 'Clear filters'
+      },
+      cssClasses: {
+        button: 'btn btn-secondary btn-sm align-content-center mb-5 mt-3'
+      }
+    }),
+    currentRefinements({
+      container: '#current-refinements-list',
+      cssClasses: {
+        list: 'list-unstyled',
+        item: '',
+        delete: 'btn btn-sm btn-link text-decoration-none p-0 px-2',
+      },
+      transformItems: (items) => {
+        // hide the heading if there are no current refinements
+        document.querySelector("#current-refinements-list-container").classList.add("d-none");
+        const labelLookup = {
+          content: 'Content',
+          author: 'Author',
+          category: 'Category',
+          source: 'Source',
+          mediaType: 'File type',
+        };
+        const modifiedItems = items.map((item) => {
+          // show the heading if there are current refinements
+          document.querySelector("#current-refinements-list-container").classList.remove("d-none");
+          return {
+            ...item,
+            label: labelLookup[item.attribute] || '',
+          };
+        });
+        return modifiedItems;
+      },
+    }),
+    // Currently not useful
+    // sortBy({
+    //   container: '#sort-by',
+    //   items: [
+    //     { label: 'Default Sort', value: 'Wot-terms' },
+    //     { label: 'Content Length: Low to High', value: 'Wot-terms/sort/contentLength:asc' },
+    //     { label: 'Content Length: High to Low', value: 'Wot-terms/sort/contentLength:desc' },
+    //   ],
+    //   cssClasses: {
+    //     select: 'form-select form-select-sm mb-2 border-light-2',
+    //   },
+    // }),
+
+    // // KNOWLEDGELEVEL
+    // refinementList({
+    //   container: '#knowledgelevel-refinement-list',
+    //   attribute: 'knowledgeLevel',
+    //   searchable: false,
+    //   searchablePlaceholder: 'Search knowledge level',
+    //   showMore: false,
+    //   cssClasses: {
+    //     searchableInput: 'form-control form-control-sm mb-2 border-light-2',
+    //     searchableSubmit: 'hidden',
+    //     searchableReset: 'hidden',
+    //     showMore: 'btn btn-secondary btn-sm align-content-center',
+    //     list: 'list-unstyled',
+    //     count: '',
+    //     label: '',
+    //     checkbox: 'me-2',
+    //   },
+
+    //   sortBy: ['name:asc', 'count:desc'],
+    // }),
+    // // TYPE
+    // refinementList({
+    //   container: '#type-refinement-list',
+    //   attribute: 'type',
+    //   searchable: false,
+    //   searchablePlaceholder: 'Search type',
+    //   showMore: false,
+    //   cssClasses: {
+    //     searchableInput: 'form-control form-control-sm mb-2 border-light-2',
+    //     searchableSubmit: 'hidden',
+    //     searchableReset: 'hidden',
+    //     showMore: 'btn btn-secondary btn-sm align-content-center',
+    //     list: 'list-unstyled',
+    //     count: '',
+    //     label: '',
+    //     checkbox: 'me-2',
+    //   },
+
+    //   sortBy: ['name:asc', 'count:desc'],
+    // }),
+    // // SUBJECT
+    // refinementList({
+    //   container: '#subject-refinement-list',
+    //   attribute: 'hierarchy.lvl1',
+    //   searchable: false,
+    //   searchablePlaceholder: 'Subject',
+    //   showMore: false,
+    //   cssClasses: {
+    //     searchableInput: 'form-control form-control-sm mb-2 border-light-2',
+    //     searchableSubmit: 'hidden',
+    //     searchableReset: 'hidden',
+    //     showMore: 'btn btn-secondary btn-sm align-content-center',
+    //     list: 'list-unstyled',
+    //     count: '',
+    //     label: '',
+    //     checkbox: 'me-2',
+    //   },
+    //   sortBy: ['name:asc', 'count:desc'],
+    // }),
+    // TAG
+
+
+    refinementListImageToggle({
+      container: '#tag-refinement-list',
+      attribute: 'tag',
+      // Include other necessary widget options here
+      transformItems: items => items.filter(item => ['img'].includes(item.label)),
+      limit: 1000
+    }),
+
+    // CATEGORY
+    refinementList({
+      container: '#category-refinement-list',
+      attribute: 'category',
+      searchable: true,
+      searchablePlaceholder: 'Category',
+      showMore: false,
+      // max_facet_values: 100, TODO: does this work?
+      cssClasses: {
+        searchableInput: 'form-control form-control-sm mb-2 border-light-2',
+        searchableSubmit: 'hidden',
+        searchableReset: 'hidden',
+        showMore: 'btn btn-secondary btn-sm align-content-center',
+        list: 'list-unstyled',
+        count: '',
+        label: '',
+        checkbox: 'me-2',
+      },
+      sortBy: ['name:asc', 'count:desc'],
+    }),
+    // SOURCE
+    refinementList({
+      container: '#source-refinement-list',
+      attribute: 'source',
+      searchable: true,
+      searchablePlaceholder: 'Source',
+      showMore: true,
+      // max_facet_values: 100, TODO: does this work?
+      cssClasses: {
+        searchableInput: 'form-control form-control-sm mb-2 border-light-2',
+        searchableSubmit: 'hidden',
+        searchableReset: 'hidden',
+        showMore: 'btn btn-secondary btn-sm align-content-center',
+        list: 'list-unstyled',
+        count: '',
+        label: '',
+        checkbox: 'me-2',
+      },
+      sortBy: ['name:asc', 'count:desc'],
+    }),
+
+    refinementList({
+      container: '#author-refinement-list',
+      attribute: 'author',
+      searchable: true,
+      searchablePlaceholder: 'Author',
+      showMore: true,
+      // max_facet_values: 100,TODO: does this work?
+      cssClasses: {
+        searchableInput: 'form-control form-control-sm mb-2 border-light-2',
+        searchableSubmit: 'hidden',
+        searchableReset: 'hidden',
+        showMore: 'btn btn-secondary btn-sm align-content-center',
+        list: 'list-unstyled',
+        count: '',
+        label: '',
+        checkbox: 'me-2',
+      },
+      sortBy: ['name:asc', 'count:desc'],
+    }),
+    // MEDIATYPE
+    refinementList({
+      container: '#media-type-refinement-list',
+      attribute: 'mediaType',
+      searchable: true,
+      searchablePlaceholder: 'File type',
+      showMore: true,
+      // max_facet_values: 100,TODO: does this work?
+      cssClasses: {
+        searchableInput: 'form-control form-control-sm mb-2 border-light-2',
+        searchableSubmit: 'hidden',
+        searchableReset: 'hidden',
+        showMore: 'btn btn-secondary btn-sm align-content-center',
+        list: 'list-unstyled',
+        count: '',
+        label: '',
+        checkbox: 'me-2',
+      },
+      sortBy: ['name:asc', 'count:desc'],
+    }),
+  ]);
+
+  // function handleSearchTermClick(event) {
+  //   const searchBox = document.querySelector('#search-box input[type=search]');
+  //   search.helper.clearRefinements();
+  //   searchBox.val(event.currentTarget.textContent);
+  //   search.helper.setQuery(searchBox.val()).search();
+  // }
+
+  // search.on('render', function () {
+  //   // Make artist names clickable
+  //   // $('#hits .clickable-search-term').on('click', handleSearchTermClick);
+  //   document.querySelectorAll('.hit-url a').forEach((el) => {
+  //     el.addEventListener('click', handleSearchTermClick);
+  //   });
+  // });
+
+  search.start();
+};
+
+typeSenseInstantSearch();
+
+// export function onRouteDidUpdate({ location, previousLocation }) {
+//   // Don't execute if we are still on the same page; the lifecycle may be fired
+//   // because the hash changes (e.g. when navigating between headings)
+//   if (location.pathname === previousLocation?.pathname) return;
+//   typeSenseInstantSearch();
+// }
diff --git a/src/typesenseInstantSearchInit.js b/src/typesenseInstantSearchInit.js
new file mode 100644
index 0000000..6dc7354
--- /dev/null
+++ b/src/typesenseInstantSearchInit.js
@@ -0,0 +1,180 @@
+/**
+ * @file This file creates the DOM elements for the Typesense search box and search results. The DOM elements for the search hits are in the main Typesense InstantSearch plugin code.
+ * @author Kor Dwarshuis
+ * @version 1.0.0
+ * @since 2023-05-19
+ */
+
+import paths from "../paths";
+
+const typesenseInstantSearchCreateDomElements = () => {
+    const domStringSearchStart = ``;
+    const domStringSearchResult = `
+
+  `;
+
+    // Add search to dom
+    if (document.querySelector('#search') === null) {
+        document
+            .querySelector('body')
+            .insertAdjacentHTML('afterbegin', domStringSearchResult);
+    }
+
+    // TODO: find out why check for null does not work
+    // if (document.querySelector('#search-start') === null) {
+    if (document.querySelector('#search-start')) {
+        document.querySelector('#search-start').remove();
+    }
+    document
+        .querySelector('body')
+        .insertAdjacentHTML('beforeend', domStringSearchStart);
+    // }
+
+
+    /*
+       TIMESTAMP   
+ 
+       The code below Fetches HTML content from indexed-in-KERISSE on this same domain using the `fetch` API.
+       
+       It then parses the fetched HTML using `DOMParser` and queries the DOM to find a paragraph element with the id "index-created-timestamp-source".
+       
+       If the element is found, its text content is added to the search result page; otherwise, an appropriate message indicating the absence of such an element is logged.
+    */
+
+    // Fetching the HTML content
+    fetch(paths.indexedInKERISSE, {
+        headers: {
+            'Cache-Control': 'no-cache',
+            'Pragma': 'no-cache',
+            'Expires': '0'
+        }
+    })
+        .then(response => response.text())
+        .then(html => {
+            // Parsing the fetched HTML string into a DOM object
+            const parser = new DOMParser();
+            const doc = parser.parseFromString(html, 'text/html');
+
+            // Finding the paragraph elements by their id's
+            const timestampElement = doc.querySelector('#index-created-timestamp-source');
+            const pageCountElement = doc.querySelector('#index-created-page-count-source');
+
+            if (timestampElement) {
+                // Extracting and logging the content of the paragraph
+                const timestampContent = timestampElement.textContent;
+                document.querySelector('#index-created-timestamp-target-search-modal').textContent = timestampContent;
+            } else {
+                console.log('Element with id "index-created-timestamp-source" not found.');
+            }
+
+            if (pageCountElement) {
+                // Extracting and logging the content of the paragraph
+                const pageCountContent = pageCountElement.textContent;
+                document.querySelector('#index-created-page-count-target-search-modal').textContent = pageCountContent;
+            } else {
+                console.log('Element with id "index-created-page-count-source" not found.');
+            }
+        })
+        .catch(error => {
+            console.error(`Error fetching the content: ${error}`);
+        });
+    // END TIMESTAMP
+
+
+
+};
+
+typesenseInstantSearchCreateDomElements();
+
+// export function onRouteDidUpdate({ location, previousLocation }) {
+//     // Don't execute if we are still on the same page; the lifecycle may be fired
+//     // because the hash changes (e.g. when navigating between headings)
+//     if (location.pathname === previousLocation?.pathname) return;
+//     typesenseInstantSearchCreateDomElements();
+// }
diff --git a/webpack.config.js b/webpack.config.js
new file mode 100644
index 0000000..b02a795
--- /dev/null
+++ b/webpack.config.js
@@ -0,0 +1,44 @@
+const path = require('path');
+const CopyWebpackPlugin = require('copy-webpack-plugin');
+const MiniCssExtractPlugin = require('mini-css-extract-plugin');
+
+
+module.exports = {
+    // entry: './src/typesenseInstantSearchInit.js', // Your main JavaScript file
+    entry: {
+        main: './src/typesenseInstantSearchInit.js', // Your existing main JavaScript file
+        additional1: './src/typesenseInstantSearch.js', // Path to your additional JS file
+        // additional2: './src/typesenseHandleSearchModal.js', // Path to another additional JS file
+    },
+    output: {
+        filename: '[name].bundle.js', // Generates main.bundle.js, additional1.bundle.js, etc.
+        path: path.resolve(__dirname, 'dist'), // Directory for the bundled file
+    },
+    devServer: {
+        static: './dist', // Folder to serve files from
+        hot: true, // Enable hot module replacement
+    },
+    module: {
+        rules: [
+            {
+                test: /\.css$/, // Matches any CSS file
+                // use: ['style-loader', 'css-loader'], // Processes CSS files
+                use: [MiniCssExtractPlugin.loader, 'css-loader']
+            },
+        ],
+    },
+    plugins: [
+        new CopyWebpackPlugin({
+            patterns: [
+                { from: 'index.html', to: './' }, // Adjust the 'from' path as necessary
+                { from: 'indexed-in-KERISSE.html', to: './' }, // Adjust the 'from' path as necessary
+                { from: 'src/custom.css', to: './custom.css' },
+
+            ]
+        })
+        // ,
+        // new MiniCssExtractPlugin({
+        //     filename: '[name].css',
+        // })
+    ],
+};
\ No newline at end of file