Blog

feature thumbnail
Back to blog

Our last blog post helped readers broadly understand information security and compliance challenges when it comes to collections. As the logical next step, we decided to offer wisdom from within re:ceeve on what we do as a company to ensure that data security is prioritised at the highest levels. We did not look far, we sat down with our CTO and Co-Founder Michael Backes and discussed with him 5 important questions that any prospective client of ours might/should ask.

With his diverse experience heading tech teams and leading start-ups, Michael’s experience in dealing with data security and compliance is quite extensive to say the least. Here is our CTO’s take on privacy, compliance and data security for anyone who is considering digital communication in debt collections. 

1) How do you maintain privacy and compliance when sending digital outreach in collections – e.g. when sending emails? 

Michael: We have a lot of information in terms of past-knowledge and best practises from different markets, so we are able to suggest baseline configurations if you just ask us.

We also help our clients at an individual level by asking them which regulations affect them most and which ones carry higher risk of non-compliance and higher penalties. Take an example such as which days to send an SMS. Our on-boarding is designed to walk you through both the regulatory baseline, as well as what are best practices and things to consider, like avoiding SMS on Sundays for corporate image reasons.

It is pretty easy for us to identify what is likely to be relevant for you, and we incorporate that into getting you up and running, but after onboarding, there is a bit of room to plan things around your comfort level. If you are not entirely convinced that your data set is 100% accurate, then you can be more cautious in your approach.

For example, you do not want to send 4000 SMS to non-customers accidentally because the phone numbers are wrong. If such SMS then contain detailed Personally Identifiable Information (PII) then the risks are significantly higher. The simple solutions include removing the PII, or requiring validation or login prior to disclosing information.

Remember, you need consent and agreement from your customers to send SMS and emails to them. Ideally there is already an online presence, like online banking, where enough baseline terms and conditions exist that allows you to reach out to customers digitally.

2) What steps do we assure that convince legal departments to sign off on a digital approach? What are the legal dept’s common concerns and how does our software allay them?

Michael: Everything is done with a security-first approach. We have a continuously ongoing compliance process, based upon such standards as ISO and other security frameworks. This ultimately ensures that we are compliant with all the regulations that are required for us to operate with banks and our clients. In addition to ISO, we leverage audits based upon OSTTMM for IT security. We even have PCI compliance if that applies to you.

We also have a strong supplier selection process. Any middle-man communication service provider through whom email and SMS are sent are all vetted by us to be compliant with GDPR. So your number 1 priority: the data does not leave the EU, the data gets deleted at the provider within said days, other stipulated risk reduction mechanisms, etc., are all checked for by us.

It is worth mentioning two examples: Infobip and Twilio. We use Infobip for inside the EU – all data stays in the EU. Twilio is a bit different, we use them for all US-based clients. So their data remains compliant with all the data regulations and laws from the USA.

3) How old is the problem of digital data privacy and compliance? how much of it is related to only GDPR?

Michael: It has been a problem really since the internet existed, now more so than ever. In the pre-GDPR era, it was very country specific. GDPR basically unified all these different standards across the EU. Before that you could choose a country, say Ireland, only because the standard of data protection there was lower, but data subjects and governments realised this loop-hole ultimately does not protect their data subjects since any company could then choose to do business from a jurisdiction that had lower data protection standards.

Also several bodies regulated data in tandem making it difficult for businesses to be compliant. E.g. Pre-GDPR, 16 different agencies covered privacy issues in Germany, and any business needed approval from all of them to process data, but now there is a centralised body. Nowadays, the variations in law are limited from one country to another. Every country has rules related to data protection – China, USA, Australia, etc. An interplay of data subjects’ location and data controllers’ location decide their applicability.

4) What are the real legal limitations/compliance/regulatory limitations while doing digital outreach?

Michael: The answer to this question starts with yet a basic question: Where is your consumer/data subject? This is important because, as stated above, variations in how data protection rules apply depend on the geographical location. Despite common rules like the GDPR, these local variations may stipulate when a data subject may be contacted and when not. In Germany, someone can be contacted on public holidays, but in Latvia, the law says no one should be contacted on Sundays and public holidays. This is not a big deal with emails, but with SMS, there are time restrictions that would deem certain frequency or timings overly aggressive. Depending on the digital channel, such strategies must be adjusted to comply with all laws.

Let us consider WhatsApp: Everyone talks about using it, but from a GDPR perspective (not from a collections regulations perspective) the data, most likely or, certainly, does leave the EU. This means that data controllers must accept the risk that PII leaves the EU. There is not a law against it, but the data controller needs to know that there is a risk exposure. Between the US and EU, for example, the agreements have been consistently thrown out by the EU courts. So even though there is consensus that eventually a deal will be worked out, it is still a risk to consider.

On the issue of communicating with clients, there are different practices preferred by different players. There are those that put only the bare minimum details, but some prefer to communicate with all the information such as first name, address, email, bank account number, etc. in the repayment requests.

As stated above, the real issue becomes the reliability of the data set. The extent to which you can put PII in a communique depends on how confident you are with the correctness of every person’s details, especially contact details.

In an SMS for example, we tend to suggest not having any PII, no names, bank details, etc. Since there is also a limit on the number of characters, we suggest the collecting party (Banks and DCAS) to leave it out.

If you are unsure, go with a minimum amount of information and go with the assumption that your debtor knows about the debt and all its reminders.

What we are able to ultimately offer is the flexibility, if Latvia suddenly says you can’t send SMS reminders after 5 PM, you can implement such limitations via our platform in under 2 minutes. This flexibility makes easy adapting to new rules.

5) What other questions should someone be asking while navigating compliance concerns in digitising/digitised collections?

Michael: There isn’t really too much extra to think about once you have done the basics. Regardless of what platforms you use, you will have a process to go through and make sure that you have both checked all the required boxes and also thought a little bit about what you want to achieve, in order to make good decisions in your content.

The other thing that helps out is selecting a partner on the other side who values both privacy and security. It’s not only about the couple of certificates, but that the DNA of the company has those things ingrained in it.

Latest Blog Posts

View All