Response to consultation Paper on Draft Regulatory Technical Standards on the prudential treatment of software assets
Go back
Otherwise it is not common among credit institutions to classify software assets within tangible assets, but in such a case the percentage of the software assets classified within tangible assets is less than 10%. For discerning the category of intangible assets some institutions follow a policy that is IAS38 compliant and transparent for both the supervisor and the auditor.
In the case of some of our members, computer software is classified as intangible assets with a useful life of 4-8 years.
Furthermore, we understand that the licenses and patents are included in the term “intangible assets” and therefore fall within the scope of the proposed capital treatment of software. A respective clarification in the final paper would be appreciated.
A) Accounting amortization in line with IFRS or local GAAP regulations
B) Prudential amortization in line with the RTS regulation
Some of the implications are summarized below:
• Another amortization view to be implemented in the IT (next to IFRS and local GAAP rules), consolidation and reporting systems
• Implementation in the IT systems: as banks are nowadays heavily investing into their IT and digitization with almost fully used project and systems capacities, another system/IT change might not be feasible within the next months but will rather be only feasible within a year’s time period, thus resulting in no benefits for banks from software exemption this year but rather at a later stage
• No one useful life fits all: see below question 3
Furthermore, the topic of a level playing field should be mentioned. Whilst the EBA draft RTS provides some relief when it comes to capital treatment of software, it is still too restrictive and inefficient in comparison with the US/Swiss Model (where 100% recognition and 0% deduction is fore-seen).
The period proposed for prudential amortization is extremely short if it is compared with the useful life of the software, that in their opinion should be the key reference to set a reasonable prudential amortization period, even in resolution (see answer to Question 3).
Self-constructed intangible assets are only capitalized if various conditions are fulfilled. Only in case that the bank can demonstrate the technical feasibility and intention of completing the soft-ware, the ability to use it, how it will generate probable economic benefits, the availability of re-sources and the ability to measure the expenditures reliably. By taking into consideration that plenty of expenditures for software are expensed immediately and only a part of total expenditure fulfills the criteria for capitalization, someone could argue that there is already a prudent approach incorporated.
We therefore are still of the opinion that the amortization rules applied for accounting purposes (either IFRS or local GAAP rules) should be followed also with regard to the prudential amortization in order to avoid complexity and also to confirm the trust and reliability in the work of external auditors which audit on an (at least) annual basis the applied amortization rules according to either IFRS and/or local GAAP.
In the light of the above-mentioned, we strongly oppose the proposed short amortization timeline (2 years) and request a longer time period (min. 4 years, ideally 6 years).
According to the explanation given in paragraph 32 of the “Background and rationale” section, the calibration of the prudential amortization period has been set at 2 years due to the evidence collected. However, it has to be noted that also based on that evidence the EBA observed that the useful life of software assets is on average around 6 years.
The evidence on which the EBA bases its conclusions stem from a data collection on software assets of a sample of 64 EU institutions as an extension of the BCBS QIS. But we are aware that only a few institutions provided some information on the amortization period. It shows the lack of representativeness of the data used in the impact assessment. Moreover, in our opinion such data provided by participant institutions are not reliable or comparable given that the instructions were not well understood and they were not applied appropriately. Therefore, we consider that basing the conclusions of the RTS on this source of data is a weakness.
In addition, the fact that most of the institutions noted by the EBA’s assessment are weak institutions introduces a bias to underestimate the conservative value of the software in case of resolution. It has to be taken into account that the resolution strategy plays an important role in deter-mining the prudential amortization period for software assets and most of the European banks consider bail-in as their preferred resolution strategy. In such cases the software is totally in force. Therefore, assuming a 2 year period means that the conservative value of the software is underestimated in case of resolution.
We believe that this period should be extended given that the useful life of software assets is longer (11 or 14 years depending whether it is a critical software asset or not). Setting it at min. 4 years (ideally 6 years) could be an appropriate solution and it would be aligned with the estima-tions for accounting purposes. It will reduce the mismatch between the accounting and prudential treatment of software assets.
Option B can result in a very high CET1 deduction especially at the beginning of the amortization period in contrast to a comparably smaller CET1 deduction in the remaining amortization period.
This option does not bring the intended relief for banks with the exemption of software assets from regulatory deduction especially during the current Covid-19 crisis. Option A deems to be more appropriate but as outlined already above the timing difference for starting of the amortization periods increases complexity and requires additional IT and system efforts from banks.
Other members support the use of option B, i.e. the supervisory amortization should start at the same time as the balance sheet depreciation. Moreover, this would provide better comparability with accounting / FinRep. Any deviation between the regulatory and accounting depreciation starting date would involve a high effort for the institutions and would unnecessarily increase the complexity of the exemption rule.
However, the proposed capital deduction should be dispensed as long as the software has not been put into operation. In line with accounting requirements, the capital deduction should not start until the start of balance sheet depreciation. The recoverability of the assets prior to the start of operation will be confirmed by the auditor in his audit opinion.
Also here, we reiterate the problem with the length of the prudential amortization period, which is capped with 2 years. As stated above, we would prefer a longer time period of at least 4 years (ideally 6 years).
We do not see a simplification but rather a complication having another amortization for prudential purposes. In our view a pragmatic approach is, as stated above, to trust in the work of external auditors and apply the accounting amortization rules for prudential purposes as well.
If regulators want to include a certain margin of conservatism or prudence in the valuation of software assets, an easy to implement haircut on top of the accounting amortization would be the most efficient way for implementation.
Additionally, we advocate that the exemption rule for avoiding capital deduction should be optional (opt-out) for certain institutions, as we mentioned in the introduction. For institutions that have hardly any software assets capitalized, the cost of implementing the prudential amortization approach would be disproportionate to the capital savings. The institutions in question should there-fore have the option of continuing to deduct the software assets in full from CET 1.
Furthermore, we would prefer the RTS to enter into force already on the day following its publication in the OJ (instead of twenty days thereafter; see Article 2 of the Draft RTS on p. 28). This would ensure that banks can apply these provisions as early as possible (as intended by the CRR Quick Fix). Alternatively, we propose a (possibly also retroactive) application of the provisions as of 30 September 2020 and therefore we request such a provision to be added to Article 2.
Finally, according to the latest EBA statements as well as the EBA letter from 12th June to the EU COM addressing the topic of further level 2 text delays, the assessment of responses to this consultation as well as the preparation of the final draft RTS should be finalized between Q3/Q4 2020. This would nevertheless result in an adoption first in Q4 2020 /Q1 2021.
In the light of the short consultation period as well as the CRR Quick Fix, we would like to ex-press the need to prioritize the work on this RTS and faster finalization of the RTS. Otherwise the process would counter the efforts of EU legislators and wouldn’t allow for a fast relief for banks.
Question 1: In case some software assets are classified within tangible assets in your institution, what are the main reasonsfor doing so and what isthe percentage of this classification compared with the classification as intangible?
This is due to the mandatory compliance with IAS 16 in conjunction with IAS 38.4, if the software is an integral part of the hardware. In addition, according to IAS 38.8, an intangible asset exists if it is a clearly identifiable, non-monetary asset without physical substance. If, however, an asset combines tangible and intangible components, it is up to the company to determine which component is to be considered material. If software is identified as an integral part of the corresponding hardware, it does not constitute an intangible asset in itself. IAS 38 is therefore not relevant. Rather, in this case the software is not clearly identifiable and separable, but it is part of the tangible components and must therefore be accounted for as property, plant and equipment in accordance with IAS 16.Otherwise it is not common among credit institutions to classify software assets within tangible assets, but in such a case the percentage of the software assets classified within tangible assets is less than 10%. For discerning the category of intangible assets some institutions follow a policy that is IAS38 compliant and transparent for both the supervisor and the auditor.
In the case of some of our members, computer software is classified as intangible assets with a useful life of 4-8 years.
Furthermore, we understand that the licenses and patents are included in the term “intangible assets” and therefore fall within the scope of the proposed capital treatment of software. A respective clarification in the final paper would be appreciated.
Question 2: Do you have any comment on the proposed approach for the prudential treatment of software assets?
Although we acknowledge the steps taken to provide some relief when it comes to capital treatment of software, this new approach might be for some institutions – especially for small and medium-sized banks – not as cost-efficient as would be expected. This is caused by the fact that the draft RTS requires banks to calculate two different amortizations in the future:A) Accounting amortization in line with IFRS or local GAAP regulations
B) Prudential amortization in line with the RTS regulation
Some of the implications are summarized below:
• Another amortization view to be implemented in the IT (next to IFRS and local GAAP rules), consolidation and reporting systems
• Implementation in the IT systems: as banks are nowadays heavily investing into their IT and digitization with almost fully used project and systems capacities, another system/IT change might not be feasible within the next months but will rather be only feasible within a year’s time period, thus resulting in no benefits for banks from software exemption this year but rather at a later stage
• No one useful life fits all: see below question 3
Furthermore, the topic of a level playing field should be mentioned. Whilst the EBA draft RTS provides some relief when it comes to capital treatment of software, it is still too restrictive and inefficient in comparison with the US/Swiss Model (where 100% recognition and 0% deduction is fore-seen).
The period proposed for prudential amortization is extremely short if it is compared with the useful life of the software, that in their opinion should be the key reference to set a reasonable prudential amortization period, even in resolution (see answer to Question 3).
Question 3: What is your view on the calibration of the prudential amortisation period?
We do not agree with the assumption of one useful life for all software assets as there is a lot of heterogeneity between the types of software assets on a bank-by-bank basis. This is also reflected in our applied IFRS methodology for useful life ranging between 4 to 8 years as well as in the average amortization period by European institutions of around 6 years, as stated on page 11 of the Consultation Paper.Self-constructed intangible assets are only capitalized if various conditions are fulfilled. Only in case that the bank can demonstrate the technical feasibility and intention of completing the soft-ware, the ability to use it, how it will generate probable economic benefits, the availability of re-sources and the ability to measure the expenditures reliably. By taking into consideration that plenty of expenditures for software are expensed immediately and only a part of total expenditure fulfills the criteria for capitalization, someone could argue that there is already a prudent approach incorporated.
We therefore are still of the opinion that the amortization rules applied for accounting purposes (either IFRS or local GAAP rules) should be followed also with regard to the prudential amortization in order to avoid complexity and also to confirm the trust and reliability in the work of external auditors which audit on an (at least) annual basis the applied amortization rules according to either IFRS and/or local GAAP.
In the light of the above-mentioned, we strongly oppose the proposed short amortization timeline (2 years) and request a longer time period (min. 4 years, ideally 6 years).
According to the explanation given in paragraph 32 of the “Background and rationale” section, the calibration of the prudential amortization period has been set at 2 years due to the evidence collected. However, it has to be noted that also based on that evidence the EBA observed that the useful life of software assets is on average around 6 years.
The evidence on which the EBA bases its conclusions stem from a data collection on software assets of a sample of 64 EU institutions as an extension of the BCBS QIS. But we are aware that only a few institutions provided some information on the amortization period. It shows the lack of representativeness of the data used in the impact assessment. Moreover, in our opinion such data provided by participant institutions are not reliable or comparable given that the instructions were not well understood and they were not applied appropriately. Therefore, we consider that basing the conclusions of the RTS on this source of data is a weakness.
In addition, the fact that most of the institutions noted by the EBA’s assessment are weak institutions introduces a bias to underestimate the conservative value of the software in case of resolution. It has to be taken into account that the resolution strategy plays an important role in deter-mining the prudential amortization period for software assets and most of the European banks consider bail-in as their preferred resolution strategy. In such cases the software is totally in force. Therefore, assuming a 2 year period means that the conservative value of the software is underestimated in case of resolution.
We believe that this period should be extended given that the useful life of software assets is longer (11 or 14 years depending whether it is a critical software asset or not). Setting it at min. 4 years (ideally 6 years) could be an appropriate solution and it would be aligned with the estima-tions for accounting purposes. It will reduce the mismatch between the accounting and prudential treatment of software assets.
Question 4: What is your view on the proposed alternative approaches illustrated above?
In both cases, the creation of a sub-ledger is necessary. Option A and B differ, however, in the expected expense for implementation. The data points required for Option B (original book value, current book value, start of depreciation) are already available in the houses.Option B can result in a very high CET1 deduction especially at the beginning of the amortization period in contrast to a comparably smaller CET1 deduction in the remaining amortization period.
This option does not bring the intended relief for banks with the exemption of software assets from regulatory deduction especially during the current Covid-19 crisis. Option A deems to be more appropriate but as outlined already above the timing difference for starting of the amortization periods increases complexity and requires additional IT and system efforts from banks.
Other members support the use of option B, i.e. the supervisory amortization should start at the same time as the balance sheet depreciation. Moreover, this would provide better comparability with accounting / FinRep. Any deviation between the regulatory and accounting depreciation starting date would involve a high effort for the institutions and would unnecessarily increase the complexity of the exemption rule.
However, the proposed capital deduction should be dispensed as long as the software has not been put into operation. In line with accounting requirements, the capital deduction should not start until the start of balance sheet depreciation. The recoverability of the assets prior to the start of operation will be confirmed by the auditor in his audit opinion.
Also here, we reiterate the problem with the length of the prudential amortization period, which is capped with 2 years. As stated above, we would prefer a longer time period of at least 4 years (ideally 6 years).
Question 5: If considered needed, please provide any complementary information regarding the costs and benefits from the application of these draft RTS.
In a growing digital banking environment, it is crucial to facilitate and incentivise banking software development and acquisition in the EU by introducing a more favorable capital treatment of software assets. By doing so, the playing field will be leveled with respect to non-EU banks and FinTechs.Question 6: If considered material, please provide your own estimate on the difference in the impact of prudential amortisation treatment between (i) assuming the capitalisation date of software assets as the starting point for prudential amortisation (ie. Option A illustrated in this CP) and (ii) assuming the date of accounting amortisation as the starting point for prudential amortisation, but fully deducting from CET1 items the costs capitalised until this date is (i.e. Option B illustrated in this CP) .
As already outlined in our statement at question 4, it is undisputed that option A results in a higher initial CET1 benefit. However, bearing in mind that a different starting point from the accounting amortization leads to another operational burden, option B would be preferred by some banks.Question 7: Please provide any additional comments on the Consultation Paper.
The Consultation Paper is too technical and we do not share the statements on page 31 which point out that the revised prudential treatment shall be simple to implement and applicable in a standardized manner.We do not see a simplification but rather a complication having another amortization for prudential purposes. In our view a pragmatic approach is, as stated above, to trust in the work of external auditors and apply the accounting amortization rules for prudential purposes as well.
If regulators want to include a certain margin of conservatism or prudence in the valuation of software assets, an easy to implement haircut on top of the accounting amortization would be the most efficient way for implementation.
Additionally, we advocate that the exemption rule for avoiding capital deduction should be optional (opt-out) for certain institutions, as we mentioned in the introduction. For institutions that have hardly any software assets capitalized, the cost of implementing the prudential amortization approach would be disproportionate to the capital savings. The institutions in question should there-fore have the option of continuing to deduct the software assets in full from CET 1.
Furthermore, we would prefer the RTS to enter into force already on the day following its publication in the OJ (instead of twenty days thereafter; see Article 2 of the Draft RTS on p. 28). This would ensure that banks can apply these provisions as early as possible (as intended by the CRR Quick Fix). Alternatively, we propose a (possibly also retroactive) application of the provisions as of 30 September 2020 and therefore we request such a provision to be added to Article 2.
Finally, according to the latest EBA statements as well as the EBA letter from 12th June to the EU COM addressing the topic of further level 2 text delays, the assessment of responses to this consultation as well as the preparation of the final draft RTS should be finalized between Q3/Q4 2020. This would nevertheless result in an adoption first in Q4 2020 /Q1 2021.
In the light of the short consultation period as well as the CRR Quick Fix, we would like to ex-press the need to prioritize the work on this RTS and faster finalization of the RTS. Otherwise the process would counter the efforts of EU legislators and wouldn’t allow for a fast relief for banks.
Upload files
425.pdf
(616.15 KB)