OPRISK View Description

# OPRISK View Description ### Overview The Operational Risk event data represents a materialized view of the event database constructed for the flexible management of different event categories including Operational Risk events, Credit Risk events, Corporate Actions and National Security events. This database maintains: * The association of different event types and categories, such as a money laundering event is a Basel / OpRisk event * Required and mandatory meta information that is associated with an instance of an event such as the requirement for associating business line information with operational risk events * Information on the entities and roles associated with an event. For example a Fraud event will likely include the defrauded institution as well as the fraudster, means of fraud (e.g. forgery), locationa and date information. * Narrative data. A narrative is a mechanism for associating events together as they occur over time into a tapestry that relates the event story line.` * Multiple management and quality control tables involved in the event production cycle` A representative entity relationship diagram of the Event Database schema is provided below to support conversations on modifying the materialed view and/or bypassing the view compeletly and having direct access to richer event data tables (A 4th quarter objective) ![](https://i.imgur.com/Ww2Fvx1.png) ### Operational Risk Event Table: Field Description The data in the (OR)Event materialized view are described below. The fields reflect discussions that have with Forge.AI over the POC and reflect the POC file define. Changes are currrently being tested for including additions that have been requested in the Event Feed Structure Requirements document. 1. **EVENTID** (NUMBER) The EVENT is a machine generated unique id for the event. 3. **PARENTID** (NUMBER) The PARENTID field is used to group events together. When non-zero, the PARENTID represents the event ID of the initial event in the group. 4. **COMPANYNAME** (VARCHAR) The COMPANYNAME is the NLP extracted text of the organization associated with the OpRisk event. 5. **COMPANYURI** (VARCHAR) The COMPANYURI is a Forge.AI unique identifier for the entity. Internally this ID is associated with additional information on the entity such as CIK, CUSIP, ISIN, SEDOL, LEI, address information, ownership information, Industry data , Sector data etc. 6. **CUSIP** (VARCHAR) The CUSIP field was initially intended t be populated with the company's CUSIP. Since not all companies have CUSIPs this field is now populated with either the CUSIP, LEI, ISIN, SEDOL or CIK for the company. If the value is not a cusip then it is prefixed with the identifier type (eg LEI: E56...). If it is a CUSIP there is no prefix. 7. **INDUSTRY**(VARCHAR) The toplevel industry group for the entity. 8. **GEOGRAPHY** (VARCHAR) The location associated with the event as extracted from the document containing the event. 9. **BISLEVEL1** (VARCHAR) ORMA Risk Category Level 1 for the event. The set of possible BIS values have been provided by the customer. 10. **BISLEVEL2** (VARCHAR) ORMA Risk Category Level 2 for the event. The set of possible BIS values have been provided by the customer. 11. **BISLEVEL3**(VARCHAR) ORMA Risk Category Level 3 for the event. The set of possible BIS values have been provided by the customer. 12. **BUSINESSLINE**(VARCHAR) Business Unit level 1 that is associated with the event. The set of possible values have been provided by the customer. 13. **SUBBUSINESSLINE**(VARCHAR) Business Unit level 2 that is associated with the event. The set of possible values have been provided by the customer.provided by the customer. 14. **IMPACTTYPELEVEL1**(VARCHAR) Impact type level 1. The set of possible values have been provided by the customer. 15. **IMPACTTYPELEVEL2**(VARCHAR) Impact type level 1. The set of possible values have been provided by the customer. 16. **AMOUNT**(FLOAT) When populated, this value represents either the event related amount such as the fraud amount, the amount laudered, etc. or the imposed fine/penalty amount. The AMOUNTDESCR field identifies the meaning of the AMOUNT. 17. **AMOUNTDESCR**(VARCHAR) The text description of the AMOUNT such as "Fine amount", "Defrauded amount", etc. 18. **CURRENCY**(VARCHAR) The ISO 4217 currency abbreviation for to be used for interpreting the AMOUNT field (Note: work is in process to normalize this to a common currency.) 19. **ACCOUNTINGDATE** (TIMESTAMPTZ) If inferred date that the monetary impact of the event would have been recorded by the affected company. 20. **ACCOUNTINGDATEDESCR**(VARCHAR) A text description providing guidance on interpreting the ACCOUNTINGDATE field. sample values include "Fine date", "Robbery date", "Lawsuit settlement date", etc. 21. **DOCSUMMARY**(VARCHAR) The extracted summary of the document. (see EVENTSECTIONTEXT) 22. **OCCURDATESTART** (TIMESTAMPTZ) When the source document identifies the start period for an event or an end period for an event the OCCURDATESTART and OCCURDATEEND fields are populated. The values are represented in the database as timestamps, containing the year, month, day, hour, minute, second and milliseconds. * If the document only refers to the year when an event occurred, the OCCURDATESTART value is entered as January 1'st of the indicated year with the timestamp of 00:00:00. The OCCURDATEEND is populated with the value representing December 31'st of the indicated year with a timestamp of 23:59:59 * If the document only has the month for the start of the event, then the OCCURDATESTART is recorded as the first day of the indicated month with a timestamp of 00:00:00. * If the document only has a month for the end date of the event, then the OCCURDATEEND is recorded as the last day of the indicated month with a timestamp of 23:59:59. * If the document only has the day of the month for the start of the event, then the OCCURDATESTART is recorded as the the indicated day of the month with a timestamp of 00:00:00. * If the document only has the day of the month for the end of the event, then the OCCURDATEEND is recorded as the the indicated day of the month with a timestamp of 23:59:59. 23. **OCCURDATEEND** (TIMESTAMPTZ) When the source document identifies the start period for an event or an end period for an event the OCCURDATESTART and OCCURDATEEND fields are populated. The values are represented in the database as timestamps, containing the year, month, day, hour, minute, second and milliseconds. * If the document only refers to the year when an event occurred, the OCCURDATESTART value is entered as January 1'st of the indicated year with the timestamp of 00:00:00. The OCCURDATEEND is populated with the value representing December 31'st of the indicated year with a timestamp of 23:59:59 * If the document only has the month for the start of the event, then the OCCURDATESTART is recorded as the first day of the indicated month with a timestamp of 00:00:00. * If the document only has a month for the end date of the event, then the OCCURDATEEND is recorded as the last day of the indicated month with a timestamp of 23:59:59. * If the document only has the day of the month for the start of the event, then the OCCURDATESTART is recorded as the the indicated day of the month with a timestamp of 00:00:00. * If the document only has the day of the month for the end of the event, then the OCCURDATEEND is recorded as the the indicated day of the month with a timestamp of 23:59:59. 24. **OCCURDATEDESCR**(VARCHAR) A text description providing guidance on how to interpret the OCCURDATESTART and OCCURDATEEND values. 25. **DISCOVERDATE**(TIMESTAMPTZ) This value represents the date as a database timestamp of when the source document was collected and processed by Forge. 26. **URL**(VARCHAR) The URL to the source document. 27. **TITLE** (VARCHAR) the title from the source document. 28. **NOTES** (VARCHAR) The notes field contains any processing notes for the event. 29. **CONFIDENCE**(FLOAT) The confidence measure is a machine generated measure reflecting the confidence the underlying AI systems had in extracting and resolving the elements associated with the event. This score ranges from 0 to 1. 30. **DOCID** (NUMBER) The docid field contains identifying information for the document in the Forge cloud data warehouse, Anvil. The value represents the internal value that Forge generates for each document we process. Using this value you can view all the information Forge has extracted and calculated for the underlying document including the sentiment, entities, entity saliencies, relationships, summary information, etc. 31. **EVENTSECTIONTEXT** (VARCHAR) The EVENTSECTIONTEXT is the identified text section of the document (summary) that reflects the extracted event. 32. **PROCESSDATE** (TIMESTAMPTZ) The PROCESSDATE is the timestamp identifying when the event processing system promoted the extracted information as an OpRisk event. 33. **EVENTSTATUS** (VARCHAR) The EVENTSTATUS field represents the state of the event as described in the underlying document. The possible values are: * Potential: This represents an activity that is expected to occur, such as a lawsuit, or a report of suspicion of fraud. * Ongoing: An event in an ongoing state reflects an activity that has started, but has not completed. * Settled: An event that has completed with financial ramifications is considered settled. * Closed: An event that has completed without any financial ramifications is considered closed. 34. **RELEVANCE**(NUMBER) Relevance is a numeric value identifying how closely connected and impactful the reported event is to the operations of companies in the finance and banking sectors. The score, ranging from 1 to 5 incorporates: * The financial amount associated with the event. * The newness of the event. * The number of times and frequency with which it is being reported. * The regional or global scope of the reporting * The region where the event occurred Current scoring guidelines are: * Score 1: The event is industry relevant(e.g. widespread outage), but not specific to any one bank. * Score 2: The event is bank specific, but there is not widely disseminated information on the event and the value is not declared and estimated to be < $10M US. * Score 3: The event is bank specific, and widely disseminated (seen multiple times from known sources). The value of the event less than $100M US. * Score 4: The event is bank specific and widely disseminated (seen multiple times from known sources). The value of the event is less than $500M US. * Score 5: The event is bank specific, and widely disseminated (seen multiple times from known sources). The value of the event is greater than $500M US. Below is a diagram illustrating the logic that is used in determining the relevance score. ![](https://i.imgur.com/g5ymBqD.png)