Open Banking API Strategies for Banks & Financial Institutions
The idea of “open banking” has been receiving a lot of attention recently and we are bound to an evolution in our interactions with banking and other financial services due to it. This paradigm shift is fuelled by application programming interfaces (APIs) rendered by banks.
Management of customers’ confidential data by banks is significant because of the UK’s “open banking” initiative and the EU’s implementation of the Payment Services Directive 2 (PSD2). Using the application programming interfaces (API), we can authorise certain applications or services to access our data. Hence, Open banking with standardised APIs would reduce a lot of barriers between diverse kinds of banking services.
For instance, it improves our lives as we opt to share our personal financial data with a mobile app that displays such data in a consolidated view or to perform payment initiation directly from a checking account through an online accounting package.
Both traditional banks and new “Fintechs” stand to benefit from these developments, since they present an opportunity to transform the business model that has defined banking for decades.
Open Banking
Open banking is a drive that enables third-party financial service providers to access consumers’ banking data. The basic objective of open banking is to provide consumers with more control over their financial information by allowing them to safely use alternative financial services that tap into banking infrastructure.
Much of this new ecosystem is supported by Web API technologies. Using an API is a necessary part of Open Banking in this setting, as it offers more options to banking consumers.
Reasons for Adopting an API Approach to Open Banking
Many financial institutions are motivated to adopt Open banking in response to the implementation of the European Union’s Second Directive on Payment Services (PSD2).
There are numerous solid reasons in favour of open banking and numerous tangible financial incentives for financial institutions to make the transition. Let us look at the top reasons that follow.
Adhering to Compliance
Compliance is the main driving force for institutions to adopt open banking practises. PSD2, also known as X2SA (Access to Account), is the greatest example of a broad law that requires banks to disclose customer data with third parties.
The US Treasury has proposed new financial data sharing legislation, contradicting the country’s traditional market-driven strategy. Other major jurisdictions are also heading in this direction.
Obviously, the goal of compliance is not to increase income, but rather to maintain a viable firm. Compliance increases profitability by preventing pointless fines and fees.
Enhanced Digital Agility
Being able to share data rapidly, safely, and effectively is one of open banking’s biggest challenges. Many financial institutions are rethinking their data architectures as a result, opting for an API-first, microservices-based strategy to make information more readily available. Therefore, open banking is both necessary and beneficial in fostering more digital agility.
Open banking improves security and transparency and makes it easier for banks to use their own data internally, such as for service customisation or frontend applications.
An enhanced digital infrastructure enables data to be utilised more effectively internally to enhance the customer experience, thus improving customer lifetime value.
Superior API Packages
Open banking makes it easy to create new API offerings that generate remarkable revenue. Banks can generate more direct income if they design and market new API products. For other banking services (such as specific business accounts), these premium APIs can be utilised as up-sells or cross-sells.
Improvement in Customer Satisfaction
With open banking, customers have unparalleled choice in selecting from a wide range of banking options.
Customers are less likely to look elsewhere for their banking needs if their present financial institution offers a wider range of financial service integrations, regardless of whether such integrations are the bank’s own or not.
Customers are less inclined to switch banks if they are satisfied. As a result, the lifetime value of a customer rises, which boosts profits eventually.
Collaboration Prospects
Banks can offer enhanced features, personalised assistance, or even research and development partnerships to third-party companies in return for non-monetary benefits like cross-branding or product functionality for the bank in exchange.
Banks can attract new consumers by working with the third-party financial services industry to develop distinctive value propositions and innovative marketing approaches.
Broad Customer Base
With open banking, banks now have an immense opportunity to introduce new financial products and services based on its integration and can serve customers of other banks, potentially generating much more revenue and a progressive customer base.
Banking Made Accessible through Fintech APIs
There is a massive quantity of information that banks collect, from timestamps to transaction IDs. This data prompted the Fintech to think about how it could be utilised for better banking. “Better” means more open, transparent, and less corrupt.
FinTech services are reshaping the banking industry and the global financial system by eliminating traditional approaches such as paper checks, physical donations, paper currency, and investment businesses.
Technology is crucial to financial service industry advancement and thus APIs help banks improve speed and cost compared to outdated systems.
Banks and other financial institutions must upgrade to modern technologies to thrive in the years to come. And London prevails as an epicentre for the global fintech sector owing to a substantial number of investments in the fintech sector over there.
The meteoric growth of FinTech firms and open financial data initiatives worldwide is largely attributable to Application Programming Interfaces (API). The decision to construct the banking platform with an ecosystem of third-party developers in mind due to the following reasons:
- A bank API facilitates a faster onboarding experience for the end users.
- Banks can acquire partners that provide niche FinTech services with optimised front-end user interfaces by using APIs.
- Their APIs can be easily integrated with crowdfunding platforms, payment-splitting apps, and more.
- This is especially useful for startups with innovative financial-oriented products that may lack the resources to manage funds or set up their own bank.
- To help FinTech businesses succeed, particularly those who are developing their own APIs, banks can share this information through partnerships and APIs.
Banks require well-designed, standardised APIs and self-serving adoption processes with documentation, sandboxes, simulated account structures, and more to gain developer users quickly. A successful banking API requires more partnerships and lower startup costs for FinTech businesses.
Getting the bank programmable is a win-win situation on all fronts
- Developers can experiment with banks’ authority and expertise to produce cutting-edge services and resolve compliance difficulties.
- Customers now have access to a whole new class of services that operate in tandem with their existing accounts. Open banking could reduce political corruption.
- By capitalising on partner resources, banks may generate new revenue and boost client satisfaction.
What Experiences Can Customers Have With Open Banking?
Breaking through the technological barrier and emphasising solutions rather than technology is one of open banking’s biggest challenges. Although the heart of open banking is APIs, which enable users to safely share financial data with platforms and apps, the typical customer is more interested in knowing how this will benefit them. Simple use cases that provide perspective for end users are crucial for bridging this gap.
Consumers can better comprehend open banking’s advantages by highlighting screen scraping’s limitations while offering a user-focused approach.
Open banking’s proponents must evangelise the technology by refining the message in several ways to successfully put it on the consumer agenda:
User Control
The focus of open banking should shift away from its technological aspects and towards how consumers are at its core, managing access to their accounts according to their own conditions. Open banking becomes more enticing by emphasising consumers’ sovereignty over their financial data and account access.
Promote Amazing Use Cases
Open banking unlocks the prospects of several banking providers for consumers. Open banking advocates may excite customers by showing real-life use cases and how they can profit from accessing and using their account data.
Reduce Security Concerns
Security problems must be addressed to build trust in open banking. By adopting high-grade API security procedures and clearly communicating the robust security protections in place, users may feel secure in the safety of their financial data.
These techniques can turn open banking into a consumer-centric movement that enables people to manage their finances.
Control Matters
A common set of questions that arise when discussing open banking with customers is who can access their accounts and who is ultimately liable if anything goes wrong.
Open banking is decentralised like the Internet and APIs, which raises fundamental issues. Consumers don’t know what they consented to or who gets their financial information without centralised control.
To solve this issue and build trust in open banking, consumers need tools to observe and manage their consented activities. Open banking empowers consumers by giving them control and visibility.
Without blindly trusting other parties, consumers should understand their role in their financial environment.
Furthermore, building an open banking marketplace would organise and make available all the solutions that make use of open banking APIs. Providers could promote their products and consumers could search for and consume them in one spot. The marketplace lets regulators evaluate, monitor, and certify new products.
Open banking can boost customer trust and create a trustworthy financial services environment by introducing signage and creating an open banking marketplace.
Best-in-class API Protection for Financial Institutions
The necessity for top-notch API security for banks has become critical with the rise of open banking, in which financial institutions exchange customer information with third-party providers. To prevent cyber threats and data breaches, financial institutions must implement secure API systems.
Multi-layer Protection
Multi-layered security protections against hacking and data breaches are an integral part of any high-quality API security solution for financial institutions. API security relies heavily on authentication and authorisation.
Banks must authenticate and authorise API users before allowing access. Multi-factor authentication does this by demanding users validate their identities in more than one way. These ways can include providing additional passwords, biometrics, or tokens.
Robust Encryption Mechanisms
Banks should use robust encryption mechanisms to secure data at rest and in flight. Given this, even if an outsider intercepts the data, they will not be able to decode it or use it to their advantage.
Constant Monitoring
High-grade API security for financial institutions also involves constant monitoring and the discovery of threats. Strong monitoring systems should be in place at banks to immediately spot any unusual or fraudulent behaviour. To this end, advanced analytics and machine learning algorithms can look for obvious indications of a security attack.
To proactively resolve any vulnerabilities in their API systems, banks should not only monitor, but also undertake frequent vulnerability assessments and penetration testing.
Access control & Privilege Management
Further, financial institutions should adopt rigorous access controls and privilege management to ensure that only authorised people have access to personal data. Depending on one’s position and responsibilities inside an organisation, one may grant varying degrees of access. There will be less opportunity for theft or fraud with consumer data if banks follow the concept of least privilege.
Keep Tabs on Updates and Patches
Finally, banks should make maintaining their API systems with the latest updates and patches a top priority. This includes upgrading software on a regular basis and implementing security patches as soon as they are issued by vendors. If banks don’t keep up with upgrades, they risk having their application programming interfaces (APIs) hacked.
Regulatory Compliance Considerations
Data privacy and protection is an important aspect of regulatory compliance related to open banking API. Since APIs allow banks and third-party providers to exchange consumer information, keeping that information safe and in compliance with privacy laws is more important.
Financial institutions and their contracted service providers must take extreme precautions to guard against hacking, data breaches, and other forms of cybercrime. To further ensure consumer privacy and secure the necessary permission for data sharing, they must adhere to legislation such as the General Data Protection Regulation (GDPR).
Here are a few of the most frequent regulatory requirements that financial sector providers may encounter.
Basel II
Basel II is a set of international regulations that mandates the assessment and reduction of the operational risk losses of financial data by financial institutions. It specifically addresses issues with inadequate data security and system failures brought on by incorrect configuration or low expectations for system requirements. This makes it a useful reference for any system that has to start working with financial data.
PSD2
PSD2 is the European Union’s updated Payment Services Directive, written by the European Commission to standardise the industry across the European Union and the European Economic Area.
The regulations are meant to safeguard consumers and lay out clear parameters for how payment processors and banks should operate.
URSIT
A US government standard, the FFIEC Uniform Rating System for Information Technology (URSIT) evaluates an organization’s Auditing, Management, Development, Acquisition, Support, and Delivery procedures.
As a framework for establishing a procedure to detect security issues, URSIT is an invaluable resource.
The Gramm-Leach-Blilely Act
It is a federal law in the United States that mandates the protection of customers’ financial and personal data. The Federal Trade Commission’s Data Safeguards Rule, which mandates a comprehensive evaluation of a company’s security measures, has its origins in this law.
PCI-DSS
PCI-DSS is a regulatory standard that mandates vulnerability scanning and source code review to guarantee that payment card industry data and procedures meet the stringent security protocols required by providers and payment providers.
Many businesses operating online, especially those whose services include handling customer payments, consider PCI-DSS mandatory.
Any API that plans to accept card payments should be highly familiar with PCI-DSS because of the stringent standards it sets.
Sarbanes-Oxley
It mandates a reporting structure for internal controls to ensure that sensitive financial information is monitored and protected. It requires a thorough assessment of IT assets, software, and solutions for their resilience against data breaches and exposures and involves severe audit mechanisms for internal controls.
This is just a portion of the most prevalent and high-level regulatory standards. Regulations can be stiffer in certain parts of the world, and there can be even more noticeable differences amongst segments of an industry.
Yet, having a strong knowledge of these underlying frameworks for regulation could potentially guide in learning about open banking.
Tavas- Open Banking Product Suite
Macro Global’s Tavas is a comprehensive Open Banking solution that aims to revolutionize digital payments while ensuring compliance with the PSD2 regulations, including the UK Open Banking Specification, which allows banks to be exempt from contingency mechanisms for their dedicated API interface.
This open banking solution is highly secure and safe, utilizing a cloud-based SaaS platform to enable secure engagement with third-party providers.
With cutting-edge technology, including state-of-the-art Open Banking APIs, Tavas offers services such as Account Information, Payment Initiation, and Confirmation of Funds. And Tavas provides customizable Open APIs, allowing banks to manage their business processes effectively.
Additionally, their web-based administration portal provides valuable insights and management capabilities for TPP (third party providers) Onboarding, Transaction Status, and Consent management.
Tavas also offers a robust data flow and enhanced security features for the deployment of open APIs. With a focus on customer-centricity, it offers a range of compelling use cases that go beyond monetization, allowing banks to transform their portfolio and business model.
Remarkable & Competitive Features of Tavas
- Establishes trust with banks and TPPs (third party providers)
- Ensures compliance with Open Banking (PSD2) regulations
- Provides secure and strong customer authentication
- Customizable API Framework
- Monitors and implements changes in the regulatory environment
- Offers safe and intuitive end-user experience
- Builds trust and loyalty in payment services
- Provides a self-service developer portal with a sandbox environment for testing and integration
- Offers a suite of pre-built APIs ready for implementation
- Secured against database breaches, DDoS attacks, and man-in-the-middle attacks
As Open Banking continues to redefine the financial services landscape, Macro Global’s Tavas remains at the forefront of empowering financial institutions with its innovative API strategies to stay agile, competitive, and customer centric.
Tavas is a trusted ally for banking institutions looking to thrive in the digital age and unlock the full potential of Open Banking.
Final Thoughts
Banks may stay competitive in the face of a trend towards open banking practises with the support of an efficient API strategy. Since banks are using open banking APIs, they must provide customers with safe and reliable experiences. Customers’ personal data must be kept secure while meeting all applicable regulations.
Consumers benefit from the options provided by market-driven strategies, which also foster innovation and healthy competition. However, banks and third-party providers benefit from the transparency and efficiency provided by standardised frameworks.
Thus, financial institutions and banks who want to embrace open banking must have a well-executed API strategy. As the landscape of open banking continues to transform, it will be ever more vital for financial institutions to monitor developments across the sector and adjust their API strategy accordingly if they hope to maintain a competitive edge.
Guide to FSCS Single Customer View – Key best practices that every FIs should follow
The US Department of the Treasury, the Federal Reserve Board (FRB), and the Federal Deposit Insurance Corporation (FDIC) announced steps to protect all deposits under an emergency lending programme and for the FDIC to finish the resolutions for Silicon Valley Bank (SVB) and Signature Bank. The US government is now taking steps to keep the banking system strong. US Federal Reserve will further investigate and write a report on the failure of SVB from a regulatory perspective.
Even though bank failures are rare, recent events at SVB, Signature Bank, and Silvergate Bank are likely to put pressure on banks to look at and improve their corporate governance and risk measuring and monitoring systems, as well as test their capital levels, complexity, and business models under stress. It’s a reminder of how important it is for the bank to have a good risk management programme to keep its operations safe and sound.
Since this is the scenario in the US, Financial Conduct Authority (FCA) in the UK is expected to give a full report and analysis of why the banks failed. As a result, changes to regulations are likely, and bank management needs to ask the right questions to be ready.
The Financial Services Compensation Scheme (FSCS) in the UK provides protection and compensation to customers of financial services firms. FSCS compensates the eligible customers within 7 days of failure. To do this, a standardised Single Customer View (SCV) should be in place which supports resolution options, such as a transfer of deposits or a bail-in, as well as a payout. You can find the SCV requirements for deposit takers regarding in the Depositor Protection Part of the Prudential Regulation Authority (PRA) Rulebook. You can also find the PRA’s expectations for deposit takers here.
Moreover, FSCS updated its “Single Customer View (SCV) Guide” which aims to provide a detailed overview of the Single Customer View (SCV) initiative, covering a range of topics to improve the data quality and governance keeping in mind the deposit takers, insolvency practitioners, SCV system auditors and SCV system vendors.
Good Data ensures Better Compliance. First and foremost, business and product development competencies are the foundation of successful competition in today’s market, and effective development necessitates fundamentally enhanced methods for organising the development process. Financial institutions are ramping up their capabilities, products, and services to be more competitive with their peers. It involves an increase in risk as well. Investments in governance, risk management, and compliance should be taken in parallel to their upgrading to avoid paying big to fail.
MG with its 20+ years of RegTech industry and being a leader in delivering regulatory products for banks and FIs, we list out the best practices that every FIs should follow to stay up to date with their data and daily operations to comply with FSCS requirements. Read on!
- Stay up-to-date on FSCS regulations and requirements: The FSCS provides guidelines and rules for firms to follow to be eligible for protection and compensation. FIs need to stay informed about any changes or updates to these regulations.
- FIs have to maintain status codes at the CBS level to identify the reporting eligibility of the customers. FI has to update the customers on at regular basis and update status codes for the customer/account where required.
- At regular intervals, FI must review the customer and accounts details and update the customer details if the data does not comply with FSCS requirements. It is recommended the FI can have an auditing platform that should audit the generated SCV/Exclusion and report any issue in the files. So, FIs can make use of the exception report and make necessary corrections at the data level or file level.
- If the customer details are unable to meet the FSCS requirement and FIs not able to correct the details then they have to allocate a separate status code for the particular issue and report the customer in the NFFSTP category.
- To categorise and report the customer details based on the status codes in SCV/Exclusion, the FIs have to have an SCV system that must have the capability to generate the SCV, Exclusion and ineligible report based on the customer/account status codes. Also, it must have the capability to generate the report within 24 hours.
- At regular intervals, FIs must conduct internal/external auditing to ensure that the SCV system satisfies the PRA-DP 11.1 and 11.2 and that PRA SCV and marking requirements are met.
- FIs have to maintain a risk register to record the issues that arise during the SCV report generation process.
- FI should communicate to the customer during the onboarding process about the eligibility of the customer for the protection provided by the FSCS.
- The FIs must, at least annually, take reasonable steps to confirm that a depositor that it has classified as a micro, small and medium-sized enterprise continues to be a micro, small and medium-sized enterprise using the exchange rate prevailing on the 3 July immediately preceding the date on which any confirmation is undertaken.
- At regular intervals, FIs have to reconcile the balance reported in the SCV file with the balance in their GL report generated in the CBS and ensure the accounts balance is tallied.
- FIs have to keep the following SCV documents up-to-date.
- a. SCV Effectiveness document
- b. Account Status Codes
- c. Product Codes
- d. SCV Policy Statement
- e. AML and CTF Manual
- f. SCV System procedure document
- g. SCV System process flow document
- h. SCV System Diagram
- i. Risk Registry
- It is recommended by FSCS to implement PGP encryption for encrypting the generated SCV files to prevent any manual corrections/tampering with the SCV files.
Banks must reconcile and fix existing data gaps and take the right stepsto make sure that accurate and complete records are kept at the time a newclient is added or an account is opened. Also, it might be important to make aneffort to learn more about the concentrations of current deposits in order toreduce liquidity risk and allow accounts to be spread out.
Regulators are more stringent to cope with the advancements in the BFSI sector. The goalpost is changing every day, and banks should prepare themselves for the increasing regulatory demands. Adopting a single customer view is all about making the most of an organization’s most valuable assets, which are its customers. In short, implementing a solution for the single customer view is a journey, not a one-time project. Putting it to use in your business is an ongoing process that takes time and effort. The journey starts with good data and accurate information about customers, and then everything else builds on that.
With our constant pursuit to bring newer tools and innovations, Macro Global is on the quest for more solutions and services that bring revolution in fintech. To partner with Macro Global, and to leverage more benefits, please reach out to salesdesk@macroglobal.co.uk or call us at +44 (0)204 574 2433.
FAQs
What are all the processes involved in auditing the generated SCV report?
- Data Mining, Cleansing, Enrichment, and Reconciliation: Uses AI-based algorithms to identify inaccurate customer and account holder information, account segregations, data duplication, and more.
- Full Audit History and Comparison: Maintain a full audit history and facility to compare previous ones to track metrics for data remediation.
- Internal/External Auditing: Conduct regular internal/external auditing to ensure that the SCV system satisfies the PRA-DP 11.1 and 11.2 requirements are met.
- Risk Register Maintenance: Maintain a risk register to record the issues that arise during the SCV report generation process.
- Security and Compliance Check: Continuously ascertain compliance with ISO standards and FSCS regulatory requirements.
- Audit and Screening: Implement a process for auditing and screening to ensure more accurate and trustworthy customer information.
- Communicate and Engage: Develop channels for communicating and engaging with stakeholders during the audit process.
These steps are essential for ensuring the accuracy, completeness, and consistency of the SCV report and maintaining regulatory compliance.
What are the third-party integrations used for data validation?
The third-party integrations used for data validation in the generated Single Customer View (SCV) report include trusted databases maintained by independent organisations such as FCA DB, Royal Mail DB through API, Companies House, Charities Register, BFPO Address, OFAC Sanction customer check, and other databases.
How are the data sources integrated for SCV report generation?
- Aggregates data from various channels for diverse customer interactions, transactions, behaviors, and preferences.
- SCV Forza, an automated platform, integrates data sources seamlessly.
- Leverages AI-based fuzzy logic and multi-level data validation to prevent data duplication and ensure consistency.
- Facilitates account segregation management, linking related accounts and datasets.
- Enables generation of accurate SCV reports meeting FSCS compliance requirements.
What are all the data privacy and compliance standards followed by the SCV regulatory reporting tool?
The SCV regulatory reporting tool follows several data privacy and compliance standards to ensure a high level of data security and regulatory adherence. Here are the standards followed:
- ISO Standards
- FSCS Regulatory Requirements
- Strong Customer Authentication
- IP Restrictions for Admin Portal
- Microsoft Enterprise Grade Security
- Secure Data Capture
- Stringent Data Retention Policies
- Malware Protection
- Robust 256-bits Encryption
- Periodic VAPT (Vulnerability Assessment and Penetration Testing)
- 3D Secure Authentication
- Firewall Protection
How data is managed in the FSCS SCV Enterprise suite?
The SCV Enterprise Suite offers a fully automated data aggregation process, ensuring accurate and reliable data management.
- Uses AI-based fuzzy logic to prevent data duplication and generates accurate SCV reports for FSCS submission.
- Ensures data privacy and compliance by complying with ISO standards and FSCS regulatory requirements.
- Maintains a full audit history, allowing users to compare previous audits and track metrics for data remediation.
- AI-based algorithms identify potential issues, such as inaccurate customer and account holder information.
- Regular compliance checks ensure data reliability.
- The platform uses robust data security measures, including 256-bit encryption, malware protection, strict data retention policies, and firewall protection.
These measures safeguard stored data from unauthorised access and ensure its integrity.
Provide utmost accuracy and Complete Peace of mind
We will be able to help you in whatever the stage of your regulatory reporting programs
Top 14 Common FATCA/ CRS Reporting Issues & Solutions
Meeting the constantly evolving regulatory requirements of the tax authorities presents a significant problem for financial institutions. The need for tax returns has surged among many banks’ clientele who have assets everywhere. The number of transactions is rising, new guidance is being released often, and it is getting harder to comply with standards, which further adds to the difficulty of the situation.
Here are MG’s view on the most common reporting standard errors identified by STEP that occur during the CRS reporting process. Let's deep dive into each of them.
- The financial institution (FI) must re-register, and it is unable to access previous returns on the portal since its login information has changed due to employee turnover. Login information for the Automatic Exchange of Information (AEOI) portal should be kept private and shared only with those who require it. The financial institution should ensure that there is a reliable method of maintaining access to its portal. A phoney email account could be a good alternative if the FI has robust security and data protection safeguards in place.
- The FI has the wrong idea of what an undocumented account is. HMRC has told FIs that they are wrongly reporting accounts as “undocumented” when an account holder has not filled out a self-certification that was asked of them. This has caused a lot of accounts to be reported with the wrong country code for GB residents. This is only applicable to Pre-Existing Individual accounts and not applicable to entities and New Individual accounts.Undocumented lower-value accounts only exist if all three of the following criteria are met:
- The Financial Institution’s only signals from their electronic record search are a “hold mail” instruction or an “in-care-of” address in a CRS Reportable Jurisdiction.
- There is no other address or indicia of residency for the Account Holder.
- The financial institution has, in the sequence that best suits the situation:
- attempted to get a self-certification or other documented evidence from the Account Holder to demonstrate the jurisdiction of tax residence of the Account Holder but was unsuccessful in doing so; or
- conducted a paper record search for indicia but no indicia were located.
- Only a “hold mail” instruction or an “in-care-of” address in a CRS Reportable Jurisdiction are the only signs that the Financial Institution has from their paper record search and electronic record search.
- There is no additional address or indication of residency for the Account Holder.
- To determine the Account Holder’s jurisdiction of tax residence, the Financial Institution has attempted to get a self-certification or other documentary evidence from the Account Holder but has been unsuccessful.
- The FIs submit using the XML schema. The submission is turned down because MessageRef, FIReturnRef, and AccountRef were used in the wrong way.HMRC published Schema and supporting documents for software developers who use the AEOI service. The schema guidance tells you everything you need to know about how to use references. You can find it here.Our CRS Stride populates the XML schema which contains the above-said parameters.
- The FI reports accounts for which the account holder does not live in a jurisdiction are subject to reporting.It is not appropriate to report people who do not reside in a reportable jurisdiction. Some jurisdictions that have signed up for CRS are not yet prepared to receive exchanges, while some of those that have signed up are not reciprocal. It is important to note that the reportable jurisdictions are updated frequently, and the notification will be given by HMRC. Refer to IEIM402340.Our CRS FATCA tax consultants follow the HMRC updates on the jurisdictions and add or remove the jurisdiction in the CRS Stride solution for effective CRS/FATCA reporting.
- Although the resident country code is not the US, the FI reports accounts as NPFFIs.Concerning years up to 2016, the phrase “non-participating foreign financial institution” (NPFFI) solely applies to FATCA and is not relevant to CRS. The resident country code, if applicable, should be US.Our CRS Stride can identify and segregate the NPFFIs in the exclusive audit reports we generate.
- The FI reports accounts that are not reportable because they are excluded, such as registered pension plans.IEIM 401720 provides a detailed definition of undesignated and designated accounts.Undesignated accounts: When a financial account (owned by a non-financial intermediary, such as a solicitor) is a pooled account that holds the funds of underlying clients of the non-financial intermediary and does not meet the requirements of IEIM401860, where:
- If the non-financial intermediary is the only person listed or identified on the financial account with the financial institution, and
- If the non-financial intermediary is not required to disclose or pass on their underlying client or clients’ information to the financial institution to comply with AML/KYC requirements or other regulatory requirements, then, provided both of these conditions are met, the financial institution is only required to carry out the due diligence procedures concerning the financial account.
- The FI reports non-individuals who should not be reported.Governmental organisations, international organisations, central banks, and financial institutions are not reportable account holders under CRS, nor are firms with regularly traded stock and similar entities. Article 1 (gg) of the UK-US Intergovernmental Agreement contains a list of exceptions to the phrase “specified US person” as used in FATCA (IGA).
- The FI submitted the CRS XML which does not adhere to XML schema definitions (XSD) published by HMRC.An XML schema definition (XSD) is a framework document that defines the rules and constraints for XML documents. The generated CRS XML must fully adhere to the rules of the XSD document published by the HMRC.
- The Entity’s account holder type is set as Reportable Entity with Controlling Person, but controlling person(s) is not provided in the XML.If the account holder type is set as “Reportable Entity with Controlling Person” then at least one controlling person must be provided for the entity.
- The entity must be reportable even though the entity’s jurisdiction is not reportable and any one of the controlling persons is in reportable jurisdictions.As per the HMRC guidelines, if any one of the controlling person’s jurisdictions is reportable and belongs to the particular entity, then entity details are also reportable.
- TIN (Tax Identification Number) is not provided for the US customer.As per the HMRC guidelines, the TIN for US Tax residence is mandatory. If the customer does not provide the TIN, then the default TIN value of nine-zero must be populated. If possible FIs can populate the TIN values provided in the link instead if nine-zero.
- Void Submission File generation to delete the submitted CRS file from the HMRC portal.If FIs identified an issue in the previously submitted CRS file, then void submission XML file needs to be generated which should adhere to XML Schema and Specification given by HMRC.
- Only financial institutions are permitted to use the AEOI enquiry helpline.HMRC requires that you refrain from providing your account holders with information about the AEOI enquiry lines. This overwhelms its AEOI filing crew and makes it unable to help FIs with their reporting requirements.
- The FI waits until the last minute to file.When submissions are made far in advance of the deadline of May 31, every year, FIs have more opportunity to address any unforeseen problems, such as missing data or incorrect XML structure, which could result in the application being denied.
Click here to learn how MG’s “CRS Stride” can satisfy your need for an optimal CRS solution. Our product and services cover all aspects of your CRS reporting obligation, but you can cancel at any time.
A look at how SME banks are adapting to the Common Reporting Standard Shifts
When it comes to data management in HMRC CRS reporting processes, SME banks faces number of compliance hurdles. To be fully compliant with HMRC, AEOI/OECD standards, banks must also ensure they have adequate controls and data management in place.
There is a level of basic information required of customers that can easily be obtained in the onboarding process are required for the CRS reporting. Our blog “Key Practical Aspects of OECD Common Reporting Standard (CRS)” explains the data requirements for the CRS reporting, OECD standards and its implications to the financial institutions.
Many SME banks offer a range of products and services, making it more challenging to determine which accounts should be subject to CRS reporting. All financial accounts which meet specific criteria must be reported in line with CRS. In addition, Banks must also report any account held by a company or trust under CRS guidelines. This means that the new rules could impact a wide range of financial products – from savings accounts to investment funds.
SME banks in particular typically have fewer compliance resources available to devote to implementation, and they may also struggle to identify all their customers who meet the reporting criteria. Banks started educating their staff on how to accurately confirm and report on a client’s identity and entity information.
The problem for growing SME-facing financial institutions is how to do these at scale with complete accuracy. As banks scale their products and services, they are continuously changing their procedures and systems to comply with CRS, requiring a data-led approach to make reporting easier. Proper systems and procedures should be put in place to identify and report any such activity and verify the identity of their clients.
Banks must take a holistic approach to CRS compliance and seek expert solutions to avoid rising compliance costs and significant fines. While training for bank staff is essential, an automated software solution will ensure smooth and compliant implementation of CRS reporting. Implementing CRS reporting software rather than relying on compliance staff to manually onboard customers is becoming increasingly essential.
CRS compliance and the impact on the client experience
The implementation of CRS will significantly impact the relationship between banks and their clients. Banks must take the necessary steps to ensure compliance but without creating a lengthy, manual customer experience.
The simple solution is automation. Capturing structured data in the onboarding journey and automatically storing data in line with HMRC CRS reporting requirements can significantly reduce onboarding time and in-life review processes. With CRS Stride banks are able to save up to 85% of their typical processing time.
Compliance can be a complex process, and banks must communicate openly with their clients about what is required of them. Embedding an end-to-end reporting solution in the customer journey will reduce duplication of entry for clients while ensuring data integrity and automated reporting workflows for compliance teams.
Key considerations by SMEs in implementing a best practice approach to CRS Compliance
There are several key considerations when implementing a best practice approach to CRS compliance. Firstly, SME banks should seek expert help to get up to speed with the new rules. If they are to build an in-house solution, it must be constantly managed to keep in line with changing regulatory requirements and to ensure controls hold up to audit standards.
Secondly, comprehensive data analysis is essential to identify all customers who meet the reporting criteria. Financial institutions must accurately report this data to HMRC. Banks must put in place systems and procedures to ensure compliance with CRS on an ongoing basis. Without an automated CRS reporting solution, this will rely heavily on training staff and manual review of potential suspicious activity.
Implementing a best practice approach to CRS compliance can be a challenge for SME banks. However, it is essential to avoid any penalties or reputational damage. By implementing expert solutions to provide comprehensive data analysis and put robust systems and procedures in place, SME banks can ensure compliance with new and changing regulations.
Final thoughts
Complying with CRS reporting standards is a complex challenge for SME banks. Obtaining the relevant data can be straightforward on a smaller scale, but manual compliance comes at the cost of longer processing times and a poor customer experience. As banks look to scale, data management should be integral to any strategic decision making. Software solutions are critical to accurate reporting and allow much greater flexibility as they grow their products, services and markets.
SME banks that take this best practice approach to CRS compliance can reap several benefits, including a reduced risk of penalties, improved reputation and a smoother relationship with HMRC.
Variable Recurring Payments (VRPs) & Sweeping in Open Banking: Everything We Need to Know
VRPs (Variable Recurring Payments) are the most significant improvement in open banking to date. VRP addresses one of the industry’s most pressing issues: the requirement for consent via Strong Customer Authentication (SCA) for every transaction. VRP effectively authorised authentication to a third-party provider (TPPs), which then enabled trusted beneficiaries to pay with a single click.
VRPs will be easier and faster to set up than existing payment methods (Direct Debit, CPA), allowing consumers to manage payments more easily and integrating payments into a broader range of customer journeys.
As a result, VRPs are on track to become yet another example of the growing trend of “embedded finance,” as well as the overall transformation of open banking into open finance.
VRP has so far only been mandated for Sweeping use cases, which are transactions between two accounts with the same name. Notably, in developing VRP for the Sweeping use case, banks have built the infrastructure needed to support first-party-to-third-party transactions.
Customers will be able to use VRP for anything from subscriptions to in-app payments, as well as general e-commerce. Card-on-file will be replaced by account-on-file. Direct debits that are outdated and have a problematic operating interface may be phased out.
How do VRPs function?
Variable Recurring Payments require these three parameters to create a long-life consent token.
1. Maximum number of transactions in each period (for example, a month),
2.Maximum value of any single transaction,
3.Total aggregate value of all transactions in that period
For example, if your maximum transaction value of any single transaction is GBP300 and assume it never exceeds GBP300 per transaction. If you make such transactions 5 times, the total amount would be GBP1500 which is the maximum number of transactions and total aggregate value for the month. And if transactions stay within these parameters, SCA is not needed.
How do the customers receive help from VRP?
VRP enables faster and more secure payments. Moreover, customers will never be asked to update their credit or debit card information again. Bank accounts do not expire, while credit cards do. VRPs also provide customers with greater convenience, control, and security. While open payments are still in their early stage, there is strong adoption and growth. The benefits offered by VRP supplies will only speed up this process.
What does VRP mean for retailers?
VRP has massive benefits for merchants, including real-time settlements, lower costs, the getting rid of card fraud, lower customer churn, and no chargebacks.
VRP enables the opportunity to monetise Open Banking
VRP is the first opportunity for banks to monetize their open banking investment and contribute to the ecosystem’s balance. This has a hugely positive effect.
Open banking eases a handshake between banks (ASPSPs (Account Servicing Payment Service Provider)) and TPPs. As a result, these industry players must continue to collaborate on initiatives that expand the functionality set of open banking and the opportunities it provides.
VRP is one such collaboration model, and it stands for a significant opportunity to bring a fairer distribution of value across the ecosystem. This new collaboration between FinTech and banks will level the playing field as we collaborate to fulfil the full promise of real-time payments everywhere.
VRP works by securely connecting authorised PISPs (Payment Initiation Service Providers) to customers’ bank accounts, allowing them to make payments on their behalf. VRPs supply several advantages over Direct Debit and card CPA to both small businesses making payments and receiving payments.
VRP and Sweeping
Sweeping is the automatic transfer of funds between a customer’s accounts, such as transferring excess funds to another savings account or using them to repay a loan or overdraft account. VRPs are an innovative method of making ongoing payments.
The CMA9 will first make these VRP APIs (Application Programming Interfaces) available for “sweeping.” This is the transfer of funds from one PSU (payment service users) account to another. This can be used to automate a fixed amount to be transferred to a savings or investment account each month, or to sweep funds between current accounts to allow a customer to receive help from new account features, rates, or fees without switching current accounts.
One of the core priorities of the open banking agenda is user experience, and both regulators and industry will be monitoring the situation as the use of VRPs for sweeping are started rolling out in the coming months.
Real-world business advantages of VRPs for sweeping
The OBIE found potential benefits for both consumers and SMEs by combining VRPs and sweeping. These are some examples:
Saving money
You should be aware that, £100 billion is locked up in the UK’s business current accounts, earning little interest. However, while many businesses have a lot of cash, they do not have the time or interest to do anything with it.
A mandate can be set with a savings company to oversee a business’s current account. When the balance exceeds a certain threshold, the money could be transferred to a business savings account. Money could be swept back every time a balance falls below a certain threshold.
Overdraft protection
Sweeping has the potential to create a type of unbundled overdraft to increase competition in the business’s current account market.
International payment cost savings
According to a 2016 report, banks generate approximately £4 billion in excess profit when small businesses do not make cross-border payments. Sweeping VRPs could be used to remove the friction from using an alternative payment company or foreign exchange business.
Manage tax efficiently
As HMRC incorporates Open banking enables technology to support real-time secure payments. With VRP and sweeping, SMEs can manage their taxes well and make payments automatically without any fail once the invoice is generated or sent to SMEs.
New Subscription Economy Options
The subscription economy is expanding, with many SMEs taking part. VRPs offer a payment system that incorporates the low cost of Direct Debit with the speed and flexibility of cards, potentially creating a strong alternative in this growing market.
VRPs and the OBIE Roadmap
If you think about the next steps for VRPs, you should consider the Open Banking Implementation Entity’s (OBIE) Roadmap, which was developed in collaboration with the CMA that supplies a framework for Open Banking implementation. This Open Banking roadmap outlines several measures, including the development of technical standards for VRPs that are compliant with PSD2 (Payment Service Directive 2), the UK Payment Services Regulations 2017, and the GDPR.
Even though OBIE developed technical standards for VRPs, the CMA9 banks are not mandated to implement VRPs for all use cases. But CMA has ordered the CMA9 to implement VRPs as the mechanism for implementing sweeping. The use and implementation of the VRP standards are optional and at the discretion of the CMA9 firms for use cases unrelated to sweeping.
The CMA had originally planned to implement VRPs for sweeping by January 31, 2022. However, in response to OBIE recommendations, the CMA has allowed the CMA9 to extend the deadline. TPPs must then complete testing of the VRP standard in a live, controlled environment by July 2022, “so the firms are ready to advance general availability of the standard.”
Potential Use cases of VRP and Sweeping
Sweeping is one of the potential use cases for VRPs, which could be applied to a wide range of recurring payments and as an alternative to traditional fixed-period direct debit or card-on-file payments.
The OBIE’s Proposition Paper, published in November 2020, describes several use cases for VRPs, including:
a) Automated payments for electricity bills.
b) Linking a bank account to a social networking site app for in-app payment authentication.
c) Setting a six-month payment limit for a new subscription.
d) Automated payments for ride-hailing fees.
e) One-time payment setup for an online marketplace’s one-click payments.
f) Using a third-party smart saving app to transfer money from a bank account to a savings account on a flexible/variable basis.
g) Utilising a third-party service that supervises bank accounts and retains a threshold balance or assisting in avoiding overdraft fees by transferring funds between accounts as needed.
h) Obtaining short-term credit to avoid overdraft fees, then automating credit repayments to reduce overdraft charges and borrowing costs.
Concluding thoughts
Our analysis clearly showed that there is an appetite for VRP technology, and SMEs are eager to take advantage of this capability. VRPs help SMEs to mitigate overdue payments, and remove challenges, and pain points associated with other payment methods such as Direct Debit and CPA. The key to adoption will be in ensuring time and cost barriers are overcome to ensure SMEs get to the start line.
Macro Global’s Open Banking (PSD2) solution, Tavas enables banks to create a connected experience while also allowing them to adapt to emerging opportunities to position themselves in the new era of consumer-centric banking. Tavas – Open Banking Product Suite & Solutions instils innovation in banks by redefining account and payment aggregation via a game-changing Open Banking API Framework that addresses all compliance requirements while providing a best-in-class user experience.
Discover more about our best-in-class Open Banking solution.
Enhancing CX in Financial Services via Open Banking
Open banking enables customer financial data, including transactions and payment history, available to financial service providers and third-party payment services. While this approach focuses on improving new financial services and products and ensuring transaction security, adoption is heavily reliant on a positive customer experience.
Open Banking Implementation Entity (OBIE) established the Customer Experience Guidelines which are intended to make it easier and safer for people to use products and services that support Open Banking. It combines the regulatory requirements and customer insights to create the Standard for TPPs and ASPSPs.
Open Banking regulation has made a significant revolution in the payment services industry, not only from a compliance perspective but also bringing a better experience to the customers. It mandates that banks develop APIs for digital banking transactions that can be used by value-added revolutionary service providers to inculcate competition and innovation among financial institutions across the industry. Open Banking also aims to prevent customer lock-in by standardising account switching capabilities and simplifying payment processing.
Customers are now exposed to a new business model where they must consent for their financial information to be shared with third parties. They can only consent if they feel well-informed, safe, and in charge throughout the entire process.
Open Banking builds healthy competition in delivering a better customer experience
The opportunity to create better customer experiences has been made possible by open banking. As per recent research, well-established or traditional banks are falling short in the eyes of customers when it comes to customer experience. However, smaller, or new banks are excelled in offering a better customer experience.
Customers laud the more niche digital banks for their user-friendly online services, appealing products, and superior customer service in general. But the gap is not caused by products or attractive interest rates. Existing banks are capable of matching both.
Customer service and digital transformation are more highly linked. With the rise of newer technologies such as mobile, big data, and enhanced real-time analytics, businesses can now create new, personalised offerings for their customers and prospects. Achieving customer expectations today includes intuitive user interfaces that allow them to accomplish their desired tasks quickly and easily across multiple devices, as well as customized value-added services based on their specific needs, backed by data and advanced analytics that offer useful insights and recommendations.
They are more customer-centric and provide a more consistent, convincing experience for the end-user thanks to the resulting agility and decreased costs of change that allow them to move quickly from idea to reality.
Traditional banks may be compelled, in the face of increasing competition, to concentrate on enhanced user interface design, giving current services slick interfaces. Customer experience, though, goes beyond the surface.
Behind appealing interfaces, a truly connected enterprise beats at the core of an intriguing customer experience. A customer journey is made or broken by the seamless integration data model and the aligned business process. Customers who self-serve and a hyper-enabled customer support function are simultaneously created by giving internal staff and customers access to the information they need when they need it.
The reliance on quick and unrestricted access to data will become incredibly valuable for traditional banks that are aiming to establish and defend a competitive advantage. The commoditization and implementation of advanced analytics have already spawned a new generation of enterprises known as FinTech, which leverage open APIs and standards while focusing on customer-centric innovation for new financial products and services.
Bringing Business & Technology together
With the evolution of FinTech, the effective implementation of new generation intelligent platforms improves, and the appetite for the predictive analytical techniques of the data will grow.
To deliver a superior customer experience, banks should consider all the possible architectural aspects such as processes, services, data, and technology. Customers will appreciate simple, fast, and sophisticated core services for multiple channels and user-friendly interfaces. All these actions necessitate the meticulous orchestration of architectural changes and fundamental architectural elements. This is where enterprise architecture comes into play. By connecting these touchpoints to business process models and information technology systems, the experience is optimally orchestrated and transformed to deliver targeted outcomes for customers – and results for the bank.
Open Banking fosters the banks to redesign their products and services for improved customer experience, improved processes, and faster time to market to avoid being relegated to “lowest common denominator” account servicing roles.
Simultaneously, banks can broaden their reach through fintech challengers by providing innovative API services that drive adoption in the fintech ecosystem. Adoption in the fintech ecosystem, of course, provides incumbent banks with sources of innovation through acquisition, fostering long-term growth and profitability.
Cloud Migration
Traditional banks are finally embracing the cloud to accelerate their digital transformation goals. Cloud migration is neither practical nor cost-effective. In contrast, the institutional agility and flexibility gained by embracing cloud infrastructure and services justify the required investments. Existing banks can provide new services, increased capacity, and ongoing modernization in ways that earlier attempts focused on delivering on-premises solutions could not.
Macro Global has achieved “Gold Partner” status with Microsoft. Most of our products are now being scaled up to Cloud Platforms, and customers will soon be able to upgrade to “Cloud Only” or “On-premises with Cloud Adoption” to address BCP and cost constraints. The cloud option allows our customers to pay a single set of fees for the entire solution, including hardware, operating system, Development Framework, and product, all of which are managed by us.
It’s simple to manage and scale up with the push of a button, and it’s accessible from anywhere on any device.
Accelerate IT modernisation and digitisation efforts
Open Banking emphasises transparency, security, and access, which provides banks with an opportunity to fast-track their digitization and IT infrastructure modernization efforts. Banks can compete as technology innovators by leveraging their vast resources and massive amounts of available data, using powerful advanced and predictive analytical tools to extract valuable insights. These insights can be used to broaden the service portfolio, gain more customers, increase revenue, and improve internal efficiency. Banks should focus on continuous innovation by improving technology infrastructure, introducing new processes, and optimising current processes to enable seamless customer journeys.
Macro Global’s Open Banking (PSD2) solution, Tavas enables banks to create a connected experience while also allowing them to adapt to emerging opportunities to position themselves in the new era of consumer-centric banking. Tavas – Open Banking Product Suite & Solutions instils innovation in banks by redefining account and payment aggregation via a game-changing Open Banking API Framework that addresses all compliance requirements while providing a best-in-class user experience.
Discover more about our best-in-class Open Banking solution.
Security & Privacy in Open Banking: Risks, Challenges & Solutions
Open banking is crucial in developing and delivering new revenue-generating services that today’s customers require. Financial institutions (FIs) around the world are increasingly making Application Programming Interfaces (APIs) available to a growing number of Fintechs and other third-party technology providers, such as Account Information Service Providers (AISPs) and Payment Initiation Service Providers (PISPs), as part of open banking initiatives.
The primary concerns for anyone involved in the open banking environment are financial privacy and the security of consumers’ finances. According to research, 48 per cent of consumers had negative opinions about open banking due to data and cybersecurity concerns. Malicious third-party apps could gain access to a customer’s account, data breaches could occur, and fraud, hacking, and insider threats are all possibilities.
To secure their businesses, protect their customer relationships, and consumer privacy, financial institutions should indeed re-evaluate their data privacy and security practices in tandem with their open banking initiatives.
In this article, we deep dive into key security and privacy challenges around open banking and the proactive steps that every financial institution should take to intensify and strengthen its open banking initiatives.
1. Adherence to Regulations and Standards
It is essential that each participant in the FI ecosystem follows the same set of guidelines and adopts a standard that can be relied upon by all. Access to open banking APIs is only available to apps that have undergone an independent audit and proven that their processes and security controls meet the FCA’s standards.
They must do this regularly after the initial audit to maintain authorization. Simultaneously, open banking regulations, such as the European PSD2, and local and regional protection laws, such as the GDPR, establish equal rules for all and enforce a high level of security.
Adherence to compliance and regulations not only helps them provide security but also frees them up to focus on innovation can be aided by an industry-wide proactive defence strategy based on the evaluation of FIs (including banks, Fintechs, regulators, and government agencies), security controls, and compiled threat intelligence data.
2. Giving Control to the Customers
Customers should be fully conscious of how their data is being used, how they can handle it, how it is being stored, and how the business is regulated, according to open banking security. The rules have already been established. Financial services, such as FinTech apps, have recently become more proactive in informing customers about their data and encouraging them to interact with it. Promoting data accessibility and transparency builds trust and ensures users have control.
3. Know Your Customer
One of the most difficult challenges that open banking faces are detecting suspicious activities in transaction monitoring that indicate cybercrimes or money laundering. KYC (Know Your Customer) is a process that every bank must go through with every customer, both initially and regularly, to identify and verify their identity.
Banks must understand their platform consumers and the partners they are connecting with. This includes their identity, as well as more detailed information about the endpoint devices from which they’re connecting (to ensure they’re not vulnerable to hacking), geographical location, and other factors. All of this is required to safeguard sensitive data, the user journey, and comply with financial sector regulations. The first step in preventing financial crime and money laundering is rigorous customer identification.
4. Evolution of Advanced Authentication and Authorization methods
For the protection of APIs, content filtering is crucial. Financial institutions require a comprehensive vulnerability management strategy that considers people, processes, and technology. As well as frequent scanning measures to identify real-time or potential threats, risks and the ability to address them in near real-time.
Access control is the main justification for using API gateways, though. With the advent of biometrics technology and multi-factor authentication (MFA), there is a significant evolution in recent times. In addition to a strong password, which is also crucial, multifactor authentication mandates an additional step for users to log into their accounts. These may involve asking the account holder one more question, sending a text message to their phone, or using a biometric scan like a fingerprint to unlock the account. According to studies, MFAs successfully thwart 99.9% of all potential hacks.
Additionally, open banking made APIs more secure. Standards like OAuth 2.0 or OpenID Connect must be used to secure API access, and it is frequently necessary to maintain support for SAML for access control on existing solutions. Implementing Single Sign-on (SSO) and Identity and Access Management (IAM) add additional security layers.
An authentication system that combines artificial intelligence (AI) and human intelligence can also assist in addressing the issue of managing multiple passwords.
Furthermore, technological solutions such as biometrics tokens (OTP) can be beneficial. It can help banks improve security and provide a better customer experience by utilising more effective processes and workflows.
5. Strong Data Encryption Techniques
Encryption is the stepping stone in ensuring data security. Data sharing in Financial Institutions should be permission-based or risk-based, with proper audit trails based on regulations and risk management standards. FIs can improve their security while running their operations more smoothly by using identity and authorization validation, Know-Your-Customer (KYC) capabilities, and fraud detection techniques.
While API management, security, and integration are the unsung heroes of open API implementations, speed and compatibility with bank infrastructure are critical to success. Banks can simplify processes for their customers and gain more control over security by implementing risk-based and permission-based security. Furthermore, it will assist banks in streamlining their security infrastructure and making it more efficient and customer-centric.
6. IT Security Governance
Cybersecurity is more than just robust. It constantly looks for threats, weak spots, scans for vulnerabilities, and flags problems before they even arise. This process is improved by information sharing between businesses and cooperative intelligence within the banking environment.
Increasing demands in Web Application Firewalls such as user experience and service networking, are causing traditional web applications to die. APIs are typically built as RESTful web services and use data formats that differ from those used by traditional web applications. As a result, the basic interaction paradigm between client and server has changed also protecting these APIs necessitates the development of new technologies.
FIs can increase the security of their operations by taking stringent measures like implementing strong customer authentication (SCA) through multifactor authentication (MFA), implementing risk-based MFA throughout the entire infrastructure, and enabling minimal role-based access.
7. Establish a secure digital platform
While implementing open banking, it is required to have a secure digital platform as banks must transfer and consume certain data with third-party providers. A secure digital banking platform serves as a central location for connecting, storing, working with, and securing your open banking data.
All of this is made possible by microservices such as security solutions, which can be easily built on the digital platform and are already integrated into the Macro Global Digital Banking Suite, Calculus.
8. AI & ML for Behaviour analysis
Artificial Intelligence has greater potential in open banking. Based on more data, it learns and creates a more realistic assessment of the customers and their transactions. Banks can forecast customer behaviour which helps the banks to serve best to their customers. It can also help them spot odd or suspicious activity.
Banks can assess and manage the behaviour of their third-party providers (TPPs) as well as capture the patterns with the aid of AI and ML-driven solutions. Real-time verification is necessary for real-time payments. Therefore, having access to advanced analytics, AI, and ML learning tools can aid FIs in identifying fraudulent and cybercriminal activity. It is not surprising that FIs are adopting new technologies more quickly than ever as it gives them the chance to improve their ability to adapt to any future changes. For instance, natural language processing (NLP) can be used to capture and process regulations, which can then be applied to gain a sizable competitive advantage. If an incident occurs, banks can track the transactions which is critical for risk and compliance.
ML can support the detection of abnormal behaviours in fraud and system breaches. Commencing with a sample set of data, the machine is trained to spot fraudulent activity, identify the fraud, and eventually predict and stop threats.
Both FIs and consumers have a lot to gain from open banking and to profit from it, FIs must maintain consumer confidence and safeguard private information.
9. Dismantling rigid organisational structures
Another significant challenge is less technical and more organisational, namely many companies’ SILO thinking. Who is the point of contact and decision-maker when multiple technologies converge to form one large whole? Is it the CISO, because security concerns impact IT infrastructure and application operations? Is it the Business Group, because integrated solutions have a substantial advantage and a shorter time to market? Is it necessary for Marketing to take the lead because intuitive user guidance and lesser bounce rates are, after all, the domain of marketing communications?
10 .Regular Control and monitoring
Once everything is in place, it is time to monitor and control. At this point, banks will typically set up alerts for access, users, transactions, locations, amounts, and other factors. If there are any anomalies, the bank will be notified.
Final thoughts
The challenge of API security in a financial ecosystem is not simple. It necessitates a lot of work and the constant attention of the architects of a banking ecosystem. Open APIs are crucial to the growth of open banking, but they also raise more security issues.
Open API security is critical because it can prevent the leakage of previously inaccessible and even secret data points. Therefore, it’s crucial to have a secure system that can evaluate each open API in real-time and quickly and flexibly verify its security throughout its lifecycle.
Currently, only a select few organisations and experts have the necessary expertise to build a performant, future-proof security framework for open banking. Macro Global is one such organisation. MG’s Open banking and other financial software are built with the primary goal to establish secure, open, and reliable interactions between banks, customers, and businesses.
Start your journey toward open banking with API security.
MG’s views on the Joint statement from HM Treasury, CMA, FCA, & PSR on the future of Open Banking
A joint statement was released on March 25, 2022, by Payment Systems Regulator (PSR), Financial Conduct Authority (FCA), CMA, and HM Treasury, announcing their collaboration on the future vision & governance of open banking and the formation of a Joint Regulatory Oversight Committee (the Committee). Further, on December 16, 2022, the committee discussed the update on the progress, the vision and innovative ideas for how the future entity should function.
This is expected to bring major changes and reforms in Open Banking, enhancing development across various spheres. Open banking has increased the UK’s international competitiveness and leadership and has also benefitted customers, businesses, and the broader economy, promoting economic growth.
Let us elucidate on what would be the impact of these statements, and how Tavas, a new-gen, platform is fuelling the development of open banking, and leveraging the future of the FinTech Industry.
The impact of the Joint Statement
Three priorities identified are to unlock the potential of Open Banking payments to support competition and innovation, and to adopt a scalable model for future data-sharing propositions. Further, the focus is also on establishing a sustainable foundation for the ongoing development of the Open Banking ecosystem.
The Strategic Working Group (SWG), convened by the Joint Regulatory Oversight Committee (JROC) and independently chaired by Bryan Zhang, is providing a comprehensive analysis that reflects the variety of stakeholder perspectives on Open Banking’s current gaps, potential short- and long-term solutions, and the structures required to further develop Open Banking and define a future roadmap. The final report of the SWG, which will be given to the Joint Regulatory Oversight Committee by January 2023, will be a crucial factor in JROC’s deliberations.
In the interim, we anticipate the future entity to begin delivering priority non-Order activities, with cooperation from regulators, as necessary. The transitional state will terminate when a permanent regulatory framework is in place. The framework will be supported by all applicable legislation.
The blueprint of the future entity includes
The Joint Regulatory Oversight Committee has a key vision for the future:
- Empower Open Banking products and services. Drive competition in financial services that benefit both consumers and businesses
- Strong technical infrastructure and services enhancing new standards
- Ensuring cohesive collaboration with partners like Pay.UK concerning Faster Payments Scheme rules.
There are three essential components that the work addresses
- To enable Open Banking to thrive, a long-term regulatory framework needs to be established and will include the relevant regulator
with powers of review, variation, or withdrawal (subject to CMA judgement). - The CMA Order is in effect before permanent regulations are set up an interim state will exist.
- To ensure usability across all users of services and capabilities, it is important that financing for this future entity comprises broad-based equitable funding which efficiently distributes costs proportionally
- In the interim state, various principles implied on non-order activities, encompassing new activities, services or infrastructure would be discussed.
- The purpose of the entity, including playing a significant role in the development and growth of Open Banking, should be reflected in its governance arrangements.
- Any fees/liability arrangements should also take into consideration these same factors.
Interaction with further open banking operations
Joint Regulatory Oversight Committee’s work and transition planning to assess any legislation required to underpin the long-term regulatory framework for Open Banking will ensure the objectives are met.
Next actions
- CMA will announce the completion of the present road map.
- In the first quarter of 2023, the Committee will make public its suggestions
About the design of the new institution, both during the interim stage and once a long-term regulatory framework is in place, as well as its vision for Open Banking.
The Committee will continue to coordinate to ensure all activities align to achieve the vision set.
MG's View on the Joint statement
The joint statement, focussing on emerging thinking, which encompasses the design of a future Open Banking entity has been revealed lately. This joint statement has added additional focus to ensure that the operation reaches more people effectively, along with a technical roadmap envisioning a broader schema of design, implementation, effectiveness, and operations of open banking. The SWG’s extensive analysis would reflect the range of stakeholder views it has gathered during a series of “strategy sprints” in recent months. Also, a further statement is yet to be released in the first quarter of 2023. This will open the views, and recommendations with futuristic insights.
In the series of Sprint Strategy, the committee consists of a range of industry representatives, subject matter experts’ consumers, businesspeople, and other prominent stakeholders who have given their views addressing the current gaps, short-and long-term solutions, along with the structures required to further develop Open Banking and define a future roadmap. According to the latest announcement, two expert panels from the SWG’s team will be set up to lead the payments strategy sprint and the data strategy sprint. The duration of each sprint would be for three weeks, starting with a one-hour “kick-off” session and followed by a two-hour sprint discussion agenda. We expect that JROC would prioritise existing issues rather than getting narrow with topics regarding ESG amongst other considerations during this period.
The advent of this joint statement is to promote the prominence of quick, efficient, and convenient data transmission methods to the third-party banking service provider, enhancing greater competition and innovation that would benefit consumers, businesses, and the wider economy. As a result, a boom in boosting the economy of the UK and fostering international leadership in this field can be achieved swiftly. This fuels the unlocking of Open Banking payments to enhance a plethora of newer options for payments, and tailored services that would reinvent a plethora of possibilities, and bring more prospects into open banking that would help invoke newer opportunities.
In addition to unlocking Open Banking payments, HM Treasury, the FCA, PSR, and CMA are focused on “Adopting a model that is scalable for future data sharing propositions”, and “Establishing a sustainable footing for the ongoing development of the Open Banking ecosystem.”
Increased impetus toward open banking – What Financial Institutions should do?
There are almost five million active users in UK. The trajectory had gained momentum in the last five years. According to the Statista Research Department, Europe has almost 12.2 million, open banking users, and is expected to reach 63.8 million by 2024. As of 2020, 24.7 million individuals worldwide used open banking services, a number that is forecast to reach 132.2 million by 2024. It is important to note that, the growth reached a great momentum between 2020 to 2024, at an almost 50% increase.
When much of the emphasis is on the security of all the transactions, where most of the data are exposed to several vulnerabilities, it is highly mandatory to enable comprehensive protection. Various financial regulatory boards and organisations are constantly working towards bringing holistic effectiveness to increase operability, facilitate ease of transactions, offer seamless operations, and strengthen the open-banking system.
The backbone of the Open Banking system lies in the modern platforms that offer a plethora of options including robust dataflow, advanced API, and adherence to strict compliance and regulations. With advanced options to choose between cloud-based architecture or an on-premises, it opens newer choices for the clients to choose efficiency and cost-effectiveness compared to the traditional methods of banking.
How Tavas will help achieve the vision?
As a comprehensive Open Banking product suite, TAVAS focuses on creating a consumer-centric digital payment transformation, encompassing advanced features with great security. Adhering to strict compliances, and regulations to achieve interoperability and stay in control of the endlessly changing payments ecosystem. TAVAS supports a robust data flow serving the Open Banking security conformance and accelerating an array of features for secure deployment of open APIs compliant with OBIE API Specifications. Along with that, it has an integrated developer portal and Open API sandbox that helps third-party providers to build and develop Open Banking APIs. Feature-rich platform with vital Data-quality controls and integrity checks offers resilience and complete end-to-end open banking solutions
As being highly inter-operable, and efficient to handle massive accounts of transactions along with a high volume of payment requests ensuring the integrity and validity of every transaction has made TAVAS, the most reliable solution.
Encompassing all the features required to build a comprehensive platform, Tavas has become a boon for banks, to expand and enhance customer satisfaction, and bring futuristic advancement proactively. To partner with us, call us at +44 (0)204 574 2433 or mail us at salesdesk@macroglobal.co.uk. Our executives will stay connected with you to understand your requirements.
PRA Consultation Paper CP9/22 – Depositor Protection Updates
As you may be aware, the Bank of England released a few important updates to depositor protection following PRA Consultation Paper (CP9/22) which has been published in Q3 2022. Our SCV experts have done an extensive impact analysis on the proposed changes by PRA, both from the Technical and business perspective. The major effect and relief is the COA (Continuity of Access) & Dormant Account Scheme rule been removed for the immediate term thus removing the ambiguity around these two rules.
We have covered all the items and necessary remediation or action required from a financial Institution (FI’s) standpoint in this article. Please read on further to learn more about each item in detail and see if you need to proactively plan to bring the changes either to your internal reporting platform or functional/operations level change to address these regulatory “must have” implementations at the earliest and stay fully compliant. Through our quarterly and seasonal patch upgrades, we automatically take care of our customers who currently use our solution.
As a result of the aforementioned changes, we anticipate that all FI’s may soon experience a new round of FSCS drills to reaffirm assurance on their readiness by PRA. Hence, it would be an excellent opportunity to make pro-active plans to implement these changes ahead and conduct stress tests on your internal systems and processes to prepare to withstand the storm.
Updates to the depositor protection following the PRA consultation paper
Background
The CoA Rules were implemented in 2015 to support the resolution and the PRA’s safety and soundness objective by reducing the adverse effects of firm failure on the stability of the UK’s financial system. The CoA Rules aimed to support the continuity of covered by maintaining a depositor’s access to deposits and banking services while a deposit taker was undergoing resolution using a Bank Insolvency Procedure (BIP) or a Building Society Insolvency Procedure (BSIP), via a transfer of covered deposits to a purchasing institution.
Following the introduction of the CoA Rules, the Bank of England’s (‘the Bank’) approach to resolution evolved, causing the Bank to reassess the transfer of FSCS-covered deposits using CoA functionality. As a result, in advance of the 1 December 2016 effective date of the CoA Rules, the PRA provided a WBC to a broad set of firms. This WBC substantially narrowed the scope of application of the CoA Rules for three years to exclude small BIP/BSIP firms and bail-in firms and allowed the Bank to consider the longer-term policy requirements for transfer resolution strategies. The original WBC expired in 2019. This was extended for a further three years to 1 December 2022 due to the possible impact of the Bank’s review of its approach to setting a minimum requirement for own funds and eligible liabilities on the scope, functionality, and necessity of the CoA Rules. During these six years, at any one time, only around 13 firms have been required to comply with the CoA Rules. Approximately 140 firms currently hold a WBC.
The Bank, alongside the PRA, has recently initiated work to develop alternative solutions to reduce disruption to transactional accounts in the event of an insolvency procedure (See PRA statement – ‘Improving depositor outcomes in the bank or building society insolvency’ (IDOBI)). This work will look to provide depositors with improved access to their deposits throughout such an insolvency procedure, and the PRA may consult in due course on proposed future rules in this area.
Proposal
The PRA is proposing to revoke the CoA Rules and amend other rules referring to CoA before the expiry of the current WBC and amend SS18/15 accordingly. The PRA considers that revoking the rules would ensure that, in the future, firms that would otherwise have had to develop systems to comply with the CoA Rules would not be disproportionately burdened by rules that are currently not being enforced for the majority of firms.
In addition to the proposal to revoke the CoA Rules, the PRA is also proposing that firms that have already developed CoA system capabilities should consider maintaining or archiving those systems. While the outcome of the IDOBI workstream is not yet known, it may lead to a consultation with proposed new rules that impose similar requirements to the CoA Rules. The PRA proposes that as part of this process, while such firms should maintain the capability to complete field 48 of the Single Customer View (SCV), which requires details of a customer’s transferable eligible deposits when completing the SCV, firms should leave it blank so that it acts as a legacy field retained as a placeholder. This may reduce any future costs should the outcome of the IDOBI workstream require firms to develop systems with similar functionality.
The PRA has previously stated that it would ensure that firms had at least 18 months to implement changes in connection with the re-implementation of the CoA Rules. The 18 months notice period was designed to give firms sufficient time to build the required systems. As the PRA is revoking rather than imposing additional rules on firms, which is intended to prevent new firms in scope of the CoA rules from investing in building new systems that may turn out to be redundant, the PRA does not consider that firms would require 18 months’ implementation time.
Action Required
Based on Macro Global’s analysis of the COA requirements, it has been observed that FI’s neither needs to get COA waivers from PRA nor implement COA activities at the CBS level.
In SCV Report, the transferrable eligible deposit field (field 48) must be reported with a blank value henceforth which Macro Global will be rolling out a new patch in the SCV Automation process shortly. In case you have not been onboarded with Macro Global’s SCV Automation for the SCV submission file generation, please ensure your existing application can handle this.
Background
The Dormant Account Scheme (the ‘Scheme’) was established under the Dormant Bank and Building Society Accounts Act 2008 and was originally launched (in respect of dormant bank and building society accounts only) in March 2011. The Scheme enables money that is held in dormant accounts to be distributed for the benefit of the community while protecting the rights of owners or beneficiaries to reclaim the value of their assets.
Under the Scheme, participating institutions can transfer money held in eligible dormant accounts to a dormant account fund operator. The dormant account fund operator manages the money received so that it can meet repayment claims from owners or beneficiaries should they come forward in the future, and distributes surplus money for the benefit of the community.
Under section 213 of the Financial Services and Markets Act 2000 (FSMA) and the FSMA (FSCS) Order 2013 (S.I. 2013/598), the PRA was required to make rules establishing a scheme for compensating persons in cases where a dormant account fund operator is unable, or likely to be unable, to satisfy a repayment claim against it. These rules, which are set out in the Dormant Account Scheme Part of the PRA Rulebook (the ‘DAS Rules’), provide for FSCS compensation in respect of repayment claims made in connection with a dormant account fund operator that is in default.
The Dormant Assets Act 2022 (the ‘2022 Act’) modified and expanded the Scheme to cover additional assets such as insurance, pension, investment, and securities assets. footnote [13] As part of the changes made by the 2022 Act, the 2013 Order was amended to exclude repayment claims made in connection with a dormant account fund operator that is in default from the scope of FSCS protection. Accordingly, the PRA no longer has the power to provide FSCS protection on repayment claims under the Scheme, and the DAS Rules have become obsolete.
Instead, HM Treasury is committed to ensuring consumer protection in the event a dormant account fund operator footnote [14] is or looks likely to be unable to meet its liabilities, and to upholding the core principle of the Scheme (i.e., that owners or beneficiaries can reclaim the amount of their dormant asset balance owed to them at any time). If there was a considerable risk that a dormant account fund operator could not fulfil its reclaim obligations, HMT would assess the most appropriate course of action in line with these principles, which may include the use of a loan to the dormant account fund operator.
Proposal
The PRA proposes to remove the DAS Rules from the PRA Rulebook, given that the PRA no longer has the power to provide FSCS protection of repayment claims under the Scheme. The deletion of the DAS Rules necessitates some consequential amendments to other Rulebook Parts which refer to the dormant account scheme.
Following the removal of the DAS Rules from the PRA Rulebook, the FCA will be making associated changes to the Fees manual (FEES) in the FCA Handbook to remove obligations relating to dormant account fund operators and the Scheme.
Action Required
This CP change is only applicable to FSCS. As per the PRA rulebook, if the dormant account operator is in default status, then the repayment claim will be handled by HMT directly.
Background
The PRA has become aware that the rules on Temporary High Balances (THB) in Depositor Protection 10 in the PRA Rulebook need to be amended to reflect the underlying policy intent and remove any ambiguity.
The PRA considers that the THB rules are unclear as to whether a trust can claim a THB on behalf of a beneficiary. When a trustee operates a bank account on behalf of a beneficiary, it is the trustee and not the beneficiary that is the legal account holder. The current definition of a THB refers to a ‘depositor who is an individual’. The PRA considers this could be interpreted to exclude corporate trustees and potentially all trustees from bringing a claim for a THB. This causes tension with the underlying policy intent as evidenced by the SoP – DGS which envisages trustees being able to claim THB protection on behalf of beneficiaries footnote [15] and the ‘look through’ concept that applies to trusts in the context of the DP Part of the PRA Rulebook. Moreover, in the case of a trust, the policy intent is that it is the individual beneficiary rather than the account holder/depositor who is of relevance in determining whether or not the rules on THB apply.
The PRA also considers that there has been some confusion as to how the rules on THB apply to joint accounts, specifically when one of the account holders dies. The existing rules in DP 10.2 provide for the THB regime to apply to sums paid to a depositor connected to a person’s death or which are held on the account of a deceased’s representative. However, the PRA considers that they do not set out how the THB regime applies in the event of a death of a joint account holder.
Currently, joint account holders are each entitled to FSCS protection up to the relevant limit, either £85,000 or, if the deposit is attributable to a THB, up to £1 million (unless the THB relates to payment in connection with personal injury or incapacity in which case there is no limit). This means, for example, that where there is a joint account with two account holders the account holders receive either £170,000 or £2 million FSCS protection in total. However, this protection is reduced to £85,000 or £1 million when one of those account holders dies, which means that if the firm then fails, the surviving account holder will have a substantial portion of their deposit not protected by the FSCS. This is not our policy intent.
Proposal
To ensure that FSCS protection continues to function in the way it was intended, the PRA proposes to amend the rules on THB to ensure that (i) trustees (whether individuals or corporate trustees) claim on behalf of eligible beneficiaries and (ii) the criteria for determining whether the THB rules apply are assessed about the individual beneficiary rather than the account holder/depositor. The PRA proposes that in line with the existing rules in the DP Part of the PRA Rulebook, the trustee of a bare trust would be able to bring a THB claim on behalf of each beneficiary, and the trustee of a discretionary trust would be able to bring one THB claim per group of beneficiaries.
To remove the current gap in protection for joint account holders, the PRA proposes to amend the rules in DP 10.2 to explicitly cover situations where a joint account holder dies. The PRA proposes to amend the rules relating to THB to provide that for a joint account, the FSCS protection limits of the surviving account holders would be increased by an amount calculated by dividing between the surviving account holders the limit applied to the deceased account holder at the date of death. The table below provides an example of the proposed changes where one depositor dies.
Depositors | Amount of deposit in a joint account | Proposal |
2 Depositors | £170,000 | FSCS protection is limited to £85,000 per depositor. The deceased’s protection is not split as there is only one remaining account holder so the surviving account holder receives £170,000 if failure is within 6 months of the death |
3 Depositors | £6 million (The deposit does not constitute a THB) | FSCS protection is limited to £85,000 per depositor. The deceased’s protection is split between the two remaining account holders so they each receive £127,500 (£85,000 + £42,500) if failure is within 6 months of the death |
3 Depositors | £6 million (The deposits are attributable to three separate THB events that have a £1 million limit) | FSCS protection is limited to £1 million per depositor. The deceased’s protection is split between the two remaining account holders so they each receive £1.5 million (£1 million + £500,000) if failure is within 6 months of the death |
The PRA considers that this would provide the surviving account holder(s) with THB protection for six months, giving them time to arrange their financial affairs and transfer any amounts over the relevant FSCS protection limit to another deposit taker.
Action Required
The THB is an exclusive FSCS internal separate process managed by them which is currently not to the scope of FI’s FSCS file submission. In case of any THB claim FI’s can deal with FSCS through their regular resolution channel.
Background
Under the Electronic Money Regulations 2011 (EMRs), the Payment Services Regulations 2017 (PSRs) and FCA guidance, e-money institutions (EMIs) and authorised payment institutions or small payment institutions (together PIs) and credit unions, in respect of e-money, footnote [18] are required to safeguard funds received from customers. One commonly used method is to segregate the relevant funds from all other funds held by the firm and deposit the funds in a separate account with a PRA-authorised credit institution. While FSCS protection is not available in the event of a failure at the level of the EMI or PI, the PRA had historically considered that these firms’ safeguarded funds deposited into a PRA-authorised credit institution would fall within the scope of FSCS depositor protection if the credit institution were to fail, as eligible end customers of EMIs and PIs would be deemed to have an absolute entitlement to those safeguarded funds via a statutory trust.
Following recent court cases, footnote [19] it is harder for the FSCS to establish that the end customers of an EMI or PI have an absolute entitlement to the safeguarded deposits. This creates a risk that the FSCS is unable to provide compensation to end customers if a PRA-authorised credit institution were to fail while holding deposits safeguarded under the EMRs/PSRs, which was not the intention of the original policy.
Proposal
The PRA is proposing to amend its rules to make FSCS depositor protection available to eligible customers of an EMI/PI in respect of their relevant proportion of safeguarded funds should the credit institution holding the safeguarded deposits fail. The proposed amendments would protect to end customers in respect of safeguarded funds which the PRA had understood to have existed before the decisions in the recent court cases. Ensuring that safeguarded deposits are FSCS protected at the point of failure of the credit institution is consistent with the logic of safeguarding.
As is currently the case, the proposals would not provide FSCS protection in the event an EMI/PI itself were to fail in an event unrelated to the failure of a safeguarding credit institution.
Eligibility
The proposed rules allow a look-through to eligible end customers of financial institutions that, under the EMRs/PSRs, deposit safeguarded funds into PRA-authorised credit institutions. Existing eligibility requirements in PRA rules will apply at the level of the end customer so not all customers of EMIs/PIs will be entitled to receive FSCS compensation. Customers would also not be eligible if they are unidentifiable (eg the e-money is anonymous) or the customer cannot be verified under AML rules.
Payment options
The proposed changes are designed to create an entitlement to depositor protection in respect of safeguarded funds for end customers to avoid an almost complete loss upon failure of a safeguarding credit institution. The PRA recognises, however, that a failure of a safeguarding credit institution combined with a requirement that the FSCS pay compensation directly to the end customers of an EMI/PI could ultimately lead to the demise of the EMI/PI. While a consequential failure may be unavoidable in certain circumstances, allowing the FSCS an option to pay the compensation amount into a safeguarding account held by the EMI/PI with an alternative credit institution may minimise the impact of the credit institution’s failure on the EMI/PI as well as the end customers. Therefore, the PRA is proposing the FSCS can pay compensation either:
into a new safeguarding account of the EMI/PI, provided the EMI/PI is not subject to a formal insolvency procedure and the FSCS is satisfied that each eligible end customer would be in no worse position than if the compensation was paid directly, or directly to the eligible end customers of the EMI/PI or to another person as directed by the end customer, if there has been an insolvency event at the EMI/PI.
The no worse off provision means that if the amount of compensation calculated by the FSCS is less than the total amount of safeguarded deposits shown in the failed credit institution’s exclusions view file (because, for example, there are customers that are ineligible for protection under PRA rules or amounts more than the deposit protection limit), the EMI/PI would need to contribute its own funds to make up the shortfall.
Calculating compensation
The calculation of compensation due to end customers of EMIs/PIs upon the failure of a safeguarding credit institution is challenging because of real-time transactions occurring at levels in the chain separate from the failed credit institution and possibly even after the time that the safeguarding credit institution has failed.
From the failed credit institution’s exclusions view file, the FSCS will know the amount of total safeguarded funds that were deposited in the failed credit institution. However, to compute the compensation due to EMI/PI customers, it also needs to receive customer data from the EMI/PI to determine the eligibility of end customers and each eligible customer’s proportion of the safeguarded funds.
Generally, depositor protection compensation is calculated by reference to eligible deposits held on the date the credit institution is in default. However, where the EMI/PI has also failed, and the FSCS compensation will go directly to the end customer rather than to a new safeguarding account, the FSCS will need to calculate entitlements to the amount of compensation on the date of the EMI/PI’s failure. This will allow for adjustments in the amount of compensation payable by the FSCS if the customer has spent some of its e-money in the intervening period, for example.
Each end customer would be considered against the eligibility requirements and eligible customers would be separately protected up to the deposit protection limit (£85,000).
Time limits and maintenance of customer details
In order for the FSCS to assess eligibility and operationalise pay-out on a timely basis, it would be important for EMIs and PIs to maintain up to date customer information in a usable format that can be transmitted to the FSCS quickly upon the failure of a safeguarding credit institution. While the PRA cannot make rules requiring such firms to maintain such customer details, it is in the EMI/PI’s interest to enable the FSCS to pay compensation quickly. The PRA considers that due to the lack of SCV requirements on EMIs/PIs, and the potentially large number of end customers due compensation, the pay-out timelines for FSCS will likely be longer than the targeted seven days for direct depositors. In recognition of the complexity of the determinations and reliance on third parties, the PRA proposes to amend DP 9.4 to allow the FSCS additional time to effect a pay-out in respect of safeguarded funds in the event that there is a delay, beyond the current payout timelines as provided for in DP 9.3, in the FSCS being able to determine the amounts to be paid to eligible customers.
Subrogation
In the event of a direct payment to the end customer, the PRA proposes to amend the subrogation rules in DP Chapter 28 to suspend an eligible end customer’s rights against the EMI/PI, in order to prevent double-recovery, i.e., both receiving FSCS compensation and exercising their contractual rights of repayment vis a vis the EMI/PI. The proposed rules would then extinguish the rights of customers against the EMI/PI when, and to the extent, the FSCS has made recoveries from the failed bank. These amendments are designed to preserve the effect of the anti-set off provisions in the EMRs/PSRs for the benefit of the FSCS during the failed credit institution’s insolvency process.
Additional changes
The proposed rules also amend DP 2.2 to make explicit the existing interpretation for looking-through credit institutions and investment firms to beneficiaries when depositors/account holders are not absolutely entitled to deposits. This amendment is for the avoidance of doubt to clarify existing treatment of beneficiaries given the changes to 2.2 needed to enable the look-through proposals regarding safeguarded funds.
Consistent with the policy outcome of protecting certain safeguarded funds, the PRA proposes to amend DP 43 to clarify that the Class A tariff base includes accounts holding safeguarded funds. The PRA considers this is also consistent with the treatment of funds that the account holder is not absolutely entitled to (eg, bare trusts).
Other types of segregated accounts
The PRA considers that similar types of segregated accounts may also need to be reviewed to determine whether end customers should also benefit from FSCS protection. The PRA welcomes responses as to whether there are similar accounts that are not already covered by PRA rules. However, the PRA acknowledges that a full review of the FSCS protection for other segregated accounts may take some time, and considers that such a review should not delay fixing this known gap in protection.
Action Required
If the FIs are handling safeguard deposits, then they must check the usual FSCS compensation eligibility of the customer and report the customer accounts in SCV / Exclusion file as normal. No specific action is required by FIs.
Background
Where a firm with Part 4A permission to accept deposits has that permission restricted by the PRA and subsequently defaults, Depositor Protection 3.2 in the PRA Rulebook (DP 3.2) provides that eligible deposits accepted while the firm held its Part 4A permission continue to benefit from FSCS protection.
DP 3.2 was drafted when the UK was still a member of the EU and was intended to apply only where the PRA significantly restricts a firm’s Part 4A permission to accept deposits but remains PRA-authorised. The PRA considers that, following the UK’s withdrawal from the EU, there is a small risk that the rule could be interpreted as applying in another circumstance: where an overseas firm with a deposit-taking permission in the UK surrenders their permission and PRA-authorisation (or their permission and PRA-authorisation lapses as a result of the expiry of the TPR or SRO), but the firm continues to hold deposits that it accepted in the UK. The PRA considers this uncertainty to be undesirable and that a potential unintended consequence of this ‘expansion of scope’ could be an increase in FSCS levy costs to the industry.
Proposals
The PRA considers that deposits held by a UK branch of an overseas deposit-taking firm that has had its Part 4A deposit-taking permission and authorisation from the PRA removed should cease to benefit from FSCS protection. For example, DP 3.2 would not apply where the overseas deposit-taking firm transfers eligible deposits to an overseas branch before surrendering its Part 4A permission and PRA-authorised status. Following EU withdrawal, eligible deposits transferred from the UK to the EU by overseas firms should generally be covered by the firm’s home state deposit guarantee scheme under the Deposit Guarantee Schemes Directive (2014/49/EU) Opens in a new window.
The PRA proposes to amend DP 3.2 to reflect the original policy intent and remove any potential for ambiguity. The PRA proposes to make clear that a firm must be authorised by the PRA at the moment they default for their depositors to be eligible for compensation. The PRA considers that this would reduce both uncertainty and the risk of the rule being interpreted in a way that expands the scope of FSCS coverage and creates a potential increase in FSCS levy costs to the industry.
The PRA proposes to add a new notification obligation on overseas firms, in similar terms to the notification obligation on them at the time of EU withdrawal, to ensure UK branch depositors are aware of the loss of FSCS coverage and is provided with information on whether and to what extent their deposits will be protected by another deposit guarantee scheme when the firm has its PRA authorisation cancelled.
Action Required
No action is required from the FSCS reporting perspective, but from an operational, finance or customer service point of view, the FIs can use their usual channel of resolution.
Also, it has been mentioned that a firm must be authorised by the PRA at the moment they default for their depositors to be eligible for compensation.
If the UK branch of an overseas deposit-taking firm that has had its Part 4A permission and authorisation from the PRA removed, should cease to benefit from FSCS protection.
Background
Depositor Protection 19.1 and 19.2 in the PRA Rulebook (‘DP 19’) require firms to notify depositors of a merger, conversion of subsidiaries into branches, transfer, or similar operation and provides such depositors with a three-month withdrawal right. In this event, the withdrawal right allows the depositor to withdraw the amount of their deposit that exceeds the FSCS coverage limit at the time of the operation and, if desired, transfer it to another firm, without incurring any penalty. The policy intent behind this rule was to ensure that depositors could retain the same level of FSCS protection in the event their total protection would be less after the restructuring than before.
Proposals
The notification and withdrawal right is currently wider than it needs to be and applies regardless of whether the depositor would suffer a reduction in the total protection under the FSCS. If a depositor’s overall FSCS protection is not affected by the transaction, the PRA considers the withdrawal right is not achieving the purpose for which it was intended and is creating an unnecessary operational burden on, and cost to, firms.
The PRA proposes to amend DP 19.2 to set out that the withdrawal right would only apply if the level of a depositor’s overall FSCS protection is reduced by a restructuring operation. The PRA considers that depositors would still have a right to be informed that the entity that holds their deposit is undergoing some form of restructuring operation, and is not proposing to change the notification requirement. However, these proposals would reduce the operational burden on firms as they will no longer need to implement systems to comply with the obligations associated with the rule DP 19.2 unless there is a reduction in FSCS protection.
For example, if a merger of two unrelated entities reduces a consumer’s combined protection from £170,000 across the two entities to only £85,000 in the newly merged entity, the withdrawal right would continue to allow withdrawal of up to £85,000 without penalty. But if there is no overall impact on the level of FSCS protection before and after the merger (for example, where entities in the same banking group merge, or if deposit accounts are transferred from one UK-based entity to another UK-based entity within the same banking group), there would be no withdrawal right.
Action Required
No action is required from the FSCS reporting perspective, but from an operational, finance or customer service point of view, the FIs can use their usual channel of resolution.
PRA has provided detailed information about the withdrawal of the deposits.
Background
The Depositor Protection Part of the PRA Rulebook (‘DP’) contains various rules that require firms to notify depositors about the scope of FSCS protection arrangements. In particular, with respect to deposits that are not eligible for FSCS protection, DP 17 requires firms to provide annual information sheets and exclusions lists.
The PRA has become aware that this notification requirement is unduly burdensome to firms with depositors who are not entitled to FSCS protection by their legal personality.
Proposal
The current rules in DP 17 transposed the EU Deposit Guarantee Schemes Directive (DGSD).footnote [21] Now that the UK has left the EU, the PRA considers that they should be amended to reduce both the operational burden on, and cost to, firms.
The PRA is proposing to remove the Chapter 17 annual notification requirement for depositors who are ineligible for FSCS protection by virtue of DP 2.2(4) (ineligible depositors). To ensure that such depositors are aware that they would not benefit from FSCS protection, the PRA proposes that firms would still be required to provide an information sheet and an exclusions list to each intending depositor, whether eligible or not, before entering into a deposit-taking contract, in addition to complying with the other requirements as required under Chapter 16. This would ensure that depositors clearly understand whether or not they will benefit from FSCS protection.
Action Required
No action is required from the FSCS reporting perspective, but from an operational, finance or customer service point of view, the FIs can use their usual channel of resolution.
Since PRA is proposing to remove the Chapter 17 annual notification requirement for depositors who are ineligible for FSCS protection, the firm doesn’t require to send the information sheet and exclusion list annually.
However, firms would still be required to provide an information sheet and an exclusions list to each intending depositor, whether eligible or not, before entering into a deposit-taking contract. So, the firm should ensure that the above proposal is accomplished while onboarding the depositor.
Background
In this section, the PRA sets out its proposals to amend its Statement of Policy ‘Calculating risk-based levies for the Financial Services Compensation Scheme deposits class’ (‘SoP – RBL’) to account for changes made to reporting requirements and the leverage ratio.
Proposal
Amendments to the non-performing loans ratio calculation
The SoP – RBL sets out the methodology used to calculate Capital Requirement Regulation (CRR) firms’ and Credit Unions’ risk-based contributions to the FSCS. The calculation takes into account several metrics, including firms’ non-performing loans (NPL) ratios. Each NPL ratio is calculated using data from the FSA015 template, or where this is not available, the FINREP F18 template.
Under the PRA’s Policy Statement (PS) 18/17 ‘IFRS 9 Changes to reporting requirements’ Opens in a new window (‘PS 18/17’), the requirements for several firms to report either the FINREP F18 or FSA015 templates were removed. As a result, the PRA has been unable to calculate the NPL ratio for this group of firms. As a temporary solution, these firms have since then been assigned the lowest possible risk score for this metric by the PRA – regardless of their riskiness. Since the overall amount levied across all firms is fixed, this means that these firms pay relatively less than before, and all others firms relatively more.
The PRA proposes to introduce a permanent solution to this issue and re-introduce the original policy intent by amending SoP – RBL to allow a proxy for the NPL ratio to be used for this group of firms. This proxy would use data from the FINREP F7 and FINREP F1 templates rather than the FSA015 or FINREP F18 templates. These firms would be ranked and rated separately from others to calculate the NPL ratio, to maintain consistent treatment across the groups for which differing data is used. Please see Appendix 6 for full details of the proposed calculation.
Amendments to the leverage ratio calculation
Another metric used in the calculation of firms’ risk-based contributions to the FSCS is the leverage ratio. Currently SoP – RBL assigns firms an individual risk score (‘IRS’) of 0 if their leverage ratio, as defined in the CRR, is greater than 3%, and an IRS of 100 if it is equal to or below 3%. This threshold is now out of line with the PRA’s Supervisory Statement ‘The UK leverage ratio framework’ updated in October 2021 (‘SS45/15’).
To achieve consistency between the SoP – RBL and the leverage ratio framework set out in SS45/15, the PRA proposes to change the threshold in the SoP to 3.25% and to specify that the leverage ratio would be defined as in the PRA Rulebook. Full details of the proposed amendments are set out in Appendix 6.
Action Required
No action is required from the FSCS reporting perspective, but from an operational, finance or customer service point of view, the FIs can use their usual channel of resolution.
PRA has proposed amendments in the reporting requirements and ratio calculation for SoP-RBL. The FI has to check the amendments and update its reporting process accordingly
Background
In this section, the PRA sets out its proposals to update SS18/15, SoP – DGS and SoP – RBL to ensure that they reflect the current PRA rules in force as well as the proposals in this CP and remove spent provisions from the PRA Rulebook.
Proposal
The PRA proposes to update SS18/15, SoP – DGS and SoP – RBL to:
- reflect the proposals consulted on in this CP, this will include changing the name of SS18/15 from ‘Depositor and dormant account protection’ to ‘Depositor protection;
- reflect the UK’s withdrawal from the EU; and
- improve the clarity of drafting, for example by removing material that is no longer relevant, due to the expiry of the relevant transition period or the deletion of certain PRA rules.
The PRA also proposes to delete rules 17.3 and 20.3 in the Depositor Protection Part of the PRA Rulebook (the ‘Rules’) as, given the period since IP Completion Day, the Rules are now spent.
Action Required
No action is required from the FSCS reporting perspective, but from an operational, finance or customer service point of view, the FIs can use their usual channel of resolution.
PRA has provided the information about this CP update on the respective policy statements.
Provide utmost accuracy and Complete Peace of mind
We will be able to help you in whatever the stage of your regulatory reporting programs
FATCA / CRS Reporting 2023 – Deadlines, Updates & Challenges
The shift in financial and economic conditions all over the world requires stringent regulatory scrutiny. Regulators demand financial institutions to improve transparency in their reportable accounts and tax revenues.
As you are aware, after decades of discussion and dialogue finally in 2014, the Organization for Economic Co-operation and Development (OECD) introduced CRS as a global legal framework for Automatic Exchange Of Information(AEOI) between multiple jurisdictions to promote tax transparency and prevent offshore tax evasion. OECD directs the participating jurisdictions to obtain information from the Financial Institutions on the financial accounts held by the non-residents. This information will then be exchanged annually among the relevant jurisdictions. So far 115 jurisdictions around the globe have adopted CRS to maintain the integrity of the tax systems by combating offshore bank secrecy.
Every financial institution is scrambling to get over the line of HMRC CRS deadline every year around April and May. Nevertheless, on the regulatory reporting front, authorities are more stubborn on respective deadlines & Reporting accuracies, hence enterprises are shifting to digital automation at a faster pace never to be “battlefield ready” with a good flood-defence system. It’s more strategical rather than a routine regular exercise.
CRS reporting landscape constantly demands increased dynamics of changes including the following
- Reporting jurisdiction addition/drop from AEOI regime.
- Sustained demand from HMRC on correct account classification & reporting.
- Continuous impact on onboarding platforms to capture extended and precise tax declaration and ongoing maintenance and review.
- Periodical review & ongoing centralised record maintenance on Self Certification.
- Platform to support HMRC queries and submit a revised variation.
- Platform to support Remediation, Cleansing & Data Enrichment using single customer view data.
Lets start discussing the above said changes and the challenges around the CRS reporting and what banks and other financial institutions should do to be proactive with an effective plan to manage the CRS FATCA regulatory obligations seamlessly.
What are the challenges faced by the financial institutions in CRS reporting?
Data quality is one of the main challenges in any regulatory reporting as the legacy technologies or the manual operational approach results in data inaccuracies, data gaps, inconsistent taxonomies & consolidation of entities that affects the accuracy of the CRS reporting and increase the operational risk.
Further, as the new compliance processes require more granularity around the reportable data, FIs with their legacy operational approach find it hard to produce data that is fully compliant with HMRC FATCA & CRS reporting guidelines.
Achieving the regulatory compliance mandate is time-dependent and involves operational risk due to manual data scrubbing. Manual validation causes are results in error-prone and require additional investigation from the Regulator prompting questions and enquiries over the operational efficiency of the business and the data which lead to reputational risk.
What do the financial institutions need to do?
As you are aware that the deadline for HMRC CRS/FATCA reporting for 2023 is 31st of May, it is the right time for financial institutions to initiate the gap study and analysis on your CRS data and reports at the earliest so that you will be fully geared up along with effective data governance framework for this year CRS reporting on time.
Financial Institutions need to foster collaboration between various teams such as Operations, IT, Legal, and Taxation that ensures comprehensive and hassle-free compliance to robust regulations. Financial institutions should revisit their existing KYC/AML and client onboarding procedures with an exhaustive due diligence procedure to segregate and categorise the CRS reportable accounts. It requires a robust framework, domain expertise, a unified solution, etc to handle the ever-evolving CRS requirements, address the challenges and be prepared for the reporting obligation now as well as future.
Macro Global offers ”Fully-Automated, Future-Proof, Cloud/On-Prem/Hybrid” platform CRS Stride – AEOI / HMRC CRS & FATCA Reporting Solution that is unique and flexible comprising both Audit & Automation processes as a single integrated platform crafted with all our experience & expertise learnt over years.
With our futureproof “CRS Reporting Solution”, financial institutions would be better placed to furnish the precise CRS data in line with the HMRC CRS specifications.
We take care of your CRS reporting obligations in its entirety and assist you not during the deadline but prepare you before and after the submission. You have one less thing to worry about and fully confident that your compliance adherence completely addressed throughout with an assurance validation by our tax and subject matter experts. You could save substantial cost and effort by your compliance team to prepare and submit CRS report without worrying endless technical challenges around the submission, remediation & managing variation and finally “Assurance Certification”.
One great reason to choose us is the product maturity as it’s already tried and tested with every small detail addressed leaving you to focus on your business than burning midnight oil to tackle endless queries from HMRC.
If this sounds like something you are keen, pls drop a note to our sales team at salesdesk@macroglobal.co.uk or call us at +44 0204 574 2433 to book a demo or for a free no-obligation product trial.