FATCA reporting, and the filings required for the similar UK and OECD regulations, are trigger issues that demand a business response. With no current process to fall back on – as new reporting, there is no ‘business as usual’ method – the options are to throw people at the problem or to invest in a technology solution.
With most businesses opting against manual solutions because of the volume and complexity of reporting, the decision becomes whether it is more appropriate to build out existing technology, or to work with vendors and bring in third party solutions.
2015 REPORTING: FATCA
At the outset, FATCA reporting looked manageable – a single set of reports to the IRS detailing American account holders. Time has clouded the picture. The proliferation of Inter- governmental Agreements (IGAs) means that most reasonable sized financial institutions will be reporting to many different governments. While details are yet to be finalized for many jurisdictions, it is expected that there will be a variety of different reporting validations, reporting formats, and various other differences. Previous experience of filing statistical data in the EU – Sales Listings and Intrastats, for example – demonstrate little consistency between countries in terms of filing formats or additional data.
For their 2015 FATCA filings, many businesses are dealing with a relatively limited number of reportable accounts. The main complexity comes in filing these in several jurisdictions.
2016 AND BEYOND – UK REPORTING AND CRS
Looking to the medium and longer term, the picture is complicated by the filing requirements for the UK’s reporting regime for the Overseas Territories and Crown Dependencies (UK CDOT) with reporting due in 2016, and for the OECD’s Common Reporting Standards (CRS) with reporting due in 2017. Under the UK regulations, the complexity expands in two main directions. While similar to FATCA, reporting requirements will not be the same – which means different rule-sets and validations need to be applied. And the data itself required to be reported will also be similar, but not the same. It is possible, for example, that a charity could be exempt under US FATCA but reportable under the UK regulations. Moreover, the volume of reportable accounts will increase dramatically. This requires a solution that can scale over time to cope with increasing complexity and volume.
Most organizations, particularly those with substantial UK operations, expect the number of reportable accounts to increase significantly under the UK regime.
CRS shifts the goal-posts even further. It requires multi-lateral information reporting which means that a financial institution will potentially be reporting to very many different jurisdictions. CRS has different account definition and de minimis rules to FATCA, which have the potential to include a much wider population of accounts. This means that the number of reportable accounts will increase dramatically.
Where an organization is filing solely to the IRS under FATCA, in-house solutions may well meet the bill – the data fields are not complex, and the XML schema is unlikely to change significantly post go-live. Complexity really kicks in for a business filing in multiple jurisdictions, to multiple tax authorities. Partnering with a vendor with a strong track record in related multi-jurisdictional tax and regulatory filing can mitigate this uncertainty.
Some businesses are taking a multi-tiered approach to reporting – tactical in-house (or outsource) solutions in 2015 for FATCA, followed by a more strategic vendor selection for UK CD-OT and CRS in years 2016 and 2017.
Cost is a key factor in any decision between in- house and third party technology, both in terms of overall investment and opportunity costs.
Requirements gathering and functional specifications are critical to the success of any IT project and require skilled and experienced resource. In a FATCA project, this is inevitably going to place a heavy burden on the tax and compliance experts themselves. Retaining their involvement through the design, development, testing and commissioning phases of an in-house build will inevitably have a knock-on effect on other areas of their role.
A typical software life cycle is 7 – 10 years, and a standard industry estimate is that around 70% of software costs occur after implementation. These costs are easy to quantify when working with a vendor, where on-going support, maintenance and enhancement licenses are agreed in advance; less so when considering the on-going cost of an in-house build. Hidden costs in an internal build include:
- The average tenure of IT staff and the likely hand-overs required
- The ability to create and maintain adequate solution documentation
- The likelihood of anticipating future requirements (business or legislative) and scheduling the appropriate upgrades
It is also important, however, to assess vendor risk over the project life cycle. Being left with unsupported technology due to a supplier withdrawing from the market gives the worst of both worlds! Smaller vendors dependent on few products or clients for their success are particularly susceptible to changing business conditions. When working with vendors it is prudent to work with an established provider.
Tax authorities are more comfortable with industry using vendor solutions that the authorities know and are familiar with – and in many cases have input into the design and rule-sets – than those developed in-house.
Specialist software vendors work with many leading businesses and third parties, including advisors and regulatory authorities, to ensure industry leading standards: an in-house team is unlikely to have such wide exposure – or the deep expertise that comes with working for many years in a specific field.
BESPOKE VS. OFF-THE-SHELF
A perceived advantage of in-house builds is their seeming ability to meet precise internal requirements in a way that off-the-shelf vendor solutions cannot. This flexibility, however, often comes at a price.
A FATCA committee at a large financial institution is often composed of representatives from several parts of the business, and all with subtly different requirements. When looking at in-house IT deployment in similar fields (Tax Provisioning, for example) bringing all of these together can often – if not managed tightly – result in a complex, unwieldy solution that proves difficult to use and impossible to Strong management and discipline over defining functional requirements are critical to success.
Many businesses seek to combine the benefits of third party solutions with the flexibility of bespoke software by heavily customizing off-the-shelf packages to meet their requirements. Taken to extremes, however, this can cause trouble. Many business systems have been so heavily bespoked that there is a double maintenance requirement – on the vendor for the core technology and on the in-house IT function to maintain the complex customization.
Well-managed, third party vendor solutions – while allowing for customisation for different business units – impose a degree of consistency across
the different parts of a business. A more rigid approach is using a Software as a Service (SaaS) model, where the interaction – through a browser rather than on-premise servers – effectively removes end user customisation from the agenda.
The right approach for making FATCA solution decisions will vary from business to business. Key factors in choosing where to ‘buy’ and which vendors to select may include:
- Stability of specialist vendor short term flexibility of in-house build
- Overall cost of deployment – in-house vendor
- Benefits of standardised processes for regulatory and other authorities
- Opportunity cost of in-house builds
- Risk profile of vendor and in-house solutions
Short term there is likely to be a tactical mix of in-house build and third party solutions. As with most areas of tax technology, the market will over time settle around a handful of key vendors with only the real outliers (in terms of in-house capability or organizational complexity) maintaining in-house solutions.