Primary tabs

German Banking Industry Committee

The reason is the mandatory compliance with IAS 16 in conjunction with IAS 38.4, provided that the software is an integral part of the hardware. In addition, pursuant to IAS 38.8 there is an intangible asset if it is a distinctly identifiable, non-monetary asset devoid of physical substance. However, if an asset combines tangible and intangible elements, it is up to the enterprise to determine which element is to be rated as more important. Now, should a software be identified as an integral element of the related hardware, then per se it does not constitute an intangible asset. IAS 38 is thus not relevant. Rather, the software is in this case not clearly identifiable and separable, but part of the tangible elements and accordingly has to be shown as a tangible fixed asset pursuant to IAS 16 in the balance sheet (as for example BIOS or every other form of firmware).
The implementation of the proposed approach would entail operational hurdles, particularly for small and medium-sized institutions. In practice, these institutions capitalise purchased software. There are hardly any in-house developments and they are rarely capitalised. As a rule, the charging of the related costs is in no proportion to the income (charging/collection of development costs involves a great deal of effort, additional computer resources for accounting, additional audit transparency, etc.). Furthermore, additional parallel accounting would have to be established for the application of the regulatory amortisation approach, which would increase the expenditure further. In accordance with the principle of proportionality, it should also be made possible for these institutions to not have to deduct the software from Common Equity Tier 1 capital. We therefore propose simplification in the identification of possible software assets. The fixed assets schedule shows current write-ups to the soft-ware. Small and medium-sized institutions should be allowed to use the write-up amount as a basis for determining the amount of amortisation. The write-up amount would be amortised over the prudential useful life. This eliminates the need for small and medium-sized institutions to identify each piece of software, which would mean considerable relief with regard to operational requirements. These data are already available today.

In addition, for all institutions which based on their own cost/benefit considerations want to waive the implementation of the regulatory amortisation method, the total software deduction from CET 1 should remain an option (see question 7).

According to Art. 13a (4) of the draft of the Amendment Regulation, with software assets purchased by subsidiaries, the date of balance-sheet capitalisation (initial recognition) in the subsidiary’s financial statements (option A) or the date on which they begin to be amortised in the subsidiary’s financial statements (option B) should be applied. We do not follow the rationale of this regulation. The proposal would result in an unreasonably additional effort to analyse the derogative accounting standards and apply them at group level. Hence, in line with the existing methodology, the applicable accounting standards at group level should prevail.
To justify the prudential useful life of 2 years, the EBA makes reference to the studies it conducted . The subject of the studies were in particular takeover (M&A) cases involving shareholdings in institutions in resolution, insolvency and liquidation. There was no exact description of the cases. For these cases, the EBA states for a software migration period of 1 to 3 years. Until then, the software would normally have migrated to the purchaser’s IT systems.

In our view, the 1 to 3 years mentioned by the EBA can mean only average figures. I.e., 1 to 3 years is the average time that is required to migrate the entire software portfolio to the acquiring bank. We do not assume that the EBA’s figures can interpreted as the maximum time span for the software migration process. For our studies and practical experiences have clearly shown that, in the event of a takeover and also liquidation, software continues to be used over a longer period (up to 8 years). In the case of a single takeover, moreover, the useful life of the individual transferred software products is not uniform. With this as a starting point, a basis of 2 years useful life would not be appropriate for prudential purposes. A useful life of 2 years reflects an average useful life of only one year since the impact on own funds decreases linearly (see diagram below). This reason why this is the case is that since at the start of prudential amortisation the impact on CET 1 is very high (100%) and at the end of the two-year amortisation it decreases to zero. That means that on average over both years there is only a 50% CET1 impact. A 100% impact, i.e., a total capital relief, is thus on average effective for only one year. Hence, on average, the result is a one-year useful life.

With an average useful life of one year, the EBA’s proposal would be very conservative and would not be justified by the results of the EBA’s study. For an average useful life of 2 years, the maximum useful life for the prudential amortisation approach would have to amount to 4 years.

(see illustration in the appendix)

Furthermore, a 2-year useful life does not take into account that with the takeover of a resolution case the institution first enters an initial evaluation phase. According to the results of our studies, the difficulties do not begin on the day of the takeover. Rather, they begin with a certain lead time. The actual decision on the resolution or even liquidation is taken at a later point in time. In our example of a liquidation, the decision was not taken until 2 years after the onset of difficulties.

(see illustration in the appendix)

The initial evaluation phase has thus lasted almost 2 years. In view of this, we consider a prolongation of the useful life taking into account an initial evaluation phase appropriate. We would regard an initial evaluation phase of 1 year as sufficiently conservative.

There is also the fact that, in the “normal case”, when preparing the annual financial statements, the legal representatives of an institution have to make a prognosis on the continuation of business activ-ity before the work on the financial statements can be performed under the “going concern” assump-tion. In the evaluation of the “going concern” assumption, the institution’s ability to continue for at least the coming 12 months as a going concern is evaluated. For this, the individual position of the bank and the overall economic circumstances are assessed. The statutory/external auditors must furthermore pass judgment on the evaluation of the legal representatives. So if the annual financial statements are produced on the assumption of a going concern, then for the next 12 months there is a very high probability that the institution will continue operating during this time. For this period, we assume a recoverable value for the software. We therefore consider an extension of the useful life of at least 1 year for prudential purposes advisable.

At the time of difficulties, there is software that for regulatory purposes would have to be deducted from Common Equity Tier 1 capital, although it is needed in a time of difficulty and does serve the bank. Hence, a period of at least 3 years should be set for regulatory useful life, which in our view would also be prudentially justifiable.

A shorter regulatory useful life of two years would – as noted by the EBA itself – otherwise have nega-tive effects on large software and IT investments, which should basically contribute to strengthening competition and resilience of the EU banking sector. In addition, those institutions would be disadvan-taged that had already early on invested in software and thus in leading market development in order to for example stay competitive vis à vis the fintechs. With a short useful life, these institutions could no longer profit from the capital relief.
We would argue very strongly for the application of Option B, i.e., prudential amortisation should begin concurrently with accounting amortisation in the balance sheet.

In both cases the establishment of a subledger/parallel accounting is necessary. Here, option A and B differ in the expected cost of implementation. The data points necessary for option B (original book value, current book value, start of amortisation) are today already available in the institutions.

This would, moreover, mean a better comparability of accounting / FinRep. A deviation between the regulatory and accounting start of amortisation would involve a great deal of effort for the institutions and would unnecessarily increase the complexity of the provision. The proposed total capital deduc-tion prior to implementation of the software, however, should be dropped. In line with accounting regulations, the capital deduction should not begin until the start of accounting amortisation in the balance sheet. The recoverable value of the assets will be confirmed by the statutory/external auditor as part of the audit opinion prior to rollout.
In our view, the relief for the institutions from option 4 is overestimated. Figure 6 indicates relief of between 19.8 b.p. and 22.4 b.p. in the CET 1 ratio. The comparison calculations by our institutions arrive at mainly lower relief figures. In the QIS data used in the analysis there were, in our opinion, no data queried of the volume of assets under construction. In option B, these must be further deducted at 100% from CET 1. In practice, assets under construction have a tangible portion of the total and the result of a total deduction is that the effect for option B from our point of view was overestimated. Hence, in order to reduce the disadvantage for EU institutions a less conservative calibration is necessary.
As a rule, the institutions do not have the necessary data to prepare a comparative calculation for option A available in analysable form and depending in part on the software would have to be effortfully collected. Hence, it is not possible to provide any information on this in the near term. To enable a timely implementation of the regulation, it is for this reason too that we clearly voice our support for the application of option B.
We advocate that the provision to avoid capital deduction should be structured as an option for institutions. For institutions that have hardly capitalised software the implementation of the regulatory amortisation approach would bear no reasonable relation to the capital relief. The institutions in question should thus continue to be allowed to fully deduct software assets from their CET 1.
German Banking Industry Committee