Skip to content

626 add securitisation attributes to the security schema#627

Merged
muratabur merged 11 commits intomasterfrom
626-add-securitisation-attributes-to-the-security-schema
Mar 27, 2026
Merged

626 add securitisation attributes to the security schema#627
muratabur merged 11 commits intomasterfrom
626-add-securitisation-attributes-to-the-security-schema

Conversation

@GGschwendtner
Copy link
Copy Markdown
Contributor

Note: added all required values in the securitisation_type fields, duplicating them for sts and sts qualifying for a differientated capital treatment in order to populate the C14.00 and C13.01 correctly. The documentation may be confusing as a result.
I still think it might be clearer to map the sts types to a new sts_type attribute with 2 values : sts (not qualifying), sts_qualifying and None or non_sts for non-sts. This would allow to reduce the number of values in securitisation_type to the 6 basic types and remove sts as it is not a securitisation type per se. However removing the exisiting sts entry would cause various bits of code in reports and unit tests to fail.

By the way I think that a pass_through is not a securitisation type, but a security type. All securitisations are pass-through by definition. A pass-through security is a classic US RMBS / CMO. Could have been another security type in my opinion.

@GGschwendtner GGschwendtner linked an issue Mar 9, 2026 that may be closed by this pull request
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The "securitisation_id" is just a generic internal id for a securitisation, but could be something else too and also "unique_id" sounds very generic now in the wider project, even though it is very specifically this Article 11 securitisation id.

So maybe we call "securitisation_id" > "internal_id" and this "unique_id" > "securitisation_id" ?

Then the internal_id could be reasonably used for other products and purposes and the securisitation id is nice and specific. does that make sense?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Three identifiers need to be reported for a securitisation, with the following definitions as per the ITS:

  • INTERNAL CODE: Internal (alpha-numerical) code used by the institution to identify the securitisation.
    The internal code shall be associated to the identifier of the securitisation transaction.
  • UNIQUE IDENTIFIER: For securitisations issued on or after 1 January 2019, institutions shall report the unique identifier as defined in Article 11(1) of Commission Delegated Regulation (EU) 2020/1224.
  • IDENTIFIER OF THE SECURITISATION: Code used for the legal registration of the securitisation transaction or, if not available, the name by which the securitisation transaction is known in the market, or within the institution in case of an internal or private securitisation. Where the International Securities Identification Number -ISIN- is available (i.e. for public transactions), the characters that are common to all tranches of the securitisation shall be reported in this column

For INTERNAL CODE, we could use id
For IDENTIFIER OF THE SECURITISATION, we can use deal_id.
For UNIQUE IDENTIFIER, I agree that unique_id is quite generic but its value shall specfically comply with art. 11(1) if the securitisation is issued after 1 Jan 2019. Otherwise, it could be left empty I guess. Shall we use securitisation_id?

muratabur

This comment was marked as duplicate.

@muratabur muratabur merged commit 04f97f7 into master Mar 27, 2026
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add securitisation attributes to the security schema

2 participants