Response to consultation Paper on Draft Regulatory Technical Standards on the prudential treatment of software assets
Go back
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 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 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 foreseen).
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 software, the ability to use it, how it will generate probable economic benefits, the availability of resources and the ability to measure the expenditures reliably. By taking into consideration that plenty 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 abovementioned, we strongly oppose the proposed short amortization timeline (2 years) and request longer time period (4 years).
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.
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.
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.
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).
In addition, according to the latest EBA statements as well as the EBA letter from 12th June to the EU Commission 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 light of the short consultation period as well as the CRR Quick Fix, we would like to express 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 would not 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?
None of the software assets area classified as tangible assets; the computer software of major banking groups in Austria is classified as intangible assets with useful live 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 paper would be appreciated.
Question 2: Do you have any comment on the proposed approach for the prudential treatment of software assets?
The proposed approach is in our view burdensome and not cost-efficient as it requires banks to calculate in future two different amortizations: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 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 foreseen).
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 type 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 the 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 software, the ability to use it, how it will generate probable economic benefits, the availability of resources and the ability to measure the expenditures reliably. By taking into consideration that plenty 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 abovementioned, we strongly oppose the proposed short amortization timeline (2 years) and request longer time period (4 years).
Question 4: What is your view on the proposed alternative approaches illustrated above?
Option B can result in a very high CET1 deduction especially at the beginning of the amortization period in contrast to a comparable 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.
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.
Question 5: If considered needed, please provide any complementary information regarding the costs and benefits from the application of these draft RTS.
n.a.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) .
n.a.Question 7: Please provide any additional comments on the Consultation Paper.
The Consultation Paper is too technical and we do not support 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.
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).
In addition, according to the latest EBA statements as well as the EBA letter from 12th June to the EU Commission 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 light of the short consultation period as well as the CRR Quick Fix, we would like to express 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 would not allow for a fast relief for banks.