Skip Ribbon Commands
Skip to main content
Sign In

EBA consultation on RTS for prudential treatment of software assets

EBA consultation on RTS for prudential treatment of software assets

​​ESBG (European Savings and Retail Banking Group)

Rue Marie-Thérèse, 11 - B-1000 Brussels

ESBG Transparency Register ID 8765978796-80

June 2020 

Published online: 9 July 2020

>> See .pdf version

ESBG would like to thank you for the opportunity to share with you our comments on the pruden-tial treatment of software. In today’s digital era, the main mission is to achieve a level playing field, preserve fair competition and advance technological innovations and digitalization in the financial (banking) sector. Furthermore, banks can be encouraged to foster investment in digital solutions and/or IT systems.

The EBA draft RTS provides some relief when it comes to the capital treatment of software, but it is still far too restrictive and inefficient in comparison to the US/Swiss Model. The prudential treatment of software assets in Europe should not penalize innovation. 

At the same time, banks need flexibility in cases where the benefits do not compensate the cost, Therefore, an option to not apply the RTS would be welcomed by certain institutions. This may lead to situations where implementation of the new approach will not be completely supported and continuation of complete deduction of the software from CET 1 would be preferred instead. If the RTS is too burdensome a possibility to opt out and not apply, it may become important for some financial institutions. The exemption rule for avoiding capital deduction could be optional for institutions that have hardly any software assets capitalized – the cost of implementing the pru-dential amortization approach would be disproportionate to the capital savings. The institutions in question could therefore have the option of continuing to deduct the software assets in full from CET 1.  

Another possibly not very well accepted point is the proposed time period for the prudential amor-tization which is deemed extremely short.

​Question 1: In case some software assets are classified within tangible assets in your institution, what are the main reasons for doing so and what is the percentage of this classification com-pared with the classification as intangible?

Answer: 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 corre-sponding hardware, it does not constitute an intangible asset in itself. IAS 38 is therefore not rele-vant. 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 re-spective 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?

​Answer: Although we acknowledge the steps taken to provide some relief when it comes to capital treat-ment of software, this new approach might be for some institutions – especially for small and me-dium-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 pro-vides some relief when it comes to capital treatment of software, it is still too restrictive and ineffi-cient in comparison with the US/Swiss Model (where 100% recognition and 0% deduction is fore-seen). 

The period proposed for prudential amortisation 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 amortisation period, even in resolution (see answer to Question 3).

Question 3: What is your view on the calibration of the prudential amortization period?

Answer: 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 re-flected 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 fulfils 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 amortiza-tion 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 ei-ther IFRS and/or local GAAP. 

In the light of the abovementioned, 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 amortisation period has been set at 2 years due to the evidence col-lected. 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 amortisation 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 institu-tions introduces a bias to underestimate the conservative value of the software in case of resolu-tion. It has to be taken into account that the resolution strategy plays an important role in deter-mining the prudential amortisation 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?

Answer: In both cases, the creation of a subledger 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 amortiza-tion periods increases complexity and requires additional IT and system efforts from banks.

Other members support the use of option B, i.e. the supervisory amortisation 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.

Answer: 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 favourable capital treatment of software assets. By doing so, the playing field will be levelled 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 pru-dential amortisation treatment between (i) assuming the capitalization 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 de-ducting from CET1 items the costs capitalised until this date is (i.e. Option B illustrated in this CP) .

Answer: 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.

Answer: 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 option-al (opt-out) for certain institutions, as we mentioned in the introduction. For institutions that have hardly any software assets capitalised, the cost of implementing the prudential amortisation ap-proach 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 publica-tion 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 provi-sions 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 con-sultation 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. 

​About ESBG (European Savings and Retail Banking Group)

​ESBG represents the locally focused European banking sector, helping savings and retail banks in 21 European countries strengthen their unique approach that focuses on providing service to local communities and boosting SMEs. An advocate for a proportionate approach to banking rules, ESBG unites at EU level some 900 banks, which together employ more than 650,000 people driven to inno-vate at roughly 50,000 outlets. ESBG members have total assets of €5.3 trillion, provide €1 trillion in corporate loans (including to SMEs), and serve 150 million Europeans seeking retail banking services. ESBG members are committed to further unleash the promise of sustainable, responsible 21st centu-ry banking. Our transparency ID is 8765978796-80.


European Savings and Retail Banking Group – aisbl

Rue Marie-Thérèse, 11 ■ B-1000 Brussels ■ Tel: +32 2 211 11 11 ■ Fax : +32 2 211 11 99 ■

Published by ESBG. June 2020

Accounting Standards; Accountancy; European Supervisory Authorities (EBA-ESMA)