Similarly, in some jurisdictions may be constraints on the usage for supervisory purposes of data obtained from sources other than the CR, especially if such data is to be used for taking specific supervisory actions and/or making other specific policy decisions. Indeed, some central banks and other financial supervisors are bounded by legislation or regulations and can only take specific supervisory actions and decisions based on the information available at the CR or at other credit databases they themselves operate. When it comes to cross-border lending activities, micro-prudential supervisors may not be able to obtain and use credit data available in foreign CRs or other CRSPs. This is often the case when a Memorandum of Understanding (MOU) or other mechanism to facilitate cross-border data exchanges has not been agreed between central banks or between other supervisory authorities, and/or between private sector operators of CBs and CCRCs. At present, a number of relevant private and public sector initiatives are underway to address the difficulties in cross-border data exchanges. At the operational level, to be able to use the data effectively it is highly important that the CR have the functionalities that supervisors require, together with a robust technological infrastructure supporting it. For example, even if the CR has comprehensive and high quality data, supervisors may be unable to exploit such data fully if the CR system itself has limited reporting tools and/or is not supported with adequate data warehousing tools. In cases like this, regular reports tend to be not comprehensive enough and the CR lacks flexibility to make adjustments to such reports. Likewise, it may be difficult for the CR to produce robust ad-hoc reports in a timely manner. These operational problems tend to be amplified as the size of the database increases. These operational problems are not exclusive to CRs. CBs and/or CCRCs may also have limited functionalities with regard to reporting data back to users – in this specific case the supervisors - regardless of the amount and quality of the data available in them.
Highly sophisticated analytical techniques for use in financial sector regulatory and supervisory tasks, both from the micro- and macro-prudential perspectives, continue to emerge. These are allowing financial sector authorities to enhance the depth of the various analyses they perform on either a regular or ad hoc basis, as well as to look at potential problems in financial institutions from new angles. Many of these newer techniques require significant and growing amounts of granular credit data, with individual- and/or household-level data being used in some cases. Key challenges: The ever-growing and increasingly complex data of financial sector authorities require a higher degree of readiness by CRSPs, especially with regard to ensuring seamless and timely reporting of the relevant data to the authorities. A higher degree of readiness by CRSPs should not have significant implications on costs and overall efficiency. CRSPs should aim at fully observing General Principle 2, in particular the guidelines on reliability and efficiency. The newer analytical techniques being used by financial sector authorities and also the eventual necessity these authorities may have to act in the market place in a timely manner and based on the most actual circumstances require credit data in CRSPs to be updated more frequently. and data providers should strive at fully observing General Principle 1, in particular as regard the guidelines on timeliness of data and on accuracy of data. Financial sector authorities need to be transparent on the use or intended use of granular credit data collected from CRSPs, in particular when sensitive or potentially sensitive data on individuals/households is involved (e.g., data on an individual’s income, or data used to derive a proxy of an individual’s income). Financial sector authorities should disclose the relevant policy objectives along with the specific purposes for which they are collecting sensitive