"MiFID demands some transactions (that were once reported on a monthly basis) must now be reported within minutes."

To achieve increased investor protection and transparency, MiFID II requires more detailed and immediate transaction reporting. In some cases, transactions that were once reported on a monthly basis must now be reported within minutes.

The challenge facing most organisations is that their existing infrastructure was not designed to cater to modern regulations.

A detail as small as inconsistent data IDs can create a significant stumbling block. To get around the obstacles, developers are writing new code and even creating systems on top of systems. This will get their organisations to the go-live dates, but what will happen after that? Transaction volume can be expected to spike unexpectedly. Unforeseen glitches will lead to slowdowns or outages. During these times, banks may find themselves unable to meet their regulatory deliverables, or worse, find that their customer experience is negatively impacted.


Like MiFID II, PSD2 will depend on the flawless interaction of multiple, existing systems that were created for other purposes. For the first time, banks will be required to open up account information to third parties to encourage innovation. The mechanism for implementing PSD2 is more than half a dozen application programming interfaces (APIs). As the name implies, APIs make it easy for one application to interact with another application.

At the surface, APIs appear refreshingly simple. However, that’s only because IT teams are busy underneath doing the heavy lifting to create and maintain the new APIs and the systems they rely on.

The risk of performance problems is high. At any given moment, dozens of internal systems could be receiving requests from multiple PSD2 APIs. The demand triggered by a successful third-party marketing campaign could easily create unexpected performance problems with a cascading effect on the user experience. The damage will be intensified by the ease with which customers can switch to a new bank whilst still being able to use the same technology. For example, 80 per cent of respondents to a recent Attention Span Survey said they deleted an app because of poor performance.


The picture for unprepared organisations is grim, but it needn’t be. Above all, it is important to recognise that disparate monitoring, alerting, and log aggregation tools are likely to fall short. Organisations need the end-to-end visibility provided by a unified solution to ensure speedy root-cause analysis and minimise downtime.

Faster, proactive issue identification and accelerated mean time to resolution (MTTR) are among the top reasons for adopting unified APM.

But the benefits go deeper. Certain solutions can help organisations meet MiFID requirements without building huge data warehouses. Instead of rolling out a new system with new points of failure, applications can enable organisations to unlock the business data within transactions and correlate that data with technology performance. Parameters that ensure transactions are being made in a client’s interest can be visually tracked on a dashboard. And, unlike alternative solutions, the value is usually seen within days rather than months.

IT departments are right to be concerned about the impact of real-world loads once the regulations take effect. By providing them with the tools they need to manage performance now, before the regulations take effect, organisations will minimise risk — and maximise resiliency.


Find out more


Solutions such as AppDynamics Business iQ also remove the guesswork from understanding the performance of new PSD2 APIs. On the one hand, they can alert IT as soon as any problem – or potential problem – is detected in the systems that support the APIs. On the other, they can deliver real-time data on how the APIs are being used far quicker than any historical method using business analytics — and further correlate with technology performance.