IS “HOPE” YOUR SEPA COMPLIANCE STRATEGY?

Justin Vaughan-Brown, DevOps Senior Marketing Strategist EMEA at CA Technologies questions whether organisations are ready as we fast approach the February 1st deadline

sepa compliance strategy

Back in January 2008, the European Commission launched the first step of the Single Euro Payments Area (SEPA), SEPA Credit Transfer (SCT). It gave corporates a clear and mandatory deadline to migrate to the SEPA collection and payment schemes.  After February 1st 2014, they will no longer be able to collect payments from customers using legacy national direct debits.

Companies seem to be having mixed success in conforming to SEPA demands ahead of February 1st, and on January 9th this year, this was recognized by an extension of the acceptance of non-SEPA format payments for another six months – but the 1st February migration cut-off date remains. Hopefully most businesses are well positioned to avoid downsides such as failed collections, penalties, reputational damage and loss of market share.

But what has been the experience of ensuring compliance within organisations? What has been the impact on development and test environments to meet the February deadline? How can organisations ensure that SEPA or any other compliance requirements in the future are met but do not negatively impact other equally important company initiatives, such as rearchitected platforms, new mobile applications or a new product or service launch?

The answer to these projected risks is a concept called “service virtualisation”. Simply put, this removes the dependencies on a limited number of mainframe, SAP, third party and other test environments and databases by simulating the behavior of these constrained systems and creating a virtual model of them. An agent listens into the traffic between the test systems, processes this data and converts this into a “live like” model of this activity that can be configured to behave not just as in the real world but even better, it can answer the “What if?” questions raised that negative testing demands.

Service virtualisation for SEPA

Service virtualisation can help with SEPA, other compliance scenarios and more commonplace application releases. In the case of SEPA, some banks have decided to use SaaS based solutions that turn the legacy account formats into SEPA-compliant data. This is a great idea, but how do you ensure a smooth integration between the 3rd party platform and your own established systems? How will you performance test these against varying levels of customer demand?

These third-parties may charge additional fees for access to test interfaces and the availability and performance of these interfaces may not be identical to the production versions. Service virtualisation removes the need for extra potential costs by providing a “live like” model to work with instead.

SEPA payments on mobile devices

Many analysts have predicted that tablet sales will outstrip those of PC’s by 2017, and increasingly applications are being developed with tablet or smartphone functionality as a major priority. Dynamic network conditions impact the communication channels between applications, the services and dependencies upon which they rely, and end users, who often have to contend with network constraints. This makes development and testing complex, as testing without emulated network conditions leads to inaccurate results.
Key challenges can include poor performance as downstream systems and mockups may not match the behavior or performance response needed. Rarely do network connections in the test lab reflect production network conditions, and end-user performance suffers.

Service virtualisation for networks addresses this by simulating network response times based on production scenarios to more reliably reflect the real world. This means accurate testing, validating and optimising of application performance beforedeployment, ensuring post- deployment service levels.

How robust are your applications?

A question that often concerns major rollouts such as SEPA includes performance testing. Software delivery projects have a tendency to slip schedules; as a result there is often pressure to reduce the time spent on late lifecycle activities such as performance testing. How close does that SEPA deadline look and what shortcuts will be made? Performance testing can only be done late in the lifecycle, requires large amounts of infrastructure, seldom replicates production to the appropriate level, and fails to allow the majority of negative testing conditions. Typically, labs cannot conduct performance testing until all of the components it depends upon are available.

The simulation approach can capture thousands of transactions that occur among the live application components and customer inputs, at a fraction of the data management cost. Its virtual environments give the performance team a much broader range of test data to recreate the variability of the application, so they can vet out the application performance much earlier in the process lifecycle, before integration is completed.

Test data – rarely discussed, often an issue

Test data management is typically the most costly and time consuming activity involved in running a performance test.

Composite applications typically have multiple data stores that need to be provisioned with test data and synchronised. Higher workloads mean that the volume of data required for a realistic test is greater than ever before. In addition, privacy regulations mean that the use of production data for performance testing is no longer an option for many organisations.

Virtual models allow all your teams to always have on-demand access to relevant datasets for systems under test, and that data will cover almost infinite valid data scenarios to support high-volume performance and regression testing needs.

Beyond SEPA

As 1st February moves closer, maybe it is time to consider how adaptable your organisation will be once your SEPA system goes live. How quickly will you able to release those minor updates or fixes and track the impact on your production environments relevant application’s performance?

Many of the world’s leading financial service organisations have adopted and trusted service virtualisation to significantly de-risk their essential programmes, compliance related and otherwise. Perhaps it is time to consider a fresh approach to application development, testing and release processes?

Justin Vaughan-Brown, DevOps Senior Marketing Strategist EMEA at CA Technologies questions whether organisations are ready as we fast approach the February 1st deadline

sepa compliance strategy

Back in January 2008, the European Commission launched the first step of the Single Euro Payments Area (SEPA), SEPA Credit Transfer (SCT). It gave corporates a clear and mandatory deadline to migrate to the SEPA collection and payment schemes.  After February 1st 2014, they will no longer be able to collect payments from customers using legacy national direct debits.

Companies seem to be having mixed success in conforming to SEPA demands ahead of February 1st, and on January 9th this year, this was recognized by an extension of the acceptance of non-SEPA format payments for another six months – but the 1st February migration cut-off date remains. Hopefully most businesses are well positioned to avoid downsides such as failed collections, penalties, reputational damage and loss of market share.

But what has been the experience of ensuring compliance within organisations? What has been the impact on development and test environments to meet the February deadline? How can organisations ensure that SEPA or any other compliance requirements in the future are met but do not negatively impact other equally important company initiatives, such as rearchitected platforms, new mobile applications or a new product or service launch?

The answer to these projected risks is a concept called “service virtualisation”. Simply put, this removes the dependencies on a limited number of mainframe, SAP, third party and other test environments and databases by simulating the behavior of these constrained systems and creating a virtual model of them. An agent listens into the traffic between the test systems, processes this data and converts this into a “live like” model of this activity that can be configured to behave not just as in the real world but even better, it can answer the “What if?” questions raised that negative testing demands.

Service virtualisation for SEPA

Service virtualisation can help with SEPA, other compliance scenarios and more commonplace application releases. In the case of SEPA, some banks have decided to use SaaS based solutions that turn the legacy account formats into SEPA-compliant data. This is a great idea, but how do you ensure a smooth integration between the 3rd party platform and your own established systems? How will you performance test these against varying levels of customer demand?

These third-parties may charge additional fees for access to test interfaces and the availability and performance of these interfaces may not be identical to the production versions. Service virtualisation removes the need for extra potential costs by providing a “live like” model to work with instead.

SEPA payments on mobile devices

Many analysts have predicted that tablet sales will outstrip those of PC’s by 2017, and increasingly applications are being developed with tablet or smartphone functionality as a major priority. Dynamic network conditions impact the communication channels between applications, the services and dependencies upon which they rely, and end users, who often have to contend with network constraints. This makes development and testing complex, as testing without emulated network conditions leads to inaccurate results.
Key challenges can include poor performance as downstream systems and mockups may not match the behavior or performance response needed. Rarely do network connections in the test lab reflect production network conditions, and end-user performance suffers.

Service virtualisation for networks addresses this by simulating network response times based on production scenarios to more reliably reflect the real world. This means accurate testing, validating and optimising of application performance beforedeployment, ensuring post- deployment service levels.

How robust are your applications?

A question that often concerns major rollouts such as SEPA includes performance testing. Software delivery projects have a tendency to slip schedules; as a result there is often pressure to reduce the time spent on late lifecycle activities such as performance testing. How close does that SEPA deadline look and what shortcuts will be made? Performance testing can only be done late in the lifecycle, requires large amounts of infrastructure, seldom replicates production to the appropriate level, and fails to allow the majority of negative testing conditions. Typically, labs cannot conduct performance testing until all of the components it depends upon are available.

The simulation approach can capture thousands of transactions that occur among the live application components and customer inputs, at a fraction of the data management cost. Its virtual environments give the performance team a much broader range of test data to recreate the variability of the application, so they can vet out the application performance much earlier in the process lifecycle, before integration is completed.

Test data – rarely discussed, often an issue

Test data management is typically the most costly and time consuming activity involved in running a performance test.

Composite applications typically have multiple data stores that need to be provisioned with test data and synchronised. Higher workloads mean that the volume of data required for a realistic test is greater than ever before. In addition, privacy regulations mean that the use of production data for performance testing is no longer an option for many organisations.

Virtual models allow all your teams to always have on-demand access to relevant datasets for systems under test, and that data will cover almost infinite valid data scenarios to support high-volume performance and regression testing needs.

Beyond SEPA

As 1st February moves closer, maybe it is time to consider how adaptable your organisation will be once your SEPA system goes live. How quickly will you able to release those minor updates or fixes and track the impact on your production environments relevant application’s performance?

Many of the world’s leading financial service organisations have adopted and trusted service virtualisation to significantly de-risk their essential programmes, compliance related and otherwise. Perhaps it is time to consider a fresh approach to application development, testing and release processes?