Response to consultation Paper on Draft Regulatory Technical Standards on the prudential treatment of software assets
Go back
Generally, the following cases can be distinguished when classifying software items (particularly purchased software licenses) as potentially tangible assets:
i. firmware embedded in hardware, e.g. micrograms, BIOS: This firmware constitutes a program module which is connected to the hardware in order to connect the hardware with the software and to operate the basic functionality. Usually it cannot be deleted. As this software component cannot be separated reasonably from the hardware, it will be classified as tangible asset.
ii. firmware bundled with hardware, e.g. some management tools: This firmware is usually delivered together with hardware. A separate purchase of the software license it not possible. An objective market value cannot be determined. The software license is deeply connected to the hardware and is therefore classified as tangible asset.
In contrast to the aforementioned cases, software sold separately but specific to a hardware, will be classified as intangible asset and recognised separately from the hardware as long as the value of the software does not exceed 10% of the sum of the value of hardware and software, even if the software is only usable with the specific hardware.
Compared to software assets classified as intangible asset, software assets classified as tangible assets constitute just a small fraction. Most software assets within DBG were internally developed and are classified as intangible assets.
Notwithstanding this, we are of the opinion that the approach should stronger differentiate between software assets that cannot be sold separately or where no reliable price can be assessed and such that can be and potentially are sold separately. While we understand EBA’s basic assumption that most software assets will be negatively affected by resolution, insolvency or liquidation and therefore cannot be considered (fully) loss absorbing, the current approach might disadvantage institutions with largely sellable software assets disproportionately.
While we consider the maximum prudential amortisation period of two years as a valuable basis that will be appropriate for balancing the software assets’ loss absorbing capacity and its importance for the business in most cases, it might be unbalanced for software assets that can be or are sold on a market or such with a long operating life. Moreover, strictly limiting the maximum prudential amortisation period to two years will rather create incentives for a continuous improvement of software, as the costs for improving existing software will be recognised respectively every time when capitalised or used. In contrast to this, larger one-off but long-term investments in software assets will be prudentially less attractive.
In order to account for their larger loss absorbing capacity also during liquidation or resolution and to incentivise development of and investment in software further, we suggest allowing for a longer prudential amortisation period for software assets that can be sold separately. Where institutions can demonstrate that selected software assets can be sold separately and where a reliable market price can be determined or is available, a prudential amortisation period of maximum five years should be possible whereas the prudential amortisation period should still be limited by the user life assessed for accounting purposes. EBA could also consider limiting the amount to be prudentially amortised to a fixed percentage of the determined value, as it is the case for software assets under Solvency II.
Moreover, with a maximum prudential amortisation period of two years institutions will not be able to benefit immediately from the capital release, as software assets capitalised more than two years ago will be still fully deducted from CET1, irrespective of whether those are fully written down from an accounting perspective. Extending the maximum prudential amortisation period for specific software assets could therefore promote EBA’s objective to support EU institutions in the context of the current COVID-19 crisis, as institutions could immediately apply the changes in Article 36 (1) (b) CRR and benefit from existing software assets in use.
Considering the current COVID-19 crisis, EBA should further elaborate the possibility to benefit from the capital decrease immediately. We welcome EU’s decision to apply the amended requirement of Article 36 (1) (b) CRR from the date of entry into force of the final regulatory technical standards but doubt that the beneficial treatment will be effective immediately as the current Draft RTS does not allow for prudential amortisation of software assets already in use. We therefore suggest to explicitly allow for a temporary consideration of software assets in use but not yet fully amortised.
Individual institutions are best-placed to assess which option is the most appropriate in light of the current COVID-19 crisis and suits its business model best. Moreover, operational as well as capital related implications resulting from the staring data of prudential amortisation will depend to a large extent also on the current account practice applied and type of software items capitalised. Although a uniform application generally contributes to decreasing potential inconsistencies in the application of regulatory requirements, increases comparability and might facilitate supervision by competent authorities, the principle of proportionality should be applied.
We are of the opinion that both options are sufficiently prudent to account for a potentially limited loss absorbing capacity of software assets, while a uniform application of one option might pose unequal operational burden to institutions and result in varying capital releases, rather relating to the type of software and accounting practice that to the volume and life use of software assets.
In case EBA should not consider integrating an option for institutions to choose the appropriate staring date for prudential amortisation into Article 13a of the Draft RTS, we would like to point out that we slightly favour Option B over Option A. Taking the date of initial recognition of the software (Option A) instead of the date available for use (Option B) wouldn’t lead to any immediate benefit for institutions suffering from the current COVID-19 crisis as existing software would still be fully deducted from CET1.
While we do not regard the classification of software assets as outlined in the BCBS QIS under 5.1 of the accompanying documents as appropriate to balance the potentially conflicting considerations (importance for business vs. loss absorbing capacity of software assets), we are of the opinion that the concept of classifying software assets might be generally beneficial and purposeful. Instead of classifying software assets along their field of use, we suggest classifying software assets according to their expected loss absorbing capacity. To assess software assets’ loss absorbing capacity, the Solvency II requirements could be used. Software assets fulfilling the requirements outlined under Solvency II could be classified as larger loss-absorbing and treated beneficially compared to other software assets.
As outlined as part of our answer to question no. 2, we encourage to re-assess the general and uniform maximum prudential amortisation period for software assets proving to be sold separately with a reliable market price.
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?
Depending on the concrete interconnectedness to or dependency on a specific hardware for its functioning, selected software items will be classified as hardware and therefore considered as tangible assets within DBG.Generally, the following cases can be distinguished when classifying software items (particularly purchased software licenses) as potentially tangible assets:
i. firmware embedded in hardware, e.g. micrograms, BIOS: This firmware constitutes a program module which is connected to the hardware in order to connect the hardware with the software and to operate the basic functionality. Usually it cannot be deleted. As this software component cannot be separated reasonably from the hardware, it will be classified as tangible asset.
ii. firmware bundled with hardware, e.g. some management tools: This firmware is usually delivered together with hardware. A separate purchase of the software license it not possible. An objective market value cannot be determined. The software license is deeply connected to the hardware and is therefore classified as tangible asset.
In contrast to the aforementioned cases, software sold separately but specific to a hardware, will be classified as intangible asset and recognised separately from the hardware as long as the value of the software does not exceed 10% of the sum of the value of hardware and software, even if the software is only usable with the specific hardware.
Compared to software assets classified as intangible asset, software assets classified as tangible assets constitute just a small fraction. Most software assets within DBG were internally developed and are classified as intangible assets.
Question 2: Do you have any comment on the proposed approach for the prudential treatment of software assets?
We fully acknowledge the need of balancing the increasing importance of software assets for financial institutions’ business against the loss absorbency capacity of software assets and consider the concept of prudential amortisation as chosen by EBA as an appropriate and targeted approach. Moreover, we appreciate EBA’s decision to fulfil its mandate by amending the existing RTS on own funds requirements and keep the implementation as well as the supervision of the amended requirements as practical and simple as possible.Notwithstanding this, we are of the opinion that the approach should stronger differentiate between software assets that cannot be sold separately or where no reliable price can be assessed and such that can be and potentially are sold separately. While we understand EBA’s basic assumption that most software assets will be negatively affected by resolution, insolvency or liquidation and therefore cannot be considered (fully) loss absorbing, the current approach might disadvantage institutions with largely sellable software assets disproportionately.
While we consider the maximum prudential amortisation period of two years as a valuable basis that will be appropriate for balancing the software assets’ loss absorbing capacity and its importance for the business in most cases, it might be unbalanced for software assets that can be or are sold on a market or such with a long operating life. Moreover, strictly limiting the maximum prudential amortisation period to two years will rather create incentives for a continuous improvement of software, as the costs for improving existing software will be recognised respectively every time when capitalised or used. In contrast to this, larger one-off but long-term investments in software assets will be prudentially less attractive.
In order to account for their larger loss absorbing capacity also during liquidation or resolution and to incentivise development of and investment in software further, we suggest allowing for a longer prudential amortisation period for software assets that can be sold separately. Where institutions can demonstrate that selected software assets can be sold separately and where a reliable market price can be determined or is available, a prudential amortisation period of maximum five years should be possible whereas the prudential amortisation period should still be limited by the user life assessed for accounting purposes. EBA could also consider limiting the amount to be prudentially amortised to a fixed percentage of the determined value, as it is the case for software assets under Solvency II.
Moreover, with a maximum prudential amortisation period of two years institutions will not be able to benefit immediately from the capital release, as software assets capitalised more than two years ago will be still fully deducted from CET1, irrespective of whether those are fully written down from an accounting perspective. Extending the maximum prudential amortisation period for specific software assets could therefore promote EBA’s objective to support EU institutions in the context of the current COVID-19 crisis, as institutions could immediately apply the changes in Article 36 (1) (b) CRR and benefit from existing software assets in use.
Considering the current COVID-19 crisis, EBA should further elaborate the possibility to benefit from the capital decrease immediately. We welcome EU’s decision to apply the amended requirement of Article 36 (1) (b) CRR from the date of entry into force of the final regulatory technical standards but doubt that the beneficial treatment will be effective immediately as the current Draft RTS does not allow for prudential amortisation of software assets already in use. We therefore suggest to explicitly allow for a temporary consideration of software assets in use but not yet fully amortised.
Question 3: What is your view on the calibration of the prudential amortisation period?
Regarding the starting point for prudential amortisation put up for discussion, we propose to leave both options and include them explicitly in the RTS as an option, whereas institutions should be obliged to ensure continuity across software assets within the prudential amortisation practice. Institutions should be able to select the most appropriate starting date from the options provided, whereas competent authorities should be informed by institutions by a set date about which option they will apply. To avoid discontinuity and any potential arbitrage or circumvention of prudential requirements, institutions should inform their respective competent authority about the intended change in prudential amortisation practice beforehand.Individual institutions are best-placed to assess which option is the most appropriate in light of the current COVID-19 crisis and suits its business model best. Moreover, operational as well as capital related implications resulting from the staring data of prudential amortisation will depend to a large extent also on the current account practice applied and type of software items capitalised. Although a uniform application generally contributes to decreasing potential inconsistencies in the application of regulatory requirements, increases comparability and might facilitate supervision by competent authorities, the principle of proportionality should be applied.
We are of the opinion that both options are sufficiently prudent to account for a potentially limited loss absorbing capacity of software assets, while a uniform application of one option might pose unequal operational burden to institutions and result in varying capital releases, rather relating to the type of software and accounting practice that to the volume and life use of software assets.
In case EBA should not consider integrating an option for institutions to choose the appropriate staring date for prudential amortisation into Article 13a of the Draft RTS, we would like to point out that we slightly favour Option B over Option A. Taking the date of initial recognition of the software (Option A) instead of the date available for use (Option B) wouldn’t lead to any immediate benefit for institutions suffering from the current COVID-19 crisis as existing software would still be fully deducted from CET1.
Question 4: What is your view on the proposed alternative approaches illustrated above?
We generally agree with the approach chosen by EBA out of the options considered for fulfilling its mandate of specifying the application of the amended Article 36 (1) (b) CRR, whereas we also consider elements of Option 2 (CET1 deduction by software type) and Option 3 (alignment with Solvency II categories) as valuable and purposeful to fulfil EBA’s mandate under the consideration of the multiple objectives.While we do not regard the classification of software assets as outlined in the BCBS QIS under 5.1 of the accompanying documents as appropriate to balance the potentially conflicting considerations (importance for business vs. loss absorbing capacity of software assets), we are of the opinion that the concept of classifying software assets might be generally beneficial and purposeful. Instead of classifying software assets along their field of use, we suggest classifying software assets according to their expected loss absorbing capacity. To assess software assets’ loss absorbing capacity, the Solvency II requirements could be used. Software assets fulfilling the requirements outlined under Solvency II could be classified as larger loss-absorbing and treated beneficially compared to other software assets.
As outlined as part of our answer to question no. 2, we encourage to re-assess the general and uniform maximum prudential amortisation period for software assets proving to be sold separately with a reliable market price.