Group 1 · fields 7–24
Identifies who is filing the report, which authority is receiving it, and who to contact for follow-up. These fields establish the administrative frame for the incident report.
1.1 Reporting Entity
The full legal registered name of the entity submitting the report. Use the entity's official name as registered with its domestic regulator or in its jurisdiction of incorporation — not a trading name or abbreviation.
For a branch reporting on behalf of a foreign parent, this should be the name of the legal entity that is the subject of the regulatory relationship, not the branch name.
One or more globally recognised identifiers for the reporting entity. Each entry is a key-value pair where the key is the identifier type and the value is the identifier string.
The preferred global identifier is the Legal Entity Identifier (LEI). Other accepted types include BIC (Bank Identifier Code) and ISIN where applicable. Including an LEI significantly aids cross-border identification and data matching by receiving authorities.
Example: {"LEI": "ABCDE12345FGHIJ67890"}
One or more identifiers assigned by a domestic regulatory authority. Each entry is a key-value pair where the key is the identifier type (typically including the issuing authority) and the value is the identifier string.
Examples include firm reference numbers, registration numbers, or other domestic identifiers issued by the receiving authority. Including local identifiers helps the receiving authority match the report to its internal records for the entity.
If the reporting entity is a subsidiary or branch within a larger group, the full legal name of the ultimate parent entity at the top of the ownership chain. This provides context for incidents that may have group-wide implications.
Leave blank if the reporting entity is itself the ultimate parent, or if the entity does not form part of a group structure.
The classification(s) of the reporting entity's type — for example, bank, insurance company, investment firm, payment service provider, or financial market infrastructure. An array is used because entities may hold multiple licence types or classifications.
The accepted values for entity type are defined by the implementing authority. Each key-value pair typically identifies both the classification scheme (key) and the specific type (value).
The ISO 3166-1 alpha-2 country code for the jurisdiction in which the reporting entity is incorporated or primarily established. For branches, this is typically the country of the branch's host jurisdiction rather than the parent's home country.
This field helps receiving authorities contextualise the entity's regulatory environment and map it to existing supervisory records.
1.2 Receiving Entity
One or more identifiers for the authority or authorities to whom this report is being submitted. Each entry is a key-value pair identifying the receiving authority using a scheme agreed between the submitting entity and the authority.
This field allows a single FIRE report to be addressed to multiple recipients, and enables automated routing and processing by intermediary systems.
A record of authorities that have previously received earlier versions of this report. Used to maintain an audit trail of which authorities have received which versions, particularly when reports are updated or forwarded between authorities.
Used when a report is being forwarded by one authority to another — identifies the authority that is forwarding the report (not the original submitting entity). Populated by the forwarding party, not by the original submitting institution.
This field is marked Not Collected in institution-initiated reporting. It is populated only in authority-to-authority forwarding scenarios.
Used when a report is being forwarded by one authority to another — identifies the intended final recipient(s) of the forwarded report. Populated by the forwarding authority.
Like field 15, this is Not Collected in institution-initiated reporting and is only populated in authority-to-authority forwarding scenarios.
1.3 Contact Details
A container that groups one or more contact person records. Each contact record within this container uses fields 18–24. At minimum, each contact entry must include contact type (field 18), contact name (field 19), and contact email (field 20).
At least one contact must be provided. Multiple contacts may be supplied — for example, a primary point of contact and a technical contact. The contact type field (18) distinguishes between contact roles.
Classifies the role of the contact person within the entity. Receiving authorities use this to route follow-up queries to the appropriate person — for example, directing technical questions to a technical contact rather than the primary business contact.
The accepted enumerated values for contact type are determined by the implementing authority. Typical types include primary contact, technical contact, management contact, and legal contact.
The full name of the contact person. Use the person's full legal or professional name as they would expect to be addressed in formal correspondence.
The email address of the contact person. Must be a valid email address in standard format. This is the primary channel through which the receiving authority will make follow-up contact, so it should be a monitored mailbox — not a generic or unmonitored address.
For ongoing incidents, consider whether the contact's email will remain accessible during a major incident (e.g., if email systems are affected).
The telephone number of the contact person, formatted in E.164 international format — a plus sign followed by the country code and number with no spaces or punctuation (e.g., +442071234567).
This should be a number at which the contact can actually be reached during an incident — ideally a direct line or mobile, not a general switchboard.
The contact person's job title or functional role within the entity — for example, "Chief Information Security Officer", "Head of Operational Resilience", or "Incident Response Lead". Provides context for the contact's authority and expertise.
The department, team, or business unit the contact person belongs to — for example, "Group Cyber Security", "Technology Risk", or "Operational Resilience". Helps route correspondence to the correct internal team.
Where a report is addressed to multiple recipients (field 13), this field specifies which recipient(s) a particular contact is associated with. This allows the reporting entity to designate different contacts for different receiving authorities — for example, a domestic regulator contact and a cross-border authority contact.
Leave blank if the same contact applies to all recipients or if only one recipient is listed.