An open letter to the FPS
By John Bird, Managing Director of Blackbaud Europe.
As a provider of fundraising CRM software specifically for the not for profit sector, Blackbaud Europe has specifically technical concerns regarding the workability of the FPS proposal. This is a summary of the key points we raised with George Kidd, Chair of the FPS working group.
The FPS represents a data processing challenge that resembles virtually no other process charities currently follow and few, if any, have the tools available to meet it. It is our view that a combination of technical and logical barriers will prevent all but a small handful of organisations being able to fully screen their data against the FPS list.
How is the FPS process different to everything else?
- As a norm, charities import data into their CRM system and deduplicate that data – the end result is to bring in additional contacts or to enhance existing records. In the case of the FPS, the aim is to screen their data against a list of external contacts (FPS list) – but not to import any of the data from the FPS.
- MPS or TPS screening are not the same processes as FPS:
o Firstly, the process of matching an individual record is far simpler on MPS/TPS, as the match is solely against a physical address or a telephone number. As FPS is multi-channel, the expectation of a match would be across a combination of physical address, telephone, email and name.
o Secondly, with MPS/TPS, screening is part of a process of fulfilment that is part of a campaign. In other words, it is done irregularly. The requirements of FPS’s 30 day window to contact a supporter means it must be executed at least fortnightly, if not weekly.
o Thirdly, MPS/TPS usually leads to a fulfilment process outside of the CRM database, so the process of extracting data and screening it externally makes more sense. The application of the FPS to all channels which may be delivered on a small scale from within the CRM system (e.g. an email campaign) make the natural home of FPS screening very different to MPS or TPS screening.
We make these points to highlight that the process of FPS screening is entirely new for most, if not all, charities and so it would be wrong to assume that in the time available and with the guidance currently published, charities will be able to comply using existing tools and knowledge.
Specific examples will illustrate the difficulties charities may encounter:
- It is not yet known what the consumer adoption of the FPS will be. A conservative estimate might be 250,000 individuals, only 0.5% of the population. A data file of 250,000 contacts will not be small – it will require specialist IT expertise to understand how to move it whilst keeping it secure. This specialist knowledge will also be required to understand the technical formats suggested in the proposal. This is no small challenge for many charities, even of a medium size.
- Additionally, at some point, to screen against their own data, the data will need to be extracted and moved around within the organisation – where the benefits of the secure file format would be lost. However secure the file transfer format, ultimately large volumes of public information will be held and processed outside of this format in a large number of charities. This must be a concern for all involved.
- The tools charities have for data cleansing and data import are typically built into their fundraising CRM system. The FPS data cannot be imported into the charity CRM system; it is neither practical to bring such volume into a CRM database up to twice per month, nor is it clear if the charity would even be entitled to import the data. Therefore, to screen against the FPS data, the charity would have to export its entire CRM database into an intermediate environment to perform the screening. This intermediate environment, and the software tools to do this, would not exist in most charities.
- One consideration to reducing the data volume and making the process more manageable is that only changes or additions to the FPS should be checked. Logically, this does not work. If a charity has acquired a supporter who was already on the FPS, then that supporter would not be on an FPS ‘changes’ file; therefore the entire FPS list would need to be screened each time.
- Of lesser significance, page 28 of the consultation refers to ‘seeds’. It is not understood how ‘seeding’ works for an opt out process. Unless those seeds were first notified as supporters to all charities, how would the regulator be able to test that they had been correctly opted out?
It is unclear what impact GDPR ‘opt-in’ legislation will have when it becomes law around one year after the anticipated launch of the FPS. If we are to assume that an individual’s ‘large red button’ preference as expressed on the FPS trumps that of an opt-in explicitly given to a charity, then the FPS continues to have an unambiguous role in the future. However, if that is not the case, and the opt-in trumps the red button, I would be concerned that the solution charities develop in 2017 will need to be significantly revised in very soon afterwards in 2018.
To make the FPS work, we would suggest that the FPS and CRM database providers, like Blackbaud and several others, will need to be given a greater responsibility in supporting the matching and screening process:
- The FPS data should be exposed only via an API. This would be more secure than a data file and more manageable – and would avoid the FPS data existing on charities’ servers.
- The FPS must publish matching criteria to determine how an individual should be considered as ‘identified’, with thresholds published to qualify as a match. This could be a typical matching technique, e.g. matched surname = 10 points, matched house number and post code = 20 points, matched email address = 50 points, and only a match scoring over, say 40 points, would be considered a match.
- As suggested, each individual record on FPS should carry a unique identifier. The charity could store that identifier and this would remove the need to rescreen each contact each time a screening is executed.
- Although the FPS API should be accessible to charities registered on the FPS so they could undertake the work above themselves, it would also need to be available to authorised technical suppliers, so they could consume the API and build these solutions to help their clients.
Finally, whilst we understand the intent to move quickly and avoid a tender process, we would suggest that whatever solution is finally reached, it would not be unreasonable to expect an absolute minimum of 12 months from the publication of the sample file format and working API details, before charities are expected to be in a position to try and use the FPS data. A useful parallel could be drawn from looking into how long the work between HMRC and various suppliers took a few years ago, when the Gift Aid XML format was introduced.
It is our view that the debate in the sector has moved positively beyond the initial reaction to stricter regulation following the Etherington Review. However, concerns and apparent resistance to the FPS are grounded in difficulties in both the technical and logical processes involved. We sincerely hope that Blackbaud and other similar organisations are brought in close to the technical feasibility piece. Working collaboratively, we can ensure the FPS works for charities on a practical level. It is simply too big a challenge to leave individual suppliers or charities to each find their own path.